Analysez un Dockerfile avant qu’il arrive en revue.

Dix-sept règles, de DF001 à DF017, et chacune décrit une erreur qui compile quand même : une image de base sans tag ou en :latest, un COPY --from qui nomme une étape qui n’existe pas encore, ADD là où COPY convient, un téléchargement distant non vérifié, un WORKDIR relatif, un apt-get update isolé dans sa propre couche, un cache de paquets laissé dans l’image, un secret écrit dans l’historique de l’image par ENV ou ARG, une étape finale qui tourne en root, cd au lieu de WORKDIR, curl redirigé dans un shell, un second CMD qui gagne silencieusement, une forme exec JSON qui n’est pas du JSON valide, sudo dans une étape de build, MAINTAINER, et un COPY . qui détruit le cache de l’installation des dépendances. Chaque règle a sa propre sous-section sur cette page, avec un extrait avant/après.

Non, et ce n’est pas le but. hadolint est un binaire que vous installez, et il associe ses propres règles à tout ce que ShellCheck signale sur le shell contenu dans vos lignes RUN — excellent en CI, et la bonne réponse quand vous pouvez imposer une chaîne d’outils. Ceci couvre le cas qu’il ne couvre pas : un Dockerfile que vous voulez vérifier tout de suite, depuis un navigateur, sur une machine où vous ne pouvez rien installer, sans envoyer le fichier à un serveur. Dix-sept règles au lieu d’une longue traîne, chacune avec son correctif, et plus bas une liste explicite de ce qu’il refuse de signaler.

Non. Le parseur et les dix-sept règles sont du JavaScript exécuté dans votre onglet — pas de serveur, pas d’appel d’API, pas de journalisation, donc 0 octet envoyé. Cela compte plus ici que pour la plupart des outils : les Dockerfiles contiennent des noms d’hôtes de registres internes, des index de paquets privés, des arguments de build et, de temps en temps, une information d’identification que personne n’aurait dû committer.

Parce que chaque RUN est une couche distincte avec sa propre entrée de cache. Quand vous ne modifiez ensuite que la ligne d’installation, Docker réutilise la couche update mise en cache — elle peut avoir des semaines ou des mois — et exécute l’installation contre cet index de paquets périmé. Le résultat est soit une version inattendue, soit un 404 pour un paquet remplacé depuis. Les réunir dans un seul RUN fait partager la même entrée de cache à l’index et à l’installation : ils ne peuvent plus se contredire.

Rien, jusqu’à ce que l’éditeur pousse une nouvelle version. :latest est un pointeur mobile, et un FROM sans tag signifie :latest : l’image de base utilisée par votre build le mois dernier et celle de ce soir peuvent être des versions majeures différentes sans le moindre changement de votre côté — et rien dans le fichier ne consigne celle que vous avez réellement testée. Épinglez un tag que vous avez testé. S’il vous faut des rebuilds identiques à l’octet, ajoutez aussi le digest (@sha256:…). Ce linter demande un tag et n’exige jamais un digest : cet arbitrage vous appartient.

Parce que Docker ne le rejette pas : il fait silencieusement autre chose. La forme exec n’est utilisée que si l’argument se parse comme du JSON, et le JSON exige des guillemets doubles. Avec des apostrophes, tout retombe en forme shell : Docker exécute /bin/sh -c "['nginx']" et les crochets comme les apostrophes deviennent une partie de la commande. Rien ne vous avertit à la compilation ; le conteneur ne démarre simplement pas, ou démarre un shell qui n’est pas le processus que vous vouliez comme PID 1.

Pas directement, et il le dit plutôt que de deviner. Un .dockerignore est un fichier séparé : un linter qui ne lit que le Dockerfile ne peut pas savoir si node_modules, .git et vos artefacts de build partent dans le contexte de build. Ce qu’il peut faire, c’est repérer le motif qui rend un .dockerignore manquant coûteux — un COPY . avant l’installation des dépendances, c’est-à-dire DF017 — et placer le conseil sur le .dockerignore dans le texte de correctif de cette règle.

Les deux ont été envisagés puis délibérément écartés. EXPOSE est de la documentation : il ne publie rien par lui-même, donc son absence ne casse rien et un EXPOSE en trop ne coûte rien. HEALTHCHECK est complètement ignoré par Kubernetes, là où ces images tournent réellement : le signaler entraînerait ce public à ignorer le linter. La liste complète de ce qui reste silencieux, avec la raison de chaque point, se trouve dans le panneau « Ce qu’il ne signale délibérément pas » au-dessus de la FAQ.

Jusqu’à 200 000 caractères — environ quatre mille lignes de texte dense, soit deux ordres de grandeur au-delà de tout Dockerfile réel. Au-delà, il refuse avec un message plutôt que de figer votre onglet, car une entrée de cette taille est un journal de build ou une archive, pas un Dockerfile. Les résultats sont plafonnés aussi, à 20 par règle et 200 au total, et le panneau annonce le plafond et le nombre réel dès qu’il s’applique.