¡Hola! Hace tiempo que trabajo con Docker. La creación de Dockerfiles es una parte esencial del proceso, y quería compartir algunos consejos sobre cómo mejorarlo evitar las malas practicas.

¡No dejes que tu docker se hunda!

Best practices for writing Dockerfiles

Un Dockerfile es un archivo o documento de texto simple que incluye una serie de instrucciones que se necesitan ejecutar de manera consecutiva para cumplir con los procesos necesarios para la creación de una nueva imagen.

De manera que las imágenes en Dockerfile se crean a partir de un comando en específico denominado docker build, que se encargará de ofrecer las herramientas para que el sistema siga las instrucciones que el usuario haya indicado en la línea de comandos.

Es bueno tener un Dockerfile 100% funcional que siga las buenas prácticas. Por lo tanto, buscamos agregar una herramienta como lo es hadolint

hadolint es "Un linter de Dockerfile más inteligente que lo ayuda a crear imágenes de Docker de mejores prácticas".

Hadolint

Hadolint es una herramienta de código abierto que lo ayudará a asegurarse de que todos los Dockerfiles que cree sigan todas las mejores prácticas de Dockerfile disponibles de forma automatizada. Hadolint, como el número ya sugerido, es una herramienta de linter y, por eso, también puede ayudarlo a enseñarle todas estas mejores prácticas al crear Dockerfiles usted mismo. Ya hablamos de ello la optimización del tamaño de la imagen del contenedor , pero hoy vamos a intentar abarcarlo más en profundidad.

Repositorio oficial

Una forma rápida de usar

Ejecutarlo como Contenedor Docker

docker run --rm -i hadolint/hadolint < Dockerfile
# OR
docker run --rm -i ghcr.io/hadolint/hadolint < Dockerfile

Ejecutándolo dentro de VS Code

Como muchos linters, es esencial tenerlo cerca de su entorno de desarrollo; esta vez no es nada diferente. Nos gustaría tener las mejores prácticas de Dockerfile en relación con el editor mientras escribimos por dos razones principales:

Tan pronto como obtenga el problema, lo solucionará más rápido para que el código siempre tenga una mejor calidad. Tan pronto como sepa del problema, no lo volverá a hacer en desarrollos más nuevos. Tendrá un Hadolint como parte de las Extensiones: Marketplace, y podrá instalarlo:

VS Code hadolint extension

¿Reglas de validación?

La validación sigue estas reglas: github.com/hadolint/hadolint#rules

Cómo personalizar la validación

Podemos personalizar la validación creando el .hadolint.yaml https://github.com/hadolint/hadolint#configure

No todas las reglas son útiles para mí, así que agreguemos un archivo de configuración para especificar las reglas de pelusa ignoradas. Primero, creamos .hadolint.yaml en la raíz y agregamos algunas reglas. En nuestro caso, agreguemos la regla para ignorar las advertencias actuales (DL3008, DL3015).

ignored:
  - DL3008
  - DL3015

¡Una vez que lo guardamos, ya no vemos las advertencias anteriores en nuestro Dockerfile!

Integrando en Herramientas de CI/CD

Hay varios ejemplos de cómo usarlo hadolint https://github.com/hadolint/hadolint/blob/master/docs/INTEGRATION.md

Ejemplo:

¿Cómo agregarlo a su archivo .gitlab-ci.yml?

Mientras buscaba para ver si se habían agregado nuevas funciones desde la última vez que revisé, me sorprendió gratamente ver que los colaboradores agregaron una nueva forma de usar la herramienta al proporcionar la receta para usar en GitLab :

# To update hadolint/hadolint version
# https://hub.docker.com/r/hadolint/hadolint/tags?page=1&ordering=last_updated
lint:hadolint:
  image: hadolint/hadolint
  only:
    refs:
      - branches
    variables:
      - $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH
  script: hadolint Dockerfile
  stage: tests

Personalmente, encontré esta manera más limpia que ejecutar el docker run --rm -i hadolint/hadolint < Dockerfilecomando, así que decido escribir esta pequeña publicación para celebrar esta nueva funcionalidad y compartir esta increíble herramienta a mi alrededor.

lint:hadolint:
  script: docker run --rm -i hadolint/hadolint < Dockerfile
  stage: tests

Ejemplo de un Dockerfile con malas practicas:

Donde hay mucha repetición de instrucciones RUN, por lo que podemos agruparlos para apuntar a las buenas practicas

Aplicación Python

Como lo mejoramos, apuntamos a las mejoras de especificar las versiones de las librerias en el caso de python o definirlos en un requirements.txt

El archivo requirements.txt permite automatizar la instalación de paquetes Python y por lo tanto agilizar esta parte del proceso de desarrollo de software.

Si apuntamos a las buenas practicas

En el caso de usarlo en alguna herramienta de CICD podemos evaluar en un stage de test nos ayudaria a que nuestros dev siempre esten cumpliendo las buenas practicas.

VIDEO: