Для того, чтобы настроить свой gitlab runner, используется config.toml файл. У вас его не будет, если вы не используете свои собственные gitlab-раннеры, и в этом случае он будет находиться в /etc/gitlab/config.toml на хосте, на котором запущен раннер.

Вы можете изменить поведение GitLab Runner и отдельных зарегистрированных раннеров, изменяя файл config.toml.

GitLab Runner не требует перезапуска при изменении большинства параметров. Сюда входят параметры в разделе [[runners]] и большинство параметров в глобальном разделе, за исключением listen_address. Если раннер уже был зарегистрирован, вам не нужно регистрировать его снова.

GitLab Runner проверяет изменения конфигурации каждые 3 секунды и при необходимости перезагружается. GitLab Runner также перезагружает конфигурацию в ответ на сигнал SIGHUP.

Вы можете найти файл config.toml в:

  • /etc/gitlab-runner/ в системах *nix, когда GitLab Runner выполняется от имени пользователя root (это также путь для настройки службы)
  • ~/.gitlab-runner/ в системах *nix, когда GitLab Runner выполняется без полномочий root
  • ./ в других системах

В файле предусмотрены глобальные секции[session_server] и секции, относящиеся к конкретному раннеру: [[runners]] и подсекции конфигурации каждого раннера, например, [runners.docker]. Секция [session_server] указывается на корневом уровне файла и позволяет пользователям взаимодействовать с джобами. Удаление этой секции выключает данную возможность.

Также на глобальном уровне можно указать ряд настроек, таких как listen_address для сборка метрик сервером Prometheus.

Раннеры и эксзекьюторы

В секции [[runners]]указывается раннеры: одна секция — один раннер. Одна из главных общих настроек раннера — executor — указывает, как проект будет собираться. Доступны следующие экзекуторы:

ExecutorТребуемая конфигурацияГде исполняются jobs
shellЛокальный shell. Дефолтный executor.
docker[runners.docker] и Docker EngineDocker контейнер.
docker-windows[runners.docker] и Docker EngineWindows Dockerконтейнер.
docker-ssh[runners.docker][runners.ssh], и Docker EngineDocker контейнер, но с подключением по SSH. The Docker контейнер исполняется на локальной машине. Эта настройка меняет, как команды запускаются внутри контейнера. Если вы хотите запускать docker команды на внешней машине, поменяйте параметр  host в секции runners.docker.
ssh[runners.ssh]SSH, удаленно.
parallels[runners.parallels] и [runners.ssh]Parallels VM, подключение по SSH.
virtualbox[runners.virtualbox] и [runners.ssh]VirtualBox VM, подключение по SSH.
docker+machine[runners.docker] и [runners.machine]Как docker, но использует auto-scaled Docker machines.
docker-ssh+machine[runners.docker] и [runners.machine]Как docker-ssh, но использует auto-scaled Docker machines.
kubernetes[runners.kubernetes]Kubernetes pods.

В большинстве случаев для сборки проекта вам потребуется dockerили docker+machine.

Autoscaling с Docker Machine

Docker Machine — это инструмент, который позволяет вам устанавливать Docker Engine на виртуальные хосты и управлять хостами с помощью команд docker-machine. Вы можете использовать Machine для создания узлов Docker на локальном компьютере Mac или Windows, в сети вашей компании, в вашем ДЦ или у облачных провайдеров, таких как Azure, AWS или DigitalOcean.

Этот инструмент предназначен для подготовки и управления вашими хостами с Docker Engine на них. Как правило, вы устанавливаете Docker Machine локально (в случае Gitlab — на сервере Gitlab). Docker Machine имеет собственный клиент командной строки docker-machine и клиент Docker Engine, docker. Вы можете использовать Machine для установки Docker Engine в запускаемых виртуалках с раннерами, которые, в свою очередь, могут располагаться с локальной сети или в облаке.

Используя команды docker-machine, вы можете запускать, проверять, останавливать и перезапускать управляемый хост, обновлять клиент Docker и демон, а также настраивать клиент Docker для связи с вашим хостом.

Для взаимодействия с конкретной виртуалкой используется драйвер. Список поддерживаемых драйверов перечислен здесь. Каждый драйвер имеет список своих параметров для конфигурации клиентов. Например, в AWS виртуальную машину можно создать так:

