HOME LAB · SELFHOSTING · NETZWERK

Kategorie: Tutorials

Schritt-für-Schritt Anleitungen für Homelab und Selfhosting.

  • Docker Logs unter Kontrolle: Rotation, Retention und schnelle Analyse

    Docker Logs unter Kontrolle: Rotation, Retention und schnelle Analyse

    Schwierigkeit: Mittel · Dauer: 35–65 Min · Ziel: Docker Logs unter Kontrolle: Rotation, Retention und schnelle Analyse

    Kurzproblem und Zielbild

    In vielen Homelabs funktioniert die Erstinstallation, aber der Dauerbetrieb wird schnell unübersichtlich. Dieses Tutorial zeigt einen reproduzierbaren Ablauf für Docker Logs unter Kontrolle mit Fokus auf Stabilität, klare Checks und einfache Fehlerbehebung.

    Ziel ist ein Setup, das nicht nur heute läuft, sondern auch nach Updates und Änderungen beherrschbar bleibt.

    Voraussetzungen

    • Aktuelles Debian/Ubuntu oder kompatible Appliance
    • Administrative Rechte und Wartungsfenster
    • Backup- oder Snapshot-Möglichkeit vor Änderungen

    Schnellstart (funktionierende Basis)

    # Basisprüfung
    hostnamectl
    ip a
    # Dienste prüfen
    systemctl --failed
    # Logs kurz prüfen
    journalctl -p 3 -xb --no-pager | tail -n 30

    Was macht das? Du prüfst erst den Grundzustand und vermeidest, dass Altfehler in neue Änderungen hineinwirken.

    Schritt-für-Schritt Umsetzung

    1) Ausgangszustand dokumentieren

    date -Iseconds
    uname -a
    # versions/relevante configs sichern

    Erklärung: Mit einer kurzen Bestandsaufnahme lassen sich spätere Fehler schneller eingrenzen.

    2) Kernkonfiguration sauber setzen

    sudo mkdir -p /etc/docker
    cat <<'EOF' | sudo tee /etc/docker/daemon.json
    {
      "log-driver": "json-file",
      "log-opts": {"max-size": "10m", "max-file": "5"}
    }
    EOF
    sudo systemctl restart docker
    docker info | grep -E "Logging Driver|Docker Root Dir"

    Erklärung: Änderungen gezielt umsetzen, danach direkt den Dienst-/Funktionszustand prüfen.

    3) Dienst kontrolliert neu laden

    sudo systemctl daemon-reload
    sudo systemctl restart 
    sudo systemctl status  --no-pager

    4) Betriebsgrenzen testen

    docker ps --format "table {{.Names}}	{{.Status}}"
    docker inspect -f "{{.Name}} -> {{.HostConfig.LogConfig.Type}} {{json .HostConfig.LogConfig.Config}}" $(docker ps -q)
    sudo du -sh /var/lib/docker/containers/*/*-json.log | sort -h | tail -n 10

    Validierung / Checks

    docker info | grep "Logging Driver"
    docker system df
    systemctl status docker --no-pager

    Troubleshooting

    Konfiguration wird nicht übernommen

    Ursache: Syntax-, Reload- oder Parameterfehler.

    docker inspect -f "{{.Name}} {{json .HostConfig.LogConfig}}" CONTAINER
    docker compose up -d --force-recreate

    Dienst läuft, Funktion aber fehlerhaft

    Ursache: Abhängigkeiten, Routing oder Berechtigungen sind inkonsistent.

    docker system df
    du -sh /var/lib/docker/volumes/* | sort -h | tail -n 10
    journalctl --disk-usage

    Fazit

    Mit einem klaren Ablauf für Docker Logs unter Kontrolle reduzierst du Ausfälle und erhöhst die Wartbarkeit deutlich. Der wichtigste Hebel ist die Kombination aus kleiner Änderung, sofortigem Check und dokumentiertem Ergebnis.

    Nächster Schritt: den Ablauf als monatliche Betriebsroutine einplanen und regelmäßig gegen echte Störfälle testen.

    Quellen

  • Proxmox Storage sauber planen: ZFS, LVM-Thin und Backup-Ziele

    Proxmox Storage sauber planen: ZFS, LVM-Thin und Backup-Ziele

    Schwierigkeit: Mittel · Dauer: 35–65 Min · Ziel: Proxmox Storage sauber planen: ZFS, LVM-Thin und Backup-Ziele

    Kurzproblem und Zielbild

    In vielen Homelabs funktioniert die Erstinstallation, aber der Dauerbetrieb wird schnell unübersichtlich. Dieses Tutorial zeigt einen reproduzierbaren Ablauf für Proxmox Storage sauber planen mit Fokus auf Stabilität, klare Checks und einfache Fehlerbehebung.

    Ziel ist ein Setup, das nicht nur heute läuft, sondern auch nach Updates und Änderungen beherrschbar bleibt.

    Voraussetzungen

    • Aktuelles Debian/Ubuntu oder kompatible Appliance
    • Administrative Rechte und Wartungsfenster
    • Backup- oder Snapshot-Möglichkeit vor Änderungen

    Schnellstart (funktionierende Basis)

    # Basisprüfung
    hostnamectl
    ip a
    # Dienste prüfen
    systemctl --failed
    # Logs kurz prüfen
    journalctl -p 3 -xb --no-pager | tail -n 30

    Was macht das? Du prüfst erst den Grundzustand und vermeidest, dass Altfehler in neue Änderungen hineinwirken.

    Schritt-für-Schritt Umsetzung

    1) Ausgangszustand dokumentieren

    date -Iseconds
    uname -a
    # versions/relevante configs sichern

    Erklärung: Mit einer kurzen Bestandsaufnahme lassen sich spätere Fehler schneller eingrenzen.

    2) Kernkonfiguration sauber setzen

    pvesm status
    zpool list
    lsblk -f
    sudo pvesm add dir local-backup --path /srv/proxmox-backups --content backup
    pvesm status

    Erklärung: Änderungen gezielt umsetzen, danach direkt den Dienst-/Funktionszustand prüfen.

    3) Dienst kontrolliert neu laden

    sudo systemctl daemon-reload
    sudo systemctl restart 
    sudo systemctl status  --no-pager

    4) Betriebsgrenzen testen

    pvesm status
    zpool status -x
    lvs -a -o+seg_monitor

    Validierung / Checks

    pvesm status
    pvesh get /nodes/$(hostname)/storage --output-format yaml
    zpool list -v
    vgs; lvs -a

    Troubleshooting

    Konfiguration wird nicht übernommen

    Ursache: Syntax-, Reload- oder Parameterfehler.

    grep -n . /etc/pve/storage.cfg
    pvesm status
    systemctl restart pvedaemon pveproxy

    Dienst läuft, Funktion aber fehlerhaft

    Ursache: Abhängigkeiten, Routing oder Berechtigungen sind inkonsistent.

    lvs -a -o lv_name,lv_size,data_percent,metadata_percent
    pvesm list local-backup | head -n 40

    Fazit

    Mit einem klaren Ablauf für Proxmox Storage sauber planen reduzierst du Ausfälle und erhöhst die Wartbarkeit deutlich. Der wichtigste Hebel ist die Kombination aus kleiner Änderung, sofortigem Check und dokumentiertem Ergebnis.

    Nächster Schritt: den Ablauf als monatliche Betriebsroutine einplanen und regelmäßig gegen echte Störfälle testen.

    Quellen

  • CrowdSec auf Debian produktiv betreiben: Collections, Bouncer, saubere Regeln

    CrowdSec auf Debian produktiv betreiben: Collections, Bouncer, saubere Regeln

    Schwierigkeit: Mittel · Dauer: 35–65 Min · Ziel: CrowdSec auf Debian produktiv betreiben: Collections, Bouncer, saubere Regeln

    Kurzproblem und Zielbild

    In vielen Homelabs funktioniert die Erstinstallation, aber der Dauerbetrieb wird schnell unübersichtlich. Dieses Tutorial zeigt einen reproduzierbaren Ablauf für CrowdSec auf Debian produktiv betreiben mit Fokus auf Stabilität, klare Checks und einfache Fehlerbehebung.

    Ziel ist ein Setup, das nicht nur heute läuft, sondern auch nach Updates und Änderungen beherrschbar bleibt.

    Voraussetzungen

    • Aktuelles Debian/Ubuntu oder kompatible Appliance
    • Administrative Rechte und Wartungsfenster
    • Backup- oder Snapshot-Möglichkeit vor Änderungen

    Schnellstart (funktionierende Basis)

    # Basisprüfung
    hostnamectl
    ip a
    # Dienste prüfen
    systemctl --failed
    # Logs kurz prüfen
    journalctl -p 3 -xb --no-pager | tail -n 30

    Was macht das? Du prüfst erst den Grundzustand und vermeidest, dass Altfehler in neue Änderungen hineinwirken.

    Schritt-für-Schritt Umsetzung

    1) Ausgangszustand dokumentieren

    date -Iseconds
    uname -a
    # versions/relevante configs sichern

    Erklärung: Mit einer kurzen Bestandsaufnahme lassen sich spätere Fehler schneller eingrenzen.

    2) Kernkonfiguration sauber setzen

    sudo apt update
    sudo apt install -y crowdsec crowdsec-firewall-bouncer-iptables
    sudo cscli hub update
    sudo cscli collections install crowdsecurity/linux crowdsecurity/sshd
    sudo systemctl enable --now crowdsec crowdsec-firewall-bouncer
    sudo cscli bouncers list

    Erklärung: Änderungen gezielt umsetzen, danach direkt den Dienst-/Funktionszustand prüfen.

    3) Dienst kontrolliert neu laden

    sudo systemctl daemon-reload
    sudo systemctl restart 
    sudo systemctl status  --no-pager

    4) Betriebsgrenzen testen

    sudo cscli metrics
    sudo cscli alerts list -n 10
    sudo cscli decisions list -n 20
    sudo nft list ruleset | grep -i crowdsec -n || sudo iptables -S | grep -i crowdsec

    Validierung / Checks

    systemctl status crowdsec --no-pager
    systemctl status crowdsec-firewall-bouncer --no-pager
    sudo cscli collections list
    sudo cscli scenarios list | head -n 30

    Troubleshooting

    Konfiguration wird nicht übernommen

    Ursache: Syntax-, Reload- oder Parameterfehler.

    sudo -u crowdsec crowdsec -c /etc/crowdsec/config.yaml -t
    sudo systemctl restart crowdsec crowdsec-firewall-bouncer
    sudo journalctl -u crowdsec -n 150 --no-pager

    Dienst läuft, Funktion aber fehlerhaft

    Ursache: Abhängigkeiten, Routing oder Berechtigungen sind inkonsistent.

    sudo cscli collections list
    sudo cscli parsers list
    sudo journalctl -u crowdsec -n 200 --no-pager

    Fazit

    Mit einem klaren Ablauf für CrowdSec auf Debian produktiv betreiben reduzierst du Ausfälle und erhöhst die Wartbarkeit deutlich. Der wichtigste Hebel ist die Kombination aus kleiner Änderung, sofortigem Check und dokumentiertem Ergebnis.

    Nächster Schritt: den Ablauf als monatliche Betriebsroutine einplanen und regelmäßig gegen echte Störfälle testen.

    Quellen

  • Home Assistant Updates ohne Ausfallstress: Compose-Workflow mit Rollback

    Home Assistant Updates ohne Ausfallstress: Compose-Workflow mit Rollback

    Schwierigkeit: Mittel · Dauer: 35–60 Min · Ziel: Home-Assistant-Updates reproduzierbar ausrollen und bei Problemen schnell zurückrollen.

    Kurzproblem und Zielbild

    Home Assistant wächst schnell mit Integrationen. Unkontrollierte Updates führen oft zu Ausfällen oder kaputten Add-ons. Ziel ist ein klarer Update-Workflow mit Backup, Check und Rollback.

    Voraussetzungen

    • Home Assistant via Docker Compose
    • Persistente Config unter ./config
    • Backup-Möglichkeit vor Update

    Schnellstart (funktionierende Basis)

    cd ~/stacks/homeassistant
    tar -czf backup-ha-$(date +%F-%H%M).tar.gz ./config
    docker compose pull
    docker compose up -d

    Schritt-für-Schritt Umsetzung

    1) Pre-Update Snapshot

    tar -czf backup-ha-$(date +%F-%H%M).tar.gz ./config
    cp compose.yml backup-compose-$(date +%F-%H%M).yml

    2) Update kontrolliert ausrollen

    docker compose pull
    docker compose up -d --remove-orphans
    docker compose ps

    3) Kernfunktionen prüfen

    docker compose logs --tail=180 homeassistant
    # Login/UI, Automationen, Integrationen testen

    4) Rollback bei Fehlern

    docker compose down
    cp backup-compose-YYYY-MM-DD-HHMM.yml compose.yml
    # ggf. config-backup zurückspielen
    docker compose up -d

    Validierung / Checks

    docker compose ps
    docker compose logs --tail=200 homeassistant
    curl -I http://localhost:8123

    Troubleshooting

    Container startet, UI bleibt unzuverlässig

    docker compose logs homeassistant --tail=250
    # fehlerhafte custom components prüfen

    Integrationen nach Update fehlerhaft

    # letzte stabile Version pinnen und erneut deployen

    Fazit

    Mit klarer Update-Routine wird Home Assistant deutlich berechenbarer. Nächster Schritt: festen Wartungstermin + Checkliste pro Update einführen.

    Quellen

  • Uptime Kuma Alerts sinnvoll aufsetzen: weniger Lärm, bessere Signale

    Uptime Kuma Alerts sinnvoll aufsetzen: weniger Lärm, bessere Signale

    Schwierigkeit: Leicht · Dauer: 30–50 Min · Ziel: Uptime-Kuma-Checks und Benachrichtigungen so konfigurieren, dass echte Störungen schnell sichtbar werden.

    Kurzproblem und Zielbild

    Zu aggressive Monitoring-Defaults erzeugen Alarmrauschen. Ziel ist ein stabiles Signal-Rausch-Verhältnis mit klaren Intervallen, Timeouts und sauberen Notification-Profilen.

    Voraussetzungen

    • Laufende Uptime-Kuma-Instanz
    • Mindestens ein Notification-Channel (Mail/Discord/Telegram)
    • Liste kritischer Dienste

    Schnellstart (funktionierende Basis)

    docker ps | grep uptime-kuma
    # UI öffnen und 3 kritische Monitore anlegen
    # Intervall 60s, Retry 2, Timeout 16s

    Schritt-für-Schritt Umsetzung

    1) Monitore nach Kritikalität gruppieren

    # Kritisch: Auth, Reverse Proxy, DNS
    # Wichtig: Medien/Tools
    # Nice-to-have: Nebenservices

    2) Timeouts/Retry je Diensttyp

    # HTTP intern: timeout 10-16s
    # Extern über WAN: timeout 20-30s
    # retry sparsam nutzen, sonst Alarmflut

    3) Wartungsfenster definieren

    # Geplante Updates als Maintenance in Kuma eintragen

    4) Alert-Routing trennen

    # Kritisch -> sofort Push
    # Nicht-kritisch -> gesammelt / zeitversetzt

    Validierung / Checks

    # 1) Kuma-Container und Health prüfen
    docker ps --filter name=uptime-kuma
    curl -fsS http://127.0.0.1:3001 >/dev/null && echo "Kuma UI erreichbar"
    
    # 2) Gezielten Ausfall simulieren (Beispielservice)
    docker stop reverse-proxy
    sleep 90
    
    # 3) Prüfen: genau 1 Alert + Recovery nach Wiederanlauf
    docker start reverse-proxy
    sleep 90
    
    # 4) Kuma-Logs auf Flapping/Fehler prüfen
    docker logs --since 10m uptime-kuma | tail -n 120

    Troubleshooting

    Zu viele Fehlalarme

    # DNS/Latenz prüfen
    dig +short example.local
    ping -c 4 example.local
    
    # Host-Antwortzeit testen
    curl -o /dev/null -s -w "HTTP:%{http_code} TIME:%{time_total}\n" https://example.local
    
    # Danach in Kuma: Timeout +5s, Retry -1

    Recovery-Meldung fehlt

    # Notification-Test in Kuma auslösen
    # Settings -> Notifications -> Test
    
    # Container-Logs nach Sendefehlern durchsuchen
    docker logs --since 30m uptime-kuma | grep -Ei "notify|telegram|discord|smtp|error" | tail -n 80

    Fazit

    Gutes Monitoring ist nicht „mehr Monitore“, sondern bessere Priorisierung. Nächster Schritt: monatlich die noisiesten Checks identifizieren und nachschärfen.

    Quellen

  • OPNsense Regeln sauber aufbauen: Segmentierung, NAT und Wartbarkeit

    OPNsense Regeln sauber aufbauen: Segmentierung, NAT und Wartbarkeit

    Schwierigkeit: Mittel · Dauer: 45–75 Min · Ziel: OPNsense-Regeln konsistent aufbauen, damit Netzwerkzugriffe nachvollziehbar und sicher bleiben.

    Kurzproblem und Zielbild

    Viele OPNsense-Setups wachsen mit Einzelregeln und verlieren schnell die Übersicht. Ziel ist ein klarer, wiederholbarer Regelaufbau mit Segmentierung, nachvollziehbarem NAT und sauberen Checks.

    Voraussetzungen

    • OPNsense mit administrativem Zugriff
    • Definierte Netze/VLANs
    • Wartungsfenster und Backup vor Regeländerungen

    Schnellstart (funktionierende Basis)

    cp /conf/config.xml /conf/config.xml.bak.$(date +%F-%H%M)
    pfctl -sr
    configctl filter status

    Schritt-für-Schritt Umsetzung

    1) Regelmodell festlegen

    # Prinzip: erst erlaubte Flows definieren, dann default deny
    # Beispielzonen: LAN, SERVER, IOT, MGMT

    2) Aliases für Dienste/Netze

    # in OPNsense GUI: Firewall > Aliases
    # z.B. RFC1918_INTERNAL, DNS_SERVERS, MGMT_HOSTS

    3) NAT konsistent halten

    # Outbound NAT auf Hybrid/Manual nur wenn nötig
    # Portforwards nur mit zugehöriger Filterregel

    4) Logging für kritische Regeln

    # Block-/Allow-Regeln für sensible Segmente mit Logging aktivieren

    Validierung / Checks

    pfctl -sr
    pfctl -sn
    configctl filter status
    clog -f /var/log/filter/filter.log

    Troubleshooting

    Traffic bricht nach Regeländerung

    pfctl -sr | less
    # Reihenfolge prüfen, pass/quick beachten

    Portforward greift nicht

    pfctl -sn
    # zugehörige Filterregel und Zielhost prüfen

    Fazit

    Mit Alias-basiertem Regelwerk und klarer Segmentierung bleibt OPNsense langfristig wartbar. Nächster Schritt: monatlicher Regel-Review mit Cleanup veralteter Ausnahmen.

    Quellen

  • WireGuard Site-to-Site im Homelab: stabile Basis mit systemd und Checks

    WireGuard Site-to-Site im Homelab: stabile Basis mit systemd und Checks

    Schwierigkeit: Mittel · Dauer: 35–55 Min · Ziel: Zwei Netze per WireGuard stabil verbinden und den Betrieb mit systemd absichern.

    Kurzproblem und Zielbild

    Site-to-Site-Setups sind oft instabil durch fehlende Keepalive-/Routing-Checks. Ziel: stabiler Tunnel mit definierten AllowedIPs, sauberem Autostart und reproduzierbarer Prüfung.

    Voraussetzungen

    • Zwei Linux-Systeme mit WireGuard
    • Öffentlich erreichbarer Endpoint auf mindestens einer Seite
    • Firewall-Freigabe UDP 51820

    Schnellstart (funktionierende Basis)

    sudo systemctl enable wg-quick@wg0.service
    sudo systemctl start wg-quick@wg0.service
    sudo wg show

    Schritt-für-Schritt Umsetzung

    1) Schlüssel erstellen

    umask 077
    wg genkey | tee privatekey | wg pubkey > publickey

    2) Minimal-Konfig setzen

    [Interface]
    Address = 10.10.10.1/24
    PrivateKey = <PRIVATE_KEY>
    ListenPort = 51820
    
    [Peer]
    PublicKey = <PEER_PUBLIC_KEY>
    AllowedIPs = 10.10.10.0/24, 192.168.50.0/24
    Endpoint = vpn.example.tld:51820
    PersistentKeepalive = 25

    3) Start + Persistenz

    sudo systemctl daemon-reload
    sudo systemctl enable wg-quick@wg0.service
    sudo systemctl restart wg-quick@wg0.service

    4) Routing/Erreichbarkeit prüfen

    ip route
    ping -c 3 10.10.10.2
    wg show

    Validierung / Checks

    systemctl status wg-quick@wg0 --no-pager
    wg show
    journalctl -u wg-quick@wg0 -n 120 --no-pager

    Troubleshooting

    Kein Handshake

    sudo ss -lunp | grep 51820
    sudo wg show

    Handshake da, aber keine Route

    ip route
    # AllowedIPs/Forwarding prüfen

    Fazit

    Mit klarer Minimal-Konfig + systemd + festen Checks wird Site-to-Site-WireGuard im Homelab deutlich stabiler. Nächster Schritt: Monitoring auf Handshake-Alter und Paketzähler.

    Quellen

  • Proxmox Backup richtig prüfen: Restore-Tests statt Backup-Illusion

    Proxmox Backup richtig prüfen: Restore-Tests statt Backup-Illusion

    Schwierigkeit: Mittel · Dauer: 40–70 Min · Ziel: Proxmox-Backups regelmäßig verifizieren und Restore-Pfade praktisch testen.

    Kurzproblem und Zielbild

    Backups ohne Restore-Test geben trügerische Sicherheit. Ziel ist ein kurzer, reproduzierbarer Prüfprozess mit klaren Kriterien: Backup vorhanden, konsistent, in vertretbarer Zeit wiederherstellbar.

    Voraussetzungen

    • Proxmox VE + Backup-Storage/PBS
    • Mindestens eine VM/CT für Test-Restore
    • Wartungsfenster

    Schnellstart (funktionierende Basis)

    vzdump --all 1 --mode snapshot --compress zstd --storage <STORAGE>
    pvesm status
    qm list
    pct list

    Schritt-für-Schritt Umsetzung

    1) Backup-Jobs und Logs prüfen

    grep -R "vzdump" /etc/pve/jobs.cfg
    journalctl -u pvedaemon -n 200 --no-pager

    2) Test-VM wiederherstellen

    qmrestore /path/to/backup.vma.zst 9001 --storage <TARGET>
    qm start 9001

    3) Funktions-Check

    qm status 9001
    # optional: service checks in restored VM

    4) Ergebnis dokumentieren

    echo "$(date -Iseconds) restore test OK" >> /root/restore-tests.log

    Validierung / Checks

    pvesm status
    qm status 9001
    ls -lh /var/log/ | head

    Troubleshooting

    Restore bricht mit Storage-Fehler ab

    pvesm status
    # Storage online/space prüfen

    VM bootet nach Restore nicht

    qm config 9001
    qm terminal 9001

    Fazit

    Restore-Tests machen aus Backups einen verlässlichen Betriebsprozess. Nächster Schritt: monatlichen Restore-Drill fix im Kalender verankern.

    Quellen

  • Docker Compose Deployments robust machen: Struktur, Healthchecks, Rollback

    Docker Compose Deployments robust machen: Struktur, Healthchecks, Rollback

    Schwierigkeit: Mittel · Dauer: 45–60 Min · Ziel: Docker-Compose-Stacks reproduzierbar deployen, validieren und sicher zurückrollen.

    Kurzproblem und Zielbild

    Viele Compose-Setups funktionieren initial, brechen aber bei Updates oder Neustarts durch fehlende Checks und unsaubere Struktur. Ziel ist ein Ablauf, der auch unter Last stabil bleibt und im Fehlerfall schnell zurückgerollt werden kann.

    Voraussetzungen

    • Debian/Ubuntu Host mit Docker + Compose Plugin
    • Sudo-Zugriff
    • Freie Volumes/Backups vor Änderungen

    Schnellstart (funktionierende Basis)

    mkdir -p ~/stacks/app && cd ~/stacks/app
    nano compose.yml
    docker compose pull
    docker compose up -d
    docker compose ps

    Was macht das? Erzeugt einen reproduzierbaren Stack-Ordner, zieht Images und startet den Stack kontrolliert.

    Schritt-für-Schritt Umsetzung

    1) Struktur und Variablen trennen

    mkdir -p ~/stacks/app/{config,data,backup}
    cp compose.yml compose.yml.bak
    nano .env

    Erklärung: Trennung reduziert Fehler bei Upgrades und vereinfacht Restore.

    2) Healthchecks definieren

    services:
      app:
        healthcheck:
          test: ["CMD", "curl", "-f", "http://localhost:8080/health"]
          interval: 30s
          timeout: 5s
          retries: 5

    3) Update-Fenster mit Validierung

    docker compose pull
    docker compose up -d --remove-orphans
    docker compose ps
    docker compose logs --tail=120

    4) Rollback vorbereiten

    cp compose.yml backup/compose-$(date +%F-%H%M).yml
    # im Fehlerfall:
    cp backup/compose-YYYY-MM-DD-HHMM.yml compose.yml
    docker compose up -d

    Validierung / Checks

    docker compose ps
    curl -fsS http://localhost:8080/health
    journalctl -u docker -n 120 --no-pager

    Troubleshooting

    Healthcheck bleibt „unhealthy“

    Ursache: Falscher Endpoint oder Startdauer zu kurz.

    docker compose logs app --tail=200
    # retries/timeout erhöhen

    Update startet, Service nicht erreichbar

    Ursache: Inkompatibles Image/Config.

    docker compose down
    cp backup/compose-*.yml compose.yml
    docker compose up -d

    Fazit

    Mit sauberer Struktur, Healthchecks und Rollback-Plan werden Compose-Deployments deutlich robuster. Nächster Schritt: Monitoring für Containerzustände ergänzen.

    Quellen