Name: Tremplin Numérique
Price range: $$$

Les Dockerfiles définissent le contenu des images Docker comme un ensemble d’instructions dans un fichier texte. La syntaxe Dockerfile est généralement simple, mais il y a quelques pièges à éviter. Adhérer aux meilleures pratiques lors de l’écriture de Dockerfiles complexes dans un environnement d’équipe peut être délicat, sauf si vous validez automatiquement le contenu de votre fichier.

Hadolint est un linter Dockerfile qui peut détecter les problèmes courants pour vous. Il utilise un arbre de syntaxe abstraite (AST) pour analyser votre Dockerfile par rapport à des ensembles de règles prédéfinis. Hadolint intègre également ShellCheck afin qu’il puisse pelucher les scripts shell dans votre Dockerfile RUN consignes aussi.

Sommaire

Commencer

Hadolint est distribué en plusieurs formats. Vous pouvez rapidement démarrer en téléchargeant le dernier binaire précompilé pour votre système d’exploitation à partir de la page des versions GitHub du projet.

Hadolint a également sa propre image Docker, hadolint/hadolint, si vous préférez ne pas utiliser le binaire directement. Enfin, vous pouvez accéder à Hadolint via le Web pour l’expérimentation.

Linger un Dockerfile

Transmettez à Hadolint le chemin d’accès à un Dockerfile pour lancer une nouvelle analyse :

hadolint Dockerfile

Si vous utilisez la version Dockerized, il est plus simple de diriger le contenu de votre fichier dans un conteneur Hadolint :

docker run --rm -i hadolint/hadolint < Dockerfile

Les résultats de l’analyse seront affichés dans votre terminal. Dans cet exemple, Hadolint suggère que le fichier Dockerfile RUN apt-get install L’instruction n’est pas sûre car elle ne spécifie pas de versions de package explicites. Le contenu de votre image peut changer entre les versions, ce qui peut créer des problèmes déroutants.

Que recherche Hadolint ?

Hadolint possède des dizaines de règles intégrées qui vérifient les problèmes de configuration et de sécurité courants. Le linter vise à rendre vos Dockerfiles conformes aux meilleures pratiques de création d’image suggérées par Docker.

Les vérifications incluses couvrent l’utilisation d’utilisateurs finaux non root, faisant référence à un chemin relatif dans un WORKDIR instruction, ajout de plusieurs HEALTHCHECK instructions, et n’utilisant pas de balises et de versions explicitement épinglées. Comme Hadolint hérite également de l’ensemble de règles ShellCheck, il fera apparaître des problèmes de script Bash courants que cet outil identifie également.

Les règles sont identifiées par des nombres précédés soit HL ou SC. HL les règles font partie de Hadolint alors que SC les entrées proviennent de ShellCheck. Chaque vérification se voit attribuer une gravité allant d’Erreur à Info. Si vous obtenez des erreurs dans les résultats de votre analyse, celles-ci devraient être les premiers problèmes que vous résolvez.

Personnalisation de la configuration

Hadolint est configuré via un .hadolint.yaml déposer. Il recherchera plusieurs emplacements, y compris votre travail, .config, et les répertoires personnels. Seul le premier fichier trouvé est utilisé – il n’y a pas de fusion entre les emplacements.

Le fichier de configuration vous permet de personnaliser vos analyses en ignorant les règles et en modifiant leur gravité. Bien que l’ensemble de règles par défaut couvre les meilleures pratiques recommandées, vous constaterez peut-être que certaines vérifications ne s’appliquent pas dans votre environnement. Commettre un .hadolint.yaml à côté de votre Dockerfile vous permet d’adapter les scans Hadolint en conséquence. La plupart des champs de fichier de configuration sont également pris en charge en tant qu’indicateurs CLI et variables d’environnement.

Les règles sont désactivées par le ignored domaine. Il doit s’agir d’une liste d’ID de règles :

ignored:
  - DL3010
  - DL3020

Si vous devez réduire la sévérité d’une règle sans la désactiver entièrement, utilisez la commande override clé à la place. Cela vous permet également de promouvoir un problème de faible gravité à un niveau supérieur. Utilisez-le si vous souhaitez mettre davantage l’accent sur un problème particulier.

