Generator Docker Compose produkcyjny

Generator Docker Compose produkcyjny: bezpieczna baza stosu

Generator produkcyjnego Docker Compose składa plik compose.yaml dla aplikacji, PostgreSQL, Redis i Nginx, a przy zaznaczonym Nginx także pasujący nginx.conf. Wynik używa wersjonowanych obrazów, trwałych wolumenów, prywatnej sieci, healthchecków, rotacji logów oraz zależności czekających na gotowość bazy i cache. Hasło nie trafia do YAML: plik wymaga ustawienia wskazanej zmiennej środowiskowej. Oba pliki skopiujesz albo pobierzesz jednym przyciskiem.

Co znajduje się w wygenerowanym stosie

Generator nie dodaje przestarzałego klucza version; współczesny Docker Compose korzysta z Compose Specification. Pole name nadaje projektowi stabilną nazwę, więc kontenery, sieć i wolumeny nie zmieniają prefiksu zależnie od nazwy katalogu. Nazwa może mieć do 63 znaków: małe litery, cyfry, „-” i „_”.

Przyciski „Laravel” i „Node” ustawiają komplet czterech usług oraz port aplikacji (9000 albo 3000), a „Minimalny” zostawia samą aplikację. Preset nie podmienia obrazu aplikacji, więc wpisany adres z rejestru zostaje.

Wersje obrazów zamiast latest

Tag latest nie mówi, jaki kod uruchomi się po następnym pobraniu obrazu. Dlatego formularz wymaga tagu albo digestu @sha256: dla każdego obrazu: aplikacji, PostgreSQL, Redis i Nginx, a latest odrzuca z komunikatem błędu. Domyślnie baza używa gałęzi postgres:17-alpine, Redis redis:7.4-alpine, a Nginx nginx:1.28-alpine. W krytycznym wdrożeniu przypnij pełny tag poprawki lub digest sha256, a aktualizacje wykonuj kontrolowanym procesem.

Obraz aplikacji jest projektem użytkownika, więc generator nie może znać właściwego numeru. Domyślne registry.example.com/myapp:1.0.0 to przykład, który trzeba zastąpić adresem obrazu z własnego rejestru. Generator Dockerfile pomoże przygotować jego definicję, ale przed wdrożeniem obraz nadal należy zbudować, przetestować i przeskanować.

Sekrety poza plikiem compose.yaml

To samo odwołanie trafia do POSTGRES_PASSWORD w usłudze db i do DB_PASSWORD w usłudze app, więc obie strony zawsze używają jednego hasła. Użytkownik i baza mają stałą nazwę app. Wartość ustaw w pliku .env obok compose.yaml (dodanym do .gitignore), w środowisku serwera albo w menedżerze sekretów CI/CD. Jeśli potrzebujesz szablonu nazw bez wartości, użyj generatora .env.example. W organizacji z dedykowanym magazynem sekretów można po wygenerowaniu zastąpić zmienną mechanizmem secrets i dostosować aplikację do odczytu pliku z /run/secrets.

Healthchecki i kolejność uruchamiania w Docker Compose

Samo uruchomienie procesu bazy nie oznacza, że przyjmuje ona połączenia. PostgreSQL dostaje test pg_isready -U app -d app co 10 s, z 10 próbami i 30-sekundowym okresem startowym, a Redis polecenie redis-cli ping co 10 s. Aplikacja używa długiej formy depends_on z warunkiem service_healthy, dlatego startuje dopiero po pozytywnym wyniku kontroli usług danych. Nginx czeka tylko na rozpoczęcie usługi aplikacji (service_started) i co 30 s weryfikuje własną konfigurację przez nginx -t.

Uniwersalnego healthchecka aplikacji dla dowolnego obrazu nie ma: PHP-FPM, Node, proces worker i aplikacja HTTP mają inne punkty gotowości. Po skopiowaniu pliku dodaj test dopasowany do obrazu, na przykład zapytanie do lekkiego endpointu /health, i zmień warunek Nginx na service_healthy. To uczciwsze niż test procesu, który dawałby zielony stan mimo niedziałających zależności. Gotowe polecenia testów podpowie generator healthcheck Docker.

Sieć, porty i trwałość danych

