Docker im Homelab

1. Einführung

Docker ist eine Plattform zur Containerisierung von Anwendungen. Statt Dienste direkt auf dem Host-Betriebssystem zu installieren – mit all den Abhängigkeitskonflikten, die das mit sich bringt – werden Anwendungen in isolierten Containern betrieben. Jeder Container enthält alles, was er braucht: Laufzeitumgebung, Bibliotheken und die Anwendung selbst.

Im Homelab hat Docker mehrere entscheidende Vorteile gegenüber direkt installierten Diensten oder vollständigen virtuellen Maschinen:

  • Leichtgewichtigkeit: Container teilen sich den Kernel des Host-Systems und benötigen kein eigenes Betriebssystem wie VMs. Ein Container startet in Sekunden statt Minuten.
  • Reproduzierbarkeit: Ein Container-Image enthält eine exakt definierte Umgebung. Kein „bei mir funktioniert es" – das Image läuft überall gleich.
  • Isolation: Dienste beeinflussen sich nicht gegenseitig. Abhängigkeitskonflikte zwischen Anwendungen gehören der Vergangenheit an.
  • Einfaches Update: Neue Version verfügbar? Image pullen, Container neu starten – fertig. Rollback ist durch das Festlegen eines alten Image-Tags ebenso trivial.
  • Community: Für nahezu jeden Homelab-Dienst existiert ein vorgefertigtes Docker-Image auf Docker Hub oder GitHub Container Registry.

Die Abgrenzung zu VMs ist wichtig: Container sind kein Ersatz für VMs, wenn vollständige Betriebssystem-Isolation oder verschiedene Kernel benötigt werden. In einem Homelab ergänzen sich Proxmox-VMs für Betriebssystem-Isolation und Docker-Container für Dienste ideal.

2. Installation

2.1 Docker Engine auf Debian/Ubuntu

Die empfohlene Installationsmethode ist über das offizielle Docker-Repository – nicht über die distributions-eigenen Pakete, die oft veraltet sind:

# Abhängigkeiten installieren
apt-get update
apt-get install -y ca-certificates curl gnupg

# GPG-Schlüssel hinzufügen
install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/debian/gpg \
  -o /etc/apt/keyrings/docker.asc
chmod a+r /etc/apt/keyrings/docker.asc

# Repository hinzufügen
echo "deb [arch=$(dpkg --print-architecture) \
  signed-by=/etc/apt/keyrings/docker.asc] \
  https://download.docker.com/linux/debian \
  $(. /etc/os-release && echo "$VERSION_CODENAME") stable" \
  > /etc/apt/sources.list.d/docker.list

# Docker installieren
apt-get update
apt-get install -y docker-ce docker-ce-cli containerd.io \
  docker-buildx-plugin docker-compose-plugin

# Aktuellen Nutzer zur docker-Gruppe hinzufügen (kein sudo nötig)
usermod -aG docker $USER

Nach dem usermod-Befehl ist ein Neuanmelden erforderlich, damit die Gruppenänderung wirksam wird. Mit docker run hello-world lässt sich die Installation testen.

2.2 Rootless Docker

Rootless Docker lässt Docker-Container ohne Root-Privilegien laufen. Jeder Nutzer betreibt seine eigene Docker-Instanz. Das reduziert das Angriffspotenzial: Selbst wenn ein Container ausgebrochen wird, hat der Angreifer nur die Rechte des unprivilegierten Nutzers. Für ein Homelab-Setup ist das eine empfehlenswerte Härtungsmaßnahme, die sich in wenigen Schritten umsetzen lässt:

# Als normaler Nutzer (nicht root)
dockerd-rootless-setuptool.sh install

# Umgebungsvariablen für die aktuelle Shell setzen
export DOCKER_HOST=unix://$XDG_RUNTIME_DIR/docker.sock

3. Grundbegriffe

