Docker desde cero: imágenes, contenedores y volúmenes

Docker es una herramienta que empaqueta una aplicación junto con todo lo que necesita para funcionar —su código, sus dependencias, sus librerías y su configuración— en una unidad que corre de la misma manera en cualquier máquina. Sirve para eliminar el clásico problema de que un programa funcione en la computadora de quien lo desarrolló pero falle en el servidor por diferencias de entorno, resumido en la frase «en mi máquina funciona». Con Docker, la aplicación lleva su entorno consigo, así que si funciona dentro del contenedor funcionará igual en la laptop del desarrollador, en el entorno de pruebas y en producción. Esto simplifica enormemente el despliegue, hace reproducibles los entornos y es la base de gran parte de las prácticas modernas de DevOps, incluidas la integración continua, el despliegue automatizado y la orquestación de aplicaciones a gran escala con herramientas como Kubernetes.

Una imagen es una plantilla inmóvil y de solo lectura que contiene la aplicación con todo su entorno, pero que no corre por sí sola: es como una receta o un molde ya preparado. Un contenedor es una instancia en ejecución de esa imagen, es decir, la aplicación efectivamente corriendo. La analogía más clara viene de la programación orientada a objetos: la imagen es como una clase, que define cómo son las cosas, y el contenedor es como un objeto, una instancia concreta creada a partir de esa clase. De una misma imagen se pueden arrancar muchos contenedores idénticos y aislados entre sí, lo que hace muy sencillo escalar una aplicación simplemente corriendo más copias. Las imágenes se descargan de registros como Docker Hub o se construyen a partir de un Dockerfile, mientras que los contenedores se crean, arrancan, detienen y borran a partir de esas imágenes según haga falta.

Es un archivo de texto que contiene la receta, paso a paso, para construir una imagen de Docker con tu propia aplicación. En él se indica de qué imagen base partir, qué dependencias instalar, qué archivos de código copiar dentro y qué comando debe ejecutarse cuando el contenedor arranque. Cada instrucción del Dockerfile genera una capa, y Docker reutiliza las capas que no cambiaron entre una construcción y otra, lo que acelera mucho las reconstrucciones cuando solo se modifica el código. A partir del Dockerfile, un comando de construcción arma la imagen, que luego puede subirse a un registro y desplegarse en cualquier servidor. Escribir bien el Dockerfile —partir de una imagen base pequeña, copiar las dependencias antes que el código para aprovechar la caché y no incluir archivos innecesarios— influye directamente en el tamaño de la imagen y en la velocidad tanto de construcción como de despliegue.

Porque un contenedor es efímero por diseño: está pensado para crearse y destruirse con facilidad, y cuando se borra, todo lo que se escribió dentro de él se pierde. Eso es una ventaja para la aplicación, que siempre arranca en un estado limpio y conocido, pero sería un desastre para los datos que deben conservarse, como el contenido de una base de datos, los archivos que suben los usuarios o los registros históricos. Los volúmenes resuelven esto: son un almacenamiento gestionado por Docker que vive fuera del contenedor, en el sistema anfitrión, y que se conecta al contenedor para que este lea y escriba ahí. Así, los datos permanecen aunque el contenedor se elimine y se vuelva a crear, por ejemplo al actualizar la aplicación a una versión nueva. Esta separación entre la aplicación sin estado y los datos con estado es fundamental, porque es lo que permite actualizar o reemplazar contenedores sin perder información.

No, y confundirlos es un malentendido habitual. Una máquina virtual emula un sistema operativo completo, con su propio núcleo corriendo sobre el sistema anfitrión, lo que la hace relativamente pesada en consumo de recursos y lenta de arrancar, aunque ofrece un aislamiento muy fuerte. Un contenedor de Docker, en cambio, no emula un sistema operativo entero: comparte el núcleo del sistema anfitrión y solo aísla la aplicación y su entorno inmediato. Como consecuencia, un contenedor ocupa mucho menos espacio, arranca en segundos y permite correr decenas de ellos en una máquina que apenas sostendría unas pocas máquinas virtuales. La contrapartida es que el aislamiento es menor y que todos los contenedores comparten el mismo núcleo, lo que hay que tener en cuenta en escenarios donde la separación estricta es un requisito de seguridad. En la práctica, ambas tecnologías conviven y muchas veces los contenedores corren dentro de máquinas virtuales.

En variables de entorno que se pasan al contenedor al ejecutarlo, o mediante un mecanismo de gestión de secretos, pero nunca escritas dentro de la imagen ni en el Dockerfile. La razón es que todo lo que se incluye en la imagen queda grabado de forma permanente en sus capas, y esas capas se pueden inspeccionar, de modo que un secreto escrito ahí queda expuesto a cualquiera que tenga acceso a la imagen, incluso si se «borra» en un paso posterior, porque la capa anterior sigue existiendo. Lo correcto es mantener la imagen genérica y sin credenciales, e inyectar los secretos en el momento de ejecutar el contenedor a través de variables de entorno o de un sistema de gestión de secretos, que además permite usar credenciales distintas en desarrollo, pruebas y producción con la misma imagen. Esta es exactamente la misma regla que se aplica al código fuente y a los pipelines: los secretos viven en un mecanismo aparte pensado para protegerlos, no dentro de lo que se versiona o se distribuye.