Cómo funciona Docker

Entender cómo funciona Docker significa entender qué ocurre entre el momento en el que escribes un comando y el momento en el que una aplicación queda ejecutándose dentro de un contenedor.

La idea clave es esta: no se crea una máquina virtual completa. Se prepara un proceso aislado, con una vista controlada del sistema de archivos, la red, los procesos visibles, los permisos y los recursos que puede consumir.

En esta lección vas a ver cómo funciona Docker por dentro: cliente, daemon, imágenes por capas, contenedores, runtime, red, volúmenes y kernel. El objetivo es que puedas depurar mejor y no usar la herramienta como una caja negra.

👉 Y recuerda, si quieres aprender más de Linux, pincha en este curso de Linux gratis.

🐳 Si quieres aprender más de Docker, pincha en este curso de Docker gratis.

El flujo real: de un comando a un proceso aislado

Cuando ejecutas un contenedor, no estás simplemente “abriendo una app”. Estás pidiendo al motor que prepare una imagen, cree una ejecución aislada y conecte filesystem, red, permisos y proceso principal.

Por ejemplo, esta orden pide levantar Nginx en segundo plano, darle un nombre y publicar el puerto 80 del contenedor en el puerto 8080 del host:

docker run -d --name web -p 8080:80 nginx:1.27-alpine

docker run -d --name web -p 8080:80 nginx:1.27-alpine

Lo importante para entender cómo funciona Docker no es memorizar una flecha detrás de otra, sino identificar qué pieza interviene en cada fase:

1. La CLI recibe tu orden: interpreta argumentos como nombre, puerto publicado e imagen.
2. El daemon recibe la petición: la orden llega al motor mediante su API local.
3. El motor resuelve la imagen: comprueba si existe en local y, si hace falta, la descarga del registro.
4. Se montan las capas: la imagen aporta capas de solo lectura y la ejecución recibe una capa escribible propia.
5. Se prepara el entorno: se configuran mounts, red, DNS, variables, límites, permisos y nombre del contenedor.
6. El runtime lanza el proceso: crea el proceso aislado usando mecanismos del kernel.
7. El proceso principal manda: si sigue vivo, el contenedor sigue vivo; si termina, el contenedor se detiene.

Ese flujo explica cómo funciona Docker de forma práctica. La CLI no hace todo el trabajo; el daemon coordina recursos y el runtime termina creando un proceso aislado usando capacidades del sistema operativo.

Visto así, cómo funciona Docker se entiende mejor como una cadena de responsabilidades: la orden describe una intención, el motor decide qué recursos hacen falta, el runtime crea el aislamiento y el kernel aplica las reglas. Si una parte falla, el síntoma suele aparecer en logs, red, permisos, mounts o proceso principal.

Cliente, daemon y runtime: quién hace qué

El cliente es la herramienta que usas en la terminal. Traduce tu orden en una petición hacia el daemon. El daemon mantiene el estado local: qué imágenes existen, qué contenedores están creados, qué redes hay y qué volúmenes están disponibles.

El runtime es la parte que baja al nivel del sistema operativo. Su trabajo es crear el proceso con el aislamiento necesario. En Linux esto se apoya en namespaces, cgroups, mounts, capabilities y perfiles de seguridad como seccomp o AppArmor, según configuración y distribución.

Imágenes: capas de solo lectura

Una imagen es una plantilla. No es un servidor ejecutándose ni un sistema completo arrancado. Es un conjunto de capas de solo lectura con archivos, dependencias, configuración y metadatos.

Las capas permiten reutilización. Si dos imágenes comparten una base, no hace falta descargar o guardar todo dos veces. Por eso una imagen bien construida acelera builds, reduce espacio y hace más predecible el despliegue.

Cuando se crea un contenedor, se usa esa plantilla y se añade una capa escribible encima. Lo que cambias dentro de la ejecución no modifica la imagen original. Si borras el contenedor, esa capa temporal puede desaparecer.

Para profundizar en esta parte tienes la guía de imágenes.

Contenedores: el proceso que se mantiene vivo

Un contenedor existe mientras su proceso principal existe. Si ese proceso termina, la ejecución se detiene. Esto es clave: no pienses en “encender una máquina”, piensa en lanzar un proceso con entorno controlado.

