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

А, ну это же про регистрацию раннера в GitLab! Давай разберем, тут всё просто, как три копейки, если не накосячить на ровном месте.

1. Ставим самого бегуна (GitLab Runner): Тут всё зависит от того, на какой системе сидишь. Команды стандартные, главное — не перепутать, а то потом будешь сидеть и думать, какого хуя ничего не работает.

# Если у тебя Ubuntu или что-то подобное (Debian)
curl -L "https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh" | sudo bash
sudo apt-get install gitlab-runner

# А если RHEL, CentOS или Fedora — тогда вот так
curl -L "https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.rpm.sh" | sudo bash
sudo yum install gitlab-runner

Поставил? Отлично. Теперь самое интересное — заставить эту штуку работать на нас.

2. Регистрируем этого товарища: Тут уже начинается магия. Запускаешь команду регистрации, и она тебя по пунктам проведёт.

sudo gitlab-runner register

Тебе начнут задавать вопросы, как на допросе. Отвечай честно.

• URL GitLab instance: Если используешь облачный GitLab.com — так и пиши https://gitlab.com. Если свой, локальный — его адрес.
• Registration token: Вот это, бля, важный момент! Токен надо брать прямо из интерфейса GitLab. Идёшь в Settings -> CI/CD -> Runners, ищешь там раздел "Set up a specific Runner manually" — вот там он и лежит, этот самый ключ. Для групповых или проектных раннеров токены свои, в соответствующих местах. Не перепутай, а то будет тебе ебать-копать, пока разберёшься.
• Description: Ну тут понятно, назови его как душе угодно. Типа docker-runner-for-backend.
• Tags (опционально): Это такие метки, чтобы потом в пайплайне указывать, на каком именно раннере запускать job. Например, docker, linux, x86. Удобная штука, если раннеров овердохуища.
• Executor: А вот тут надо подумать. Выбираешь среду исполнения.
  • docker — классика, изоляция в контейнерах. Я его чаще всего юзаю, надёжно.
  • kubernetes — если хочешь запускать джобы прямо в K8s кластере. Для продвинутых.
  • shell — самый простой, но и самый опасный. Скрипты выполняются прямо на хосте, так что доверия ебать ноль, если не уверен в безопасности.

3. Глянем на конфиг (обычно /etc/gitlab-runner/config.toml): После регистрации там появится запись. Выглядит примерно так, можешь под себя подкрутить:

concurrent = 4
check_interval = 0

[[runners]]
  name = "production-docker-runner"
  url = "https://gitlab.com"
  token = "glrt-xxxxxxxxxxxxxxxx"
  executor = "docker"
  [runners.docker]
    tls_verify = false
    image = "alpine:latest"
    privileged = false
    disable_entrypoint_overwrite = false
    oom_kill_disable = false
    disable_cache = false
    volumes = ["/cache", "/var/run/docker.sock:/var/run/docker.sock"]
    shm_size = 0
  [runners.cache]
    [runners.cache.s3]
    [runners.cache.gcs]

4. Практический пример из боевых условий: Однажды пришлось регистрировать раннер прямо в Kubernetes. Сделал это через Helm chart, и всё взлетело с первого раза, что было удивление пиздец.

helm upgrade --install gitlab-runner gitlab/gitlab-runner 
  --namespace gitlab-runner 
  --set "gitlabUrl=https://gitlab.example.com" 
  --set "runnerRegistrationToken=GR1348941nBhuynDxmJCMttrsTox" 
  --set "rbac.create=true" 
  --set "runners.tags=kubernetes,production"

После всех этих телодвижений твой раннер должен появиться в списке в GitLab. Всё, он готов пахать. Чтобы заставить его выполнять конкретную работу, в твоём .gitlab-ci.yml просто укажи нужные теги:

build:
  stage: build
  tags:
    - docker
    - linux
  script:
    - docker build -t app:latest .

Вот и вся наука. Главное — токен правильно взять и executor не промахнуться, а дальше уже дело техники.