Co znaczą ID reguł typu DL3007?

Prefiks to **rodzina**: `DL` dla reguł Dockerfile hadolinta, `SC` dla reguł ShellCheck. Liczba to **numer reguły** w publicznym katalogu. `DL3007` to „Nie używaj tagu :latest". `SC2086` to „Cytuj zmienne powłoki, by zapobiec word splitting". Wyszukanie ID w repo hadolinta albo ShellCheck na GitHubie daje pełen opis, uzasadnienie i przykłady.

Czemu konkretnie :latest to problem?

Bo **:latest to ruchomy cel**. `FROM node:latest` buduje z wersją Node, która była otagowana jako latest w momencie builda. Trzy miesiące później obraz się rebuilduje (cache CI invalid, refresh base image, cokolwiek) i Node 22 to teraz Node 24 z breaking changes. Pinuj do **konkretnej wersji** typu `node:20.11-alpine` albo, lepiej, **do digestu** typu `node:20.11-alpine@sha256:abc...` dla pełnej powtarzalności. Trade-off: digest wymaga ręcznych bumpów.

apt-get install + cleanup, czemu w jednym RUN?

Bo **każde `RUN` to osobna warstwa**. Warstwa 1 instaluje pakiety -> 200 MB. Warstwa 2 kasuje `/var/lib/apt/lists` -> 0 MB, ale **warstwa 1 nadal niesie te 200 MB**. Warstwy Dockera są append-only; nie da się usunąć contentu w późniejszej warstwie. Więc wzorzec to **install + clean w jednym RUN**: `RUN apt-get update && apt-get install -y --no-install-recommends curl=1.2 && rm -rf /var/lib/apt/lists/*`. Te 200 MB nigdy nie wchodzą do żadnej warstwy.

Czemu ADD jest gorsze od COPY?

Bo **ADD ma ukrytą magię**. Robi trzy rzeczy: kopiuje pliki lokalne (jak COPY), ściąga z URL-i (czasem przydatne, często nieoczekiwane) i auto-rozpakowuje tarballe (`ADD foo.tar.gz /app/` rozpakuje go). Auto-rozpakowanie zaskakuje ludzi. **COPY** robi jedną rzecz przewidywalnie. Hadolint mówi: używaj COPY dla lokalnych plików (`DL3020`); sięgaj po ADD tylko, gdy naprawdę chcesz URL fetch albo tarball extract. Fix w tym linterze zamienia `ADD` na `COPY` tylko, gdy ścieżka jest lokalna.

CMD shell form vs exec form, jaka różnica?

**Shell form**: `CMD npm run start`. Docker owija to w `/bin/sh -c "npm run start"`. Prawdziwy PID 1 to **powłoka**, nie Twoja aplikacja. Powłoka **nie przekazuje sygnałów** do dziecka, więc `docker stop` wysyła SIGTERM do powłoki, która często go ignoruje. Kontener idzie do śmierci 10 sekund (domyślny stop timeout). **Exec form**: `CMD ["npm", "run", "start"]`. Twoja aplikacja jest PID 1 bezpośrednio, sygnały do niej docierają. Graceful shutdown faktycznie działa. Zawsze preferuj exec form (`DL3025`).

Czemu ma znaczenie, że działa jako root?

Trzy powody. **Raz**, obrona w głąb: jeśli jest podatność w Twojej aplikacji, root w kontenerze ucieknie szybciej (pomyśl o CVE w starszych wersjach runc). **Dwa**, Pod Security Standards w Kubernetes domyślnie odrzucają root w trybie restricted; wiele organizacji z tym jedzie. **Trzy**, uprawnienia plików są mylące, gdy Twoja aplikacja pisze jako root, a ktoś inny czyta jako zwykły user (volume mounty). Dodaj `USER 65532:65532` (albo nazwanego usera utworzonego przez `adduser`) pod koniec Dockerfile i upewnij się, że ścieżki, gdzie aplikacja pisze, są zapisywalne dla tego UID.

Do czego HEALTHCHECK?

HEALTHCHECK to komenda, którą Docker uruchamia okresowo, żeby zapytać „czy kontener jest gotowy?". Wynik: `healthy` / `unhealthy`. Docker wystawia ten status **orchestratorom**: `docker compose up --wait` czeka na healthy; Kubernetes używa podobnego mechanizmu przez probe; Swarm reschedule'uje niezdrowe taski. Bez HEALTHCHECK kontener jest po prostu „running", a to nie to samo, co „gotowy przyjąć pracę". Dodaj jeden dla długo żyjących serwisów: `HEALTHCHECK --interval=30s --timeout=5s CMD wget -q --spider http://localhost:3000/health || exit 1`.

