Es scheiden sich die Geister, ob man einen Datenbankcontainer für alle Anwendungen, die einen benötigen, macht und diesen überall einbindet, oder jedem Applikationscontainer seine eigene DB mitgibt. Ich finde das zweite Modell - auch wenns mehr Ressourcen benötigt - sinnvoller, da dann die Apps eigenständig sind und sich nicht gegenseitig beeinflussen können.
In der Tat, ich war historisch ein Freund einer dicken (Postgres) Datenbank irgendwo für alles, weil ich fand, daß Tuning, Datensicherung, Monitoring dann einfacher sind. Doch jetzt, wo ich Container gerne mal neu und isoliert aufbaue, stellt der Datenbank-Krempel (Export, Teilimport, Kopie, was auch immer) einen zusätzlichen Schritt dar, den ich mir mit getrennten Datenbank-Containern je Service spare. Dito für redis, mongo, was auch immer.
Sicherheitsproblem in irgendeiner verwendeten Bibliothek? Bei Docker muss man erst einmal warten, bis das in zig Images behoben wird. (Oder selbst bauen, aber dann gehen viele Vorteile wieder verloren, weil man erst mehr Aufwand hat.)
Selbst bauen: ist doch einfach, wenn man in der docker-compose.yml das korrekte build script von github gleich mit einbaut, wie in:
image: tiredofit/nextcloud:27-latest
build:
context: https://github.com/tiredofit/docker-nextcloud.git#27-3.6.10
args:
NEXTCLOUD_VERSION: 27.1.3
Eine weitere Hilfe ist mir eine zentrale .env Datei, die in die Unterverzeichnissen meiner services hineingelinkt ist.
Mir ist aber schon klar, daß das mit Kubernetes noch viel schöner wäre. Wenn ich dann in Rente bin, hab ich Zeit dafür.