Automatisierte Docker-Deployments auf dem Raspberry Pi: Local-First Dev Environments
Teil 3 von 4 der Reihe Homelab auf dem Raspberry Pi

Inhalt
Der Betrieb selbstgehosteter Dienste – wie Home Assistant, Node-RED oder lokaler Analytics-Tracking-Umgebungen – auf einem Raspberry Pi erfordert im klassischen Setup häufig manuelle Software-Updates und unstrukturierte Konfigurationsänderungen. Dieser Ansatz bindet wertvolle Administrationszeit und birgt signifikante operative Risiken, darunter Konfigurationsdrift, Abhängigkeitskonflikte und unerwartete Ausfallzeiten.
Für eine resiliente, deterministische lokale Infrastruktur muss die Service-Schicht strikt vom zugrundeliegenden Host-Betriebssystem entkoppelt werden. Die vollständige Containerisierung der Smart-Home- und Analytics-Tool-Landschaft mittels Docker Compose in Kombination mit automatisierten Deployment-Pipelines – sei es über lokale Watchtower-Setups oder strukturierte CI/CD-Workflows via GitHub Actions – garantiert reproduzierbare und ausfallsichere Edge-Umgebungen.
1. Containerisierung der Edge-Landschaft mit Docker Compose
Docker Compose bildet das deklarative Fundament moderner Local-First-Architekturen. Durch die Definition sämtlicher Dienste, persistenter Volume-Mounts und virtueller Netzwerkbrücken in einer versionskontrollierten Konfigurationsdatei wird der Systemzustand vollständig reproduzierbar.
# docker-compose.yml: Integrierter Smart-Home- & Tracking-Stack
services:
homeassistant:
container_name: homeassistant
image: ghcr.io/home-assistant/home-assistant:stable
volumes:
- /opt/homeassistant/config:/config
- /etc/localtime:/etc/localtime:ro
restart: unless-stopped
network_mode: host
nodered:
container_name: nodered
image: nodered/node-red:latest
environment:
- TZ=Europe/Warsaw
volumes:
- /opt/nodered/data:/data
ports:
- "1880:1880"
restart: unless-stopped
watchtower:
container_name: watchtower
image: containrrr/watchtower:latest
volumes:
- /var/run/docker.sock:/var/run/docker.sock
environment:
- WATCHTOWER_CLEANUP=true
- WATCHTOWER_SCHEDULE=0 0 4 * * *
restart: unless-stopped
Ein Hinweis zum Wartungsstand: Das Ursprungsprojekt containrrr/watchtower wurde am 17. Dezember 2025 archiviert und ist seitdem schreibgeschützt; das Image erhält also keine weiteren Aktualisierungen oder Sicherheitskorrekturen. Einen offiziellen Nachfolger haben die ursprünglichen Maintainer nicht benannt. Die Weiterentwicklung findet in Community-Forks statt – nickfedor/watchtower (ebenfalls als ghcr.io/nicholas-fedor/watchtower veröffentlicht) ist konfigurationskompatibel und erscheint weiterhin in regelmäßigen Releases. Vor dem produktiven Einsatz sollte der Aktualisierungspfad dieses Dienstes daher geprüft werden.
In dieser Architektur befinden sich die persistenten Datenverzeichnisse auf externem, ausfallsicherem Speicher (wie einer NAS-Freigabe oder SSD), sodass Container-Aktualisierungen niemals bestehende Konfigurationen oder historisierte Metriken überschreiben.
2. Automatisierte Wartung: Watchtower vs. CI/CD-Pipelines
Die Automatisierung von Deployments und Lebenszyklus-Management kann in Abhängigkeit von Systemkomplexität und Governance-Anforderungen über zwei primäre Architekturmuster realisiert werden:
| Deployment-Muster | Ausführungsmechanismus | Optimal geeignet für | Zentraler Vorteil |
|---|---|---|---|
| Lokale Automatisierung (Watchtower) | Ein Hintergrund-Dienst prüft Image-Registries täglich und startet aktualisierte Container automatisch neu. | Standard-Images (Home Assistant, Node-RED, Eclipse Mosquitto). | Keine externe Infrastruktur erforderlich; vollautonome Wartung an der Edge. |
| GitOps / CI/CD (GitHub Actions) | Code-Commits initiieren remote Build-Pipelines, die per SSH auf dem Raspberry Pi deployen. | Spezifische Eigenentwicklungen, proprietäre Analytics-Tools oder Multi-Node-Infrastrukturen. | Deterministische Versionskontrolle, automatisierte Tests vor dem Deployment und einfache Rollbacks. |
3. Implementierung einer GitHub-Actions-Deployment-Pipeline
Für spezifische Edge-Applikationen oder strukturierte Infrastructure-as-Code-Repositories (IaC) bietet das Deployment über GitHub Actions eine lückenlose Historie aller Konfigurationsänderungen. Sobald Änderungen im Hauptzweig freigegeben werden, verbindet sich ein Workflow sicher per SSH mit dem Raspberry Pi, ruft die Neuerungen ab und rekonfiguriert den Stack.
# .github/workflows/deploy-edge.yml
name: Deploy Stack to Raspberry Pi
on:
push:
branches:
- main
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- name: Execute Remote Deployment via SSH
uses: appleboy/ssh-action@v1.0.0
with:
host: ${{ secrets.RPI_HOST }}
username: ${{ secrets.RPI_USER }}
key: ${{ secrets.RPI_SSH_KEY }}
script: |
cd /opt/edge-stack
git pull origin main
docker compose pull
docker compose up -d --remove-orphans
docker system prune -f
Zusammenfassung
Die Transformation eines Raspberry Pi von einem manuell verwalteten Einplatinencomputer hin zu einem automatisierten, containerisierten Edge-Server reduziert den administrativen Aufwand auf ein Minimum. Ob über autonome Watchtower-Aktualisierungen oder deterministische GitOps-Workflows via GitHub Actions: Containerisierung garantiert eine stabile, sichere und wartungsarme Betriebsumgebung für Smart-Home- und Analytics-Infrastrukturen.
Homelab auf dem Raspberry Pi
- Raspberry Pi 4 und 5: Vom SSD-Laufwerk booten über den Bootloader
- Unterbrechungsfreie Stromversorgung (USV) für Raspberry Pi 4 und 5: Die Top 5 Lösungen für anspruchsvolle Setups
- Automatisierte Docker-Deployments auf dem Raspberry Pi: Local-First Dev Environments
- Lokales CI/CD für den Raspberry Pi: Automatisierung von Docker-Compose-Deployments
2 Kommentare
Die Gegenüberstellung von Watchtower und einer Pipeline trifft die eigentliche Entscheidung: fertige Abbilder gegen eigene Anwendungen, nicht Bequemlichkeit gegen Kontrolle.
Beim zweiten Weg bleibt mir ein Unbehagen: Der private Schlüssel für den Zugang zum Pi liegt als Geheimnis im Repository-Dienst. Gibt es dazu eine sparsamere Variante?
Ja, und sie kostet zwei Zeilen. Der Schlüssel bleibt, wo er ist — begrenzt wird, was er ausrichten kann.
In der Datei mit den erlaubten Schlüsseln lässt sich vor den Schlüssel eine erzwungene Anweisung setzen. Eine Anmeldung mit genau diesem Schlüssel führt dann ausschliesslich das hinterlegte Bereitstellungsskript aus, unabhängig davon, was der Aufruf verlangt. Dazu passen die üblichen Einschränkungen in derselben Zeile: keine Weiterleitung von Anschlüssen, kein Terminal.
Damit verschiebt sich der Schaden eines abhandengekommenen Geheimnisses von „Zugang zum Server“ auf „Auslösen einer Bereitstellung“. Zwei Ergänzungen runden das ab: ein eigener Benutzer statt des Hauptkontos, Mitglied der Docker-Gruppe und sonst nichts, sowie ein Skript, das keine Argumente entgegennimmt — sonst wandert die Angriffsfläche einfach in dessen Parameter.