Runner — процесс-агент, который принимает задания от CI/CD-сервера и выполняет их в изолированном окружении. В GitLab CI это GitLab Runner, в GitHub Actions — GitHub Actions Runner, в CircleCI — CircleCI Executor. Понятие общее для всех CI/CD-систем.
Как работает
Runner регистрируется в CI/CD-системе через токен. Затем опрашивает сервер (polling) на наличие заданий. При получении задания: клонирует репозиторий, выполняет команды из конфига пайплайна, отправляет артефакты и результаты обратно на сервер.
Executor определяет среду выполнения: Docker (контейнер создаётся и уничтожается для каждого job), Shell (напрямую на ОС runner), Kubernetes (job запускается как Pod), VirtualBox (полная VM). Docker executor наиболее популярен: полная изоляция, воспроизводимость.
GitLab Runner устанавливается: curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh | sudo bash && sudo apt install gitlab-runner. Регистрация: gitlab-runner register.
История
Концепция CI-агентов существует с Jenkins (Hudson, 2004) — тогда они назывались slaves/nodes. GitLab Runner выпущен в 2015 году как замена GitLab CI coordinator. GitHub Actions запустился в 2018 году с hosted runners. Self-hosted runners как концепция активно развивается с 2019 года для корпоративных требований к безопасности.
Shared vs Self-hosted
- Shared runner: предоставлен провайдером, бесплатен или платен по минутам, не нужно настраивать.
- Self-hosted runner: на своём сервере, неограниченные минуты, доступ к внутренней сети, нужна настройка.
Связь с хостингом
Self-hosted runner устанавливается на VPS или выделенный сервер. Преимущества: доступ к приватным ресурсам (внутренние реестры, базы данных), нет лимита минут, кастомное ПО в окружении. GitLab Runner на собственном сервере позволяет деплоить в приватную инфраструктуру без VPN.
Ключевые отличия от похожих терминов
CI/CD пайплайн — описание процесса. Runner — исполнитель этого описания. Job — конкретное задание в рамках пайплайна. Worker — более общий термин для процесса, выполняющего фоновые задачи (не обязательно CI/CD).
Self-hosted Runner
Self-hosted runner — агент CI/CD на собственной инфраструктуре. GitHub Actions runner: устанавливается на сервер за 5 минут. Преимущества: доступ к внутренней сети, специфичное ПО, экономия минут. Минус: сопровождение и безопасность на стороне пользователя.
GitLab Runner
GitLab Runner — наиболее гибкий: Docker executor (запуск в контейнере), Shell executor (прямо на хосте), Kubernetes executor (pods). gitlab-runner register → URL, токен, executor. Масштабирование: несколько runners под один GitLab проект. Autoscaling через Docker Machine (устарело) или Kubernetes.
Безопасность runners
Secrets в CI/CD хранятся в переменных (GitHub Secrets, GitLab Variables). В конфиге — только имена переменных, не значения. Shared runners для публичных репозиториев — не передавать им чувствительные переменные. Для production: dedicated self-hosted runner в изолированном окружении.
GitHub Actions Runner Scale Sets
Actions Runner Controller (ARC): Kubernetes-оператор для автомасштабирования self-hosted runners. Создаёт runner Pod при появлении задачи, удаляет после завершения. Ephemeral runners: каждая задача — чистое окружение. Стоимость: Kubernetes кластер vs фиксированные VPS. Оптимально для непостоянной CI-нагрузки.
CI/CD-раннеры выполняют пайплайны для Docker-сборок, тестов, деплоев. Self-hosted на VPS: доступ к приватной сети. Используют SSH-ключи для деплоя. Kubernetes executor создаёт Pod per task. CD автоматизирует деплой на серверы.