© zssp / 123RF.com

Portainer verspricht, das Deployment von Containern mit einer grafischen Oberfläche zu erleichtern und dabei dem Admin viele Routinearbeiten abzunehmen, die er bei Docker, Podman oder Kubernetes selbst erledigen muss.

Container-Virtualisierung ist keine neue Erfindung und war es auch vor zehn Jahren schon nicht mehr, als Docker sie unter Linux salonfähig machte. Dennoch fühlt es sich so an, als kenne die Begeisterung für Container unter Linux seit den ersten Docker-Versionen kein Halten mehr: Im Wochentakt erreichen Redaktionen und Administratoren Pressemitteilungen von Herstellern, die ab sofort die beste, einfachste, schnellste und effektivste Container-Lösung anbieten können.

Längst haben Red Hat, Suse und Konsorten damit begonnen, ihre Enterprise-Distributionen in Container-Abspiel-Systeme zu verwandeln. Wer sich mit IT der Gegenwart beschäftigt, gewinnt den Eindruck, Kubernetes lauere quasi an jeder Ecke. Sehr zum Verdruss vieler Administratoren, die dem Container-Hype längst nicht all das Positive abgewinnen können, von dem die Hersteller dauernd sprechen. Ganz im Gegenteil: Viele Systemverwalter, die sich das erste Mal mit dem Thema Container befassen, werfen schnell entnervt wieder hin. Kein Wunder, wirkt es doch, als müsse man erst eine neue Sprache erlernen, um sich im Wörterbuch der Container-Begriffe überhaupt zurechtzufinden.

Docker, Podman, OCI, Registry, Runtime & Co. sind einzelne Konzepte, die es alle zu verstehen gilt. Von Kubernetes mit seinen unzähligen Standards wie CNI und CSI mitsamt allen Eigenbegriffen wie CSR und Operator ist dabei noch gar nicht die Rede. Wie man es auch dreht und wendet: Vom einst laut herausposaunten Versprechen der einfachen Container-Handhabung unter Linux ist nicht viel übrig, und wer in die Materie einsteigt, hat einen steinigen Weg vor sich.

Das muss nicht sein, denkt man sich bei Portainer, und stellt Administratoren ein Werkzeug an die Seite, das laut Hersteller fast den gesamten Container-Zirkus vor ihnen verbirgt. Über eine einfache, webbasierte Oberfläche teilt der Benutzer Portainer mit, welche Container es in welchem Zustand ausrollen soll. Um den Rest kümmert das Programm sich laut Prospekt dann autark. Dabei unterstützt es eine Vielzahl von Lösungen, von purem Docker bis zu einem Deployment inklusive Kubernetes. Der Support für die fertigen Kubernetes-Distributionen der großen Hyperscaler zählt ausdrücklich zum Paket. Mit Kubernetes selbst muss sich der Admin also gar nicht mehr im Detail beschäftigen, so das Versprechen.

Grund genug, dem Tool einmal genauer unter die Haube zu sehen: Ist es wirklich das Wundermittel für Administratoren, die in Sachen Container schnell Ergebnisse liefern müssen? Wodurch unterscheiden sich die verfügbaren Portainer-Editionen, wie leicht geht das Setup von der Hand, was kostet der Spaß, und wie schnell liefert er Resultate?

Die Basics

Eines der großen Probleme mit dem Container-Universum unter Linux ist die enorme Zahl (vermeintlich) hilfreicher Werkzeuge von Drittanbietern. Es fällt schwer, hier den Überblick zu bewahren. Deshalb drängt es sich auf, sich am Anfang der Betrachtungen zu Portainer zunächst mit dessen wesentlichen Eigenschaften zu befassen. Konkret geht es um die Frage, was das Tool eigentlich ist und was es leisten kann.

Dabei hilft ein Blick in die Architektur des Werkzeugs (Abbildung 1). Sie ergibt sich unmittelbar aus der unter https://www.portainer.io verfügbaren Doku von Portainer. Demnach besteht die Lösung im Kern aus zwei Komponenten. Ein zentraler Server bietet die grafische Oberfläche an und liefert die GUI in Form einer Webschnittstelle. Die von ihm angebotenen Dienste, zum Beispiel eine im Hintergrund laufende Datenbank, versteckt er vor den Augen des Administrators. Ein Agent kommt in zwei nicht ganz deckungsgleichen Varianten daher, nämlich als Edge Agent und als Portainer Agent. Der Portainer Agent ist historisch betrachtet der ältere, doch dazu später mehr.

