Cómo funciona Docker: construir, distribuir, ejecutar
Cómo funciona Docker, explicado en un lienzo interactivo: del Dockerfile a la imagen, del registro al contenedor y los namespaces y cgroups que aíslan un proceso.
Docker empaqueta una aplicación y todo lo que necesita en una imagen y después la ejecuta como un contenedor: un proceso aislado que se comporta igual en cualquier máquina que tenga un motor de Docker.
Cómo funciona Docker: construir, distribuir, ejecutar
El lienzo interactivo de FlowJam de esta explicación: cada carril, cada fila y cada flecha de arriba forma parte de un diagrama real de QueryChart que puedes abrir y editar.
Cómo leer este diagrama
- Lee las tres columnas de izquierda a derecha: Construcción, Distribución y Ejecución.
- La banda inferior, «Sistema operativo anfitrión», es el cimiento: el contenedor que cierra el flujo se ejecuta SOBRE él y comparte su kernel.
- La imagen es el artefacto que todo lo demás mueve de un lado a otro: del motor de Docker al registro de imágenes y de vuelta al runtime.
Construir la imagen
«El desarrollador escribe un Dockerfile que describe la aplicación» es una receta, no un resultado: una imagen base, las dependencias que instalar, los archivos que copiar y el comando que ejecutar. «docker build empaqueta la aplicación y sus dependencias» ejecuta la receta, y «La build produce una imagen: una instantánea de solo lectura» es la salida: un artefacto inmutable en un sistema de archivos por capas. La reproducibilidad es lo importante: el mismo Dockerfile produce la misma imagen en cualquier máquina.
Distribuir el artefacto
«La imagen se sube a un registro de imágenes, o se descarga de él» es el acto de «Distribución». El registro es la red de distribución de imágenes: uno privado para tu equipo, uno público para las imágenes base. La imagen no cambia durante la distribución, y eso es lo que hace determinista el despliegue: lo que probaste es exactamente lo que ejecutas.
Ejecutar el contenedor
«docker run arranca un contenedor a partir de la imagen» cruza del motor de Docker al grupo «Runtime de contenedores». «El contenedor se aísla con namespaces y cgroups» es el mecanismo de aislamiento: los namespaces dan al proceso su propia vista del sistema de archivos, la red y la tabla de procesos, y los cgroups limitan su CPU y su memoria. «El contenedor comparte el kernel del anfitrión pero tiene su propio sistema de archivos» está en la banda «Sistema operativo anfitrión» para hacer explícito el contraste con una máquina virtual, y «El proceso de la aplicación se ejecuta igual en todas partes» es la recompensa que justifica toda la pila.
Relaciones clave y conclusiones
- Una imagen es una instantánea de solo lectura; un contenedor es una instancia suya en ejecución.
- Los contenedores comparten el kernel del anfitrión y fingen el aislamiento con namespaces, y por eso arrancan en segundos donde una máquina virtual tarda minutos.
- Los cgroups limitan lo que un contenedor puede consumir, así que un vecino ruidoso no puede dejar sin recursos al anfitrión.
- La inmutabilidad de la imagen es lo que hace cierto el «se ejecuta igual en todas partes».
- Docker aporta el empaquetado y el runtime; los orquestadores como Kubernetes gestionan muchos contenedores repartidos entre anfitriones.
Cuándo usar este diagrama
- Explicar a un desarrollador por qué funciona Docker y en qué se diferencia un contenedor de una máquina virtual.
- Formar a un equipo en el modelo construir-distribuir-ejecutar antes de que escriba su primer Dockerfile.
- Anclar una conversación sobre la deriva de entornos: por qué «funciona en mi máquina» deja de aplicarse.
Cómo funciona
Anota los pasos de tu Dockerfile
En la caja del Dockerfile, enumera las capas reales de tu build —imagen base, instalación de dependencias, copia del código fuente, comando de arranque— para que la receta sea concreta.
Nombra tus registros de imágenes
Renombra el paso del registro con tus registros reales (un ECR privado, una imagen pública) y anota qué imágenes subes y cuáles descargas.
Añade las cajas de red y de volumen
Amplía la columna de ejecución con cómo se comunican tus contenedores —una red bridge— y dónde vive el estado —un volumen—, porque son las dos partes que más se le escapan a quien empieza.
Enlaza con la orquestación
Si usas Kubernetes, añade una nota que vaya del contenedor en ejecución al diagrama de Kubernetes y a lo que cambia el kubelet sobre dónde se ejecuta el contenedor.
Preguntas frecuentes
¿Cuál es la diferencia entre un contenedor y una máquina virtual?
Una máquina virtual virtualiza el hardware: lleva un sistema operativo completo y un hipervisor media en todo, lo que la hace pesada y lenta de arrancar. Un contenedor virtualiza el sistema operativo: comparte el kernel del anfitrión y usa namespaces para el aislamiento y cgroups para los límites de recursos. Por eso los contenedores arrancan en segundos y son mucho más ligeros; a cambio, todos los contenedores de un anfitrión comparten el kernel de ese anfitrión.
¿Qué es una imagen frente a un contenedor?
Una imagen es el artefacto estático: una instantánea de solo lectura de la aplicación y sus dependencias, construida a partir del Dockerfile. Un contenedor es esa imagen en movimiento: un proceso en ejecución con una capa de escritura encima. Construyes una imagen una vez y puedes arrancar miles de contenedores a partir de ella, cada uno aislado de los demás.
¿Cómo aísla Docker los contenedores?
Con dos funciones del kernel de Linux. Los namespaces dan a cada contenedor su propia vista del sistema —su sistema de archivos, su pila de red, su tabla de procesos y sus identificadores de usuario—, de modo que parece una máquina propia. Los cgroups (grupos de control) limitan y miden los recursos: acotan cuánta CPU, memoria y E/S puede consumir un contenedor para que uno no tumbe a sus vecinos.
¿Por qué Docker hace portables las aplicaciones?
Porque la imagen agrupa la aplicación con su runtime, sus bibliotecas y su configuración: todo excepto el kernel. Allí donde exista un motor de Docker, la imagen se ejecuta igual, así que la distancia entre el portátil de un desarrollador, un runner de CI y un servidor de producción se reduce a la configuración que se deja fuera de la imagen a propósito.
Edita este diagrama en QueryChart (FlowJam)
Abre ese mismo lienzo de Docker como tu propio diagrama, renombra los grupos con tu stack y anota tu pipeline de imágenes.