Ein sicheres Verständnis der Docker-Terminologie verhindert Missverständnisse beim Lesen von Dokumentation und beim Troubleshooting:

  • Image: Eine unveränderliche, schichtweise aufgebaute Vorlage für einen Container. Ein Image ist wie eine Klasse in der Programmierung – aus ihr werden Instanzen (Container) erstellt. Images werden aus einer Dockerfile gebaut oder von einer Registry gepullt.
  • Container: Eine laufende Instanz eines Images. Container sind flüchtig – alles, was im Container-Dateisystem geschrieben wird, geht beim Löschen des Containers verloren (sofern kein Volume eingebunden ist).
  • Registry: Ein Speicherort für Images. Docker Hub ist die öffentliche Standard-Registry. Alternativ gibt es GitHub Container Registry (ghcr.io) oder selbst gehostete Lösungen wie Harbor.
  • Volume: Persistenter Speicher außerhalb des Container-Dateisystems. Volumes überleben das Löschen und Neuerstellen von Containern. Sie sind der empfohlene Weg, Anwendungsdaten zu persistieren.
  • Bind Mount: Ein Verzeichnis vom Host-Dateisystem wird direkt in den Container eingebunden. Einfach zu verstehen, aber an den Host-Pfad gebunden – weniger portabel als Volumes.
  • Network: Logisches Netzwerk, über das Container miteinander und mit der Außenwelt kommunizieren. Docker verwaltet standardmäßig eigene virtuelle Netzwerke.
  • Docker Compose: Ein Werkzeug zum Definieren und Starten von Multi-Container-Anwendungen über eine YAML-Datei. Unverzichtbar im Homelab.

4. Docker Compose

Docker Compose erlaubt es, mehrere Container, ihre Netzwerke, Volumes und Konfigurationen in einer einzigen compose.yml-Datei zu definieren. Das macht Setups reproduzierbar, versionierbar und leicht wartbar. Im modernen Docker ist Compose als Plugin integriert und wird mit docker compose (ohne Bindestrich) aufgerufen.

4.1 Dateistruktur

Ein typisches Beispiel für eine Compose-Datei, die einen Webdienst mit einer Datenbank betreibt:

services:
  app:
    image: nextcloud:latest
    container_name: nextcloud
    restart: unless-stopped
    ports:
      - "8080:80"
    volumes:
      - nextcloud_data:/var/www/html
    environment:
      - MYSQL_HOST=db
      - MYSQL_DATABASE=nextcloud
      - MYSQL_USER=nextcloud
      - MYSQL_PASSWORD=${DB_PASSWORD}
    depends_on:
      - db

  db:
    image: mariadb:10.11
    container_name: nextcloud_db
    restart: unless-stopped
    volumes:
      - db_data:/var/lib/mysql
    environment:
      - MYSQL_ROOT_PASSWORD=${DB_ROOT_PASSWORD}
      - MYSQL_DATABASE=nextcloud
      - MYSQL_USER=nextcloud
      - MYSQL_PASSWORD=${DB_PASSWORD}

volumes:
  nextcloud_data:
  db_data:

Passwörter und Geheimnisse sollten nie direkt in der compose.yml stehen. Stattdessen werden sie über Umgebungsvariablen aus einer .env-Datei gelesen (die nicht in Git eingecheckt wird).

4.2 Wichtige Befehle

  • docker compose up -d – Alle Services starten (detached, im Hintergrund)
  • docker compose down – Alle Services stoppen und Container entfernen (Volumes bleiben erhalten)
  • docker compose down -v – Services stoppen und Volumes löschen (Achtung: Datenverlust!)
  • docker compose pull – Neueste Images für alle Services holen
  • docker compose logs -f app – Logs des app-Service live verfolgen
  • docker compose ps – Status aller Services anzeigen
  • docker compose exec app bash – Shell in laufendem Container öffnen
  • docker compose restart app – Einzelnen Service neu starten

5. Netzwerke in Docker

Die Netzwerkkonfiguration ist oft der komplexeste Teil eines Docker-Setups im Homelab. Docker bietet mehrere Netzwerk-Treiber für verschiedene Anforderungen.

5.1 Bridge-Netzwerk