Abbildung 1: Das Architekturdiagramm von Portainer zeigt, dass die Lösung selbst aus gar nicht vielen Komponenten besteht – der Server nebst Agent reicht aus, um das gesamte Feature-Set anzubieten. Quelle: Portainer

Um Portainer auszuprobieren, müssen Sie nicht viel tun: Sie installieren auf einem aktuellen System, etwa unter Ubuntu 22.04, die Community-Edition von Docker (Docker CE). Danach legen Sie ein persistentes Volume an (Listing 1, Zeile 2) und starten dann den Portainer-Container (Zeile 3). Der Rest passiert automatisch. Dabei haben die Portainer-Entwickler durchaus Weitsicht bewiesen: Portainer legt beim Start ein selbst signiertes SSL-Zertifikat an, um die Übertragung von Passwörtern und vergleichbaren Inhalten zumindest grundsätzlich zu schützen. In der Dokumentation des Werkzeugs findet sich zudem eine Anleitung, wie Sie eigene SSL-Zertifikate nutzen können, damit es nicht zu Warnmeldungen kommt.

### Portainer installieren
# docker volume create portainer_data
# docker run -d -p 8000:8000 -p 9443:9443 --name portainer --restart=always -v /var/run/docker.sock:/var/run/docker.sock -v portainer_data:/data portainer/portainer-ce:latest
### Portainer-Agent aufsetzen
# docker run -d -p 9001:9001 --name portainer_agent --restart=always -v /var/run/docker.sock:/var/run/docker.sock -v /var/lib/docker/volumes:/var/lib/docker/volumes portainer/agent:latest

Der Eindruck, dass die Portainer-Entwickler mitgedacht haben, erhärtet sich nach dem ersten Start schnell. Das Werkzeug bietet einen Assistenten an, der Sie durch den Prozess der ersten Konfiguration führt. Hier legen Sie für Portainer zunächst einen Standardbenutzer an, über dessen Konto Sie sich später am Webinterface anmelden. So gibt es kein Standardpasswort, das versehentlich unverändert bleibt und später Angreifern den Zugriff ermöglicht, wenn die Applikation aus dem Internet erreichbar ist.

Im letzten Schritt erkennt der Assistent zudem automatisch die Umgebung, innerhalb derer er läuft, und nimmt entsprechende Voreinstellungen vor. Allzu viel sollten Sie sich davon aber nicht versprechen. Schließlich läuft Portainer selbst in einem Container und hat deswegen keinen Zugriff auf den physischen Host, auf dem es läuft. So lautet zumindest die Theorie, denn in Sachen Sicherheit leistet das Tool sich manchen Lapsus, wie wir später noch sehen werden.

Nach der Ersteinrichtung haben Sie in den meisten Fällen die im Wesentlichen leere Weboberfläche von Portainer vor der Nase, was unmittelbar mit der Funktionsweise des Programms zu tun hat. Es funktioniert wie eine Art Makler oder Dienstbote, der Ihre Wünsche in konkreten Container-Code umsetzt und diesen auf Zielsystemen ausführt. Die Zielsysteme fehlen in Portainer nach der ersten Installation freilich noch. Dasselbe gilt für Ihre Wünsche, die Sie ebenfalls per GUI hinterlegen. Folglich besteht der nächste Schritt im Portainer-Setup darin, eine Umgebung für Portainer zu konfigurieren, in der das Werkzeug seine Workloads ausrollen darf. Dazu bieten sich mehrere Möglichkeiten.

Die nahe Umgebung

Die zweifelsohne einfachste Möglichkeit besteht darin, einen Host mit laufendem Linux und funktionaler Docker-CE-Installation unter die Fittiche von Portainer zu stellen. Dabei ergeben sich zwei Optionen: Portainer kann das entfernte System unmittelbar über die Docker-API selbst steuern. Die liegt prinzipiell auf jedem Host mit Docker-CE-Installation vor, ist ab Werk aber so konfiguriert, dass sie sich aus der Ferne nicht erreichen lässt. CISOs verziehen zudem das Gesicht beim Gedanken, die Docker-API für Aufrufe von außen zu öffnen, denn die API unterstützt den Zugriff auf Basis von Passwörtern nicht. Immerhin lässt sich die Verbindung per SSL-Zertifikat absichern. Trotzdem erscheint dieses Vorgehen nicht sinnvoll. Besser ist die Variante mittels Portainer-Agent, die zudem mehr Funktionalität bietet.

