Ich habe es hunderte Male gesehen: Ein motivierter Bastler kauft sich einen Raspberry Pi, eine günstige SD-Karte vom Discounter und fängt an, nach einer Anleitung für How To Run Docker On Raspberry Pi zu suchen. Drei Wochen später raucht die SD-Karte ab, die Datenbank ist korrupt und das ganze Projekt landet in der Schublade, weil "der Pi zu schwach ist". Das ist kompletter Unsinn. Der Fehler liegt nicht am Gerät, sondern an der Ignoranz gegenüber der Hardware-Architektur. Wer glaubt, er könne einen Mini-Rechner wie einen ausgewachsenen Server behandeln, verbrennt buchstäblich Geld. Ich habe miterlebt, wie kleine Unternehmen versuchten, ihre gesamte Edge-Infrastruktur auf SD-Karten-Basis aufzubauen, nur um nach zwei Monaten im Chaos zu versinken, weil die Schreibzyklen der Container das Dateisystem zerfressen haben. Das kostet nicht nur die 20 Euro für eine neue Karte, sondern Tage an Arbeit für das Recovery und die Neukonfiguration.
Die Lüge von der SD-Karte als Systemlaufwerk
Der größte Fehler, den fast jeder Anfänger macht, ist das Vertrauen in die Micro-SD-Karte. Docker produziert ständig Logs, schreibt Metadaten und rotiert temporäre Dateien. Eine Standard-SD-Karte ist für sequenzielles Schreiben von Fotos in einer Kamera gebaut, nicht für die Millionen von kleinen Random-Write-Operationen eines Container-Daemons.
In meiner Praxis ist die Lösung simpel, wird aber oft aus falscher Sparsamkeit ignoriert: USB-Boot mit einer SSD. Wer heute noch Betriebssystem und Container-Volumes auf einer SD-Karte betreibt, plant den Ausfall fest ein. Ein USB-zu-NVMe-Adapter kostet etwa 15 Euro, eine kleine SSD weitere 20 Euro. Diese Investition spart Ihnen Wochen an Frust. Wenn Sie den Pi professionell oder auch nur für ein stabiles Smart Home nutzen wollen, werfen Sie die SD-Karte nach der ersten Einrichtung weg.
Ein weiterer Punkt ist die Wahl des Betriebssystems. Viele greifen blind zur 32-Bit-Version, weil sie "kompatibler" erscheint. Das ist veraltet. Moderne Container-Images setzen fast ausschließlich auf arm64. Wer auf 32-Bit bleibt, verbringt die Hälfte seiner Zeit damit, mühsam nach kompatiblen Images zu suchen oder sie selbst zu bauen, anstatt einfach das zu nutzen, was vorhanden ist. Installieren Sie das Raspberry Pi OS 64-Bit Lite. Alles andere ist Zeitverschwendung.
How To Run Docker On Raspberry Pi ohne Hitzetod
Ein Raspberry Pi 4 oder 5 unter Last wird heiß. Docker-Container, die vielleicht noch Java-Anwendungen oder Python-Skripte ausführen, treiben die CPU-Temperatur in Sekunden über 80 Grad Celsius. Sobald das passiert, taktet die CPU runter (Thermal Throttling). Ihr System wird unerträglich langsam, und Sie suchen den Fehler in der Docker-Konfiguration, obwohl die Hardware einfach nur nach Luft schnappt.
In meiner Erfahrung ist ein passives Gehäuse, das den gesamten Pi als Kühlkörper nutzt, die einzige vernünftige Wahl. Diese kleinen 40mm-Lüfter, die oft in Bundles verkauft werden, fangen nach drei Monaten an zu rattern und bewegen kaum Luft. Ein massives Aluminiumgehäuse hält die Temperatur auch unter Dauerlast bei etwa 50 bis 55 Grad. Das ist der Unterschied zwischen einem System, das stabil durchläuft, und einem, das bei jedem Backup-Job einfriert.
Der RAM-Fresser und die Swap-Falle
Viele Nutzer kaufen den Pi mit 2 GB oder 4 GB RAM und wundern sich, warum Docker-Compose-Stacks mit acht Containern das System in die Knie zwingen. Das Problem ist meistens nicht der RAM an sich, sondern wie Linux damit umgeht, wenn er voll wird. Standardmäßig nutzt das Raspberry Pi OS eine sehr kleine Swap-Datei auf – Sie ahnen es – der langsamen SD-Karte oder SSD.
Warum zram Ihre Rettung ist
Anstatt den langsamen Speicher als Erweiterung für den RAM zu nutzen, sollten Sie zram einsetzen. Dabei handelt es sich um einen komprimierten Bereich im Arbeitsspeicher selbst. Wenn der RAM voll wird, komprimiert der Kernel die Daten im Speicher, anstatt sie auf die Festplatte auszulagern. Das ist um Welten schneller und schont die Hardware. Ich habe Setups gesehen, die mit 4 GB RAM dank zram Lastspitzen abgefangen haben, die normalerweise ein 8-GB-Modell erfordert hätten.
Hier ist ein Punkt, den viele übersehen: Die Stromversorgung. Ein "Handyladegerät" reicht nicht aus. Docker-Container verursachen Lastspitzen. Wenn die CPU hochfärt und gleichzeitig die SSD Strom über USB zieht, bricht die Spannung ein. Der Pi zeigt das oft mit einem kleinen gelben Blitz-Symbol (oder in den Logs als Under-voltage detected) an. Das führt zu Dateisystemfehlern, die man fälschlicherweise Docker zuschreibt. Nutzen Sie das offizielle Netzteil. Es gibt hier keinen Platz für Experimente mit alten Kabeln.
Netzwerkkonfiguration und das Docker-Bridge-Dilemma
Ein Fehler, der oft erst spät bemerkt wird, ist die IP-Adress-Kollision. Docker nutzt intern oft das Subnetz 172.17.0.0/16. Wenn Ihr Heimnetzwerk oder Ihr VPN zufällig denselben Bereich nutzt, erreichen Sie Ihre Container nicht mehr, oder die Container können nicht mehr nach draußen telefonieren.
In meiner beruflichen Laufbahn war das einer der mühsamsten Fehler, die man im Nachhinein beheben muss. Es ist klüger, Docker von Anfang an anzuweisen, ein anderes Subnetz zu nutzen. Das macht man in der /etc/docker/daemon.json. Wer das ignoriert, baut sich eine technische Schuld auf, die bei der Erweiterung des Netzwerks garantiert zurückschlägt.
Ein weiterer Aspekt ist IPv6. Auf einem Raspberry Pi ist IPv6 oft standardmäßig aktiv, aber Docker hat eine historisch komplizierte Beziehung dazu. Wenn Sie nicht explizit IPv6 für Ihre Container benötigen, deaktivieren Sie es in Docker, um seltsame Timeouts beim Pulling von Images zu vermeiden. Es gibt kaum etwas Nervigeres als einen docker pull, der hängen bleibt, weil der Pi versucht, über ein nicht konfiguriertes IPv6-Routing zu laden.
Die Volume-Lüge und der Datenverlust
Wer Container startet, ohne sich Gedanken über Volumes zu machen, verliert Daten. Das ist Gesetz. Aber der Fehler geht tiefer. Viele nutzen Pfade wie /home/pi/mydata. Wenn Sie dann den Benutzer löschen oder das System neu aufsetzen wollen, sind die Daten im Zweifel weg oder die Berechtigungen stimmen nicht mehr.
Arbeiten Sie mit dedizierten Mount-Punkten unter /var/lib/docker_data oder ähnlichen Strukturen. Verlassen Sie sich niemals auf die interne Speicherverwaltung von Docker-Volumes, wenn Sie die Daten jemals sichern wollen. Ein strukturierter Ansatz bei den Pfaden spart Ihnen Stunden bei der Migration auf einen neuen Pi.
Ein Vorher-Nachher-Vergleich aus der Praxis
Stellen wir uns ein typisches Szenario vor: Ein Nutzer will ein Dashboard und eine Datenbank betreiben.
Der falsche Ansatz (Vorher): Der Nutzer flasht Raspberry Pi OS (32-Bit) auf eine 32 GB Class 10 SD-Karte. Er verbindet den Pi per WLAN und nutzt ein altes Smartphone-Netzteil. Er installiert Docker über ein zufälliges Skript aus dem Internet. Die Datenbank schreibt alle 5 Sekunden Logs auf die SD-Karte. Nach zwei Wochen wird das System extrem langsam. Jeder Klick im Dashboard dauert 10 Sekunden. Schließlich bootet der Pi nicht mehr, weil das Dateisystem der SD-Karte durch die ständigen Schreibvorgänge und plötzliche Spannungsabfälle korrupt ist. Die Daten sind verloren, da sie innerhalb des Containers gespeichert wurden.
Der richtige Ansatz (Nachher):
Der Nutzer greift zum Raspberry Pi OS (64-Bit) und installiert es auf einer 120 GB SSD via USB-3.0-Adapter. Er verbindet den Pi per Ethernet-Kabel für stabile Latenzen. Er verwendet das offizielle 15W/27W Netzteil. Docker wird über das offizielle Repository installiert, um Updates sicherzustellen. Die Datenbank-Daten liegen auf einem sauber gemounteten Verzeichnis auf der SSD. Mit zram konfiguriert er einen effizienten Arbeitsspeicher-Puffer. Das System läuft seit 18 Monaten ohne einen einzigen manuellen Eingriff, die Temperaturen bleiben dank Passiv-Kühlgehäuse unter 50 Grad, und Backups werden nachts automatisiert auf ein NAS geschoben.
Sicherheit ist kein optionales Extra
Wer Docker auf dem Pi betreibt, öffnet oft Ports. Der größte Fehler hier ist, Docker-Container mit Root-Rechten laufen zu lassen, obwohl das nicht nötig ist. Ja, Docker selbst braucht Root-Rechte, um das Netzwerk und den Storage zu verwalten, aber die Prozesse innerhalb des Containers sollten als User mit niedrigen Privilegien laufen.
Ein oft übersehenes Risiko ist die Docker-Socket-Datei /var/run/docker.sock. Wenn Sie Tools wie Portainer nutzen und ihnen vollen Zugriff auf diesen Socket geben, geben Sie dem Tool die volle Kontrolle über Ihr gesamtes System. Seien Sie vorsichtig mit Anleitungen, die Ihnen raten, Berechtigungen einfach auf 777 zu setzen, damit es "funktioniert". Das ist die digitale Entsprechung dazu, den Hausschlüssel unter die Fußmatte zu legen und ein Schild an die Tür zu hängen.
Nutzen Sie stattdessen Tools wie ufw (Uncomplicated Firewall), aber seien Sie gewarnt: Docker hebelt ufw standardmäßig aus, da es die iptables direkt manipuliert. Das bedeutet, dass ein Port, den Sie in Docker freigeben, im Internet offen sein kann, obwohl Ihre Firewall ihn eigentlich blockiert. Das ist ein extrem gefährlicher Fallstrick beim Thema How To Run Docker On Raspberry Pi. Sie müssen Docker explizit anweisen, die iptables nicht eigenmächtig zu verändern, oder die Bindings auf 127.0.0.1 beschränken.
Realitätscheck
Lassen Sie uns ehrlich sein: Ein Raspberry Pi ist ein fantastisches Werkzeug, aber er ist kein Wundergerät. Wenn Sie planen, schwere Enterprise-Anwendungen, komplexe Video-Transkodierung oder riesige Datenbanken darauf laufen zu lassen, werden Sie scheitern. Die ARM-Architektur hat ihre Grenzen, und der USB-Bus teilt sich die Bandbreite mit anderen Komponenten.
Erfolg mit Docker auf dem Pi bedeutet, die Hardware zu respektieren. Es bedeutet, zu akzeptieren, dass man etwa 50 bis 100 Euro in Zubehör (SSD, Gehäuse, Netzteil) investieren muss, bevor man überhaupt den ersten Container startet. Wer versucht, diese Kosten zu drücken, zahlt später mit seinen Nerven und seiner Zeit. Wenn Sie jedoch die Grundlagen – 64-Bit OS, SSD-Boot, vernünftige Kühlung und Stromversorgung – richtig umsetzen, ist der Pi eine der stabilsten und kosteneffizientesten Plattformen, die es gibt. Erwarten Sie keine "Klick-und-Fertig"-Lösung. Docker auf dem Pi erfordert ein Verständnis für Linux-Berechtigungen und Ressourcenmanagement. Wenn Sie dazu nicht bereit sind, ist ein gebrauchter Thin Client vielleicht die bessere Wahl für Sie. Wenn Sie es aber richtig machen, haben Sie ein System, das jahrelang ohne Murren seinen Dienst verrichtet.
