Container mit Portainer verwalten: anlegen, Logs, Updates

Kurz gesagt: In Portainer legst du Container unter Containers → Add container an, wählst Image und Tag, gibst Ports frei, bindest Volumes ein und setzt eine Restart-Policy. Logs, Statistiken, Konsole und Inspect erreichst du über die Detailseite des Containers. Änderungen und Image-Updates laufen über Duplicate/Edit: Portainer erzeugt dabei einen neuen Container und ersetzt den alten – was nicht in einem Volume liegt, geht dabei verloren.

Dieser Guide zeigt die Alltagsaufgaben rund um einzelne Container in der Weboberfläche von Portainer CE. Er ist für dich, wenn Portainer bereits läuft und du jetzt verstehen willst, welche Schalter was bewirken – und an welcher Stelle ein Klick Daten kosten kann. Die Bezeichnungen der Oberfläche stammen aus der offiziellen Portainer-Dokumentation; zu jedem Schritt steht das entsprechende Docker-Verhalten dabei, damit du das Ergebnis auch im Terminal prüfen kannst.

Voraussetzungen #

• Eine laufende Portainer-Instanz mit angelegtem Administratorkonto. Falls noch nicht geschehen: Portainer installieren.
• Die Docker-Grundbegriffe Image, Tag, Volume, Port-Freigabe und Restart-Policy. Kurz erklärt in den Docker-Grundlagen.
• Ein Test-Host oder zumindest ein unkritischer Dienst zum Üben – nicht der produktive Container mit deiner einzigen Datenbank.

Was du am Ende kannst #

Du legst einen Container mit Port, Volume und Restart-Policy an, liest seine Logs und Statistiken, öffnest eine Konsole, aktualisierst ihn auf ein neues Image und entfernst ihn wieder – und weißt bei jedem Schritt, ob deine Daten erhalten bleiben.

Das richtige Environment öffnen #

Nach dem Login zeigt Portainer die Startseite Home mit einer Kachel pro Environment – so nennt Portainer einen verwalteten Docker-Host. Ein Klick auf die Kachel öffnet das Environment; erst dann erscheinen im Menü Bereiche wie Containers, Images, Networks und Volumes. Wenn du mehrere Hosts verwaltest, prüfe hier zuerst, dass du im richtigen Environment bist. Ein Container, der auf dem falschen Host landet, ist ein typischer Grund für „aber der Port war doch frei“.

Container anlegen: ein Webserver mit Volume #

Als Beispiel dient ein nginx-Webserver, der seine Seiten aus einem Volume liest. Er ist harmlos, startet schnell und zeigt alle wichtigen Einstellungen.

Schritt 1: Image und Name #

Wähle Containers und dann Add container. Im oberen Bereich trägst du ein:

• Name: web-test
• Registry: die Registry, aus der das Image stammt – für nginx Docker Hub
• Image: nginx:1.30-alpine

Gib den Tag immer mit an. Ohne Tag nimmt Docker latest, und du weißt später nicht mehr, welche Version eigentlich läuft. Bei Docker Hub hilft die Schaltfläche Search, Namen und Tag vorab zu prüfen. Der Schalter Always pull the image sorgt dafür, dass Portainer das Image frisch aus der Registry lädt, statt eine lokal vorhandene Kopie zu verwenden – wichtig für Updates, dazu unten mehr.

Schritt 2: Port freigeben #

Unter den Netzwerk-Ports legst du mit publish a new network port eine Zuordnung an: Host-Port 8080, Container-Port 80. Das entspricht -p 8080:80 und bedeutet: Anfragen an Port 8080 des Hosts landen bei nginx im Container. Den Schalter Publish all exposed network ports to random host ports lässt du aus – zufällige Ports sind für einen Dienst, den du wiederfinden willst, unpraktisch. Beachte: Der Port ist danach auf allen Adressen des Hosts erreichbar, auch an ufw und firewalld vorbei – Details in den Docker-Grundlagen.

Schritt 3: Volume einbinden #

Öffne unten die Advanced container settings und dort den Abschnitt Volumes. Mit map additional volume fügst du eine Zuordnung hinzu:

• Container-Pfad: /usr/share/nginx/html
• Mapping type: Volume und ein benanntes Volume, z. B. web-test-daten (falls es noch nicht existiert, legst du es vorher unter Volumes → Add volume → Create the volume an)
• Writable, damit der Container in das Volume schreiben darf

