Комментарии 10
спасибо, познавательно
Есть ли в GitLab профили переменных? Например, я хочу сделать переменную host, и чтобы она приезжала разная в зависимости от окружения. Есть ли какое-нибудь профилирование? Например, я не хочу называть переменную host_dev, host_prod и host_test, а хочу указать окружение, и оно определённый набор переменных вытащит? Можно ли такое сделать?
Тимофей Ларкин: С ходу на ум мало что приходит. Можно, наверное, какие-то env-файлы держать в репозитории и просто их сорсить в пайплайне.
уже же есть такое… Гитлаб очень быстро развивается, так что не всегда успеваешь уследить
Однако этот подход через Docker Machine сам GitLab считает малость устаревшим. Есть открытый баг, где разработчики размышляют, куда лучше перейти, какие-то варианты есть. Самый очевидный — перейти в Kubernetes
устаревший — не устаревший, но ничего лучше не придумали. Заведя раннеры в кубе — мы сразу получаем пакет неустранимых проблем. Начиная от изоляции и безопасности и кончая тем, что Кубер накладывает ограничения на то какие пайплайны мы можем гонять.
Есть ли в GitLab профили переменных? Например, я хочу сделать переменную host, и чтобы она приезжала разная в зависимости от окружения. Есть ли какое-нибудь профилирование? Например, я не хочу называть переменную host_dev, host_prod и host_test, а хочу указать окружение, и оно определённый набор переменных вытащит? Можно ли такое сделать?
Да, у переменных есть Environment Scope
Да, особо не работал с этой фичёй и поэтому не сразу понял, что вопрошающий хотел. Но мне кажется, держать информацию о среде деплоя даже не в значении переменной, а в её имени — хреновая практика. В идеале ваши скрипты вообще должны быть способны "оглянуться" вокруг себя, понять в какой среде они исполняются и из единого источника правды понять, где там аписервер кубера и хранилище секретов, допустим.
voffk это не та фича ) Вроде как.
Речь же об этом:
Т.е. можно одну и ту же переменную назначить на разные окружения с разными значениями.
Но мне кажется, держать информацию о среде деплоя даже не в значении переменной, а в её имени — хреновая практика
в целом — да. Но на первых порах — это может быть разумным дешевым подходом сделать наиболее приемлемо
Почему 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?
Имеет, если у вас большие очереди обычно, но хочется чтобы релиз на прод проходил максимально быстро, вне очереди
Тонкости настройки CI/CD: как работает GitLab runner, когда использовать Docker-in-Docker и где пригодится Argo CD