В первом приближении по моему CV/Blog у меня все готово. Шаблоны приложений созданы, сборка приложений в докер закончена, имеются окружение для разработки и Production-окружение в личном Kubernetes-кластере. Написан Yaml-манифест развертывания приложения в кластере и CI для автоматической сборки образов в GitLab CI.

Что же еще не хватает? Правильно не хватает автоматизированного деплоя в кластер, что называется «По кнопочке» из любого branch и авторазвертывания при деплое в ветку release. Чем собственно сейчас и займемся.

Настройка агента для Kubernetes

Для подключения к кластеру кубика создайте отдельный репозитарий и назовите его например k8s-connection. Создаем дефолтного агента для нашего приложения, для чего в репозитории создаем файл .gitlab/agents/default/config.yaml и пока оставляем его пустым.

В GUI GitLab переходим Operate > Kubernetes clusters > Connect a cluster (agent).

Получаем токен и инструкцию по развертыванию агента в кластере.

Токен мы конечно же сохраняем в хранилище паролей, после чего проверяем, что агент появился в списке и на связь не выходил.

Регистрируем агента при помощи helm-chart по инструкции любезно предоставленной нам гитлабом (helm должен быть установлен на вашей рабочей станции):

$ helm repo add gitlab https://charts.gitlab.io
$ helm repo update
$ helm upgrade --install default gitlab/gitlab-agent \
    --namespace gitlab-agent-default \
    --create-namespace \
    --set image.tag=v16.9.0-rc1 \
    --set config.token=xxx-SECRET-TOKEN-xxx \
    --set config.kasAddress=wss://gitlab.bds.su/-/kubernetes-agent/

Проверяем что пространство имен в кластере создано:

И соответственно удостоверимся, что агент вышел на связь.

Агент готов и можно переходить к настройке проекта.

Настройка проекта для автодеплоя приложения

Дальше сущий ужас и бардак. Пока искал адекватное объяснение процесса было непреодолимое желание все сделать по своему, но раз уж эта чертова интеграция настроена будем петь и плясать от этой стены. Итак, вообще зачем нам понадобился дополнительный репозиторий описанный выше? А он выступает в качестве своеобразного Firewall где мы описываем какие проекты, пользователи и группы могут взаимодействовать с нашим кластером. 

Мы можем разрешить доступ для:

• Проекта
• Группы проектов
• Пользователя

Подробнее на официальном сайте https://docs.gitlab.com/ee/user/clusters/agent/ci_cd_workflow.html#authorize-the-agent

Минимальное содержимое файла .gitlab/agents/default/config.yaml будет выглядеть следующим образом (приминительно для моего приложения).

ci_access:
  projects:
    - id: production-services/chernousov-cv-and-blog

И пример собственно джобы для взаимодействия с кластером.

variables:
  KUBE_CONTEXT: production-services/k8s-connection:k8s-connection

deploy-prod:
  image:
    name: bitnami/kubectl:latest
    entrypoint: [""]
  stage: deploy-prod
  script:
    - kubectl config get-contexts
    - kubectl config use-context $KUBE_CONTEXT
    - kubectl get pods