Docker Engine utiliza varios componentes para convertir una orden en un contenedor en ejecución. El cliente Docker se comunica con el daemon mediante la Docker API; el daemon coordina la operación y delega el ciclo de vida en containerd. En la configuración habitual, containerd utiliza runc para crear el proceso aislado según la especificación OCI. En esta lección recorreremos la arquitectura Docker Engine y la función de cada pieza.
👉 Y recuerda, si quieres aprender más de Linux, visita el curso de Linux gratis.
🐳 Si quieres aprender más de Docker, visita el curso de Docker gratis.
Arquitectura Docker Engine: dockerd, containerd y runc
La arquitectura Docker Engine separa la interfaz que recibe las órdenes de los servicios que administran imágenes y procesos. Así el cliente puede controlar un daemon local o remoto, mientras el daemon se ocupa de coordinar los objetos de Docker.
| Componente | Responsabilidad principal | Qué conviene recordar |
|---|---|---|
| Cliente docker | Envía las órdenes que escribe el usuario. | No es el daemon ni ejecuta por sí solo los contenedores. |
| Docker API | Define las solicitudes y respuestas entre clientes y daemon. | Puede usar un socket local o una conexión remota configurada. |
| dockerd | Recibe solicitudes y administra contenedores, imágenes, redes y volúmenes. | Es el daemon principal de Docker Engine. |
| containerd | Gestiona tareas del ciclo de vida y coordina la ejecución de contenedores. | Trabaja debajo del daemon y no sustituye la CLI de Docker. |
| containerd-shim | Mantiene la conexión con un proceso de contenedor y su estado. | Ayuda a desacoplar el proceso del daemon de containerd. |
| runc | Crea el contenedor conforme a una configuración OCI. | Normalmente prepara el aislamiento y lanza el proceso inicial. |
| Kernel de Linux | Proporciona mecanismos de aislamiento y límites de recursos. | Namespaces y cgroups son funciones del kernel, no de runc por sí solos. |
Flujo de la arquitectura Docker Engine al ejecutar docker run
Este ejemplo crea un contenedor sencillo y consulta su estado. El nombre web-demo permite identificarlo después:
docker run -d --name web-demo nginx:alpine
docker ps
docker inspect web-demoAl ejecutar docker run, el cliente prepara una solicitud y la envía a dockerd por la Docker API. El daemon valida la petición, comprueba la imagen y configura los recursos de Docker necesarios, como la red y el almacenamiento. Después delega la ejecución del contenedor en containerd.
Containerd organiza la tarea y utiliza el runtime configurado. Con la configuración habitual, runc crea el proceso inicial usando la especificación OCI y las funciones del kernel. Cuando el proceso queda en marcha, runc termina su trabajo de arranque; el shim y containerd permiten seguir administrando el ciclo de vida. La implementación concreta puede variar según la versión, la plataforma y el runtime seleccionado.
Cómo comprobar la arquitectura Docker Engine desde la terminal
La CLI ofrece una vista práctica de las versiones de cliente y servidor. El resultado de docker version suele incluir también las versiones de containerd y runc usadas por el Engine:
docker versionSi el cliente controla un daemon remoto, la sección del servidor corresponde a ese Engine, no necesariamente al equipo desde el que ejecutaste el comando. Los detalles que muestra docker info dependen de la instalación y de las opciones habilitadas.
Diferencias entre dockerd, containerd y runc
Estos componentes no son intercambiables. Dockerd es la puerta de entrada habitual para la administración de objetos Docker. Containerd maneja tareas de bajo nivel relacionadas con imágenes y el ciclo de vida. Runc es un runtime OCI que configura y arranca un proceso de contenedor; no ofrece la experiencia de usuario de Docker ni gestiona por sí solo redes y volúmenes Docker.
Por eso, los comandos de uso diario se ejecutan con el cliente docker. Herramientas de nivel inferior resultan útiles para diagnóstico especializado, pero modificar directamente el estado interno que administra Docker puede causar inconsistencias.
Errores habituales al entender Docker Engine
- Suponer que el comando docker es el propio daemon.
- Confundir dockerd, containerd y runc como si hicieran el mismo trabajo.
- Afirmar que runc permanece como daemon permanente para cada contenedor.
- Suponer que el cliente y el daemon siempre se ejecutan en el mismo equipo.
- Exponer la Docker API en una red sin proteger el acceso.
Documentación oficial
- Arquitectura y conceptos de Docker
- Documentación de Docker Engine
- Referencia del comando docker version
- Especificación OCI Runtime
