Как удалить gitlab runner

Настройка, использование GitLab CI/CD

GitLab – это программный инструмент, созданный с целью хранения и управления репозиториями Git. Концепция непрерывной интеграции (Continuous Integration — CI) на примере использования GitLab CI/CD. Сервис Gitlab предоставляет возможность получить не только бесплатный приватный GIT репозиторий, но и бесплатный CI/CD.

Для самостоятельной установки ПО GitLab на свой сервер используйте ссылки официальную документацию. Основной функционал GitLab:

Планирование и управление разрабатываемыми проектами;
Создание, просмотр и управление кодом и данными проектов;
Проверка кода благодаря автоматическому тестированию и отчетности;
Мониторинг ресурсов и просмотр метрик;
Использование готовых шаблонов моделей.

На этом список функционала не заканчивается. Это лишь основная часть, необходимая для понимания важности использования этого ПО в проектной деятельности. В этой статье будет рассмотрена настройка GitLab CI CD для тестового проекта.

1. Установка GitLab Runner

Runner в GitLab позволяют автоматизировать рутинные задачи при обновлении проектов в репозитории. Для того чтобы у GitLab был доступ к серверу, на этот сервер необходимо установить службу gitlab-runner. Runner будет забирать новые исходники с GitLab, выполнять с ними нужные действия и разворачивать на сервере.

Рассмотрим установку Runner для Debian/Ubuntu/Mint, в моем случае Debian 11 (bullseye):

curl -L "https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh" | sudo bash apt install gitlab-runner

Будет добавлен пользрватель gitlab-runner

gitlab-runner:x:999:999:GitLab Runner:/home/gitlab-runner:/bin/bash

Проверим состояние раннера и если нужно добавим runner в автозагрузку и сразу запустим

systemctl status gitlab-runner systemctl enable --now gitlab-runner

Схема как работает Git раннер:

2. Регистрация GitLab Runner

В репозитории на GitLab, для которого вы хотите настроить CI, выберите пункт меню Settings подменю CI/CD. Возле пункта Runners нажмите кнопку Expand.

Общие раннеры от GitLab можно отключить для того чтобы они вам не мешали и не забирали задачи у вашего раннера. Для этого под надписью Enable shared runners for this project установите значение выключателя в положение выключено.

Необходимая информация находится в левой части окна, в разделе Specific runners. Тут вам надо узнать URL сервиса и токен авторизации, с которыми нужно регистрировать раннер.

На сервер, на котором был установлен runner и выполните команду для регистрации раннера в Gitlab:

sudo gitlab-runner register

Программа запросит URL , token, которые вы узнали на GitLab в разделе Specific runners и попросит ввести описание и теги. Теги будут использоваться в будущем для того чтобы отправлять этому раннеру задания. Далее останется только выбрать способ выполнения команд. Для того чтобы просто запускать командную оболочку можно выбрать shell.

Для того чтобы убедится, что всё настроено и работает нормально выполните такую команду:

sudo gitlab-runner verify . Verifying runner. is alive

Она должна показать сообщение is_alive. Настройка gitlab runner на сервере завершена.

Для удаления зарегистрированного раннера используйте команду:

gitlab-runner verify --delete --url https://gitlab.com/ --token H2RRJd

3.1 Настройка GitLab Runner в Linux

Скорей всего у вас раннер работать не будет. GitLab Runner при запуске в качестве службы запускает все сценарии оболочки от имени непривилегированного пользователя: gitlab-runner. Если вы хотите использовать команды системного уровня, например, apt-get вам нужно выполнить их с помощью sudo.

Зададим нужные привилегии пользователю gitlab-runner — добавим его в группу sudo и разрешим запуск команд без пароля:

usermod -aG sudo gitlab-runner

и меняем строки в файле /etc/sudoers, используя команду visudo

# visudo #%sudo ALL=(ALL:ALL) ALL %sudo ALL=(ALL) NOPASSWD:ALL

Если нужно ограничит пользователя gitlab-runner в запуске команд, смотрите пример ниже

gitlab-runner ALL= (root) NOPASSWD: /usr/bin/mkdir gitlab-runner ALL= (root) NOPASSWD: /usr/bin/touch

3.2 Настройка GitLab Runner вебинтерфейс

Обновите страницу настроек CI на GitLab. Новый раннер должен появится в списке и кружок возле него должен быть зелёным.

Кликните по значку карандаша (Edit) возле раннера и выставьте такие настройки:

Active — должно быть включено, иначе раннер не сможет выполнять задания;

