Llevas 44 lecciones construyendo imágenes con Docker, y hay algo que conviene decir con claridad: esas imágenes no son «de Docker». Son artefactos que cumplen un estándar abierto, y funcionan igual en Podman, en containerd, en CRI-O o en un nodo de Kubernetes sin cambiar un byte. Esta lección explica por qué, desmonta el ecosistema pieza a pieza y ejecuta ghcr.io/auroralibros/aurora-api:2.0.0 fuera de Docker para demostrarlo.

1. La pregunta correcta: ¿de quién es una imagen?
2. El estándar OCI y sus tres especificaciones
3. Qué significa esto en la práctica
4. El mapa de piezas: runtimes de bajo y alto nivel
5. CRI: por qué Kubernetes no habla con Docker
6. Podman: la arquitectura sin daemon
7. Rootless por defecto
8. Compatibilidad de comandos y qué se rompe
9. Pods, generate kube y play kube
10. Compose, el socket compatible y Testcontainers
11. Docker frente a Podman, y la migración de Aurora Libros
12. containerd y nerdctl
13. Buildah y Skopeo
14. Aislamiento reforzado: gVisor y Kata Containers
15. Tabla de decisión

Cuando ejecutaste docker build -t aurora-api:2.0.0 ., Docker no inventó un formato propio. Produjo un artefacto con una estructura pública: un manifiesto JSON, una configuración con las variables de entorno, el ENTRYPOINT, el usuario y el historial, y una lista de capas comprimidas, todo identificado por digests SHA-256.

Fíjate en el mediaType: pone vnd.oci.image.index.v1+json, no «docker». Ese prefijo es la prueba literal de que tu imagen es un artefacto OCI, y de que la multiarquitectura que montaste en 05-05 es una función del estándar, no de Docker.

La Open Container Initiative nació en 2015 dentro de la Linux Foundation, impulsada por la propia Docker, que donó su formato de imagen y su runtime runc. El motivo fue evitar una guerra de formatos incompatibles (había un competidor serio, rkt, con su propio formato). El resultado es que hoy el contenedor es un estándar y no un producto.

Cualquier constructor produce imágenes que cualquier registro almacena y cualquier runtime ejecuta. Esa cuadrícula completa es lo que compra el estándar.

Consecuencia directa para Aurora Libros: ghcr.io/auroralibros/aurora-api:2.0.0 —104 MB, dos arquitecturas, firmada con Cosign, con SBOM y attestation de procedencia— corre exactamente igual en Docker, en Podman, en containerd o en cualquier nodo de Kubernetes, y su firma se verifica igual en todos. No has aprendido un producto: has aprendido un estándar y una de sus implementaciones.

Cambiar el de bajo nivel es una línea de configuración, y las imágenes no se enteran:

Kubernetes necesita hablar con algún runtime en cada nodo. En vez de acoplarse a uno, definió la Container Runtime Interface, una API gRPC con dos servicios: RuntimeService (ciclo de vida de Pods y contenedores) e ImageService (imágenes).

Docker Engine nunca implementó CRI, así que existió un adaptador llamado dockershim dentro del propio kubelet. Era código de Kubernetes manteniendo compatibilidad con un producto concreto, y se retiró en la versión 1.24 (2022).

Aquello se comunicó fatal y generó titulares del tipo «Kubernetes deja de soportar Docker». Lo que realmente ocurrió fue que se eliminó un intermediario: containerd, que ya estaba ahí debajo, pasó a hablar directamente con el kubelet. Tus imágenes no se vieron afectadas en absoluto, porque son OCI. Es la mejor ilustración posible de la tesis de esta lección.

Podman (Red Hat) es la alternativa más relevante a Docker, y su diferencia estructural es que no hay daemon.

La cuarta fila es la razón de fondo. El «el grupo docker es equivalente a root» que aprendiste en 05-03 simplemente no existe en Podman: no hay socket privilegiado al que pertenecer. Y la última importa en entornos regulados: los registros de auditoría atribuyen las acciones a personas, no a un demonio.