$ docker-machine create --driver amazonec2 aws01

Само собой, для выполнения потребуется аутентификация. Ключи доступа к AWS аккаунту можно положить в файл ~/.aws/credentials или использовать хелпер, который подгружают ключи из переменных среды. Подробнее о хелперах можно почитать здесь: https://github.com/awslabs/amazon-ecr-credential-helper#docker

Список прочих опций для настройки драйвера описан здесь: Документация на Github

Рассмотрим пример раннера с драйвером Google Cloud.

concurrent = 50   # До 50 параллельных jobs
[[runners]]
  url = "https://gitlab.com"
  token = "RUNNER_TOKEN"             # Это другой токен, чем используется в `gitlab-runner register`
  name = "autoscale-runner"
  executor = "docker+machine"        # Используем 'docker+machine' executor
  limit = 10                         # Этот раннер может исполнять до 10 jobs (созданных машин)
  [runners.docker]
    image = "ruby:2.7"               # Дефолтный образ для jobs 'ruby:2.7'
  [runners.machine]
    IdleCount = 5                    # Должно быть 5 машин в Idle state - вне пиковых часов
    IdleTime = 600                   # Каждая машина может быть в Idle state до 600 сек (после чего она удаляется) - вне пиковых часов
    MaxBuilds = 100                  # Каждая машина может обработать до 100 jobs подряд (после чего она удаляется)
    MachineName = "auto-scale-%s"    # Каждая машина будет иметь уникальное имя ('%s' требуется)
    MachineDriver = "google" # Смотрим как аутентифицироваться здесь: https://docs.docker.com/machine/drivers/gce/#credentials
    MachineOptions = [
      "google-project=GOOGLE-PROJECT-ID",
      "google-zone=GOOGLE-ZONE", # e.g. 'us-central-1'
      "google-machine-type=GOOGLE-MACHINE-TYPE", # e.g. 'n1-standard-8'
      "google-machine-image=ubuntu-os-cloud/global/images/family/ubuntu-1804-lts",
      "google-username=root",
      "google-use-internal-ip",
      "engine-registry-mirror=https://mirror.gcr.io"
    ]
    [[runners.machine.autoscaling]]  # Определим периоды с другими настройками
      Periods = ["* * 9-17 * * mon-fri *"] # По рабочим дням с 9 до 17 UTC
      IdleCount = 50
      IdleCountMin = 5
      IdleScaleFactor = 1.5 # Текущее количество Idle машин будет в 1.5 раза больше используемых машин,
                            # но не больше 50 и не меньше 5
      IdleTime = 3600
      Timezone = "UTC"
  [runners.cache]
    Type = "s3"
    [runners.cache.s3] # Будем использовать AWS S3 в качестве кэша
      ServerAddress = "s3.eu-west-1.amazonaws.com"
      AccessKey = "AMAZON_S3_ACCESS_KEY"
      SecretKey = "AMAZON_S3_SECRET_KEY"
      BucketName = "runner"
      Insecure = false

А теперь посмотрим на пример с AWS EC2 виртуальными машинами и аутентификацией в ECR.

