GitOps с GitLab: CI/CD Tunnel

GitLab можно использовать как первоклассный инструмент GitOps, и здесь мы покажем как. Это пятое практическое руководство из серии, посвящённой разным задачам пользователей, включая подготовку базовой инфраструктуры, управление ей и развёртывание поверх неё различных сторонних и кастомных приложений. 

Здесь мы посмотрим, как получить доступ к кластеру Kubernetes с помощью GitLab CI/CD и зачем это нужно, если вы взяли курс на GitOps.

Предварительные требования

Предполагается, что у вас есть кластер Kubernetes, подключённый к GitLab через GitLab Kubernetes Agent.

Что такое CI/CD Tunnel

GitLab Kubernetes Agent — это не просто инструмент GitOps для развёртывания на основе pull, и он не станет очередным приложением в стеке DevOps, где вам и так приходится жонглировать десятками инструментов. С ним вы сможете управлять всем жизненным циклом DevSecOps в одном приложении — в духе GitLab. Агент предоставляет интегрированный подход для всех соответствующих функций GitLab:

• GitLab CI/CD.

• Защита сети контейнеров.

• Защита хоста контейнеров.

• Сканирование контейнеров.

В этой статье мы поговорим об интеграции GitLab CI/CD. GitLab CI/CD — очень мощный и гибкий инструмент, поэтому большинство пользователей успешно используют его годами. Правда, до появления агента часто приходилось вручную писать скрипт для соединений кластера и развёртывания в него. Если вам это знакомо, испытайте функции интеграции CI/CD в Agent — CI/CD Tunnel. CI/CD Tunnel позволяет использовать соединение кластера из GitLab CI/CD. Достаточно немного скорректировать существующую настройку, чтобы получить компонент, поддерживаемый GitLab, который мы будем постоянно развивать, чтобы добавлять новые интеграции.

CI/CD Tunnel всегда включён в проекте, где зарегистрирован и настроен Agent, а соединение может использоваться ещё и другими группами и проектами по всей организации. Так вы сэкономите на ресурсах и обслуживании.

GitLab автоматически внедряет доступные контексты Kubernetes в KUBECONFIG окружении CI/CD раннера. В результате можно без лишней настройки активировать контекст и использовать его.

Настройка CI/CD Tunnel

Итак, CI/CD Tunnel всегда включён в проекте, где вы зарегистрировали и настроили Agent. Если вы хотите использовать Tunnel в том же репозитории, никакая дополнительная конфигурация не нужна. Чтобы поделиться соединением с другими репозиториями, откройте файл конфигурации агента и добавьте следующие строки:

ci_access:
   projects:
   - id: path/to/project
   groups:
   - id: path/to/group

Вместо плейсхолдеров укажите путь к проекту или группе. Если поделиться соединением с группой, можно получить доступ ко всем проектам в этой группе. Сохранив файл конфигурации, обратитесь к репозиторию проекта приложения и выполните следующее задание, чтобы вывести список агентов и выбрать агент:

deploy:
   image:
     name: bitnami/kubectl:latest
     entrypoint: [""]
   script:
   - kubectl config get-contexts 
   - kubectl config use-context path/to/agent-configuration-project:your-agent-name

Установка интегрированных приложений GitLab в кластер

Установим в кластер несколько приложений, которые нужны для разных функций GitLab. У GitLab есть шаблон проекта по управлению кластером, который поможет вам в этом. С помощью этого шаблона можно легко установить интегрированные приложения GitLab в кластеры. Как это сделать с помощью CI/CD Tunnel и Agent?

Создание проекта по управлению кластером

Сначала создайте новый проект GitLab с помощью шаблона Cluster Management Project. Откройте страницу создания проекта из шаблона, найдите GitLab Cluster Management и начните новый проект.

Вы получите проект, где уже много чего есть. Например, готовый файл .gitlab-ci.yml и настройка на основе helmfile для 11 приложений, которые интегрируются с разными функциями GitLab. Разные приложения могут требовать разных конфигураций. См. документацию.

