Generator .dockerignore

Generator .dockerignore — mniejszy kontekst budowania, krótszy build

Generator .dockerignore składa listę wykluczeń z gotowych bloków: zależności, katalog Gita, sekrety, pliki CI, ustawienia edytorów, dokumentacja i śmieci systemowe. Zaznacz technologie, których używa projekt, skopiuj wynik do katalogu z kontekstem budowania i przestań wysyłać do demona Dockera setki megabajtów, które w obrazie nigdy nie wylądują.

Czym jest kontekst budowania

Polecenie docker build . najpierw pakuje wskazany katalog i przesyła go do demona jako kontekst budowania. Dopiero potem wykonują się instrukcje z Dockerfile. Jeśli w katalogu leżą node_modules, vendor i pełna historia repozytorium, każdy build zaczyna się od kilkudziesięciu sekund przepychania plików, których obraz w ogóle nie potrzebuje. Plik .dockerignore działa właśnie na tym etapie: filtruje kontekst, zanim cokolwiek dotrze do demona.

Co warto wykluczyć

Jak korzystać z generatora

1. Zaznacz kafelki odpowiadające stosowi technologicznemu projektu. Możesz łączyć kilka, na przykład PHP i Node.js dla aplikacji Laravel z frontendem budowanym przez Vite.
2. Kliknij Generuj .dockerignore. Wzorce powtarzające się między grupami trafiają do wyniku tylko raz.
3. Skopiuj zawartość i zapisz jako .dockerignore w katalogu, który podajesz jako kontekst — zwykle w korzeniu repozytorium.
4. Uruchom docker build . i porównaj linię Sending build context to Docker daemon przed i po zmianie.

Ten sam projekt potrzebuje zwykle także listy plików pomijanych przez Gita — przygotuje ją generator .gitignore, który operuje na bardzo podobnej składni. Przy wdrożeniu obrazu na klaster przyda się generator manifestu Deployment dla Kubernetes, a przy klasycznym hostingu generator pliku .htaccess. Składnię towarzyszącego pliku docker-compose.yml sprawdzisz walidatorem YAML.

Składnia wzorców i różnice wobec .gitignore

Wzorce są dopasowywane zawsze względem korzenia kontekstu, a nie względem katalogu, w którym leży plik. To pierwsza istotna różnica: w Gicie każdy podkatalog może mieć własny .gitignore, w Dockerze liczy się wyłącznie .dockerignore z korzenia kontekstu. Gwiazdka zastępuje fragment nazwy w jednym segmencie ścieżki, podwójna gwiazdka przechodzi przez dowolną liczbę katalogów, więc **/*.log obejmuje logi na każdym poziomie drzewa. Wykrzyknik tworzy wyjątek, a przy konflikcie wygrywa ostatnia pasująca linia — dlatego *.md w jednej linii i !README.md w następnej zostawi README w kontekście.

Czego nie wykluczać

Grupa „Dokumentacja” wyklucza tests oraz *.md. To dobry domyślny wybór dla obrazu produkcyjnego, ale jeśli w obrazie uruchamiasz testy albo composer.json mapuje katalog testów przez autoload-dev, usuń ten wzorzec z wyniku.

Cache warstw a kolejność kopiowania

Najwięcej zyskujesz, łącząc .dockerignore z sensowną kolejnością instrukcji: najpierw manifesty zależności, potem instalacja, a kod na końcu:

COPY package.json package-lock.json ./
RUN npm ci
COPY . .
RUN npm run build

Warstwa z npm ci zostaje wtedy w cache, dopóki nie zmienią się manifesty. Bez .dockerignore ten układ i tak niewiele daje, bo lokalny node_modules wpada do kontekstu i unieważnia warstwę COPY . . przy każdej instalacji pakietu na maszynie deweloperskiej.

Najczęściej zadawane pytania