Das Standard-Netzwerk für Docker-Container. Compose erstellt automatisch ein eigenes Bridge-Netzwerk für jedes Compose-Projekt. Container innerhalb desselben Bridge-Netzwerks können sich über ihren Service-Namen ansprechen (DNS-basierte Service-Discovery). Nach außen erreichbar sind sie nur über Port-Mappings (ports:).

Der Vorteil: Isolation. Container aus verschiedenen Compose-Projekten können sich nicht gegenseitig erreichen, es sei denn, sie teilen ein explizit definiertes Netzwerk.

5.2 Macvlan – direkte Heimnetz-Integration

Macvlan ist besonders nützlich im Homelab: Ein Container bekommt eine eigene MAC-Adresse und erscheint im Heimnetz als eigenständiges Gerät mit eigener IP-Adresse. Der Container ist direkt über das Heimnetz erreichbar, ohne Port-Mappings.

Typischer Anwendungsfall: Pi-hole als DNS-Server soll eine feste IP aus dem Heimnetz haben, damit Router und andere Geräte ihn als DNS-Server konfigurieren können.

networks:
  heimnetz:
    driver: macvlan
    driver_opts:
      parent: eth0
    ipam:
      config:
        - subnet: 192.168.10.0/24
          gateway: 192.168.10.1
          ip_range: 192.168.10.128/25

services:
  pihole:
    image: pihole/pihole:latest
    networks:
      heimnetz:
        ipv4_address: 192.168.10.53

Achtung: Aufgrund der Linux-Macvlan-Architektur kann der Host nicht direkt mit dem Macvlan-Container kommunizieren. Dafür muss ein zusätzliches macvlan-Interface auf dem Host erstellt werden.

5.3 Host-Netzwerk

Mit dem Host-Netzwerk teilt der Container den Netzwerk-Stack des Hosts vollständig. Kein NAT, keine Port-Mappings nötig. Anwendungsfall: Dienste, die viele Ports benötigen oder niedrige Latenz erfordern. Nachteil: Keine Netzwerk-Isolation – der Container hat denselben Netzwerkzugang wie der Host.

services:
  monitoring:
    image: netdata/netdata
    network_mode: host

6. Storage-Konzepte

Im Homelab ist persistenter Storage oft der entscheidende Faktor: Anwendungsdaten, Datenbanken und Konfigurationen müssen Container-Neustarts und -Updates überleben.

6.1 Named Volumes vs. Bind Mounts

Named Volumes werden von Docker verwaltet und sind unter /var/lib/docker/volumes/ gespeichert. Sie sind portabel (können mit docker volume verwaltet und gesichert werden) und die empfohlene Methode für Anwendungsdaten.

Bind Mounts binden ein Host-Verzeichnis direkt ein. Vorteil: Du weißt genau, wo die Daten liegen, und kannst sie einfach über normale Dateisystemoperationen verwalten. Im Homelab sind Bind Mounts für Konfigurationsdateien oft praktischer:

services:
  nginx:
    image: nginx:alpine
    volumes:
      # Bind Mount für Konfiguration
      - ./nginx.conf:/etc/nginx/nginx.conf:ro
      # Named Volume für Logs
      - nginx_logs:/var/log/nginx

volumes:
  nginx_logs:

6.2 Backup-Strategie

Volumes lassen sich mit einem einfachen Container-Trick sichern, ohne den laufenden Dienst zu stoppen:

# Volume-Backup als tar-Archiv
docker run --rm \
  -v nextcloud_data:/data:ro \
  -v $(pwd):/backup \
  alpine tar czf /backup/nextcloud_backup_$(date +%Y%m%d).tar.gz -C /data .

Für systematische Backups im Homelab bietet sich Duplicati oder Restic an, das direkt auf das Volume-Verzeichnis zugreift.

7. Typische Homelab-Services

Diese Dienste laufen in nahezu jedem gut aufgestellten Homelab als Docker-Container:

Portainer

