Введение

Что такое werf?

werf — это CLI-инструмент для организации полного цикла развертывания приложения с Git в качестве единого и универсального “источника истины”. werf может:

Собирать docker-образы.
Деплоить приложение в кластер Kubernetes.
Убеждаться в том, что приложение запустилось и нормально работает после завершения развертывания.
Пересобирать docker-образы при внесении изменений в код приложения.
Ре-деплоить приложение в кластер Kubernetes при необходимости.
Удалять ненужные и неиспользуемые образы.

Как werf работает?

Определить желаемое состояние

0. Конфигурация

Определить желаемое состояние

0. Конфигурация

1. Копируем Dockerfiles в репозиторий приложения

2. Создаем файл конфигурации werf.yaml

3. Описываем шаблоны helm-чартов для развертывания приложения

4. Делаем коммит

Converge

1. Вычисляем сконфигурированные образы исходя из текущего состояния Git-коммита.

2. Считываем образы, доступные в container registry.

3. Вычисляем разницу между образами, соответствующими состоянию для текущего Git-коммита и теми, которые уже доступны в container registry.

4. Собираем и публикуем только те образы, которые отсутствуют в container registry (если такие имеются).

5. Считываем целевую конфигурацию ресурсов Kubernetes, связанную с текущим состоянием, определяемым Git-коммитом.

6. Считываем конфигурацию имеющихся в кластере Kubernetes-ресурсов.

7. Подсчитываем разницу между целевой для текущего состояния Git и имеющейся конфигурацией Kubernetes-ресурсов в кластере.

8. Применяем изменения (при необходимости) к ресурсам Kubernetes, чтобы они соответствовали состоянию, определенному в Git-коммите.

9. Убеждаемся в работоспособности всех ресурсов, незамедлительно сообщаем об ошибках (при этом при возникновении ошибки можно откатить кластер в предыдущее состояние).

Конфигурация werf должна храниться в Git-репозитории приложения вместе с его кодом.

Обратите особое внимание на параметр project — он содержит название проекта. В дальнейшем werf будет активно его использовать во время converge-процесса. Изменение этого параметра потом, когда приложение уже развернуто и работает, будет связано с простоем и потребует ре-деплоя приложения.

Специальная шаблон-функция werf_image позволяет сгенерировать полное имя собираемого образа. У этой функции имеется параметр name, который соответствует образу, определенному в werf.yaml ("frontend" или "backend" в нашем примере).

На этом шаге werf генерирует имена целевых образов. Имена могут менять или оставаться прежними после очередного коммита в зависимости от изменений в репозитории Git. Обратите внимание, что имена образов детерминированы и воспроизводимы и привязаны к соответствующему коммиту.

Что такое converge?

Converge — это процесс сборки docker-образов (и их пересоздания в ответ на изменения), деплоя приложения в кластер Kubernetes (и ре-деплоя при необходимости) и контроля за работоспособностью приложения.

Команда werf converge запускает этот процесс. Ее может вызывать как пользователь, так и Ci/CD-система или оператор в ответ на изменения в состоянии приложения, описанном в Git. Поведение werf converge полностью детерминировано и прозрачно с точки зрения Git-репозитория (подробнее про гитерминизм можно прочитать здесь). После завершения converge-процесса, приложение будет соответствовать состоянию, описанному в целевом Git-коммите. Для того, чтобы откатить приложение к предыдущей версии, обычно достаточно выполнить converge на соответствующем более раннем коммите (при этом werf будет использовать образы для этого коммита).

Выполните следующую команду в корневой директории своего проекта, чтобы запустить converge:

werf converge --docker-repo myregistry.domain.org/example-app [--kube-config ~/.kube/config]

Обычно у команды converge имеется только один обязательный аргумент: адрес docker-репозитория. werf будет использовать этот репозиторий для хранения собранных образов и их использования в Kubernetes (то есть репозиторий должен быть доступен из кластера Kubernetes). Kube-config — необязательный аргумент; определяет целевой кластер Kubernetes для подключения. Также имется опциональный параметр --env (и переменная окружения WERF_ENV), позволяющий развертывать приложение в различные окружения.

Примечание: Если ваше приложение не использует кастомные docker-образы (а использует только публичные), параметр --docker-repo можно не указывать.

Дальнейшие шаги

Краткое руководство по началу работы поможет вам развернуть и запустить демо-приложение. Руководства рассказывают о конфигурировании различных приложений, написанных на различных языках программирования и базирующихся на разных фреймворках. Здесь вы можете найти руководство, подходящее для вашего приложения, и воспользоваться приведенными в нем инструкциями.

Желающие получить более глубокое представление о рабочих процессах CI/CD, которые можно реализовать с помощью werf, могут обратиться к этой статье.