Protected — должно быть включено, для того чтобы раннер брал задания из всех веток, а не только защищённых;

Run untagged jobs — должно быть включено, позволяет раннеру брать задачи без тегов;
Lock to current projects — если включено, этот раннер доступен только для этого проекта.

Все остальные опции можно не трогать.

4. Создание gitlab-ci.yml

В файле gitlab-ci.yml описываются все задачи, а также команды, которые gitlab-runner будет выполнять на сервере. Вы можете создать его вручную или же, если такого файла ещё нет, то нажмите кнопку Editor в меню CI/CD вашего проекта.

Файл в формате YAML, поэтому отступы перед значениями очень важны.

stages: - название_этапа_1 - название_этапа_2 название_задачи_1-job stage: название_этапа_1 script: - команда_1 - команда_2

Раздел stages описывает этапы разворачивания приложения и очередность их выполнения. Затем описываются задачи, которые будут выполняться в рамках каждого этапа. У задачи должен быть указан этап: stage и script со списком команд, которые будут выполняться на сервере.

Во время разворачивания gitlab-runner автоматически создает на сервере (по умолчанию в домашней папке) директорию build, клонирует туда свежие исходники проекта и переходит в папку с исходниками. А дальше с помощью команд в секции script вы можете делать всё, что нужно с этими исходниками.

Сохраните этот файл. Для этого пролистайте вниз страницы и нажмите кнопку Commit Changes.

Простой пример gitlab-ci.yml создающий файлы. Параметр only жестко задает для какой ветки, какой код должен выполняться.

stages: # List of stages for jobs, and their order of execution - master - develop - staging master-job: # This job runs in the build stage, which runs first. stage: master only: - master script: - echo "Compiling the code. " - echo `date +'%m/%d/%Y'` >> /tmp/master777 - echo "Compile complete." staging-job: # This job runs in the deploy stage. stage: staging # It only runs when *both* jobs in the test stage complete successfully. only: - staging script: - echo "Deploying application. " - echo `date +'%m/%d/%Y'` >> /tmp/staging - echo "Application successfully deployed." develop-job: stage: develop only: - develop script: - echo "Deploying application. " - echo `date +'%m/%d/%Y'` >> /tmp/develop - echo "Application successfully deployed."

5. Проверка работы Pipeline

Если всё было сделано правильно, то ваш раннер получит эту задачу, склонирует исходники. Для того чтобы убедится что это всё произошло, в боковом меню выберите значок ракеты (CI/CD) а затем Pipelines.

Чистка build-агентов Gitlab

Спешим поделиться с вами нашим инструментом для поддержания чистоты и порядка на наших (RNDSOFT) сборочных серверах gitlab-janitor . О том, как мы к нему пришли, и каков первый опыт — далее по тексту.

С каждым годом инфраструктура RNDSOFT, обеспечивающая процессы CI/CD, растёт. Появляются новые проекты, усложняются процессы (pipelines) сборки и тестирования, растет количество сборщиков (build agents), и всё это приносит дополнительные накладные расходы. Сегодня мы рассмотрим конкретную проблему — чистку/освобождение ресурсов на самих сборочных серверах. Мы используем Gitlab и несколько Gitlab runners с докером ( docker executor ) под капотом. Вот с проблем и начнём.

Проблемы

Вся терминология будет опираться на Gitlab , но всё это применимо и к другим решениям, опирающимся на docker.

Типовой процесс сборки и доставки состоит из 4х больших этапов (stages), по несколько задач (jobs) в каждом:

• сборка docker-образа (обычно одного на проект, но бывает и больше).
• тестирование. Тут мы используем подход, когда тестируем не сам код, а весь контейнер. Конечно, есть юнит-тесты, интеграционные, графические и прочие, но запускаем мы их непосредственно внутри боевого контейнера. А что? У нас ruby — можем себе позволить �� 🙂
• тэгирование (image promoting). Этап в зависимости от результатов тестов и QA перетегируется во что-то вроде stable или release , или как-то еще, в зависимости от конкретного проекта, команды и принятых процессов.
• доставка (deploy). Тут всё как обычно — дев/тест стенды, QA-стенды, динамические стенды для MR и всякое разное вроде документации.

Давно хочу написать отдельно про процесс image promotiong, про то, как мы таскаем образы между стадиями, но руки не доходят. Если кого сильно интересует — пишите в комментариях, и мне придётся найти в себе силы 🙂

В результате описанных выше процессов (особенно тестирования) на сборщиках остаётся много мусора, именно это является проблемой. Далее по порядку.

Подвисшие контейнеры (dangling containers)