Wszystkie usługi należą do prywatnej sieci app-net ze sterownikiem bridge. PostgreSQL i Redis nie mają sekcji ports, więc nie są wystawione na interfejs hosta. Aplikacja używa expose, które dokumentuje port dostępny wewnątrz sieci, ale go nie publikuje. Jedynym wejściem z hosta jest Nginx: domyślnie mapowanie "80:80", a po zmianie pola portu na przykład "8080:80", gdy przed kontenerem działa już inne proxy.

Po zaznaczeniu wolumenów dane PostgreSQL i Redis trafiają do nazwanych wolumenów db-data i redis-data zadeklarowanych na najwyższym poziomie. Generator nie montuje generycznego katalogu aplikacji, bo jego ścieżka zależy od własnego obrazu i błędny mount mógłby zasłonić pliki. Odznaczenie opcji usuwa montowania i deklaracje wolumenów usług danych, więc plik pozostaje składniowo poprawny, ale dane staną się nietrwałe. Produkcyjnie pozostaw wolumeny włączone i opracuj niezależny backup bazy; wolumen nie jest kopią zapasową.

Wygenerowany nginx.conf i pułapka PHP-FPM

Przy zaznaczonym Nginx narzędzie wypisuje blok server nasłuchujący na porcie 80, z proxy_pass http://app:PORT i nagłówkami Host, X-Real-IP, X-Forwarded-For oraz X-Forwarded-Proto. Plik zapisz jako nginx.conf obok compose.yaml; Compose montuje go jako /etc/nginx/conf.d/default.conf. To konfiguracja dla aplikacji, która sama mówi HTTP, czyli typowo Node na porcie 3000.

Port 9000 (domyślny i z presetu Laravel) to zwykle PHP-FPM, który używa protokołu FastCGI, a nie HTTP. Z proxy_pass Nginx zwróci błąd 502. Lista kontrolna pod wynikiem ostrzega o tym; zamień wtedy blok location na fastcgi_pass app:9000 z parametrami FastCGI. Pamiętaj też, że Nginx w kontenerze PHP-FPM nie widzi plików aplikacji, więc statyczne zasoby trzeba udostępnić osobno. Bloki dla PHP i plików statycznych pomoże złożyć konfigurator bloków location Nginx.

Logi, limity zasobów i utwardzanie

Rotacja logów jest domyślnie włączona: każda usługa dostaje sterownik json-file z max-size: "10m" i max-file: "3", czyli najwyżej około 30 MB logów na kontener. Bez tego logi mogą zapełnić dysk, o ile limitu nie ustawia konfiguracja demona Docker.

Opcja „Limity zasobów aplikacji” dodaje do usługi app blok deploy.resources.limits z pamięcią w formacie 512m lub 2g i CPU od 0,01 do 64 rdzeni (np. 0.5). Bazie i Redisowi limity dobierz sam, bo zależą od rozmiaru danych. Opcja no-new-privileges:true trafia do security_opt wszystkich usług i blokuje podnoszenie uprawnień w kontenerze; jest domyślnie wyłączona, bo część obrazów jej nie toleruje, więc po włączeniu przetestuj aplikację. Polityka restartu do wyboru to unless-stopped (domyślna), always albo on-failure.

Uruchomienie produkcyjnego compose.yaml i kontrola konfiguracji

1. Wybierz preset albo usługi, podaj nazwę projektu, port procesu aplikacji i wersjonowane obrazy. Nginx wymaga zaznaczonej aplikacji, bo generowana konfiguracja zakłada reverse proxy.
2. Ustaw nazwę zmiennej hasła. Nie podawaj wartości sekretu w generatorze.
3. Pobierz compose.yaml i nginx.conf do jednego katalogu; dla PHP-FPM popraw blok location.
4. Ustaw sekret w środowisku, uruchom docker compose config i przejrzyj rozwinięty model. Składnię możesz dodatkowo sprawdzić w walidatorze YAML.
5. Uruchom docker compose up -d, a potem sprawdź docker compose ps, logi, stan healthchecków i dostępność endpointu aplikacji.

Jeśli potrzebujesz prostszego pliku do pracy lokalnej, generator Docker Compose oferuje szerszy zestaw usług deweloperskich. Wariant produkcyjny celowo unika bind mountu całego kodu i skupia się na niezmiennym obrazie z rejestru.