LXC <-> Docker für dumme

[mstefan]

Hallo Forengemeinde.

ich benötige ein wenig Aufklärungsarbeit von euch, da ich irgendwie einen Knoten im Kopf habe.

Mein aktueller Setup:
Proxmox Host mit Ubuntu VM, alles jeweils auf der neusten Version.
In der VM ist docker installiert und dort laufen alle meine Services.
d.h. aber auch, starte ich die VM neu, sind alle Services weg, nicht nur einer.

Deshalb bin ich mittlerweile am überlegen, meinen Setup auf lxc umzustellen,
(Netter nebeneffekt wäre hier auch, dass der Server ohne VM ca. 18 Watt weniger zieht)
Hier hab ich allerdings einen Knoten im Kopf und ein paar Verständnisprobleme.

1. In Docker arbeite ich mit Docker Compose, sehe ich das richtig, dass ich bei LXC keine "Bauanleitung" wie die Compose Dateien habe, sondern jeden Container wie ein frisches System behandeln muss und den/die gewünschte/n Service/Software installieren muss um zum selben Ergebnis zu kommen?
2. Bei Docker habe ich alle persistenten Daten in named Volumes liegen, diese überleben auch beim Zerstören des Containers. Bei LXC ist ein über die GUI eingehangener Mountpoint weg, wenn der Container gelöscht wird. Was ist hier bei LXC vergleichbar? Sind es die nicht über die GUI verwendbaren BindMounts?
   Oder verwendet man bei LXC ein anderes Konzept? Aktuell liegen Daten und Configs jeweils in einem Named Volume, macht man das bei LXC auch so? Oder hat man halt einfach Backups in denen alles drin ist?
3. Wie macht man denn Updates / Upgrades? Bei Docker passe ich meine compose yml an und ziehe dass neue Image, Volumes bleiben bestehen und alles ist auf dem neusten Stand. Bei LXC müsste ich dann immer pro container

   apt update && apt upgrade

   ausführen, wenn die installierte Software in den Paketquellen ist oder?
4. Ist mein Vorhaben aus eurer Sicht überhaupt sinnvoll?
   (Ich sehe häufig solche Sachen wie Unifi Controller, Pihole etc. in LXC Containern)

 

[Dunuin]

In Docker arbeite ich mit Docker Compose, sehe ich das richtig, dass ich bei LXC keine "Bauanleitung" wie die Compose Dateien habe, sondern jeden Container wie ein frisches System behandeln muss und den/die gewünschte/n Service/Software installieren muss um zum selben Ergebnis zu kommen?

Ja, außer du nimmst eines der turnkey templates.

Bei Docker habe ich alle persistenten Daten in named Volumes liegen, diese überleben auch beim Zerstören des Containers. Bei LXC ist ein über die GUI eingehangener Mountpoint weg, wenn der Container gelöscht wird. Was ist hier bei LXC vergleichbar? Sind es die nicht über die GUI verwendbaren BindMounts?
Oder verwendet man bei LXC ein anderes Konzept? Aktuell liegen Daten und Configs jeweils in einem Named Volume, macht man das bei LXC auch so? Oder hat man halt einfach Backups in denen alles drin ist?

LXC wirft man nicht weg zum Updaten. Man aktualisiert sie wie jede andere VM auch. Also im Normalfall muss man keine LXCs löschen, außer man will sie nicht mehr haben.
Und ja, Daten über Bind-mounts bleiben auf dem Host erhalten, wenn man den LXC löscht.
NFS/SMB shares würden auch gehen (welche aber nicht von unprivilegieten LXCs unterstützt werden).

Wie macht man denn Updates / Upgrades? Bei Docker passe ich meine compose yml an und ziehe dass neue Image, Volumes bleiben bestehen und alles ist auf dem neusten Stand. Bei LXC müsste ich dann immer pro container

apt update && apt upgrade

ausführen, wenn die installierte Software in den Paketquellen ist oder?

Genau.

Ist mein Vorhaben aus eurer Sicht überhaupt sinnvoll?
(Ich sehe häufig solche Sachen wie Unifi Controller, Pihole etc. in LXC Containern)

Ist immer Geschmackssache. Ich persönlich mag LXCs z.B. lieber, weil ich kein großer Freund von Appliances bin, wo ich nichts dran ändern darf/kann und auch oft nicht weiß, was der Dienst da genau tut. Gerade bei Containern von Dritten.
Dienste einzeln zu haben ist jedenfalls praktisch. Macht das Backuppen und Migrieren leichter. Aber du hast natürlich auch erhöhten Verwaltungsaufwand, da du den LXC pflegen musst wie jeden anderen Host/VM auch.

 

[Devian242]

Ja, außer du nimmst eines der turnkey templates.

Genau.


Ist immer Geschmackssache. Ich persönlich mag LXCs z.B. lieber, weil ich kein großer Freund von Appliances bin, wo ich nichts dran ändern darf/kann und auch oft nicht weiß, was der Dienst da genau tut. Gerade bei Containern von Dritten.
Dienste einzeln zu haben ist jedenfalls praktisch. Macht das Backuppen und Migrieren leichter. Aber du hast natürlich auch erhöhten Verwaltungsaufwand, da du den LXC pflegen musst wie jeden anderen Host/VM auch.