Ein Docker-Host muss freilich kein physischer Host sein, ein virtuelles System reicht völlig aus (wie übrigens auch für den Betrieb des Portainer-Servers). Wichtig ist jedoch, dass der ausführende Systemverwalter administrativen Zugang zu dem System hat, das künftig Portainer dienen soll. Das gilt für den Use Case mit der Docker-API ebenso wie für die Variante mit Portainer-Agent. Das Setup des Agenten kann Portainer allein nämlich nicht bewerkstelligen. Hier greifen Sie dem Dienst stattdessen unter die Arme, indem Sie zunächst die CE-Edition von Docker installieren und anschließend den Befehl aus der letzten Zeile von Listing 1 ausführen.

In der Portainer-UI unterscheiden die beiden Varianten sich gar nicht so sehr voneinander. Bei beiden Ansätzen fügen Sie zunächst eine entfernte Umgebung hinzu und wählen dann je nach Situation als Unterkapitel von Docker Standalone entweder die Variante mittels Docker-API oder jene per Agent. Für das Setup eines entfernten Systems mit Portainer-Agent steht in der Oberfläche allerdings wieder ein Wizard zur Verfügung, der Ihnen einen Teil der Arbeit abnimmt. Ist der erste Host mit Docker-CE in Portainer hinterlegt, geht es an das Ausrollen von Containern.

Was ist mit Kubernetes?

Aufmerksame Leser werden sich an der Stelle freilich fragen, was denn mit Kubernetes ist, dem Container-Orchestrator von Google. Er kommt mittlerweile fast schon synonym zum Begriff Container zum Einsatz, obwohl beide Begriffe keineswegs deckungsgleich sind. Die Antwort ist simpel.

Portainer kann seine Dienste wahlweise in Form ganz regulärer Docker-Container starten, sofern der Remote-Host ein entsprechendes System ist und als entfernte Umgebung in Portainer hinterlegt wurde. Dieser Use Case eignet sich bevorzugt für Workloads, in denen nur einzelne Anwendungen in Container-Form vorliegen. Geht es hingegen um Cloud-native Anwendungen, hat man es meist mit einer Vielzahl einzelner Container zu tun, die es in zusammenhängender Art und Weise kontrolliert und gesteuert auszurollen gilt. Das klappt nur mit Kubernetes, und genau darin liegt eine der großen Stärken von Portainer.

Das Werkzeug versteht sich nicht nur auf den Umgang mit Docker, sondern beherrscht auch die Handhabung von Kubernetes und kann ebenso gut eine K8s-Installation als Deployment-Target nutzen. Wenn die Portainer-Entwickler Systemverwaltern also versprechen, dass sich Anwendungen für K8s mit Portainer genauso leicht ausrollen lassen wie einzelne, autarke Container, dann ist genau das gemeint. Voraussetzung dafür ist freilich, dass irgendwo bereits ein Kubernetes läuft.

Hier steht Ihnen in Portainer erneut ein Assistent zur Seite, der die benötigten Portainer-Dienste in ein schon laufendes K8s ausrollt. Betreiben Sie noch gar kein Kubernetes, können Sie aus Portainer heraus eines in Azure starten, ein Managed Kubernetes namens AKS (Abbildung 2). Das ist zweifelsohne die einfachste Art, Portainer im Gespann mit Kubernetes zum Laufen zu bringen.

Abbildung 2: AKS ist der einzige Kubernetes-Dienst der Hyperscaler, den Portainer ab Werk unterstützt. Quelle: Microsoft

Alternativ beherrscht Portainer auch den Umgang mit Nomad (Abbildung 3). Dabei handelt es sich um ein Werkzeug zur automatischen Planung von Server-Aufgaben, das für den Betrieb mit Clouds und insbesondere mit Container-Umgebungen optimiert ist. Damit die Liaison mit Nomad funktioniert, hinterlegen Sie in der Portainer-Konfiguration zunächst die in Ihrer Umgebung existierenden Nomad-Cluster und weisen ihnen anschließend Aufgaben per GUI genauso zu wie bei Kubernetes. Via Nomad lassen sich dann wiederum Workloads in anderen Umgebungen starten, sodass Portainer im Gespann mit Nomad effektiv einen Teil seiner eigenen Funktionalität dorthin auslagert.

