что такое helm в openshift
Практическое знакомство с пакетным менеджером для Kubernetes — Helm
Статья является логическим продолжение нашей недавней публикации об истории пакетного менеджера для Kubernetes — Helm. В этот раз мы снова затронем вопросы устройства и функционирования нынешнего Helm (версия 2.x), а также управляемых им чартов и репозиториев, после чего перейдём к практике: установке Helm в кластер Kubernetes и использованию чартов.
Вступление
Helm — инструмент для управления чартами.
Чарт описывает необходимый набор данных для создания экземпляра приложения в кластере Kubernetes. Он может иметь вложенные чарты и использоваться как для описания полноценных сервисов, состоящих из множества зависимых ресурсов, так и для описания отдельных независимых составляющих. К примеру, чарт stable/gitlab-ce описывает комплексное решение с использованием независимых чартов redis и postgresql.
Чарт может быть установлен неограниченное количество раз в одном и том же кластере. Таким образом, описание логики выката приложения в разные окружения может и должно храниться в одном чарте.
Клиентская часть Helm отвечает за формирование чарта и передачу вместе с пользовательскими параметрами находящемуся в кластере Kubernetes компоненту Tiller. В свою очередь, Tiller отвечает за жизненный цикл экземпляра запущенного чарта, релиза. (На всякий случай напомню, что в следующем крупном обновлении Helm — версии 3 — уже не будет Tiller.)
А теперь — обо всём по порядку.
Установка и обновление
Для работы с Helm требуется Kubernetes. Можно использовать локально установленный Minikube (см. также «Начало работы в Kubernetes с помощью Minikube») или любой другой доступный кластер.
Начнём с установки клиента: выбираем релиз, скачиваем и распаковываем архив для своей системы, переносим исполняемый файл…
Теперь Tiller установлен в кластер и готов к управлению релизами, взаимодействию с Kubernetes API.
Репозитории чартов
По умолчанию Helm использует официальный репозиторий чартов Kubernetes. Он содержит тщательно проработанные актуальные чарты для решения множества прикладных задач. Этот репозиторий именуется stable:
При необходимости создание собственного репозитория не составит никаких проблем. Требования к серверу — минимальные, поэтому, как и большинство публичных репозиториев чартов, его можно разместить на GitHub Pages. Подробнее про инструменты и необходимые для этого шаги можно почитать в документации.
При использовании репозиториев чартов они могут быть добавлены и удалены. Для того, чтобы версии чартов были актуальными, необходимо периодически обновлять индекс. Приведу пример для публичного репозитория bitnami, большая часть чартов которого используется в официальном репозитории Helm:
Далее — поиск по репозиториям. Вызов helm search без аргументов показывает все доступные чарты:
В необязательном поле keywords в Chart.yaml разработчики указывают теги, которые используются для упрощения поиска в репозиториях чартов:
Примечание: При использовании команды helm search можно столкнуться с нестабильной работой нескольких фильтров: наличие результата зависит от порядка указания и количества фильтров.
В официальном репозитории чарты прекрасно документированы и содержат примеры использования, а некоторые чарты — даже готовые конфигурации для production. К примеру, хороший readme представлен у stable/wordpress (для его вывода в консоли см. helm inspect readme stable/wordpress ).
Поиск — это хороший способ найти доступные пакеты. После того, как пакет найден, можно использовать его для установки приложения в кластер.
Первое приложение
Для примера выбран уже упомянутый чарт stable/wordpress.
Установим чарт с конфигурацией для production, поменяем название блога, отключим сохранение данных WordPress в PersistentVolumeClaim (подробнее про постоянные хранилища см. в документации Kubernetes):
В случае работы с полноценным кластером далее можно следовать рекомендациям из блока NOTES выше. Если же у вас Minikube — откройте сайт в браузере следующим образом:
Поздравляю, приложение в кластере!
Развёрнутый чарт с WordPress появился в списке всех релизов Helm:
Следующим шагом обновим наш релиз и изменим образ с блогом. Для примера будет использован другой тег из того же Docker-репозитория ( 4.9.8-ol-7 ):
Обратите внимание, что при обновлении Tiller сравнивает полученный чарт с параметрами с последним сохранённым и выполняет соответствующие запросы в Kubernetes API, а актуальное состояние ресурсов релиза не берётся в расчёт. Важно понимать эту особенность и не совершать ошибок:
Состояние компонентов релиза приложения в кластере всегда можно проверить следующим образом:
Helm позволяет откатываться до определённой ревизии релиза. На текущий момент ревизий две:
Откатим приложения к первоначальному состоянию:
Теперь история ревизий пополнилась на одну запись:
Статья подходит к концу и релиз больше не требуется?
А удалён ли он в действительности.
Команда удаляет Kubernetes-ресурсы, связанные с релизом, но не сам релиз. Вся информация о релизе остаётся доступной, в том числе и его история:
Примечание: По задумке, удалённый релиз можно откатывать к предыдущим версиям, но в последних версиях эта возможность не работает — подробности см. в issue #3722.
Резюмируя
В этой статье рассказано про базовую архитектуру Helm 2, его компоненты и их функций, а также об основных примитивах, чартах, релизах и репозиториях чартов. Мы установили Helm в кластер Kubernetes и получили понимание жизненного цикла релиза и основных команд для работы с ним.
Следующий материал из этого цикла будет посвящён теме создания собственного чарта — в нём я расскажу про структуру чарта, шаблонизацию и инструменты отладки. ОБНОВЛЕНО: Новая статья доступна по этой ссылке.
Основы работы с Helm чартами и темплейтами — Часть 1
В этом руководстве мы кратко обсудим, как Helm может помочь упростить управление приложениями Kubernetes, и узнаем, как использовать Helm для создания базового чарта.
Управление приложениями — сложный аспект Kubernetes. Helm значительно упрощает его, предоставляя единый метод упаковки программного обеспечения, поддерживающий контроль версий. Helm устанавливает пакеты (называются Чартами в Helm) для Kubernetes и управляет ими, как это делают yum и apt.
В этом руководстве мы позволим Helm создать для нас базовый чарт. В этом руководстве предполагается, что у вас есть хотя бы базовое понимание того, что такое Helm. Если вы не знакомы с ним, я предлагаю вам ознакомиться с этим руководством, прежде чем приступить к статье: https://www.alibabacloud.com/help/doc-detail/86511.htm
Затем мы будем постепенно вносить изменения, чтобы узнать, как файл значений и части шаблона работают вместе.
С таким базовым рабочим чартом легче работать, чем начинать с нуля.
Чарт — это пакет Helm. Он содержит все определения ресурсов, необходимые для запуска приложения, инструмента или службы внутри кластера Kubernetes.
Думайте об этом как о Kubernetes-эквиваленте формулы Homebrew, Apt dpkg или Yum RPM-файле.
Создание полной структуры каталогов рабочего чарта
Это создает полный рабочий чарт со всеми необходимыми файлами в каталоге myhelm.
Вам будут представлены некоторые из этих файлов на протяжении всего этого руководства — только тогда, когда нам нужно узнать об этих конкретных файлах.
Цель — как можно скорее использовать чарт для создания работающего экземпляра. Затем мы исследуем, что создал чарт и как он это сделал.
Измените values.yaml вверху, чтобы использовать busybox, как показано ниже. Обратите внимание на изменения тегов.
Это развертывание (deployment), как и любое другое, которое вы используете в Kubernetes. Основное отличие состоит в том, что большинство значений полей он получает из только что отредактированного файла значений.
Отредактируйте файл deployment.yaml около строки 27 — добавьте команду. Мы используем образ busybox. Если мы создадим наши поды, они сразу же выйдут, так как ни одна команда или программа не запущены. Команда позволила нашему поду busybox спать 60 секунд.
Теперь мы готовы позволить Helm установить наш отредактированный чарт.
Helm автоматически генерирует название выпуска для вашего: NAME: loopy-otter
Ваш будет другим. Ненавижу эти глупые имена. Позже мы будем использовать наши собственные имена.
Мы видим сервис, развертывание и создание пода.
Эти примечания взяты из NOTES.txt, другого файла шаблона.
Через несколько секунд мы увидим, что наш Pod работает.
Релиз — это экземпляр чарта, работающей в кластере Kubernetes.
helmignore NOTES.txt
.helmignore содержит список имен файлов и шаблонов имен файлов, которые Helm должен игнорировать.
Если вы снова запустите установку, вы увидите, что эти примечания больше не отображаются.
(Позже мы будем использовать такие заметки, но здесь и сейчас этот файл нам не нужен.)
Удалите наш тестовый релиз test1.
Таким образом мы не засоряем наш узел Kubernetes несколькими ненужными объектами.
Как видите, релиз может существовать только один раз.
Проверим статус release
Мы просто удалили его.
Для тестирования отладки ( debug ) нам понадобится другое название релиза: мы используем test2:
Очень полезно, но слишком много информации, если мы хотим постоянно редактировать и устанавливать наш чарт.
Прямо сейчас я не буду пытаться все это разобрать, давайте сначала уменьшим вывод.
Под Хуками есть тестовое соединение. Это было полезно для тестирования исходного nginx. Нам это не нужно.
Нашему поду busybox не нужны порты или livenessProbes.
Удалите строки с 29 по 42 из deployment.yaml
Давайте запустим снова нашу установку.
Давайте разберемся данных командах:
Мы довольны результатами отладки, давайте запустим установку.
Как и ожидалось — происходит развертывание и его Pod. Через несколько секунд Pod запускается.
imagePullPolicy = Never
Значения в values.yaml заменяют свои заполнители (placeholders) в файлах шаблонов.
В этой части руководства демонстрируется передача imagePullPolicy в командной строке.
Редактирование не требуется, просто обратите внимание на последнюю строку извлечения файла значений ниже.
Файл значений по умолчанию должен называться values.yaml.
Теперь посмотрите, где он используется в шаблоне. (в диапазоне 22-25)
.Values.image.pullPolicy получает значение из
Предположим, что для этого тестового прогона мы НЕ хотим, чтобы образ было извлечен из репозитория. ( imagePullPolicy: Never )
Из документации Kubernetes:
imagePullPolicy: Never: предполагается, что образ существует локально. Попытки вытащить образ не предпринимаются.
USER-SUPPLIED VALUES кажутся правильными: imagePullPolicy: Never
COMPUTED VALUES: указывают на наличие проблемы:
Они имеют разные имена и находятся на разных уровнях yaml.
В развертывании мы видим: imagePullPolicy: IfNotPresent : переопределение не выполнено.
Давайте исправим это: смотрите на вторую попытку:
Почти готово, но все равно неверно. Теперь у нас есть две политики, написанные по-разному. (Первая буква в нижнем регистре — это правильная буква, которая появляется в файле значений).
Соглашение гласит, что мы должны называть наши значения, начиная со строчной буквы. Наши values.yaml верны. Наше переопределение командной строки неверно.
Третья попытка, смотрите команду ниже.
В приведенном выше развертывании показано, как imagePullPolicy: Never … прошло успешно.
COMPUTED VALUES показывают, что переопределение выполнено правильно.
Вывод отладки выглядит хорошо. Мы готовы установить этот выпуск вживую.
Я хочу скрыть все остальные значения, которые нам не нужны. Отредактируйте файл значений так, чтобы только первые 5 значений не закомментировались.
Установим наш чарт
Values.ingress.enabled используется в myhelm1/templates/ingress.yaml
Нам не нужен ingress — это часть чарта nginx, с которого мы начали.
Добавьте ingress.yaml в конец нашего файла игнорирования.
—set replicaCount правильно переопределяет значение в deployment.yaml
Сделаем живую установку.
Успешно. ЖЕЛАТЕЛЬНОЕ развертывание — 3, и мы видим, что создаются 3 модуля.
Демо завершено. Удалите наш релиз test3.
Определение нового value
Мы также передали значения переопределения в командной строке.
Теперь мы создаем собственное новое значение: terminationGracePeriodSeconds
terminationGracePeriodSeconds — Необязательная продолжительность в секундах, необходимая для корректного завершения работы модуля. grace period — это продолжительность в секундах после того, как процессы, запущенные в модуле, отправляют сигнал завершения, и время, когда процессы принудительно останавливаются с сигналом уничтожения. Установите это значение больше, чем ожидаемое время очистки для вашего процесса. По умолчанию 30 секунд.
Отредактируйте файл развертывания, чтобы он использовал это новое значение (строки с 22 по 29 должны быть такими, как показано ниже)
Сделайте пробный запуск.
Успешно. COMPUTED VALUES: показывает их правильно и развертывание внизу использует их правильно.
Еще один тест: давайте отладим тест, переопределив значение terminationGracePeriodSeconds на 10.
Успешно. COMPUTED VALUES: правильно показывает 10 и при развертывании внизу правильно используется 10.
Мы даже не посмотрели на _helpers.tpl или каталог чартов. (Это касается зависимостей. Это тема для другого руководства из этого набора.)
Мы внесли несколько изменений в наш файл значений, а также в файл развертывания и увидели его результаты с помощью отладки и команд живой установки.
На работе вы создадите свои собственные скелетные базовые чарты, из которых будете копировать.
Погружение в Helm Package Manager. Часть первая
Helm — один из самых популярных пакетных менеджеров для Kubernetes. Познакомиться с ним полезно любому DevOps-инженеру и всем, кто сталкивается с задачами деплоя приложений. Эту мини-серию из двух статей можно рассматривать как краткое, но достаточно полное введение в Helm. В первой части поговорим об архитектуре Helm и некоторых типичных задачах, которые он позволяет решать. В частности, кастомизации приложения и переиспользвании кода.
Фрагменты кода в статье специально даны в виде картинок — это позволило выделить важные для нас строки. Но для вашего удобства я на всякий случай собрал все примеры в этом репозитории.
Назначение Helm
Современное приложение — сложный продукт с множеством внутренних компонентов и внешних связей.
При этом чаще всего у нас есть несколько рабочих окружений, которые могут достаточно сильно отличаться друг от друга и по количеству компонентов и связей, и по их качеству.
Кроме того, в современном мире микросервисов и распиленных монолитов у нас может быть гораздо больше одного проекта.
Управлять этим сложным хозяйством хочется максимально простым, универсальным и наименее затратным способом. Поэтому отношение к выбору подходящего инструмента для деплоя и построение технической дисциплины на его основе варируется от хорошей практики до необходимого условия выживания.
Таким тулингом для многих стал Helm Package Manager.
Возможности Helm
Список основных возможностей включают в себя:
Простую текстовую шаблонизацию (Go templates + Sprig framework).
Управление релизами (установка, апгрейд, откат, удаление).
Tracking выката релиза с возможностью отката в случае неудачи.
Для публикации последних создатели Helm даже запустили специальный сайт artifacthub.io. Там уже собрана и постоянно пополняется сообществом огромная коллекция чартов (в апреле 2021-го их было 3402, в сентябре — уже 5568).
Правда, как это бывает с опенсорс-наработками, их качество совершенно разное (я бы не рекомендовал использовать чарты с artifactshub без изменений). Более или менее сориентироваться в содержимом позволяют звезды, которые присваивают наработкам пользователи. Разумеется, вы также можете внести вклад в оценку.
В любом случае, даже если не найдете ничего подходящего, всегда можно взять готовый вариант за основу собственного проекта. Просто чтобы не начинать с нуля.
Альтернативы Helm
Конечно же, Helm — не единственное решение для деплоя в Kubernetes. У нас есть и другие:
Kustomize от авторов Kubernetes. Этакий «kubectl на стероидах», который, однако, слабо подходит для больших и сложных проектов.
Паттерн Kubernetes Operators, который в последнее время активно продвигает компания Red Hat. Она спонсируют опенсорсный Operators Framework и сайт operatorshub.io для публикации наработок. Более того, даже встроила в свою платформу OpenShift возможность установки операторов с этого сайта по клику. Но нужно понимать, что Kubernetes Operator — вещь в себе. Порой очень трудно разобраться, как он все-таки работает, а уж тем более внести в него изменения.
Ansible. Его используют многие, хотя, на мой взгляд, когда дело касается деплоя в Kubernetes, Ansible в сочетании с Jinja — прекрасный способ все запутать.
Terraform. С его помощью также можно строить деплой, используя какие-нибудь специализированные провайдеры, только вот красивых решений на его основе лично я до сих пор не видел.
Jsonnet — язык шаблонизации от Google, на котором построены некоторые инструменты. Например:
При выборе инструмента, безусловно, стоит учесть и его слабые стороны. Например, именно недостатки Helm и попытались преодолеть ребята из Grafana, создавая собственный продукт Tanka с использованием jsonnet.
Итак, основные недостатки Helm:
Только строковая шаблонизация. Мы строим деплой, ничего не зная о конечных примитивах, основываясь на хрупком YAML-синтаксисе.
Сложное расширение. Если вам чего-то не хватает в готовом чарте, скорее всего, придется его форкнуть и доработать самостоятельно.
Низкий уровень абстракции. Мы не можем описать объект, порождающий deployment, service и ingress, унаследоваться от него и переопределить deployment в StatefulSet.
Потенциальная запутанность. Конечные результаты генерации релиза могут очень сильно различаться в зависимости от значений, которые мы подали на вход.
Но несмотря на все недостатки Helm, я не знаю людей, сменивших его на что-то другое. А вот с обратными примерами сталкивался неоднократно. Например, мои знакомые сперва деплоили при помощи Terraform и Jsonnet provider, потом перешли на Ansible, но в итоге и его переписывают на Helm. Они объяснили это тем, что начали привлекать для описания деплоя в Kubernetes разработчиков, а Helm, покрывая большинство их потребностей, обеспечивает еще и низкий уровень входа.
Кстати, та же Tanka не так давно официально и с гордостью объявила о поддержке Helm charts.
Архитектура и основные понятия Helm
Сейчас актуальны версии Helm 2 и Helm 3, причем последняя, в отличии от предыдущей, не имеет серверного компонента (Tiller). Фактически это просто Go-бинарник, причем Helm 3 гораздо более легковесный и дружественный к разделению прав.
Архитектура Helm 3 представлена на схеме:
Работает же Helm 3 следующим образом:
Получает на вход Chart (локально или из репозитория, при этом чарты могут использовать друг друга) и генерирует манифест релиза.
Получает текст предыдущего релиза.
Получает текущее стостояние примитивов из namespace-релиза.
Сравнивает эти три вещи, делает patch и передает его в KubeAPI.
Дожидается выката релиза (опциональный шаг).
Эта схема называется 3-way merge. Таким образом Helm приведет конфигурацию приложения к состоянию, которое описано в git, но не тронет другие изменения. Т. е., если у вас в кластере есть какая-то сущность, которая трансформирует ваши примитивы (например, Service Mesh), то Helm отнесется к ним бережно.
Теперь пройдемся по основным понятиям Helm.
1. Helm chart
Фактически, папка определенной структуры с текстовыми файлами внутри. По команде helm create [chartname] будет создана заготовка, которую вы сможете развить нужным вам образом.
Файлы имеют разную структуру и назначение. Например, в Chart.yaml описаны основные параметры чарта. Перед вами официальный Chart.yaml minio:
В нем много произвольных описательных полей, однако необходимое и достаточное условие — указать только name и version. Если хотите копнуть глубже, вам сюда.
2. Репозиторий чартов
В принципе, управлять репозиторием можно вручную, используя команды Helm. Хотя существует и ПО, обеспечиващее быстрый старт и визуальные интерфейсы для облегчения работы. Например:
Копнуть глубже можно здесь.
3. Helm Release, Helm Values
Helm Release генерируется из чарта (Chart) с использованием входных значений (Values):
Chart + Values = Release
При помощи команды helm list мы можем просмотреть релизы, установленные в конкретном Kubernetes Namespace.
С релизами связано понятие Release backend — места, в котором Helm хранит и версионирует переданные на деплой релизы.
Это может быть configmap/secret/SQL. По умолчанию это secret — Helm создает объект этого типа (в котором хранится JSON, завернутый в gzip + Base64) на каждый релиз в Namespace, куда его и устанавливает. Хотя он может сделать это и, например, в SQL-базе.
Типовые задачи «YAML-девелопера»
Перейдем к задачам, которые наиболее часто возникают в процессе деплоя приложений в Kubernetes, и их реализции с помощью Helm. У меня получился вот такой короткий список:
Кастомизация приложения в разрезе окружений.
Управление блоками кода по условию.
Установка очередности запуска подов.
Расширение функциональности Helm.
Как видите, в список вошли и базовые, я бы даже сказал, экзистенциальные, задачи вроде переиспользования кода, и вполне практические, вроде отладки
1. Кастомизация приложения в разрезе окружений
У нас может быть достаточно много окружений, похожих в целом, но, в то же время, имеющих несколько важных отличий.
Среди последних можно выделить два типа:
Отличия, связанные с параметрами работы приложений (например, данные внешних систем, имена баз, очередей и т. п.).
Отличия в инфраструктуре (адреса ингрессов, количество реплик, включение или отключение инфраструктурных компонентов).
Согласно лучшим практикам, мы должны уметь передавать рабочие параметры в приложение как можно ближе к деплою. Если вы до сих пор устанавливаете их при сборке имиджа или запекаете в образ, не делайте так — этот подход чреват многими проблемами. Хороший способ управления рабочими параметрами — передавать их через переменные окружения или configmap, которые монтируются в под.
Управление инфраструктурными изменениями концептуально сходно с управлением рабочими параметрами приложения: в рамках Helm это изменение текстовых файлов в зависимости от набора входных значений.
Чтобы управлять входными значениями, в Helm есть механизм Values, расположенный в файле values.yaml:
Мы можем использовать values в templates.
Values.yaml представляет собой иерархическую древовидную структуру «ключ — значение».
С ее помощью мы можем создавать нужную группировку и мнемонику для наших входных величин.
Использовать values мы можем в файлах templates при помощи конструкций вида:
Здесь “.” означает текущую область значений (current scope), далее идет зарезервированное слово Values и путь до ключа. При рендере релиза сюда подставится значение, которое было определено по этому пути.
Но values.yaml — статический способ задания величин. Очевидно, что нам нужно менять некоторые values при деплое в конкретное окружение. В Helm для этого предусмотрено несколько способов:
или несколько директив set:
Передавать несколько значений через запятую в одной директиве set:
Передавать значения в списки:
1.1. Работа со списками
В примере values.yaml выше были описаны списки storageClass и persistentVolumeSize в секции app.storage. Они описывают параметры persistentVolume в зависимости от облака, куда мы производим деплой (aws или gcp). Такие списки очень удобны и встречаются достаточно часто. Есть несколько вариантов использования таких списков. При деплое нам прежде всего нужно определить value, характеризующее конкретный вариант. В примере выше это
Плохой способ использования списка — описать при помощи конструкции if все имеющиеся варианты:
Более правильный способ — использовать функции Go templates:
Функции Go templates, расширенные Sprig framework, позволяют делать код гораздо более красивым, функциональным и компактным. Если вы что-то делаете и чувствуете, что получается не очень-то хорошо, подумайте насчет использования Go templates.
Вот пара полезных ссылок на этот случай:
Говоря о values, нужно упомянуть стандартные значения Helm, которые формируются автоматически при каждом рендере релиза.
Они подробно описаны в документации по этой ссылке.
Если вы используете эти значения в своем коде
то при переносе его между чартами, код подхватит нужные значения и бесшовно, без изменений встроится в новый чарт.
2. Переиспользование кода
Допустим, у нас есть некоторое количество значений:
И эти значения нужны нескольким приложениям в нашем чарте:
Вполне очевидно, что дублировать секцию env: в описании каждого приложения совершенно некрасиво.
Для решения этой проблемы в Helm есть механизм “Named templates”.
Там мы можем определить секцию “define”…
…которую потом сможем подключить к нашим yaml при помощи директивы include:
Здесь мы видим, что в функцию include передается имя define и текущий контекст, потом текст, описанный в define, при помощи pipe передается в функцию indent, которая сдвигает его на 12 пробелов.
Для чего это может быть использовано? Для любых повторяющихся участков кода.
Определение общих labels:
Используйте templates и следуйте базовому правилу программирования “DRY”: DON’T REPEAT YOURSELF!
2.1. Использование циклов (range)
Примеры values.yaml и define, который был сделан для подключения его в yaml приложения, выглядят совсем некрасиво. Приходится описывать значение в values, потом описывать его же в define. Это явное дублирование.
Избавиться от него в Helm можно при помощи range.
Пример 1: range по заданному списку.
Пример 2: range по values.yaml
Допустим, у нас есть некоторое количество cronJob, которые различаются фактически только расписанием и командой запуска. Описываем их как список в values.yaml:
При этом мы делаем include переменных окружения из верхней области значений по аналогии с предыдущим примером (Строка 19).
Range — очень мощное средство шаблонизации, но оно требует повышенного внимания, не проявив его, можно запросто выстрелить себе в ногу.
Скажем, в Примере 2 допущена ошибка, которая приведет к тому, что из всего списка будет создан только последний cronJob. Дело в отсутствии yaml разделителя. Правильный вариант выглядит так (обратите внимание на Строку 2):
Каким же образом при помощи range мы можем улучшить эту конструкцию?
Итоговая конструкция получается гораздо проще и лаконичнее:
2.3. Хорошие практики values.yaml
Гораздо лучше описывать переменные списком в разрезе окружений. Т. о., базовое описание values…
Однако от окружения к окружению менять нужно не все величины, часть из них изначально описана как _default.
Код для разбора таких конструкций будет выглядеть так:
Если значения, соответствующего окружению, не найдено, то при помощи функции default подставляется значение из ключа _default.
Этот способ описания очень любят разработчики, поскольку оно достаточно простое и наглядное.
2.4. Лучшие практики
Если говорить о лучших практиках, в документации Helm есть набор рекомендаций и хаков, которые могут пригодиться при его использовании: Chart best practices, Chart tips and tricks.
Например, из подборки лучших практик вы можете узнать, что создатели Helm топят за использование camelCase. А в tips and tricks я недавно нашел такую штуку:
Здесь же мы делаем аннотацию подов в template, которая рассчитывается на основании хеш-функции от содержимого configmap. Configmap изменился, хеш пересчитался, анотация поменялась, поды перекатились, конфигурация применилась. На мой взгляд, решение очень остроумное.
На этом пункте я решил сделать перерыв, поскольку материал получается очень большим. Впрочем, обещаю не затягивать с выкатом продолжения, в котором речь пойдет о прочих типичных задачах, возникающих в ходе деплоя в Kubernetes: трекинге выката, отладке, управлении релизным циклом и т. д.