Yandex Cloud
  • Сервисы
  • Решения
  • Почему Yandex Cloud
  • Сообщество
  • Тарифы
  • Документация
  • Связаться с нами
Подключиться
Language / Region
Проект Яндекса
© 2023 ООО «Яндекс.Облако»
Практические руководства
  • Веб-сервис
    • Все руководства
    • Статический сайт в Object Storage
    • Сайт на LAMP- или LEMP-стеке
    • Отказоустойчивый сайт с балансировкой нагрузки с помощью Network Load Balancer
    • Отказоустойчивый сайт с балансировкой нагрузки с помощью Application Load Balancer
    • Сайт на базе Joomla с БД PostgreSQL
    • Создание сайта на WordPress
    • Сайт на WordPress с БД MySQL
    • Перенос WordPress сайта с хостинга в Yandex Cloud
    • Сайт на базе 1С-Битрикс
    • Организация виртуального хостинга
    • Создание балансировщика с защитой от DDoS
    • Публикация обновлений для игр с помощью Cloud CDN
    • Интеграция L7-балансировщика с Cloud CDN и Object Storage
    • Сине-зеленое и канареечное развертывание версий сервиса
    • Терминирование TLS-соединений
  • Интернет-магазины
    • Все руководства
    • Интернет-магазин на 1С-Битрикс
    • Интернет-магазин на OpenCart
  • Архив данных
    • Все руководства
    • Однонодовый файловый сервер
    • Настройка SFTP-сервера на Centos 7
    • Резервное копирование в Object Storage через Acronis
    • Резервное копирование в Object Storage с помощью CloudBerry Desktop Backup
    • Резервное копирование в Object Storage через Duplicati
    • Резервное копирование в Object Storage с помощью Bacula
    • Резервное копирование в Object Storage с помощью Veritas Backup Exec
    • Распознавание архива изображений в Vision
  • Тестовая среда
    • Все руководства
    • Тестирование приложений с помощью GitLab
    • Создание тестовых ВМ через GitLab CI
    • Высокопроизводительные вычисления на прерываемых ВМ
    • Эмуляция множества IoT-устройств
    • Нагрузочное тестирование gRPC-сервиса
    • Развертывание и нагрузочное тестирование gRPC-сервиса с масштабированием
    • HTTPS-тест с постоянной нагрузкой с помощью Phantom
    • HTTPS-тест со ступенчатой нагрузкой с помощью Pandora
    • Нагрузочное тестирование с нескольких агентов
  • Управление инфраструктурой
    • Все руководства
    • Начало работы с Terraform
    • Загрузка состояний Terraform в Object Storage
    • Начало работы с Packer
    • Сборка образа ВМ с набором инфраструктурных инструментов с помощью Packer
    • Автоматизация сборки образов с помощью Jenkins и Packer
    • Непрерывное развертывание контейнеризованных приложений с помощью GitLab
    • Создание кластера Linux-серверов «1С:Предприятия» с кластером Managed Service for PostgreSQL
    • Миграция в Yandex Cloud с помощью Hystax Acura
    • Защита от сбоев с помощью Hystax Acura
    • Настройка синхронизации часов с помощью NTP
    • Работа с группой ВМ с автомасштабированием
    • Масштабирование группы ВМ по расписанию
    • Автомасштабирование группы ВМ для обработки сообщений из очереди Message Queue
    • Обновление группы ВМ под нагрузкой
    • Передача логов с ВМ в Cloud Logging
    • Резервное копирование ВМ с помощью Hystax Acura Backup
    • Настройка отказоустойчивой архитектуры в Yandex Cloud
    • Создание SAP-программы в Yandex Cloud
    • Настройка локального кеширующего DNS-резолвера
    • Миграция DNS-зон из Яндекс 360 в Cloud DNS
    • Интеграция Cloud DNS и корпоративного сервиса DNS
    • Создание веб-хука резолвера ACME для ответов на DNS01-проверки
    • Запись логов балансировщика в PostgreSQL
    • Создание триггера для бюджетов, который вызывает функцию для остановки ВМ
  • Построение Data Platform
    • Все руководства
    • Миграция БД из стороннего кластера Apache Kafka® в Managed Service for Apache Kafka®
    • Поставка данных из Managed Service for MySQL в Managed Service for Apache Kafka® с помощью Data Transfer
    • Поставка данных из Managed Service for PostgreSQL в Managed Service for Apache Kafka® с помощью Data Transfer
    • Поставка данных из Managed Service for Apache Kafka® в Managed Service for ClickHouse с помощью Data Transfer
    • Перенос данных между кластерами Managed Service for Apache Kafka® с помощью Data Transfer
    • Поставка данных из Managed Service for Apache Kafka® в Managed Service for YDB с помощью Data Transfer
    • Поставка данных из Managed Service for MySQL в Managed Service for Apache Kafka® с помощью Debezium
    • Поставка данных из Managed Service for PostgreSQL в Managed Service for Apache Kafka® с помощью Debezium
    • Настройка Kafka Connect для работы с кластером Managed Service for Apache Kafka®
    • Управление схемами данных в Managed Service for Apache Kafka®
    • Использование Managed Schema Registry с Managed Service for Apache Kafka®
    • Использование Confluent Schema Registry с Managed Service for Apache Kafka®
    • Миграция базы данных из MySQL в ClickHouse с помощью Data Transfer
    • Асинхронная репликация данных из PostgreSQL в ClickHouse
    • Обмен данными между Managed Service for ClickHouse и Data Proc
    • Настройка Managed Service for ClickHouse для Graphite
    • Получение данных из Managed Service for Apache Kafka® в Managed Service for ClickHouse
    • Поставка данных из Managed Service for Apache Kafka® в Managed Service for ClickHouse с помощью Data Transfer
    • Получение данных из RabbitMQ в Managed Service for ClickHouse
    • Сохранение потока данных Data Streams в Managed Service for ClickHouse
    • Использование гибридного хранилища в Managed Service for ClickHouse
    • Шардирование таблиц Managed Service for ClickHouse
    • Настройка Cloud DNS для доступа к кластерам управляемых баз данных из других облачных сетей
    • Настройка Cloud DNS для доступа к кластеру Managed Service for ClickHouse из других облачных сетей
    • Обмен данными между Managed Service for ClickHouse и Data Proc
    • Импорт данных из Managed Service for MySQL в Data Proc с помощью Sqoop
    • Импорт данных из Managed Service for PostgreSQL в Data Proc с помощью Sqoop
    • Использование скриптов инициализации для настройки GeeseFS в Data Proc
    • Миграция данных из стороннего кластера Elasticsearch в Managed Service for Elasticsearch с помощью Reindex API
    • Миграция коллекций из стороннего кластера MongoDB в Managed Service for MongoDB
    • Миграция данных в Managed Service for MongoDB
    • Шардирование коллекций MongoDB
    • Анализ производительности и оптимизация MongoDB
    • Миграция БД из стороннего кластера MySQL в кластер Managed Service for MySQL
    • Анализ производительности и оптимизация Managed Service for MySQL
    • Синхронизация данных из стороннего кластера MySQL в Managed Service for MySQL с помощью Data Transfer
    • Миграция БД из Managed Service for MySQL в сторонний кластер MySQL
    • Миграция БД из Managed Service for MySQL в Object Storage с помощью Data Transfer
    • Импорт данных из Managed Service for MySQL в Data Proc с помощью Sqoop
    • Поставка данных из Managed Service for MySQL в Managed Service for Apache Kafka® с помощью Data Transfer
    • Поставка данных из Managed Service for MySQL в Managed Service for Apache Kafka® с помощью Debezium
    • Миграция БД из Managed Service for MySQL в Managed Service for YDB с помощью Data Transfer
    • Создание кластера PostgreSQL для «1С:Предприятия»
    • Анализ производительности и оптимизация Managed Service for PostgreSQL
    • Миграция БД из Managed Service for PostgreSQL
    • Миграция БД из стороннего кластера PostgreSQL в Managed Service for PostgreSQL
    • Асинхронная репликация данных из PostgreSQL в ClickHouse
    • Поставка данных из Managed Service for PostgreSQL в Managed Service for Apache Kafka® с помощью Data Transfer
    • Поставка данных из Managed Service for PostgreSQL в Managed Service for Apache Kafka® с помощью Debezium
    • Импорт данных из Managed Service for PostgreSQL в Data Proc с помощью Sqoop
    • Поставка данных из Managed Service for PostgreSQL в Managed Service for YDB с помощью Data Transfer
    • Миграция БД из Managed Service for PostgreSQL в Object Storage
    • Миграция БД из Greenplum® в ClickHouse
    • Миграция БД из Greenplum® в PostgreSQL
    • Миграция БД из стороннего кластера Redis в Managed Service for Redis
    • Использование кластера Managed Service for Redis в качестве хранилища сессий PHP
  • Продукты Microsoft в Yandex Cloud
    • Все руководства
    • Развертывание Active Directory
    • Развертывание Microsoft Exchange
    • Развертывание Remote Desktop Services
    • Развертывание группы доступности Always On с внутренним сетевым балансировщиком
    • Развертывание Remote Desktop Gateway
  • Сетевая инфраструктура
    • Все руководства
    • Архитектура и защита базового интернет-сервиса
    • Настройки DHCP для работы с корпоративным DNS-сервером
    • Маршрутизация с помощью NAT-инстанса
    • Создание туннеля IPSec VPN
    • Установка виртуального роутера Cisco CSR 1000v
    • Установка виртуального роутера Mikrotik CHR
    • Соединение с облачной сетью при помощи OpenVPN
    • Создание и настройка шлюза UserGate в режиме прокси-сервера
    • Создание и настройка шлюза UserGate в режиме межсетевого экрана
    • Настройка сети для Data Proc
  • Визуализация и анализ данных
    • Все руководства
    • Визуализация данных из файла
    • Создание и публикация диаграммы с картой Москвы из CSV-файла
    • Анализ продаж сети магазинов из БД ClickHouse
    • Анализ открытых данных ДТП на дорогах России
    • Анализ продаж и локаций пиццерий на данных из БД ClickHouse и Cloud Marketplace
    • Веб-аналитика с подключением к Яндекс Метрике
    • Веб-аналитика с расчетом воронок и когорт на данных Яндекс Метрики
    • Аналитика мобильного приложения на данных AppMetrica
    • Анализ статистики подкастов Яндекс Музыки (для авторов подкастов)
    • Визуализация данных с помощью QL-чарта
    • Анализ customer journey мобильного приложения на данных AppMetrica
    • Анализ логов Object Storage при помощи DataLens
  • Интернет вещей
    • Руководства по работе с интернетом вещей
    • Мониторинг состояния географически распределенных устройств
    • Мониторинг показаний датчиков и уведомления о событиях
  • Бессерверные технологии
    • Сокращатель ссылок
    • Ввод данных в системы хранения
    • Хранение журналов работы приложения
    • Развертывание веб-приложения с использованием Java Servlet API
    • Разработка Slack-бота
    • Разработка Telegram-бота
    • Разработка пользовательской интеграции в API Gateway
    • Разработка CRUD API для сервиса фильмов
    • Разработка навыка Алисы и сайта с авторизацией
  1. Управление инфраструктурой
  2. Непрерывное развертывание контейнеризованных приложений с помощью GitLab

