Взаимосвязь ресурсов в Managed Service for GitLab

GitLab — это веб-инструмент жизненного цикла DevOps с открытым исходным кодом. Он представляет собой систему управления репозиториями кода для Git с системой отслеживания ошибок, CI/CD пайплайном, собственной Wiki и другими функциями.

Managed Service for GitLab позволяет настроить развертывание приложений на виртуальных машинах Yandex Compute Cloud, а также поддерживает интеграцию с Yandex Container Registry и Yandex Managed Service for Kubernetes.

Схема работы Managed Service for GitLab:

Инстанс GitLabИнстанс GitLab

Инстанс GitLab — основная сущность, которой оперирует сервис. Это ВМ, размещенная в Yandex Cloud. Managed Service for GitLab берет на себя рутинные операции по техническому обслуживанию этой ВМ, например, обеспечение отказоустойчивости хранилища, установку обновлений безопасности, автоматизированное обновление до новых версий GitLab и т. д.

Пользователь может управлять инстансами с помощью консоли управления Yandex Cloud, CLI и API.

Конфигурация инстансаКонфигурация инстанса

При создании инстанса указываются:

• Тип инстанса — количество ядер (vCPU) и объем памяти (RAM). Доступные типы инстансов:

  Тип	Вычислительные ресурсы
  s2.micro	2 vCPU, 8 ГБ RAM
  s2.small	4 vCPU, 16 ГБ RAM
  s2.medium	8 vCPU, 32 ГБ RAM
  s2.large	16 vCPU, 64 ГБ RAM

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

• Подсеть.

  Важно

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

• Размер диска. После создания инстанса размер его диска можно увеличить.

• Имя в домене .gitlab.yandexcloud.net — адрес вашего экземпляра GitLab в интернете.

• Данные администратора:

  • Электронная почта.
  • Логин.

GitLab RunnerGitLab Runner

GitLab Runner — приложение с открытым исходным кодом, которое выполняет задания конвейерной обработки GitLab CI/CD по инструкциям из специального файла .gitlab-ci.yml. Оно позволяет запускать автоматизированные сборки внутри кластеров Managed Service for Kubernetes и на виртуальных машинах Compute Cloud.

Начать работу с GitLab Runner можно следующими способами:

• Установить GitLab Runner в кластер Managed Service for Kubernetes.
• Создать виртуальную машину Compute Cloud и вручную установить на нее GitLab Runner.
• Создать раннер, управляемый Yandex Cloud.

Управляемые раннерыУправляемые раннеры

В сервисе Managed Service for GitLab вы можете создать управляемый раннер, который автоматически разворачивает указанное число виртуальных машин Compute Cloud с установленными воркерами GitLab. Также управляемый раннер обеспечивает горизонтальное масштабирование ВМ с воркерами в зависимости от нагрузки.

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

• Настройки масштабирования:

  • Минимум воркеров — число воркеров, которые всегда запущены и готовы выполнять задачи. Значение по умолчанию — 1, минимальное — 0, максимальное — 10.
  • Максимум воркеров — максимальное число воркеров, которые могут быть созданы для выполнения задач. Значение по умолчанию — 3, минимальное — 1, максимальное — 30. Максимальное количество воркеров не может быть меньше минимального.
  • Лимит простоя воркера, в минутах — максимальное время простоя, по истечении которого дополнительно созданный воркер будет удален. Значение по умолчанию — 10, минимальное — 0.
  • Максимум задач на воркер — максимальное количество задач, после выполнения которых воркер будет удален. Значение по умолчанию — 100, минимальное — 0.
  • Количество параллельных задач на воркер — количество задач, которые выполняются на одном воркере одновременно. Значение по умолчанию — 1, минимальное — 0.

