{"id":430,"date":"2026-08-31T11:30:00","date_gmt":"2026-08-31T09:30:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/?p=430"},"modified":"2026-08-19T10:10:48","modified_gmt":"2026-08-19T08:10:48","slug":"local-ci-cd-raspberry-pi-automating-docker-compose-de","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/de\/raspberry-pi-de\/local-ci-cd-raspberry-pi-automating-docker-compose-de\/","title":{"rendered":"Lokales CI\/CD f\u00fcr den Raspberry Pi: Automatisierung von Docker-Compose-Deployments"},"content":{"rendered":"\r\n
Die Verwaltung von Container-Infrastrukturen auf Edge-Ger\u00e4ten wie einem Raspberry Pi ist im Alltag oft mit wiederholten manuellen SSH-Sitzungen, h\u00e4ndischen Image-Downloads und dem direkten Ausf\u00fchren von Docker-Compose-Befehlen verbunden. Der Wechsel zu einer lokalen CI\/CD-Pipeline automatisiert den gesamten Lebenszyklus selbstgehosteter Anwendungen \u2013 darunter Home Assistant, Nextcloud und ma\u00dfgeschneiderte Python-Skripte \u2013 mit Git-Repositories, Webhook-Listenern und lokalen Deploy-Agenten.<\/p>\r\n\r\n\r\n\r\n
1. Architektur von lokalem GitOps auf Edge-Hardware<\/h2>\r\n\r\n\r\n\r\n
Die Einf\u00fchrung eines GitOps-Konzepts verlagert die zentrale Datengrundlage s\u00e4mtlicher Infrastrukturkonfigurationen vom lokalen Dateisystem in ein zentrales Git-Repository. Anstatt YAML-Dateien direkt auf dem System zu modifizieren, werden alle Bereitstellungsdefinitionen in der Versionskontrolle gepflegt.<\/p>\r\n\r\n\r\n\r\n
\r\n
Deklarative Konfiguration:<\/strong> S\u00e4mtliche Dienste, Netzwerkdefinitionen und persistenten Speicherinhalte werden klar strukturiert in docker-compose.yml<\/code>-Dateien innerhalb eines Git-Repositories abgebildet.<\/li>\r\n
Nachvollziehbarkeit & Rollbacks:<\/strong> Die Versionskontrolle bietet eine l\u00fcckenlose Historie aller Konfigurations\u00e4nderungen, was im Fehlerfall ein sofortiges Zur\u00fccksetzen auf einen stabilen vorherigen Zustand erm\u00f6glicht.<\/li>\r\n
Wartungsfreier Betrieb:<\/strong> Der Edge-Server agiert als kontinuierlicher Abnehmer des Repository-Zustands, wodurch manuelle Shell-Eingriffe bei Standard-Updates entfallen.<\/li>\r\n<\/ul>\r\n\r\n\r\n\r\n\n\nDas Edge-Ger\u00e4t ist Konsument, nicht Ziel: Es zieht den Repository-Zustand selbst und bringt seinen Stack in Deckung. Die HMAC-Pr\u00fcfung ist das Tor \u2014 ein nicht verifizierter Webhook erreicht den Pull nie.<\/figcaption>\n<\/figure>\n\n
Um manuelle SSH-Befehle vollst\u00e4ndig abzul\u00f6sen, k\u00f6nnen ressourcenschonende Webhook-Server (wie adnanh\/webhook<\/code> oder spezialisierte Automatisierungsdienstprogramme) direkt auf dem Raspberry Pi installiert werden. Diese Dienste empfangen eingehende HTTP-POST-Signale, die durch Push-Ereignisse im Code-Repository oder durch externe CI\/CD-Systeme ausgel\u00f6st werden.<\/p>\r\n\r\n\r\n\r\n
Ablauf der Webhook-Ausf\u00fchrung<\/h3>\r\n\r\n\r\n\r\n
\r\n
Validierung der Anfragen:<\/strong> Eingehende Webhook-Aufrufe werden kryptografisch \u00fcber HMAC-Schl\u00fcssel auf Authentizit\u00e4t gepr\u00fcft, um unbefugten Zugriff zu verhindern.<\/li>\r\n
Automatischer Git-Abruf:<\/strong> Nach erfolgreicher Pr\u00fcfung startet der Hintergrunddienst einen Aktualisierungsprozess, um das lokale Arbeitsverzeichnis auf den Stand des externen Hauptbranches zu bringen.<\/li>\r\n
Rekonvergenz der Container:<\/strong> Der Ausf\u00fchrungsdienst startet den Befehl docker compose up -d --remove-orphans<\/code>, sodass ausschlie\u00dflich ver\u00e4nderte Container-Images oder angepasste Konfigurationen neu erstellt werden.<\/li>\r\n<\/ul>\r\n\r\n\r\n\r\n
3. Lebenszyklus-Management ohne SSH<\/h2>\r\n\r\n\r\n\r\n
Architekturen f\u00fcr die kontinuierliche Bereitstellung im Self-Hosting-Bereich profitieren von lokalen Agenten, die Container-Registries \u00fcberwachen und die Erneuerung von Containern vollautomatisch durchf\u00fchren.<\/p>\r\n\r\n\r\n\r\n
\r\n
Automatisierte \u00dcberwachung von Image-Registries:<\/strong> Werkzeuge aus der Watchtower-Familie pr\u00fcfen regelm\u00e4\u00dfig Image-Digests aktiver Container und starten Dienste automatisch neu, sobald aktuelle Builds bereitstehen. Das urspr\u00fcngliche Repository containrrr\/watchtower<\/code> wurde im Dezember 2025 archiviert, das \u00e4ltere Projekt Ouroboros wird nicht mehr entwickelt; gepflegte Community-Forks wie nickfedor\/watchtower<\/code> lassen sich als direkter Ersatz einsetzen.<\/li>\r\n
Lokale Build-Automatisierung:<\/strong> F\u00fcr eigene Python-Anwendungen oder Mikroservices k\u00f6nnen Build-Prozesse per Dockerfile direkt auf der ARM-Architektur ausgef\u00fchrt werden, um komplexe Cross-Compilation-Schritte zu vermeiden.<\/li>\r\n
Health Checks & automatische Wiederherstellung:<\/strong> Die Integration nativer Docker-Health-Checks stellt sicher, dass fehlerhafte Aktualisierungen umgehend identifiziert werden, ohne dass manuelle Log-Analysen erforderlich sind.<\/li>\r\n<\/ul>\r\n\r\n\r\n\r\n
4. Sicherheitsaspekte f\u00fcr lokale CI\/CD-Pipelines<\/h2>\r\n\r\n\r\n\r\n
Die Bereitstellung automatisierter Endpunkte im lokalen Netzwerk erfordert eine strikte Rechteentflechtung. Webhook-Dienste sollten niemals mit Root-Berechtigungen ausgef\u00fchrt werden; stattdessen ist der Zugriff auf den Docker-Socket \u00fcber dedizierte Gruppenrechte oder schreibgesch\u00fctzte Socket-Proxys zu reglementieren. Zudem sch\u00fctzt ein restriktives Management-VLAN die Automatisierungs-Dienste vor unautorisierten Zugriffen aus anderen Subnetzen.<\/p>\r\n\n\n
![\"Senkrechte](\"https:\/\/www.lukaswojcik.com\/blog\/wp-content\/uploads\/diagrams\/raspberry-pi-lokale-cicd-pipeline-de.png\")
\n