Тут речь, конечно, идёт не о повисании ПО внутри контейнера, а о самих «ненужных» контейнерах. Например, для графических тестов поднимается целый стек: Postgres, Chrome, Selenium, само приложение, контейнер, из которого запускаются тесты, Redis и бог еще знает что. Если весь процесс (pipeline) или непосредственно задача (job) будут прерваны, то никто не погасит за нас эти контейнеры, и они продолжат висеть и потреблять ресурсы. Проблема!

Ненужные образы

В процессе сборки имя образа претерпевает примерно следующие изменения: image:$SHA -> image:stable -> image:release. Конечно, это примерно, шагов может больше или именования другие, но сути это не меняет. При последовательных комитах сратыестарые образы остаются лежать мёртвым грузом.

В день мы генерим примерно 75GB образов. ~25GB на каждом из трех сборщиков. И это летом, когда многие в отпуске 🙂

Ситуация усугубляется тем, что один и тот же образ находится (с максимальной вероятностью) сразу на всех сборщиках, поскольку разные типы тестов запускаются параллельно и попадают на все сборщики и занимают x3 места. Проблема! Дважды проблема, поскольку с образами всё не так просто и очень интересно — об этом ниже.

Безымянные и кеширующие тома (unnamed and cache volumes)

Многие контейнеры при создании аллоцируют в докере временные анонимные тома/диски (мы же всегда про докер говорим, верно?) и оставляют их после себя. Также сам Gitlab, если вы не используете распределённые кеш (shared cache) на базе S3 , всё равно создаёт кеш-тома, если ему явно не запретить это делать через disable_cache . Проблема!

Конечно, эти проблемы не простой «мусор» — старые образы могут ускорить последующую сборку, кеш-тома также теоретически могут ускорять сборку, так что они не совсем бесполезны. Однако, проблемы ускорения и кеширования мы решаем немного иначе — с помощью определённых схем именования образов, используя buildkit, который умеет подтягивать кешированные слои прямо из реестра образов (в нашем случае harbor) и пр.

Что же делать?

Проблемы появляются не сразу. Когда-то у нас был один сборщик, там вообще не было проблем с перетягиванием образов между этапами, а образы чистились через docker rmi на последнем шаге процесса. Когда сборщиков стало больше, и на них докинули ресурсы, пришлось немного усложнить схему — сначала были bash-скрипты, которые по расписанию удаляли образы по шаблону имени. Затем периодически стали использовать docker system prune . Но эти решения очень негибкие, плохо поддерживаются и масштабируются и обладают фундаментальной проблемой — частыми кеш-промахами (cache miss), что периодически сильно тормозило процессы (pipelines). И вот однажды терпеть это стало невозможно �� :)))

Нам нужно хорошее решение, желательно с баристой и массажисткой! Встречаем — gitlab-janitor !

Gitlab-janitor

Основными задачами были:

• консолидация всех чисток сборщика в одном месте;
• уменьшение кеш-промахов, насколько это возможно;
• простота работы.

Для чистки места на сборщиках уже есть проект gitlab-runner-docker-cleanup , он и явился идейным вдохновителем нашей утилиты, но, к сожалению, не выполнял всех необходимых нам функций.

Написав своё решение, мы решили опубликовать его в открытом виде — и зеркало на github , и образы на docker-hub , и даже документация с примерами. Ну и не мог я удержаться от разнообразных бейджиков 🙂

Проще всего запускать его в докере на каждом сборщике (для этого мы используем nomad �� ):

docker run --rm \ -v /var/run/docker.sock:/var/run/docker.sock \ -v /persistent/janitor:/store \ -e REMOVE=true \ -e INCLUDE="*integr*, *units*" \ -e EXCLUDE="*gitlab*" \ -e CONTAINER_DEADLINE="1h10m" \ -e VOLUME_DEADLINE="4d" \ -e IMAGE_DEADLINE="4d" \ -e CACHE_SIZE="10G" \ -e IMAGE_STORE="/store/images.txt" \ rnds/gitlab-janitor:latest

Заметили IMAGE_STORE ? С остальными параметрами всё просто — шаблоны для имён образов, томов, сроки хранения, а вот для образов всё гораздо интереснее!

Докер не сохраняет в своём локальном хранилище никакой информации о времени загрузки образа, а только обычную дату создания образа. В результате нет возможности определить, какой образ очень нужен и часто используется (хоть и создан давно), а какой свеженький, но больше никогда и никому не будет нужен.

