Fragen bzgl. Architektur aus Sicht eines Neulings (meine Anforderungen vs. VM, LXC, Docker etc.)

[Thakis]

Hallo zusammen,

ich nutze nun seit ein, zwei Jahren meinen RaspberryPi 4 erfolgreich und habe darauf einige Anwendungen in Docker Container laufen und ich überwache diese über Portainer.
Seit kurzem habe ich mir einen weiteren Server zugelegt und darauf Proxmox installiert. (siehe Bild für mein zukünftigen Plan)


Nun benötige ich eure Unterstützung beim Aufbau der Architektur.
Ich habe nachfolgende Anforderungen oder zumindeset Wunschvorstellungen. Ich weiß aber nicht, was davon sinnvoll umsetzbar ist und wo ich Kompromisse eingehen muss bzw. wo ich sogar widersprüchliche Anforderungen habe.



1. Ich möchte, wo möglich, meine Anwendungen in Docker Container laufen lassen, da ich bereits durch meinen Raspberry den Umgang mit Docker Container sehr angenehm finde und ich gerne meine Docker-compose.ymls selbst erstelle bzw. templates anpasse.
Zusätzlich finde ich es sehr angenehm, dass ich nur den Container herunterfahren muss, um anschließend die config in der yml anpassen zu müssen, falls ich einen Fehler gemacht habe oder generell etwas ändern möchte.
2. Ich möchte so gut es geht all meine Anwendungen, egal ob auf dem Pi oder auf dem Minisforum, in einer Portainerumgebung monitoren können. (Notiz: Ich besitze eine Businesslinzenz, in der ich drei Nodes nutzen kann.
3. Ich möchte einige Anwendungen automatisch mit Hilfe von Watchtower auf dem aktuellsten Stand halten.
4. Ich möchte über Updates von Watchtower per Gotify informiert werden.
5. Ich möchte gerne den Leistungsverbrauch, Ausfall etc. der Anwendungen einzeln betrachten können, um ein besseres Verständnis für den Ressourcenverbrauch der Anwendungen erhalten zu können.
6. Ich möchte schnell mit großer Unabhängigkeit von Bestandsanwendungen Umgebungen starten und neue Applictions testen können und diese auch rückstandslos entfernen können.



Meine Idee war nun folgende, wobei ich damit noch nicht ganz zufrieden bin:
1. Ich habe mir ein CT-Template erstellt
1.1 Ubuntu, 1 CPU, 512 MB RAM, 8 GB SSD
1.2 Darin installiert sind bereits: docker, docker compose, portainer, portainer-agent, watchtower
2. Jedes Mal, wenn ich nun eine neue Anwendung oder ein Verbund von mehreren Komponenten testen oder direkt produktiv nutzen möchte, verwende ich das Template, vergebe eine neue IP-Adresse und entscheide direkt oder später, ob ich die Hardware-Ressourcen erweitere

Meine Sorgen mit diesem Konzept sind jedoch:
1. Ich habe mehrere Beiträge in verschiedenen Foren gelesen, die sagen, dass von der Nutzung von Docker in LXC Container abgeraten wird. Sogar von den Docker-Entwicklern selbst. Das würde somit meine Architektur sehr riskant machen.
2. Wenn ich alles in separate LXC laufen lasse, würde ich auch relativ viele Environments in Portainer haben, was das Monitoring relativ unübersichtlich macht, da es keine environmentübergreifende Container list meines Wissens nach gibt.
3. Ich müsste überall Watchtower mit Gotify verbinden und würde bei Gotify keine gesammelte Nachricht erhalten, sondern auch für jeden LXC eine eigene, was die Übersichtlichkeit wieder vermindert.

Meine Überlegung nun:
Zu Testzwecken erstelle ich für neue Applikationen einen separaten LXC. Wenn ich ausreichend getestet habe, führe ich die Installation erneut in einem zentralen LXC durch, in dem ich alles produktiv laufen lasse und schließe anschließend den Test-LXC. Damit
Damit hätte ich zumindest den Vorteil, dass ich zu Testzwecken schnell etwas aufziehen kann und für die produktiven Anwendungen ein zentrales Monitoring mit Portainer habe und eine gesammelte Nachricht von Watchtower an Gotify erhalte.
Das Problem mit Docker und LXC würde dennoch bestehen. Außer ich nutze statt einem LXC eine VM.

Wie ist eure Meinung dazu?


Generelle Fragen:
1. Wie lautet die Empfehlung, Applikationen in LXC zu installieren, wenn nicht mit Docker? Denn zu den Anwendungen, die ich so nutze, finde ich meinst nur docker-Installationsanleitungen.
2. Wie kann dieser User mit einer Community Edition so viele Environments haben? Mit meiner Business Lizenz kann ich nur zwei Agents hinzufügen.

 

[Philipp Hufnagl]

Hallo

Zu den genauen Services, die du rennen lassen willst, kann ich wenig sagen. Jedoch wie du Docker am besten mit Proxmox nutzt, empfehle ich dir unsere Dokumentation durchzuschauen.

Hier ein Zitat aus Kapitel 11:

If you want to run application containers, for example, Docker images, it is recommended that you run them inside a Proxmox QEMU VM. This will give you all the advantages of application containerization, while also providing the benefits that VMs offer, such as strong isolation from the host and the ability to live-migrate, which otherwise isn’t possible with containers.

 

[cwt]

VMs sind für Docker immer die beste Wahl. Alleine schon wegen der Isolierung.

Du benötigst keine Businesslizenz, um mehrere Docker Agents zentral zu verwalten. In meinem Homelab habe ich das ebenfalls so. Eine Portainerinstanz auf eine Rpi4, die ganzen VMs mit Debian und Docker haben nur den Agent installiert und werden auf dem Rpi hinzugefügt.

 

[Thakis]

1. Danke Philipp für den Hinweis.

2. @cwt
Und wie geht das? Ich habe gerade versucht einen weiteren Agent mit meiner "Hauptportainerinstanz" zu verbinden, aber ab der vierten Verbindung erhalte ich die Fehlermeldung, dass meine Lizenz nicht mehr erlaubt.

3. Zwar nicht unerwartet, aber dennoch interessant, dass ihr beide auch VMs empfehlt anstatt LXC, denn ich frage mich, ob die Leute hinter einigen Proxmox-Videos auf YouTube bewusst die nicht empfohlene Variante mit Anwendungen im LXC nutzen oder wie sie ansonsten die Installation durchgeführt haben, denn wie gesagt, ich für meinen Teil finde teils nur Docker-Installationsanleitungen und keine weiteren.

 

[cwt]

Das ist halt Geschmackssache, was man präferiert. Ein LXC ist jetzt nicht 1:1 vergleichbar mit Docker. Vielmehr ist es eine eingeschränkte VM, welche quasi vom Hostsystem „abgeknabbert“ wird. Klassisker sind z.B. Dienste wie PiHole/AdGuard/Wireguard/etc. Diese werden allerdings „normal“ im LXC installiert und nicht gepullt. Oder man verwendet eines der fertigen Templates (Samba, Turnkey, whatever).

Der Fehler bzgl. des weiteren Agents resultiert aus Deiner Lizenz. Wenn Du Portainer als CE laufen lässt, kannst Du wie o.g. mehrere Agents hinzufügen (allerdings ohne die Features der Business Edition).

 

[Thakis]

@cwt
Danke für den Hinweis.


Werden, wenn ich mich dazu entscheide, meine produktiven Anwendungen nicht zentral in einer VM laufen zu lassen sondern auch in einzelne VM, die dafür benötigten Hardware-Ressourcen deutlich steigen im Vergleich zu LXC-Nutzung?

 

[sb-jw]

denn ich frage mich, ob die Leute hinter einigen Proxmox-Videos auf YouTube bewusst die nicht empfohlene Variante mit Anwendungen im LXC nutzen oder wie sie ansonsten die Installation durchgeführt haben

Also bei manchen YouTubern wundert mich persönlich nichts mehr was die da so empfehlen. Da mangelt es leider bei manchen doch an Erfahrungen oder die sind einfach nicht weit genug im Thema Enterprise drin. Ich kann mir schon denken welche YouTuber du da ansprichst und genau das ist meine Meinung dazu.

Im Enterprise Umfeld möchtest du Systeme haben, die möglichst ohne Ausfallzeiten migriert werden können. Ich möchte nicht 100 VMs abschalten müssen weil ich jetzt mal ne Node upgraden möchte oder LXC Container mit einem Ausfall verschieben, den die Kunden ggf. merken. Ich habe z. B. meine Infrastruktur so im Griff, dass ich regelmäßig alle Wartungen ohne Ankündigung durchführen kann. Warum? Es ist bei mir alles redundant ausgelegt, von der Switch Infrastruktur, über die Uplinks und dem Strom Feed bis hin zum Shared Storage mit CEPH und der reinen Nutzung von KVM VMs, die sich live migrieren lassen.

Für den Heimanwendungsfall ist LXC oftmals die bessere Lösung, da du kein zweites Betriebssystem innerhalb des Container am laufen hast. Das ist bei einer VM schon der Fall. Das bedeutet aber auch, dass du für jede VM wieder die Grundressourcen für das OS benötigst und genau das sparst du dir halt mit LXC weil es einfach den Host mitnutzt und hier sehr wenig Overhead entsteht. Bei einem Container kannst du auch einfach die Platte resizen, das geht bei einer VM zwar auch, aber nicht so easy wie unter LXC.
Bei LXC darfst du aber auch nicht vergessen, dass es durch Updates ggf. auch zu Problemen kommen kann, weil die Anwendung im Container plötzlich X oder Y nicht mehr hat. Das gleiche gilt aber ebenfalls für gewisse Berechtigungen, die kannst du im Container einfach nicht bekommen.

Du kannst dir also mit LXC auch selbst Probleme erzeugen, die du nicht so einfach debuggen kannst weil z. B. installer einfach abbrechen, weil Sie X oder Y nicht finden oder eben durch Upgrades ein neuer Kernel läuft den deine Anwendung aber nicht mag.

Du musst dir letztlich also einfach bewusst sein, was die Unterschiede zwischen LXC und VM sind und ob du mit diesen leben kannst oder halt eben nicht. Ich persönlich finde VMs einfacher zu handhaben, die lassen sich in der Regel nämlich auch einfach easy woanders wieder deployen und haben keine Abhängigkeit zum Host. Durch die bessere Isolierung sind die VMs auch weniger anfällig für mögliche Angriffe oder "lateral movements", ebenfalls kann ich bei Bedarf die VMs live migrieren und kann eben das eine File auch ohne weiteres von A nach B kopieren und direkt nutzen.

Aber wie gesagt, du musst für dich die Vor- und Nachteile abwägen.

 

[Thakis]

Danke für dein Feedback @sb-jw
Ein Hinweis dazu:
Bei mir betrifft es ausschließlich den Heimanwenderfall. Und auch die Videos, die ich so schaue, zeigen Homelab-Szenarien.


Aktuell wäre somit meine Überlegung, meine Anwendungen entweder einzeln in LXC laufen zu lassen, egal, ob "direkte" Installation oder per docker-compose und erst, wenn ich Probleme bekomme, würde ich die gewisse Anwendung in einer VM installieren.
Oder ich nutze die LXCs für temporäre Spielerein, Testen etc. und für die Produktivnutzung in meinem HomeLab rolle ich es in einer größeren, zentralen VM aus.

 

[Ernst T.]

sondern auch in einzelne VM

Warum nicht zentral alle Docker-Dienste in einer VM???

Mach dir eine produktive Docker-VM (für all deine Docker-Dienste), und eine VM als Docker Testumgebung, die nur zum testen läuft. Die Test-VM ist eigentlich nicht notwendig, da du mit Snapshots/Backups in wenigen Minuten wieder den alten Zustand herstellen kannst.

 

[h00bi]

Klar KANN man Docker in einen LXC installierern. Ich würde als Docker Host aber immer eine vollwertige VM nehmen.
Das hängt ja auch damit zusammen, dass du fast immer persistente Volumes vom Host an den Container durchreichst.

Ob man einen Dienst dann als Docker-Container oder LXC realisiert, entscheide ich danach, ob es einen guten und aktiven Maintainer für den Docker Container gibt.

Gibt es den nicht, dann mache ich es selbst lieber in einem LXC statt der Docker.
Einfache Scripts wie z.B. DDNS Updater packe ich ebenfalls jeweils in einem separaten LXC.
Unifi Controller ist auch so ein Ding.... Container sind meist etwas hintendran was updates betrifft und der bekannteste(?) lscr.io/linuxserver/unifi-controller wurde jetzt zum Jahreswechel eingestellt https://info.linuxserver.io/issues/2023-09-06-unifi-controller/

Also Docker nur dann, wenn mir der Container Maintainer Arbeit abnimmt.

 

[Thakis]

Erneut vielen Dank für euer Feedback

@Ernst T.
Der Hintergrund meiner Überlegung, meine Dienste dezentral anzulegen ist der, dass ich in diesen Themenbereiche (noch) nicht so sicher und erfahren bin und beruflich auch andere Aufgaben nachgehe.
Wenn ich also etwas falsch installiere, etwas falsch einstelle, dann kann ich genau diesen einen Use Case komplett löschen und neu aufsetzen, ohne irgend etwas anderes dabei "berührt" zu haben.
Ja, ich hätte auf einer zentralen Docker-VM auch Snapshots/Backups, aber wenn ich zwischendurch an andere Dienste arbeite und ich erst später merke, ich habe ein Problem, hilft mir das nur bedingt weiter, sofern ich meinen zwischenzeitlichen Arbeitsfortschritt nicht verlieren möchte.

Der Ansatz von dir @h00bi gefällt mir auf jeden Fall sehr gut.
Wie kann ich die Aussage "Also Docker nur dann, wenn mir der Container Maintainer Arbeit abnimmt." für mich am besten einschätzen? Hast du dazu Tipps?
EDIT: Gerade mit Watchtower in einer Docker-Umgebung ist doch das Maintaing unglaublich einfach, oder?

 

[h00bi]

So als grobe Faustregel:
Wenn du länger als 10 Minuten brauchst um eineno der mehrere Docker Container für deinen Wunschdienst zu finden

und/oder

wenn es länger als 30min dauert bis der runtergeladene Docker Container läuft

dann ist der LXC für mich der Weg der Wahl.

Beispiel: Du suchst einen Reverse Proxy.
Innerhalb von wenigen Minuten findest du traefik und ngnix Proxy Manager.
Du entscheidest dich für npm2, merkst dann aber nach einigen Minuten basteln dass mit dem Container irgendwas nicht stimmt (z.B. DNS Challenge im armv7 Container war monatelang defekt).
Das ist dann der punkt wo ich auf einen anderen Maintainer wechsle oder auf eine andere Software wechsele oder es dann einfach selbst in einem LXC installiere.
Gerade bei Sachen, die häufiger Sicherheitspatches bekommen sollten, weil Zugang von extern drauf läuft sind mir per Docker ganz recht, denn die Maintainer haben meist ein besseres Patchmanagement als ich.

Ich mag auch keine Datenbanken in Docker. Habe ich lieber in einer VM oder einem LXC.
Die Datenbank liegt ja außerhalb des Docker Containers und wird in den Container gemapped. Geht nach einem Update irgendwas schief und der neue Container schreibt Unsinn in die Datenbank, die dadurch unbrauchbar wird, muss ich beides unabhängig recovern, was auch heißt ich muss es unabhängig sichern (oder den kompletten Docker Host recovern, aber das setzt ja andere Dienste ebenfalls zurück).
Einen LXC recovere ich einfach komplett aus dem vor dem Update erstellen Snapshot incl. der Datenbank, die ich im LXC liegen habe.

 

[Thakis]

Interessant finde ich ja, dass parallel zu meinem Thread dieser hier exisitert, indem nach meinem Verständnis genau das gegenteilige von der Mehrheit empfohlen wird, nämlich "pro Applikation ein Container".
Ja, hier geht es nicht um Docker in Container oder VMs, aber die Argumente sind davon unabhängig, oder verstehe ich da etwas falsch?

Ich möchte keine Meinung in diesem Thread oder im anderen grundsätzlich mehr oder minder gewichten. Ich möchte lediglich verstehen, warum ggf. andere Empfehlungen gemacht werden.

 

[cwt]

LXC vs Container in VMs erlaubt mehr Kontrolle bzw. Eingriffsmöglichkeiten. Ist jetzt zumindest meine bescheidene Meinung. Gibt es bspw. ein Update für die Anwendung, ist man nicht vom Maintainer des Containers abhängig, sondern kann dieses nach eigenem Geschmack aufspielen. Manche Container bringen auch unschöne Konstellationen mit sich, die bei direkter Verwendung entfallen. Allerdings ist der administrative Aufwand zur Aktualisierung dann anders, als Container etwa via Watchtower einfach neu pullen zu lassen. So oder so kommt man um Systempflege nicht rum.

 

[Dunuin]

Ich mache das hier so:
Ist der Dienst für mich wichtig oder vom Internet aus erreichbar? Wenn ja, dann VM wegen Zuverlässigkeit und Sicherheit dank bester Isolation.
Speichert der Dienst große Mengen an Daten? Wenn ja, dann als VM, weil sich LXCs nicht schnell sichern lassen (kein Dirty-Bitmapping).
Kann ich den Dienst relativ einfach über APT oder ähnliches installieren und aktuell halten und braucht der Dienst keinen Zugriff auf SMB/NFS Shares? Dann nehme ich einen unprivilegierten LXC.
Ist der Dienst rein offline und braucht SMB/NFS-Zugriff, dann nehme ich stattdessen die unsicheren privilegierten LXCs.
Gibt es außer einem Docker-Container keine gute Option den Dienst ohne zu viel Verwaltungsarbeit aktuell zu halten, dann setze ich mir eine VM mit Docker auf.

 

[h00bi]

Interessant finde ich ja, dass parallel zu meinem Thread dieser hier exisitert, indem nach meinem Verständnis genau das gegenteilige von der Mehrheit empfohlen wird, nämlich "pro Applikation ein Container".

Etwas anderes meine ich auch nicht.
Selbstverständlich mache ich trotzdem "pro Applikation ein Container".
Es ging nur um der Container Docker ist oder LXC