Wohin Docker auf Proxmox gehört: die Platzierungsentscheidung und die Compose-Falle

Proxmox ist installiert und du willst Container betreiben. Die Frage lautet nicht "wie installiere ich es", sondern wohin stelle ich es. Und das ist keine Geschmacksfrage, sondern eine Frage danach, wie viele Dinge kaputtgehen, wenn eines kaputtgeht.

Drei Platzierungen

Direkt auf den Host. Das Einfachste und genau das, was man nicht tun sollte. Der Host ist die Schicht, auf der alles darüber ruht. Alles, was du dort installierst, liegt nun im Wirkungsradius jeder virtuellen Maschine: ein Abhängigkeitskonflikt, eine volle Platte oder eine schlechte Aktualisierung reißt nicht nur deine Container mit, sondern alles auf einmal.

In einen Systemcontainer. Leicht und schnell aufgesetzt. Dafür betreibst du Container in einem Container, und dieser Aufbau hat eigene scharfe Kanten: das Rechtemodell, die Dateisystemschichten, der geteilte Kernel. Bewusst gewählt ist er vernünftig; gewählt, weil "es einfacher war", erzeugt er Überraschungen.

In eine virtuelle Maschine. Auf dem Papier das Schwerste, in der Praxis das Sauberste. Fällt der Containeraufbau um, fällt eine virtuelle Maschine um, nicht dein Server. Und willst du ihn neu aufsetzen, setzt du eine Maschine neu auf.

Die einzige Frage, die entscheidet

"Wenn das kaputtgeht, was passiert mit allem anderen?" Auf dem Host lautet die Antwort "alles", in einer virtuellen Maschine "eines davon". Ressourcenverbrauch, Einfachheit der Installation, all das ist neben dieser Antwort zweitrangig.

Die zweite Hälfte: Compose ist ein Programm

Eine Compose-Datei sieht aus wie Konfiguration. Sie ist es nicht. Sie auszuführen heißt Code ausführen, und sie läuft mit deinen Rechten. Zwei Zeilen darin können dem Container die ganze Maschine geben.

Kopieren Leute eine Compose-Datei aus dem Netz, empfinden sie nicht das Unbehagen, das sie beim Kopieren eines Befehls empfinden. Der Unterschied liegt nicht in der Gefahr, sondern im Aussehen: ein Befehl sieht aus wie ein Befehl, Compose sieht aus wie eine Einstellungsdatei. So auszusehen macht sie nicht sicher.

Vier Zeilen, die man vor dem Ausführen ansieht

Hängt sie das Dateisystem des Hosts hinein. Verlangt sie privilegierten Modus. Reicht sie den eigenen Socket der Containerverwaltung hinein. Nutzt sie das Netz des Hosts direkt.

Diese vier sind die Zeilen, die die Containergrenze durchstoßen: ist eine davon da, ist dieser Container kein Container mehr, er ist der Host selbst. Sie zu lesen dauert zehn Sekunden, und diese zehn Sekunden sind mehr wert als alles andere in diesem Eintrag.

Was Atlas tut

Atlas prüft Compose-Dateien und Installationsskripte vor der Installation, und diese Prüfung sitzt auf dem Server und nicht in der Oberfläche. Was die Oberfläche also auch sendet, die Kontrolle lässt sich nicht überspringen.

Befunde kommen in zwei Stufen. Rot heißt etwas, das den Container aus der Containergrenze heraushebt, also Rechte gleichwertig zum Host; in dem Fall wird ausdrückliche Zustimmung verlangt. Gelb heißt etwas, das bewusst gemacht werden kann, das dir aber gesagt werden muss. Auf Seiten des Anwendungskatalogs wird Rot gar nicht akzeptiert.

Ein Detail noch, und es zählt: der Prüfer gibt keine Meinung ab, er meldet den Sachverhalt. Er sagt nicht "das ist gefährlich", er sagt "diese Zeile tut jenes". Entschieden wird vom Lesenden, denn dieselbe Zeile kann in einer Umgebung hinnehmbar und in einer anderen nicht hinnehmbar sein.