Какие способы доставки приложения на prod существуют в gitlab?

Question

[Александр Панков]

ребят, запутался. помогите разобраться
ранее в ci\cd нос не совал
обновлял php приложение так
1) с локальной машины делаю push в main
2) захожу на vps через ssh
3) пишу там git pull origin main
4) готова - фича выкачена

на данном этапе никакого докера

хочу теперь через ci\cd гитлаба сделать
вижу шаги
1) с локальной машины делаю push в main
2) в gitlab-ci.yml у меня есть джоба (only: - main)
3) через шаред раннер гитлаб запускает мой пайплайн
4) внутри него я через rsync копирую файлы на prod сервер (а если файлов тысяча...)

так?
(учебный проект, без доекра, node и тп, просто php)
если все так, выходит на проде мне не нужен теперь гит?
только composer чтобы зависимости скачать и обновить?

Какие вообще есть варианты доставить код, если не учитывать docker
rsync, scp, ftp?
а если у нас nuxt, которого нужно собирать (билдить), и бесшовно менять на проде тогда как?

Answer 1

[Василий Банников]

4. Хоть тысяча, хоть миллион - проблемы вряд ли возникнут. В крайнем случае упаковать в архив и передать на прод в виде архива, и там его распаковать.
Можно ещё с докером попробовать заморочиться.

И да, на проде гит тебе не нужен.
На счёт composer не подскажу, но по идее тоже не нужен, если отправлять сразу с загруженными зависимостями.

С nuxt - точно также билдишь в gitlab ci и отправляешь уже собранные артефакты.
Чтобы не уходить в простой, пока файлы подменяются - сделать хотябы два узла и раскатывать blue-green или rolling update.

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

Но в простом случае легче будет запаковать файлы в tar и передать по scp

Comments

[Александр Панков]

Василий Банников спасибо

Верно ли я понял?

у меня есть приложение nuxt.js(ssr)
запускается в докере

стоит задача сделать бесшовный деплой
согласно blue-green методологии, когда создаются 2 инстанса моего приложения
первый - спит, второй - обрабатывает запросы

при деплое из ci\cd у меня "спящий" инстанс обновляется из реджестри
как только он готов, он становится "основным"
все запросы идут на него, другой инстанс становится спящим и тоже начинает обновляться
таким образом достигается бесшовный деплой (zero-downtime)

а управлять этим всем (абзац выше) позволяет Docker Swarm
(ps у меня приложение дергает api на другом сервере, на этом все)

Подскажите все ли верно я у себя в голове по полочкам расположил? (если да буду дальше изучать)

Могу ли я на ОДНОЙ linux vps использоваться Docker Swarm,
который будет окрестрирвоать 2мя инстансами (ну может 3мя "для себя побаловаться")
проект не большой, не высоконагруженный

или что я выше описал назыается Rolling updates? (updates to nodes incrementally)

Rolling updates: At rollout time you can apply service updates to nodes incrementally. The swarm manager lets you control the delay between service deployment to different sets of nodes. If anything goes wrong, you can roll back to a previous version of the service.

[Василий Банников]

Александр Панков,

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

Да, именно это я и имел в виду)
Docker Swarm тут не обязателен кстати. Вместо него может быть что угодно, а может быть даже просто пачка sh-ников.

Могу ли я на ОДНОЙ linux vps использоваться Docker Swarm,

Вот про swarm не подскажу. Без swarm ты точно можешь запустить два экземпляра на разных портах, и разрулить через nginx тот же.

или что я выше описал назыается Rolling updates? (updates to nodes incrementally)

Отличие rolling update от blue-green в том, что у тебя раскатка обновления происходит без остановки других экземпляров. Тоесть чисто теоретически у тебя может в один момент жить несколько версий.

[Saboteur]

Александр Панков,

Стоит задача сделать бесшовный деплой

В первую очередь приложение должно уметь это делать - запустить два экземпляра и не мешать друг другу. С учетом, что новый экземпляр может быть другой версии. С учетом работы с базой данных.
Тогда можно деплоить новый экземпляр как угодно - blue/green, rolling update на 2+ инстанса, и останавливать старый после того как новый завелся.

Всякие CI/CD инструменты это именно инструменты, а не правила. Ты придумай как ты это приложение деплоил бы руками, а через ci/cd просот автоматизируй.