Für LXC gibt es ja nicht nur die Turnkey-Templates.. Im Netz finden sich viele Scripts die LXC's erstellen und entsprechende Dienste installieren.
Und mit ein bisschen Knowhow kann man die Scripte ja einsehen und sich vergewissern, dass sie auch wirklich nur das tun, was sie sollen.

Und LXC's pflegen... Nun, auch da gibts genug Scripts die die LXCs "durcharbeiten" und aktualisieren. Gerade bei vielen Containern ist das schon eine echte Arbeitserleichterung.

Viele Grüße
Christian

 

[mstefan]

Vielen Dank euch Beiden für die Antworten, das macht es für mich schon etwas klarer.
Ich muss einafch ein wenig mit den LXC rumspielen um mit ihnen warm zu werden

Eine Frage treibt mich aber noch um, ist vielleicht etwas offtopic aber gehört für mich zum Thema:
(Stichworte: Loadbalancer Traefik, Pihole, nextcloud)

Ich habe aktuell interne und externe Websiten.
Pihole ist intern erreichbar (pihole.domain.de) und meine cloud auch von extern (cloud.domain.de).
Daher landen alle Anfragen von Port 80 oder 443 bei meiner VM und dort verarbeitet der Traefik Container alles weiter.
DNS Anfrage auf Port 53 landen auch bei der VM, gehen dann aber zu pihole durch.

Wenn ich das jetzt in lxc umdenke, habe ich ja bswp. den Pihole Container, der seine IP Adresse (x.x.x.10) und den traefik Container (x.x.x.11).
Hier wirds dann für mich verwirrend, möchte ich mich per ssh einloggen, soll die Adresse pihole.domain.de auf die IP des Containers zeigen (x.x.x.10). Rufe ich die Website https://pihole.domain.de muss die Anfrage aber beim traefik Container (x.x.x.11) landen.

In meiner Docker VM ist das easy, weil die IP immer die selbe ist nur die entsprechenden Ports geöffnet werden.

Das hört sich für mich nach "proxmoxunabhängigem" Problem an oder?
Port Forwarding am Router: Alle internen LAN IN Anfragen, die Port 80 oder 443 in das Netzwerk der Container aufrufen, werden auf die IP des Traefik Containers weitergeleitet. (Falls ich so eine Regel überhaupt erstellen kann )

 

[Dunuin]

Naja, Traefik ist doch ein Reverse Proxy. Für verschiedene Webserver würdest du dann je nach Subdomain zu einer anderen IP weiterleiten. Da muss ich also dein Traefik drum kümmern, dass die Anfragen beim richtigen LXC/VM landen. Wüsste jetzt aber keinen Reverse Proxy der auch SSH unterstützen würde. Wenn du aber nur lokal per SSH Zugriff haben willst, würde ich das über deinen lokalen DNS-Server auflösen lassen.

 

[Devian242]

Ich gebe zu das ich mich mit Traefik nocht wirklich auskenne.. Für ein "normales" Setup nutze ich den NginX Proxy Manager.. Der lauscht eh nur auf Port 80 und 443.

VIelleich ein kleiner Gedankenanstoss:

NImm den PiHole als DHCP-Server und trage den PiHole auch als DNS-Server ein. Dann trägst du unter Local DNS deine DIenste mit den entsprechenden IPs ein und fertig. Port 80 und 443 leitest du am Router einfach auf den Proxy Manager weiter und schon ist dein Split-DNS fertig

Port 53 solltest du aber nicht via Internet verfügbar machen. Das mögen einige Provider nicht ^^

Viele Grüße
Christian

 

[Devian242]

Naja, Traefik ist doch ein Reverse Proxy. Für verschiedene Webserver würdest du dann je nach Subdomain zu einer anderen IP weiterleiten. Da muss ich also dein Traefik drum kümmern, dass die Anfragen beim richtigen LXC/VM landen. Wüsste jetzt aber keinen Reverse Proxy der auch SSH unterstützen würde. Wenn du aber nur lokal per SSH Zugriff haben willst, würde ich das über deinen lokalen DNS-Server auflösen lassen.

Wenn es wirklich ein Reverse Proxy mit LoadBalancing sein muss schau doch mal auf den HAproxy. Damit habe ich ich was SSL angeht auch sehr gute Erfahrungen gemacht.

 

[mstefan]

Wenn es wirklich ein Reverse Proxy mit LoadBalancing sein muss schau doch mal auf den HAproxy. Damit habe ich ich was SSL angeht auch sehr gute Erfahrungen gemacht.

Load Balancing brauche ich tatsächlich überhaupt nicht. Ich hab kein HA Cluster, lediglich einen Server mit vielen Services.
Ich bin traefik nur schon lange Zeit gewöhnt und mit den static configs kann man so einiges realisieren.
Die automatischen Wildcard Zertifikate per DNS Challenge sind auch super.

Port 53 solltest du aber nicht via Internet verfügbar machen. Das mögen einige Provider nicht ^^

Das ist klar, der bleibt schön Intern.

Das einzige Loch das ich auf mache ist 80 und 443.


Also Hausaufgaben für mich fürs Wochenende:

1. Checken was die Unifi USG Firewall an Spielereien mit macht
2. Mit ein paar Pihole Containern rumspielen

Danke euch!