Комментарии 27
Держать две конфигурации смысла нет.
Я видел драму в issue helm'a c интеграцией поддержки kubedog в нем.
Можно расчитывать, что вы не оставите надежду интегрировать этот функционал в Helm 3?
Не оставим, но в любом случае, когда выйдет стабильный helm 3 и будет способ мигрировать старые инсталляции на новый хельм — мы перейдем на кодовую базу helm 3 и будем использовать и развивать kubedog для слежения за ресурсами в werf.
Короче советую переходить на werf ;)
Вы рассматривали возможность использования helper image в раннере вместо использования тулзы as is в одном джобе?
В принципе ваша стратегия мне понятна – одно решение для любой системы хранения кода (или без неё вовсе), но всё-же это не очень удобно.
Пока нет, не смотрели, выглядит как немного не то.
Но интеграция с самим gitlab у нас есть и достаточно плотная:
- https://werf.io/documentation/reference/plugging_into_cicd/gitlab_ci.html
- https://werf.io/documentation/reference/plugging_into_cicd/overview.html
Например werf автоматом использует токены, которые выдает gitlab для логина в docker-registry, который также задает gitlab. Werf автоматом использует gitlab-environment если он определен.
Так-то по возможности стараемся лишнего не делать, если это можно переложить на внешнюю CI-систему.
Какой в gitlab есть ci конкретно для деплоя в кубы, где верф будет избыточен, можно подробнее на примере? Везде где используется kubectl apply или helm upgrade можно использовать и werf deploy — тут никаких ограничений не вносится, даже наоборот werf deploy проще использовать из-за наличия интеграции с гитлабом.
* Сборка образов на машине разработчика (для тестирования и отладки инструкций) без лишних приседаний, включая работу под Win, как, собственно, можно делать с Dockerfile.
* Параллельная сборка независимых stages. Это сделало бы werf реально мощнее того, что может сейчас предложить многоконтейнерный Dockerfile.
Werf ориентирован на kubernetes. И чтобы деплоить приложения туда. И в дальнейшем чтобы собирать образы используя runner-ы работающие в самом kubernetes.
Риск, конечно, всегда есть, но это ещё и Open Source, что при достаточном сообществе + использовании стандартных для экосистемы технологий (речь и про сам язык, и про применяемые внутри технологии вроде Helm) по меньшей мере даёт куда большие шансы на жизнь в будущем, чем в иных ситуациях.
Этот пост (и сама фича, про которую он) — хорошая иллюстрация того, как мы стремимся развивать сообщество вокруг проекта. Заходите ещё в tg-канал (werf_ru), чтобы увидеть, как активно там люди («сторонние», т.е. вне «Фланта») пользуются и им помогают, вплоть до оперативных патчей, решающих их проблемы.
О преимуществах werf в сравнении с использованием родных средств Kubernetes (и не только) хорошо рассказано в недавнем докладе (по ссылке краткий его обзор и там же полное видео). Там как раз о проблемах, которые в принципе возникают при построении Continuous Delivery на базе K8s, и как они решены конкретно в werf.
target из Докер файла можно указать?
Экспериментальный синтаксис с buildkit поддерживается? Все эти RUN --mount=…
И только для сборки можно использовать? А то сегодня полдня писал build.sh — грустно как то…
Target можно:
configVersion: 1
project: myproj
---
image: backend
dockerfile: ./Dockerfile
target: backend
---
image: frontend
dockerfile: ./Dockerfile
target: frontendПоддерживается любой синтаксис стандартного Dockerfile, т.к. для билда используется docker server (который может использовать buildkit).
После того как образы описаны в werf.yaml, собраны и опубликованы (через werf build-and-publish), их можно использовать для деплоя в кубы. Для этого надо описать chart. В описанном чарте можно ссылаться на имена образов из werf.yaml, в нашем случае например так:
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: backend
spec:
template:
metadata:
labels:
service: backend
spec:
containers:
- name: main
command: [ ... ]
{{ tuple "backend" . | include "werf_container_image" | indent 8 }}
env:
{{ tuple "backend" . | include "werf_container_env" | indent 8 }}Имелось в виду, можно ли использовать исключительно для сборки, возможностями деплоя не пользуясь. Только закончил описывать собственно деплой на helm 3, перешёл к написанию build.sh "универсального", намучался с "конфигом" на баш массивах, а тут ваш пост. :)
Понял, так тоже можно. Использовать только werf build-and-publish и werf cleanup. Вот по этому гайду https://werf.io/documentation/guides/gitlab_ci_cd_integration.html#pipeline просто пропустить стадию деплоя.
Поддерживается любой синтаксис стандартного Dockerfile, т.к. для билда используется docker server (который может использовать buildkit).
Поигрался сегодня, не смог заставить интерпретировать директиву syntax, создал issue https://github.com/flant/werf/issues/1767 — оно и не должно работать? Или нужно в схему werf.yaml добавлять какой-то buildkit: true, чтобы эмулировать что-то вроде DOCKER_BUILDKIT=1 werf build --stages-storage :local?
Решили. Была проблема с использованием RUN --mount.
https://github.com/flant/werf/pull/1769
Проверить можно в бета-канале <(multiwerf use 1.0 beta).
Зачем вообще упоминать команду ADD? Мое мнение, что ее нужно выжигать калёным железом в пользу COPY. Докеровцы реально "молодцы", что сделали такой комбайн как ADD — который и ссылки скачает, и архивы распакует, что делает прогноз того, что произойдет весьма нетривиальным. Поэтому мой выбор — вполне ясная директива COPY для копирования файлов внутрь образа.
На самом деле хочу сказать:
Ребята! Вы — молодцы. Похоже, что несмотря на весь мой скепсис — werf взлетит. Как говорится, одна картинка — лучше тысячи слов (отсылаю к скриншоту о сборке Dockerfile из статьи). Но не помешало бы описать больше юзкейсов, если вы действительно заинтересованы в популяризации утилиты и снадбить их видосиками в ASCII формате (забыл как этот чудесный сайт называется, который позволяет такие штуки)...
Интересно вообще как пойдет развитие технологий, но пока видится, что чтобы собрать какой-либо софт — нужно тащить целый стек разных штуковин. А хочется что-то типа самораспаковывающейся коробки — установить кубер, ввести команду "поехали!" и чтобы он сам из исходников все скомпилировал и внутрь себя задеплоил (влажные мечты опса). Работа в этом направлении, насколько мне известно, ведется, но как-то не особо видно результаты. Это отсылка к Argo-CI и Tekton.
Это https://asciinema.org/ скорее всего, делали ролики когда-то для статей про dapp. Жалко, что хабр не умеет делать для них embed, можно только ссылку с картинкой.
ну, так давайте убедим редакцию включить возможность включения embed asciinema )
Для встраивания стороннего контента мы используем API сервиса iframely.com
К сожалению, нам не известно планирует ли этот сервис добавить поддержку указанного вами ресурса.
Спасибо за ответ! Если вставка должна выглядеть просто так: <oembed>https://asciinema.org/a/168763</oembed> — то это не работает, т.к. браузер показывает URL без каких-либо картинок. Однако проверка вставки URL'а через сам iframely показывает другой результат. На чьей стороне проблема?Довольно странно. Спасибо, что обратили на это наше внимание. Нам потребуется некоторое время, чтобы с этим разобраться. Мы поставили соответствующую задачу коллегам из отдела разработки, но когда они смогут уделить ей внимание нам, к сожалению, пока не известно.
А можно использовать werf только для сборки и хранения образов? Например, мой проект пока не требует k8s, хватает докер-композа. Но удобный ci/cd и чистый registry хочется).
Собирать Docker-образы в werf теперь можно и по обычному Dockerfile