Alternativ wählst du Bind und gibst einen Pfad auf dem Host an, etwa /opt/web-test/html. Ein Volume ist für den Anfang die einfachere Wahl, weil Docker den Speicherort verwaltet und ein leeres Volume beim ersten Start mit den Dateien aus dem Image (samt Besitzer) befüllt. Wann welcher Typ passt, erklärt der Guide Netzwerke und Volumes.

Wird ein leeres benanntes Volume an einen Pfad gebunden, an dem das Image bereits Dateien enthält, kopiert Docker diese beim ersten Start hinein. Bei nginx liegen danach die Standardseiten index.html und 50x.html im Volume. Bei Bind Mounts passiert das nicht: Ein leeres Host-Verzeichnis überdeckt den Inhalt des Images.

Schritt 4: Restart-Policy und Ressourcen #

Im Abschnitt Restart policy stehen vier Optionen zur Wahl:

Für dauerhafte Dienste ist Unless stopped meist die passende Wahl. Unter Runtime & Resources kannst du zusätzlich ein Speicherlimit setzen (Memory limit (MB)). Das schützt den Host, falls ein Dienst im Fehlerfall den gesamten Arbeitsspeicher belegen will. Den Schalter Privileged mode im selben Abschnitt lässt du aus, solange die Anleitung eines Images ihn nicht ausdrücklich verlangt – er hebt fast alle Schutzmechanismen zwischen Container und Host auf.

Schritt 5: Bereitstellen und prüfen #

Mit Deploy the container erzeugt Portainer den Container. Er erscheint danach in der Container-Liste. Prüfen kannst du das Ergebnis im Browser unter http://192.168.10.20:8080 (Beispieladresse, setze die deines Hosts ein) oder im Terminal des Docker-Hosts:

docker ps --filter name=web-test
docker inspect -f '{{.HostConfig.RestartPolicy.Name}}' web-test

Der erste Befehl zeigt den Container mit 0.0.0.0:8080->80/tcp, [::]:8080->80/tcp in der Spalte PORTS, der zweite die gewählte Restart-Policy, hier unless-stopped. Zum Vergleich: Derselbe Container auf der Kommandozeile wäre

docker run -d --name web-test -p 8080:80 \
  -v web-test-daten:/usr/share/nginx/html \
  --restart unless-stopped nginx:1.30-alpine

Solche Befehle kannst du dir auch mit dem Docker-Run-Command-Builder zusammenstellen – praktisch, um eine Portainer-Konfiguration als nachvollziehbare Zeile zu dokumentieren.

Starten, stoppen, entfernen #

Auf der Detailseite eines Containers (in der Liste auf den Namen klicken) siehst du Status, Ports, Umgebungsvariablen, Labels, Volumes und Netzwerke. Darüber stehen die Aktionen Start, Stop, Kill, Restart, Pause, Resume, Remove, Recreate und Duplicate/Edit. Für den Alltag reichen wenige davon, und was dabei passiert, ist reines Docker-Verhalten:

• Stoppen beendet den Prozess. Der Container bleibt mit Status Exited erhalten, samt allem, was er in sein eigenes Dateisystem geschrieben hat.
• Starten setzt denselben Container wieder in Gang.
• Recreate erzeugt den Container mit unveränderter Konfiguration neu – laut Release Notes auf Wunsch mit frisch aus der Registry geladenem Image. Wie bei Duplicate/Edit (siehe unten) geht dabei alles verloren, was nicht in einem Volume liegt.
• Entfernen löscht den Container endgültig. In der Liste markierst du ihn dazu und wählst Remove. Portainer fragt dabei, ob auch nicht-persistente Volumes automatisch entfernt werden sollen. Lass die Option im Zweifel aus; ein benanntes Volume wie web-test-daten räumst du später bewusst unter Volumes auf, wenn du die Daten wirklich nicht mehr brauchst.

Ein bewusst gestoppter Container mit Unless stopped bleibt auch nach einem Neustart des Hosts aus. Mit Always würde er beim nächsten Start des Docker-Dienstes wieder hochfahren.

Logs, Statistiken, Konsole und Inspect #

