Docker
Docker Engine, daemon, CLI, containerd, runc y BuildKit.
Docker funciona mediante una arquitectura cliente-servidor. La CLI traduce una intención humana en una solicitud a la API del Engine; el daemon coordina imágenes, redes, volúmenes y contenedores; componentes especializados construyen la image y crean el proceso aislado.
docker CLI
→ Docker API
→ dockerd
├── BuildKit / builder
├── image store y registry
├── network y volume drivers
└── containerd
→ runc
→ proceso del containerEntender esta cadena evita la idea equivocada de que el comando docker “es” Docker completo. También permite localizar fallos: una orden puede fallar antes del daemon, durante el pull, en la creación del runtime o dentro de la aplicación.
Un sistema de contenedores debe coordinar tareas diferentes:
Separar cliente y servidor permite que la CLI sea una interfaz ligera y que el daemon mantenga el estado del host. También permite administrar un Engine remoto mediante un contexto, aunque esa capacidad exige proteger el canal y las credenciales.
El binario docker interpreta argumentos y llama a la API del daemon configurado.
docker --context production container lsLa CLI puede ejecutarse en una máquina distinta al Engine. No contiene las imágenes ni los contenedores; solo presenta y envía operaciones.
El daemon administra el estado de Docker Engine. Entre otras tareas:
Cuando dockerd se detiene, la capacidad de administrar recursos se pierde. El comportamiento de containers ya iniciados depende de la configuración y componentes del runtime, pero no debes asumir continuidad sin probar la versión y política del entorno.
En Linux, la CLI suele conectarse a un socket Unix:
/var/run/docker.sockQuien puede usar ese socket puede pedir al daemon crear containers privilegiados, montar el filesystem del host o acceder a secretos. Por eso montar el socket dentro de un container suele equivaler a entregar control administrativo del host.
docker run -v /var/run/docker.sock:/var/run/docker.sock ...No es “solo acceso para listar containers”. La API permite operaciones de alto impacto.
containerd administra el lifecycle de containers, contenido y snapshots mediante APIs de runtime. Docker Engine lo utiliza como componente interno.
Su responsabilidad está más cerca de:
No conviene administrar directamente con ctr recursos creados por Docker salvo diagnóstico experto: ctr es una herramienta de bajo nivel y no representa todas las abstracciones de Docker.
runc es un runtime OCI de bajo nivel. Recibe una especificación y crea el proceso con namespaces, cgroups, mounts, usuario y capacidades.
OCI runtime spec
+ root filesystem
→ runc create/start
→ proceso aisladorunc no es un daemon que mantenga toda la plataforma. Ejecuta la creación del proceso y sale; otros componentes conservan supervisión y metadata.
BuildKit resuelve builds como un grafo de operaciones, administra cache y soporta mounts temporales, secrets, SSH y builds multi-platform.
Dockerfile + build context
→ frontend Dockerfile
→ grafo LLB
→ ejecución paralela/cache
→ image resultBuild y runtime son rutas relacionadas, pero diferentes. Una image puede construirse en un builder remoto y ejecutarse en otro Engine.
El registry almacena manifests, configs, layers y otros artefactos OCI. Cuando el Engine hace pull:
El registry no ejecuta contenedores. Distribuye contenido.
Considera:
docker run -d \
--name api \
-p 3000:3000 \
--memory 512m \
my-api:1.0Determina endpoint, TLS y credenciales. Un contexto equivocado puede ejecutar la operación en otro host.
docker run es una operación conveniente que combina creación y arranque. La CLI envía configuración de image, command, environment, mounts, network, recursos y políticas.
Si no existe localmente, consulta el registry y descarga contenido faltante. Un tag puede apuntar a contenido diferente con el tiempo; un digest fija el resultado.
El runtime crea una vista con layers read-only y una writable layer. Después aplica volumes o bind mounts sobre rutas específicas.
Se preparan namespaces, cgroups, usuario, capabilities, seccomp y otras políticas.
Se conecta el container a una network, se asignan interfaces y DNS, y se crean reglas de publicación para el puerto solicitado.
containerd y runc crean el proceso principal según ENTRYPOINT, CMD y overrides.
La CLI recibe el ID. Con -d termina mientras el proceso sigue activo.
docker stop apiEl shutdown correcto depende de que PID 1 reciba y maneje la señal.
Docker conserva dos tipos de estado:
docker inspect muestra ambos. Un container puede tener configuración correcta, pero estado observado fallido.
Docker Engine es el daemon y componentes para ejecutar containers. Docker Desktop añade una experiencia administrada para macOS, Windows y Linux, normalmente con:
En macOS y Windows, el daemon de containers Linux vive dentro de la VM. Por eso paths, rendimiento y networking pueden diferir de un host Linux nativo.
Ejecutas:
docker run --name api my-api:1.0El container sale inmediatamente. El diagnóstico debe seguir la arquitectura:
docker versionSi solo aparece Client, el problema está en endpoint, daemon o permisos.
docker image inspect my-api:1.0
docker inspect api --format '{{.State.Error}}'Un error exec format error puede indicar arquitectura incompatible.
docker logs api
docker inspect api --format '{{json .State}}'Exit code 1 suele venir de la aplicación; 137 puede relacionarse con SIGKILL u OOM; 126/127 suelen indicar permisos o comando inexistente, aunque el contexto importa.
Supón un servicio de CI que recibe el socket para construir imágenes. Si la aplicación es comprometida, puede pedir:
docker run --rm -v /:/host alpine chroot /host shEl proceso obtiene acceso al filesystem del host mediante el daemon. Ejecutar el servicio como usuario no root dentro de su container no neutraliza este acceso porque el daemon realiza la operación privilegiada.
Alternativas según el caso:
La API negocia compatibilidad, pero funciones nuevas pueden no estar disponibles. Revisa ambas versiones con docker version.
Los paths de bind mount pertenecen al host remoto, no a la máquina donde ejecutas la CLI.
Las políticas y configuración determinan qué containers continúan o reinician. Prueba el comportamiento en lugar de asumirlo.
El Engine selecciona la variante según plataforma. Un fallo puede estar en el manifest o en una dependencia nativa de esa variante.
Versiones modernas de Docker pueden usar el image store de containerd. Conceptos como capas y digests permanecen, pero paths internos, snapshots y herramientas de diagnóstico pueden cambiar. No dependas de manipular directamente el data root.
Distingue si falla la CLI, daemon, pull, create, proceso o aplicación.
Puede ocultar que el usuario no tiene acceso al socket. Añadirlo al grupo docker concede privilegios equivalentes a administración del host.
El contenido pertenece al daemon y storage driver. Cambiarlo manualmente puede corromper metadata.
Opera otra capa y puede crear recursos que Docker no administra como esperas.
Entrega control remoto del host a cualquiera con acceso a ese puerto.
docker version
docker info
docker context inspect
docker eventsEn otra terminal:
docker run --rm alpine echo holadocker events permite observar pull, create, start, die y destroy. Relaciona cada evento con la cadena de componentes.
Para inspeccionar el proceso desde Linux:
docker run -d --name demo alpine sleep 300
docker inspect --format '{{.State.Pid}}' demo
ps -p $(docker inspect --format '{{.State.Pid}}' demo) -o pid,ppid,user,cmdEl proceso aislado sigue siendo un proceso del host.
dockerd coordina recursos y delega lifecycle.docker run y asigna una responsabilidad a cada componente.Instalación y entorno de Docker, para identificar qué Engine estás controlando, dónde se ejecuta y qué límites tiene.