Czemu pinować po digestcie?

Bo **tag to etykieta, digest to zawartość**. Nawet `node:20.11-alpine` może być **republished** z inną zawartością (fix bezpieczeństwa, update warstwy bazowej). Najczęściej zmiana jest mile widziana, ale w środowiskach regulowanych albo dla forensicowej powtarzalności chcesz `node:20.11-alpine@sha256:abc...`. Po przypięciu jedynym sposobem na zmianę zawartości obrazu jest podbicie digestu w Dockerfile i rebuild. Trade-off: musisz pamiętać o updatach dla fixów bezpieczeństwa (użyj automatyzacji typu Renovate).

Czy linter umie przeformatować cały Dockerfile?

**Częściowo.** Proste podstawienia są automatyczne: `MAINTAINER` staje się `LABEL maintainer`, `ADD` staje się `COPY`, gdy źródło to ścieżka lokalna. Złożone zmiany wymagają człowieka: pinowanie wersji wymaga wybrania właściwej wersji, łączenie RUN wymaga zrozumienia zależności, dodanie HEALTHCHECK wymaga wiedzy, co probe'ować. Użyj panelu „fixed" jako punktu startu, potem nanieś resztę sugestii ręcznie.

Linter Dockerfile

Wklej Dockerfile i zobacz listę problemów (~20 reguł hadolint + custom): :latest, MAINTAINER, ADD, brak USER, brak HEALTHCHECK.

LiveDziała w przeglądarce

PrzykładyKliknij, żeby wczytać

Dockerfile

Wklej zawartość Dockerfile

11 linii

Błędy

Ostrzeżenia

Informacje

Lista problemów