Die Werkzeuge für die Diagnose verlinkt die Detailseite als Logs, Inspect, Stats, Console und Attach. Attach verbindet dich laut Doku mit dem Hauptprozess eines interaktiv gestarteten Containers und spielt für typische Homelab-Dienste kaum eine Rolle.

Logs zeigt die Ausgabe des Containers – dasselbe wie docker logs. Wenn ein Container nicht startet oder immer wieder neu startet, ist das Log der erste Blick. Bei einer Restart-Schleife hilft es, Display timestamps einzuschalten: Dann siehst du, ob die Fehlermeldung zum letzten Startversuch gehört oder schon älter ist. Auto-refresh logs hält die Anzeige aktuell, Wrap lines bricht lange Zeilen um. Mit Fetch grenzt du den Zeitraum ein (All logs, Last day, Last 4 hours, Last hour oder Last 10 minutes), mit Search filterst du nach einem Begriff. Portainer zeigt nur so viele Zeilen, wie unter Lines eingetragen sind; liegt der erste Fehler weiter zurück, erhöhst du den Wert oder sicherst das Log mit Download logs, bevor du den Container neu erzeugst. Copy und Copy selected lines übernehmen das Log oder einzelne Zeilen in die Zwischenablage.

Stats zeigt laufend Speicher- und CPU-Verbrauch, Netzwerkverkehr (RX/TX), I/O und die Prozesse im Container. Damit erkennst du, ob ein Dienst sein Speicherlimit ausreizt oder ungewöhnlich viel Last erzeugt.

Console öffnet eine Shell im laufenden Container. Du wählst Befehl und Benutzer und klickst Connect. Bei Alpine-basierten Images wie nginx:1.30-alpine musst du /bin/ash wählen, weil dort keine Bash installiert ist. Mit Disconnect trennst du die Sitzung. Die Konsole entspricht docker exec -it web-test /bin/ash im Terminal. Was du hier außerhalb eines Volumes änderst, ist beim nächsten Neuerzeugen des Containers verschwunden.

Inspect zeigt die komplette Konfiguration des Containers als Baum; mit Text wechselst du in die JSON-Ansicht, die auch docker inspect web-test ausgibt. Hier findest du zum Beispiel Exit-Code, Neustart-Zähler und eingebundene Volumes.

Ändern und aktualisieren: Duplicate/Edit #

Docker kann die meisten Einstellungen eines bestehenden Containers nicht nachträglich ändern. Portainer löst das, indem es neu erzeugt: Du wählst den Container, klickst Duplicate/Edit, passt die Einstellungen an und bestätigst mit Deploy the container und anschließend Replace. Der alte Container wird durch einen neuen mit den geänderten Einstellungen ersetzt.

Daraus ergibt sich die wichtigste Regel dieses Guides: Vor jedem Duplicate/Edit prüfen, ob alle Daten in Volumes liegen. Was der Container nur in sein eigenes Dateisystem geschrieben hat, existiert danach nicht mehr. Das Volume dagegen wird an den neuen Container gebunden. Auf der Kommandozeile lässt sich das Verhalten leicht nachvollziehen: Löschst du den Container web-test mit docker rm -f web-test und startest ihn mit dem docker run-Befehl von oben neu, liegen Dateien in /usr/share/nginx/html noch da, eine Datei in /etc dagegen nicht.

Auch ein Volume nachträglich an einen laufenden Container zu hängen, geht nur auf diesem Weg. Die Portainer-Doku warnt dabei ausdrücklich: Der laufende Container wird zerstört und neu gestartet – vorher sichern.

Ein neues Image einspielen #

Für ein Update eines einzelnen Containers gibt es zwei Wege:

1. Neuer Tag: Unter Duplicate/Edit trägst du die neue Version ein, etwa einen neueren nginx-Tag, und ersetzt den Container. Das ist der nachvollziehbarste Weg, weil die Version danach sichtbar in der Konfiguration steht.
2. Gleicher Tag, frisches Image: Bei Tags, die der Herausgeber weiterbewegt (etwa 1.30-alpine, der mit jeder Patch-Version 1.30.x neu gebaut wird), aktivierst du Always pull the image und ersetzt den Container. Portainer holt dann die aktuelle Fassung des Tags aus der Registry.

