Использование диаграмм Хелма для упрощения развертывания Kubernetes в трубопроводах Ci/cd

Что такое карты шлема и почему они используются в развертываниях Kubernetes

Kubernetes появился как стандартная платформа для оркестровки контейнеров, но управление приложениями на Kubernetes - особенно в непрерывной интеграции и непрерывной доставке (CI / CD) трубопроводы - может быть сложным. Helm, часто называемый "менеджер пакетов для Kubernetes", обращается к этой сложности, предоставляя способ определения, установки и обновления даже самых сложных приложений Kubernetes как один, версия единицы. A Helm Chart - это коллекция файлов, которые описывают связанный набор ресурсов Kubernetes: Развертывания, Услуги, ConfigMaps, Ingresses, PersistentVolumeClaims и многое другое. Графики могут быть разделены через репозитории, в версии с семантической версией и параметризированы с значениями файлов, которые позволяют адаптировать одну и ту же диаграмму к различным средам (разработка, постановка, производство) без копирования или изменения шаблонов непосредственно. Эта абстракция делает Helm незаменимым инструментом для команд, которые должны развертываться последовательно, быстро откатывать и поддерживать четкий аудит маршрут того, что было развернуто и когда.

Для команд, работающих с конвейерами CI/CD, Helm предлагает мощный механизм для автоматизации развертываний Kubernetes. Вместо написания сложных сценариев оболочки или жонглирования сырыми манифестами YAML вы можете определить логику развертывания внутри одной диаграммы, а затем вызвать , или в качестве шагов в вашем конвейере. Результатом является оптимизированный, повторяемый процесс, который уменьшает человеческие ошибки, обеспечивает соблюдение стандартов и ускоряет цикл обратной связи от кода, обязывающего к развертыванию производства. В этой статье мы исследуем, как диаграммы Helm упрощают развертывание Kubernetes в трубопроводах CI/CD, погружаются в стратегии реализации и делятся передовыми практиками, на которые производственные команды полагаются каждый день.

Преимущества использования диаграмм Хелма в трубопроводах CI / CD

Последовательность во всех средах

Одной из наиболее значительных проблем в CI/CD является обеспечение того, чтобы тот же манифест, развернутый в кластере разработки, также работал в постановке и производстве. Без менеджера пакетов команды часто копируют сырые файлы YAML и настраивают параметры вручную, что приводит к проблемам дрейфа и «работы на моем ноутбуке». Helm Charts обеспечивает согласованность путем упаковки всех требуемых Kubernetes манифестов в единую диаграмму, которая может быть установлена одинаково в любом кластере с соответствующими значениями. Шаблон диаграммы использует шаблоны Go, позволяя вам вводить параметры, специфичные для среды (например, теги изображений, подсчет реплик или доменные имена) во время развертывания. Это означает, что ваш конвейер CI/CD может развертывать одну и ту же диаграмму в несколько кластеров, полагаясь только на файл значений для среды, который вы также храните в управлении версиями.

Автоматизация и интеграция с инструментами CI/CD

Helm интегрируется с практически каждым инструментом CI/CD на рынке, включая Jenkins, GitLab CI/CD, GitHub Actions, CircleCI, ArgoCD и Flux. Поскольку команды Helm являются простыми вызовами CLI, вы можете добавить их непосредственно в свои скрипты конвейера. Например, типичная работа GitLab CI/CD может включать:

deploy:
 stage: deploy
 script:
 - helm upgrade --install my-release ./chart --values prod-values.yaml --namespace production
 only:
 - main

Эта команда заменяет десятки вызовов и гарантирует, что развертывание является атомным: если обновление не удается (по любой причине - ошибка синтаксиса, отсутствие ресурса или несоответствие версии API), Helm автоматически откатится к предыдущей редакции.

Контроль версий и возможности Rollback

Каждый раз, когда вы запускаете или , Helm записывает ревизию. Вы можете просмотреть историю пересмотра с и вернуться к любой предыдущей редакции с . Это бесценно в трубопроводах CI/CD, где плохое развертывание может быть обнаружено быстро и автоматически возвращено. Кроме того, поскольку сами диаграммы Helm являются версиями (через поле ] в ), вы можете соотнести версию диаграммы с конкретным набором манифестов. В сочетании с семантической версией это дает вам четкий аудиторский след: «Версия 1.2.3 диаграммы X была развернута в постановке на эту дату, и она использует определения ресурсов Kubernetes из этого тега в хранилище».

