Михаил

docker-compose up --force-recreate

RTFM

Неважно. В любой момент вы можете собрать ваш проект в docker image и далее использовать его любым угодным вам образом.

В случае spring (и вообще java/kotlin), см. jib-gradle-plugin или jib-maven-plugin в зависимости от используемой системы сборки.

Вы не очень понимаете что такое образ докера. Образ докера содержит всё для запуска приложения, кроме ядра ОС (ядро используется из хост-системы). А в зависимости от того как собирали образ - может быть и что-то лишнее, нафиг не нужное для запуска приложения. Но автору образа было лень это выпиливать из него (или он на это забил). Собственно вот и вся разница. И те библиотеки, которые у вас уже есть в системе (и которые вы не учитываете при расчетах занимаемого им места) - докер притащит с собой (это наверняка будут другие версии библиотек, но факт в том что он их с собой притащит). Например, если вы говорите о Java-приложении, в системе наверняка есть JVM. И вы увидите только размер jar-файла и каких-то обвязок вокруг него. А в докере это будет плюс JVM, плюс библиотеки для JVM, плюс, плюс, плюс... Вот и набегает размер образа.

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

Зависит от того сколько планируется запускать контейнеров и каких
Но из общих соображений - больше ядер процессора (8 ядер/16 потоков), больше оперативки (16 и более гигабайт)

1. Использовать volume
2. Либо убедиться что каталог существует: mkdir -p <directory> && docker ...
3. Либо назначить нужного владельца каталога:

mkdir -p <directory> && chown 1000:1000 <directory> && docker ...

Если это запускается не рутом - в п.3 потребуется использовать sudo.

А зачем вам гит на vps? Должен быть какой-то один "источник правды".

Мне кажется что история должна быть такой: git server (github/gitlab/etc) -> local repository -> rsync to vps -> volume to docker

Соответственно, когда вы меняете ветку в локальном репозитории - rsync видит изменения файлов и синхронизирует их с vps, который ничего про гит не знает - для него это просто набор файлов.

Как вариант - выдать каждому воркеру свой докер-контейнер. А общий для них node_modules смонтировать как volume (я так подозреваю можно даже смонтировать как read-only).

Принцип следующий:

1. Делаете контейнер с фронтом-балансировщиком (nginx или что-то подобное).
   
2. Запускаете второй контейнер с бэком, содержащий новую версию.
   
3. Новый контейнер подключается к балансировщику. Тут дальше возможны варианты - балансировщик автоматически начинает переводить траффик на новую версию. Или в каком-то соотношении. Или только тестовый трафик. Или переключаете балансировщик на новый контейнер вручную. Или... (в общем вариантов тут много). Идея в том, чтобы перейти в целевое состояние - запросы обрабатывает новый бэкэнд. На этом этапе старая и новая версия бэкэнда должны уметь работать параллельно, то есть часть запросов может обрабатываться старой версией, часть новой, что налагает на новую версию требование сохранения обратной совместимости со старой версией (в частности это ограничивает возможные изменения структуры БД). В любой момент, если новая версия заработала как-то не так, можно "вертать всё взад", то есть опустить контейнер с новой версией и вернуть весь трафик на старую.
   
4. Убедившись что новая версия работает стабильно, переводите с балансировщика весь трафик на новую и опускаете контейнер со старой версией, оставляя контейнер с новой единственным.
   

Не очень понимаю что вы подразумеваете под контейнером с фронтендом, если это просто веб-сервер, который раздает SPA-приложение (HTML/CSS/JS), то в принципе аналогично.

Схема такого апгрейда не слишком проста в реализации, поэтому такой апгрейд (zero-downtime upgrade) применяется в энтерпрайзе, в котором никак нельзя допустить простоя в обслуживании. Поэтому смотрите сами - насколько те несколько секунд (максимум минут) простоя за которые запускается новый контейнер стоят этой возни. Если такой апгрейд действительно нужен, то советую вместо docker compose посмотреть в сторону kubernetes.