Да просто там всё. Если у тебя основная инфра в кубе, то в кубе и крутим.
ㅤ
Ну а если ламповые сервера, без всей этой кубовой хуйни, то вариантов не много.
Заводим себе отдельный сервер/сервера, чисто под раннеры. Заводим с учетом на то, что на этих серверах будут собираться докер образы. Со временем место будет забиваться.
Здесь важно раздуплить себе какой-нибудь гарбаж коллектор, либо башник в крону накидать.
Часто раннеры пихают прям на продакшен сервера, где крутятся все бизнес процессы. В этом случае продакшен превращается в помойку, нагрузка постоянно скачет при сборках/деплое и т.п.
Это хуёвая практика, на продакшене такого быть не должно. Лишь поэтому мы и поднимаем отдельный сервер под раннеры.
Подняли сервер, нарегали нужных раннеров. В идеале это процесс автоматизировать, ансибл-хуянсибл ну или чё там у тебя есть.
Раннеры можно зарегать на один токен:
Сервер 1
gitlab-runner register \
--url https://gitlab.com/ \
--registration-token ABCDEFG123456 \
--executor docker \
--description "runner-1"
Сервер 2
gitlab-runner register \
--url https://gitlab.com/ \
--registration-token ABCDEFG123456 \
--executor docker \
--description "runner-2"
В морде гитлаба появятся 2 отдельных раннера, а далее гитлаб будет балансировать между ними. Также можешь указать одинаковые теги. Тут у нас все сводится в сторону масштабируемости.
Раннер 1
--description "runner-fast"
--tag-list "docker"
Раннер 2
--description "runner-slow"
--tag-list "docker"
В
.gitlab-ci.yml у нас так:build:
script: echo "Building"
tags:
- docker
Задание пойдет на тот раннер, который раньше освободится. Если оба свободны — гитлаб рандомно сделает выбор, приоритетности нет.
Если важна приоритетность, можно поиграть в юните с параметром
GITLAB_RUNNER_PRIORITY.Короче если хочешь распределять нагрузку по раннерам с одинаковыми тегами, и раннера работают на разных машинах, просто регистрируй всех с одинаковыми тегами — гитлаб сам уже всё разрулит.
А как деплоить?
Тоже всё просто,
ssh/rsync в помощь, раннер подключается к нужному серверу, например по ssh и выполняет все необходимые команды. Затаскивает новый докер образ, стопорит старый, запускает новый.Как-то так:
deploy:
stage: deploy
script:
- |
ssh $SSH_USER@$SSH_HOST << EOF
docker pull $IMAGE_NAME
docker stop my_app || true
docker rm my_app || true
docker run -d -p 5000:5000 --name my_app $IMAGE_NAME
EOF
Подключаемся под юзером из переменной
$SSH_USER к хосту из переменной $SSH_HOST. Ну и запускаем команды.Важно!
Если у тебя 100500 раннеров — ты с ними заебешься, поэтому на моменте регистрации, сделай себе табличку, пропиши в них теги раннеров и на каких серверах они у тебя живут. Опять же это можно сделать через ансибл-роль, либо скриптом генерить. Тут уже сам наколдуешь.
Основное рассказал, если что-то еще вспомню, накидаю. Если у тебя есть мысли, пиши в комментарии, будем обсуждать.
🛠 #devops #linuxfactory #cicd
—
✅ @bashdays ✅ @linuxfactory ✅ @blog