Raspberry Pi Docker: Einfache Container-Anleitung

Der SSH-Login klappt, docker compose up -d läuft durch, alles grün. Und dann antwortet der Container nicht. Kein Fehler, kein Log, nichts. Ich habe an dem Abend zwei Stunden an einem Problem gesessen, das hinterher drei Zeilen in einer Datei war: Die Image war nur für arm64 gebaut, mein Pi lief noch mit dem 32-Bit-System. exec format error – so nennen sie es. So sieht der typische Einstieg in das Thema Raspberry Pi Docker aus. Und genau dieser Moment fehlt in den meisten Anleitungen, die Sie finden werden.

Denn die allermeisten Tutorials hören auf, wenn Docker installiert ist. Der Teil danach – warum Ihre SSD nach acht Monaten stirbt, warum Portainer nicht im Internet hängen sollte und warum der Pi 5 plötzlich ein ganz anderes Gerät ist als der Pi 4 – der kommt selten vor. Das hole ich hier nach.

Wichtige Erkenntnisse

Das 64-Bit-Betriebssystem ist für Docker auf dem Raspberry Pi praktisch Pflicht – armhf-Images verschwinden zunehmend.
Der Installer von get.docker.com funktioniert einwandfrei, prüft aber nicht, ob Ihre Architektur zu den Images passt, die Sie später ziehen.
Eine SD-Karte ist kein Speicher für Container-Daten. Verschieben Sie /var/lib/docker auf USB oder SSD.
Portainer ist bequem, aber ein Root-Zugang zu Ihrem Host über eine Weboberfläche – behandeln Sie es entsprechend.
Der Sprung von Pi 4 auf Pi 5 ist beim Thema Container größer, als die Zahlen vermuten lassen.

Docker auf Raspberry Pi installieren: was wirklich zählt

Der Befehl ist bekannt und er ist gut:

curl -fsSL https://get.docker.com | sh

Das Skript erkennt Ihre Architektur, legt das offizielle Docker-Repository an und installiert Engine plus Compose-Plugin. Fertig. Was danach kommt, ist der interessante Teil.

32-Bit oder 64-Bit – und warum das keine Detailfrage ist

Raspberry Pi OS gibt es in einer 32-Bit-Variante (armhf) und einer 64-Bit-Variante (arm64). Auf einem Pi 4 oder Pi 5 mit ausreichend RAM gibt es heute kaum einen Grund, noch 32-Bit zu fahren. Trotzdem laufen erstaunlich viele Kisten so – weil die Karte schon beschrieben war, weil es damals einfacher war, weil man nicht neu aufsetzen wollte.

Für Docker ist das ein Problem mit Anlauf. Viele beliebte Images existieren schlicht nur noch als arm64-Build. Ziehen Sie ein solches Image auf ein armhf-System, kommt kein Hinweis auf die Architektur, sondern ein exec format error. Ehrlich gesagt habe ich beim ersten Mal ewig in den Container-Logs gesucht, bis mir jemand den naheliegenden Befehl nannte:

uname -m

Steht dort aarch64, sind Sie auf arm64. Steht dort armv7l, laufen Sie 32-Bit – und werden früher oder später auf dieses Problem stoßen. Prüfen Sie es, bevor Sie zehn Stunden in ein Setup investieren, das Sie danach neu aufsetzen dürfen. Das ist keine Theorie: Ich habe ein Wochenende verloren, weil ich die Karte aus Bequemlichkeit nicht neu geflasht habe.

Nach der Installation: drei Handgriffe, die niemand macht

Docker läuft ab Werk als root. Wenn Sie es ohne sudo nutzen wollen, kommen Sie in die Gruppe docker:

sudo usermod -aG docker $USER – danach einmal ab- und wieder anmelden
sudo systemctl enable docker – damit nach einem Neustart alles von selbst startet
Log-Rotation einrichten, sonst wachsen die Container-Logs unbemerkt und füllen die Karte

Die Gruppe docker ist übrigens faktisch gleichwertig zu root. Wer dort drin ist, kann das ganze System übernehmen. Das ist bei einem Heimserver meistens vertretbar, bei einem Gerät mit offenem SSH-Port nicht.

