Zugriff auf Raspberry Pi GPIO-Pins in einem Docker-Container

Cover Image for Zugriff auf Raspberry Pi GPIO-Pins in einem Docker-Container

Offenlegung: Dieser Beitrag kann Affiliate-Links enthalten. Wenn du über diese Links einen Kauf tätigst, erhalte ich unter Umständen eine kleine Provision, ohne dass für dich zusätzliche Kosten entstehen.

Wenn du ein Homelab aufbaust oder dein Heimnetzwerk automatisierst, wirst du früher oder später leichtgewichtige Dienste auf einem Raspberry Pi 4 mit Docker laufen lassen wollen. Docker ist fantastisch, um Abhängigkeiten isoliert zu halten. Aber diese Isolation wird zur Hürde, wenn deine containerisierte App mit physischer Hardware interagieren muss – wie den GPIO-Pins (General Purpose Input/Output) des Pi.

Standardmäßig haben Docker-Container keinen Zugriff auf die Hardware der Host-Maschine. Wenn du versuchst, ein Skript in einem Container auszuführen, das einen GPIO-Pin schaltet, wird es wahrscheinlich mit einer Fehlermeldung wie „Permission Denied“ oder „Device Not Found“ abstürzen.

Hier erfährst du, wie du das richtig löst, ohne die Sicherheit deines Systems zu gefährden.

Die Lösung: Mapping von /dev/gpiomem

Viele Tutorials im Netz raten dazu, den Docker-Container im --privileged-Modus zu starten, um Hardware-Zugriffsprobleme zu lösen. Vermeide das, wenn möglich. Der Privileged-Modus heb die Sicherheitsisolation von Docker fast vollständig auf und gibt dem Container Root-Zugriff auf dein gesamtes Host-System.

Stattdessen ist die sichere und elegante Lösung, explizit nur das GPIO-Speicherinterface an den Container zu übergeben. Linux behandelt Hardware wie Dateien, und auf einem Raspberry Pi befindet sich der GPIO-Speicher unter /dev/gpiomem.

Mit Docker Compose

Wenn du deine Deployments mit docker-compose.yml verwaltest (was für Homelab-Setups absolut empfehlenswert ist), kannst du die devices-Anweisung nutzen, um das GPIO-Interface vom Host in den Container zu mappen.

Füge dies zu deiner Service-Konfiguration hinzu:

version: '3.8'
services:
  my-gpio-app:
    image: my-node-red-or-python-app:latest
    restart: unless-stopped
    # Das ist die magische Zeile, die die GPIO-Hardware an den Container übergibt
    devices:
      - /dev/gpiomem:/dev/gpiomem

Mit der Docker CLI

Falls du deine Container lieber manuell über die Kommandozeile startest, erreichst du mit dem --device-Flag genau dasselbe Ergebnis:

docker run -d \
  --name my-gpio-app \
  --device /dev/gpiomem:/dev/gpiomem \
  my-app:latest

Warum /dev/gpiomem und nicht /dev/mem?

In älteren Versionen des Raspberry Pi OS mussten Entwickler oft /dev/mem mappen, um auf GPIO zuzugreifen. Das Problem dabei: /dev/mem gewährt Zugriff auf den gesamten physischen Speicher des Geräts. Das bedeutet, dass dein Container mit Root-Rechten laufen müsste, was ein erhebliches Sicherheitsrisiko darstellt.

/dev/gpiomem wurde als sicherere Alternative eingeführt. Es beschränkt den Zugriff rein auf die GPIO-Register. Dadurch können deine Scripte sicher als Nicht-Root-Benutzer laufen und trotzdem LEDs blinken lassen, Sensordaten auslesen oder Relais steuern.

Fazit

Durch das Mapping von /dev/gpiomem hältst du deine Docker-Container sicher, folgst dem Prinzip der minimalen Rechtevergabe (Least Privilege) und schlägst erfolgreich die Brücke zwischen Software-Containern und physischer Hardware. Viel Spaß beim Basteln!

Nächste Artikel.

Cover Image for Internal TryHackMe Write-Up

Internal TryHackMe Write-Up

The Internal room on TryHackMe is an hard challenge that let's you slip in the role of a penetration tester, where your objective is to perform a thorough penetration test

Cover Image for Bau des Ploopy Adept BLE (Any Ball Mod)

Bau des Ploopy Adept BLE (Any Ball Mod)

Ein umfassender Guide zum Bau eines kabellosen Ploopy Adept Trackballs mit dem Any Ball Mod, der PCB-Bestellung und der Montage der Komponenten.