Настройка GitLab Runner и структура .gitlab-ci.yml

Курс: DevOps с нуля: Путь к автоматизации и CI/CD16+

Мы уже разобрались, что такое CI/CD: непрерывная интеграция, доставка и развертывание позволяют нам автоматизировать сборку, тестирование и выпуск кода. Это экономит время, уменьшает ошибки и делает процесс предсказуемым.

Но как эти процессы на самом деле происходят в GitLab?
Кто выполняет команды, которые мы описываем в пайплайне?
И где хранится инструкция для автоматизации?

Сегодня мы переходим от теории к практике.
Мы настроим GitLab Runner — исполнителя всех задач — и напишем первый файл .gitlab-ci.yml, который определит, что и как будет выполняться.

GitLab Runner: двигатель вашего CI/CD

Когда вы делаете git push, GitLab узнаёт об этом и хочет запустить пайплайн.
Но сам GitLab не выполняет команды — он лишь координирует процесс.

За выполнение отвечает GitLab Runner — отдельный агент, установленный на сервере, в контейнере или в облаке.
Он "слушает" GitLab, получает задания и выполняет их.

💡 GitLab Runner — это исполнитель задач в CI/CD.
Без него пайплайн — просто текст в файле. Он не запустится.

Runner может работать в разных режимах, называемых executor:

shell — запускает команды напрямую на хосте (подходит для тестов, но не для продакшена)
docker — запускает каждую задачу в отдельном контейнере (рекомендуется)
kubernetes — запускает задачи в Pod'ах (для сложных сред)

В 2025 году Docker-исполнитель — стандарт де-факто. Он обеспечивает изоляцию, воспроизводимость и безопасность.

Как зарегистрировать GitLab Runner

Чтобы Runner мог работать с вашим проектом, его нужно зарегистрировать.

Шаг 1: Получите токен регистрации

Перейдите в свой проект в GitLab
Откройте Settings → CI/CD → Runners
Скопируйте token из раздела "Set up a project runner manually"

🔐 Этот токен даёт доступ к вашему проекту. Храните его в безопасности.

Шаг 2: Установите и зарегистрируйте Runner

Если у вас есть сервер или ВМ с Linux, выполните:

# Установка (для Ubuntu/Debian)
sudo apt-get update
sudo apt-get install gitlab-runner

# Регистрация
sudo gitlab-runner register

При регистрации укажите:

URL GitLab: https://gitlab.com (или ваш внутренний URL)
Токен: скопированный ранее
Имя: например, python-ci-runner
Executor: выберите docker
Docker image: alpine:latest (или python:3.11 для Python-проектов)

✅ После регистрации Runner появится в интерфейсе GitLab и будет готов к работе.

.gitlab-ci.yml: рецепт вашего пайплайна

Файл .gitlab-ci.yml — это декларативное описание всего CI/CD-процесса.
Он лежит в корне репозитория и читается GitLab при каждом push.

Представьте его как рецепт приготовления блюда:

Этапы (stages) — шаги: маринование, жарка, подача
Задачи (jobs) — конкретные действия: нарезать лук, включить духовку

Основные элементы

Элемент	Описание
`pipeline`	Весь процесс CI/CD от начала до конца
`stage`	Этап пайплайна: например, `test`, `build`, `deploy`
`job`	Конкретная задача, выполняемая на одном из этапов
`script`	Команды, которые Runner выполнит в рамках job
`before_script`	Команды, которые выполняются перед каждым job (подготовка)

Простой пример: Hello CI

Создадим минимальный пайплайн, который выводит сообщение.

# .gitlab-ci.yml

stages:
  - test

run_hello_job:
  stage: test
  script:
    - echo "Hello from CI!"
    - python --version

Что здесь происходит:

Определяем один этап: test
Создаём job с именем run_hello_job
В script указываем команды: вывести текст и проверить версию Python

Если вы сделаете git push, GitLab запустит этот пайплайн, и Runner выполнит команды.

Где и как выполняются команды?

Поскольку мы выбрали Docker executor, каждая задача запускается в контейнере на основе образа python:3.11.

Это значит:

Все команды выполняются в изолированной среде
Установленный Python, pip, зависимости — всё внутри контейнера
После выполнения контейнер удаляется

🔄 Это обеспечивает воспроизводимость: пайплайн будет работать одинаково на любом сервере.

Используем before_script для подготовки

Допустим, у нас есть Python-скрипт, и перед запуском нужно установить зависимости.

stages:
  - test

run_tests:
  stage: test
  before_script:
    - pip install -r requirements.txt
  script:
    - python test_app.py

Важно понимать:

before_script выполняется в каждом job отдельно
Он не влияет на другие задачи — каждый job изолирован

❌ Ошибка: думать, что before_script выполняется один раз на весь пайплайн.
✅ Правильно: он запускается перед каждым job, даже если их несколько.

Управление запуском: правила (rules)

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

Например, запускать тесты только при пуше в ветку main:

run_tests:
  stage: test
  script:
    - python -m pytest
  rules:
    - if: $CI_COMMIT_BRANCH == "main"

Или запускать только при создании Merge Request:

rules:
  - if: $CI_PIPELINE_SOURCE == "merge_request_event"

💡 Правила помогают избежать лишних запусков и экономят ресурсы.

Практическое задание

Цель: настроить Runner и запустить пайплайн.

Шаг 1: Установите и зарегистрируйте Runner

Используйте сервер или локальную машину с Linux
Выберите executor docker
Укажите образ python:3.11

Шаг 2: Создайте в репозитории файл `.gitlab-ci.yml`

stages:
  - setup
  - test

install_deps:
  stage: setup
  before_script:
    - echo "Preparing environment..."
  script:
    - pip install pytest
  rules:
    - if: $CI_COMMIT_BRANCH == "main"

run_tests:
  stage: test
  script:
    - echo "Running tests..."
    - python -c "print('Test passed!')"
  rules:
    - if: $CI_COMMIT_BRANCH == "main"

Шаг 3: Сделайте push и проверьте пайплайн

Перейдите в GitLab → CI/CD → Pipelines
Убедитесь, что пайплайн запустился и прошёл

✅ Если всё работает — вы только что создали настоящий CI-процесс!

Что дальше?

Теперь вы умеете:

Настроить GitLab Runner — исполнителя задач
Написать .gitlab-ci.yml — инструкцию для пайплайна
Определить stages, jobs, script и before_script
Контролировать запуск с помощью rules

Но в реальных проектах пайплайны используют секреты: пароли, токены доступа, ключи API.
Хранить их прямо в коде — категорически нельзя.

В следующей теме мы научимся безопасно работать с переменными и секретами в GitLab CI/CD.
Вы узнаете, как использовать CI/CD Variables, передавать артефакты между этапами и хранить данные без риска утечки.

🔐 Уже скоро вы сможете автоматизировать даже самые чувствительные процессы — безопасно и профессионально.

Готовы к следующему шагу?
Тогда вперёд — к мастерству DevOps! 🚀