Статья посвящена разработке Helm-чартов для Kubernetes с использованием готовых решений из репозиториев чартов. При таком подходе пользователь применяет рецепты сообщества или свои собственные, обеспечивая своевременное обновление типовых компонентов всех своих проектов и удобство сопровождения решений в целом.
Такая удобная возможность теперь встроена и в нашу GitOps-утилиту werf, что должно упростить весь процесс эксплуатации инфраструктуры для собираемых и выкатываемых в Kubernetes приложений.
Встроенный Helm
Пожалуй, основной успех Helm — «пакетного менеджера для Kubernetes» — связан не столько с его функциональностью, сколько с официальным репозиторием чартов и поддержкой репозиториев в целом. Рецепты и настройки чартов сопровождаются огромным сообществом. Специалисты поддерживают актуальные решения, которые требуются конечным пользователям. Каждый чарт официального репозитория стандартизирован и отлично документирован.
В тривиальных случаях пользователю даже не требуется создавать чарт для выката приложения: он просто находит готовое решение, читает документацию, подготавливает настройки и использует официальный чарт.
Мы уже долгое время активно применяем Helm внутри werf для выкатывания инфраструктуры приложения и теперь пошли дальше. Начиная с версии v1.0.4-alpha.10, в werf добавлены команды для работы с зависимостями и чарт-репозиториями, чтобы полностью отказаться от Helm-клиента.
Основные команды для этого:
-
werf helm repoadd Add a chart repository fetch Download a chart from a repository and (optionally) unpack it in local directory init Init default chart repositories configuration list List chart repositories remove Remove a chart repository search Search for a keyword in charts update Update information of available charts locally from chart repositories -
werf helm dependencybuild Rebuild the charts/ directory based on the requirements.lock file list List the dependencies update Update charts/ based on the contents of requirements.yaml
Плюс, в команде werf helm deploy-chart добавилась поддержка chart reference.
И вот как выглядит в действии вся эта магия — точнее, здесь мы показываем сравнение выката одного и того же чарта в werf (слева) и в Helm (справа):
Больше практики
Возвращаясь к удобству использования готовых решений для выката целых приложений — банальный пример с WordPress. Выкат его Helm-чарта в Kubernetes-кластер с помощью werf может выглядеть буквально так:
$ cat << EOF > values.yaml
wordpressBlogName: flant
wordpressUsername: admin
wordpressPassword: password
mariadb:
mariadbRootPassword: password
EOF
$ werf helm deploy-chart --values values.yaml stable/wordpress my-web-appПоскольку репозитории содержат множество решений, из них можно скомпоновать собственные приложения как из кубиков, где кубиками будут являться различные Helm-чарты, от которых зависит вся система. Вероятнее всего, вам останется только правильно настроить компоненты под ваши нужды.
К примеру, для веб-приложения требуются очередь, кэш и хранилище данных. Как мы развернём эти компоненты через werf?
Для начала — ускорим поиск всего необходимого, воспользовавшись CLI:
$ werf helm repo search queue
NAME CHART VERSION APP VERSION DESCRIPTION
stable/rabbitmq 6.4.1 3.7.17 Open source message broker software that implements the A...
stable/rabbitmq-ha 1.31.0 3.7.15 Highly available RabbitMQ cluster, the open source messag...
По аналогии найдем остальные компоненты по всем зарегистрированным репозиториям чартов (список используемых репозиториев можно увидеть, выполнив команду werf helm repo list).
После того, как всё найдено, остаётся только добавить их к чарту. Это можно сделать несколькими способами: добавить чарты компонентов в директорию charts или создать файл requirements.yaml и описать зависимости, а дальше взаимодействовать с ними с помощью специальных команд werf helm dependency build|list|update.
Иллюстрация второго пути:
$ cat << EOF > .helm/requirements.yaml
dependencies:
- name: mysql
version: 0.3.4
repository: "@stable"
- name: redis
version: 1.1.11
repository: "@stable"
- name: rabbitmq
version: 0.6.16
repository: "@stable"
EOF
$ werf helm dependency build
$ werf deploy --env testВ процессе выката werf создаст все зависимости и будет отслеживать их вместе с остальными ресурсами — никакие дополнительные действия не требуются.
В результате, с учётом экспертизы опытного сообщества, вы значительно экономите время на разработку и сопровождение чартов. Впрочем, никто вас не ограничивает использованием публичных чартов: ведь с равным успехом можно выкатывать и свои чарты, конфигурации которых подготовлены с учетом требуемой специфики.
Документация по командам работы с репозиториями и зависимостями в werf представлена здесь. Также вам может быть интересно прочитать в документации подробнее про выкат в werf и основные отличия от Helm.
Заключение
Отсутствие критичных для нас фич в существующих Open Source-решениях вынуждает нас создавать соответствующие возможности, обвязки, интеграции. Проект werf создавался и поддерживается, в первую очередь, для решения повседневных задач наших DevOps-инженеров.
Как пример, вот уже долгое время (второй год!) мы работаем над тем, чтобы наше предложение по отслеживанию ресурсов в Helm приняли как альтернативный режим в основной кодовой базе проекта (upstream). Сообществом идея была принята и поддерживалась, т.к. многим нужна такая возможность. Однако подвижки в этом направлении начались в Helm 3 и только сейчас…
До сих пор реализация этой идеи в Helm была фактически заблокирована разработчиками. Однако за это время мы развили соответствующие функции по слежению за ресурсами в отдельной Open Source-библиотеке — kubedog — и уже используем её в werf. А судя по активности на GitHub, библиотека нашла интерес и у других пользователей Kubernetes/Helm, что очень радует.
Поддержать нашу идею (и реализацию) можно, поставив звезду проекту kubedog на GitHub и/или thumbs up в оригинальном issue в Helm. Спасибо!
P.S.
Читайте также в нашем блоге:
- Цикл заметок о нововведениях в werf:
- «Трезвый взгляд на Helm 2: „Вот такой, какой есть...“»;
- «Практическое знакомство с пакетным менеджером для Kubernetes — Helm»;
- «Представляем библиотеку kubedog для слежения за ресурсами Kubernetes».
Автор: Алексей Игрычев