Docker Compose auf dem Raspberry Pi: die Datei, die alles trägt

Compose ist für mich der eigentliche Grund, warum Docker auf einem Pi überhaupt Spaß macht. Statt sich Befehle zu merken, beschreiben Sie in einer docker-compose.yml, was laufen soll. Nach einem Systemwechsel kopieren Sie eine Datei und sind in zwei Minuten wieder online.

Ein typischer Aufbau für einen kleinen Heimserver sieht so aus:

services:
  pihole:
    image: pihole/pihole:latest
    ports:
"53:53/tcp"
"80:80/tcp"
    environment:
      TZ: "Europe/Berlin"
    volumes:
      - ./etc-pihole:/etc/pihole
    restart: unless-stopped

Drei Dinge, die ich schmerzhaft lernen musste:

Immer restart: unless-stopped setzen. Sonst bleibt nach einem Stromausfall alles stehen, und Sie merken es erst, wenn das WLAN-DNS nicht mehr antwortet.
Volumes relativ halten (./ statt absolute Pfade), wenn Sie sie später auf ein anderes Gerät umziehen wollen.
Kein latest-Tag bei Diensten, die Sie nicht regelmäßig anschauen. Ein unbeabsichtigtes Update hat mir einmal die Datenbank-Konfiguration zerlegt.

Der Speicherort: warum Ihre SD-Karte das nicht lange mitmacht

Docker schreibt standardmäßig nach /var/lib/docker. Auf einer SD-Karte ist das ein Verschleißbeschleuniger: viele kleine Schreibvorgänge, Logs, Layer. Genau das, was Flash-Speicher auf Dauer übel nimmt.

Mein erster Pi – ein Pi 4 mit 4 GB – hat unter Dauerbetrieb mit Containern eine Marken-SD-Karte in etwa neun Monaten geschrottet. Danach habe ich eine USB-SSD drangehängt und den Docker-Datenordner verschoben. Seitdem: Ruhe. Der Pi 5 hat dafür sogar einen eigenen PCIe-Anschluss.

Wie verschiebe ich /var/lib/docker auf eine SSD?

Container und Images stoppen, dann in /etc/docker/daemon.json den neuen Pfad angeben:

{
  "data-root": "/mnt/ssd/docker"
}

Danach sudo systemctl restart docker. Existierende Container müssen vorher gestoppt sein, sonst zieht Docker sie nicht mit um.

Portainer auf dem Raspberry Pi: Fluch und Segen

Portainer ist eine Weboberfläche für Docker. Container starten, Logs lesen, Images löschen – alles per Klick statt per Terminal. Gerade am Anfang ist das angenehm, vor allem, wenn man von Synology oder einer anderen NAS-Oberfläche kommt.

Die Installation über Compose ist ein Vierzeiler:

services:
  portainer:
    image: portainer/portainer-ce:latest
    ports:
      - "9443:9443"
    volumes:
/var/run/docker.sock:/var/run/docker.sock
./portainer-data:/data
    restart: unless-stopped

Und jetzt der Teil, den ich Ihnen dringend mitgeben will: /var/run/docker.sock ist der Zugang zu Ihrer Docker-Engine. Wer diesen Socket kontrolliert, kontrolliert mit einem Trick auch den Host. Portainer gehört deshalb nicht ins offene Internet. Betreiben Sie es nur im lokalen Netz oder hängen Sie es hinter einen Reverse-Proxy mit Anmeldung. Das ist der Punkt, an dem ich in meinen eigenen Setups am längsten nachlässig war – ich hatte Portainer monatelang direkt aus dem WLAN erreichbar, ohne Passwort-Rotation.

Raspberry Pi 4 vs. Pi 5 für Docker: lohnt sich der Wechsel?

Hier wird es bei den meisten Anleitungen dünn. Ehrlich gesagt: Für einen kleinen Heimserver mit ein paar Containern reicht der Pi 4 mit 4 GB dicke. Der Pi 5 ist trotzdem ein spürbarer Sprung – aber nicht in allen Punkten gleich.

