Deckhouse Kubernetes Platform (DKP) использует container registry для загрузки и обновления модуля. В container registry хранятся артефакты модуля. Артефакты модуля появляются в результате сборки модуля, после чего их можно загрузить (опубликовать) в registry.

Состав артефактов модуля

В результате сборки модуля создаются три типа артефактов, которые впоследствии загружаются в container registry:

  • Образы контейнеров приложений. Правила сборки и исходный код таких образов находятся в директории с именем приложения внутри images. Собранные образы указываются в шаблонах и запускаются в кластере. Образы тегируются content-based тегами, и для их использования в шаблонах необходимо подключить библиотеку lib-helm.
  • Образ модуля. Правила сборки модуля находятся в файле werf.yaml в директории модуля. В качестве тегов образов используется семантическое версионирование.
  • Релиз. Артефакт версии модуля. На основе данных релиза DKP принимает решение об обновлении модуля в кластере. У релизов есть два типа тегов: тег семантического версионирования (как у образа модуля) и тег, соответствующий каналу обновлений (например, alpha, beta и т. д.). В шаблоне модуля есть пример workfklow для GitHub Actions, где релиз создается автоматически при сборке.

Сборка артефактов модуля и публикация в container registry

Для сборки артефактов модуля и загрузки их в container registry в рамках процесса CI/CD мы предлагаем воспользоваться подготовленными GitHub Actions.

В репозитории шаблона модуля представлен пример модуля, который содержит простой workflow для GitHub Actions и использует GitHub Packages (ghcr.io) в качестве container registry. В представленном примере workflow используется следующая логика:

  • Сборка артефактов модуля при изменениях в рамках PR и при слиянии изменений в ветку main.
  • Сборка артефактов модуля из тегов с использованием продуктивного container registry.
  • Публикация модуля в container registry GitHub Packages в выбранный канал обновлений из тега.

Артефакты модуля будут загружаться по адресу ghcr.io/<OWNER>/modules/, который будет являться источником модулей.

Выполните следующие настройки в свойствах вашего проекта на GitHub, чтобы workflow модуля работал корректно:

  • Откройте страницу Settings -> Actions -> General.
  • Установите параметр Read and write permissions в разделе Workflow permissions.

Вы также можете модифицировать workflow, предусмотреть использование своего container registry и более сложный процесс сборки и публикации (например, с использованием отдельных container registry для разработки и промышленной эксплуатации).

Артефакты модуля также можно собрать локально с помощью werf (это может потребоваться, например, при отладке).

Вы также можете самостоятельно сделать сборку артефактов модуля и публикацию для вашей системы CI/CD по аналогии с workflow для GitHub Actions, приведенном в шаблоне модуля, но это может потребовать глубокого понимания процессов сборки и публикации модуля. Обратитесь к сообществу при появлении вопросов и затруднений.

Общий сценарий работы с workflow, приведенным в шаблоне модуля:

  1. Опубликуйте изменения в коде модуля в ветке проекта на GitHub. Это запустит сборку артефактов модуля и их публикацию в container registry.
  2. Создайте новый релиз модуля или установите тег в формате семантического версионирования на нужном коммите.
  3. Перейдите в раздел Actions репозитория модуля на GitHub и слева, в списке workflow, выберите Deploy.
  4. В правой части страницы нажмите на выпадающий список Run workflow, выберите необходимый канал обновлений и укажите нужный тег в поле ввода тега. Нажмите кнопку Run workflow.
  5. После успешного выполнения workflow в container registry появится новая версия модуля. Опубликованную версию модуля можно использовать в кластере.