Por ejemplo, un servidor web se queda vivo porque su proceso principal sigue escuchando peticiones. Un comando que imprime algo y termina crea una ejecución breve y luego se detiene.

docker run -d --name web -p 8080:80 nginx:1.27-alpine
docker ps
docker stop web
docker rm web

docker run -d --name web -p 8080:80 nginx:1.27-alpine
docker ps
docker stop web
docker rm web

En ese ejemplo se crea un servicio web, se publica el puerto 80 del contenedor como 8080 en el host, se revisa su estado y después se limpia. Usar un tag concreto, como nginx:1.27-alpine, evita depender de latest en ejemplos que podrían acabar copiándose a entornos reales.

Namespaces y cgroups: aislamiento y límites

Los namespaces separan vistas del sistema. Gracias a ellos, un proceso puede tener su propia lista de procesos visibles, su propio hostname, su propia vista de red o su propio árbol de mounts.

Los cgroups controlan recursos. Sirven para limitar o medir CPU, memoria y otros recursos. Sin estos mecanismos, un proceso sería mucho más parecido a cualquier otro proceso del host.

Este punto también marca un límite: un contenedor no es una sandbox perfecta. Comparte kernel con el host en Linux, así que conviene cuidar permisos, usuario, capabilities, mounts sensibles y acceso al socket del daemon.

Red: bridge, puertos publicados y DNS interno

La red suele ser una de las partes que más confunde. Un contenedor puede tener su propia interfaz virtual y estar conectado a una red bridge. Desde dentro ve su entorno; desde fuera necesitas publicar puertos si quieres acceder desde el host.

EXPOSE en un Dockerfile solo documenta intención. No abre el puerto automáticamente. Para exponer un servicio hacia el host necesitas una regla de publicación de puertos o una configuración equivalente en Compose.

En redes creadas por el usuario, los servicios pueden resolverse por nombre. Por eso una aplicación puede conectar con una base de datos usando el nombre del servicio en vez de una IP fija.

Si quieres ampliar esta parte, revisa redes.

Volúmenes: separar datos y ejecución

La capa escribible del contenedor no debe ser tu estrategia de persistencia. Si guardas una base de datos ahí y luego recreas la ejecución, puedes perder información.

Los volúmenes separan los datos del ciclo de vida del contenedor. Así puedes borrar y recrear la ejecución sin perder archivos importantes. En bases de datos, uploads o datos de aplicaciones, esto es obligatorio.

Para profundizar, tienes la lección de volúmenes.

Errores comunes al entender la arquitectura

• Confundir contenedor con VM: en Linux comparte kernel con el host.
• Guardar datos en la capa temporal: para persistencia usa volúmenes.
• Creer que EXPOSE publica puertos: solo documenta; publicar requiere configuración de puertos.
• Usar latest sin control: fija versiones en entornos reales.
• Dar privilegios de más: evita privileged, mounts sensibles y acceso innecesario al socket.

Lecciones relacionadas del curso Docker

Si estás siguiendo el itinerario, usa este post como explicación de arquitectura y continúa con piezas más concretas del curso:

• Guía completa de Docker, como índice principal del curso.
• Docker Engine, para profundizar en el motor.
• Imágenes de Docker, para entender capas y construcción.
• Contenedor Docker, para entender la unidad de ejecución.
• Docker Compose, para trabajar con varios servicios.

Recursos oficiales para seguir contrastando conceptos:

• Overview oficial
• Engine oficial
• Referencia de Dockerfile
• Documentación de Compose

Ahora ya tienes una explicación real de cómo funciona Docker: una orden llega al daemon, se resuelve una imagen por capas, se crea una capa escribible, se configuran red y mounts, y el runtime lanza un proceso aislado sobre el kernel.

Quédate con esta idea: si entiendes esas piezas, dejas de memorizar comandos sueltos y empiezas a razonar los errores. Eso es lo que te permite avanzar hacia Compose, redes, volúmenes, seguridad y despliegues reales con mucha más confianza. En el fondo, aprender cómo funciona Docker es aprender a leer esa cadena completa, no solo a copiar comandos.