Источник: Nuances of Programming
С появлением 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.
Читайте также:
Перевод статьи Hayk Davtyan: Using GitLab As Helm Chart Registry