Параметризация и повторное использование

Одна диаграмма Хелма может использоваться для нескольких приложений или микросервисов, переопределяя значения. Например, общая диаграмма веб-приложений может содержать шаблоны для развертывания, обслуживания и входа. Передавая разные , и , вы можете развернуть как «пользовательскую службу», так и «службу заказа» из одной и той же диаграммы. Эта многоразовая возможность означает, что вашей команде нужно поддерживать только несколько диаграмм вместо сотен отдельных файлов YAML. В конвейере CI/CD вы можете повторно использовать одну и ту же диаграмму для предварительного просмотра запросов тяги, ветвей функций и производства, просто изменяя файлы значений.

Внедрение шлема в трубопроводах CI / CD

Шаг 1: Подготовьте диаграммы шлема для ваших приложений

Прежде чем вы сможете автоматизировать развертывание с Helm, вам нужна диаграмма. Вы можете создать ее с нуля, используя или использовать существующую диаграмму из публичного хранилища (например, Bitnami или стабильный архив Helm). Для внутренних приложений рекомендуется поддерживать свою собственную папку в репозитории Git или выделенный репозиторий диаграмм, размещенный на страницах GitHub или хранилище объектов. Каждая диаграмма должна определять ресурсы Kubernetes, которые требуются вашему приложению. Как минимум, включите манифест развертывания, который ссылается на изображение контейнера, плюс Службу для его раскрытия. Если вы следуете архитектуре микросервисов, рассмотрите возможность создания одной диаграммы на услугу, но также исследуйте библиотечные диаграммы (общие подсхемы) для общих компонентов, таких как метрики Prometheus или сетевые политики.

Шаг 2: Настройте свой инструмент CI / CD для управления командами рулевого управления

