Docker <-> VM

Avenger84

Lt. Commander
Registriert
Feb. 2008
Beiträge
1.506
Hallo, ich habe noch nie Docker benutzt um es Vorweg zu nehmen.
Ich baue mir ein NAS mit Unraid und dort gibt es massig Docker für alles.

Ich verwende z.B. Node-Red mit Influxdb und Grafana. Alles gibt es als Container.
Auf dem RPi bzw. in der VM läuft alles parallel, ich kann in Node-Red/Grafana als Datenbank 127.0.0.1 / localhost eintragen und gut.

Wenn ich nun Docker verwende, bekommt jeder Docker Container eine eigenen IP und ich muss dann mit der Datenbank Abfrage über den Router gehen.

Sehe da keinen Vorteil, außer dass eine VM aufzusetzen länger dauert (einmalig).

Wie ist es z.B. mit PiHole? Das müsste dann auch eine eigene IP bekommen ?
 
Du solltest einen Virtuellen Switch erstellen können und auch alle Container da drin verbinden können. So hast du dann nur 1 IP und verschiedene Ports.

Müsste bei Unraid gehen da es auch bei jedem anderen NAS / Vhost geht
 
Avenger84 schrieb:
Wenn ich nun Docker verwende, bekommt jeder Docker Container eine eigenen IP und ich muss dann mit der Datenbank Abfrage über den Router gehen.
Du kannst, z.B. mit docker-compose auch ganze Umgebungen erstellen, die alle im selben virtuellen Netz haengen und gar nicht erst nach aussen exposed sind.
Avenger84 schrieb:
Sehe da keinen Vorteil, außer dass eine VM aufzusetzen länger dauert (einmalig).
Leichtgewichtiger, also weniger Ressourcenoverhead. Dazu musst du nicht die VMs updaten und managen. Dazu ist es portabler. Du musst nur das/die Volumes sichern und dein docker-compose file und kannst es auf andere systeme verschieben.
 
  • Gefällt mir
Reaktionen: Raijin und SaxnPaule
Avenger84 schrieb:
Wenn ich nun Docker verwende, bekommt jeder Docker Container eine eigenen IP und ich muss dann mit der Datenbank Abfrage über den Router gehen.
In der Regel werden Docker Container, oder besser die Applikationen darin, über die IP des Host und einen Port angesprochen. Die Ports müssen natürlich eindeutig sein. Wenn du IPs für Container vergeben möchtest, kannst du auch welche aus dem Subnetz des Hosts vergeben. Dann geht nichts über einen Router.

Avenger84 schrieb:
Sehe da keinen Vorteil, außer dass eine VM aufzusetzen länger dauert (einmalig).
Wie immer gilt: Beides hat Vor- und Nachteile.

Avenger84 schrieb:
Wie ist es z.B. mit PiHole? Das müsste dann auch eine eigene IP bekommen ?
Muss nicht. Kannst ja einfach den DNS Port an den Container reichen.
 
Standardmäßig erhalten die Container keine eigenständige (öffentliche) IP, sondern nutzen die IP des Hosts.

Es ist jedoch möglich, virtuelle Netzwerke zu erstellen, in denen sich zusammengehörige Container miteinander verständigen können. Das Erstellen geht mit Docker Compose hervorragend.

Hier ein Beispiel von Nextcloud. https://github.com/nextcloud/docker...ginx-proxy/postgres/apache/docker-compose.yml
Hier sind nur Port 443 und 80 geöffnet


Ob Unraid mittlerweile jedoch Docker Compose direkt integriert hat, entzieht sich meinem Wissen.
 
Ich empfehele auch docker-compose zu nutzen und zusammengehörige Applikationen in einem Container zu fahren. Nach außen erreichbare Ports müssen separat exposed werden. IP haben alle Container nach außen hin die gleiche (die des Hosts).
 
Du kannst bei Docker z.B. auch feste IPs vergeben.
Der Einsatz eines virtuellen Switches (custom network) macht dich da sehr flexibel. Innerhalb dieses Netzes kannst du auch einfach über den Namen auflösen.
Einzige ist halt das die Ports nach außen sich nicht überschneiden dürfen.
PiHole läuft bei mir als Docker auf unraid ohne Probleme da die DNS Ports eh frei sind und 1:1 durchgeroutet werden können. Einzige Nachteil ist, das wenn Unraid bzw. der Dockercontainer nicht läuft, hat man halt kein DNS. Ist aber für mich vernachlässigbar.

Großer Vorteil, meiner Meinung nach, ist die Trennung von Daten und Applikation. Das macht z.B. das Backup und das Update extrem einfach.
 
