Как использовать GitLab в качестве реестра Helm-чартов

С появлением GitLab 14.1 реестр пакетов Package Registry позволяет пользователям собирать, публиковать, устанавливать и делиться Helm-чартами (англ. chart).

Что такое Helm-чарт? 

Пакетный менеджер Helm использует пакеты под названием чарты. Чарт  —  это совокупность файлов, определяющих соответствующий набор ресурсов Kubernetes. Один такой чарт можно задействовать для развертывания как простого пода memcached, так и сложного полностекового веб-приложения с HTTP-серверами, базами данных, кэшами и т.д. 

Создание простого Helm-чарта 

Мы создадим простой Helm-чарт, передадим его в проект GitLab, упакуем и опубликуем в реестре пакетов GitLab Package Registry.

Сначала создаем проект GitLab, где будут храниться шаблоны чарта: 

После этого с помощью следующей команды создаем простой Helm-чарт на локальном компьютере: 

$ helm create example-chart

Требуется предварительная установка Helm на компьютере, иначе команда не сработает. 

Команда helm create создает директорию с общими файлами и каталогами, которые применяются в чарте. 

Вывод команды ls подтверждает создание всех необходимых файлов. Теперь отправляем их в проект GitLab helm-chart-example.

После успешной отправки файлов упаковываем директорию как Helm-чарт для хранения в реестре пакетов. Эта процедура выполняется либо командой helm package на компьютере, либо с помощью конвейера CI, предоставляемого GitLab. Рекомендую для упаковки и отправки Helm-чартов воспользоваться вторым вариантом.

Создание конвейера CI на GitLab

Перед созданием конвейера убедитесь, что во вкладке Visibility, project features, permissions (Видимость, функциональности проекта, разрешения) из разделов проекта Settings→General активирована кнопка Packages:

На этом этапе нас ждет самое интересное  —  создание конвейера GitLab для упаковки и публикации Helm-чарта. Мы легко это сделаем в разделе проекта CI/CD→Editor. Если вы ранее не работали с GitLab CI/CD, то данное обучающее руководство введет вас в курс дела. 

Конвейер выглядит следующим образом: 

Ниже представлен код конвейера. Проведем его построчный анализ: 

stages:
  - package-publish

helm-package:
  stage: package-publish
  image:
    name: alpine/helm:3.5.3
    entrypoint: [""]
  tags: 
    - minikube    
  variables:
    CHART: example-chart
  before_script:
    - apk add git
    - helm plugin install --version=v0.9.0 https://github.com/chartmuseum/helm-push.git
    - >
      helm repo add ${CHART}
      --username ${CI_REGISTRY_USER}
      --password ${CI_REGISTRY_PASSWORD}
      ${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/packages/helm/stable
  script:
    - helm package ${CHART}
    - helm push ${CHART}*.tgz ${CHART}
  only:
    refs:
      - main
    changes:
      - example-chart/**/*

В верхней части файла задаем этапу stages имя package-publish, которое будет использовано в задаче helm-package. Ключевое слово tags отвечает за Gitlab-Runner (приложение, выполняющее задачи в конвейере). Поскольку в нашем случае приложение Gitlab-Runner установлено на собственном сервере в среде Minikube, то в проекте указывается соответствующий ему тег. 

Обратите внимание, что в своем конвейере вы указываете другие теги. 

Как видно, в коде присутствует переменная CHART, значение которой совпадает с именем созданного Helm-чарта. Эта переменная нужна исключительно для удобства и позволяет избежать многократного применения одного и того же имени. 

В разделе before_script устанавливаем зависимости: git и плагин helm-push. Следующий важный шаг  —  это аутентификация в реестре с помощью команды helm repo add, которая добавляет репозиторий Helm в командную оболочку Gitlab-Runner. Переменные CI_REGISTRY_USER, CI_REGISTRY_PASSWORD, CI_API_V4_URL и CI_PROJECT_ID являются специальными переменными GitLab CI/CD.

• CI_REGISTRY_USER  —  имя пользователя для отправки контейнеров/чартов в реестр контейнеров/пакетов проекта GitLab. Задается только при активном режиме данного реестра в проекте. 
• CI_REGISTRY_PASSWORD  —  пароль для отправки контейнеров/чартов в реестр контейнеров/пакетов проекта GitLab. Задается только при активном режиме данного реестра в проекте.
• CI_API_V4_URL  —  корневой URL-адрес GitLab API v4.
• CI_PROJECT_ID  —  ID текущего проекта. Этот ID уникален для всех проектов на экземпляре GitLab. 

В разделе script соответствующими командами Helm мы выполняем два действия: упаковку и отправку. Команда helm package упаковывает чарт в архивный файл с версией чарта. Команда helm push загружает чарт в реестр. 

Последний раздел определяет момент запуска задачи GitLab. Ключевое слово only.refs означает, что задача будет создана в случае любого коммита в главной ветке. Ключевое слово only.changes подразумевает, что задача будет создана и автоматически запущена при любых изменениях файлов в директории example-chart. 

Итак, мы подробно проанализировали все нужные аспекты. Пора запускать конвейер. Для этого нужно просто изменить один из файлов в директории example-chart. 

Успешно зафиксировав изменения, переходим на вкладку CI/CD и проверяем состояние задачи.

Кроме того, проверим Helm-чарт, который был отправлен в реестр пакетов под версией 0.1.1. 

Заключение

Мы научились использовать GitLab Package Registry в качестве реестра чартов Helm. Храните, публикуйте и работайте с чартами наряду с манифестами Kubernetes. 

Читайте также:

• Обзор команд Git для отмены изменений
• Как настроить непрерывную интеграцию на GitLab с помощью Docker
• Как настроить отдельные SSH-ключи для нескольких учётных записей GitLab

Читайте нас в Telegram, VK и Яндекс.Дзен

---

Перевод статьи Hayk Davtyan: Using GitLab As Helm Chart Registry