Вы когда-нибудь сталкивались с проблемой частого деплоя большого количества приложений в Kubernetes-кластер? Представьте, что у вас десяток сервисов, которые успешно сбилдились, и образы приложений ждут своего часа в registry, но к сожалению деплойменты в Kubernetes сами себя не рестартанут. Вам приходится вручную перезапускать каждый деплоймент, чтобы он подхватил новый образ приложения. Возможно, вы даже написали скрипт для ускорения этой процедуры. Но, как порядочный DevOps-инженер, вы задумываетесь: "Неужели нельзя оптимизировать этот процесс?" Можно! И сегодня мы рассмотрим, как GitLab Agent решает эту проблему, позволяя управлять Kubernetes-кластером напрямую из GitLab CI.
GitLab Agent — это компонент GitLab, который помогает интегрировать и автоматизировать процессы CI/CD с использованием GitLab и Kubernetes. Агент обеспечивает связь между GitLab и Kubernetes-кластерами, позволяя деплоить приложения и управлять ими непосредственно из GitLab.
Этому инструменты можно найти множество применений, но сейчас мы рассмотрим простой пример рестарта деплоймента из CI для обновления образа приложения.
Для данного рецепта вам понадобится:
- Kubernetes-кластер
- GitLab (если у вас self-hosted, убедитесь что то, что стоит перед gitlab умеет в websocket )
- Helm
- Прямые руки
Шаг 1.
Создаем в gitlab новый проект.
Шаг 2.
Заходим в проект и создаем файл с путем вида: .gitlab/agents/project-name/config.yaml
Пока оставляем этот файл пустым.
Шаг 3.
Теперь необходимо задеплоить сам агент в кластер. Находим в нашем созданном проекте раздел Operate-> Kubernetes clusters.
Находим там кнопку Connect a cluster. Нажимаем.
Выбираем репозиторий с нашим агентом (он сам будет предложен для выбора).
Шаг 4.
Выполните сгенерированные Helm команды из командной строки в контексте вашего Kubernetes кластера (лучше их не изменять). Сохраните access token, он больше не появится.
Закройте окно и обновите страницу, чтобы статус сменился с Never connected на Connected.
Шаг 5.
Идем в репозиторий вашего сервиса (проекта), в котором располагается непосредственно gitlab-ci, в котором вы хотите использовать команды управления Kubernetes кластером. Смотрим на url этого проекта и вставляем запись в ранее созданный файл .gitlab/agents/project-name/config.yaml в проекте агента.
Запись должна выглядеть примерно так, по надобности можно добавлять сколько угодно проектов, чтобы дать доступ к ним агенту.
Шаг 6.
Осталось добавить новую джобу в ci вашего сервиса. Это мой пример, но вы можете оформить ее как хотите. Только укажу, что необходимо использовать DEPLOYMENT_NAME ровно такое же как оно отображается в кластере. А K8S_CONTEXT состоит из "path проекта с агентом" : "имя агнета".
Ура! Теперь можно идти переписывать все ci в проектах и больше не заниматься ручным рестартом деплойментов в Kubernetes кластере.
