GitLab Runner: docker, shell и kubernetes executor — три класса ошибок
Почему один и тот же GitLab job ведёт себя по-разному на docker, shell и kubernetes executor: registry, volume/cache, DNS, права и pod scheduling.
GitLab Runner — это машина или процесс, который реально выполняет ваш job. В .gitlab-ci.yml всё может выглядеть одинаково, но поведение сильно меняется от executor: docker, shell или kubernetes.
Если вы новичок или мидл, полезно думать так: YAML описывает намерение, а executor определяет окружение, где это намерение выполняется.
Коротко про executor
Docker executor запускает job в контейнере. Shell executor выполняет команды прямо на хосте runner'а. Kubernetes executor создаёт pod в кластере. Ошибка в логе часто говорит не только о коде, но и об этом окружении.
Docker executor: registry и filesystem
Типичные симптомы:
pull access denied;no basic auth credentials;Cannot connect to the Docker daemon;- артефакт есть в одном job, но исчез в другом.
Смотрите image name, registry URL, credentials, volumes и cache paths. Частая причина — токен registry истёк или runner не видит приватный image.
Shell executor: загрязнённый хост
Shell executor быстрый, но job наследует состояние машины:
- старые версии Node/Python/Java;
- файлы от прошлых запусков;
- права пользователя runner;
- локальный кэш, который «лечит» проблему только на одном хосте.
Если на shell runner «работает», а на docker нет, это не доказательство корректности. Это сигнал проверить окружение.
Kubernetes executor: сеть и scheduling
В Kubernetes чаще встречаются:
ImagePullBackOff;- DNS до registry или service;
- pod не стартует из-за resources;
- volume mount errors;
- service container не успел подняться.
Здесь лог job может быть коротким, а причина спрятана в событиях pod. Нужно смотреть Kubernetes events и описание pod, а не только GitLab UI.
Где тут Exlogare
Для RCA важно классифицировать падение: это код, dependency, runner или инфраструктура. Exlogare получает лог упавшего job и может подсветить тип проблемы в MR: например, «похоже на registry auth в docker executor», а не «тесты упали». Подключение описано в GitLab CI ingest.
Читайте также
- GitLab CI:
rules,workflowи почему job не запустился - Self-hosted runner vs shared runner: что меняется в логах CI
Чеклист
- Узнайте executor конкретного runner.
- Проверьте image pull и registry auth.
- Сравните runtime versions.
- Для shell runner проверьте состояние хоста.
- Для Kubernetes runner смотрите pod events.
- Не смешивайте infra failure и code regression в одном выводе.