słownik automatyzacji

Docker

Docker to platforma konteneryzacji pozwalająca pakować aplikację razem ze wszystkimi jej zależnościami w izolowany, przenośny kontener. Kontener uruchamia się identycznie na każdej maszynie z zainstalowanym Dockerem, niezależnie od systemu operacyjnego hosta i wersji bibliotek systemowych.

Kontener to lżejsza alternatywa dla maszyny wirtualnej. VM emuluje całe hardware i uruchamia osobny system operacyjny. Kontener współdzieli jądro systemu z hostem, ale ma izolowany system plików, sieć i procesy. Efekt: uruchomienie kontenera zajmuje sekundy, a nie minuty, i zajmuje dużo mniej zasobów.

Docker Compose to narzędzie do zarządzania wieloma kontenerami jako jedną aplikacją. Jeden plik YAML opisuje wszystkie serwisy, ich powiązania, volumes i zmienne środowiskowe. docker compose up -d uruchamia cały stack. To standard dla wdrożeń self-hosted złożonych z kilku komponentów: n8n + Redis + Postgres + Caddy.

Docker jest punktem wyjścia dla każdego self-hosted wdrożenia w Workin'Flows. Nie dlatego, że to modne, ale dlatego, że rozwiązuje realny problem: ta sama konfiguracja działa identycznie na VM testowej i produkcyjnej, aktualizacja oznacza podmianę obrazu, a nie konfigurowanie systemu ręcznie.

W praktyce

Stack n8n na GCP VM zarządzany przez Docker Compose ma cztery serwisy: n8n (main process + worker), Redis (kolejka BullMQ), PgBouncer (connection pooler przed Cloud SQL) i Caddy (reverse proxy, TLS). Każdy ma swój volume na dane, każdy ma zdefiniowane limity zasobów (CPU, RAM), każdy ma healthcheck. Przy awarii jednego serwisu Compose restartuje tylko ten jeden, nie cały stack. Upgrade n8n to podmiana tagu obrazu i docker compose pull && docker compose up -d.

Jedna reguła, którą egzekwuję bez wyjątku: nigdy nie bind-mount pojedynczego pliku do kontenera. Docker trzyma referencję do inode, a po atomicznej edycji pliku z zewnątrz (np. przez edytor) inode się zmienia, a kontener widzi stary plik. Zawsze bind-mountuję katalog.

Powiązane

← Wróć do słownika