SaxnPaule schrieb:
Ich empfehele auch docker-compose zu nutzen und zusammengehörige Applikationen in einem Container zu fahren.
Ich vermute, du hast dich nur vertippt, aber man packt NICHT mehrrere Anwendungen in einen Container, sondern alle zusammenhaengende Container in eine Umgebung.
 
  • Gefällt mir
Reaktionen: schwimmcoder und SaxnPaule
wenn es eine neue Version für Grafana gibt, wie läuft das dann mit dem Update ?
 
Docker bietet verschiedene Netzwerkmodi, so wie es auch bei VMs der Fall ist. Man kann also selbst entscheiden wie ein Container mit dem Netzwerk verbunden ist, sei es rein lokal im Host oder gar als eigenständiger Teilnehmer inkl. MAC-Adresse im Netzwerk des Hosts. Hier wird das etwas detaillierter erklärt.
 
NJay schrieb:
Leichtgewichtiger, also weniger Ressourcenoverhead. Dazu musst du nicht die VMs updaten und managen. Dazu ist es portabler.
Musste ich auch feststellen. Auf meinem TS-673A habe ich für jeden Dienst eine eigene VM mit Debian gehabt. Anfänglich ganz in Ordnung, allerdings nicht ressourcenschonend und am Ende administriert man nicht nur den Dienst, sondern auch die Betriebssysteme.

Aus diesem Grund bin ich in meinem Fall auf die Container Station gewechselt. Die Handhabung und Administration geht wesentlich schneller.

NJay schrieb:
Du musst nur das/die Volumes sichern
Dafür nutze ich zum Beispiel Freigabeordner, um dem Sichern von Volumes aus dem Weg zu gehen.
 
Avenger84 schrieb:
wenn es eine neue Version für Grafana gibt, wie läuft das dann mit dem Update ?
Du hast gerade einen Nachteil der Container entdeckt. Wenn der "Anbieter" des Containers die darin enthaltenen Applikationen nicht pflegt und eine neue Version "seines" Containers anbietet, dann wird es schwierig mit einem Update. Aus Security Sicht sind deshalb solche Container u.U. großer Mist.

Wenn Grafana eigenständig im Container läuft ist das Update relativ einfach. Wird es aber zusammen mit anderen Applikationen und angepasster Konfiguration in einem "Dritt"-Container betrieben, muss man i.d.R. hoffen, dass der Ersteller des Containers ein Update liefert.
 
ok, würde sagen ich bleibe doch bei einer VM für die Kombination Node-Red / Influx / Grafana & Wireguard. Läuft seit Jahren problemlos auf dem RPi. Manchmal haut Grafana eine Version mit Fehlern raus, aber mit einem Befehl kann man die Vorgängerversion wieder installieren. Zuletzt war nur die ARM Version davon betroffen.

Sehe für mich keine Vorteile beim Docker.

Mit der Hardware (i5 8400T und 32GB Ram) lassen sich wohl ohne Probleme mehrere VM erstellen, falls ich mal experimentieren will.
Docker kann ich ja davon unberührt auch noch ausprobieren.
 
  • Gefällt mir
Reaktionen: BeBur
Avenger84 schrieb:
Manchmal haut Grafana eine Version mit Fehlern raus, aber mit einem Befehl kann man die Vorgängerversion wieder installieren. Zuletzt war nur die ARM Version davon betroffen.
Das kannst du auch mit docker machen, einfach das alte Image starten.
 
Ich habe Mal TeamSpeak Docker ausprobiert und bin erstaunt wie schnell und einfach das läuft. Wow.

Was ich nicht ganz verstanden habe ist der Unterschied zwischen bridge und Host Netzwerk Einstellung.
In bridge ist eine andere IP zum Unraid vorgeschaltet.
Wie ich das verstanden habe kann dann jeder Container mit jedem Container kommunizieren in dem 172.x Netz.
Aber sollte nicht eigentlich genau das nicht möglich sein, sondern alle Container isoliert gegenseitig.
 
Avenger84 schrieb:
Wenn ich nun Docker verwende, bekommt jeder Docker Container eine eigenen IP und ich muss dann mit der Datenbank Abfrage über den Router gehen.
Das ist falsch. Die haben zwar IP-Adressen aus deinem Heimnetz, wenn du sie dem br0 Netzwerk zuordnest, der Traffic verlässt aber nicht die Maschine.

