{"id":13043,"date":"2026-09-16T12:45:00","date_gmt":"2026-09-16T10:45:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=13043"},"modified":"2026-09-09T13:22:38","modified_gmt":"2026-09-09T11:22:38","slug":"tutorial-eine-docker-compose-datei-fur-den-unbeaufsichtigten-betrieb-auf-dem-raspberry-pi-harten","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/de\/raspberry-pi-de\/tutorials-de-raspberry-pi-de\/tutorial-eine-docker-compose-datei-fur-den-unbeaufsichtigten-betrieb-auf-dem-raspberry-pi-harten\/","title":{"rendered":"Tutorial: Eine Docker-Compose-Datei f\u00fcr den unbeaufsichtigten Betrieb auf dem Raspberry Pi h\u00e4rten"},"content":{"rendered":"

Eine Compose-Datei, die einen Stapel startet, ist in zehn Minuten geschrieben. Eine Compose-Datei, die den Stapel ein Jahr am Laufen h\u00e4lt, braucht etwa sechs Zeilen mehr je Dienst – und jede dieser Zeilen existiert wegen einer bestimmten Art, auf die Dinge umfallen.<\/p>\n

Es folgt der Durchgang in der Reihenfolge, in der sie \u00fcblicherweise n\u00f6tig werden – was ungef\u00e4hr der Reihenfolge entspricht, in der eine sich selbst \u00fcberlassene Maschine darauf st\u00f6sst.<\/p>\n

\n\"F\u00fcnf
Keiner dieser f\u00fcnf F\u00e4lle braucht einen seltenen Umstand. Sie sind das, was neunzig Tage unbeaufsichtigter Betrieb von allein hervorbringt.<\/figcaption><\/figure>\n

Die Zeile, die \u00fcber die R\u00fcckkehr entscheidet<\/h2>\n

Ein Container, der stehen bleibt, bleibt stehen. Nach einem Stromausfall, nach einem Absturz, nach einem Neustart des Dienstes – solange keine Neustartregel etwas anderes sagt.<\/p>\n

services:\n  app:\n    restart: unless-stopped<\/code><\/pre>\n
Drei Werte lohnen sich auseinanderzuhalten. no<\/code> ist die Voreinstellung und heisst, dass nichts zur\u00fcckkommt. always<\/code> startet den Container in jedem Fall neu, auch nachdem er von Hand angehalten wurde und die Maschine danach neu startete – so erscheint ein absichtlich ausser Betrieb genommener Container um drei Uhr nachts wieder. unless-stopped<\/code> tut dasselbe ausser in genau diesem Fall und ist die richtige Voreinstellung f\u00fcr eine Maschine, die niemand beobachtet.<\/p>\n
Zwei Einzelheiten dahinter. Docker wartet zwischen Neustartversuchen zunehmend l\u00e4nger, von 100 Millisekunden verdoppelnd bis zu einer Minute – ein Container in einer Absturzschleife legt die Maschine also nicht lahm, h\u00f6rt aber auch nicht auf, und nichts weist darauf hin. Und die Neustartregel greift nur bei einem Container, der sich beendet. Ein Prozess, der h\u00e4ngt, w\u00e4hrend sein Container weiterl\u00e4uft, ist genau der Fall des n\u00e4chsten Abschnitts.<\/p>\n
Eine Gesundheitspr\u00fcfung, die etwas pr\u00fcft<\/h2>\n
Eine h\u00e4ngende Anwendung ist schlimmer als eine abgest\u00fcrzte, denn alles ringsum h\u00e4lt sie f\u00fcr funktionierend. Der Container l\u00e4uft, der Port ist offen, und die Anfragen laufen ins Leere.<\/p>\n
    healthcheck:\n      test: [\"CMD\", \"curl\", \"-fsS\", \"http:\/\/localhost:8080\/health\"]\n      interval: 30s\n      timeout: 5s\n      retries: 3\n      start_period: 60s<\/code><\/pre>\n
Die letzte Zeile fehlt am h\u00e4ufigsten und stiftet die meiste Verwirrung. W\u00e4hrend der start_period<\/code> z\u00e4hlt eine fehlgeschlagene Pr\u00fcfung nicht gegen retries<\/code>. Ohne sie wird ein Dienst, der vierzig Sekunden zum Hochkommen braucht, unterwegs f\u00fcr krank erkl\u00e4rt und neu gestartet – endlos.<\/p>\n
Was die Pr\u00fcfung pr\u00fcft, wiegt schwerer als dass es sie gibt. Eine Anfrage auf \/<\/code> belegt, dass der Webserver antwortet, und das tut er auch, w\u00e4hrend die Datenbankverbindung dahinter seit einer Stunde weg ist. Ein Endpunkt, der die ausfallgef\u00e4hrdeten Teile ber\u00fchrt, lohnt sich genau daf\u00fcr zu schreiben – und er sollte schnell antworten, denn er l\u00e4uft alle dreissig Sekunden, so lange die Maschine steht.<\/p>\n
Eine Gesundheitspr\u00fcfung erm\u00f6glicht ausserdem eine Aussage \u00fcber die Reihenfolge, die depends_on<\/code> allein nicht trifft. Ohne die Bedingung startet Compose die Abh\u00e4ngigkeit und macht sofort weiter; mit ihr wartet es.<\/p>\n
  app:\n    depends_on:\n      db:\n        condition: service_healthy<\/code><\/pre>\n
Eine Folge f\u00fcr schlanke Abbilder: curl<\/code> ist oft nicht enthalten, und eine Pr\u00fcfung, die sich nicht ausf\u00fchren l\u00e4sst, gilt als fehlgeschlagen. Entweder benutzt die Pr\u00fcfung etwas, das im Abbild vorhanden ist – wget -q --spider<\/code> oder einen Befehl der Anwendung selbst -, oder das Abbild bekommt ein Paket, das es sonst nicht br\u00e4uchte.<\/p>\n
Protokolle, die die Karte nicht f\u00fcllen<\/h2>\n
Der voreingestellte Protokolltreiber schreibt in eine JSON-Datei, die unbegrenzt w\u00e4chst. Auf einem Server mit grosser Platte ist das unordentlich; auf einem Pi mit Speicherkarte ist es ein Ausfallgrund, denn ein volles Dateisystem legt die ganze Maschine still statt nur des geschw\u00e4tzigen Containers.<\/p>\n
    logging:\n      driver: json-file\n      options:\n        max-size: \"10m\"\n        max-file: \"3\"<\/code><\/pre>\n
Dreissig Megabyte je Dienst sind f\u00fcr alles reichlich, was nicht gerade untersucht wird. Die Einstellung geh\u00f6rt an jeden Dienst und nicht nur an den geschw\u00e4tzigen, denn der geschw\u00e4tzige ist meist der Dienst, der irgendwann anf\u00e4ngt, jede Sekunde einen Fehlerbericht zu schreiben.<\/p>\n
Dieselbe Grenze l\u00e4sst sich einmal f\u00fcr die ganze Maschine in \/etc\/docker\/daemon.json<\/code> setzen, und das ist der bessere Ort daf\u00fcr – allerdings gilt sie nur f\u00fcr danach erzeugte Container, ein bestehender Stapel muss also neu angelegt werden, damit sie greift.<\/p>\n
{\n  \"log-driver\": \"json-file\",\n  \"log-opts\": { \"max-size\": \"10m\", \"max-file\": \"3\" }\n}<\/code><\/pre>\n
Wo nicht der Platz, sondern die Schreibvorg\u00e4nge das Problem sind, gewinnt eine Speicherkarte damit, die Protokolle ganz aus dem Dateisystem zu nehmen – driver: journald<\/code> reicht sie an systemd weiter, dem sich sagen l\u00e4sst, sie im Arbeitsspeicher zu halten.<\/p>\n
Speichergrenzen und die Pi-eigene Falle<\/h2>\n
Eine Maschine mit vier Gigabyte und ohne Auslagerung hat keinen Puffer f\u00fcr ein Leck. Welcher Prozess bei Speichermangel stirbt, entscheidet der Kern – und es ist regelm\u00e4ssig nicht der verursachende.<\/p>\n
    deploy:\n      resources:\n        limits:\n          memory: 512M\n          cpus: \"1.5\"<\/code><\/pre>\n
Eine Grenze macht aus einem Ausfall der ganzen Maschine einen Ausfall eines Containers: Der schuldige Container wird beendet und von seiner Neustartregel wieder gestartet, alles andere l\u00e4uft weiter. Das ist ein deutlich besserer Ausgang, und die Grenze lohnt sich auch dann, wenn die Zahl geraten ist – eine grossz\u00fcgige Grenze begrenzt den Schaden immer noch.<\/p>\n
Und nun der Teil, der den Raspberry Pi allein betrifft. Unter Raspberry Pi OS ist die Speicher-Steuergruppe voreingestellt abgeschaltet, und eine Speichergrenze in der Compose-Datei wird dann klaglos angenommen und bleibt wirkungslos. Eine Warnung erscheint einmal beim Start des Dienstes und danach nie wieder.<\/p>\n
# an die einzige Zeile in \/boot\/firmware\/cmdline.txt anhaengen, dann neu starten\ncgroup_enable=memory cgroup_memory=1\n\n# danach muss diese Zeile verschwunden sein:\ndocker info 2>&1 | grep -i \"no memory limit support\"<\/code><\/pre>\n
Die Datei enth\u00e4lt genau eine Zeile, und ein von einem Editor angeh\u00e4ngter Zeilenumbruch macht die Maschine unstartbar – der Zusatz geh\u00f6rt also an das Ende der bestehenden Zeile, durch ein Leerzeichen getrennt.<\/p>\n
Das Abbild festnageln, damit ein Neustart keine Aktualisierung ist<\/h2>\n
Ein Tag ist ein wandernder Zeiger. postgres:16<\/code> bedeutet in diesem Monat etwas anderes als im letzten, und den Zeitpunkt des Wechsels w\u00e4hlt niemand – er ist der Moment, in dem der Container zuf\u00e4llig neu angelegt wird.<\/p>\n
    image: postgres:16.4@sha256:f8cd4e0b9b0d15b6bbbcbbdf8c5f8c8b6c6b3e9b7cbb4f2d1e3a5c7d9f0b2a46<\/code><\/pre>\n
Ein Digest ist unver\u00e4nderlich, und damit wird aus \u201eContainer neu anlegen” ein Vorgang mit bekanntem Ergebnis. Der Tag bleibt davor stehen, als Dokumentation – der Digest allein ist unlesbar, und eine Datei voller Pr\u00fcfsummen sagt niemandem, was l\u00e4uft.<\/p>\n
Der Digest eines bereits benutzten Abbilds ist einen Befehl entfernt.<\/p>\n
docker image inspect postgres:16.4 --format '{{index .RepoDigests 0}}'<\/code><\/pre>\n
Eine Warnung zur Verbindung mit automatischen Aktualisierungen. Ein Werkzeug, das planm\u00e4ssig neue Abbilder holt, und ein fester Digest sind Gegens\u00e4tze – beides zusammen heisst, dass der Digest stillschweigend gewinnt, w\u00e4hrend das Aktualisierungswerkzeug Erfolg meldet. Entweder wandern die Versionen nach Plan, oder sie wandern, wenn jemand es entscheidet; beides ist vertretbar, eines davon versehentlich zu haben nicht.<\/p>\n
Zwei weitere Zeilen geh\u00f6ren in denselben Block und kosten nichts. Ein Container, der nie in sein eigenes Dateisystem schreibt, darf das sagen, und einem, der nicht Wurzel werden muss, l\u00e4sst sich mitteilen, dass er es nie wird.<\/p>\n
    read_only: true\n    tmpfs:\n      - \/tmp\n    security_opt:\n      - no-new-privileges:true\n    user: \"1000:1000\"<\/code><\/pre>\n
Die Datei pr\u00fcfen, bevor sie l\u00e4uft<\/h2>\n
Compose l\u00f6st Variablen auf, f\u00fchrt Erg\u00e4nzungsdateien zusammen und setzt Voreinstellungen ein – und das Ergebnis ist oft nicht das, was die Datei zu sagen scheint. Ein Befehl gibt aus, was tats\u00e4chlich gestartet wird.<\/p>\n
docker compose config<\/code><\/pre>\n
Drei Dinge lohnen sich in dieser Ausgabe zu suchen. Ein leerer Wert, wo eine Variable stehen sollte – eine nicht gesetzte Variable wird ohne Fehlermeldung zur leeren Zeichenkette, und ein fehlendes Passwort liest sich oft als kein Passwort. Ein Abbild ohne Digest. Und ein Dienst ohne restart<\/code>, ohne healthcheck<\/code> oder ohne logging<\/code>, wor\u00fcber das Auge in einer Datei mit acht Diensten leicht hinwegliest.<\/p>\n
Das Letzte l\u00e4sst sich maschinell pr\u00fcfen, und das lohnt sich, denn es ist genau die Art von Auslassung, die beim schnellen Hinzuf\u00fcgen eines Dienstes entsteht.<\/p>\n
docker compose config --format json | python3 -c '\nimport json, sys\nstack = json.load(sys.stdin)\nfor name, svc in stack[\"services\"].items():\n    fehlt = [f for f in (\"restart\", \"healthcheck\", \"logging\") if f not in svc]\n    if \"@sha256:\" not in svc.get(\"image\", \"\"):\n        fehlt.append(\"digest\")\n    print(f\"{name:20s} {\\\", \\\".join(fehlt) if fehlt else \\\"ok\\\"}\")\n'<\/code><\/pre>\n
Nach dem ersten Lauf geh\u00f6rt eine letzte Pr\u00fcfung zur Routine, und sie braucht kein Werkzeug: die Maschine absichtlich neu starten und ansehen, was zur\u00fcckkommt. Ein Stapel, der noch nie einen Neustart \u00fcberstanden hat, ist nicht gepr\u00fcft – und der Morgen nach einem Stromausfall ist nicht der Zeitpunkt, das herauszufinden.<\/p>\n
\n
Quellen<\/h2>\n