Какие executors использовали для gitlab ci

Использование executor'ов в GitLab CI/CD

В GitLab CI/CD executor — это компонент GitLab Runner, который определяет среду выполнения для заданий (jobs). За годы работы с GitLab CI я использовал практически все доступные executor'ы, каждый из которых подходит для определённых сценариев. Выбор executor'а критически важен для производительности, безопасности и гибкости вашего пайплайна.

Основные типы executor'ов и их применение

Я разделил бы executor'ы на несколько категорий по их характеру и использованию в production-средах:

1. Docker (наиболее распространённый)

Этот executor использует контейнеры Docker для изоляции заданий. Он обеспечивает высокую воспроизводимость и быстрое создание сред.

# Пример конфигурации runner с Docker executor
[[runners]]
  name = "docker-runner"
  url = "https://gitlab.example.com"
  token = "TOKEN"
  executor = "docker"
  [runners.docker]
    image = "alpine:latest"
    privileged = false
    volumes = ["/cache", "/builds:/builds:rw"]

Преимущества:

• Идемпотентность: каждый job запускается в чистом контейнере
• Быстрое развёртывание: контейнеры запускаются за секунды
• Лёгкое кэширование: можно кэшировать слои образов
• Поддержка Docker-in-Docker для сборки образов

Недостатки:

• Требует установленного Docker на хосте
• Может быть медленнее для очень тяжёлых образов

2. Shell

Запускает задания непосредственно на хосте runner'а. Использовал для специфических задач, где нужен прямой доступ к оборудованию.

# Конфигурация runner с shell executor
[[runners]]
  name = "shell-runner"
  url = "https://gitlab.example.com"
  token = "TOKEN"
  executor = "shell"
  [runners.custom_build_dir]
    enabled = true

Сценарии использования:

• Развёртывание на физических серверах
• Работа с аппаратным обеспечением
• Задачи, требующие специфических драйверов ОС

3. Kubernetes

Запускает задания как поды в кластере Kubernetes. Современный подход для cloud-native сред.

# Часть конфигурации для Kubernetes executor
[[runners]]
  name = "k8s-runner"
  url = "https://gitlab.example.com"
  token = "TOKEN"
  executor = "kubernetes"
  [runners.kubernetes]
    namespace = "gitlab-runner"
    image = "alpine:latest"
    [runners.kubernetes.node_selector]
      "node-type" = "ci"

Преимущества:

• Автоматическое масштабирование подов
• Изоляция на уровне Kubernetes
• Интеграция с service accounts и секретами Kubernetes
• Эффективное использование ресурсов кластера

4. VirtualBox/Parallels

Использовал в средах, где нужны полные виртуальные машины для тестирования на разных ОС.

Особые случаи:

• Тестирование установщиков ПО
• Кросс-платформенная сборка
• Тестирование на разных версиях Windows/Linux

5. Custom (собственные реализации)

В одном проекте мы создали кастомный executor для интеграции с выделенным GPU-кластером для ML-задач.

Сравнительная таблица executor'ов

Практические рекомендации по выбору

1. Для большинства современных проектов я рекомендую комбинацию:

   • Docker executor для сборки и тестирования
   • Kubernetes executor для production-пайплайнов в cloud-средах
   • Shell executor на отдельных runner'ах для специфичных задач развёртывания

2. Кэширование по-разному работает с разными executor'ами:

   # Пример кэширования в Docker executor
   cache:
     key: ${CI_COMMIT_REF_SLUG}
     paths:
       - node_modules/
       - .cache/
     policy: pull-push
   

3. Безопасность: Docker и Kubernetes executor'ы обеспечивают лучшую изоляцию, тогда как shell executor требует особых мер безопасности.

4. Гибридные конфигурации: Часто настраивал несколько runner'ов с разными executor'ами, тегируя их для разных типов задач:

   # Регистрация runner с тегами
   gitlab-runner register --tag-list "docker,aws" --executor "docker"
   gitlab-runner register --tag-list "shell,deploy" --executor "shell"
   

Проблемы и их решения

С каждым executor'ом сталкивался с характерными проблемами:

• Docker: Проблемы с Docker socket mounting и безопасностью. Решение: использование Docker-in-Docker с отдельным Docker daemon.
• Kubernetes: Сложности с persistent volumes для кэширования. Решение: настройка ReadWriteMany томов или использование S3-совместимого кэша.
• Shell: Загрязнение среды между заданиями. Решение: тщательная очистка в after_script и использование отдельных runner'ов для разных проектов.

В современных DevOps-стеках я чаще всего вижу переход к Kubernetes executor'у как наиболее отказоустойчивому и масштабируемому решению, особенно в сочетании с GitLab Auto Scaling для динамического управления runner'ами в ответ на нагрузку CI/CD.