werf converge как единая точка входа

Уровень: expert ~35 мин Практика: Vikunja (продолжение) (AGPL-3.0)

Что нужно знать перед уроком

  • M8.06 — Distroless и минимизация размера — завершающий урок серии продвинутых тем Werf модуля M8
  • M4.05 — Nelm CLI — нужно понимание отдельных команд release install, с которыми сравнивается converge

Что нужно знать перед уроком

M4 урок 5 — команды Nelm CLI по отдельности. M8 урок 4 — разделённый через bundle сценарий. Этот заключительный урок модуля M8 разбирает werf converge — единую команду, интегрирующую build и deploy.

Теория

werf converge — build + deploy одной командой

werf converge объединяет возможности werf build и деплоя (werf deploy/по сути обёртку над Nelm) в единую операцию: собирает образы (используя весь кэш и cache-repo из M8 урока 2), публикует их, и сразу применяет Helm/Nelm-чарт в целевой кластер — всё за один вызов команды. Это основной, рекомендуемый способ деплоя в «нормальном» сценарии, когда у CI-процесса есть непрерывный доступ и к git-репозиторию, и к целевому кластеру в рамках одного job’а.

1
werf converge --repo example.org/mycompany/myapp --env production

Раздельные шаги: werf buildwerf converge --require-built-images

1
2
werf build --repo example.org/mycompany/myapp
werf converge --require-built-images --repo example.org/mycompany/myapp

Флаг --require-built-images инструктирует converge не пытаться выполнить сборку самостоятельно, а потребовать, чтобы все образы уже были собраны и опубликованы заранее (отдельным шагом werf build). Это разделение полезно, когда сборка и деплой должны быть раздельными этапами одного и того же CI-пайплайна (например, отдельные stage’ы build и deploy в .gitlab-ci.yml, позволяющие независимо перезапускать один из этапов без повторного выполнения другого, или явно разграничивающие права доступа джобов — сборочный джоб не должен иметь прав на деплой в кластер, и наоборот).

Сравнение трёх подходов деплоя

ПодходДоступ к git нужен дляКогда использовать
werf converge (единая команда)Сборки и деплоя одновременно, в одном окруженииТиповой CI-релиз, простой пайплайн, разработка
werf buildwerf converge --require-built-imagesОбоих шагов, но раздельно во времени/джобахРазделение stage’ов build/deploy в одном пайплайне, независимый повторный запуск шагов
werf bundle publishwerf bundle applyТолько на этапе publish; apply вообще не нуждается в gitAir-gapped деплой, полное организационное разделение CI и деплоя, деплой сторонним инструментом (M8 урок 4)

Когда локальная разработка предпочитает раздельные шаги

Для локальной разработки, где код меняется часто, но образы пересобираются не при каждом изменении конфигурации Helm-чарта, разработчик может использовать отдельный nelm release install (без пересборки образов вообще) для быстрой итерации над templates//values.yaml, прибегая к полному werf converge только когда действительно нужно пересобрать изменившийся код приложения. Это ускоряет цикл разработки, избегая ненужных пересборок образов при чисто конфигурационных изменениях.

Частые ошибки и подводные камни

  • Использовать werf converge там, где организационно нужно разделение прав build/deploy. Единая команда неявно требует единого набора учётных данных с доступом и к сборке, и к кластеру — для более строгого разделения ролей нужны раздельные шаги или полный bundle publish/bundle apply.
  • Забывать --require-built-images при разделении на раздельные шаги в CI. Без этого флага converge может попытаться пересобрать образы самостоятельно, что либо дублирует работу, либо (при отсутствии доступа к исходному коду на этапе деплоя) приведёт к ошибке.
  • Использовать полный werf converge для каждой мелкой правки Helm-шаблона при локальной разработке. Это неоправданно замедляет цикл разработки, если образы приложения не менялись — быстрее использовать nelm release install напрямую для конфигурационных изменений.

Практика в кластере

🧩 Практика урока: Vikunja (продолжение) · лицензия AGPL-3.0
1
werf converge --repo $CI_REGISTRY_IMAGE --env course-m8

Затем внесите изменение только в values.yaml (без изменения кода приложения) и разверните его напрямую через Nelm, минуя пересборку:

1
nelm release install -n course-m8-vikunja -r vikunja .

Сравните время выполнения обоих подходов и сделайте вывод о том, когда каждый из них уместен.

Практика разработки

Настройте в .gitlab-ci.yml пакета Vikunja два альтернативных сценария деплоя: единый werf converge для стандартного релиза и раздельные werf build/werf converge --require-built-images для сценария с разделением stage’ов, обсуждаемого в теории.

Шпаргалка команд урока

1
2
3
werf converge --repo <repo> --env <env>
werf build --repo <repo>
werf converge --require-built-images --repo <repo> --env <env>

Полная сводная таблица команд Werf — 📋 werf .

Вопросы для самопроверки

Что делает флаг --require-built-images при werf converge?

Это ключевой флаг для разделения шагов build и deploy в CI-пайплайне.

Источник: Werf — документация — Separate Build and Deploy Steps

Какой из трёх подходов деплоя вообще не требует доступа к git на этапе применения в кластер?

Это разобрано в M8 уроке 4 — bundle apply полностью независим от git.

Источник: Рекомендуемая литература

Оправдано ли использовать полный werf converge для каждой мелкой правки только Helm-шаблона при локальной разработке?

Полный converge с пересборкой избыточен для чисто конфигурационных изменений.

Источник: Рекомендуемая литература

Что объединяет werf converge в одну команду?

Converge — основная, рекомендуемая команда для типового CI-релиза.

Источник: Werf — документация — Reference

Рекомендуемая литература

Официальная документация

Статьи и блоги

Книги

  • Nigel Poulton. Docker Deep Dive. 2023. ISBN 978-1916585206.

Связанные материалы