Volúmenes y bind mounts en Docker Compose: persistir MySQL y editar el código sin reconstruir

Hola, bienvenido. Un volumen guarda datos fuera del contenedor para que sobrevivan cuando lo borras, y es lo que necesita MySQL para no perder la base de datos. Un bind mount monta una carpeta de tu máquina dentro del contenedor, y es lo que necesitas para ver los cambios del código sin reconstruir la imagen. En Docker Compose, los 2 se declaran en la clave volumes de cada servicio.

Ya tenemos tasks respondiendo con sus 3 tareas, y ahora toca que no se pierdan. En esta lección vamos a comprobar que ahora mismo perdemos los datos de MySQL, a guardarlos en un volumen con nombre, a cargar el esquema de forma automática y a montar el código de tasks para editarlo en caliente, resolviendo de paso un problema de permisos que vas a ver en Linux y en WSL2.

Vamos a empezar por el problema. Ahora mismo tenemos 3 tareas en la base de datos:

Bajamos el stack y lo volvemos a levantar, que es algo que vas a hacer cada día:

Y repetimos la consulta:

La tabla ha desaparecido. ¿Qué ha pasado? docker compose down borra los contenedores, y como vimos en la lección de comandos básicos, lo que se escribe dentro de un contenedor se va con él. En realidad es un poco más sutil: la imagen de MySQL declara su carpeta de datos, /var/lib/mysql, como volumen. Cuando no le damos uno nuestro, Docker crea un volumen anónimo, con un nombre aleatorio, para cada contenedor nuevo. El del contenedor anterior sigue en tu disco, pero el contenedor nuevo no sabe nada de él y arranca con uno vacío. Puedes verlos con:

Cada uno de esos nombres largos es una base de datos de un contenedor de MySQL que ya no existe, y en tu máquina tendrás uno por cada vez que se ha creado el contenedor de MySQL. Ocupan unos 200 MB cada uno, aunque la base de datos esté casi vacía, y en la lección siguiente veremos cómo limpiarlos.