{"id":8703,"date":"2026-08-14T18:44:00","date_gmt":"2026-08-14T16:44:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=8703"},"modified":"2026-08-13T14:29:52","modified_gmt":"2026-08-13T12:29:52","slug":"zautomatyzowane-wdrozenia-docker-raspberry-pi-local-first-8703","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/pl\/raspberry-pi-pl\/zautomatyzowane-wdrozenia-docker-raspberry-pi-local-first-8703\/","title":{"rendered":"Zautomatyzowane wdro\u017cenia Docker na Raspberry Pi: \u015arodowiska deweloperskie Local-First"},"content":{"rendered":"\r\n

Utrzymanie w\u0142asnych us\u0142ug \u2014 takich jak Home Assistant, Node-RED czy lokalne \u015brodowiska \u015bledzenia analitycznego \u2014 na platformie Raspberry Pi w klasycznym modelu cz\u0119sto wymaga r\u0119cznych aktualizacji oprogramowania oraz dora\u017anych modyfikacji konfiguracji. Podej\u015bcie to poch\u0142ania znaczny czas administracyjny i generuje ryzyko operacyjne, w tym rozbie\u017cno\u015bci konfiguracyjne (configuration drift), konflikty zale\u017cno\u015bci oraz nieoczekiwane przestoje.<\/p>\r\n\r\n\r\n\r\n

W celu stworzenia niezawodnej, deterministycznej infrastruktury lokalnej warstwa us\u0142ug musi zosta\u0107 \u015bci\u015ble odseparowana od systemu operacyjnego hosta. Pe\u0142na konteneryzacja \u015brodowiska Smart Home oraz narz\u0119dzi analitycznych za pomoc\u0105 Docker Compose<\/strong> w po\u0142\u0105czeniu ze zautomatyzowanymi potokami wdro\u017ceniowymi \u2014 przy u\u017cyciu lokalnego mechanizmu Watchtower<\/strong> lub struktur CI\/CD w GitHub Actions<\/strong> \u2014 gwarantuje w pe\u0142ni powtarzalne \u015brodowiska brzegowe o zerowym czasie niedost\u0119pno\u015bci.<\/p>\r\n\r\n\r\n\r\n

1. Konteneryzacja \u015brodowiska brzegowego za pomoc\u0105 Docker Compose<\/h2>\r\n\r\n\r\n\r\n

Docker Compose stanowi deklaratywn\u0105 podstaw\u0119 nowoczesnych architektur Local-First. Zdefiniowanie wszystkich us\u0142ug, wolumen\u00f3w trwa\u0142ych oraz wirtualnych mostk\u00f3w sieciowych w jednym pliku konfiguracyjnym obj\u0119tym kontrol\u0105 wersji zapewnia ca\u0142kowit\u0105 powtarzalno\u015b\u0107 stanu infrastruktury.<\/p>\r\n\r\n\r\n\r\n

# docker-compose.yml: Zintegrowany stos Smart Home i analityki lokalnej\r\nservices:\r\n  homeassistant:\r\n    container_name: homeassistant\r\n    image: ghcr.io\/home-assistant\/home-assistant:stable\r\n    volumes:\r\n      - \/opt\/homeassistant\/config:\/config\r\n      - \/etc\/localtime:\/etc\/localtime:ro\r\n    restart: unless-stopped\r\n    network_mode: host\r\n\r\n  nodered:\r\n    container_name: nodered\r\n    image: nodered\/node-red:latest\r\n    environment:\r\n      - TZ=Europe\/Warsaw\r\n    volumes:\r\n      - \/opt\/nodered\/data:\/data\r\n    ports:\r\n      - \"1880:1880\"\r\n    restart: unless-stopped\r\n\r\n  watchtower:\r\n    container_name: watchtower\r\n    image: containrrr\/watchtower:latest\r\n    volumes:\r\n      - \/var\/run\/docker.sock:\/var\/run\/docker.sock\r\n    environment:\r\n      - WATCHTOWER_CLEANUP=true\r\n      - WATCHTOWER_SCHEDULE=0 0 4 * * *\r\n    restart: unless-stopped<\/code><\/pre>\r\n\r\n\r\n\r\n
Uwaga dotycz\u0105ca stanu utrzymania: pierwotny projekt containrrr\/watchtower<\/code> zosta\u0142 zarchiwizowany 17 grudnia 2025 roku i od tego czasu pozostaje w trybie tylko do odczytu, przez co obraz nie otrzymuje kolejnych aktualizacji ani poprawek bezpiecze\u0144stwa. Pierwotni opiekunowie nie wskazali oficjalnego nast\u0119pcy. Dalszy rozw\u00f3j odbywa si\u0119 w forkach spo\u0142eczno\u015bciowych \u2014 nickfedor\/watchtower<\/code> (publikowany r\u00f3wnie\u017c jako ghcr.io\/nicholas-fedor\/watchtower<\/code>) zachowuje zgodno\u015b\u0107 konfiguracyjn\u0105 i nadal ukazuje si\u0119 w regularnych wydaniach. Przed zastosowaniem produkcyjnym warto zatem zweryfikowa\u0107 \u015bcie\u017ck\u0119 aktualizacji tej us\u0142ugi.<\/p>\r\n\r\n\r\n\r\n
W przedstawionej architekturze katalogi z danymi trwa\u0142ymi znajduj\u0105 si\u0119 na zewn\u0119trznej, bezpiecznej przestrzeni dyskowej (np. udziale NAS lub dysku SSD), dzi\u0119ki czemu aktualizacje kontener\u00f3w nigdy nie nadpisuj\u0105 krytycznych konfiguracji ani zebranych danych historycznych.<\/p>\r\n\r\n\r\n\r\n
\n\"Diagram\n
3 element\u00f3w artyku\u0142u w skr\u00f3cie: Konteneryzacja \u015brodowiska brzegowego za pomoc\u0105\u2026, Automatyzacja utrzymania: Watchtower a potoki CI\/CD, Implementacja potoku wdro\u017ceniowego w GitHub Actions.<\/figcaption>\n<\/figure>\n\n
2. Automatyzacja utrzymania: Watchtower a potoki CI\/CD<\/h2>\r\n\r\n\r\n\r\n
Automatyzacja proces\u00f3w wdro\u017ceniowych oraz zarz\u0105dzania cyklem \u017cycia oprogramowania mo\u017ce by\u0107 realizowana w oparciu o dwa g\u0142\u00f3wne wzorce architektoniczne, w zale\u017cno\u015bci od z\u0142o\u017cono\u015bci systemu i wymaga\u0144 governance:<\/p>\r\n\r\n\r\n\r\n
Wzorzec wdro\u017ceniowy<\/th>Mechanizm wykonawczy<\/th>Optymalne zastosowanie<\/th>Kluczowa zaleta<\/th><\/tr><\/thead>
Automatyzacja lokalna (Watchtower)<\/strong><\/td>Us\u0142uga w tle codziennie weryfikuje rejestry obraz\u00f3w i automatycznie restartuje zaktualizowane kontenery.<\/td>Standardowe, gotowe obrazy (Home Assistant, Node-RED, Eclipse Mosquitto).<\/td>Brak konieczno\u015bci utrzymywania infrastruktury zewn\u0119trznej; w pe\u0142ni autonomiczna praca.<\/td><\/tr>
GitOps \/ CI\/CD (GitHub Actions)<\/strong><\/td>Zmiany w kodzie inicjuj\u0105 zdalne potoki wdro\u017ceniowe, kt\u00f3re \u0142\u0105cz\u0105 si\u0119 przez SSH z Raspberry Pi.<\/td>W\u0142asne aplikacje, dedykowane narz\u0119dzia analityczne lub infrastruktury rozproszone.<\/td>Pe\u0142na kontrola wersji, automatyczne testy przed wdro\u017ceniem i szybkie wycofywanie zmian.<\/td><\/tr><\/tbody><\/table><\/figure>\r\n\r\n\r\n\r\n
3. Implementacja potoku wdro\u017ceniowego w GitHub Actions<\/h2>\r\n\r\n\r\n\r\n
W przypadku autorskich aplikacji brzegowych lub strukturalnych repozytori\u00f3w Infrastructure-as-Code (IaC), wdro\u017cenie przy u\u017cyciu GitHub Actions zapewnia pe\u0142n\u0105 histori\u0119 audytow\u0105 ka\u017cdej zmiany konfiguracyjnej. Po opublikowaniu zmian w ga\u0142\u0119zi g\u0142\u00f3wnej, zautomatyzowany przep\u0142yw pracy \u0142\u0105czy si\u0119 bezpiecznie przez SSH z Raspberry Pi, pobiera aktualizacje i przebudowuje stos kontener\u00f3w.<\/p>\r\n\r\n\r\n\r\n
# .github\/workflows\/deploy-edge.yml\r\nname: Deploy Stack to Raspberry Pi\r\n\r\non:\r\n  push:\r\n    branches:\r\n      - main\r\n\r\njobs:\r\n  deploy:\r\n    runs-on: ubuntu-latest\r\n    steps:\r\n      - name: Execute Remote Deployment via SSH\r\n        uses: appleboy\/ssh-action@v1.0.0\r\n        with:\r\n          host: ${{ secrets.RPI_HOST }}\r\n          username: ${{ secrets.RPI_USER }}\r\n          key: ${{ secrets.RPI_SSH_KEY }}\r\n          script: |\r\n            cd \/opt\/edge-stack\r\n            git pull origin main\r\n            docker compose pull\r\n            docker compose up -d --remove-orphans\r\n            docker system prune -f<\/code><\/pre>\r\n\r\n\r\n\r\n
Podsumowanie<\/h2>\r\n\r\n\r\n\r\n
Przekszta\u0142cenie Raspberry Pi z r\u0119cznie konfigurowanego komputera jednop\u0142ytkowego w zautomatyzowany, skonteneryzowany serwer brzegowy redukuje narzut administracyjny do minimum. Zar\u00f3wno autonomiczne aktualizacje realizowane przez Watchtower, jak i deterministyczne wdro\u017cenia GitOps w GitHub Actions gwarantuj\u0105 stabilne, bezpieczne i niewymagaj\u0105ce sta\u0142ego nadzoru \u015brodowisko operacyjne dla system\u00f3w Smart Home oraz infrastruktury analitycznej.<\/p>\r\n\n\n
\n
\u0179r\u00f3d\u0142a<\/h2>\n