Docker admite modo rootless desde la 20.10, pero hay que activarlo. En Podman es lo normal desde el principio, apoyado en user namespaces (05-07) y en los rangos de /etc/subuid y /etc/subgid.

El contenedor cree ser el usuario redis (UID 999) y el kernel lo ve como el 100998, un UID sin ningún privilegio. Una fuga del contenedor no da root: da un usuario que no puede hacer nada.

Podman replica la CLI de Docker de forma deliberada:

Funciona para la inmensa mayoría del trabajo diario. Lo que no es idéntico:

Podman toma prestada de Kubernetes su unidad de agrupación: el pod, un conjunto de contenedores que comparten namespace de red (y por tanto localhost y los puertos).

Fíjate en REDIS_URL=redis://localhost:6379: dentro de un pod, los contenedores comparten la interfaz de red, así que se alcanzan por localhost. Es exactamente el modelo de un Pod de Kubernetes, ensayado en tu portátil.

Y de ahí sale el puente más útil de Podman:

generate kube produce un Pod (o Deployment con --type deployment) listo para revisar. No sustituye al trabajo del módulo 6 —no genera Ingress, HPA, PDB ni sondas afinadas— pero como borrador es mucho mejor que kompose, porque parte de algo que ya funciona.

Dos caminos para ejecutar tu compose.yaml:

La opción B es superior porque usa el Compose oficial v2, con toda su cobertura de claves, hablando con Podman a través de un socket que emula la API de Docker. Y ese mismo socket habilita lo demás:

Migración de Aurora Libros, paso a paso y con la comprobación al final:

Cero cambios en la imagen, cero cambios en el compose.yaml, misma firma verificable y el cache-aside devolviendo db y luego cache. La única diferencia real de operación está en el paso 5: donde Docker tenía restart: unless-stopped, aquí hay unidades de systemd de usuario, y el enable-linger es el detalle que se olvida siempre.

containerd es un proyecto graduado de la CNCF, y es la pieza que ya usas sin saberlo: Docker Engine delega en él. Gestiona imágenes, snapshots, redes básicas y el ciclo de vida, y llama a runc. Es también el runtime por defecto de la mayoría de los Kubernetes gestionados.

Su CLI nativa, ctr, es una herramienta de depuración, no de trabajo:

nerdctl es lo que hace containerd usable: replica la CLI de Docker, incluye BuildKit y trae Compose.

nerdctl además expone funciones que Docker no tiene: imágenes cifradas, lazy-pulling con stargz (arranque sin descargar la imagen entera) y contenedores Wasm. Es la vía habitual para experimentar con lo que viene.

Buildah construye imágenes OCI sin daemon y sin Dockerfile si no lo quieres:

Skopeo es el que más se echa de menos cuando no se conoce: inspecciona y copia imágenes entre registros sin descargarlas al disco local.

El --all copia el índice multiarquitectura completo, no solo la variante de tu máquina: sin él, replicarías media imagen y el servidor amd64 fallaría. Y el último comando es oro puro en un pipeline: verificar el digest de producción cuesta una petición HTTP en lugar de una descarga completa.

Los contenedores comparten el kernel del host. Si aparece una vulnerabilidad de escalada en el kernel, el aislamiento se rompe. Estos dos runtimes atacan justo eso.

Para Aurora Libros no hacen falta: tu código es tuyo y ya corre sin privilegios, con read_only, cap_drop: [ALL] y no-new-privileges. Se justifican cuando ejecutas código que no controlas —funciones de clientes, CI de repositorios públicos, cuadernos de terceros— y ahí el coste de rendimiento se paga sin discusión.

La conclusión honesta: en 2026 Docker sigue siendo la elección natural para desarrollo por ecosistema y comodidad, Podman gana en entornos donde la seguridad y la política del sistema mandan, y containerd es lo que ejecuta el mundo en producción sin que casi nadie lo teclee. Y las tres cosas ejecutan tu misma imagen.