Im Versuch gab es an dieser Funktionalität nichts zu bemängeln. Das gilt zumindest dann, wenn man von dem Umstand absieht, dass Nomad das Setup komplexer gestaltet und eine eigene Anwendung ist, in die man sich zunächst hineindenken muss. Der berüchtigte Layer-Cake, von dem Administratoren im Kontext von K8s und Containern regelmäßig sprechen, stellt mithin auch bei Portainer eine Gefahr dar. Durch das gut strukturierte Interface der Lösung lässt sie sich jedoch gut im Griff behalten.

Abbildung 3: Andere Deployment-Ziele als die ab Werk unterstützten lassen sich gegebenenfalls mittels Nomad einbinden. Das erzwingt jedoch zusätzliche Komplexität. Quelle: HashiCorp

Setups ohne direkten Zugriff

Wie schon beschrieben kommt der Portainer-Agent in zwei Formen daher: in der ursprünglichen Form und als Edge-Variante. Was zunächst nach Marketing- und Bullshit-Bingo klingt, bezieht sich lediglich auf das Kommunikationsmodell zwischen Portainer-Server und Agent. Die Funktionalität der beiden Agenten ist deckungsgleich.

Der Standard-Portainer-Agent ist jedoch darauf angewiesen, vom Portainer-Server mittels Push-Funktionalität Befehle zu erhalten. Hier handelt es sich also um ein klassisches Server-Agent-Modell, das sich heute nicht mehr in jedem Setup umsetzen lässt. In vielen Unternehmen etwa gilt es als Sakrileg, den Zugriff auf Teilbereiche der eigenen Infrastruktur für eingehende Verbindungen zu erlauben. Darüber hinaus ist möglicherweise gar nicht jedes entfernte System, das Portainer unter seine Fittiche nehmen soll, unmittelbar von außen zu erreichen.

Darauf bezieht sich die Bezeichnung Edge: Gemeint sind als Compute-Zelle von der Außenwelt weitgehend abgeschottete Systeme in Edge-Umgebungen. Hier springt die Edge-Variante des Portainer-Agents in die Bresche, die nach dem Pull-Prinzip funktioniert. Der Agent verbindet sich also aus eigener Initiative mit dem Portainer-Server und fragt ab, welche Aufgaben für ihn anstehen. Der Edge-Agent funktioniert also zumindest dort, wo Clients noch selbst ins Internet funken oder eine entsprechende VPN-Verbindung nutzen dürfen.

Viele Möglichkeiten

Haben Sie Portainer aufgesetzt und mit Zielknoten aufgerüstet, kommen Sie in den Genuss umfassender Container-Dienstleistung. Einfache Aufgaben lassen sich mit wenigen Mausklicks erledigen. Möchten Sie etwa auf einem Zielsystem einen Docker-Container mit angehängtem Server starten, erledigen Sie das über die Schaltfläche Containers im GUI.

Schnell fällt auf, dass die Entwickler die Portainer-Oberfläche bewusst so konstruiert haben, dass jeder Admin sich zurechtfindet, der bereits mit anderen Virtualisierungslösungen wie VMware Kontakt hatten. Ganz klassisch finden sich links im Menü Einträge für Abbilder, Netzwerke und für das Anlegen persistenter Volumes. Die müssen Sie bei fortschreitendem Wissensstand aber nicht nutzen, denn das Anlegen von Netzen und Storage-Volumes kann implizit auch beim Anlegen eines Containers oder eines Stacks geschehen, also einer Container-Umgebung in einer Kubernetes-Installation.

An Einstellungsmöglichkeiten mangelt es dabei nicht. Viele Unternehmen gehen mittlerweile dazu über, das Verwenden von Abbildern aus Docker Hub komplett zu untersagen. Die Erfahrung zeigt, dass gerade weniger erfahrene Admins auf der Suche nach schnellen Lösungen für ein Problem mit höherer Wahrscheinlichkeit zu dubiosen Abbildern greifen. Die enthalten dann gern auch mal unerwünschtes Beiwerk wie einen Bitcoin-Miner. Portainer deckt dieses Einsatzszenario ab: Hier lässt sich sowohl die Verwendung von Docker Hub explizit verbieten als auch die Nutzung anderer, privater Registries ermöglichen, indem Sie diese in der Portainer-Konfiguration hinterlegen.