Непрерывное развертывание контейнеризованных приложений с помощью GitLab

Статья создана
Yandex Cloud
  • Подготовьте облако к работе
    • Необходимые платные ресурсы
    • Установите дополнительные зависимости
  • Создайте ресурсы Managed Service for Kubernetes и Container Registry
    • Получите токен сервисного аккаунта Kubernetes для аутентификации в GitLab
  • Создайте инстанс GitLab
  • Настройте GitLab
  • Создайте тестовое приложение
  • Создайте GitLab Runner
  • Настройте сборку и развертывание Docker-образа из CI
  • Удалите созданные ресурсы
  • См. также

GitLab — инструмент непрерывной интеграции (Continuous integration, CI).

В этом руководстве описаны:

  • Сборка приложения в Docker-контейнер.
  • Развертывание приложения из контейнера в кластере Yandex Managed Service for Kubernetes через GitLab с помощью инструментов Yandex Cloud.

После каждого коммита в GitLab:

  • Выполнится сценарий, в котором описаны шаги сборки Docker-образа.
  • Применится новая конфигурация кластера Managed Service for Kubernetes, в которой будет указано приложение для развертывания.

Чтобы настроить необходимую инфраструктуру для хранения исходного кода, сборки Docker-образа и развертывания приложения:

  1. Подготовьте облако к работе.

    1. Изучите список необходимых платных ресурсов.

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

  2. Создайте ресурсы Managed Service for Kubernetes и Yandex Container Registry.

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

  4. Настройте GitLab.

  5. Создайте тестовое приложение.

  6. Создайте GitLab Runner.

  7. Настройте сборку и развертывание Docker-образа из CI.

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