• Creer que hay que reconstruir para cambiar de runtime. No. El digest es el mismo y la firma de Cosign se verifica igual.
• Repetir que «Kubernetes dejó de soportar Docker». Lo que se retiró fue dockershim, un adaptador. Las imágenes OCI nunca estuvieron en cuestión.
• Mezclar contenedores de root y de usuario en Podman. Los almacenes están separados: lo que construyes con sudo podman no lo ve podman. Es la confusión número uno al empezar.
• Esperar restart: always en Podman. No hay daemon. Genera unidades con podman generate systemd y no olvides loginctl enable-linger.
• Publicar el puerto 80 en rootless sin ajustar nada. Los puertos privilegiados están vetados. Ajusta ip_unprivileged_port_start o pon un proxy delante.
• Copiar imágenes con skopeo copy sin --all. Te llevas solo una arquitectura y el otro entorno falla al desplegar.
• Usar ctr para el día a día. Es una herramienta de depuración de containerd. Usa nerdctl.
• Consejo: ejecuta docker buildx imagetools inspect --raw sobre tu imagen y lee el mediaType. Ver vnd.oci en pantalla fija la idea mejor que cualquier explicación.
• Consejo: si te interesa Podman, empieza por el socket compatible y docker compose. Migras la ejecución sin migrar las herramientas.
• Consejo: podman generate kube es el mejor borrador de manifiestos que existe, porque parte de algo que ya funciona.

Ejercicio 1 — Demuestra la portabilidad. Ejecuta ghcr.io/auroralibros/aurora-api:2.0.0 con Docker y con Podman (o nerdctl) en la misma máquina. Compara el digest de la imagen en ambos, comprueba que el endpoint /libros devuelve los nueve títulos en los dos casos y verifica la firma de Cosign contra el registro. Escribe qué es idéntico y qué cambia entre ambas ejecuciones.

Ejercicio 2 — Un pod al estilo Kubernetes con Podman. Crea un pod aurora que contenga aurora-cache (redis:7-alpine) y aurora-api, comunicándose por localhost, con el puerto 8080 publicado. Comprueba que el cache-aside funciona (origen: db la primera vez, cache la segunda). Después genera el manifiesto de Kubernetes con podman generate kube, léelo y anota tres cosas que le faltan para ser apto para producción según lo aprendido en el módulo 6.

Ejercicio 3 — Skopeo en el pipeline. Escribe un script que, sin descargar ninguna imagen, compruebe si el digest de ghcr.io/auroralibros/aurora-api:2.0.0 coincide con el que hay desplegado en producción (léelo de un fichero digest-produccion.txt), y que en caso de discrepancia replique la imagen completa, con sus dos arquitecturas, al registro interno registro.interno:5000. El script debe devolver 0 si todo coincide y 10 si tuvo que replicar.

Solución 1.

Idéntico: el digest, el contenido, el comportamiento de la API y la verificación de la firma —porque Cosign valida un artefacto que vive en el registro, no en el runtime—. Cambia lo que rodea a la ejecución: en Docker el contenedor es hijo de dockerd (root) y aparece en ps aux como tal; en Podman rootless es hijo de conmon bajo tu UID, el proceso interno se mapea a un UID alto del host, y podman ps solo muestra tus contenedores. También cambia la red (netavark frente al bridge de Docker) y la gestión del arranque automático. Ninguna de esas diferencias afecta al artefacto: lo que se ejecuta es exactamente lo mismo.

Solución 2.

