# Запуск пайплайнов из .gitlab-ci.yml в GitLab Runners

## Обзор CI/CD Pipeline в GitLab

* **`.gitlab-ci.yml`:** Файл в корне репозитория, определяющий конфигурацию CI/CD pipeline.
    * Состоит из набора **stages** (этапов), которые выполняются последовательно (по умолчанию).
    * Каждый stage содержит один или несколько **jobs** (заданий), которые выполняются параллельно на доступных Runners.
    * **Jobs** определяют конкретные действия, такие как сборка, тестирование, развертывание.

## GitLab Runner: исполнитель задач CI/CD

* **Что такое GitLab Runner?** Агент, который запускает задачи (jobs), определенные в `.gitlab-ci.yml`.
* **Типы GitLab Runners:**
    * **Shared Runners:** Доступны для всех проектов в GitLab instance. Управляются администратором GitLab.
    * **Group Runners:** Доступны для всех проектов в определенной группе. Управляются администраторами группы.
    * **Specific Runners:** Назначаются конкретным проектам. Управляются владельцами проектов или администраторами.
* **Executor:** Определяет, как Runner выполняет задачи. Наиболее распространенные:
    * **shell:** Выполняет скрипты непосредственно на машине Runner.
    * **docker:** Запускает каждое задание в отдельном Docker-контейнере. Обеспечивает изолированность и воспроизводимость.
    * **kubernetes:** Запускает задания как Pods в кластере Kubernetes.
    * **virtualbox, parallels, ssh, docker-ssh, custom:** Другие варианты для специфических сценариев.

## Как GitLab Runner "подхватывает" пайплайны?

1. **События в репозитории:** Пайплайн запускается автоматически при определенных событиях (push нового кода, создание Merge Request, merge, расписание и т.д.) или вручную.
2. **GitLab CI/CD Coordinator:** Компонент GitLab Server, который обрабатывает события и создает пайплайны на основе `.gitlab-ci.yml`.
3. **Ожидание Runner'а:** GitLab CI/CD Coordinator ищет доступного Runner'а, который соответствует требованиям задания (теги, executor).
4. **Выбор Runner'а:** Когда подходящий Runner найден, GitLab CI/CD Coordinator передает ему информацию о задании.
5. **Выполнение задания:** Runner получает задание и выполняет шаги, определенные в секции `script` этого задания, используя настроенный executor.
6. **Отчет о статусе:** Runner отправляет отчет о статусе выполнения задания обратно в GitLab CI/CD Coordinator.
7. **Продолжение пайплайна:** В зависимости от статуса задания (success, failed), запускаются следующие этапы или задания в текущем этапе.

## Ключевые аспекты `.gitlab-ci.yml`, влияющие на запуск на Runner'ах:

* **`stages`:** Определяют последовательность выполнения этапов.
* **`jobs`:** Определяют конкретные задачи для выполнения.
    * **`stage`:** Указывает, к какому этапу относится задание.
    * **`script`:** Содержит команды, которые будут выполнены Runner'ом.
    * **`tags`:** Метки, которые используются для выбора подходящих Runner'ов. Runner должен иметь хотя бы одну из указанных меток.
    * **`only` / `except`:** Определяют, при каких условиях (ветки, теги, события) должно выполняться задание.
    * **`image`:** (Для Docker executor) Определяет Docker-образ, который будет использоваться для выполнения задания.
    * **`services`:** (Для Docker executor) Определяет сервисы, которые будут запущены вместе с основным контейнером задания.
    * **`before_script` / `after_script`:** Скрипты, выполняемые до и после основного скрипта задания.
    * **`artifacts`:** Файлы или директории, которые будут сохранены после выполнения задания.
    * **`cache`:** Настройка кэширования зависимостей между заданиями и пайплайнами.

## Регистрация и настройка GitLab Runner'а:

1. **Установка GitLab Runner:** Загрузка и установка пакета GitLab Runner на целевой машине (физической или виртуальной).
2. **Регистрация Runner'а:** Связывание установленного Runner'а с конкретным GitLab instance, группой или проектом с помощью команды `gitlab-runner register`.
    * Необходимо указать URL GitLab instance и регистрационный токен (можно найти в настройках CI/CD).
    * Выбор executor'а.
    * Ввод тегов для Runner'а.
    * Другие настройки (например, concurrency - количество параллельных заданий).
3. **Настройка Runner'а:** Редактирование конфигурационного файла `config.toml` для более тонкой настройки (например, лимиты ресурсов, настройки Docker).
4. **Запуск и управление Runner'ом:** Использование команд `gitlab-runner start`, `gitlab-runner stop`, `gitlab-runner restart`, `gitlab-runner status`.

## Принцип работы выбора Runner'а:

* Когда запускается пайплайн, GitLab CI/CD Coordinator ищет активных Runner'ов.
* Для каждого задания в пайплайне Coordinator пытается найти Runner, который:
    * Не занят выполнением другого задания (если достигнут лимит concurrency).
    * Имеет хотя бы одну из меток, указанных в секции `tags` задания (если теги указаны).
    * Совместим с требованиями задания (например, executor).
* Если подходящий Runner найден, задание назначается ему для выполнения.
* Если подходящих Runner'ов нет, задание остается в состоянии "pending" до тех пор, пока Runner не станет доступен.

## Лучшие практики:

* **Используйте теги:** Четко определяйте теги для Runner'ов и заданий, чтобы обеспечить выполнение заданий на подходящих ресурсах.
* **Оптимизируйте `.gitlab-ci.yml`:** Делайте пайплайны эффективными, используйте кэширование, параллельное выполнение заданий.
* **Мониторинг Runner'ов:** Следите за состоянием Runner'ов, их загрузкой и доступностью.
* **Используйте Docker executor (рекомендуется):** Обеспечивает изоляцию и воспроизводимость окружения выполнения заданий.
* **Настраивайте concurrency:** Определите оптимальное количество параллельных заданий для каждого Runner'а в зависимости от его ресурсов.

## Заключение:

Понимание того, как GitLab CI/CD Coordinator взаимодействует с GitLab Runners и как `.gitlab-ci.yml` определяет выполнение пайплайнов, является ключевым для эффективной автоматизации процессов разработки и доставки программного обеспечения. Правильная настройка Runner'ов и конфигурация пайплайнов позволяют максимально использовать возможности GitLab CI/CD.