• Параметры ВМ с воркером:

  • Конфигурация вычислительных ресурсов воркера:

    • 2 vCPU, 4 ГБ RAM.
    • 2 vCPU, 8 ГБ RAM.
    • 4 vCPU, 16 ГБ RAM.
    • 8 vCPU, 64 ГБ RAM.
    • 16 vCPU, 128 ГБ RAM.

  • Тип (HDD или SSD) и объем диска. Подробнее см. в разделе Типы дисков.

  • Сервисный аккаунт.

    Примечание

    Этот сервисный аккаунт будет привязан к ВМ с воркером. С помощью него воркер сможет аутентифицироваться в API Yandex Cloud и взаимодействовать с облачными ресурсами.

    Назначьте сервисному аккаунту роль на ресурс, с которым вы хотите работать.

  • Группа безопасности.

Подробнее о работе с управляемыми раннерами см. на страницах:

• Работа с управляемым раннером
• Развертывание GitLab Runner на виртуальной машине Yandex Compute Cloud

Сетевое взаимодействие между GitLab и управляемыми раннерамиСетевое взаимодействие между GitLab и управляемыми раннерами

Подсеть инстанса, к которому подключен управляемый раннер, должна иметь доступ в интернет (через NAT-шлюз или NAT-инстанс).

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

Правила для входящего трафикаПравила для входящего трафика

Зачем нужно правило	Настройки правила
Для управления раннером с инстанса GitLab по протоколу SSH. Обязательное правило.	Диапазон портов — 22. Протокол — TCP. Источник — CIDR. CIDR блоки — CIDR всех подсетей, где могут запускаться раннеры. Вместо CIDR вы можете указать группу безопасности, созданную для раннеров.

Правила для исходящего трафикаПравила для исходящего трафика

Зачем нужно правило	Настройки правила
Для взаимодействия с публичным адресом инстанса GitLab по протоколу HTTPS (например, для клонирования репозиториев, загрузки артефактов). Обязательное правило.	Диапазон портов — 443. Протокол — TCP. Источник — CIDR. CIDR блоки — публичный адрес GitLab.
Для доступа к реестру артефактов (например, Cloud Registry, dockerhub.io). Рекомендуемое правило.	Диапазон портов — 443, 5000 или другой. Протокол — TCP. Источник — CIDR. CIDR блоки — CIDR реестров, к которым предоставляется доступ. Чтобы разрешить трафик на любые IP-адреса, укажите 0.0.0.0/0.
Для доступа к объектным хранилищам (например, LFS, Container Registry). Рекомендуемое правило.	Диапазон портов — 443. Протокол — TCP. Источник — CIDR. CIDR блоки — CIDR объектных хранилищ, к которым предоставляется доступ. Чтобы разрешить трафик на любые IP-адреса, укажите 0.0.0.0/0.
Для доступа к внешним ресурсам. Опциональное правило.	Диапазон портов — 443, 80 или другой. Протокол — TCP. Источник — CIDR. CIDR блоки — CIDR внешних ресурсов. Если список ресурсов не определен, можно разрешить исходящий трафик к любым адресам (CIDR — 0.0.0.0/0) через все порты. В этом случае можно пропустить настройку рекомендуемых правил и настройку доступа из управляемого раннера к публичному адресу инстанса GitLab.

GitLab PagesGitLab Pages

GitLab Pages — инструмент для публикации статических сайтов на основе файлов, расположенных в репозитории GitLab. Сайты разворачиваются по заданиям GitLab CI/CD. GitLab Pages работает с генераторами статических сайтов и обычными файлами HTML, CSS и JavaScript.

GitLab Pages позволяет использовать собственные домены и сертификаты SSL/TLS, а также настраивать доступ к сайтам.

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

Примеры использованияПримеры использования

• Безопасное хранение паролей для GitLab CI в виде секретов Yandex Lockbox
• Построение пайплайна CI/CD с использованием serverless-продуктов
• Развертывание GitLab Runner на виртуальной машине Yandex Compute Cloud
• Непрерывное развертывание контейнеризованных приложений Managed Service for Kubernetes