Принцип следующий:
- Делаете контейнер с фронтом-балансировщиком (nginx или что-то подобное).
- Запускаете второй контейнер с бэком, содержащий новую версию.
- Новый контейнер подключается к балансировщику. Тут дальше возможны варианты - балансировщик автоматически начинает переводить траффик на новую версию. Или в каком-то соотношении. Или только тестовый трафик. Или переключаете балансировщик на новый контейнер вручную. Или... (в общем вариантов тут много). Идея в том, чтобы перейти в целевое состояние - запросы обрабатывает новый бэкэнд. На этом этапе старая и новая версия бэкэнда должны уметь работать параллельно, то есть часть запросов может обрабатываться старой версией, часть новой, что налагает на новую версию требование сохранения обратной совместимости со старой версией (в частности это ограничивает возможные изменения структуры БД). В любой момент, если новая версия заработала как-то не так, можно "вертать всё взад", то есть опустить контейнер с новой версией и вернуть весь трафик на старую.
- Убедившись что новая версия работает стабильно, переводите с балансировщика весь трафик на новую и опускаете контейнер со старой версией, оставляя контейнер с новой единственным.
Не очень понимаю что вы подразумеваете под контейнером с фронтендом, если это просто веб-сервер, который раздает SPA-приложение (HTML/CSS/JS), то в принципе аналогично.
Схема такого апгрейда не слишком проста в реализации, поэтому такой апгрейд (zero-downtime upgrade) применяется в энтерпрайзе, в котором никак нельзя допустить простоя в обслуживании. Поэтому смотрите сами - насколько те несколько секунд (максимум минут) простоя за которые запускается новый контейнер стоят этой возни. Если такой апгрейд действительно нужен, то советую вместо docker compose посмотреть в сторону kubernetes.