Kriterium	Raspberry Pi 4	Raspberry Pi 5
Speicher für Docker	USB oder SD	PCIe / HAT, deutlich schneller
RAM-Optionen	bis 8 GB	bis 8 GB, aber flotter angebunden
Kühlung	passiv meist ausreichend	aktive Kühlung praktisch Pflicht
Eignung für viele Container	gut bis mittel	gut
Empfehlung für Einsteiger	preislich attraktiv, reicht für den Start	sinnvoll, wenn ein NAS geplant ist

Ein Punkt, der oft untergeht: Ohne Kühlkörper und Lüfter drosselt der Pi 5 unter Last. Nicht dramatisch – die Container laufen weiter, nur langsamer. Wenn Sie aber zehn Dienste gleichzeitig betreiben, merken Sie es an der Reaktionszeit. Bei meinem Pi 5 hat der Tausch von einem kleinen Kühlkörper auf ein Gehäuse mit Lüfter die CPU-Temperatur unter Volllast um gut 20 Grad gesenkt. Das ist der Punkt, an dem aus Frust wieder Spaß wird.

Kann ich mit dem Raspberry Pi und Docker ein NAS bauen?

Ja, und das ist in meinen Augen der sinnvollste Einstieg überhaupt. Eine Kombination aus Samba-Container (Dateifreigaben), Nextcloud (Cloud-Speicher), Uptime Kuma (überwacht, ob Ihre Dienste noch antworten) und einem Backup-Container deckt die meisten Heim-Anforderungen ab. Der Pi 5 mit seinem PCIe-Anschluss macht das erstmals richtig attraktiv, weil die SSD nicht mehr über USB-Flaschenhals angebunden ist.

Was ich Ihnen aus eigener Erfahrung rate: Fangen Sie mit zwei Containern an, nicht mit sechs. Ich habe mir zu Beginn eine Sammlung aus Pi-hole, Home Assistant, einer Nextcloud, einem VPN und drei Spielereien gleichzeitig auf den Pi gelegt. Nicht einer dieser Dienste war sauber dokumentiert, und als eine Karte starb, wusste ich nicht mehr, wie ich irgendetwas davon aufgesetzt hatte. Heute habe ich eine einzige docker-compose.yml, eine .env mit Passwörtern und ein Git-Repository. Mehr braucht es nicht.

Was ich nach einiger Zeit anders machen würde

Drei Fehler, die ich gemacht habe und die vielleicht Ihnen Arbeit sparen:

Keine Backup-Strategie. Container sind wegwerfbar. Die Volumes sind es nicht. Ein Volume mit Datenbank drin ist nicht gesichert, nur weil das Image neu ziehbar ist.
Updates blind eingespielt. Ein docker compose pull ohne Changelog-Lesen hat mir einen Dienst gekillt, der seit Monaten lief.
Zu wenig auf Architektur geachtet. Der erste Frust hätte sich vermeiden lassen, wenn ich von Anfang an arm64 genutzt und mir eine Notiz angelegt hätte, welche Images nur dort existieren.

Und noch ein Gedanke, der erst mit der Zeit kam: Der Pi ist kein Server. Er ist ein Rechner, der auf Ihrer Fensterbank steht, über eine kleine Temperaturgrenze verfügt und bei Stromausfall nicht sauber herunterfährt. Das ist in Ordnung – solange Sie Ihre Erwartungen darauf ausrichten. Wer Ausfallsicherheit braucht, ist auf einem Pi falsch. Wer verstehen will, wie Container funktionieren, hat kaum etwas Besseres fürs Geld.

Was bei mir nach all dem hängen geblieben ist: Das Schwierige an Raspberry Pi Docker ist nicht die Installation. Das Skript dafür ist gut. Das Schwierige ist zu merken, dass man es am ersten Abend mit einem Betriebssystem, einer Architektur und einer Speicherkarte zu tun hat, die alle drei irgendwann zu einem Hindernis werden. Wenn Sie heute eine Sache mitnehmen, dann diese: uname -m eingeben. Es dauert zwei Sekunden und erspart Ihnen den einen Fehler, der mich am längsten aufgehalten hat.