Docker: Datenbanken...Einsteigerfrage

[the other]

Moinsen,
wie ja vielleicht bekannt, kenne ich mich wenig aus mit Docker und Co. Auch das Thema "Datenbank" ist für mich mehr ein ominöses "Ja, so etwa..." anstatt Erfahrung und Theoriewissen.
Ich arbeite bevorzugt mit docker-compose.yml und Stacks (unter Portainer). Einige Anwendungen sind ja auf Datenbanken im Hintergrund angewiesen und bringen diese direkt mit (zB https://docs.paperless-ngx.com/setup/ und https://nginxproxymanager.com/setup/). Nun laufen also in diesen containern die jeweiligen Datenbanken. Alternativ, habe ich gelesen, könnten diese auch ausgelagert werden in eine (im eigenen container laufende) zentrale Datenbank bzw einen zentralen DB Server, der für jeden Container die Datenbank bereitstellt.
Aktuell: Alle durch die Container genutzten Ordner werden gemappt, so dass die Daten konsistent sind, auch wenn der Container nicht mehr aktiv / da. Die Container haben je ihre eigene mitgebrachte Datenbank im Hintergrund, die im selben Container ist und direkt "mit installiert" wird.
Ich selber nutze Docker container absehbar weiter, allerdings rein privat und im überschaubaren Ausmaß. Daher bin ich unsicher, wie am Besten vorgehen...

Meine Fragen an die anderen Menschen hier:
a. bei einem so überschaubaren Einsatzbereich: die jeweiligen Datenbanken einfach so belassen (direkt in den jeweiligen Containern, also unverändert)?
oder
b. einen Container mit Datenbank (zb postgres mit pgadmin als docker-compose.yml) als zentrale Instanz für die anderen Container?
oder
c) je Container (der eine db benötigt) einen Container mit einer laufenden Datenbank nur für die jeweilige Anwendung?

Unsicher weil:
alles so belassen...verbraucht mehr Leistung (mehr RAM) (hörte ich beim Recherchieren)?
EINE zentrale Datenbank...ein Single Point Of Failure (SPOF), fällt dieser Container aus, alles andere auch offline/ nicht brauchbar und erschwerte Fehlersuche...(welche Anwendung streikt?)
je ein DB Container pro Anwendungscontainer....aufwändig, wo liegt dann der Vorteil genau zu "alles so belassen"?

Ihr erkennt schon an den Fragen: wenig Ahnung, aber durchaus nicht unmotiviert.
Danke für euren erneuten Input!

 

[blurrrr]

Also dass die DBs direkt in den App-Containern sind (a), sieht man eher selten. Das jeder Stack einen eigenen DB-Container mitbringt ist recht weit verbreitet (c), die meisten gehen aber auch nur einfach hin und kopieren sich den Inhalt eines compose-Files, wo dann zwangsläufig auch nochmal ein DB-Container enthalten ist - macht es allerdings einfacher beim copy/paste. Einen einzelnen DB-Container mit mehreren Datenbanken zu nutzen (b), hat auf der einen Seite natürlich den SPOF-Nachteil, auf der anderen Seite ist es aber auch leichter zu warten (Thema DB-Backups). Problematisch "könnte" es beim letzteren Teil allerdings sein, wenn verschiedene Container verschiedene DB-Versionen/-Arten haben wollen (z.B. MySQL/MariaDB vs. Postgres).

Unter'm Strich muss man halt schon sagen: "Es kommt darauf an...". Hast Du 10 Container, die alle MySQL wollen und einen der Postgres haben möchte, könnte man für die 10 Container schon einen einzelnen DB-Container mit den entsprechend benötigten Datenbanken bereitstellen. Da könnte man dann auch direkt wieder einen Stack nutzen, wo z.B. phpmyadmin direkt integriert ist und/oder alternativ ggf. auch direkt in regelmässigen Abständen Datenbank-Backups erzeugt und verschoben werden.

Wenn Du für jeden Stack eine eigenen eigenen DB-Container laufen lässt, hättest Du diesen Aufwand halt direkt mal X, natürlich nur, sofern diese DBs dann auch einer Sicherung würdig sind. Ich persönlich nutze Datenbanken in Containern eigentlich nur bei Dingen, die nicht wichtig sind (oder grade nur ausprobiert werden), ansonsten gibt's da eher eine eigene VM für und je nach Wichtigkeit ggf. auch mit Replikation).

Was den SPOF angeht... wenn es Dir den DB-Container/die DB-VM zerschiesst, biste natürlich auch angeschmiert (je nachdem, wie wichtig Dir diese Dinge dort sind).

Also so ganz generell würde ich mal sagen: Ist erstmal in Ordnung wie es ist. Wenn es Dich zur Zusammenfassung drängt, probier es einfach mal mit ein paar Test-App-Containern aus (DB halt als extra Container oder VM). Wenn alles gefällt, kannst Du den Rest ja noch umstellen

 

[Confluencer]

Ich kann mich da @blurrrr nur anschließen.

Auf der Arbeit sind Datenbanken im Container für Produktivanwendung nicht zulässig. Selbst bei Testumgebungen wird es nicht gerne gesehen, weil Abnahme-Umgebungen nahe an der Produktion sein müssen. Bei Entwicklermaschinen ist es dagegen okay, wenn ihre Datenbank(en) als Container betreiben. Allerdings muss man auch sagen, dass Datenbanken bei den Hyperscalern einen einfachen Snapshot/Restore und Backup Mechanismuss mitbringen, bei dem man schön blöd wäre ihn nicht zu nutzen ^^

Privat finde ich es okay Datenbanken im Container zu betreiben. Ob eine zentrale oder je Anwendung eine ist imho Geschmackssache.

Ausprobieren und schauen was einem besser gefällt. Wenn man mit der gewählten Variante nicht mehr zu frieden ist: dump ziehen und jeweils in die andere Variante importieren. Es bleibt dabei nicht aus, dass man ein wenig was über Datenbanken lernen muss. Das wird bspw. bei Postgres schon notwendig, wenn man von einer Minor Version auf die nächste geht.