Web-GUI zur Verwaltung von Docker-Containern. Ermöglicht das Starten, Stoppen und Inspizieren von Containern, Volumes und Netzwerken ohne die Kommandozeile. Besonders nützlich als Einstieg oder für weniger CLI-affine Nutzer.

docker run -d \
  --name portainer \
  --restart=always \
  -p 9443:9443 \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v portainer_data:/data \
  portainer/portainer-ce:latest

Traefik

Reverse Proxy und automatisches TLS-Zertifikat-Management. Traefik erkennt neue Container automatisch über Docker-Labels und richtet Routing-Regeln ein. Ideal um mehrere Webdienste unter einer Domain zu betreiben (nextcloud.homelab.local, grafana.homelab.local usw.).

Homepage / Heimdall

Dashboard für alle Homelab-Dienste. Zeigt alle laufenden Container mit Status, Links und optionaler API-Integration (z. B. Ressourcenverbrauch direkt im Dashboard).

Vaultwarden

Selbst gehosteter Passwort-Manager, kompatibel mit dem Bitwarden-Client. Läuft in einem einzigen, leichtgewichtigen Container (in Rust geschrieben). Deutlich ressourcenschonender als die offizielle Bitwarden-Server-Implementierung.

Uptime Kuma

Monitoring-Dashboard für Dienste. Prüft per HTTP, TCP, Ping oder DNS, ob Dienste erreichbar sind, und sendet Benachrichtigungen bei Ausfällen.

8. Best Practices

Images aktuell halten

Veraltete Images enthalten bekannte Sicherheitslücken. Im Homelab empfiehlt sich Watchtower, das Container automatisch auf neue Image-Versionen prüft und aktualisiert. Für produktive Umgebungen sollte man Updates aber manuell kontrollieren:

# Watchtower für automatische Updates (nur im Homelab empfohlen)
docker run -d \
  --name watchtower \
  --restart always \
  -v /var/run/docker.sock:/var/run/docker.sock \
  containrrr/watchtower --schedule "0 0 4 * * *"

Ressourcenlimits setzen

Ohne Limits kann ein Container den gesamten Host-Arbeitsspeicher belegen. In compose.yml:

services:
  app:
    image: myapp:latest
    deploy:
      resources:
        limits:
          cpus: '0.50'
          memory: 512M
        reservations:
          memory: 128M

Logs verwalten

Ohne Konfiguration wachsen Docker-Logs unbegrenzt. Entweder global in /etc/docker/daemon.json oder pro Container:

# /etc/docker/daemon.json
{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}

Geheimnisse nicht in Images baken

Passwörter und API-Keys gehören in .env-Dateien oder Docker Secrets – niemals direkt in compose.yml oder Dockerfile. .env-Dateien niemals in Git einchecken (.gitignore pflegen).

Regelmäßige Aufräumarbeiten

# Nicht verwendete Images, Container, Volumes und Netzwerke entfernen
docker system prune -a

# Nur ungenutzte Volumes entfernen
docker volume prune

9. Zusammenfassung

Docker ist im Homelab eine der nützlichsten Technologien: leichtgewichtig, reproduzierbar und mit einem riesigen Ökosystem an vorgefertigten Images. Docker Compose macht Multi-Container-Setups wartbar und versionierbar.

Die wichtigsten Punkte im Überblick:

  • Container teilen den Host-Kernel und sind deutlich leichtgewichtiger als VMs – kein Ersatz, aber eine ideale Ergänzung.
  • Docker Compose ist das Standardwerkzeug für Homelab-Setups mit mehreren Diensten.
  • Named Volumes für Anwendungsdaten, Bind Mounts für Konfigurationsdateien.
  • Macvlan ermöglicht es, Containern eine eigene IP im Heimnetz zu geben – ideal für DNS-Server wie Pi-hole.
  • Images regelmäßig aktualisieren, Ressourcenlimits setzen, Logs begrenzen und Geheimnisse aus Code und Compose-Dateien heraushalten.
  • Portainer, Traefik, Vaultwarden und Uptime Kuma sind bewährte Startpunkte für ein vollständiges Homelab-Setup.