Встроенный Helm-клиент и Tiller

Helm 2 использует компонент Tiller для управления релизами: выполняет операции создания, обновления, удаления и вывода списка релизов.

Деплой с помощью werf не требует установленного в кластере Kubernetes Tiller. Helm-клиент и Tiller полностью встроены в werf. Tiller работает в рамках единого процесса werf во время деплоя (без сетевых gRPC запросов). werf полностью совместим с существующими инсталляциями Helm 2.

Такая архитектура дает werf ряд преимуществ, которые рассматриваются далее.

Расширение функционала Helm

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

Безопасность

Обычно Tiller устанавливается в кластере Kubernetes с правами администратора. С помощью werf пользователь может более тонко настраивать доступ к кластеру, например, для каждого namespace проекта.

В отличие от Tiller в werf хранилище данных о релизах не привязано к конфигурации кластера или другим параметрам установки. werf может хранить данные о релизах каждого проекта прямо в namespace проекта. Это приводит к тому, что другие проекты в кластере не смогут получить доступ к данным релиза другого проекта при отсутствии доступа к соответствующему namespace.

Установка

Поскольку Helm-клиент и Tiller встроены в werf нет необходимости ни в установке Helm-клиента на хосте ни в установке Tiller в кластере.

Правильное отслеживание ресурсов

werf отслеживает все ресурсы чарта до тех пор, пока каждый ресурс не перейдет в состояние готовности. В процессе отслеживания werf выводит журналы и информацию о текущем состоянии ресурсов, изменениях состояния ресурсов в процессе деплоя, а также информацию о том, чего ожидает werf (например, готовности каких ресурсов).

В стандартном Helm пользователь имеет возможность только указать флаг --wait для ожидания ресурсов, но при использовании этого флага Helm не дает никакой интерактивной информации о том, что происходит в данный момент.

Сравнение werf и helm

Также werf быстро завершает процесс при возникновении ошибки во время деплоя. При использовании флага --wait в стандартном Helm пользователь должен дождаться истечения таймаута. Поскольку неудачные деплои — не редкость, обратная связь появляется с существенной задержкой, простой сервиса увеличивается.

Кроме того, поведение при отслеживании по умолчанию можно настроить согласно вашим потребностям (читайте подробнее об этом в соответствующей статье).

Отслеживание ресурсов в werf реализовано с помощью библиотеки kubedog.

Использование аннотаций и лейблов ресурсов чарта

Ко всем ресурсам чарта, включая хуки, werf автоматически добавляет аннотации. Например, следующие при использовании в GitLab:

  • "project.werf.io/git": $CI_PROJECT_URL;
  • "ci.werf.io/commit": $CI_COMMIT_SHA;
  • "gitlab.ci.werf.io/pipeline-url": $CI_PROJECT_URL/pipelines/$CI_PIPELINE_ID;
  • "gitlab.ci.werf.io/job-url": $CI_PROJECT_URL/pipelines/$CI_JOB_ID.

Пользователь может передавать любые дополнительные аннотации и лейблы при вызове команды werf deploy. werf установит эти аннотации и метки всем ресурсам чарта.

Эта возможность позволяет группировать ресурсы по имени проекта, URL и т.д. (например, для использования в мониторинге). Читайте подробнее про основы деплоя в соответствующей статье.

У Helm пока нет такого функционала и он не появится в ближайшем будущем.

Безопасный параллельный деплой

werf использует блокировки для предотвращения параллельного деплоя и удаления ресурсов в рамках одного релиза. Блокировка выполняется по имени релиза.

Helm не использует каких-либо блокировок, поэтому параллельный деплой может приводить к неожиданным результатам.

Встроенная поддержка секретов

У werf есть встроенные инструменты работы с файлами секретов и секретными значениями. Эта возможность позволяет хранить конфиденциальные данные прямо в репозитории проекта. Подробнее об этом можно прочитать в статьях по основам деплоя и работе с секретами.

Интеграция с образами

werf расширяет возможности Helm, благодаря специальным функциям шаблонов, таким как werf_container_image и werf_container_env. Для организации корректной работы с образами пользователю достаточно использовать эти функции с именем образа из werf.yaml в качестве параметра. В зависимости от используемой схемы тегирования функции вернут полное имя для образа, значения для imagePullPolicy и другие поля для конфигурации контейнера. Подробнее про функции можно прочитать в соответствующем разделе документации.

Таким образом, werf значительно упрощает использование образов в шаблонах: генерирует «правильные» имена и теги Docker-образа, а также гарантирует, что, когда это необходимо, pod’ы будут перевыкачены с актуальным образом.

В случае стандартного Helm, пользователь сам должен организовывать эти процессы.

Генерация шаблонов чарта

При выполнении команды werf:

  • Прокидывает в Helm дополнительные значения, которые могут быть полезны пользователю.
  • Расшифровывает файлы с секретными значениями (по умолчанию secret-values.yaml) и прокидывает получившиеся значения в Helm. Подробнее про файлы с секретными значениями можно почитать в отдельной статье.
  • Добавляет в стандартный генератор Helm дополнительные функции Go-шаблонов:
    • для интеграции с образами: werf_container_image, werf_container_env (подробнее здесь);
    • для работы с пременными окружения: env, expandenv (sprig OS Functions);
    • для использования расшифрованного контента секретных файлов: werf_secret_file (подробнее здесь).

Chart.yaml не требуется

Helm требует наличия файла Chart.yaml в корне директории чарта. В этом файле обязательно должны быть определены имя и версия чарта.

werf генерирует все метаданные чарта во время исполнения и файл Chart.yaml не требуется. Если файл Chart.yaml существует, то werf проигнорирует описанные в нём значения и выведет соответствующее предупреждение.

Зарезервированная директория для Helm-чарта в проекте

werf требует, чтобы директория чарта с именем .helm хранилась в корне проекта вместе с конфигурацией werf.yaml.

Helm не определяет фиксированного места размещения чарта в проекте.

Проверка ресурсов чарта

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

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

Трехстороннее слияние и применение изменений

В werf реализовано два метода применения изменений — двухсторонний, как в Helm 2, и трехсторонний. Оба способа совместимы с существующими инсталляциями Helm 2. Подробности в соответствующей статье документации, а также в статье на Хабр “3-way merge в werf: деплой в Kubernetes с Helm «на стероидах»”.

Также в werf реализована возможность явным образом перенести в Helm-релиз существующие ресурсы в работающем Kubernetes-кластере. Для этого необходимо вручную явно установить аннотацию у желаемого ресурса и развернуть чарт с помощью werf. Подробная информация об использовании ресурсов доступна в соответствующей статье.