Подготовьте облако к работе

Перед работой нужно зарегистрироваться в Yandex Cloud и создать платежный аккаунт:

  1. Перейдите в консоль управления, затем войдите в Yandex Cloud или зарегистрируйтесь, если вы еще не зарегистрированы.
  2. На странице биллинга убедитесь, что у вас подключен платежный аккаунт, и он находится в статусе ACTIVE или TRIAL_ACTIVE. Если платежного аккаунта нет, создайте его.

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

Подробнее об облаках и каталогах.

Необходимые платные ресурсы

В стоимость поддержки инфраструктуры входит плата за следующие ресурсы:

  • Диски и постоянно запущенные виртуальные машины (см. тарифы Yandex Compute Cloud).
  • Использование динамического публичного IP-адреса (см. тарифы Yandex Virtual Private Cloud).
  • Хранение созданных Docker-образов (см. тарифы Container Registry).
  • Использование мастера Managed Service for Kubernetes (см. тарифы Managed Service for Kubernetes).

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

Для выполнения сценария установите в локальном окружении:

  • Интерфейс командной строки Yandex Cloud (YC CLI).
  • Утилиту потоковой обработки JSON-файлов jq.
  • Менеджер пакетов Helm.

Создайте ресурсы Managed Service for Kubernetes и Container Registry

  1. Создайте кластер Managed Service for Kubernetes и реестр Container Registry.

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

    Для хранения Docker-образов вам понадобится реестр Container Registry.

    Вручную
    С помощью Terraform
    1. Если у вас еще нет сети, создайте ее.

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

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

      • С ролью editor на каталог, в котором создается кластер Managed Service for Kubernetes. От его имени будут создаваться ресурсы, необходимые кластеру Managed Service for Kubernetes.
      • С ролями container-registry.images.puller и container-registry.images.pusher. От его имени узлы будут загружать в реестр собранные в GitLab Docker-образы, а также скачивать их для запуска подов.

      Совет

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

    4. Создайте кластер Managed Service for Kubernetes и группу узлов со следующими настройками:

      • Сервисный аккаунт для ресурсов — созданный ранее сервисный аккаунт с ролью editor.
      • Сервисный аккаунт для узлов — созданный ранее сервисный аккаунт с ролями container-registry.images.puller и container-registry.images.pusher.
      • Версия Kubernetes — не ниже 1.21.
      • Публичный адрес — Автоматически.

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

    5. Создайте реестр.

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

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

    2. Скачайте файл с настройками провайдера. Поместите его в отдельную рабочую директорию и укажите значения параметров.

    3. Скачайте в ту же рабочую директорию файл конфигурации кластера k8s-gl.tf. В файле описаны:

      • Сеть.
      • Подсеть.
      • Группа безопасности и правила, необходимые для работы кластера Managed Service for Kubernetes:
        • Правила для служебного трафика.
        • Правила для доступа к API Kubernetes и управления кластером с помощью kubectl через порты 443 и 6443.
        • Правила для подключения к Git-репозиторию по протоколу SSH через порт 22.
        • Правила, разрешающие HTTP- и HTTPS-трафик через порты 80 и 443.
        • Правила для подключения к Container Registry через порт 5050.
      • Кластер Managed Service for Kubernetes.
      • Сервисный аккаунт, необходимый для работы кластера и группы узлов Managed Service for Kubernetes.
      • Реестр Container Registry.
    4. Укажите в файле конфигурации:

      • Идентификатор каталога.
      • Версию Kubernetes для кластера и групп узлов Managed Service for Kubernetes.
      • CIDR кластера Managed Service for Kubernetes.
      • Имя сервисного аккаунта кластера.
      • Имя реестра Container Registry.
    5. Выполните команду terraform init в директории с конфигурационными файлами. Эта команда инициализирует провайдер, указанный в конфигурационных файлах, и позволяет работать с ресурсами и источниками данных провайдера.

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

      terraform validate
      

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

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

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

        terraform plan
        

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

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

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

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

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

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

  2. Установите kubectl и настройте его на работу с созданным кластером.