DL3007 · line 1
FROM uses :latest tag (node:latest)
Fix: Pin to an explicit version, e.g. `node:20.11-alpine`, or even better, a digest
CUSTOM_DIGEST · line 1
Image node:latest is not pinned by digest
Fix: For maximal reproducibility, pin to a digest: `image:tag@sha256:...`. Trade-off: harder to update
CUSTOM_USER · line 1
Stage (default) never sets USER, will run as root
Fix: Add `USER 65532:65532` (or a named user) toward the end of the build stage
CUSTOM_HEALTH · line 1
Final stage has no HEALTHCHECK
Fix: Add a `HEALTHCHECK CMD ...` so Docker can mark unhealthy containers and other tooling can wait for ready
DL4000 · line 2
MAINTAINER is deprecated since Docker 1.13
Fix: Replace with `LABEL maintainer="name <email>"`
DL3020 · line 3
ADD is used for a local file, use COPY instead
Fix: COPY is preferred for local files. ADD has surprising behavior (auto-extract, URL fetch)
DL3020 · line 4
ADD is used for a local file, use COPY instead
Fix: COPY is preferred for local files. ADD has surprising behavior (auto-extract, URL fetch)
DL3008 · line 6
apt-get install has unpinned versions: curl, wget, git
Fix: Pin versions: `apt-get install -y package=1.2.3`. Build reproducibility depends on this
DL3015 · line 6
apt-get install without --no-install-recommends
Fix: Add `--no-install-recommends` to skip optional dependencies and shrink the image
DL3009 · line 6
apt-get install without cleanup
Fix: Add `&& rm -rf /var/lib/apt/lists/*` at the end of the RUN to delete cached package lists
DL3047 · line 6
wget without --progress (or -q) emits noisy logs
Fix: Use `wget --progress=dot:giga` or `wget -q` to keep the build log clean
DL4001 · line 6
Both wget and curl are used
Fix: Pick one. Mixing both adds an unnecessary package and a few MB to the image
DL3059 · line 6
Multiple consecutive RUN instructions
Fix: Each RUN is a new layer. Merge with `&&` and `\` line continuations to reduce image size
DL3003 · line 7
RUN cd ... is brittle, use WORKDIR
Fix: Each RUN starts a fresh shell. `cd` does not persist across instructions. Use `WORKDIR /path` instead
DL3059 · line 7
Multiple consecutive RUN instructions
Fix: Each RUN is a new layer. Merge with `&&` and `\` line continuations to reduce image size
DL3000 · line 8
WORKDIR uses a relative path (app)
Fix: Use an absolute path, e.g. `WORKDIR /app`
DL3025 · line 10
CMD should use the JSON array form
Fix: Use the exec form: `CMD ["bin", "arg1", "arg2"]`. The shell form (string) forks a /bin/sh that does not forward signals

Wersja z poprawkami (best-effort)

Proste substytucje: MAINTAINER -> LABEL, ADD -> COPY. Reszta wymaga ręcznych zmian

FROM node:latest
LABEL maintainer="team@example.com"
COPY package.json .
COPY package-lock.json .
RUN apt-get update
RUN apt-get install -y curl wget git
RUN cd /app && npm install
WORKDIR app
COPY . .
CMD npm run start

Lista wszystkich reguł

DL3000Use absolute WORKDIR
DL3003Use WORKDIR, not RUN cd ...
DL3007Do not use the :latest tag
DL3008Pin versions in apt-get install
DL3009Delete the apt lists after installing
DL3015Avoid additional packages with --no-install-recommends
DL3018Pin versions in apk add
DL3020Use COPY instead of ADD for local files
DL3025Use JSON array syntax for CMD/ENTRYPOINT
DL3028Pin gem versions
DL3045COPY destination should end with a / when copying to a directory
DL3047wget without --progress emits noisy logs
DL3059Multiple consecutive RUN. Consider merging to reduce layers
DL4000MAINTAINER is deprecated. Use LABEL maintainer instead
DL4001Use either wget or curl, not both
DL4006Set SHELL with -o pipefail before using pipes in RUN
SC2086Quote shell variables to prevent word splitting
CUSTOM_USERContainer runs as root. Set USER to a non-root account
CUSTOM_HEALTHHEALTHCHECK is missing for long-running services
CUSTOM_DIGESTImage is not pinned by digest (@sha256:...) for reproducibility

Co robi ten linter

Dockerfile, który technicznie się buduje, to nie to samo, co Dockerfile, który powinien iść na produkcję. Obraz może mieć kilkaset MB pozostałego cache apt, którego nikt nie używa. Może działać jako root bez HEALTHCHECK, więc K8s nigdy nie wie, że kontener jest popsuty. Może używać tagów `:latest`, które się zmieniają pod nogami. Może używać `ADD` tam, gdzie `COPY` byłoby bezpieczniejsze. Żadne z tego nie zatrzyma builda, ale każde powoduje ból na produkcji.

Ten linter uruchamia reguły w stylu hadolint w Twojej przeglądarce. Wklejasz Dockerfile, dostajesz listę problemów per linia z ID reguły, poziomem, opisem i podpowiedzią naprawy. Około 20 reguł ze standardowego katalogu hadolint (`DL3000`, `DL3007`, `DL3008`, ...) plus parę custom checków na brak USER, brak HEALTHCHECK i brak pinowania obrazu do digestu.

Wszystko działa client-side. Bez uploadu, bez builda, bez kontaktu z daemon Dockera. Wynik to ten sam rodzaj feedbacku, jaki dostałbyś z lokalnego `hadolint Dockerfile`, tylko w zakładce przeglądarki.

Jak używać

Wklej Dockerfile w panelu wejściowym albo wybierz jeden z przykładów u góry, żeby zobaczyć format wyniku.
Po prawej masz liczniki błędów / ostrzeżeń / info. Kliknij dowolny issue, żeby zobaczyć numer linii i podpowiedź naprawy. Każdy issue ma ID reguły typu `DL3007`, które możesz wyszukać w dokumentacji hadolint.
Częste ostrzeżenia, które linter łapie: tag `:latest` (`DL3007`), `apt-get install` bez pinowania wersji (`DL3008`) i **bez `rm -rf /var/lib/apt/lists/*` (`DL3009`), `MAINTAINER` które jest deprecated (`DL4000`), `ADD` na lokalnych plikach, gdzie `COPY` jest bezpieczniejsze (`DL3020`), `CMD` w formie powłoki zamiast JSON exec (`DL3025`), `RUN cd ...`** zamiast `WORKDIR` (`DL3003`).
Sprawdzenia bezpieczeństwa: kontener jako root, gdy nie ustawiono `USER`, wzorce typu `privileged: true`, obraz nie pinowany do digestu, brak `HEALTHCHECK` w finalnym etapie.
Użyj panelu „fixed" pod listą issues, żeby zobaczyć best-effort przeróbkę prostych przypadków: `MAINTAINER` staje się `LABEL maintainer`, `ADD` staje się `COPY`, gdy źródło jest lokalne. Bardziej złożone fixy (pinowanie wersji, dodanie HEALTHCHECK, łączenie RUN) wymagają ludzkiego przejrzenia.
Kliknij Kopiuj w panelu „fixed", żeby zgarnąć przerobioną wersję, albo Kopiuj w panelu wejściowym, żeby wrzucić oryginał do schowka.
Jeśli linter mówi „czysto", masz Dockerfile zgodny z dobrze znanymi dobrymi praktykami. Wciąż mogą być rzeczy projektowe do poprawy (rozmiar obrazu, kolejność warstw dla cache builda), ale podstawy są pokryte.

Kiedy się przydaje

Siedem konkretnych sytuacji, w których lintowanie Dockerfile przed `docker build` oszczędza realne nerwy:

Review PR-a kolegi z nowym Dockerfile. Linter daje szybką obiektywną listę: pinuj wersje, wyrzuć `:latest`, dodaj cleanup, dodaj non-root usera. Review skupia się na logice, nie na każdej oczywistej pułapce.
Pierwsze czyszczenie starego Dockerfile. Wiele starych Dockerfile używa `MAINTAINER`, `ADD` na lokalnych plikach, `apt-get install` bez cleanupu i finalny obraz jest dwa razy większy, niż mógłby być. Linter podświetla łatwe wygrane.
Optymalizacja rozmiaru obrazu. `DL3009` (cleanup list apt) i `DL3015` (`--no-install-recommends`) razem potrafią obciąć obrazy o 100+ MB. `DL3059` (łączenie kolejnych RUN) zmniejsza liczbę warstw, co ma znaczenie przy skali.
Audyt bezpieczeństwa. `CUSTOM_USER` flaguje każdy etap, który kończy jako root. W połączeniu z `CUSTOM_HEALTH` na finalnym etapie to minimum przed hartowaniem przed wysyłką.
Pinowanie wersji dla powtarzalności. `DL3007` (brak `:latest`), `DL3008` (wersje apt), `DL3018` (wersje apk), `DL3028` (wersje gem), `CUSTOM_DIGEST` (obraz po sha256). Razem czynią buildy deterministycznymi.
Nauczanie juniorów, co łapie hadolint. ID reguł mapują się 1:1 do publicznego katalogu hadolint, więc każdy może je sprawdzić i nauczyć się uzasadnienia każdej reguły.
Szybki check w przeglądarce przed pushem. `docker build` trwa minuty; linter jest natychmiastowy. Krótki feedback loop podczas iteracji nad Dockerfile.

Pytania i odpowiedzi

hadolint to standardowy open-source linter Dockerfile napisany w Haskellu. Pod spodem używa ShellCheck do analizy komend powłoki w `RUN`. To narzędzie implementuje 20 najczęstszych reguł z tymi samymi ID (więc możesz je wyszukać w katalogu hadolint), działa w całości w przeglądarce, bez instalacji. Dla pełnej jakości analizy powłoki z ShellCheck i 60+ reguł zainstaluj prawdziwego hadolinta lokalnie i wpinaj do CI.

Mogą Cię też zainteresować

Powiązane narzędzia

Kreator docker-compose.yml

Złóż docker-compose.yml klikami: WordPress + MySQL, Node + Postgres + Redis, Nginx + PHP-FPM + MariaDB, sam Redis, ClickHouse. Każda opcja z opisem zwykłym językiem.

Walidator YAML Kubernetes

Wklej manifesty Kubernetesa (multi-doc OK) i zobacz listę błędów + ostrzeżeń + sugestii: matchLabels, targetPort, :latest, brak limitów, privileged.

Kreator GitHub Actions YAML

Zbuduj `.github/workflows/ci.yml` klikami: triggery, joby, macierze, popularne akcje. Walidacja i podgląd na żywo.

Kreator GitLab CI YAML

Zbuduj `.gitlab-ci.yml` klikami: etapy, joby, reguły, artefakty, cache. Walidacja zależności i podgląd na żywo.

Generator .editorconfig

Złóż `.editorconfig` klikami: charset, end_of_line, indent, trim_trailing_whitespace + bloki dla *.md, Makefile, *.go. Presety dla JS, Python, Go, Polyglot.

Builder konfiguracji nginx

Złóż gotowy server-block nginx w pięciu trybach: strona statyczna, reverse proxy, przekierowanie, subdomena, load balancer. SSL, gzip i WebSocket jednym przełącznikiem.

FROM node:latest LABEL maintainer="team@example.com" COPY package.json . COPY package-lock.json . RUN apt-get update RUN apt-get install -y curl wget git RUN cd /app && npm install WORKDIR app COPY . . CMD npm run start

Co robi ten linter

Jak używać

Wklej Dockerfile w panelu wejściowym albo wybierz jeden z przykładów u góry, żeby zobaczyć format wyniku.

Po prawej masz liczniki błędów / ostrzeżeń / info. Kliknij dowolny issue, żeby zobaczyć numer linii i podpowiedź naprawy. Każdy issue ma ID reguły typu `DL3007`, które możesz wyszukać w dokumentacji hadolint.

Częste ostrzeżenia, które linter łapie: tag `:latest` (`DL3007`), `apt-get install` bez pinowania wersji (`DL3008`) i **bez `rm -rf /var/lib/apt/lists/*` (`DL3009`), `MAINTAINER` które jest deprecated (`DL4000`), `ADD` na lokalnych plikach, gdzie `COPY` jest bezpieczniejsze (`DL3020`), `CMD` w formie powłoki zamiast JSON exec (`DL3025`), `RUN cd ...`** zamiast `WORKDIR` (`DL3003`).

Sprawdzenia bezpieczeństwa: kontener jako root, gdy nie ustawiono `USER`, wzorce typu `privileged: true`, obraz nie pinowany do digestu, brak `HEALTHCHECK` w finalnym etapie.

Użyj panelu „fixed" pod listą issues, żeby zobaczyć best-effort przeróbkę prostych przypadków: `MAINTAINER` staje się `LABEL maintainer`, `ADD` staje się `COPY`, gdy źródło jest lokalne. Bardziej złożone fixy (pinowanie wersji, dodanie HEALTHCHECK, łączenie RUN) wymagają ludzkiego przejrzenia.

Kliknij Kopiuj w panelu „fixed", żeby zgarnąć przerobioną wersję, albo Kopiuj w panelu wejściowym, żeby wrzucić oryginał do schowka.

Jeśli linter mówi „czysto", masz Dockerfile zgodny z dobrze znanymi dobrymi praktykami. Wciąż mogą być rzeczy projektowe do poprawy (rozmiar obrazu, kolejność warstw dla cache builda), ale podstawy są pokryte.

Kiedy się przydaje

Siedem konkretnych sytuacji, w których lintowanie Dockerfile przed `docker build` oszczędza realne nerwy:

Review PR-a kolegi z nowym Dockerfile. Linter daje szybką obiektywną listę: pinuj wersje, wyrzuć `:latest`, dodaj cleanup, dodaj non-root usera. Review skupia się na logice, nie na każdej oczywistej pułapce.
Pierwsze czyszczenie starego Dockerfile. Wiele starych Dockerfile używa `MAINTAINER`, `ADD` na lokalnych plikach, `apt-get install` bez cleanupu i finalny obraz jest dwa razy większy, niż mógłby być. Linter podświetla łatwe wygrane.
Optymalizacja rozmiaru obrazu. `DL3009` (cleanup list apt) i `DL3015` (`--no-install-recommends`) razem potrafią obciąć obrazy o 100+ MB. `DL3059` (łączenie kolejnych RUN) zmniejsza liczbę warstw, co ma znaczenie przy skali.
Audyt bezpieczeństwa. `CUSTOM_USER` flaguje każdy etap, który kończy jako root. W połączeniu z `CUSTOM_HEALTH` na finalnym etapie to minimum przed hartowaniem przed wysyłką.
Pinowanie wersji dla powtarzalności. `DL3007` (brak `:latest`), `DL3008` (wersje apt), `DL3018` (wersje apk), `DL3028` (wersje gem), `CUSTOM_DIGEST` (obraz po sha256). Razem czynią buildy deterministycznymi.
Nauczanie juniorów, co łapie hadolint. ID reguł mapują się 1:1 do publicznego katalogu hadolint, więc każdy może je sprawdzić i nauczyć się uzasadnienia każdej reguły.
Szybki check w przeglądarce przed pushem. `docker build` trwa minuty; linter jest natychmiastowy. Krótki feedback loop podczas iteracji nad Dockerfile.

Pytania i odpowiedzi