In der Business Edition zeigt die Container-Liste zusätzlich die Spalte Images up to date, die pro Environment eingeschaltet wird: Sie vergleicht den Digest – den eindeutigen Fingerabdruck – des lokalen Images mit dem in der Registry. Laut Portainer-Doku gibt es diese Anzeige nur in der Business Edition. In der Community Edition prüfst du neue Versionen selbst, etwa über die Tag-Liste auf Docker Hub oder die Release Notes der Anwendung. Auch die Anzeige der BE sagt übrigens nichts über neue Hauptversionen; die musst du immer selbst als neuen Tag eintragen.

Vor einem Update mit Datenbank oder wichtigen Daten: Volume sichern und die Release Notes der Anwendung lesen. Manche Anwendungen migrieren beim ersten Start ihre Daten, und ein Zurück zum alten Image funktioniert danach nicht mehr ohne Weiteres.

Typische Probleme #

• Fehlermeldungen beim Bereitstellen oder Starten (port is already allocated, pull access denied, not found, Status Exited oder Restarting) – das sind reine Docker-Meldungen. Ursachen und Lösungen stehen in den Docker-Grundlagen; in Portainer findest du die nötigen Angaben unter Logs und Inspect (Exit-Code), Namen und Tags prüfst du mit Search.
• Container landet auf dem falschen Host – Ursache: Beim Anlegen war ein anderes Environment geöffnet. Lösung: über Home das richtige Environment wählen und den Container dort neu anlegen.
• Konsole verbindet nicht – Ursache: Die gewählte Shell existiert im Image nicht. Lösung: /bin/ash wählen oder über Use custom command eine andere Shell wie /bin/sh angeben; bei Images ganz ohne Shell bleiben nur Logs und Inspect.
• Feste IP-Adresse lässt sich nicht setzen – Ursache: Im Standardnetzwerk bridge erlaubt Docker keine statischen Adressen. Lösung: ein eigenes Netzwerk anlegen und den Container dort einhängen.
• Daten nach dem Bearbeiten verschwunden – Ursache: Der betroffene Pfad war nicht als Volume eingebunden, Duplicate/Edit hat den Container neu erzeugt. Lösung: Volume für den Pfad anlegen; verlorene Daten kommen nur aus einem Backup zurück.
• Permission denied im Container bei einem Bind Mount – Ursache und Lösung wie in den Docker-Grundlagen: Besitzer des Host-Verzeichnisses an den Benutzer im Container anpassen.

Ausführliche Diagnosewege für diese und weitere Fälle sammelt der Guide Portainer-Fehlersuche.

Sicherheit und Betrieb #

• Einzelcontainer sind schwer nachvollziehbar. Die Konfiguration steckt nur in Portainer und im Docker-Dienst. Für Dienste, die bleiben sollen, ist ein Stack mit Compose-Datei besser: Er lässt sich sichern, vergleichen und auf einem anderen Host wiederherstellen – siehe Stacks mit Docker Compose.
• Riskante Optionen bewusst einsetzen. Privileged mode, das Einbinden von /var/run/docker.sock oder ein Bind Mount auf / geben einem Container weitreichende Macht über den Host. Nur verwenden, wenn die Anwendung es wirklich braucht und du ihr vertraust.
• Löschen ist endgültig. Laut Portainer-Doku wird beim Entfernen eines Volumes dessen gesamter Inhalt gelöscht; ein Volume, das noch an einem Container hängt, lässt sich gar nicht erst entfernen. Vor dem Entfernen von Containern und Volumes: Backup prüfen, üben nur auf einem Test-Host.
• Nur benötigte Ports veröffentlichen. Ein Container, den nur andere Container brauchen – etwa eine Datenbank –, bekommt keine Port-Freigabe, sondern hängt im selben eigenen Netzwerk wie seine Anwendung.
• Auto remove nur für Einmal-Aufgaben. Der Schalter Auto remove löscht den Container, sobald er sich beendet. Für einen dauerhaften Dienst verlierst du damit nach einem Absturz auch Logs und Konfiguration.

Weiterlesen #

• Stacks mit Docker Compose – der nächste Schritt: Dienste als Compose-Datei statt als Einzelcontainer betreiben.
• Netzwerke und Volumes – wann ein eigenes Netzwerk nötig ist und wie sich Volumes und Bind Mounts im Betrieb unterscheiden.
• Portainer-Fehlersuche – systematische Diagnose, wenn ein Container nicht startet oder nicht erreichbar ist.
• Die Portainer-Serie im Überblick, von der Installation bis zum Backup.