Для решения этой проблемы в gitlab-janitor сделан простенький механизм — когда образ встречается первый раз, он сохраняется в файл с временной меткой — это считается датой появления. Когда подходит срок — образ удаляется. Однако, если gitlab-janitor увидит созданный контейнер из этого образа — то временная метка в этом файле сбрасывается. Именно для этого и используется параметр IMAGE_STORE . Данный файл можно монтировать с хост-машины, а можно и нет — в этом случае история образов будет теряться при пересоздании/обновлении контейнера-чистильщика:

selenium/standalone-chrome:latest sha256:c01aea5eb0bf279df5f745e3c277e30d7d9c81f15b9d1d4e829f1075c31ed5b1 1660205645 postgres:10-alpine sha256:d7023df56cb7cbe961f0c402888f7170397c98c099fb76fbe16b5442a236ad51 1660205040 redis:latest sha256:3edbb69f9a493835e66a0f0138bed01075d8f4c2697baedd29111d667e1992b4 1660205645

С остальными параметрами, документацией и примерами можно ознакомиться на гитхабе.

Результаты

Вот и подъехали результаты объективного контроля за работой gitlab-janitor на трех наших сборщиках:

Все чистки с помощью cron+bash , docker prune и пр. выключены. Параметры, оптимально подходящие под наши процессы, мы еще подбираем (и будем подбирать), но уже видно, что процесс вошел в стабильную фазу, и наш чистильщик выполняет свою работу!

How do I delete/unregister a GitLab runner

I have registered a personal GitLab runner several months ago, which I no longer use. How do I completely delete it so that it does not show up on my GitLab CI/CD settings page?

asked Mar 13, 2021 at 16:40
18.6k 12 12 gold badges 83 83 silver badges 93 93 bronze badges

10 Answers 10

1. List runners to get their tokens and URLs:

sudo gitlab-runner list 

sudo gitlab-runner verify --delete -t YMsSCHnjGssdmz1JRoxx -u http://git.xxxx.com/ 

5,134 17 17 gold badges 35 35 silver badges 42 42 bronze badges
answered Aug 2, 2021 at 6:55
Serge Iroshnikov Serge Iroshnikov
809 1 1 gold badge 7 7 silver badges 18 18 bronze badges
For this you will also need to remove it from your CI/CD page on Gitlab first
Nov 7, 2021 at 6:45

Even though the command executes successfully, the runner is still in /etc/gitlab-runner/config.toml , so that seemingly did nothing. The other answer here that suggests a gitlab-runner unregister command works for me tho.

Aug 31, 2022 at 11:56

Get your runner token and id

First, go to the GitLab settings page and find the token (e.g. 250cff81 in the image below) and the id (e.g. 354472 in the image below) of the GitLab runner which you wish to delete.

Use the gitlab-runner CLI to unregister the runner

If you have access to the machine which was used to register the GitLab runner, you can unregister the runner using the following command, where you replace with the token of your GitLab runner (e.g. 250cff81 in the example above).

gitlab-runner unregister --url https://gitlab.org/ --token

Use the GitLab API to unregister the runner

If you no longer have access to the machine which was used to register the runner, or if the runner is associated with multiple projects, you can use the following Python script. Set RUNNER_ID to the id of your runner (e.g. 354472 in the example above) and GITLAB_AUTH_TOKEN to a GitLab token which you can generate from your profile page.

import os import requests GITLAB_AUTH_TOKEN = . RUNNER_ID = . headers = r = requests.get(f"https://gitlab.com/api/v4/runners/", headers=headers) runner_data = r.json() for project in runner_data.get("projects", []): r = requests.delete( f"https://gitlab.com/api/v4/projects//runners/", headers=headers, ) if not r.ok: print("Encountered an error deleting runner from project:", r.json()) r = requests.delete(f"https://gitlab.com/api/v4/runners/", headers=headers) if not r.ok: print("Encountered an error deleting runner:", r.json()) 

Настройка Gitlab runner

Для того, чтобы настроить свой 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 Engine	Docker контейнер.
docker-windows	[runners.docker] и Docker Engine	Windows Dockerконтейнер.
docker-ssh	[runners.docker] , [runners.ssh] , и Docker Engine	Docker контейнер, но с подключением по 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=>', 'DOCKER_AWS_SECRETS_PREFIX=gitlab-runner-builder/staging/docker-registry', 'DOCKER_BUILDER_CONFIG=>' ] # Здесь укажем скрипт, который будет запускаться на раннере перед выполнением джоб pre_build_script = ''' # Проверяем Gitlab проект (gitlab project group) case "$" in backoffice) ;; *) echo "Wrong project 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/" 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.

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

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