Информация

Дата основания
Местоположение
Россия
Сайт
southbridge.io
Численность
51–100 человек
Дата регистрации

Блог на Хабре

Обновить

Тонкости настройки CI/CD: как работает GitLab runner, когда использовать Docker-in-Docker и где пригодится Argo CD

Блог компании SouthbridgeСистемное администрированиеПрограммированиеIT-инфраструктураDevOps
Рейтинг +17
Количество просмотров 4,9k Добавить в закладки 79 Читать комментарии 10
Комментарии 10

спасибо, познавательно


Есть ли в GitLab профили переменных? Например, я хочу сделать переменную host, и чтобы она приезжала разная в зависимости от окружения. Есть ли какое-нибудь профилирование? Например, я не хочу называть переменную host_dev, host_prod и host_test, а хочу указать окружение, и оно определённый набор переменных вытащит? Можно ли такое сделать?

Тимофей Ларкин: С ходу на ум мало что приходит. Можно, наверное, какие-то env-файлы держать в репозитории и просто их сорсить в пайплайне.

уже же есть такое… Гитлаб очень быстро развивается, так что не всегда успеваешь уследить


Однако этот подход через Docker Machine сам GitLab считает малость устаревшим. Есть открытый баг, где разработчики размышляют, куда лучше перейти, какие-то варианты есть. Самый очевидный — перейти в Kubernetes

устаревший — не устаревший, но ничего лучше не придумали. Заведя раннеры в кубе — мы сразу получаем пакет неустранимых проблем. Начиная от изоляции и безопасности и кончая тем, что Кубер накладывает ограничения на то какие пайплайны мы можем гонять.

А можно немного больше насчет значение переменной от env? похоже тоже пропустил Уже увидел ниже)
Есть ли в GitLab профили переменных? Например, я хочу сделать переменную host, и чтобы она приезжала разная в зависимости от окружения. Есть ли какое-нибудь профилирование? Например, я не хочу называть переменную host_dev, host_prod и host_test, а хочу указать окружение, и оно определённый набор переменных вытащит? Можно ли такое сделать?

Да, у переменных есть Environment Scope

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

voffk это не та фича ) Вроде как.


Речь же об этом:


Т.е. можно одну и ту же переменную назначить на разные окружения с разными значениями.


lllamnyp


Но мне кажется, держать информацию о среде деплоя даже не в значении переменной, а в её имени — хреновая практика

в целом — да. Но на первых порах — это может быть разумным дешевым подходом сделать наиболее приемлемо

Да, это уже вариант получше. Но мне всё равно не нравится хранить конфигурацию в переменных гитлаба, а не в коде. К сожалению, хранение секретов не так хорошо продвинулось, как хранение кода.

Почему job’a release триггерится при изменении тега, хотя в родительском пайплайне стоит only changes?

Добавлю также к ответу, что общая рекомендация на сегодня — переход на использование rules вместо only/except

А в общем отличная Q&A сессия! Спасибо большое!

Всё делается очень просто: раннер с предварительно настроенными ключами заходит по SSH на хост, делает там docker stop, docker rm (удаляет старый контейнер) и docker run с прямым указанием на конкретный образ, который мы только что собрали. В результате поднимается новый образ.

чтобы простой был минимален — нужно делать немного в другом порядке docker pull (чтобы не ждать скачивания образа), docker stop, docker rm и уже тогда только docker run :-)
Автоматизировать процесс можно через какой-нибудь https://github.com/containrrr/watchtower хотя я к нему со скепсисом отношусь. По ZTD (Zero-Time Deployment) — да, тут он не получается, нужно вносить дополнительные компоненты — тот же reverse proxy traefik.

Имеет смысл разделять раннеры, которые деплоят на test и staging, и раннеры, которые деплоят на prod?

Имеет, если у вас большие очереди обычно, но хочется чтобы релиз на прод проходил максимально быстро, вне очереди

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.