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 le RUN de votre Dockerfile instructions aussi.
Mise en route
Hadolint est distribué en plusieurs formats. Vous pouvez commencer rapidement 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.
Linter un Dockerfile
Transmettez à Hadolint le chemin d'accès à un Dockerfile pour démarrer 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 RUN apt-get install du Dockerfile 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'images suggérées par Docker.
Les vérifications incluses couvrent l'utilisation d'utilisateurs finaux non root, référençant un chemin relatif dans un WORKDIR déclaration, en ajoutant 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 de 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, ce devraient être les premiers problèmes que vous résolvez.
Personnalisation de la configuration
Hadolint est configuré via un .hadolint.yaml dossier. 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 à 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ègle :
ignored: - DL3010 - DL3020
Si vous avez besoin de réduire la sévérité d'une règle sans la désactiver entièrement, utilisez le 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 nécessite que vous utilisiez COPY au lieu 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. Définition du 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 quitter 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. Lorsque les 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 son fonctionnement :
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 à celles présentes 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 supportés 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 forme de 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.