Notas del curso Docker a fondo e Introducción a Kubernetes: aplicaciones basadas en contenedores

Hasta ahora hemos visto cómo gestionar nuestras imágenes, así como crear imágenes nuevas y contenedores. Pero, por ahora hemos estado en escenarios con un solo contenedor. Tampoco hemos hablado sobre la manera de configurar contenedores más allá de usar la sentencia ENV en el Dockerfile.

En este módulo aprenderemos:

• A configurar contenedores: distintas configuraciones a distintos contenedores de la misma imagen
• El comando docker compose (conocido generalmente como “Compose” a secas)
• Cómo usar compose en escenarios de un solo contenedor

En este módulo se asume ya fluidez en todos los aspectos explicados hasta ahora, así que no ¡dudes en repasar los módulos anteriores en cualquier momento!

Tradicionalmente para parametrizar el funcionamiento de las aplicaciones se han usado los ficheros de configuración. Esa técnica es posible aplicarla en Docker. Lo único que debemos tener presente es que debemos evitar que el fichero de configuración forme parte de la imagen. Es decir, debemos evitar que se incluya en la imagen usando las sentencias COPY o ADD del Dockerfile.

¿Por qué es mala idea que el fichero de configuración forme parte de la imagen?

Pues porque entonces todos los contenedores creados a partir de dicha imagen tendrían la misma configuración. Supón que la configuración es una cadena de conexión a una base de datos: dicha cadena de conexión será distinta según el entorno en el que estés ejecutando el contenedor (desarrollo, pruebas, preproducción, …). Si la configuración la tienes en la imagen vas a necesitar imágenes distintas por entorno y eso no es muy buena idea.

La solución pasa por usar un bind mount: tener los ficheros de configuración en el host y usar un bind mount para mapear la carpeta con los ficheros de configuración en un directorio determinado del contenedor. De esta manera, un mismo host puede contener ficheros de configuración de distintos entornos (en distintos directorios) y cuando se ejecutan los contenedores utilizar el bind mount para montar un directorio u otro en el contenedor, según las necesidades. Eso permite ejecutar contenedores con distintas configuraciones en el mismo host.

La idea es que la configuración no está en la imagen, sino que sea proporcionada por el entorno. La configuración forma parte del entorno y no de la imagen. Usar un bind mount es la manera de que el entorno (el host) proporcione ficheros de configuración al contenedor.

Dado que la configuración debe ser proporcionada por el entorno, lo ideal es que dicha configuración forme parte del propio entorno. Y para ello lo mejor es usar “variables de entorno”. Las variables de entorno son la forma preferida de configurar contenedores.

Vamos a ver cómo pasar una variable de entorno a un contenedor…

Con la sentencia ENV del archivo Dockerfile creábamos una variable de entorno a nivel de imagen (para todos los contenedores creados a partir de esta imagen). Pero eso no es lo que queremos ahora. Ahora necesitamos crear una variable de entorno cuyo valor pueda ser distinto para cada contenedor que ejecutemos.

De nuevo es el comando docker run el que nos permite hacer eso. Mediante el modificador -e podemos establecer una variable de entorno:

docker run -e "variable=valor" <nombre_imagen>

El contenedor se inicia con la variable de entorno variable establecida al valor valor.

Podemos establecer tantas variables de entorno como necesitemos utilizando varias veces el modificador -e.

Docker Compose es un comando cuyo principal propósito es definir y ejecutar aplicaciones multicontenedor.

El uso de Compose en escenarios multicontenedor lo veremos en el siguiente módulo, pero Compose es de aplicación también en escenarios con un solo contenedor, que es lo que estudiaremos ahora.

Docker compose forma parte de la herramienta de Docker. Es un comando más, tal y como lo son docker ps o docker run, por poner dos ejemplos. Pero eso no siempre fue así. Antiguamente era una aplicación que se instalaba y se descargaba aparte. Era por lo tanto un ejecutable distinto cuyo nombre era docker-compose (con un guion en medio).

Si tienes Docker for Windows o Docker for Mac ya tienes Docker Compose instalado en tu sistema. No es así en el caso de que uses una distro de Linux. Por suerte la instalación de Compose es trivial, ya que basta tan solo con descargarte el ejecutable. Para más información sigue los pasos indicados en su página web.

Docker compose tiene su propia versión (con un número distinto de la versión de Docker, por temas históricos), que puedes verificar con el comando:

docker compose --version

El fichero Compose es el fichero que define una aplicación. Recuerda que, si Docker se encarga de la creación, ejecución y gestión de contenedores, Compose se encarga de la definición de aplicaciones. Por “aplicación” en este contexto entendemos uno o varios contenedores trabajando conjuntamente: eso significa que deben levantarse, pararse y configurarse de forma coordinada.

Este fichero es un fichero en formato YAML que describe:

• Qué contenedores forman parte de la aplicación
• Qué configuración tiene cada contenedor
• Qué puertos exponen y cómo se mapean
• Cómo se pueden comunicar entre ellos

