LW IT Solutions
« Blog Overview /Raspberry Pi / Automatisierte Docker-Deployments auf dem Raspberry Pi: Local-First...
This post in other languages:

Automatisierte Docker-Deployments auf dem Raspberry Pi: Local-First Dev Environments

Teil 3 von 4 der Reihe Homelab auf dem Raspberry Pi

Automatisierte Docker-Deployments auf dem Raspberry Pi: Local-First Dev Environments
Inhalt
  1. 1. Containerisierung der Edge-Landschaft mit Docker Compose
  2. 2. Automatisierte Wartung: Watchtower vs. CI/CD-Pipelines
  3. 3. Implementierung einer GitHub-Actions-Deployment-Pipeline
  4. Zusammenfassung
  5. Quellen

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.

Diagramm zum Artikel: Containerisierung der Edge-Landschaft mit Docker…, Automatisierte Wartung: Watchtower vs.…, Implementierung einer…
Die 3 Bausteine des Artikels auf einen Blick: Containerisierung der Edge-Landschaft mit Docker…, Automatisierte Wartung: Watchtower vs.…, Implementierung einer….

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-MusterAusführungsmechanismusOptimal geeignet fürZentraler 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

  1. Raspberry Pi 4 und 5: Vom SSD-Laufwerk booten über den Bootloader
  2. Unterbrechungsfreie Stromversorgung (USV) für Raspberry Pi 4 und 5: Die Top 5 Lösungen für anspruchsvolle Setups
  3. Automatisierte Docker-Deployments auf dem Raspberry Pi: Local-First Dev Environments
  4. Lokales CI/CD für den Raspberry Pi: Automatisierung von Docker-Compose-Deployments
Lukas Wojcik

Lukas Wojcik

Systems architect and technology enthusiast specializing in scalable tracking solutions, GMP Stack (GA4 & GTM), and robust backend architectures. Advocate for clean code and privacy-first design.

Get in Touch

Briefly describe your project or inquiry for a tailored response. This site is protected by reCAPTCHA.

2 Kommentare

  1. Marlis Kettner

    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?

    1. Lukas Wojcik Autor

      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.

Kommentar schreiben

Die E-Mail-Adresse wird nicht veröffentlicht. Pflichtfelder sind mit einem Stern versehen.

ALL ARTICLES & CATEGORIES

CCTV

Diese Rubrik per RSS verfolgen

Cloud & AI

Diese Rubrik per RSS verfolgen

Data Privacy

Alle 11 Artikel dieser Rubrik Diese Rubrik per RSS verfolgen

Digital Analytics

Alle 44 Artikel dieser Rubrik Diese Rubrik per RSS verfolgen

Digital Marketing

Alle 25 Artikel dieser Rubrik Diese Rubrik per RSS verfolgen

IT & Networks

Alle 15 Artikel dieser Rubrik Diese Rubrik per RSS verfolgen

Raspberry Pi

Diese Rubrik per RSS verfolgen

Smart Home

Alle 11 Artikel dieser Rubrik Diese Rubrik per RSS verfolgen

Web Entwicklung

Diese Rubrik per RSS verfolgen

WordPress-Plugins & Tricks

Diese Rubrik per RSS verfolgen