В этой статье мы установим NGINX Ingress и GitLab Runners с помощью проекта по управлению кластером.

Общее использование CI/CD Tunnel

Новому проекту нужен доступ к одному из кластеров. Поделитесь с ним соединением Agent, как описано выше. В файл конфигурации агента добавьте:

ci_access:
   projects:
   - id: path/to/your/cluster/management/project

Выбор нужного контекста Kubernetes

CI/CD Tunnel уже доступен в проекте по управлению кластером. Мы попытались упростить процесс, так что вам не придётся редактировать .gitlab-ci.yml, чтобы начать использовать соединение. В простых системах достаточно настроить для переменной среды KUBE_CONTEXT путь и имя агента.

Это можно сделать в разделе Settings / CI/CD / Variables.

Установка NGINX Ingress

С помощью этого соединения агента теперь можно установить любое из поддерживаемых приложений. Начнём с установки NGINX Ingress, потому что для него не потребуется конкретная конфигурация, зависящая от приложения.

В проекте по управлению кластером в файле helmfile.yaml раскомментируйте строку, которая указывает на приложение ingress. Осталось закоммитить изменения, и GitLab всё сделает сам.

Установка GitLab Runner

GitLab Runner теснее интегрирован с GitLab, так что нужно будет кое-что настроить. Runner должен знать, где найти ваш инстанс GitLab, и ему нужен токен для аутентификации.

Чтобы упростить себе жизнь, можно задать для этого переменные среды. По умолчанию CI_SERVER_URL указывает URL GitLab. Эту переменную можно изменить. Для токена нужно создать GITLAB_RUNNER_REGISTRATION_TOKEN в качестве замаскированной и защищённой переменной среды и указать значение токена регистрации Runner. Можно взять токен регистрации проекта или группы.

Наконец, как и при установке Ingress, раскомментируйте соответствующую строку helmfile.yaml.

Потенциал проекта по управлению кластером

Проект принадлежит вам. Вы по желанию можете менять, расширять или удалять его. В этом разделе я дам несколько советов, как извлечь из него максимум преимуществ.

Вы уже перешли с Helm v2?

В файле .gitlab-ci.yml в проекте по управлению кластером есть задание для апгрейда с Helm v2 на v3. Если вы никогда не устанавливали эти приложения через проект по управлению кластером с Helm v2, это задание вам не нужно, и его можно спокойно удалить.

Добавляйте в проект свои приложения

Проект по управлению кластером самодостаточен, но в него можно добавлять приложения на основе helm/helmfile. См. helmfile README.

Обновляйтесь вовремя

Вы сами отвечаете за свой проект по управлению кластером, поэтому можете апгрейдить приложения независимо от релизов GitLab. Но можно следовать релизам GitLab, ведь шаблон проекта по управлению кластером наверняка будет совершенствоваться. Что для этого нужно?

Если вы выполнили установку агента с помощью kpt, то знаете, что kpt может выгрузить поддерево git и объединить локальные изменения с изменениями из апстрима при запросе обновления. Здесь тоже можно использовать kpt.

В проекте по управлению кластером можно заменить выбранные приложения на выгрузки kpt. Например, можно следовать апстрим-шаблону:

cd applicatioins
rm -rf prometheus
kpt pkg get https://gitlab.com/gitlab-org/project-templates/cluster-management.git/applications/prometheus prometheus

и обновиться до последней версии:

kpt pkg update applications/prometheus

Итоги

GitLab Kubernetes Agent даёт гораздо больше возможностей, чем специализированные инструменты GitOps. Он не только поддерживает развёртывания на основе pull, но и может интегрироваться в имеющиеся рабочие процессы CI/CD. Шаблон Cluster Management Project, который поставляется с GitLab, дополняет различные интеграции GitLab, чтобы вам было проще начать работать с ними.