Kompletna aplikacja, django+postgres+react zapakowane w docker-compose

Cześć,
mam pytanko dotyczące wdrażania aplikacji webowej. Nie mam totalnie doświadczenia w tej kwestii a jestem bliski dokończenia mojej aplikacji łączącej backend w django i frontend w reakcie.
Każdy z elementów mam zapakowany do kontenera (tzn oddzielnie dla react, django i postgres, użyłem też nginx do przekierowywania portów)
Lokalnie mam dwie wersje docker-compose - jedną totalnie developerską (bez nginx), drugą - z nginx - powiedzmy powoli przygotowywaną pod produkcję.

Powyższa aplikacja webowa - do komunikacji z użytkownikiem.
Mam też dwie dodatkowe aplikacje do przetwarzania danych, wymagane do dzialania aplikacji, które są po prostu skryptami napisanymi w pythonie, pobierają dane z bazy (m.in o użytkownikach) przetwarzają dane, asynchronicznie obsługują użytkowników, wyniki wracają do bazy.

Moje pytania:

1. Czy warto na produkcji bawić się w docker-compose?
2. Jeśli tak to czy każdy z elementów powinien być uruchomiony w kontenerze? Z tego co widzialem w sieci niegdyś panowało przekonanie, zę kontener do bazy danych ble - bo kolejny klocek który trzeba zarządzać i teoretycznie może się zepsuć.
3. Wstępnie, podczas początkowego wdrożenia planuję użyć maszyny wirtualnej na Google Cloud Platform - całość uruchomię używając docker-compose i będę testować aplikację (z użytkownikami itp). Tam też uruchomię pozostałe aplikacje mające za zadanie przetwarzanie danych i wysyłanie wyników na konkretne endpointy.
4. Co powinno być kolejnym krokiem? Nie za miliony monet, a bezpieczne i z sensem? Wydzielać każdą z aplikacji? W sensie aplikację webową postawić na jakimś konkretnym serwerze, bazę danych też oddzielnie (np Azure ma opcję uruchomienia postgres), a aplikacje do przetwarzania danych jeszcze gdzie indziej?
5. No i finalnie jaki serwer polecacie do tego typu aplikacji?

PS. Wszelkie uwagi miło widziane.

Pozdrawiam!

Jak już masz plik docker-compose i chcesz uruchomić na produkcji, to już lepiej w swarm mode. Tylko musisz mieć plik docker-compose.yml w wersji 3.x.
Odpalasz tryb swarm
docker swarm init - to wystarczy odpalić tylko raz.
i potem
docker stack deploy -c ./docker-compose.yml jakasnazwacosobiejawymyslisz

Co do samego django i reszty, ja to zwykle robię tak.

Mam 4 kontenery.

1. Ten z django, czyli cała aplikacja
2. Ten z bazą danych, tutaj postgres
3. Ten bazą danych do cache i do sesji, tutaj redis
4. Reverse proxy i serwer plików statycznych i plików "media" - tutaj nginx

Ostatnio dorzuciłem jeszcze Traefik przed nginx jako reverse proxy, wtedy nginx pełni tylko funkcję serwera plików statycznych.

Wszystkie obrazy kontenerów wrzucam do docker-registry na githubie, jest to darmowe (do pewnej powierzchni), nie muszę wtedy budować obrazów na maszynie produkcyjnej, tylko wszystko się zaciąga z githuba. Ułatwia to też aktualizację kontenerów.

Co do twoich pytań.

1. Tak warto, ułatwia to parę rzeczy a nie jest przekombinowane jak kubernetes.
2. Baza danych bez kontenera to też klocek którym trzeba zarządzać, nie widzę tutaj różnicy. Tylko oczywiście pliki bazy danych z kontenera musisz zamontować na jakimś "volume" na hoście (serwerze), żeby Ci bazy szlag nie trafił jak będziesz stawiał na nowo kontener.
3. Jak nie tworzysz nowego Facebooka, a nie planujesz mieć milionów użytkowników, to jeden serwer wystarczy. Chyba że nie możesz sobie pozwolić, że raz na rok aplikacja nie będzie działać przez 15 minut. Dodatkowo jakiś serwer na backupy bazy danych, może coś do monitoringu (Prometheus, Grafana, czy tam ELK stack). Wszystko zależy od wymagań. Nie ma co na początek przekombinować, a jak masz wszystko to kontenerach, to potem skalowanie tego nie jest takie trudne.
4. Zależy od budżetu, najtańsze opcje to OVH, Hetzner, Linode. Droższe, to coś w stylu Digital Ocean, a najdroższe to te dużych graczy (GCP, AWS, Azure).