Получите токен сервисного аккаунта Kubernetes для аутентификации в GitLab

Примечание

Сервисный аккаунт Kubernetes отличается от сервисного аккаунта Yandex Identity and Access Management.

Чтобы получить токен сервисного аккаунта Kubernetes:

  1. Настройте локальное окружение на работу с созданным кластером Kubernetes:

    yc managed-kubernetes cluster get-credentials <идентификатор или имя кластера> --external
    
  2. Сохраните спецификацию для создания сервисного аккаунта Kubernetes в YAML-файл gitlab-admin-service-account.yaml:

    gitlab-admin-service-account.yaml
    ---
    apiVersion: v1
    kind: ServiceAccount
    metadata:
      name: gitlab-admin
      namespace: kube-system
    ---
    apiVersion: rbac.authorization.k8s.io/v1beta1
    kind: ClusterRoleBinding
    metadata:
      name: gitlab-admin
    roleRef:
      apiGroup: rbac.authorization.k8s.io
      kind: ClusterRole
      name: cluster-admin
    subjects:
    - kind: ServiceAccount
      name: gitlab-admin
      namespace: kube-system
    
  3. Создайте сервисный аккаунт:

    kubectl apply -f gitlab-admin-service-account.yaml
    
  4. Узнайте токен сервисного аккаунта:

    kubectl -n kube-system get secrets -o json | \
    jq -r '.items[] | select(.metadata.name | startswith("gitlab-admin")) | .data.token' | \
    base64 --decode
    
  5. Сохраните полученный токен — он понадобится для следующих шагов.

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

