BartoszMazurczak.pl

DIC: kontrolowane aktualizacje obrazów Docker Compose

·

#
DIC dashboard in dark mode showing Docker Compose services and image update status

ŹRÓDŁO: https://repo.noop.re/drops/dic

Jeśli używasz Docker Compose dłużej niż tydzień, znasz ten moment: obrazy się starzeją, CVE cały czas dochodzą, upstream regularnie wypuszcza nowe wersje, a ty nie chcesz ręcznie odpalać docker compose pull && docker compose up -d dla wszystkiego.

Pełna automatyzacja też potrafi zaboleć, szczególnie gdy aktualizacja się wywróci i dostajesz niespodziankę w środku nocy.

Właśnie tutaj pasuje DIC (Docker Image Control): lokalna usługa do monitorowania obrazów Compose, z powiadomieniami, ręczną kontrolą i opcjonalną automatyczną aktualizacją wybranych usług.

Panel DIC w trybie ciemnym pokazujący usługi Docker Compose i status aktualizacji obrazów
Panel DIC (tryb ciemny)

Co właściwie robi DIC

DIC działa jako lekka usługa podłączona do docker.sock. Skanuje usługi Compose, sprawdza, czy dla danego taga jest dostępny nowszy obraz, i zapisuje aktualny stan.

To brzmi standardowo. Różnica zaczyna się przy tym, co możesz zrobić dalej:

  • włączyć lub wyłączyć monitorowanie dla każdej usługi przez label (dic.enable)
  • zdecydować o automatycznej aktualizacji dla każdej usługi (dic.autoupdate)
  • sterować powiadomieniami dla każdej usługi (dic.notify)
  • użyć panelu webowego i API do ręcznych akcji (refresh, update)
  • trzymać historię zdarzeń i aktualizacji w SQLite
  • wystawiać metryki Prometheus do monitoringu operacyjnego

Daje to praktyczny balans: automatyzacja tam, gdzie jej chcesz, i kontrola tam, gdzie jest potrzebna.

Dlaczego nie po prostu Watchtower albo DIUN?

Watchtower i DIUN to bardzo dobre narzędzia, ale rozwiązują trochę inne problemy. W skrócie: DIC jest bardziej operatorski dla środowisk Compose.

DIC vs Watchtower

Watchtower to przede wszystkim automatyczny aktualizator kontenerów. To ma sens, jeśli chcesz utrzymywać wszystko świeże przy minimalnym udziale człowieka.

DIC idzie bardziej w stronę codziennej obsługi:

  • DIC: panel + API z akcjami dla pojedynczych usług (/api/services/:id/refresh, /api/services/:id/update)
  • Watchtower: HTTP API to głównie globalny trigger aktualizacji (/v1/update)
  • DIC: polityki dla pojedynczych usług przez dedykowane labele (dic.enable, dic.autoupdate, dic.notify)
  • DIC: jawny flow rollbacku i zdarzenia rollbacku

Jeśli twoim celem nie jest tylko „zaktualizuj”, ale „zaktualizuj z kontrolą”, DIC daje więcej narzędzi operacyjnych.

DIC vs DIUN

DIUN świetnie sprawdza się jako notifier aktualizacji obrazów. Ma szerokie wsparcie providerów (Docker, Kubernetes, Swarm, Nomad i inne) oraz wiele kanałów powiadomień.

DIC jest bardziej wyspecjalizowany:

  • skupia się na Docker Compose
  • łączy wykrywanie zmian i akcje aktualizacji w jednym miejscu
  • daje operacyjny UI/API, a nie tylko powiadomienia
  • przechowuje historię i stan lokalnie (SQLite), z metrykami Prometheus

W skrócie: DIUN jest świetnym radarem, a DIC bardziej przypomina konsolę operatora dla Compose.

Najważniejsze różnice (TL;DR)

Obszar DIC Watchtower DIUN
Główna rola Monitoring + kontrolowane aktualizacje Compose Automatyczne aktualizacje kontenerów Powiadomienia o zmianach obrazów
UI Tak (panel webowy) Nie (CLI/logi + API) Nie (konfiguracja + powiadomienia)
API akcji dla pojedynczych usług Tak Głównie globalny trigger aktualizacji Nie w tym modelu
Polityka dla pojedynczych usług Tak (labele dic.*) Wybór kontenerów + opcje runtime Zaawansowany model watch/config
Rollback Jawny, wbudowany w logikę aktualizacji Zależy od scenariusza Nie dotyczy (notifier)
Trwała lokalna historia Tak (SQLite) Głównie logi Własny model DB/konfiguracji
Zakres platform Compose-first Docker-first Multi-provider (Docker/K8s/Swarm/Nomad/…)

Jak działają aktualizacje w DIC i dlaczego to ma znaczenie

Najbardziej praktyczna część: DIC aktualizuje ostrożnie.

  1. pobiera nowy obraz
  2. zatrzymuje stary kontener (jeśli działa)
  3. zmienia nazwę starego kontenera na backup
  4. tworzy i uruchamia nowy kontener z odtworzoną konfiguracją
  5. sprawdza, czy kontener działa albo jest healthy
  6. usuwa kontener backupowy

Jeśli coś pójdzie źle po drodze, DIC uruchamia rollback i zapisuje zdarzenie. Brzmi nudno, ale właśnie takie nudne mechanizmy ratują weekendy.

Dla kogo jest DIC

DIC ma sens, jeśli:

  • działasz głównie na Docker Compose
  • chcesz auto-update tylko dla wybranych usług
  • chcesz mieć szybkie ręczne obejście przez UI albo API
  • zależy ci na lokalnej historii i metrykach

Jeśli musisz monitorować jednocześnie Docker + Kubernetes + Swarm + Nomad, DIUN naturalnie ma szerszy zakres. Jeśli wystarcza ci prosty model „automatycznie aktualizuj i zapomnij”, Watchtower może być wystarczający.

Szybki start

wget https://repo.noop.re/drops/dic/raw/branch/main/docker-compose.yml
wget -O .env https://repo.noop.re/drops/dic/raw/branch/main/.env.example
docker compose pull
docker compose up -d

Domyślnie panel działa pod http://localhost:8080, metryki pod http://localhost:8080/metrics, a readiness pod http://localhost:8080/readyz.

Najwięcej zyskasz, jeśli od początku jasno opiszesz usługi labelami:

  • dic.enable=false dla usług, których nie chcesz sprawdzać
  • dic.autoupdate=true tam, gdzie automatyczne aktualizacje są bezpieczne
  • dic.notify=false tam, gdzie chcesz mniej szumu w powiadomieniach

Podsumowanie

DIC nie próbuje być narzędziem do wszystkiego. Rozwiązuje konkretną rzeczywistość: codzienną obsługę Docker Compose, w której kontrola aktualizacji ma znaczenie.

Jeśli chcesz aktualizacji z kontrolą, a nie aktualizacji na zasadzie „może będzie dobrze”, DIC jest rozsądnym środkiem między czystym auto-updaterem a samym notifierem.

Autor

Bartek