Lo que le falta al manifiesto generado para ser apto para producción: (1) las tres sondas —genera como mucho lo que dedujo del contenedor, no las startupProbe, livenessProbe y readinessProbe sobre /salud/vivo y /salud/listo que separaste en 06-01—; (2) resources con requests y limits, sin los cuales el planificador no puede colocar el Pod con criterio ni el HPA calcular el porcentaje de uso; (3) es un Pod suelto, no un Deployment, así que no hay réplicas, ni rolling updates, ni rollback, ni recuperación si el nodo cae. Añadiría dos más: no hay ConfigMap/Secret (la configuración va como variables literales, incluidas las credenciales) y no hay Service ni Ingress. Sirve como borrador excelente porque parte de algo que funciona, y como recordatorio de que todo lo que hace un despliegue apto para producción es trabajo deliberado.

Solución 3.

Las claves. skopeo inspect --format '{{.Digest}}' hace una única petición HTTP al manifiesto: comprobar si algo cambió cuesta milisegundos en lugar de descargar 104 MB, y eso permite ejecutarlo cada cinco minutos sin coste. skopeo copy transfiere de registro a registro sin materializar capas en el disco local, algo que docker pull seguido de docker push no puede hacer. El --all es imprescindible: sin él copiarías solo el manifiesto que corresponde a la arquitectura del ejecutor, y el día que un nodo arm64 tirase de la copia interna, el pull fallaría con un error de plataforma que cuesta bastante diagnosticar; la verificación posterior con --raw confirma que las dos arquitecturas llegaron. Y el código de salida 10 distingue «no había nada que hacer» de «he replicado», que es lo que permite encadenar un paso de notificación en el pipeline solo cuando hubo cambio real.

Ya sabes por qué las imágenes que has construido durante todo el curso no son «de Docker». Lo has comprobado leyendo el mediaType de tu propio índice multiarquitectura: application/vnd.oci.image.index.v1+json. La Open Container Initiative normaliza tres cosas —la Image Spec que da forma a tus imágenes, la Runtime Spec que define el config.json que abriste en 05-07, y la Distribution Spec que rige cada push a ghcr.io—, y de ahí sale la cuadrícula completa: cualquier constructor, cualquier registro, cualquier runtime.

Tienes el mapa de piezas ordenado por capas: runtimes de bajo nivel que viven milisegundos (runc, crun, youki) frente a gestores de alto nivel (containerd, CRI-O, Podman, Docker Engine), con CRI en medio explicando por qué el kubelet habla con containerd y por qué la retirada de dockershim en la 1.24 fue eliminar un intermediario, no dejar de soportar tus imágenes.

Conoces Podman a fondo: sin daemon, con los contenedores como hijos de tu usuario y no de un proceso root, lo que hace que el «grupo docker es root» de 05-03 simplemente no exista; rootless por defecto sobre user namespaces, con sus cuatro limitaciones reales y sus soluciones; los pods que ensayan el modelo de Kubernetes en tu portátil con localhost entre contenedores; generate kube y play kube como el mejor borrador de manifiestos que existe, porque parte de algo que funciona; y el socket compatible que te deja usar el docker compose oficial y Testcontainers sin cambiar de herramientas. Y has migrado Aurora Libros de verdad: misma imagen, mismo digest, misma firma verificada, mismo compose.yaml, con el cache-aside devolviendo db y después cache, y systemd de usuario ocupando el lugar de restart: unless-stopped.

Completan el cuadro containerd —la pieza que ya usabas sin saberlo— con ctr para depurar y nerdctl para trabajar, incluido nerdctl compose; Buildah para construir sin daemon; Skopeo para inspeccionar y copiar entre registros sin descargar nada, con el --all que evita replicar media imagen; y gVisor y Kata cuando hay que ejecutar código que no controlas y el coste de rendimiento se paga a gusto. La tabla de decisión te dice cuándo Docker sigue siendo la elección natural y cuándo compensa otra cosa.

En la última lección del curso levantamos la vista del todo: hacia dónde va el ecosistema de contenedores, qué tendencias tienen sustancia y cuáles son apuesta, qué no va a cambiar —y por eso es donde conviene invertir el aprendizaje—, y el cierre completo del camino que ha recorrido Aurora Libros desde aquellos quince pasos manuales de onboarding.