Довольно частый вопрос с LF — Как жить с gitlab раннерами?
Да просто там всё. Если у тебя основная инфра в кубе, то в кубе и крутим. Ну а если ламповые сервера, без всей этой кубовой хуйни, то вариантов не много.
Заводим себе отдельный сервер/сервера, чисто под раннеры. Заводим с учетом на то, что на этих серверах будут собираться докер образы. Со временем место будет забиваться.
Здесь важно раздуплить себе какой-нибудь гарбаж коллектор, либо башник в крону накидать.
Подняли сервер, нарегали нужных раннеров. В идеале это процесс автоматизировать, ансибл-хуянсибл ну или чё там у тебя есть.
Раннеры можно зарегать на один токен:
Сервер 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. Ну и запускаем команды.
Важно!
Основное рассказал, если что-то еще вспомню, накидаю. Если у тебя есть мысли, пиши в комментарии, будем обсуждать.








Комментарии