Связаться с намиПодключиться

Интеграция с Argo CD

Статья создана
Улучшена
Обновлена 23 апреля 2025 г.

Argo CD — декларативный инструмент для непрерывной доставки в Kubernetes по модели GitOps.

В этом руководстве описана интеграция инстанса Yandex Managed Service for GitLab, кластера Managed Service for Kubernetes и установленных в кластере Argo CD и GitLab Runner, который выполняет сборку Docker-контейнеров с помощью инструмента Kaniko.

Чтобы интегрировать Argo CD с Managed Service for Kubernetes и Managed Service for GitLab:

  1. Создайте инстанс GitLab.
  2. Настройте GitLab.
  3. Создайте GitLab Runner.
  4. Подготовьте репозиторий приложения для развертывания.
  5. Разверните приложение с помощью Argo CD.

Если созданные ресурсы вам больше не нужны, удалите их.

В стоимость поддержки описываемого решения входят:

  • Плата за кластер Managed Service for Kubernetes: использование мастера и исходящий трафик (см. тарифы Managed Service for Kubernetes).

  • Плата за узлы кластера (ВМ): использование вычислительных ресурсов, операционной системы и хранилища (см. тарифы Compute Cloud).

  • Плата за публичные IP-адреса, если они назначены узлам кластера (см. тарифы Virtual Private Cloud).

  • Плата за NAT-шлюз, если он используется вместо публичных IP-адресов для узлов кластера (см. тарифы Virtual Private Cloud).

  • Плата за использование хранилища Container Registry.

  • Плата за инстанс GitLab. Она зависит от способа создания инстанса:

    • Managed Service for GitLab: оплачиваются ресурсы ВМ, хранение данных и резервных копий, объем исходящего трафика (см. тарифы Managed Service for GitLab).
    • ВМ с образом GitLab: оплачиваются ресурсы ВМ, образ GitLab, публичный IP-адрес для ВМ (см. тарифы Compute Cloud и Virtual Private Cloud).

Перед началом работы

Подготовьте инфраструктуру

  1. Если у вас еще нет сети, создайте ее.

  2. Если у вас еще нет подсетей, создайте их в зонах доступности, где будут созданы кластер Managed Service for Kubernetes и группа узлов.

  3. Создайте сервисные аккаунты:

    Совет

    Вы можете использовать один и тот же сервисный аккаунт для управления кластером Managed Service for Kubernetes и его группами узлов.

  4. Создайте группы безопасности для кластера Managed Service for Kubernetes и входящих в него групп узлов.

    Важно

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

  5. Создайте группу безопасности для работы инстанса Managed Service for GitLab.

  6. Создайте кластер Managed Service for Kubernetes и группу узлов. При создании кластера Managed Service for Kubernetes укажите ранее созданные сервисные аккаунты для ресурсов и узлов и группы безопасности для кластера.

  7. Создайте реестр Yandex Container Registry.

  8. Сохраните идентификатор созданного реестра — он понадобится для следующих шагов.

  1. Если у вас еще нет Terraform, установите его.

  2. Получите данные для аутентификации. Вы можете добавить их в переменные окружения или указать далее в файле с настройками провайдера.

  3. Настройте и инициализируйте провайдер. Чтобы не создавать конфигурационный файл с настройками провайдера вручную, скачайте его.

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

  5. Скачайте в ту же рабочую директорию файл конфигурации кластера Managed Service for Kubernetes k8s-argocd.tf. В файле описаны:

    • Сеть.

    • Подсеть.

    • Кластер Managed Service for Kubernetes.

    • Сервисный аккаунт для ресурсов и узлов Managed Service for Kubernetes.

    • Реестр Container Registry.

    • Группы безопасности, которые содержат необходимые правила для кластера Managed Service for Kubernetes и входящих в него групп узлов.

      В этих группах безопасности также присутствуют правила, необходимые для работы инстанса Managed Service for GitLab и реестра Container Registry.

      Важно

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

  6. Укажите в файле конфигурации:

    • Идентификатор каталога.
    • Версию Kubernetes для кластера Managed Service for Kubernetes и групп узлов.
    • CIDR кластера Managed Service for Kubernetes.
    • Имя сервисного аккаунта для ресурсов и узлов Managed Service for Kubernetes.
    • Имя реестра Container Registry.

  7. Проверьте корректность файлов конфигурации Terraform с помощью команды:

    terraform validate

    Если в файлах конфигурации есть ошибки, Terraform на них укажет.

  8. Создайте необходимую инфраструктуру:

    1. Выполните команду для просмотра планируемых изменений:

      terraform plan

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

    2. Если вас устраивают планируемые изменения, внесите их:

      1. Выполните команду:

        terraform apply

      2. Подтвердите изменение ресурсов.

      3. Дождитесь завершения операции.

    В указанном каталоге будут созданы все требуемые ресурсы. Проверить появление ресурсов и их настройки можно в консоли управления.

