Portainer: Docker GUI die nicht nervt

GUI für Docker? Braucht man das? Manchmal ja. Hier mein Take zu Portainer.

Was ist Portainer?

Web-UI für Docker (und Kubernetes). Container, Images, Volumes, Networks - alles klickbar.

Installation

services:
  portainer:
    image: portainer/portainer-ce:latest
    container_name: portainer
    restart: unless-stopped
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - portainer_data:/data
    ports:
      - "9443:9443"

volumes:
  portainer_data:

docker compose up -d

Öffne https://server-ip:9443 und erstelle Admin-Account.

Wann ist Portainer sinnvoll?

1. Schneller Überblick

Was läuft gerade?

• Alle Container auf einen Blick
• CPU/RAM Verbrauch
• Logs direkt im Browser

Statt:

docker ps
docker stats
docker logs app

Ein Klick im Dashboard.

2. Teamarbeit

Nicht jeder im Team will CLI lernen. Portainer macht Docker zugänglich für:

• Devs die Container starten/stoppen wollen
• Support der Logs checken muss
• Manager die "mal gucken" wollen

Mit Role-Based Access Control (RBAC).

3. Mehrere Server verwalten

Portainer Agent auf jedem Server:

services:
  portainer-agent:
    image: portainer/agent
    restart: unless-stopped
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - /var/lib/docker/volumes:/var/lib/docker/volumes
    ports:
      - "9001:9001"

In Portainer: Environments → Add Environment → Agent.

Alle Server in einer UI.

4. Container ohne Compose starten

Schnell mal einen Container testen? Formular ausfüllen statt Flags tippen.

Wann ist Portainer NICHT sinnvoll?

1. Infrastructure as Code

Wenn alles in Git liegt (Compose Files, Ansible), ist Portainer gefährlich:

• Änderungen gehen am Git vorbei
• Keine Versionierung
• Kein Review-Prozess

Regel: Was in Git ist, wird nicht in Portainer geändert.

2. Nur du alleine

Du bist der einzige Admin? Du kennst die CLI? Dann brauchst du Portainer nicht wirklich.

3. Kritische Produktion

Für Prod-Server würde ich Portainer nicht exponieren. Angriffsfläche.

Best Practices

Read-Only Zugang

Für die meisten User reicht:

• Container sehen
• Logs lesen
• Stats ansehen

Kein Start/Stop, kein Delete.

Nicht öffentlich exponieren

ports:
  - "127.0.0.1:9443:9443"

Zugriff nur via SSH-Tunnel oder VPN.

Stacks für Compose

Portainer kann Compose-Files als "Stacks" verwalten:

1. Stacks → Add Stack
2. Git Repository angeben
3. Auto-Redeploy bei Push

Damit hast du Git-Versionierung UND GUI.

Edge Agent für Remote-Server

Für Server die nicht erreichbar sind (NAT, Firewall):

1. Edge Agent installiert
2. Verbindet sich ZU Portainer (Outbound)
3. Kein Port-Forwarding nötig

Alternativen

Lazydocker (Terminal UI)

brew install lazydocker
lazydocker

Für CLI-Fans: Terminal-basierte UI. Schnell, keine Installation auf Server.

Dockge

Vom Uptime-Kuma Entwickler. Fokus auf Compose-Files:

services:
  dockge:
    image: louislam/dockge:1
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - ./data:/app/data
      - /opt/stacks:/opt/stacks
    ports:
      - "5001:5001"

Einfacher als Portainer, aber weniger Features.

Mein Setup

• Dev/Test: Portainer für schnelles Debugging
• Produktion: Kein Portainer, alles via Ansible/Git
• Logs: Portainer nur zum Lesen, Änderungen über Git

Fazit

Portainer ist nützlich, aber kein Ersatz für Infrastructure as Code. Nutze es als Ergänzung, nicht als Hauptwerkzeug:

• Überblick: Ja
• Logs lesen: Ja
• Quick Tests: Ja
• Prod-Änderungen: Nein
• Öffentlich exponieren: Nein

Im Zweifel: Weniger GUI, mehr CLI + Git.