Docker: Ein Image, ein od. mehrere Container (ggf. Hyper-V isoliert) u. eine lokale Datenbank-Installation

[Kerchner]

Hallo ,

beschäftige mich nun etwas mit Docker. Da ich aber noch viel Zeit benötige um da komplett durchzublicken, haben sich aber dennoch vorab Fragen ergeben auf die ich gerne schon eine Antwort hätte (die ich mir leider selbst durch googeln nicht wirklich beantworten kann) - nicht, dass ich jetzt so viel Zeit da reinstecke und am Ende ist es doch nicht mit Docker machbar.

Gehen wir von folgender Situation aus:
1 Docker Image (beinhaltet einen Dienst/Service; welcher Dienst ist erstmal egal; z.B. Videokonferenz-Software oder CMS wie WP etc.)
1 lokale Datenbank-Installation

Nun könnte ich entweder einen (Bild 1) oder mehrere Docker-Container (Bild 2 bzw. Bild 3) starten.
Über Subdomain 1, Subdomain 2, Subdomain n müsste man den Dienst in dem jeweiligen Container erreichen können.
Dazu müsste man wohl einen Reverse Proxy einrichten?!

Der Docker-Container bzw. jeder Docker-Container soll/en auf die lokale Datenbank (die nicht in einem Container läuft, aber per volumes eingebunden werden muss?) zugreifen können. Jeder Container hat dazu aber seine eigene Datenbank (Bild 2 bzw. Bild 3) in der DB-Installation!

Ggf. zusätzlich, dass jeder Container per Hyper-V isoliert ist (Bild 3) und in ein und demselben Docker-Netzwerk liegt.
Wie aber bekäme ich dann Zugriff von jedem dieser Container auf die lokale DB-Installation?

Falls ich dazu Docker Compose nutzen sollte, genügt es dann die IP da in den Environment-"Details" für die DB einzutragen?

Was ich vermeiden wollte ist jedem Container einen Port (z.B. 8080, 8081, 8082, n) zuzuweisen nur um damit die Subdomain's zu "bedienen".

 

[efcoyote]

Vielleicht kann ich zumindest einige Fragen beantworten.
Ein Image ist eine "Schablone" für Container und läuft nicht in dem Sinne. Das was läuft ist ein Container und zwar als Prozess auf dem Host (im Hyper-V ggf. gekapselt durch eine VM).

Wenn du einen Dienst unter www.foobar.de/app1 anbieten willst, dann muss unter der IP-Adresse von www.foobar.de auf dem Port 80/443 ein Dienst auf Anfragen reagieren. Willst du nun mehrere Container an diesen gleichen Port anbinden, dann bietet sich, wie du richtig erkannt hast, ein Reverse Proxy (nginx, traefik) an. Dieser sollte praktischerweise auch gleich als Container laufen. Alternative wäre soetwas unschönes wie www.foobar.de:8081

Jeder Container ist in ein docker-network eingebunden und hat ein oder mehrere IP-Adressen. Dies ermöglicht es ihm mit anderen Containern oder anderen Netzen (Host, Internet) zu kommunizieren. Wenn die Container im gleichen docker-network sind können sie einfach über ihren Containernamen erreicht werden und man muss nicht die interne IP kennen.

Würde man die Datenbank auch als Container laufen lassen, was ganz klar die Empfehlung ist, dann wäre die Verbindung der Dienste zur Datenbank ein leichtes. Wenn es eine lokale Datenbank auf dem Host sein soll, dann wirst du sichergehen müssen, das die Routen vom Container zum Host korrekt eingerichtet sind. Das kann je nach Konstellation (Windows, Hyper-V, Linux-VM) einige Probleme bereiten.

Und volumes haben mit der ganzen Geschichte erstmal nichts zu tun.

 

[Kerchner]

Erstmal Danke, dass wenigstens einer (schon) was geschrieben hat.

Ein Reverse Proxy würde ich dann schon als Container laufen lassen.

Im Internet wird klar davon abgeraten eine DB als Container laufen zu lassen, da Conatiner und die Daten darin nicht persistent sind. Würde der DB-Conatiner angehalten und gelöscht werden wären die Daten unwiderruflich weg!
Daher würde ich die DB ungern als Container laufen lassen.
Sicherlich wäre es einfacher... geht aber wohl eher auf Kosten der "Sicherheit".

Hoffe das sich noch andere hier beteiligen und was dazu schreiben.

Was ist mit meiner Frage zu docker compose und den Env-Werten?
Welche Konstellation (von den 3 Szenarien, siehe Bilder oben) wäre denn am sinnvollsten und warum?

 

[efcoyote]

Die Daten der Datenbank sollte man natürlich persistent speichern. Ohne eine entsprechende Möglichkeit wäre das ganze Container-Zeug arg sinnlos.

Das ganze nennt sich "mounten" und wird auch z.B. bei MariaDB unter "Where to Store Data" erklärt.
Deine 3 Diagramme sind irgendwie jedes fürs sich falsch bzw. unverständlich, weswegen ich darauf nicht eingegangen bin.

Docker-Compose unterstützt die Angabe von ENV-Variablen (siehe Dokumentation). Das Thema Geheimnisse (Secrets) und Docker ist allerdings ein Kapitel für sich. Die Grundlagen stehen auch in der verlinkten MariaDB Doku.