Установите дополнительные зависимости

Установите в локальном окружении:

Создайте инстанс GitLab

Создайте инстанс Managed Service for GitLab или виртуальную машину с образом GitLab в той же облачной сети, где расположен кластер Managed Service for Kubernetes.

Создайте инстанс Managed Service for GitLab согласно инструкции.

Запустите GitLab на ВМ с публичным IP-адресом.

  1. На странице каталога в консоли управления нажмите кнопку Создать ресурс и выберите Виртуальная машина.

  2. В блоке Образ загрузочного диска в поле Поиск продукта введите Gitlab и выберите публичный образ GitLab.

  3. В блоке Расположение выберите зону доступности, в которой будет находиться ВМ. Если вы не знаете, какая зона доступности вам нужна, оставьте выбранную по умолчанию.

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

    • Платформа — Intel Ice Lake.
    • vCPU — 4.
    • Гарантированная доля vCPU — 100%.
    • RAM — 8 ГБ.

  5. В блоке Сетевые настройки:

    • В поле Подсеть выберите сеть и подсеть, к которым нужно подключить ВМ. Если нужной сети или подсети еще нет, создайте их.
    • В поле Публичный IP-адрес оставьте значение Автоматически, чтобы назначить ВМ случайный внешний IP-адрес из пула Yandex Cloud, или выберите статический адрес из списка, если вы зарезервировали его заранее.

  6. В блоке Доступ выберите вариант SSH-ключ и укажите данные для доступа на ВМ:

    • В поле Логин введите имя пользователя. Не используйте имя root или другие имена, зарезервированные ОС. Для выполнения операций, требующих прав суперпользователя, используйте команду sudo.

    • В поле SSH-ключ выберите SSH-ключ, сохраненный в вашем профиле пользователя организации.

      Если в вашем профиле нет сохраненных SSH-ключей или вы хотите добавить новый ключ:

      • Нажмите кнопку Добавить ключ.
      • Задайте имя SSH-ключа.
      • Загрузите или вставьте содержимое открытого SSH-ключа. Пару SSH-ключей для подключения к ВМ по SSH необходимо создать самостоятельно.
      • Нажмите кнопку Добавить.

      SSH-ключ будет добавлен в ваш профиль пользователя организации.

      Если в организации отключена возможность добавления пользователями SSH-ключей в свои профили, добавленный открытый SSH-ключ будет сохранен только в профиле пользователя создаваемой виртуальной машины.

  7. В блоке Общая информация задайте имя ВМ: ci-tutorial-gitlab.

  8. Нажмите кнопку Создать ВМ.

Создание ВМ может занять несколько минут. Когда ВМ перейдет в статус RUNNING и запустится GitLab, настройте его.

Настройте GitLab

Чтобы настроить GitLab и подготовить процесс непрерывной интеграции (Continuous Integration, CI), создайте новый проект и введите параметры для авторизации в CI:

  1. Авторизуйтесь в веб-интерфейсе инстанса Managed Service for GitLab.

  2. Нажмите кнопку Create a project.

  3. Нажмите кнопку Create blank project.

  4. Заполните поля:

    • Project name — gitlab-test.
    • Project URL — выберите пользователя-администратора в поле рядом с FQDN инстанса Managed Service for GitLab.

    Остальные поля оставьте без изменений.

  5. Нажмите кнопку Create project.

  1. На странице сервиса Yandex Compute Cloud выберите созданную ВМ и скопируйте ее публичный IP-адрес.

  2. Подключитесь к ВМ по протоколу SSH.

  3. Получите пароль администратора GitLab с помощью команды ВМ:

    sudo cat /etc/gitlab/initial_root_password

  4. Скопируйте пароль из строки Password (исключая пробелы) в буфер обмена или отдельный файл.

  5. Откройте в браузере ссылку http://<публичный_IP-адрес_ВМ>. Откроется веб-интерфейс GitLab.

  6. Войдите в систему с учетной записью администратора:

    • Username or email — root.
    • Password — пароль, скопированный ранее.

    Если вы не можете войти, сбросьте пароль учетной записи администратора.

  7. Смените пароль учетной записи администратора.

  8. Повторно войдите в систему с учетной записью администратора, используя новый пароль.

  9. Выберите Create a project.

  10. Задайте имя проекта: gitlab-test.

  11. Нажмите кнопку Create project.

