Ce que fait ce linter
Un Dockerfile qui buildent techniquement n'est pas le même qu'un Dockerfile qui devrait être livré. L'image peut avoir quelques centaines de Mo de cache apt résiduel que personne n'utilise. Elle peut tourner en root sans HEALTHCHECK, K8s ne sait donc jamais que le conteneur est cassé. Elle peut utiliser des tags `:latest` qui changent sous vos pieds. Elle peut utiliser `ADD` là où `COPY` serait plus sûr. Aucun de ces points n'arrête le build, mais chacun cause de la douleur en production.
Ce linter lance des règles style hadolint dans votre navigateur. Collez votre Dockerfile et vous obtenez une liste d'issues par ligne avec rule ID, gravité, description, et un indice de fix. Environ 20 règles du catalogue standard hadolint (`DL3000`, `DL3007`, `DL3008`, ...) plus quelques vérifs custom pour USER non réglé, HEALTHCHECK manquant, et image non épinglée par digest.
Tout tourne côté client. Pas d'upload, pas de build, pas de contact avec le daemon Docker. La sortie est le même type de feedback que vous obtiendriez en lançant `hadolint Dockerfile` localement, juste dans l'onglet du navigateur.
Mode d'emploi
- Collez votre Dockerfile dans le panneau d'entrée, ou choisissez un des exemples en haut pour voir le format de sortie.
- Lisez les compteurs erreur / avertissement / info en haut à droite. Cliquez sur n'importe quelle issue pour voir le numéro de ligne et l'indice de fix. Chaque issue porte un rule ID comme `DL3007` que vous pouvez chercher pour la doc hadolint complète.
- Avertissements courants que le linter flague : tag `:latest` (`DL3007`), `apt-get install` sans versions épinglées (`DL3008`) et **sans `rm -rf /var/lib/apt/lists/*` (`DL3009`), `MAINTAINER` qui est déprécié (`DL4000`), `ADD` pour les fichiers locaux où `COPY` est plus sûr (`DL3020`), `CMD` en forme shell au lieu de forme exec JSON (`DL3025`), `RUN cd ...`** au lieu de `WORKDIR` (`DL3003`).
- Vérifs sécurité : conteneur tourne en root quand aucun `USER` n'est réglé, patterns style `privileged: true`, image non épinglée par digest, `HEALTHCHECK` manquant sur le stage final.
- Utilisez le panneau "fixed" sous les issues pour voir une réécriture best-effort des cas simples : `MAINTAINER` devient `LABEL maintainer`, `ADD` devient `COPY` quand la source est locale. Les fixes plus complexes (épinglage versions, ajout HEALTHCHECK, splitting RUN) ont besoin d'une lecture humaine.
- Cliquez sur Copier sur le panneau "fixed" pour attraper la version réécrite, ou Copier sur le panneau d'entrée pour mettre l'original dans votre presse-papiers.
- Quand le linter dit "tout propre", vous avez un Dockerfile qui suit les bonnes pratiques bien connues. Il peut encore y avoir des choses spécifiques au projet à corriger (taille d'image, ordre des layers pour le cache de build), mais les basiques sont couverts.
Quand cet outil est utile
Sept situations concrètes où linter un Dockerfile avant `docker build` évite de vrais mal de têtes :
- Reviewer la PR d'un collègue avec un nouveau Dockerfile. Le linter donne une liste rapide objective : épingler les versions, virer `:latest`, ajouter le cleanup, ajouter un user non-root. La revue de code focalisée sur la logique, pas sur chaque écueil courant.
- Nettoyage premier-passage d'un Dockerfile legacy. Beaucoup de vieux Dockerfiles utilisent `MAINTAINER`, `ADD` pour les fichiers locaux, `apt-get install` sans cleanup, et une image finale deux fois plus grosse qu'elle pourrait. Le linter highlight les gains faciles.
- Optimiser la taille d'image. `DL3009` (cleanup apt list) et `DL3015` (`--no-install-recommends`) ensemble peuvent rétrécir les images de 100+ Mo. `DL3059` (merger les RUN consécutifs) réduit le nombre de layers ce qui compte à l'échelle.
- Passe sécurité. `CUSTOM_USER` flague chaque stage qui finit en root. Combiné avec `CUSTOM_HEALTH` pour le stage final, c'est les vérifs baseline minimum pour hardener avant de livrer.
- Épingler les versions pour la reproductibilité. `DL3007` (pas de `:latest`), `DL3008` (versions apt), `DL3018` (versions apk), `DL3028` (versions gem), `CUSTOM_DIGEST` (image par sha256). Ensemble ils rendent les builds déterministes.
- Enseigner aux juniors ce qu'hadolint attrape. Les rule IDs mappent 1:1 sur le catalogue hadolint public pour que quiconque puisse les chercher et apprendre le raisonnement derrière chaque règle.
- Vérif rapide dans le navigateur avant de push. `docker build` prend des minutes ; le linter est instantané. Boucle de feedback rapide pendant l'itération sur le Dockerfile.