Docker Compose

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!

Configuración de contenedores

Ficheros de configuración

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.

En según qué escenarios es posible usar un volumen externo (por ejemplo, si los ficheros de configuración no están en el host) pero la idea es la misma.

Variables de entorno

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.

No todos los frameworks permiten usar variables de entorno con facilidad. Por ejemplo, en ASP.NET para crear aplicaciones web, existe el fichero web.config, que debe llamarse así y estar localizado en el directorio raíz de la aplicación web. En esos casos, por supuesto, es mejor la opción de usar un volumen o un bind mount.

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.

Podemos usar el modificador -e y especificar solo el nombre de una variable (docker run -e variable <nombre_imagen>). En este caso el contenedor tendrá la variable definida y su valor será el mismo que tenía dicha variable en el host al hacer el run. Existen muchas variables de entorno en los sistemas y de este modo no tendremos que definirlas explícitamente, pudiendo gestionarlas a nivel de sistema operativo para todos los contenedores.