Generator Dockerfile multistage

Generator Dockerfile multistage — build oddzielony od runtime

Generator Dockerfile multistage przygotowuje dwa wyspecjalizowane etapy dla PHP, Node.js, Pythona albo Go. Kompilatory i zależności deweloperskie zostają w obrazie build, a finalny etap otrzymuje tylko kod, artefakty oraz biblioteki potrzebne do uruchomienia aplikacji.

Wybierz stos i wspieraną wersję obrazu, nazwę aplikacji, katalog roboczy i port. Domyślny wynik uruchamia proces jako non-root, używa exec form dla CMD i dodaje próbę zdrowia dopasowaną do runtime. Prostszy, jednoetapowy punkt wyjścia znajdziesz w generatorze Dockerfile.

Co naprawdę trafia do obrazu końcowego

Cache zależności i powtarzalne buildy

Manifest zależności jest kopiowany przed kodem: composer.lock, package-lock.json, requirements.txt albo go.sum. Docker może wtedy wykorzystać kosztowną warstwę instalacji po zmianie pliku aplikacji. Zmiana lockfile celowo unieważnia cache i pobiera nowy zestaw pakietów.

Wybrane tagi wskazują konkretne, wspierane linie języka i wariant Alpine lub Slim; generator nie przyjmuje dowolnego tekstu w polu wersji. Tag nadal może zostać przesunięty przez wydawcę. Dla audytowalnej produkcji po testach przypnij każdy FROM do digestu, a aktualizacje digestów wykonuj automatycznym, recenzowanym pull requestem.

Bezpieczeństwo obrazu: non-root, sekrety i minimalny runtime

Właściciel plików i użytkownik procesu

PHP korzysta z istniejącego konta www-data, Node z konta node, Python tworzy systemowego użytkownika app, a Go robi to samo w Alpine. Instrukcje COPY --chown zapewniają dostęp do artefaktów bez późniejszego, kosztownego chown -R. Opcję non-root wyłączaj wyłącznie do świadomego debugowania obrazu.

Non-root nie naprawi zbyt szerokich uprawnień hosta. Nie montuj docker.sock, nie używaj --privileged i przydzielaj zapisywalny wolumen tylko tam, gdzie aplikacja go potrzebuje. Gdy obraz jest gotowy, parametry uruchomienia sprawdzisz w generatorze Docker Compose.

Sekrety nie należą do ARG ani ENV

Generator nie tworzy żadnego pola na sekret i nie umieszcza przykładowego hasła. Plik .dockerignore powinien dodatkowo wykluczać .env, katalog .git, lokalne cache i wyniki testów. Wzorzec listy ignorowanych plików przygotuje generator .gitignore.

Jak użyć i sprawdzić wygenerowany Dockerfile

1. Wybierz język. Zmiana presetu ustawia zgodny tag i port; PHP-FPM pozostaje na porcie 9000.
2. Dopasuj nazwę modułu, katalog roboczy i ścieżkę artefaktu. W Node generator zakłada dist/server.js.
3. Zapisz plik jako Dockerfile oraz przygotuj mały .dockerignore.
4. Uruchom docker build --pull -t app:test ., następnie przeskanuj obraz i obejrzyj historię warstw.
5. Wystartuj kontener bez roota, sprawdź logi, endpoint /health i zatrzymanie procesu sygnałem SIGTERM.

Healthcheck zależny od runtime

PHP-FPM nie obsługuje HTTP, dlatego próba używa cgi-fcgi i portu 9000. Node oraz Go korzystają z wget dostępnego w obrazie Alpine. Python odpytuje HTTP modułem urllib ze standardowej biblioteki, więc nie instaluje programu curl. Dla aplikacji HTTP dostosuj ścieżkę /health; jeśli proces jest workerem, zastąp próbę kontrolą kolejki lub wyłącz ją.

CMD w exec form i własna komenda

Domyślne polecenia powstają jako tablica JSON, dzięki czemu proces aplikacji otrzymuje sygnały bez pośredniej powłoki. Jeśli wpiszesz własne CMD, generator jawnie zapisze ["sh","-c",…], poprawnie ucieknie cudzysłowy i odrzuci znaki sterujące. To umożliwia potoki, ale odpowiedzialność za bezpieczną składnię pozostaje po stronie autora obrazu.

Przed wdrożeniem sprawdź także uprawnienia katalogów, np. w kalkulatorze chmod, i ustaw limity CPU/pamięci w orchestratorze. Wieloetapowy build zmniejsza powierzchnię ataku, lecz nie zastępuje skanowania zależności i regularnego odświeżania obrazów bazowych.

Najczęściej zadawane pytania