Инстанс Yandex Managed Service for GitLab
ВМ с образом GitLab

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

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

  1. На странице каталога в консоли управления нажмите кнопку Создать ресурс и выберите Виртуальная машина.
  2. В поле Имя введите имя ВМ: ci-tutorial-gitlab.
  3. Выберите зону доступности, в которой будет находиться ВМ.
  4. В блоке Выбор образа/загрузочного диска перейдите на вкладку Cloud Marketplace и нажмите кнопку Посмотреть больше. В открывшемся окне выберите образ GitLab и нажмите кнопку Использовать.
  5. В блоке Вычислительные ресурсы укажите следующую конфигурацию:
    • vCPU — 4.
    • Гарантированная доля vCPU — 100%.
    • RAM — 8 ГБ.
  6. В блоке Сетевые настройки:
    • Выберите, к какой подсети подключить ВМ. Если нужной сети или подсети нет, создайте их с помощью кнопок Создать сеть и Добавить подсеть.

      Важно

      Технические ограничения Yandex Cloud временно не позволяют выбрать подсеть с диапазоном адресов 192.168.0.0/24.

    • В поле Публичный адрес выберите Автоматически.

  7. В блоке Доступ укажите данные для доступа на ВМ:
    • В поле Логин введите имя пользователя.

      Внимание

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

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

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

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

Настройте GitLab

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

Инстанс Managed Service for GitLab
Виртуальная машина с образом GitLab
  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.

Создайте тестовое приложение