[[runners]]
  name = "staging-builder"
  url = "https://gitlab.your-domain.com/" # Ваш Gitlab CE
  token = "gXjxKyem6kK4F_Lr13BD"
  executor = "docker+machine"
  # Здесь укажем переменные среды для аутентификации Docker Engine в AWS ECR и локальном registry для скачивания образов
  environment = [
    'DOCKER_CONFIG=/.docker',
    'DOCKER_AUTH_CONFIG={"credHelpers":{"123456789.dkr.ecr.eu-west-1.amazonaws.com":"ecr-login","docker-registry.your-domain.com":"aws-core"}}',
    'DOCKER_AWS_SECRETS_PREFIX=gitlab-runner-builder/staging/docker-registry',
    'DOCKER_BUILDER_CONFIG={"credHelpers":{"123456789.dkr.ecr.eu-west-1.amazonaws.com":"ecr-login","docker-registry.your-domain.com":"aws"}}'
  ]
  # Здесь укажем скрипт, который будет запускаться на раннере перед выполнением джоб
  pre_build_script = '''
    # Проверяем Gitlab проект (gitlab project group)
    case "${CI_PROJECT_ROOT_NAMESPACE}" in
      backoffice) ;;
      *) echo "Wrong project namespace: ${CI_PROJECT_ROOT_NAMESPACE}" >&2 ; exit 1 ;;
    esac
    # Настроим docker внутри раннера, дав ему права доступа в реджистри
    if mkdir -p "$DOCKER_CONFIG" 2> /dev/null; then
    echo "$DOCKER_BUILDER_CONFIG" > "$DOCKER_CONFIG/config.json"
    fi
  '''
  [runners.cache]
    Type = "s3"
    [runners.cache.s3]
      ServerAddress = "bucket.vpce-123465798.s3.eu-west-1.vpce.amazonaws.com"
      BucketName = "gitlab-runner-cache-staging"
      BucketLocation = "eu-west-1"
  [runners.machine]
    IdleCount = 0
    IdleTime = 1800
    MaxBuilds = 20
    MachineDriver = "amazonec2"
    MachineName = "common-staging-builder-%s"
    MachineOptions = [
      "engine-registry-mirror=https://docker-hub-mirror.yuor-domain.net/",
      "amazonec2-region=eu-west-1",
      "amazonec2-vpc-id=vpc-0facb4036aac45a1b",
      "amazonec2-subnet-id=subnet-035dfe68548201ade",
      "amazonec2-private-address-only=true",
      "amazonec2-ami=ami-0afb63d874a2d5790",
      "amazonec2-ssh-user=centos",
      "amazonec2-iam-instance-profile=gitlab-runner-builder-staging",
      "amazonec2-instance-type=t3a.large",
      "amazonec2-volume-type=gp3",
      "amazonec2-keypair-name=gitlab-runner",
      "amazonec2-ssh-keypath=/etc/gitlab-runner/.ssh/id_ed25519",
      "amazonec2-security-group=gitlab-runner-builder",
      "amazonec2-security-group-readonly=true",
      "amazonec2-tags=Name,Costs,staging-builder,Owner,gitlab-runner,Backup,none",
      "amazonec2-request-spot-instance=true",
      "amazonec2-spot-price="
    ]
  [runners.docker]
    image = "busybox:latest" # используем образ busybox
    privileged = true
    disable_cache = true
    volumes = [ # смонтируем файлы с креденшелами в целевую файловую систему раннера с правами read-only
      "/etc/gitlab-runner/bin/aws-env:/bin/aws-env:ro",
      "/etc/gitlab-runner/bin/docker-credential-ecr-login:/bin/docker-credential-ecr-login:ro",
      "/etc/gitlab-runner/bin/docker-credential-aws:/bin/docker-credential-aws:ro",
      "/var/run/docker.sock:/var/run/docker.sock"
    ]

Использование shell

Если вам не требуется docker-in-docker, то можно запустить просто скриптовую оболочку для сборки или деплоя приложения. Пример такого раннера:

[[runners]]
  name = "linux-runner"
  url = "https://gitlab.com/"
  id = 17390444
  token = "UHdwAw3MXnyf-C1NgwMR"
  token_obtained_at = 2022-09-07T05:49:15Z
  token_expires_at = 0001-01-01T00:00:00Z
  executor = "shell"
  [runners.custom_build_dir]
  [runners.cache]
    [runners.cache.s3]
    [runners.cache.gcs]
    [runners.cache.azure]

Доступные оболочки:

ShellОписание
bashСгенерировать Bash скрипт. Все команды выполняются в bash контексте. Дефолт для Linux.
shСгенерировать sh скрипт. Все команды выполняются в sh контексте.
powershellСгенерировать PowerShell скрипт. Все команды выполняются в PowerShell Desktop контексте. В GitLab Runner 12.0-13.12 это дефолт для Windows.
pwshСгенерировать PowerShell скрипт. Все команды выполняются в PowerShell Core контексте. In GitLab Runner 14.0 и более поздних это default для Windows.


Был ли наш пост полезен?

Нажмите на звезду, чтобы оценить мои труды!

Средний рейтинг: 0 / 5. Количество голосов: 0

Пока голосов нет. Проголосуй первым!

Мне жаль, что пост вам не помог 🙁

Позвольте мне исправиться.

Поделитесь, что можно улучшить?

Поделиться в соц. сетях

Опубликовать в Google Buzz
Опубликовать в LiveJournal
Опубликовать в Мой Мир

Похожие посты