Los Dockerfiles definen el contenido de las imágenes de Docker como un conjunto de instrucciones en un archivo de texto. La sintaxis de Dockerfile es generalmente sencilla, pero hay algunos errores que se deben evitar. Adherirse a las mejores prácticas al escribir Dockerfiles complejos en una configuración de equipo puede ser complicado a menos que esté validando automáticamente el contenido de su archivo.
Hadolint es un filtro de Dockerfile que puede detectar problemas comunes por usted. Utiliza un árbol de sintaxis abstracta (AST) para analizar su Dockerfile contra conjuntos de reglas predefinidos. Hadolint también incorpora ShellCheck para que pueda borrar los scripts de shell en el RUN de su Dockerfile. instrucciones también.
Cómo empezar
Hadolint se distribuye en múltiples formatos. Puede comenzar rápidamente descargando el último binario precompilado para su sistema operativo desde la página de lanzamientos de GitHub del proyecto.
Hadolint también tiene su propia imagen Docker, hadolint/hadolint , si prefiere no usar el binario directamente. Como opción final, puede acceder a Hadolint a través de la web para experimentar.
Linting de un Dockerfile
Pase a Hadolint la ruta a un Dockerfile para iniciar un nuevo escaneo:
hadolint Dockerfile
Si está utilizando la versión Dockerizada, es más fácil canalizar el contenido de su archivo a un contenedor Hadolint:
docker run --rm -i hadolint/hadolint < Dockerfile
Los resultados del escaneo se mostrarán en su terminal. En este ejemplo, Hadolint sugiere que RUN apt-get install de Dockerfile La declaración no es segura ya que no especifica versiones explícitas del paquete. El contenido de su imagen podría cambiar entre compilaciones, lo que podría crear problemas confusos.
¿Qué busca Hadolint?
Hadolint tiene docenas de reglas integradas que verifican problemas comunes de configuración y seguridad. El linter tiene como objetivo hacer que sus Dockerfiles cumplan con las mejores prácticas de creación de imágenes sugeridas por Docker.
Las comprobaciones incluidas cubren el uso de usuarios finales no root, haciendo referencia a una ruta relativa en un WORKDIR declaración, agregando múltiples HEALTHCHECK instrucciones, y no usar etiquetas y versiones fijadas explícitamente. Como Hadolint también hereda el conjunto de reglas de ShellCheck, mostrará problemas comunes de secuencias de comandos de Bash que esa herramienta también identifica.
Las reglas se identifican como números con el prefijo HL o SC . HL las reglas son parte de Hadolint mientras que SC las entradas provienen de ShellCheck. A cada verificación se le asigna una gravedad desde Error hasta Información. Si obtiene errores en los resultados de su análisis, esos deberían ser los primeros problemas que resuelva.
Configuración personalizada
Hadolint se configura mediante un .hadolint.yaml expediente. Buscará múltiples ubicaciones, incluido su trabajo, .config y directorios de inicio. Solo se usa el primer archivo encontrado; no hay fusión entre ubicaciones.
El archivo de configuración le permite personalizar sus escaneos ignorando las reglas y cambiando su gravedad. Si bien el conjunto de reglas predeterminado cubre las mejores prácticas recomendadas, es posible que algunas comprobaciones no se apliquen en su entorno. Confirmar un .hadolint.yaml El archivo junto con su Dockerfile le permite personalizar los escaneos de Hadolint en consecuencia. La mayoría de los campos del archivo de configuración también se admiten como indicadores de la CLI y variables de entorno.
Las reglas están deshabilitadas por ignored campo. Esta debería ser una lista de ID de reglas:
ignored: - DL3010 - DL3020
Si necesita reducir la gravedad de una regla sin deshabilitarla por completo, use la override clave en su lugar. Esto también le permite promover un problema de baja gravedad a un nivel superior. Úselo si desea poner mayor énfasis en un tema en particular.
override:
warning:
- DL3020
Esto degrada la regla DL3020 de su nivel predeterminado de "error" a la "advertencia" menos grave. Esta regla requiere que uses COPY en lugar de ADD al hacer referencia a archivos y carpetas en su contexto de compilación.
También puede ajustar el nivel de gravedad global. Configuración del failure-threshold El campo indica a Hadolint que salga con un estado de falla si alguna prueba informa un error en el nivel de gravedad dado:
failure-threshold: warning
Esta instrucción significa que el análisis de Hadolint fallará si hay un error o una advertencia en su salida.
Puede deshabilitar la salida con un código de falla usando el no-fail: true opción de configuración o --no-fail bandera CLI. Esto le indicará a Hadolint que salga con un 0 código independientemente del resultado real de la prueba. Puede ser útil si desea incluir Hadolint como un trabajo sin bloqueo en una canalización de CI.
Registros de confianza
Otro uso del archivo de configuración es definir registros confiables a los que desea poder hacer referencia en sus Dockerfiles. Cuando trustedRegistries está establecido, Hadolint le avisará cuando se utilice una imagen de otro registro:
trustedRegistries: - docker.io - docker-registry.example.com
Esquemas de etiquetas
Hadolint también ofrece desforrado básico de etiquetas. Esto le permite hacer cumplir las etiquetas agregadas a su imagen por Dockerfile LABEL las instrucciones cumplen con las restricciones especificadas. He aquí un ejemplo de cómo funciona:
label-schema: notes: text app-version: semver built-at: rfc3339
Este fragmento de configuración define tipos de datos para cuatro etiquetas que puede usar en su Dockerfile. notes se declara como un campo de texto arbitrario mientras que app-version debe ser un identificador de versión compatible con semver. built-at está marcado como una cadena de fecha y hora RFC-3339. Puede obtener la lista completa de tipos admitidos en los documentos de Hadolint.
Hadolint permite el uso de etiquetas que no figuran en su esquema. Puede deshabilitar esto y restringir LABEL instrucciones solo para aquellos presentes en el esquema configurando strict-labels: true o usando --strict-labels bandera.
Formatos de salida
Se admiten varios formatos de salida a través del format opción o --format bandera. El valor predeterminado es tty que emite una salida coloreada a su terminal. Los colores se pueden desactivar con --no-color bandera.
Están disponibles los siguientes formateadores alternativos:
json– Proporciona la lista de problemas detectados como una estructura JSON detallada que es ideal para usar con sus propios scripts.checkstyle– Un informe compatible con Checkstyle.codeclimate– Un informe compatible con Code Climate.gitlab_codeclimate– Variación del informe Code Climate que funciona con las funciones de calidad de código integradas de GitLab. Esto le permite ver los errores como un widget en las páginas de solicitud de combinación cuando ejecuta Hadolint con GitLab CI.
Estos formatos de salida son ideales para usar Hadolint mediante programación o como parte de una canalización de CI.
Resumen
Hadolint automatiza la detección de problemas de Dockerfile. Esto ayuda a que sus imágenes de Docker se adhieran a las mejores prácticas y estándares organizacionales. La configuración predeterminada es un buen punto de partida, pero puede personalizarla para que se ajuste a sus necesidades reclasificando y deshabilitando las reglas.
Debería considerar integrar Hadolint con su herramienta de CI para obtener informes instantáneos a medida que se confirman los cambios de Dockerfile. Esto acelera la revisión del código al brindarles a los desarrolladores una visibilidad inmediata de los problemas. También puede usar la herramienta localmente mientras trabaja a través de extensiones de editor compatibles con la comunidad, lo que brinda un ciclo de comentarios aún más corto.