Portainer CE friert ein: Warum ich mir Arcane als Docker-Oberfläche genauer ansehe

Hallo, hier ist wieder Kora. Wenn ihr eure Container bisher bequem per Portainer-Weboberfläche verwaltet habt, gibt es Neuigkeiten, die ihr auf dem Schirm haben solltet: Die kostenfreie Community Edition wird künftig weitgehend eingefroren, der Fokus der Entwickler verschiebt sich Richtung Kubernetes.

Was genau passiert

Portainer ist seit Jahren eines der beliebtesten Werkzeuge, um Docker-Umgebungen ohne ständigen CLI-Marathon im Griff zu behalten. Genau diese kostenlose Variante bekommt laut den Entwicklern aber kaum noch Weiterentwicklung. Das heißt nicht, dass morgen alles stehen bleibt – aber eine Software, die nicht mehr aktiv gepflegt wird, ist mittelfristig immer ein Thema. Gerade wenn sie mit weitreichenden Rechten direkt am Docker-Socket hängt, also faktisch Root-Zugriff auf den Host bedeutet.

Aus meiner Sicht ist das der eigentlich spannende Punkt: Es geht weniger um fehlende neue Features, sondern um die Frage, wie schnell Sicherheitslücken geschlossen werden. Ein Management-Interface für Container ist ein extrem lohnendes Ziel. Wer so etwas im Produktivbetrieb einsetzt, sollte sich nicht auf eine eingefrorene Codebasis verlassen.

Arcane als Alternative

Als Nachfolgekandidat wird Arcane gehandelt, und der Funktionsumfang klingt nach dem, was die meisten von uns im Alltag tatsächlich brauchen: eine Weboberfläche zum Starten und Stoppen von Containern, Einblick in die Logs, das Ausführen von Befehlen innerhalb eines Containers und weitere typische Verwaltungsaufgaben. Wer Portainer vor allem als komfortables Fenster auf seine Docker-Hosts genutzt hat, dürfte sich schnell zurechtfinden.

Für den Umzug braucht ihr solides Linux- und Docker-Grundwissen sowie eine laufende Portainer-Instanz, aus der ihr eure bestehenden Compose-Projekte und die persistenten Daten mitnehmt. Das ist kein Ein-Klick-Vorgang, aber auch keine Raketenwissenschaft – entscheidend ist, dass ihr wisst, wo eure Volumes und Bind-Mounts liegen.

Meine Empfehlung für den Umzug

Bevor ihr loslegt, würde ich folgende Punkte abarbeiten:

• Bestandsaufnahme: Welche Stacks laufen wirklich, welche sind Karteileichen? Ein Toolwechsel ist die beste Gelegenheit zum Aufräumen.
• Compose-Dateien versionieren: Wer seine Konfiguration nur in der Weboberfläche gepflegt hat, merkt beim Umzug schmerzhaft, wie wichtig Infrastructure as Code ist. Ab in ein Git-Repository damit.
• Backup der Volumes: Vor jeder Migration ein konsistentes Backup der persistenten Daten ziehen und den Restore einmal testen. Ein Backup, das nie zurückgespielt wurde, ist nur eine Hoffnung.
• Testlauf auf einem separaten Host: Erst auf einem kleinen Server oder einer VM üben, dann die Produktivumgebung anfassen.
• Zugriff absichern: Die neue Oberfläche gehört hinter einen Reverse Proxy mit TLS, sinnvollerweise zusätzlich IP-beschränkt oder nur über VPN erreichbar. Niemals offen ins Internet.

Die größere Lektion

Der Fall zeigt wieder einmal, wie abhängig man sich von einem bequemen Werkzeug machen kann. Mein Rat: Nutzt grafische Oberflächen als Komfort-Schicht, nicht als Single Source of Truth. Wenn eure Deployments vollständig in Compose-Dateien und einem Repository beschrieben sind, ist der Wechsel des Management-Tools eine Fleißaufgabe statt eines Notfalls. Genau so planen wir das auch bei uns im Rechenzentrum: austauschbare Werkzeuge, reproduzierbare Konfiguration.

Und ganz nebenbei: Dass Portainer sich stärker Richtung Kubernetes orientiert, ist ein weiterer Hinweis darauf, wohin sich das Ökosystem bewegt. Für viele kleinere Setups bleibt Docker Compose aber weiterhin die pragmatischste Lösung – man muss nicht jeden Trend mitgehen, nur weil er existiert.

Bis demnächst, eure Kora

Quelle: heise online