Привет, собрал проект через compose, вроде все ок работает. У меня

только вопрос. При запуске команды docker-compose up -d перезапускаются контейнеры при наличии изменений в коде, что логично конечно же, только мне нужно, чтобы приложение на проде работало без вот этих пробелов во время перезапуска, так как в этот момент пользователи могут совершать важные запросы на сайте, которые должны все отработать.
Каким образом бесшовный деплой делают?

Самый простой способ это повесить нжинкс перед например двумя хостами где у вас докер и сделать апстримы. Сначала деплой на один хост, потом на другой. Может конечно пятисотить, но с трудом представляю как можно вообще без пятисоток переехать на новый код

Странно конечно

?!

Ну если без докеров всяких просто деплоить новый код путем замены файлов, то никаких 500 не будет, а с докером костыли какие-то постоянно приходится делать) Это пока, что я понял за время изучения

Без докера код на ноде через pm2, пятисотит при деплоях…

Ну это беда. Если в сервисе пользователь запускает длительные процессы и в это время происходит деплой, то его процесс тупо оборвётся, что повлечёт за собой негативный опыт

это работает только в случае cgi (а-ля php) или раздачи файлов из папки (.js, статика), да и то чудом (один файл обновился, второй нет, запрос попал на полурабочее окружение)

И к выше описанному другим это происходит за какие то милесекунды и на 500 запросов в секунду, 2-3 пятисотки…

Для чего тогда докер? Для развлечений на локалке?)

Ровно для того, что заявлено в описании

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

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

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

Ок понял

Я слышал что через это делают https://github.com/containrrr/watchtower , раннер и ci cd вроде . Там все вместе связано

нет

Ну лан , тогда не прав )

100% отказоустойчивости не бывает. 2-3 на 500 запросов это прям норм показатель.

Тупанул кстати. Мне важно было чтобы при деплое запросы к апи не обрубались у пользователей. В нгиксе же настроен тайм-аут на ожидание ответа, который помогает избежать эту ситуацию. А вот что бы фронт сохранить доступным при деплое, может можно сделать фронт-заглушку со страницей типа "Идет обновление сервиса....". Ток хз, можно в компоузе как-то указать, что надо подрубать фронт заглушку, если основной фронт ещё не запущен

В компоузе никак

А какие варианты реализации этой идеи могут быть?

а как юзеры идут на приложение? по доменному имени? кмк только костыли с редиректом через днс на заглушку. но это уже все в не композа

Два app, один из них в nginx описан как backup upstream Обновляешь основной app, nginx видит, что он не доступен , шлёт запросы на запасной app Обновил основной, он заработал, трафик переключился на основной, обновил запасной

Ага домен. Ну редирект тогда придется на другой домен делать или поддомен где страничка заглушка будет. Как вариант да

Во, примерно такое думалось, спасибо изучу)