{"id":8702,"date":"2026-08-14T17:25:00","date_gmt":"2026-08-14T15:25:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=8702"},"modified":"2026-08-13T14:29:51","modified_gmt":"2026-08-13T12:29:51","slug":"automatisierte-docker-deployments-raspberry-pi-local-first-8702","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/de\/raspberry-pi-de\/automatisierte-docker-deployments-raspberry-pi-local-first-8702\/","title":{"rendered":"Automatisierte Docker-Deployments auf dem Raspberry Pi: Local-First Dev Environments"},"content":{"rendered":"\r\n

Der Betrieb selbstgehosteter Dienste \u2013 wie Home Assistant, Node-RED oder lokaler Analytics-Tracking-Umgebungen \u2013 auf einem Raspberry Pi erfordert im klassischen Setup h\u00e4ufig manuelle Software-Updates und unstrukturierte Konfigurations\u00e4nderungen. Dieser Ansatz bindet wertvolle Administrationszeit und birgt signifikante operative Risiken, darunter Konfigurationsdrift, Abh\u00e4ngigkeitskonflikte und unerwartete Ausfallzeiten.<\/p>\r\n\r\n\r\n\r\n

F\u00fcr eine resiliente, deterministische lokale Infrastruktur muss die Service-Schicht strikt vom zugrundeliegenden Host-Betriebssystem entkoppelt werden. Die vollst\u00e4ndige Containerisierung der Smart-Home- und Analytics-Tool-Landschaft mittels Docker Compose<\/strong> in Kombination mit automatisierten Deployment-Pipelines \u2013 sei es \u00fcber lokale Watchtower<\/strong>-Setups oder strukturierte CI\/CD-Workflows via GitHub Actions<\/strong> \u2013 garantiert reproduzierbare und ausfallsichere Edge-Umgebungen.<\/p>\r\n\r\n\r\n\r\n

1. Containerisierung der Edge-Landschaft mit Docker Compose<\/h2>\r\n\r\n\r\n\r\n

Docker Compose bildet das deklarative Fundament moderner Local-First-Architekturen. Durch die Definition s\u00e4mtlicher Dienste, persistenter Volume-Mounts und virtueller Netzwerkbr\u00fccken in einer versionskontrollierten Konfigurationsdatei wird der Systemzustand vollst\u00e4ndig reproduzierbar.<\/p>\r\n\r\n\r\n\r\n

# docker-compose.yml: Integrierter Smart-Home- & Tracking-Stack\r\nservices:\r\n  homeassistant:\r\n    container_name: homeassistant\r\n    image: ghcr.io\/home-assistant\/home-assistant:stable\r\n    volumes:\r\n      - \/opt\/homeassistant\/config:\/config\r\n      - \/etc\/localtime:\/etc\/localtime:ro\r\n    restart: unless-stopped\r\n    network_mode: host\r\n\r\n  nodered:\r\n    container_name: nodered\r\n    image: nodered\/node-red:latest\r\n    environment:\r\n      - TZ=Europe\/Warsaw\r\n    volumes:\r\n      - \/opt\/nodered\/data:\/data\r\n    ports:\r\n      - \"1880:1880\"\r\n    restart: unless-stopped\r\n\r\n  watchtower:\r\n    container_name: watchtower\r\n    image: containrrr\/watchtower:latest\r\n    volumes:\r\n      - \/var\/run\/docker.sock:\/var\/run\/docker.sock\r\n    environment:\r\n      - WATCHTOWER_CLEANUP=true\r\n      - WATCHTOWER_SCHEDULE=0 0 4 * * *\r\n    restart: unless-stopped<\/code><\/pre>\r\n\r\n\r\n\r\n
Ein Hinweis zum Wartungsstand: Das Ursprungsprojekt containrrr\/watchtower<\/code> wurde am 17. Dezember 2025 archiviert und ist seitdem schreibgesch\u00fctzt; das Image erh\u00e4lt also keine weiteren Aktualisierungen oder Sicherheitskorrekturen. Einen offiziellen Nachfolger haben die urspr\u00fcnglichen Maintainer nicht benannt. Die Weiterentwicklung findet in Community-Forks statt \u2013 nickfedor\/watchtower<\/code> (ebenfalls als ghcr.io\/nicholas-fedor\/watchtower<\/code> ver\u00f6ffentlicht) ist konfigurationskompatibel und erscheint weiterhin in regelm\u00e4\u00dfigen Releases. Vor dem produktiven Einsatz sollte der Aktualisierungspfad dieses Dienstes daher gepr\u00fcft werden.<\/p>\r\n\r\n\r\n\r\n
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 \u00fcberschreiben.<\/p>\r\n\r\n\r\n\r\n
\n\"Diagramm\n
Die 3 Bausteine des Artikels auf einen Blick: Containerisierung der Edge-Landschaft mit Docker\u2026, Automatisierte Wartung: Watchtower vs.\u2026, Implementierung einer\u2026.<\/figcaption>\n<\/figure>\n\n
2. Automatisierte Wartung: Watchtower vs. CI\/CD-Pipelines<\/h2>\r\n\r\n\r\n\r\n
Die Automatisierung von Deployments und Lebenszyklus-Management kann in Abh\u00e4ngigkeit von Systemkomplexit\u00e4t und Governance-Anforderungen \u00fcber zwei prim\u00e4re Architekturmuster realisiert werden:<\/p>\r\n\r\n\r\n\r\n
Deployment-Muster<\/th>Ausf\u00fchrungsmechanismus<\/th>Optimal geeignet f\u00fcr<\/th>Zentraler Vorteil<\/th><\/tr><\/thead>
Lokale Automatisierung (Watchtower)<\/strong><\/td>Ein Hintergrund-Dienst pr\u00fcft Image-Registries t\u00e4glich und startet aktualisierte Container automatisch neu.<\/td>Standard-Images (Home Assistant, Node-RED, Eclipse Mosquitto).<\/td>Keine externe Infrastruktur erforderlich; vollautonome Wartung an der Edge.<\/td><\/tr>
GitOps \/ CI\/CD (GitHub Actions)<\/strong><\/td>Code-Commits initiieren remote Build-Pipelines, die per SSH auf dem Raspberry Pi deployen.<\/td>Spezifische Eigenentwicklungen, propriet\u00e4re Analytics-Tools oder Multi-Node-Infrastrukturen.<\/td>Deterministische Versionskontrolle, automatisierte Tests vor dem Deployment und einfache Rollbacks.<\/td><\/tr><\/tbody><\/table><\/figure>\r\n\r\n\r\n\r\n
3. Implementierung einer GitHub-Actions-Deployment-Pipeline<\/h2>\r\n\r\n\r\n\r\n
F\u00fcr spezifische Edge-Applikationen oder strukturierte Infrastructure-as-Code-Repositories (IaC) bietet das Deployment \u00fcber GitHub Actions eine l\u00fcckenlose Historie aller Konfigurations\u00e4nderungen. Sobald \u00c4nderungen im Hauptzweig freigegeben werden, verbindet sich ein Workflow sicher per SSH mit dem Raspberry Pi, ruft die Neuerungen ab und rekonfiguriert den Stack.<\/p>\r\n\r\n\r\n\r\n
# .github\/workflows\/deploy-edge.yml\r\nname: Deploy Stack to Raspberry Pi\r\n\r\non:\r\n  push:\r\n    branches:\r\n      - main\r\n\r\njobs:\r\n  deploy:\r\n    runs-on: ubuntu-latest\r\n    steps:\r\n      - name: Execute Remote Deployment via SSH\r\n        uses: appleboy\/ssh-action@v1.0.0\r\n        with:\r\n          host: ${{ secrets.RPI_HOST }}\r\n          username: ${{ secrets.RPI_USER }}\r\n          key: ${{ secrets.RPI_SSH_KEY }}\r\n          script: |\r\n            cd \/opt\/edge-stack\r\n            git pull origin main\r\n            docker compose pull\r\n            docker compose up -d --remove-orphans\r\n            docker system prune -f<\/code><\/pre>\r\n\r\n\r\n\r\n
Zusammenfassung<\/h2>\r\n\r\n\r\n\r\n
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 \u00fcber autonome Watchtower-Aktualisierungen oder deterministische GitOps-Workflows via GitHub Actions: Containerisierung garantiert eine stabile, sichere und wartungsarme Betriebsumgebung f\u00fcr Smart-Home- und Analytics-Infrastrukturen.<\/p>\r\n\n\n
\n
Quellen<\/h2>\n