Eine eigene Image-Registry bietet Portainer allerdings nicht. Schade, denn aus Sicht eines Systemverwalters ist es gar nicht so einfach, sich eine solche private Registry zu bauen. Das gilt umso mehr, wenn sie allen Anforderungen der Sicherheit genügen soll. Die meisten kommerziellen Anbieter haben entsprechende Komponenten zwar im Programm, doch die fungieren dann als fester Bestandteil einer riesigen Lösung wie OpenShift und sind für Container-Einsteiger eher von untergeordnetem Interesse.

Darüber hinaus findet sich im Portainer-UI noch eine Option, die man dort im ersten Moment gar nicht vermuten würde. Fast schon despektierlich beschreiben die Entwickler ihr Werkzeug in der eigenen Dokumentation schließlich als ClickOps-Tool. Das lässt sich frei so übersetzen, dass ein Werkzeug die allermeiste Komplexität vor den Augen des ausführenden Administrators versteckt, was operative Aufgaben angeht.

In diese Kategorie gehört das Thema Continuous Integration und Continuous Deployment ja eigentlich nicht, oder zumindest nicht vollständig. Trotzdem haben die Portainer-Entwickler ihr Werkzeug mittlerweile mit Optionen ausgestattet, um es in CI/CD-Pipelines zu integrieren. Dazu lässt es sich über Webhooks etwa mit Gitlab oder Github verbinden und überwacht danach Quelltextverzeichnisse, für die die CI/CD-Funktion aktiviert wurde. Ändert sich darin etwas, übernehmen sie die geänderte Konfiguration in den produktiven Einsatz.

Wenn sich der Inhalt eines Abbilds ändert, muss der Administrator sicherstellen, dass das aktualisierte Abbild es irgendwie in eine öffentlich zugängliche Registry schafft, von wo Portainer die neue Version dann aber zuverlässig herunterlädt und startet. Das ist zwar nicht ganz so Feature-überladen wie eine komplette Jenkins-Installation, bietet im Zweifelsfall aber einen flotten Einstieg in das Thema, ohne allzu viel Wissen vorauszusetzen.

Potenzieller Blindflug

An etlichen Stellen wird allerdings eines der zentralen Probleme deutlich, die mit der Nutzung von Containern einhergehen: Der Administrator muss blind darauf vertrauen, dass Portainer funktioniert und im Hintergrund korrekt arbeitet. Das gilt umso mehr, da das Tool auch noch mit einer App-Template-Galerie daherkommt (Abbildung 4), über die sich verschiedene Dienste mit wenigen Mausklicks ausrollen lassen.

Abbildung 4: Die App-Templates in Portainer verleiten dazu, viele Dienste schnell auszurollen. Falls mal etwas schief geht, muss der Admin aber wissen, was er zu tun hat. Quelle: Red Hat

Es ist eine Sache, Container auf einem System auszurollen, auf dem die Community-Edition von Docker installiert ist. Das dafür benötigte Wissen lässt sich auch ohne einschlägige Vorkenntnisse recht schnell erlernen, was es beispielsweise ermöglicht, Probleme in einem Container zu finden. Im Hinblick auf Kubernetes oder komplexere Aufgaben wie das Abarbeiten einer CI/CD-Toolchain liegen die Dinge allerdings anders, denn Kubernetes selbst ist wie beschrieben hochkomplex, selbst wenn nur die Standard-Edition zum Einsatz kommt.

Wer Kubernetes-Distributionen wie Rancher oder OpenShift (Abbildung 5) nutzt, der hat gleich mehrere zusätzliche Ebenen der Komplexität am Bein, die es ebenfalls zu bewältigen gilt. Ähnliches gilt für die verwalteten Kubernetes-Instanzen der Hyperscaler, die unter der Haube zum Teil anders funktionieren als normales Kubernetes und dadurch auch wieder eigene Komplexität implizieren. Wer hier mit Portainer Dienste ausrollt, steht ohne Kubernetes-Vorwissen bei Problemen wie der sprichwörtliche Ochse vor dem Berg: Kubernetes ohne Vorwissen zu debuggen, ist zumindest herausfordernd, wenn nicht unmöglich.