Создайте GitLab Runner

Чтобы запускать задачи сборки в кластере Yandex Managed Service for Kubernetes, создайте GitLab Runner. Для этого установите приложение GitLab Runner согласно инструкции.

После установки вы можете запускать автоматизированные сборки внутри своего кластера Managed Service for Kubernetes.

Подробнее про установку и настройку GitLab Runner читайте в документации GitLab.

Подготовьте репозиторий приложения для развертывания

  1. Получите авторизованный ключ для созданного ранее сервисного аккаунта с ролями container-registry.images.puller и container-registry.images.pusher:

    yc iam key create --service-account-name <имя_сервисного_аккаунта_для_узлов> -o key.json

  2. Сохраните содержимое этого ключа — оно потребуется на следующем шаге:

    cat key.json | base64

  3. Создайте переменные окружения GitLab:

    1. На панели слева в GitLab перейдите в раздел Settings и во всплывающем списке выберите пункт CI/CD.

    2. Нажмите кнопку Expand напротив пункта Variables.

    3. Добавьте переменные окружения:

      • CI_REGISTRY — адрес созданного ранее реестра в формате cr.yandex/<идентификатор_реестра>.
      • CI_REGISTRY_USER — json_key.
      • CI_REGISTRY_PASSWORD — вывод команды cat key.json | base64.

      Для добавления переменной:

      1. Нажмите кнопку Add variable.
      2. В появившемся окне в поле Key укажите имя переменной, в поле Value — значение переменной.
      3. Нажмите кнопку Add variable.

  4. Настройте доступ к репозиторию:

    1. Сгенерируйте новую пару SSH-ключей или используйте существующую.
    2. Добавьте публичную часть SSH-ключа в настройки учетной записи GitLab.

  5. Клонируйте репозиторий:

    git clone git@<имя_инстанса>.gitlab.yandexcloud.net:<имя_пользователя-администратора>/gitlab-test.git

  6. Клонируйте репозиторий yc-webinar-gitops-argo-crossplane на рабочую машину:

    git clone https://github.com/yandex-cloud-examples/yc-webinar-gitops-argo-crossplane.git

  7. Скопируйте в директорию gitlab-test все файлы из директории yc-webinar-gitops-argo-crossplane/02-argocd/app, включая скрытые:

    cp -rT <путь_к_директории_app> <путь_к_директории_gitlab-test>

  8. Зафиксируйте изменения в gitlab-test и отправьте их в репозиторий:

    git add . && \
git commit -m "Add app src and CI" && \
git push

  9. Запустится сценарий сборки. Чтобы посмотреть его выполнение, на панели слева в GitLab выберите Build → Pipelines. Дождитесь успешного завершения обоих этапов сборки.

  10. Откройте завершенную сборку и скопируйте строку из лога, она понадобится на следующем этапе:

    INFO[0025] Pushing image to cr.yandex/<идентификатор_реестра>/<имя_пользователя-администратора>/gitlab-test:main.<номер_коммита>

Разверните приложение с помощью Argo CD

Установите Argo CD в кластер Managed Service for Kubernetes

  1. Установите Argo CD согласно инструкции.

    Важно

    Группам узлов Kubernetes требуется доступ в интернет для скачивания образов и компонентов.

    Предоставить доступ в интернет можно следующими способами:

  2. Получите пароль администратора из секрета Kubernetes:

    kubectl --namespace <пространство_имен> get secret argocd-initial-admin-secret \
  --output jsonpath="{.data.password}" | base64 -d

  3. Настройте переадресацию порта сервиса ArgoCD на локальный компьютер:

    kubectl port-forward service/<название_приложения_Argo_CD>-argocd-server \
  --namespace <пространство_имен> 8080:443

  4. Откройте в браузере консоль Argo CD по адресу https://127.0.0.1:8080.

  5. Авторизуйтесь в консоли, используя имя пользователя admin и полученный ранее пароль.

