Saltar la navegación

6.2.1 Resumen de comandos Dockerfile

En el apartado anterior hemos descrito como construir nuevos contenedores  mediante la docker build y los ficheros Dockerfile pero, ¿qué son y qué contienen esos ficheros declarativos que me sirven para construir mis imágenes?.

Si queremos hacer una definición más o menos formal de estos ficheros podríamos decir que:

"Un fichero Dockerfile es un conjunto de instrucciones que serán ejecutadas de forma secuencial para construir una nueva imagen docker".

Cada una de estas instrucciones crea una nueva capa en la imagen que estamos creando. Si no ha habido cambios estas instrucciones  son cacheadas y la capa previamente creada usada. Esto me permite reusar capas entre imágenes que  están construidas de forma similar y basándose en las mismas imágenes de base. Esta estructura en forma de capas de las imágenes la podemos ver cuando ejecutamos la orden docker pull. Podemos apreciarlo en la siguiente imagen.

Capas de una imagen docker
Juan Diego Pérez Jiménez. Capas de una imagen docker (Dominio público)

Cada una de las líneas que nos aparecen en el proceso de descarga es una de las capas que conforman la imagen. En este caso tres capas, cada una con su identificador.

¿ Y las instrucciones que puede contener el fichero Dockerfile?. Son varias que explicaremos posteriormente, pero de manera general podemos decir que dichos ficheros tienen la siguiente estructura.

Estructura de los ficheros Dockerfile
Estructura de los ficheros Dockerfile. Estructura de los ficheros Dockerfile (Dominio público)

ORDENES FICHEROS DOCKERFILE

Las órdenes más comunes son:

  • FROM: Sirve para especificar la imagen sobre la que voy a construir la mía. Ejemplo: FROM php:7.4-apache

  • LABEL: Sirve para añadir metadatos a la imagen mediante clave=valor. Ejemplo: LABEL company=iesalixar

  • COPY: Para copiar ficheros desde mi equipo a la imagen. Esos ficheros deben estar en el mismo contexto (carpeta o repositorio). Su sintaxis es COPY [--chown=<usuario>:<grupo>] src dest. Por ejemplo: COPY --chown=www-data:www-data myapp /var/www/html

  • ADD: Es similar a COPY pero tiene funcionalidades adicionales como especificar URLs  y tratar archivos comprimidos.

  • RUN: Ejecuta una orden creando una nueva capa. Su sintaxis es RUN orden / RUN ["orden","param1","param2"]. Ejemplo: RUN apt update && apt install -y git. En este caso es muy importante que pongamos la opción -y porque en el proceso de construcción no puede haber interacción con el usuario.

  • WORKDIR: Establece el directorio de trabajo dentro de la imagen que estoy creando para posteriormente usar las órdenes RUN,COPY,ADD,CMD o ENTRYPOINT. Ejemplo: WORKDIR /usr/local/apache/htdocs

  • EXPOSE: Nos da información acerca de qué puertos tendrá abiertos el contenedor cuando se cree uno en base a la imagen que estamos creando. Es meramente informativo.  Ejemplo: EXPOSE 80

  • USER: Para especificar (por nombre o UID/GID) el usuario de trabajo para todas las órdenes RUN,CMD Y ENTRYPOINT posteriores. Ejemplos: USER jenkins / USER 1001:10001

  • ARG: Para definir variables para las cuales los usuarios pueden especificar valores a la hora de hacer el proceso de build mediante el flag --build-arg. Su sintaxis es ARG nombre_variable o ARG nombre_variable=valor_por_defecto. Posteriormente esa variable se puede usar en el resto de la órdenes de la siguiente manera $nombre_variable. Ejemplo: ARG usuario=www-data. NO SE PUEDE USAR EN ENTRYPOINT Y CMD

  • ENV: Para establecer variables de entorno dentro del contenedor. Puede ser usado posteriormente en las órdenes RUN añadiendo $ delante de el nombre de la variable de entorno. Ejemplo: ENV WEB_DOCUMENT_ROOT=/var/www/html  NO  SE PUEDE USAR EN ENTRYPOINT Y CMD

  • ENTRYPOINT: Para establecer el ejecutable que se lanza siempre  cuando se crea el contenedor  con docker run, salvo que se especifique expresamente algo diferente con el flag --entrypoint. Su síntaxis es la siguiente: ENTRYPOINT <command> / ENTRYPOINT ["executable","param1","param2"]. Ejemplo: ENTRYPOINT ["service","apache2","start"]

  • CMD: Para establecer el ejecutable por defecto (salvo que se sobreescriba desde la order docker run) o para especificar parámetros para un ENTRYPOINT. Si tengo varios sólo se ejecuta el último. Su sintaxis es CMD param1 param2 / CMD ["param1","param2"] / CMD["command","param1"]. Ejemplo: CMD [“-c” “/etc/nginx.conf”]  / ENTRYPOINT [“nginx”].

FICHERO .dockerignore

Antes de que se ejecuten las órdenes ADD y COPY de los Dockerfile el proceso de construcción de docker build mira si en el contexto de la construcción  existe un fichero .dockerignore. El funcionamiento de este tipo de ficheros es análogo al funcionamiento de los ficheros .gitignore que excluyen una serie de ficheros del control de versiones.

EN ESTE CASO LOS ARCHIVOS QUE SE RECOJAN EN EL FICHERO .DOCKERIGNORE NO PASARÁN A LA IMAGEN EN EL PROCESO DE CONSTRUCCIÓN DE LA IMAGEN.

Algunos ejemplos de ficheros .dockerignore.

Un ejemplo genérico:

# Esa carpeta app tiene el contenido de un repositorio

#Excluyo la carpeta .git

app/.git

#Excluyo el fichero .gitignore

app/.gitignore

#Excluyo todos los archivos dentro de la carpeta log pero dejo la carpeta

app/log/*

#Excluyo todos los archivos dentro de la carpeta tmp pero dejo la carpeta.

app/tmp/*

#Excluyo el archivo README.md

app/README.md

Un ejemplo para una aplicación node:

# Esa carpeta nodeapp tiene el contenido de un repositorio

#Excluyo la carpeta .git

nodeapp/.git

#Excluyo el fichero .gitignore

nodeapp/.gitignore

#Excluyo la carpeta node_modules. Eso me obliga a hacer npm install al arrancar el contenedor

nodeapp/node_modules

#Excluyo el fichero creado por el editor de código

.vscode

Para más información sobre los comodines y reglas que puedo tener en un fichero .dockerignore os dejo este enlace: https://docs.docker.com/engine/reference/builder/#dockerignore-file

Creado con eXeLearning (Ventana nueva)