Большинство платформ CI/CD поддерживают запуск команд Helm изначально, если вы включаете двоичную строку в среду конвейера. Для контейнерных бегунов вы можете использовать изображения, которые включают Helm (например, . Убедитесь, что бегун также имеет сконфигурированный для аутентификации с вашим целевым кластером Kubernetes. Как правило, вы храните токен kubeconfig или учетной записи службы в качестве секрета CI/CD. Для действий GitHub вы можете использовать действие , за которым следует пользовательский шаг, который запускает . Для GitLab CI/CD вы можете использовать команду внутри работы с соответствующими переменными, определенными. Ниже приведен пример для действий GitHub:

deploy:
 runs-on: ubuntu-latest
 steps:
 - uses: actions/checkout@v3
 - uses: azure/setup-helm@v3
 with:
 version: 'latest'
 - name: Deploy to Kubernetes
 run: |
 helm upgrade --install my-release ./chart --values values-prod.yaml --namespace production
 env:
 KUBECONFIG: ${{ secrets.KUBECONFIG }}

Шаг 3: Автоматизация развертывания с установкой / обновлением рулевого управления в трубопроводных сценариях

Ядром этапа развертывания вашего трубопровода будет одна (или несколько) команд . Эта команда проверяет, существует ли релиз; если он существует, она выполняет обновление; если нет, она устанавливает его. Флаг гарантирует, что ресурсы создаются в правильном пространстве имен. Вы также можете добавить , чтобы заблокировать, пока не будут запущены все Pods, или , чтобы не выполнить работу, если развертывание висит. Для канарейки или сине-зеленых развертываний вы можете использовать с другим именем выпуска, а затем переключать трафик через Ingress или служебную сетку. Трубопровод также может запускать дымовые испытания после развертывания с использованием встроенных тестовых крючков Helm или выполняя отдельную тестовую диаграмму.

Шаг 4: Тестирование и откат в трубопроводе

Helm предоставляет команду , которая запускает любые тестовые модули, определенные в каталоге диаграммы. Вы можете вызвать эту команду на отдельном этапе конвейера — если она не срабатывает, трубопровод должен остановиться и необязательно вызвать откат. Для автоматизации отката вы можете запускать команды цепи: . Если тест не срабатывает, запустите . Некоторые команды предпочитают использовать более сложный подход: они хранят предыдущий номер пересмотра до обновления и откат к этому пересмотру при отказе. В CI/CD откат может выполняться автоматически в той же работе или в отдельной работе отката, которая зависит от статуса отказа развертывания.

Лучшие практики использования диаграмм Хелма в CI/CD

Поддерживайте четкую версию диаграмм Helm

Используйте семантическую версию для своей версии диаграммы. Каждый раз, когда вы изменяете шаблоны диаграммы или значения по умолчанию, увеличивайте версию в . Это позволяет вам отмечать релизы в вашем репозитории и ссылаться на них в своем конвейере. Например, вы можете прикрепить команду развертывания к конкретной версии диаграммы: . Избегайте использования метки для диаграммы; всегда укажите версию явно в конвейере для обеспечения воспроизводимости.

Используйте файлы значений для конфигураций, ориентированных на окружающую среду

Создавайте отдельные файлы значений для каждой среды (например, , , ). Храните их внутри хранилища диаграмм или рядом с диаграммой в хранилище приложений. В вашем конвейере CI/CD выберите соответствующий файл значений на основе ветви или переменной среды. Этот подход удерживает чувствительные значения (например, пароли базы данных) из шаблонов диаграмм. Для еще большей безопасности используйте инструмент управления секретами, такой как хранилище HashiCorp или Sealed Secrets, для впрыскивания чувствительных данных во время выполнения, а не для хранения его в файлах значений.

Автоматическое тестирование диаграмм рулевого управления перед развертыванием

Перед развертыванием диаграммы в производство запустите серию автоматизированных тестов: lint с использованием , рендеринг шаблонов с , чтобы поймать синтаксические ошибки YAML и недостающие значения, и модульные тесты с использованием инструмента, такого как . Вы можете интегрировать эти шаги в свой конвейер CI/CD в качестве предварительной проверки развертывания. Многие команды также устанавливают «стадийную» среду, где диаграмма развертывается и выполняется через интеграционные тесты (например, с использованием ) перед продвижением на производство.

Храните диаграммы руля модульные и многоразовые

Разбейте большие монолитные диаграммы на более мелкие, композитные подсхемы или используйте библиотечный шаблон диаграмм для общих шаблонов помощников. Это позволяет избежать дублирования и упрощает обновления. Например, создайте «общую» библиотечную диаграмму, которая определяет помощников шаблонов для ярлыков, правил входа и проверок здоровья, а затем импортируйте ее в качестве зависимости в ваших служебных диаграммах. В вашем конвейере CI/CD вы можете перестраивать и публиковать библиотечные диаграммы отдельно, и каждая служебная диаграмма может прикрепляться к конкретной библиотечной версии.

Ограничьте количество версий

Хотя Helm по своей сути не ограничивает количество версий диаграмм, которые вы можете опубликовать, хорошей практикой является удаление старых версий диаграмм из вашего хранилища, чтобы избежать загромождения индекса. Некоторые команды сохраняют только последние версии N (например, последние 10) и архивируют более старые. В CI / CD всегда ссылаются на конкретную версию диаграммы, а не только на последнюю, чтобы обеспечить детерминированные сборки.

Общие проблемы и решения при использовании Helm в CI / CD

Управление большим количеством выпусков

По мере роста архитектуры микросервисов вы можете получить десятки или сотни выпусков Helm. Это может сделать медленными и усложнять отслеживаемость. Решение: использовать пространства имен для логически разделяемых сервисов и рассмотреть возможность использования таких инструментов, как Helmfile или GitOps framework (ArgoCD, Flux), которые декларативно согласовывают желаемые состояния. В CI/CD вы также можете группировать службы в единую зонтичную диаграмму, которая развертывает несколько подсхем одновременно, уменьшая количество отдельных команд.

Безопасное управление секретами

Хранение секретов в простом тексте в файлах значений или Git представляет собой риск безопасности. Сам Хелм не шифрует файлы значений — является простым текстом. Используйте инструмент управления внешними секретами и передайте секреты в качестве переменных среды в конвейер, а затем введите их в Хелм с помощью или через шаблон секретов, который ссылается на Kubernetes Secret, зашифрованный с помощью Sealed Secrets или Mozilla SOPS. Избегайте передачи любых чувствительных значений в хранилище.

Работа с зависимостями от графика

Если ваша диаграмма использует подсхемы из публичного хранилища, ваш конвейер CI/CD должен получить эти зависимости перед упаковкой или развертыванием. Запустите в конвейере, чтобы загрузить последние совместимые версии. Для воспроизводимости рассмотрите возможность вендинга ваших зависимостей диаграмм в хранилище (например, с использованием ) и их связывания. Тогда трубопровод может использовать продаваемые диаграммы без необходимости доступа к внешним репозиториям во время развертывания.

Вернуться назад на Неудача

Автоматический откат в CI/CD требует тщательной разработки. Если трубопровод автоматически откатывает на отказ, вы можете создать «петлю отката», если основная проблема не решена. Лучший подход: пусть работа развертывания не срабатывает, уведомите команду и откатывайте только вручную (или через отдельную откатную работу, вызванную оператором). Для критических служб вы можете реализовать «самоисцеляющийся» шаблон, где трубопровод проверяет здоровье после короткого охлаждения и, если это не удается, запускает откат к предыдущему пересмотру. Всегда регистрируйте пересмотр перед обновлением, чтобы вы точно знали, к какой версии вернуться.

Расширенные функции рулевого управления для трубопроводов CI / CD

Использование крючков для управления жизненным циклом

Крючки руля позволяют выполнять задания до или после определенных событий жизненного цикла (например, предустановка, после обновления). Вы можете использовать крючки для запуска миграций баз данных, настройки внешних служб или запуска дымовых тестов. В CI/CD крючки выполняются автоматически при запуске установки/обновления руля. Однако имейте в виду, что крючки работают в одном кластере и могут влиять на сроки развертывания. Всегда определяйте значения тайм-аута для крючков и изящно обрабатывайте сбои.

Работа с Helmfile для комплексных развертываний

Когда вам нужно развернуть несколько диаграмм с чередующимися зависимостями, рассмотрите возможность использования Helmfile. Helmfile позволяет определить декларативный манифест релизов, которые вы хотите применить к кластеру, включая ссылки на диаграммы, значения и пространство имен. В CI/CD вы можете запускать вместо того, чтобы вызывать шлем по отдельности для каждой диаграммы. Это особенно полезно для сред, которые требуют воспроизводимых, многоприкладных стеков (например, полная среда постановки со всеми микросервисами).

Интеграция с инструментами GitOps

В то время как конвейеры CI/CD запускают команды Helm, инструменты GitOps, такие как ArgoCD или Flux, используют другой подход: они контролируют репозиторий Git для изменений и автоматически применяют желаемое состояние к кластеру с помощью Helm под капотом. CI/CD все еще может создавать и нажимать изображения контейнеров и обновлять файл значений репозитория Git (например, изменяя тег изображения), затем пусть инструмент GitOps обрабатывает фактическое развертывание. Этот шаблон уменьшает область разрешения CI/CD бегуна и облегчает аудит развертываний. Многие команды принимают гибридную модель: CI/CD запускает тесты и сборки, затем нажимает новый манифест в репозиторий GitOps, а отдельный агент Git развертывается в производство.

Заключение

Хелм-чарты - это не просто способ упаковать манифесты Kubernetes - они являются проверенным инструментом, который значительно упрощает развертывание приложений в CI / CD-паттернах. Абстрагируя сложные YAML в версии, параметризованные и многоразовые пакеты диаграмм, вы получаете согласованность в средах, автоматические откаты и четкий аудиторский след. Интеграция Хелм в ваш конвейер так же проста, как добавление нескольких команд в сценарий работы, но преимущества умножаются по мере роста вашей организации и развертывания десятков сервисов. Следуя лучшим практикам, изложенным здесь - версивая ваши диаграммы, используя значения, специфичные для окружающей среды, тщательно тестируя и безопасно обрабатывая секреты - поможет вам избежать подводных камней и ускорить скорость развертывания. Независимо от того, используете ли вы Дженкинс, GitLab, GitHub Actions или GitOps подход, Хелм остается краеугольным камнем современных стратегий развертывания Kubernetes. , руководство по развертыванию , руководство