Gitlab в качестве Helm Package Registry¶

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

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

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

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

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

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

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

$ helm create example-chart

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

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

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

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

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

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

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

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

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

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. alt text Повышение версии чарта

Успешно зафиксировав изменения, переходим на вкладку CI/CD и проверяем состояние задачи. alt text Задача helm-package запущена

Кроме того, проверим Helm-чарт, который был отправлен в реестр пакетов под версией 0.1.1. alt text example-chart сохранен в реестре пакетов GitLab Заключение

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