Создайте тестовое приложение, которое можно будет развернуть в кластере Managed Service for Kubernetes:

  1. Добавьте в проект Dockerfile:
    1. Авторизуйтесь в GitLab.

    2. На главной странице выберите репозиторий.

    3. Выберите раздел Repository → Files.

    4. Нажмите кнопку + и в выпадающем меню выберите пункт New file.

    5. Назовите файл Dockerfile и добавьте в него код:

      FROM alpine:3.10
      CMD echo "Hello"
      
    6. Напишите комментарий к коммиту в поле Commit message: Dockerfile for test application.

    7. Нажмите кнопку Commit changes.

  2. Добавьте в проект манифест ресурсов кластера Managed Service for Kubernetes:
    1. Выберите раздел Repository → Files.

    2. Нажмите кнопку + и в выпадающем меню выберите пункт New file.

    3. Назовите файл k8s.yaml:

      apiVersion: v1
      kind: Namespace
      metadata:
        name: hello-world
      ---
      apiVersion: apps/v1
      kind: Deployment
      metadata:
        name: hello-world-deployment
        namespace: hello-world
      spec:
        replicas: 1
        selector:
          matchLabels:
            app: hello
        template:
          metadata:
            namespace: hello-world
            labels:
              app: hello
          spec:
            containers:
              - name: hello-world
                image: cr.yandex/<идентификатор реестра>/hello:__VERSION__
                imagePullPolicy: Always
      
    4. В поле <идентификатор реестра> укажите идентификатор созданного ранее реестра.

    5. Напишите комментарий к коммиту в поле Commit message: Docker image deployment config.

    6. Нажмите кнопку Commit changes.

Создайте GitLab Runner

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

  1. Подключите Helm-репозиторий, который содержит дистрибутив GitLab Runner:

    helm repo add gitlab https://charts.gitlab.io
    
  2. Узнайте настройки GitLab Runner:

    1. Откройте в браузере административную панель GitLab:
      • Если GitLab развернут на виртуальной машине Yandex Compute Cloud, используйте ее публичный IP-адрес.
      • Если GitLab развернут в сервисе Managed Service for GitLab, используйте FQDN инстанса.
    2. Выберите проект с именем gitlab-test.
    3. В открывшемся окне слева нажмите кнопку Settings и выберите пункт CI/CD.
    4. В блоке Runners нажмите кнопку Expand.
    5. Сохраните значения параметров URL и registration token — они понадобятся на следующем шаге.
  3. Создайте файл values.yaml, содержащий настройки GitLab Runner:

    values.yaml
    ---
    imagePullPolicy: IfNotPresent
    gitlabUrl: <публичный IP-адрес ВМ или FQDN инстанса Managed Service for GitLab>
    runnerRegistrationToken: "<registration token>"
    terminationGracePeriodSeconds: 3600
    concurrent: 10
    checkInterval: 30
    sessionServer:
     enabled: false
    rbac:
      create: true
      clusterWideAccess: true
      podSecurityPolicy:
        enabled: false
        resourceNames:
          - gitlab-runner
    runners:
      config: |
        [[runners]]
          [runners.kubernetes]
            namespace = "{{.Release.Namespace}}"
            image = "ubuntu:20.04"
            privileged = true
    
  4. Установите GitLab Runner с помощью команды:

    helm install --namespace default gitlab-runner -f values.yaml gitlab/gitlab-runner
    
  5. Дождитесь перехода пода GitLab Runner в состояние Running:

    kubectl get pods -n default | grep gitlab-runner
    

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

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