Por defecto dicho fichero toma el nombre de docker-compose.yml, aunque se pueden usar otros nombres si se desea.

Veamos un ejemplo de un fichero Compose que nos defina una aplicación que se compone de un solo contenedor con la imagen dockercampusmvp/nodejs-sample:

version: '3'

services:
  sample-api:
    image: dockercampusmvp/nodejs-sample
    ports:
      - "9000:3000"

Crea un directorio en tu máquina y copia el contenido anterior en un fichero llamado docker-compose.yml. Luego desde este mismo directorio usa el comando:

docker compose up

Esto debería:

• Descargarte la imagen dockercampusmvp/nodejs-sample (si no la tienes ya)
• Poner en marcha un contenedor de dicha imagen

Al final deberías ver una salida parecida a esta (y la línea de comandos estará esperando):

Recreating testcompose_sample-api_1 ...
Recreating testcompose_sample-api_1 ... done
Attaching to testcompose_sample-api-api_1
sample-api_1  | Ejemplo del curso corriendo en puerto 3000

Y si ahora navegas a http://localhost:9000/ping deberías recibir el “pong” de respuesta, verificando que el contenedor está en marcha. ¡Felicidades! ¡Has puesto en marcha tu primera aplicación usando Compose!

También puedes, por supuesto, usar docker ps para ver el contenedor creado.

Al principio del fichero Compose se define una versión (por ejemplo, version: '3'). No confundas la versión de fichero Compose con la versión de docker-compose. Por supuesto que hay una correlación, en tanto que es necesaria una versión mínima de Docker Compose para poder ejecutar ficheros Compose de una determinada versión.

El contenedor que se ha creado con el comando docker compose up tiene su puerto 3000 mapeado al puerto 9000 del host. Eso es porque así lo hemos especificado en el fichero docker-compose.yml:

    ports:
      - "9000:3000"

La sección ports permite especificar una lista de mapeos de puertos (en el formato clásico <puerto-host>:<puerto-contenedor>). Si el contenedor abre más de un puerto que deseas mapear, simplemente agrega más entradas a la lista.

Aunque podemos usar el modificador -e de docker run para pasar configuración a nuestros contenedores, esto se vuelve muy pesado, en especial cuando queremos tener configuraciones distintas para entornos distintos. Por supuesto, siempre nos podemos crear nuestros ficheros de shell (.sh o .cmd) para lanzar los contenedores, pero para estos casos Compose ofrece una solución mejor.

Y es que mediante Compose podemos pasar la configuración (variables de entorno) que deseemos a nuestros contenedores.

Vamos a partir del fichero de Compose que teníamos en la lección anterior:

version: '3'

services:
  sample-api:
    image: dockercampusmvp/nodejs-sample
    ports:
      - "9000:3000"

Este fichero define una aplicación que tiene un servicio (sample-api) y nos especifica la imagen del contenedor y en este caso el mapeo de puertos (el 3000 del contenedor al 9000 del host).

Del mismo modo que hay una sección ports, existe una sección llamada environment cuyo objetivo es contener la configuración en variables de entorno del contenedor. Dicha sección contiene una lista en formato variable=valor:

version: '3'

services:
  sample-api:
    image: dockercampusmvp/nodejs-sample
    ports:
      - "9000:80"
    environment:
      - PORT=80

En este caso estamos estableciendo la variable de entorno PORT con el valor de 80. Así, el contenedor escuchará por su puerto 80, en lugar del 3000 que usa por defecto. Observa cómo cambiamos también el mapeo de puertos.

Por supuesto, puedes agregar tantas entradas a environment como necesites, para especificar todas las variables de entorno que sean necesarias.

Si ahora ejecutas el comando docker compose up la salida será parecida a:

Recreating untitledproject_sample-api_1 ...
Recreating untitledproject_sample-api_1 ... done
Attaching to untitledproject_sample-api_1
sample-api_1  | Ejemplo del curso corriendo en puerto 80

Observa como el contenedor indica que está corriendo en el puerto 80. Y si navegas a http://localhost:9000/ping deberías recibir el pong de respuesta.

En el fichero Compose puedes definir volúmenes a usar, usando la sección volumes. Por ejemplo, para definir un bind mount en un determinado contenedor usaríamos la siguiente sintaxis:

services:
  my-service:
    image: my-image-name
    volumes:
      - /home/data:/var/lib/data

En este caso se crea un bind mount donde el directorio del host /home/data se monta en el directorio /var/lib/data del sistema de ficheros del contenedor.

Para usar volúmenes se emplea esta otra sintaxis:

services:
  my-service:
    image: my-image-name
    volumes:
      - data-volume:/var/lib/data
volumes:
  data-volume:

Observa como hay dos secciones volumes: una global donde definimos el volumen (data-volume) y otra a nivel de servicio donde asignamos el volumen a un directorio del sistema de ficheros del contenedor.

Compose creará el volumen si no existe. Para evitar que Compose cree el volumen y dé error si este no existe, se puedes indicar que es un volumen externo:

volumes:
  data-volume:
     external: true