Добавьте репозиторий GitLab в Argo CD

  1. На панели слева в GitLab перейдите в раздел Settings и во всплывающем списке выберите пункт Access Tokens.

  2. Задайте параметры нового токена:

    • Token name — argocd.
    • Select a role — Maintainer.
    • Select scopes — read_repository.

  3. Нажмите кнопку Create project access token.

  4. Скопируйте значение созданного токена.

  5. В консоли Argo CD перейдите в раздел Settings → Repositories.

  6. Нажмите кнопку Connect Repo и выберите в списке VIA HTTPS.

    Примечание

    Если при подключении репозитория вы получаете ошибку FATA[0000] rpc error: code = Unknown desc = error testing repository connectivity: authorization failed, включите доступ в GitLab по протоколу HTTP(S).

    Чтобы включить доступ, на панели слева в GitLab выберите Admin → Settings → General. В блоке Visibility and access controls найдите настройку Enabled Git access protocols и выберите в списке пункт, разрешающий доступ по протоколу HTTP(S).

    Подробнее в документации GitLab.

  7. В открывшейся форме задайте параметры:

    • Repository URL — URL репозитория вида https://<имя_инстанса_GitLab>.gitlab.yandexcloud.net/<имя_пользователя-администратора>/gitlab-test.git.
    • Username — gitlab-ci-token.
    • Password — токен GitLab, сгенерированный ранее.

  8. Нажмите кнопку Connect.

  9. В консоли Argo CD перейдите в раздел Applications и нажмите кнопку Create Application.

  10. В открывшейся форме задайте параметры:

    • Application Name — gitlab-test.
    • Project — default.
    • Sync policy — Automatic, затем выберите опции Prune resources и Self Heal.
    • Sync options — выберите опцию Auto-Create Namespace.
    • Repository URL — укажите URL репозитория вида https://<имя_инстанса_GitLab>.gitlab.yandexcloud.net/<имя_пользователя-администратора>/gitlab-test.git.
    • Path — .helm.
    • Cluster URL — https://kubernetes.default.svc.
    • Namespace — gitlab-test.
    • image.repository — cr.yandex/<идентификатор_реестра>/<имя_пользователя-администратора>/gitlab-test.
    • image.tag — main.<номер_коммита>.

  11. Нажмите кнопку Create и дождитесь завершения синхронизации.

  12. Для проверки запуска приложения выполните команду в кластере Managed Service for Kubernetes:

    kubectl get all -n gitlab-test

    Результат:

    NAME                               READY   STATUS    RESTARTS   AGE
pod/gitlab-test-67c8d58bc4-6w4q7   1/1     Running   0          2m26s
pod/gitlab-test-67c8d58bc4-sldpc   1/1     Running   0          2m26s

NAME                  TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
service/gitlab-test   ClusterIP   10.96.186.223   <none>        80/TCP    2m26s

NAME                          READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/gitlab-test   2/2     2            2           2m26s

NAME                                     DESIRED   CURRENT   READY   AGE
replicaset.apps/gitlab-test-67c8d58bc4   2         2         2       2m26s

Проверьте автоматическую синхронизацию из репозитория

  1. Перейдите в директорию с клонированным проектом и откройте файл .helm/values.yaml.

  2. Измените значение параметра replicaCount на 3.

  3. Сохраните изменения и отправьте их в репозиторий:

    git add . && \
git commit -m "Increase replica count" && \
git push

  4. В консоли Argo CD дождитесь синхронизации приложения.

  5. Проверьте, что количество подов приложения в кластере Managed Service for Kubernetes увеличилось:

    kubectl get pod -n gitlab-test

    Результат:

    NAME                               READY   STATUS    RESTARTS   AGE
pod/gitlab-test-67c8d58bc4-6w4q7   1/1     Running   0          15m
pod/gitlab-test-67c8d58bc4-7hmcn   1/1     Running   0          10m
pod/gitlab-test-67c8d58bc4-sldpc   1/1     Running   0          15m

NAME                  TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
service/gitlab-test   ClusterIP   10.96.186.223   <none>        80/TCP    15m

NAME                          READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/gitlab-test   3/3     3            3           15m

NAME                                     DESIRED   CURRENT   READY   AGE
replicaset.apps/gitlab-test-67c8d58bc4   3         3         3       15m

Удалите созданные ресурсы

Некоторые ресурсы платные. Чтобы за них не списывалась плата, удалите ресурсы, которые вы больше не будете использовать:

  1. Удалите созданные Docker-образы.

  2. Удалите кластер Managed Service for Kubernetes и реестр Container Registry:

    1. В терминале перейдите в директорию с планом инфраструктуры.

      Важно

      Убедитесь, что в директории нет Terraform-манифестов с ресурсами, которые вы хотите сохранить. Terraform удаляет все ресурсы, которые были созданы с помощью манифестов в текущей директории.

    2. Удалите ресурсы:

      1. Выполните команду:

        terraform destroy

      2. Подтвердите удаление ресурсов и дождитесь завершения операции.

      Все ресурсы, которые были описаны в Terraform-манифестах, будут удалены.

  3. Удалите созданную виртуальную машину GitLab или инстанс Managed Service for GitLab.

Предыдущая
Передача логов кластера Managed Service for Kubernetes в Cloud Logging
Следующая
Интеграция с Crossplane