Настройте сборку и развертывание Docker-образа из CI

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

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

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

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

      • KUBE_URL — адрес мастера Kubernetes. Узнайте его с помощью команды:

        yc managed-kubernetes cluster get <идентификатор или имя кластера Kubernetes> --format=json \
          | jq -r .master.endpoints.external_v4_endpoint
        
      • KUBE_TOKEN — токен, который будет использовать GitLab для применения конфигурации. Используйте токен, полученный ранее.

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

      • Нажмите кнопку Add variable.
      • В появившемся окне в поле Key укажите имя переменной, в поле Value — значение переменной.
      • Нажмите кнопку Add variable.
  2. GitLab позволяет настраивать сценарии сборки в YAML-файле. Создайте файл конфигурации .gitlab-ci.yml:

    1. На панели слева в GitLab перейдите в раздел Repository и выберите вкладку Files.

    2. Справа от имени проекта нажмите кнопку + и в выпадающем меню выберите пункт New file.

    3. Назовите файл .gitlab-ci.yml. Добавьте в него шаги сборки и загрузки Docker-образа и обновления конфигурации приложения в кластере Kubernetes:

      stages:
        - build
        - deploy
      
      build:
        stage: build
        variables:
          DOCKER_DRIVER: overlay2
          DOCKER_TLS_CERTDIR: ""
          DOCKER_HOST: tcp://localhost:2375/
        image: cr.yandex/yc/metadata-token-docker-helper:0.2
        services:
          - docker:19.03.1-dind
        script:
          - docker build . -t cr.yandex/<идентификатор реестра>/hello:gitlab-$CI_COMMIT_SHORT_SHA
          - docker push cr.yandex/<идентификатор реестра>/hello:gitlab-$CI_COMMIT_SHORT_SHA
      
      deploy:
        image: gcr.io/cloud-builders/kubectl:latest
        stage: deploy
        script:
          - kubectl config set-cluster k8s --server="$KUBE_URL" --insecure-skip-tls-verify=true
          - kubectl config set-credentials admin --token="$KUBE_TOKEN"
          - kubectl config set-context default --cluster=k8s --user=admin
          - kubectl config use-context default
          - sed -i "s/__VERSION__/gitlab-$CI_COMMIT_SHORT_SHA/" k8s.yaml
          - kubectl apply -f k8s.yaml
      
    4. Замените в приведенном файле <идентификатор реестра> на идентификатор вашего реестра, созданного ранее.

    5. Напишите комментарий к коммиту в поле Commit message: CI scripts.

    6. Нажмите кнопку Commit changes.

    В файле .gitlab-ci.yml описаны два шага сборки проекта:

    • Сборка Docker-образа с использованием Dockerfile из предыдущего этапа и загрузка образа в Yandex Container Registry.
      • Для этого шага используйте контейнер для сборки Docker-образов и запустите Docker-сервер как GitLab-сервис.
      • Для аутентификации в Container Registry используйте сервисный аккаунт, подключенный к узлам Kubernetes. В начале работы этому аккаунту была назначена роль container-registry.images.pusher.
      • Чтобы получить из метаданных виртуальной машины данные для аутентификации, используется вспомогательный публичный Docker-образ cr.yandex/yc/metadata-token-docker-helper:0.2. Внутри него работает Docker credential helper, который получает Identity and Access Management-токен из сервиса метаданных.
    • Настройка окружения для работы с Kubernetes и применение конфигурации k8s.yaml к кластеру Kubernetes. Таким образом приложение развертывается на созданном ранее кластере.
  3. После сохранения файла запустится сценарий сборки. Чтобы посмотреть его выполнение, выберите в выпадающем меню пункт CI/CD → Pipelines. Дождитесь успешного завершения обоих этапов сборки.

  4. Проверьте результат, посмотрев логи контейнера в кластере Kubernetes:

    kubectl logs deployment/hello-world-deployment -n hello-world
    

    Результат:

    Hello
    

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

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

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

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

    Вручную
    С помощью Terraform
    1. Удалите кластер Managed Service for Kubernetes.
    2. Удалите реестр Container Registry.
    3. Удалите созданные подсети и сети.
    4. Удалите созданные сервисные аккаунты.
    1. В командной строке перейдите в директорию, в которой расположен актуальный конфигурационный файл Terraform с планом инфраструктуры.

    2. Удалите конфигурационный файл k8s-gl.tf.

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

      terraform validate
      

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

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

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

        terraform plan
        

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

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

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

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

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

      Все ресурсы, которые были описаны в конфигурационном файле k8s-gl.tf, будут удалены.

  3. Удалите созданную ВМ GitLab или инстанс Managed Service for GitLab.

См. также

  • Создание тестовых ВМ через GitLab CI.

Была ли статья полезна?

Language / Region
Проект Яндекса
© 2023 ООО «Яндекс.Облако»
В этой статье:
  • Подготовьте облако к работе
  • Необходимые платные ресурсы
  • Установите дополнительные зависимости
  • Создайте ресурсы Managed Service for Kubernetes и Container Registry
  • Получите токен сервисного аккаунта Kubernetes для аутентификации в GitLab
  • Создайте инстанс GitLab
  • Настройте GitLab
  • Создайте тестовое приложение
  • Создайте GitLab Runner
  • Настройте сборку и развертывание Docker-образа из CI
  • Удалите созданные ресурсы
  • См. также