Для того, чтобы обновить бек приложение, вам приходится его останавливать?

Есть какие-то варианты, как это можно реализовать, чтобы и бек обновить, и не останавливать приложение в проде?
Мне вот кажется такая схема: что есть несколько инстансов приложения и ты просто по очереди отключаешь один, заменяешь его (нагрузка на остальные уходит, а очереди через кафку организуются), и там по очереди все, в итоге бек работает. Кто-то так делает? Где об этом можно почитать
И, например, как производить обновление базы данных на проде без остановки? С какими ещё проблемами можно столкнуться, если хочется обновлять именно без остановки работы приложения?

Да, так и делают. По очередь перезапускают сервисы. Часто с готовыми решениями типа pm2, например. С базой сложнее...

мне так видится, что обновлять базу лучше через создание новых табличек (даже если не совсем семантически подходит), не трогая существующие. Например, поставить задачу в task manager (наравне с обычными запросами), оно создаст новые таблички, затем обновляю инстансы, чтобы логика стала доступна и в самом конце обновляю фронт, чтобы он уже начал посылать запросы. В этой схеме есть что-то неправильное?

Для этого нужно иметь связь с прокси/лб который будет понимать readyness. На самом деле чаще всего применяется небольшой downtime, потому что остальные решения довольно костыльные. В базе чаще всего делаются промежуточные шаги без breaking changes, а потом чистятся остаточные колонки

обновление базы - абстрактная задача. оно может быть только на добавление, а может быть деструктивным, сможет ли старый сервис работать с новой бд? Если да, то ок. Например, боавились новые столбцы, которые нужны только новому сервису

В том же кубере это делается довольно просто, также есть возможность делать canary deploy(выкатка не на всех пользователей)

Я пытаюсь понять, как мне всё это освоить( Пишу пет проект, хочется всё покруче сделать и вот zero-downtime deployment оч желанная штука.

Я бы посоветовал что-то в теме hot-reload для программного и не упарываясь в системную плоскость. Иначе можно изучать год минимум чтобы просто задеплоить :)

У гугл сервисов есть 300$ на 1 год, если хочешь делать zero downtime как большие дяди можешь разобраться в кубере на минимальном уровне в gke

не нужен для этого кубер

То есть имеет смысл копать в сторону кубернейтс? Я приложение в принципе планрую в докер контейнер завернуть, а по поводу кубера не уверена была...

Вроде как давно уже не на год.

Если обновление БД не ломает старые сервисы, просто делаете миграцию и по очереди перезапускаете сервисы. Это делает даже простой процесс менеджер, например, pm2, либо разные варианты с докером. Если обновление бд всё ломает, тогда выключетесь, обновляете и включаетесь :)

а кубер мне зачем-то может пригодится?

он из коробки тоже умеет контейнеры по очереди заменять, но эот как пушкой по воробьям, брать его только для обновления

Вот кстати да, с compose можно спокойно сделать роллинг апдейт, чуть запарившись со скриптом. Но нужен всё равно прокси, думаю 🤔

а зачем прокси?

Пэт проект в моем понимании подразумевает изучение новых технологий, а пм2 это такое себе

граница "нового" может быть разной

Согласен