Avenger84 schrieb:
Wie ich das verstanden habe kann dann jeder Container mit jedem Container kommunizieren in dem 172.x Netz.
Aber sollte nicht eigentlich genau das nicht möglich sein, sondern alle Container isoliert gegenseitig.
Du kannst zb per Kommandozeile neue benutzerdefinierte Netze erstellen. Container, die dann in dem Netz liegen, können dann nicht mit Containern aus anderen Netzen kommunizieren.

Zb kann man so den Datenbank Container von Nextcloud nur über Nextcloud erreichbar machen.

In unRAID wird das aber kaum genutzt, da es benutzerfreundlich sein soll und die meisten bereits mit den paar Standardnetzen überfordert sind.

Der Mehrwert in Sachen Sicherheit ist aber auch gering. Es müsste ja jemand zb den Grafana Container hacken und dann nach einer Sicherheitslücke des Nextcloud Datenbank Containers suchen. Und das wegen einer popeligen privaten Nextcloud. Welcher Angreifer verschwendet dafür schon seine Ressourcen. Einen Bitcoin holt der sich damit sicher nicht ;)

Ich nutze übrigens ausschließlich Host und Bridge Netzwerke ohne feste IP Adressen aus meinem Heimnetz. Beispiel:

Screenshot_20230929-081112.png


Und nur damit das klar ist: Die internen 172 IP-Adressen darf man nicht zb bei Datenbank Logindaten hinterlegen. Je nach Startreihenfolge der Container, ändern sich diese nämlich. Also wenn hinterlegt man Unraid's IP + Port. Und ja, auch dieser Traffic verlässt nicht den Server.

Avenger84 schrieb:
Sehe da keinen Vorteil, außer dass eine VM aufzusetzen länger dauert (einmalig).
Eine VM verursacht durchgehend mehr Last und reserviert sich Ressourcen. Hast du zb eher VM 4GB RAM zugewiesen, dann sind die weg. Laufen mehrere VMs, zieht das System gerne mal 20 bis 40W im Leerlauf.

Backups von Containern sind dazu deutlich kleiner, weil man nur die Nutzerdaten (in unRAID appdata) sichern muss, während man bei einer VM das komplette Image zB 32GB sichert. Inkrementell sichern ist da manchmal gar nicht möglich, je nachdem wo sich im Image die Daten geändert haben.

Als letztes wäre noch der Zugriff auf die Dateien ein interessanter Punkt. Du kannst zb über den Dateiexplorer von unRAID die Config Datei eines Containers bearbeiten. Bei der VM muss du dich erstmal in der VM selbst anmelden und je nach VM gibt es keinen Desktop und du musst dich mit deren Kommandozeile herumschlagen.
 
  • Gefällt mir
Reaktionen: alturismo und Avenger84
mgutt schrieb:
Eine VM verursacht durchgehend mehr Last und reserviert sich Ressourcen. Hast du zb eher VM 4GB RAM zugewiesen, dann sind die weg. Laufen mehrere VMs, zieht das System gerne mal 20 bis 40W im Leerlauf

habe nun Ubuntu Server als VM am laufen (mit Node-Red und Influxdb), nun ist der Stromverbrauch von 3,5W auf 4,2W gestiegen - damit kann ich leben. (minimaler Leerlaufverbauch)

Paar Docker habe ich auch am laufen (mini DLNA, TS3, Duplicati).
 
NJay schrieb:
Dazu ist es portabler. Du musst nur das/die Volumes sichern und dein docker-compose file und kannst es auf andere systeme verschieben.
Naja. Das mit dem portabler gilt auch nur, wenn das Zielsystem docker supportet.
Docker-Images sind also nicht per se protabler.
Vielleicht meinst Du aber auch was anderes mit Portabilität.

mgutt schrieb:
Eine VM verursacht durchgehend mehr Last und reserviert sich Ressourcen. Hast du zb eher VM 4GB RAM zugewiesen, dann sind die weg.
Das kann man so pauschal nicht sagen. Gerade dein RAM-Beispiel passt auf aktuelle Virtualisierer gar nicht mehr.
Dann gibts auch noch so was wie MicroVMs wo das Ressourcenargument kaum noch zieht.

mgutt schrieb:
Inkrementell sichern ist da manchmal gar nicht möglich, je nachdem wo sich im Image die Daten geändert haben.
Wieso sollte das nicht gehen?

mgutt schrieb:
Du kannst zb über den Dateiexplorer von unRAID die Config Datei eines Containers bearbeiten. Bei der VM muss du dich erstmal in der VM selbst anmelden und je nach VM gibt es keinen Desktop und du musst dich mit deren Kommandozeile herumschlagen.
Dateien innerhalb des VM-Images bearbeiten ohne die VM zu starten kann ich auch, indem ich das Image mounte.
 
Zurück
Oben