{"id":13045,"date":"2026-09-16T18:25:00","date_gmt":"2026-09-16T16:25:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=13045"},"modified":"2026-09-09T13:22:41","modified_gmt":"2026-09-09T11:22:41","slug":"tutorial-utwardzanie-pliku-docker-compose-do-pracy-bez-nadzoru-na-raspberry-pi","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/pl\/raspberry-pi-pl\/tutorials-pl-raspberry-pi-pl\/tutorial-utwardzanie-pliku-docker-compose-do-pracy-bez-nadzoru-na-raspberry-pi\/","title":{"rendered":"Tutorial: Utwardzanie pliku Docker Compose do pracy bez nadzoru na Raspberry Pi"},"content":{"rendered":"

Plik Compose uruchamiaj\u0105cy stos pisze si\u0119 w dziesi\u0119\u0107 minut. Plik Compose utrzymuj\u0105cy ten stos przy \u017cyciu przez rok potrzebuje oko\u0142o sze\u015bciu linii wi\u0119cej na us\u0142ug\u0119 – a ka\u017cda z tych linii istnieje z powodu okre\u015blonego sposobu, w jaki rzeczy si\u0119 przewracaj\u0105.<\/p>\n

Poni\u017cej przej\u015bcie po nich w kolejno\u015bci, w jakiej zwykle staj\u0105 si\u0119 potrzebne – co mniej wi\u0119cej odpowiada kolejno\u015bci, w jakiej natrafia na nie maszyna pozostawiona sama sobie.<\/p>\n

\n\"Pi\u0119\u0107
\u017baden z tych pi\u0119ciu przypadk\u00f3w nie wymaga rzadkiej okoliczno\u015bci. To wynik dziewi\u0119\u0107dziesi\u0119ciu dni pracy bez nadzoru.<\/figcaption><\/figure>\n

Linia rozstrzygaj\u0105ca o powrocie<\/h2>\n

Kontener, kt\u00f3ry si\u0119 zatrzyma\u0142, pozostaje zatrzymany. Po przerwie w zasilaniu, po awarii, po restarcie us\u0142ugi – dop\u00f3ki \u017cadna regu\u0142a restartu nie m\u00f3wi inaczej.<\/p>\n

services:\n  app:\n    restart: unless-stopped<\/code><\/pre>\n
Trzy warto\u015bci warto rozr\u00f3\u017cni\u0107. no<\/code> jest domy\u015blne i oznacza, \u017ce nic nie wraca. always<\/code> uruchamia kontener ponownie w ka\u017cdym przypadku, tak\u017ce po zatrzymaniu go r\u0119cznie i p\u00f3\u017aniejszym restarcie maszyny – i tak kontener celowo wy\u0142\u0105czony z u\u017cycia pojawia si\u0119 o trzeciej nad ranem. unless-stopped<\/code> robi to samo z wyj\u0105tkiem w\u0142a\u015bnie tego przypadku i jest w\u0142a\u015bciwym ustawieniem domy\u015blnym dla maszyny, kt\u00f3rej nikt nie obserwuje.<\/p>\n
Dwa szczeg\u00f3\u0142y stoj\u0105ce za tym. Docker odczekuje mi\u0119dzy pr\u00f3bami restartu coraz d\u0142u\u017cej, podwajaj\u0105c od 100 milisekund do minuty – kontener w p\u0119tli awarii nie k\u0142adzie wi\u0119c maszyny, ale te\u017c nie przestaje pr\u00f3bowa\u0107, a nic na to nie wskazuje. I regu\u0142a restartu dzia\u0142a wy\u0142\u0105cznie przy kontenerze, kt\u00f3ry si\u0119 ko\u0144czy. Proces zawieszony przy dzia\u0142aj\u0105cym kontenerze to dok\u0142adnie przypadek nast\u0119pnego rozdzia\u0142u.<\/p>\n
Badanie kondycji, kt\u00f3re co\u015b bada<\/h2>\n
Zawieszona aplikacja jest gorsza od takiej, kt\u00f3ra pad\u0142a, bo wszystko wok\u00f3\u0142 uwa\u017ca j\u0105 za dzia\u0142aj\u0105c\u0105. Kontener dzia\u0142a, port jest otwarty, a \u017c\u0105dania id\u0105 w pr\u00f3\u017cni\u0119.<\/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
Ostatniej linii brakuje najcz\u0119\u015bciej i to ona wywo\u0142uje najwi\u0119cej zamieszania. W czasie start_period<\/code> nieudane badanie nie liczy si\u0119 do retries<\/code>. Bez niej us\u0142uga potrzebuj\u0105ca czterdziestu sekund na wstanie zostaje po drodze uznana za chor\u0105 i zrestartowana – bez ko\u0144ca.<\/p>\n
To, co badanie bada, wa\u017cy wi\u0119cej ni\u017c samo jego istnienie. \u017b\u0105danie na \/<\/code> dowodzi, \u017ce serwer WWW odpowiada, a robi to r\u00f3wnie\u017c wtedy, gdy stoj\u0105ce za nim po\u0142\u0105czenie z baz\u0105 znikn\u0119\u0142o godzin\u0119 temu. Punkt ko\u0144cowy dotykaj\u0105cy cz\u0119\u015bci podatnych na awari\u0119 warto napisa\u0107 w\u0142a\u015bnie w tym celu – i powinien odpowiada\u0107 szybko, bo biegnie co trzydzie\u015bci sekund przez ca\u0142y czas pracy maszyny.<\/p>\n
Badanie kondycji umo\u017cliwia ponadto wypowied\u017a o kolejno\u015bci, kt\u00f3rej sam depends_on<\/code> nie stawia. Bez warunku Compose uruchamia zale\u017cno\u015b\u0107 i natychmiast idzie dalej; z warunkiem czeka.<\/p>\n
  app:\n    depends_on:\n      db:\n        condition: service_healthy<\/code><\/pre>\n
Skutek dla szczup\u0142ych obraz\u00f3w: curl<\/code> cz\u0119sto nie jest zawarty, a badanie, kt\u00f3rego nie da si\u0119 wykona\u0107, liczy si\u0119 jako nieudane. Albo badanie u\u017cywa czego\u015b, co w obrazie jest – wget -q --spider<\/code> albo polecenia samej aplikacji – albo obraz dostaje pakiet, kt\u00f3rego inaczej by nie potrzebowa\u0142.<\/p>\n
Dzienniki, kt\u00f3re nie zape\u0142ni\u0105 karty<\/h2>\n
Domy\u015blny sterownik dziennik\u00f3w pisze do pliku JSON rosn\u0105cego bez ogranicze\u0144. Na serwerze z du\u017cym dyskiem jest to nieporz\u0105dek; na Pi z kart\u0105 pami\u0119ci jest to przyczyna awarii, bo pe\u0142ny system plik\u00f3w k\u0142adzie ca\u0142\u0105 maszyn\u0119, a nie tylko gadatliwy kontener.<\/p>\n
    logging:\n      driver: json-file\n      options:\n        max-size: \"10m\"\n        max-file: \"3\"<\/code><\/pre>\n
Trzydzie\u015bci megabajt\u00f3w na us\u0142ug\u0119 wystarcza z zapasem dla wszystkiego, co nie jest w\u0142a\u015bnie badane. Ustawienie nale\u017cy do ka\u017cdej us\u0142ugi, a nie tylko do tej gadatliwej, bo gadatliw\u0105 bywa zwykle ta us\u0142uga, kt\u00f3ra kiedy\u015b zaczyna wypisywa\u0107 \u015blad b\u0142\u0119du co sekund\u0119.<\/p>\n
Ten sam limit da si\u0119 ustawi\u0107 raz dla ca\u0142ej maszyny w \/etc\/docker\/daemon.json<\/code>, i to lepsze dla niego miejsce – obowi\u0105zuje jednak tylko dla kontener\u00f3w utworzonych p\u00f3\u017aniej, istniej\u0105cy stos trzeba wi\u0119c utworzy\u0107 na nowo, aby zadzia\u0142a\u0142.<\/p>\n
{\n  \"log-driver\": \"json-file\",\n  \"log-opts\": { \"max-size\": \"10m\", \"max-file\": \"3\" }\n}<\/code><\/pre>\n
Tam, gdzie problemem jest nie miejsce, lecz same zapisy, karta pami\u0119ci zyskuje na wyprowadzeniu dziennik\u00f3w poza system plik\u00f3w – driver: journald<\/code> przekazuje je do systemd, kt\u00f3remu da si\u0119 kaza\u0107 trzyma\u0107 je w pami\u0119ci operacyjnej.<\/p>\n
Limity pami\u0119ci i pu\u0142apka w\u0142a\u015bciwa dla Pi<\/h2>\n
Maszyna z czterema gigabajtami i bez pliku wymiany nie ma zapasu na wyciek. To, kt\u00f3ry proces ginie przy braku pami\u0119ci, rozstrzyga j\u0105dro – i regularnie nie jest to proces winny.<\/p>\n
    deploy:\n      resources:\n        limits:\n          memory: 512M\n          cpus: \"1.5\"<\/code><\/pre>\n
Limit zamienia awari\u0119 ca\u0142ej maszyny w awari\u0119 jednego kontenera: winny kontener zostaje zako\u0144czony i uruchomiony ponownie przez w\u0142asn\u0105 regu\u0142\u0119 restartu, a reszta dzia\u0142a dalej. To wynik znacznie lepszy, a limit op\u0142aca si\u0119 tak\u017ce wtedy, gdy liczba jest zgadywana – hojny limit wci\u0105\u017c ogranicza szkod\u0119.<\/p>\n
A teraz cz\u0119\u015b\u0107 dotycz\u0105ca wy\u0142\u0105cznie Raspberry Pi. W Raspberry Pi OS grupa kontrolna pami\u0119ci jest domy\u015blnie wy\u0142\u0105czona, a limit pami\u0119ci w pliku Compose zostaje wtedy przyj\u0119ty bez skargi i pozostaje bez skutku. Ostrze\u017cenie pojawia si\u0119 raz przy starcie us\u0142ugi i nigdy wi\u0119cej.<\/p>\n
# dopisac do jedynej linii w \/boot\/firmware\/cmdline.txt, potem restart\ncgroup_enable=memory cgroup_memory=1\n\n# potem ta linia musi zniknac:\ndocker info 2>&1 | grep -i \"no memory limit support\"<\/code><\/pre>\n
Plik zawiera dok\u0142adnie jedn\u0105 lini\u0119, a znak ko\u0144ca linii dopisany przez edytor czyni maszyn\u0119 niezdoln\u0105 do startu – dopisek nale\u017cy wi\u0119c na koniec istniej\u0105cej linii, oddzielony spacj\u0105.<\/p>\n
Przypi\u0119cie obrazu, by restart nie by\u0142 aktualizacj\u0105<\/h2>\n
Tag jest w\u0119druj\u0105cym wska\u017anikiem. postgres:16<\/code> oznacza w tym miesi\u0105cu co innego ni\u017c w poprzednim, a chwili zmiany nikt nie wybiera – jest ni\u0105 moment, w kt\u00f3rym kontener przypadkiem powstaje na nowo.<\/p>\n
    image: postgres:16.4@sha256:f8cd4e0b9b0d15b6bbbcbbdf8c5f8c8b6c6b3e9b7cbb4f2d1e3a5c7d9f0b2a46<\/code><\/pre>\n
Digest jest niezmienny, przez co z \u201eponownego utworzenia kontenera” staje si\u0119 czynno\u015b\u0107 o znanym wyniku. Tag zostaje przed nim jako dokumentacja – sam digest jest nieczytelny, a plik pe\u0142en sum kontrolnych nikomu nie m\u00f3wi, co dzia\u0142a.<\/p>\n
Digest u\u017cywanego ju\u017c obrazu jest o jedno polecenie st\u0105d.<\/p>\n
docker image inspect postgres:16.4 --format '{{index .RepoDigests 0}}'<\/code><\/pre>\n
Ostrze\u017cenie co do po\u0142\u0105czenia z automatycznymi aktualizacjami. Narz\u0119dzie planowo pobieraj\u0105ce nowe obrazy i przypi\u0119ty digest to przeciwie\u0144stwa – jedno i drugie naraz oznacza, \u017ce digest po cichu wygrywa, podczas gdy narz\u0119dzie aktualizuj\u0105ce melduje sukces. Albo wersje w\u0119druj\u0105 wed\u0142ug planu, albo w\u0119druj\u0105, gdy kto\u015b tak postanowi; oba rozwi\u0105zania da si\u0119 obroni\u0107, posiadanie jednego z nich przez przypadek ju\u017c nie.<\/p>\n
Do tego samego bloku nale\u017c\u0105 jeszcze dwie linie i nic nie kosztuj\u0105. Kontener nigdy niepisz\u0105cy do w\u0142asnego systemu plik\u00f3w mo\u017ce to powiedzie\u0107, a temu, kt\u00f3ry nie musi stawa\u0107 si\u0119 u\u017cytkownikiem uprzywilejowanym, da si\u0119 oznajmi\u0107, \u017ce nigdy nim nie b\u0119dzie.<\/p>\n
    read_only: true\n    tmpfs:\n      - \/tmp\n    security_opt:\n      - no-new-privileges:true\n    user: \"1000:1000\"<\/code><\/pre>\n
Sprawdzenie pliku przed uruchomieniem<\/h2>\n
Compose rozwija zmienne, scala pliki uzupe\u0142niaj\u0105ce i wstawia warto\u015bci domy\u015blne – a wynik cz\u0119sto nie jest tym, co plik zdaje si\u0119 m\u00f3wi\u0107. Jedno polecenie wypisuje to, co faktycznie zostanie uruchomione.<\/p>\n
docker compose config<\/code><\/pre>\n
W tym wyniku warto szuka\u0107 trzech rzeczy. Pustej warto\u015bci tam, gdzie powinna sta\u0107 zmienna – nieustawiona zmienna staje si\u0119 bez komunikatu pustym ci\u0105giem znak\u00f3w, a brakuj\u0105ce has\u0142o czyta si\u0119 cz\u0119sto jako brak has\u0142a. Obrazu bez digestu. Oraz us\u0142ugi bez restart<\/code>, bez healthcheck<\/code> albo bez logging<\/code>, co oko w pliku z o\u015bmioma us\u0142ugami \u0142atwo przeoczy.<\/p>\n
To ostatnie da si\u0119 sprawdzi\u0107 maszynowo, i to si\u0119 op\u0142aca, bo jest to dok\u0142adnie ten rodzaj pomini\u0119cia, kt\u00f3ry powstaje przy szybkim dodaniu us\u0142ugi.<\/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
Po pierwszym przebiegu do rutyny nale\u017cy ostatnie sprawdzenie i nie potrzebuje \u017cadnego narz\u0119dzia: celowo zrestartowa\u0107 maszyn\u0119 i zobaczy\u0107, co wraca. Stos, kt\u00f3ry nigdy nie prze\u017cy\u0142 restartu, nie jest sprawdzony – a poranek po przerwie w zasilaniu nie jest por\u0105, by si\u0119 o tym dowiadywa\u0107.<\/p>\n
\n
\u0179r\u00f3d\u0142a<\/h2>\n