В первом приближении по моему 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