Volúmenes y almacenamiento de la información en contenedores

Docker crea, en sus contenedores, un sistema de ficheros superpuesto u overlay. Este sistema de ficheros superpuesto puede usar diferentes mecanismos posibles, igual que en Linux hay varios tipos de sistemas de ficheros posibles; Docker usa drivers tales como overlay u overlay2 para estructurar la información dentro del contenedor y que esta información se almacene en el sistema de ficheros del anfitrión, pero generalmente usa un sistema copy on write que escribe en sistema de ficheros anfitrión cada vez que se produce una modificación en el sistema de ficheros superpuesto u overlay.

En general, salvo que haya algún problema crítico de prestaciones, es mejor usar el driver por omisión; el que se use dependerá de la implementación de Docker (CE o EE) y de la versión del kernel. En esta página se indica como configurar el driver que se quiere usar, para lo que hay que cambiar la configuración del daemon de Docker. En general, sin embargo, es suficiente con usar el driver por omisión.

Por otro lado, Docker introduce el concepto de volúmenes; son sistemas de ficheros gestionados por el propio Docker y que pueden compartirse entre diferentes contenedores. Se crea usando la suborden volume create

sudo docker volume create log

Igual que un contenedor Docker es algo así como un proceso con esteroides, un volumen de Docker es una especie de disco transportable, que almacena información y que puedes usar para transportar información entre contenedores y entre estos y el anfitrión.

Y de la misma forma, la arquitectura de acceso a datos de las aplicaciones basadas en Docker varían. Por ejemplo, no vamos a tener una aplicación monolítica que escriba en el log, lo analice y lo lea, sino diferentes contenedores que interaccionarán no directamente, sino a través de este contenedor de almacenamiento.

Por ejemplo, podemos usar un volumen para montar el directorio /app de contenedores basados en diferentes sistemas operativos, de forma que podamos probar una aplicación determinada en los mismos. Hagamos

docker volume create benchmark && docker pull fedora && docker run -it --rm -v benchmark:/app fedora /bin/bash

La primera sentencia usa la suborden create para crear un volumen que vamos a llamar benchmark. Tras pre-descargar Fedora, ejecutamos en la última orden un intérprete. Con -v benchmark:/app es como convertimos el volumen externo creado en un directorio, /app, del contenedor sobre el que vamos a ejecutar dicho benchmark. Una vez dentro, se puede crear un minibenchmark usando las propias órdenes de los diferentes sistemas operativos, que diga por ejemplo el número de ficheros ls -R / | wc y escriba el resultado en el mismo /app.

time ls -R / | wc > result-uname -m-uname -s.dat

Una vez hecho eso, puedes ejecutar ese programa en cualquier distro, de esta forma:

time docker run -it --rm -v benchmark:/app fedora sh /app/bm.sh 0,04s user 0,02s system 6% cpu 1,045 total

time docker run -it --rm -v benchmark:/app debian sh /app/bm.sh 0,04s user 0,01s system 5% cpu 0,872 total

time docker run -it --rm -v benchmark:/app centos sh /app/bm.sh 0,03s user 0,01s system 4% cpu 0,878 total

time docker run -it --rm -v benchmark:/app alpine sh /app/bm.sh 0,02s user 0,00s system 1% cpu 1,192 total

time docker run -it --rm -v benchmark:/app busybox sh /app/bm.sh 0,01s user 0,04s system 3% cpu 1,505 total

Aunque influye la cantidad de ficheros que haya en el mismo, busybox tarda la cuarta parte de lo que tarda Fedora.

El usar para comparar diferentes sistemas operativos en una aplicación determinada es sólo una de las utilidades que tiene el uso de volúmenes. En general, siempre que necesitemos compartir ficheros entre diferentes contenedores vamos a usar esta opción; hay también plugins que permiten trabajar con ficheros almacenados en la nube para que se puedan compartir entre contenedores ya desplegados.

La utilidad de los volúmenes, salvo los alojados en la nube, se limita a los despliegues locales; en general, cuando vayamos a desplegar diferentes contenedores lo que haremos será crear contenedores cuyo cometido sea precisamente ese, almacenar datos; en este caso, usando el mismo mecanismo, la opción -v del CLI de Docker, se podrán montar directorios pertenecientes a diferentes contenedores para que aparezcan localmente.