Abbildung 5: OpenShift ist ein komplexes Konstrukt und bietet zusätzlich zur Funktionalität von normalem Kubernetes viele Zusatz-Features. Quelle: Red Hat

Damit keine Missverständnisse entstehen: Bis hierhin erledigt Portainer zuverlässig alles, was seine Entwickler versprechen. Selbst ohne jedes Kubernetes-Wissen ist es aus Sicht des Administrators nicht schwierig, Workloads in K8s zum Laufen zu bekommen. Portainer abstrahiert die Kubernetes-Ebene beinahe vollständig. Das ist aber nur schön und gut, solange alles glatt läuft. Geht etwas schief, gerät der Segen schnell zum Fluch, gerade dann, wenn Portainer an produktiven Workloads scheitert.

It’s all about the money

Portainer bietet an einer weiteren Stelle Anlass zur Kritik: beim Preis- und Lizenzmodell. Sie müssen sich zwischen der Community-Edition und der Business-Edition des Tools entscheiden. Erstere bleibt grundsätzlich kostenfrei, und auch die Business-Edition lässt sich kostenlos betreiben, sofern nicht mehr als fünf Zielknoten zum Einsatz kommen. Das dürfte für die meisten produktiven Container-Umgebungen jedoch zu wenig sein. Hier steht also eine Entscheidung entweder für die Open-Source-Variante der Community-Edition oder die Bezahlversion der Business-Edition an.

Das Preismodell ist dreigeteilt: 15 Knoten pro Jahr kosten im Rahmen einer Home&Student-Lizenz 149 US-Dollar. Die Professional-Edition schlägt dann bereits mit 3900 US-Dollar pro Jahr zu Buche, enthält groteskerweise jedoch keine zusätzlichen Knoten – die muss man stattdessen separat dazubuchen. Wie viel der Spaß kostet, verrät der Hersteller auf seiner Website nicht, doch sind Knoten-Preise von 30 bis 40 US-Dollar durchaus üblich. Im Gegenzug enthält man 9×5-Support und Hilfe bei der Installation. Ausschließlich volumenbasiert gestaltet sich schließlich die Preispolitik bei der Enterprise-Edition, die einen eigenen Customer Success Engineer und priorisierten Support umfasst. Einzelne Knoten muss man auch hier zusätzlich buchen, sodass es sich im Wesentlichen um eine Art Grundgebühr handelt.

Was dabei schnell zu Bluthochdruck führt: Viele ausschließlich der Business-Version vorbehaltene Features sind für den Betrieb im Alltag praktisch zwingend notwendig. Das betrifft etwa den Anschluss an einen LDAP-Dienst sowie die Option, in Portainer ein rollenbasiertes Zugriffssystem (RBAC) zu implementieren oder das Tool per OAuth an die unternehmensinterne Authentifizierung anzubinden. Möchten Sie Portainer für mehr als simple Basteleien einsetzen, kommen Sie um den Kauf der Business-Variante also gar nicht herum. Dadurch reiht sich die Software in die unrühmliche Liste der Nicht-so-richtig-Open-Source-Lösungen ein.

Fazit

Portainer hält in weiten Teilen, was der Hersteller verspricht. Es ermöglicht den schnellen und unkomplizierten Einstieg in das Deployment von Containern und bietet im Alltag auch links und rechts der Strecke viele praktische Optionen. Das Setup geht leicht von der Hand. Auch Updates stellen keine Herausforderung dar, da die laufenden Container sich jederzeit leicht ersetzen lassen. Für das Feature-Set und die Handhabung heimst das Tool also durchaus Punkte ein.

Abzüge gibt es allerdings für das Lizenzmodell, das im kommerziellen Betrieb praktisch immer zum Kauf der Business-Edition nötigt. Sie sollten sich obendrein der Tatsache bewusst sein, dass Portainer nicht jedes Problem in Containern oder den unterstützten Orchestrieren – neben Kubernetes kann es auch Docker Swarm steuern – vollständig abfängt. Wollen Sie nicht in der Tinte sitzen, wenn einmal etwas schiefgeht, sollten Sie sich parallel zum Portainer-Einsatz also auch Wissen rund um die genutzten Komponenten und ihr Zusammenspiel auf die Platte schaufeln. Das vermeidet im Falle eines Falles böse Überraschungen. (jcb/jlu)