override:
  warning:
    - DL3020

Cela rétrograde la règle DL3020 de son niveau « d’erreur » par défaut au niveau « d’avertissement » moins grave. Cette règle exige que vous utilisiez COPY à la place de ADD lors du référencement de fichiers et de dossiers dans votre contexte de construction.

Vous pouvez également ajuster le niveau de gravité global. Réglage de la failure-threshold indique à Hadolint de quitter avec un statut d’échec si un test signale une erreur au niveau de gravité donné :

failure-threshold: warning

Cette instruction signifie que l’analyse Hadolint échouera s’il y a une erreur ou un avertissement dans sa sortie.

Vous pouvez désactiver la sortie avec un code d’échec en utilisant le no-fail: true l’option de configuration ou l’option --no-fail Indicateur CLI. Cela demandera à Hadolint de sortir avec un 0 code quel que soit le résultat réel du test. Cela peut être utile si vous souhaitez inclure Hadolint en tant que tâche non bloquante dans un pipeline CI.

Registres de confiance

Une autre utilisation du fichier de configuration consiste à définir des registres de confiance que vous souhaitez pouvoir référencer dans vos Dockerfiles. Quand le trustedRegistries est défini, Hadolint vous avertira lorsqu’une image d’un autre registre est utilisée :

trustedRegistries:
  - docker.io
  - docker-registry.example.com

Schémas d’étiquettes

Hadolint propose également un peluchage de base des étiquettes. Cela vous permet d’appliquer les étiquettes ajoutées à votre image par Dockerfile LABEL les instructions sont conformes aux contraintes spécifiées. Voici un exemple de la façon dont cela fonctionne :

label-schema:
  notes: text
  app-version: semver
  built-at: rfc3339

Cet extrait de configuration définit les types de données pour quatre étiquettes que vous pouvez utiliser dans votre Dockerfile. notes est déclaré comme un champ de texte arbitraire alors que app-version doit être un identifiant de version compatible avec semver. built-at est marqué comme une chaîne datetime RFC-3339. Vous pouvez obtenir la liste complète des types pris en charge dans la documentation Hadolint.

Hadolint autorise l’utilisation d’étiquettes qui ne sont pas répertoriées dans votre schéma. Vous pouvez désactiver cela et restreindre LABEL instructions uniquement à ceux présents dans le schéma en définissant strict-labels: true ou en utilisant le --strict-labels drapeau.

Formats de sortie

Plusieurs formats de sortie sont pris en charge via le format option ou --format drapeau. La valeur par défaut est tty qui émet une sortie colorisée sur votre terminal. Les couleurs peuvent être désactivées avec le --no-color drapeau.

Les formats alternatifs suivants sont disponibles :

json – Fournit la liste des problèmes détectés sous la forme d’une structure JSON détaillée, idéale pour une utilisation avec vos propres scripts.
checkstyle – Un rapport compatible Checkstyle.
codeclimate – Un rapport compatible Code Climat.
gitlab_codeclimate – Variation du rapport Code Climate qui fonctionne avec les fonctionnalités de qualité de code intégrées de GitLab. Cela vous permet d’afficher les erreurs sous forme de widget sur les pages de demande de fusion lors de l’exécution de Hadolint avec GitLab CI.

Ces formats de sortie sont idéaux pour utiliser Hadolint par programmation ou dans le cadre d’un pipeline CI.

Résumé

Hadolint automatise la détection des problèmes Dockerfile. Cela aide vos images Docker à respecter les meilleures pratiques et les normes organisationnelles. La configuration par défaut est un bon point de départ, mais vous pouvez la personnaliser en fonction de vos besoins en reclassant et en désactivant les règles.

Vous devriez envisager d’intégrer Hadolint à votre outil CI pour obtenir des rapports instantanés au fur et à mesure que les modifications Dockerfile sont validées. Cela accélère la révision du code en donnant aux développeurs une visibilité immédiate sur les problèmes. Vous pouvez également utiliser l’outil localement pendant que vous travaillez via des extensions d’éditeur prises en charge par la communauté, offrant une boucle de rétroaction encore plus courte.