Docker Engine 29: containerd default y nftables

Docker Engine 29 llegó como una de esas versiones que no agregan una feature vistosa, sino que mueven los cimientos: el image store de containerd pasa a ser el default en instalaciones nuevas y aparece un backend de firewall basado en nftables, todavía experimental. Ninguno de los dos cambios te va a saltar a la cara durante un docker pull cotidiano, pero ambos redefinen cómo Docker guarda imágenes y cómo programa las reglas de red del kernel. Si administrás servidores, conviene entender qué se movió antes de reinstalar.

Docker Engine 29 es la versión mayor del runtime de contenedores de Docker (proyecto Moby) para Linux, publicada el 10 de noviembre de 2025 según las release notes oficiales. Su cambio central es adoptar el containerd image store como almacenamiento por default de imágenes en instalaciones nuevas, sumar soporte experimental de nftables como backend de firewall y elevar la API mínima del daemon a la v1.44.

¿Qué es el containerd image store y por qué ahora es el default?

Docker Engine 29: containerd por default y nftables experimental

El containerd image store es el subsistema que usa containerd —el runtime que Docker ya utilizaba por debajo— para gestionar capas y contenido de imágenes, en reemplazo del viejo graph driver (overlay2). Desde la v29 es el default en instalaciones nuevas. En palabras del blog oficial de Docker: "As of Docker Engine v29, the containerd image store becomes the default for image layer and content management for new installs."

El cambio unifica ejecución y almacenamiento bajo containerd, la misma pieza sobre la que se apoya Kubernetes. Eso reduce duplicación y habilita capacidades que el graph driver no soportaba: distintos snapshotters, lazy pulling (bajar sólo las capas que se necesitan), content stores remotos y distribución peer-to-peer. Lo importante para producción:

Solo afecta instalaciones nuevas. Docker aclara que "these changes only impact new installs; existing users will not be forced to containerd". Si ya tenés un host corriendo, sigue con overlay2 hasta que decidas migrar.
No aplica a daemons con userns-remap. Según las release notes, los daemons configurados con userns-remap quedan afuera del default de containerd por ahora. Si endurecés tus hosts mapeando usuarios (un patrón recomendable), este cambio no te toca automáticamente.
El graph driver tiene fecha de vencimiento. Docker anticipa que "the graph driver backend will be removed in a future release". No es urgente, pero la dirección está marcada: migrar es cuestión de cuándo, no de si.

¿Cómo activo containerd en un host que ya existe?

Se activa agregando un flag de features al daemon.json y reiniciando el daemon. No hay conversión automática de tus imágenes actuales: al prender containerd, las imágenes y contenedores del store viejo siguen en disco pero quedan ocultos. Este es el detalle que más sorprende en reinstalaciones.

{
  "features": {
    "containerd-snapshotter": true
  }
}

Guardás eso en /etc/docker/daemon.json y reiniciás con sudo systemctl restart docker. Antes de hacerlo en un servidor con imágenes que te importan:

Preservá lo que no querés perder de vista. Como el contenido del store anterior se oculta (no se borra), para volver a usar esas imágenes con el nuevo backend hay que empujarlas a un registry con docker push o exportarlas con docker save antes de cambiar.
Probá en un host de staging primero. El almacenamiento cambia de raíz; conviene validar que tus builds, volúmenes y compose files se comporten igual antes de tocar producción.
Ojo con reinstalar. Como bien señalan varios análisis de la comunidad, el riesgo real no está en el upgrade (que respeta tu config), sino en una reinstalación limpia: ahí arrancás con containerd por default y da la impresión de que "desaparecieron" las imágenes.

¿Qué cambia con el backend nftables experimental?

Docker Engine 29 puede programar sus reglas de red con nftables en lugar de iptables, pero es opt-in y experimental. La documentación oficial lo dice sin vueltas: "Support for nftables introduced in Docker 29.0.0 is experimental, configuration options, behavior and implementation may all change in future releases." Hasta esta versión, Docker siempre manejó bridge y overlay con iptables/ip6tables.

El movimiento acompaña a las distribuciones que vienen dejando iptables atrás en favor de nftables. Para habilitarlo:

{
  "firewall-backend": "nftables"
}

o en la línea de comandos con dockerd --firewall-backend=nftables. Puntos a tener en cuenta antes de tocarlo:

No funciona en Swarm. La doc es explícita: "nftables cannot be enabled when the Docker daemon is running in Swarm mode." Las reglas de redes overlay todavía no fueron migradas; el soporte de Swarm queda para una versión futura.
La cadena DOCKER-USER desaparece. Si tenías reglas custom en la clásica cadena DOCKER-USER de iptables, ese mecanismo no existe en nftables. En su lugar, agregás reglas en tablas separadas con base chains que usen los mismos hooks y priority que las de Docker. Es el cambio que más te va a hacer reescribir scripts de firewall.
Cuidado con el IP forwarding tras un reboot. La doc advierte que si parás Docker para migrar, es probable que ya haya habilitado IP forwarding; después de reiniciar, si ningún otro servicio lo re-activa, Docker puede fallar al arrancar. Verificá net.ipv4.ip_forward.

Docker adelantó que nftables será el default en una versión futura y que ahí iptables quedará deprecado. Por ahora es para experimentar en entornos controlados, no para producción.

¿Qué otras cosas se rompen al saltar a la v29?

Además de los dos cambios estrella, la v29 sube el piso de compatibilidad y saca cosas viejas. El más filoso es la API mínima del daemon, que ahora exige v1.44 (Moby v25). Clientes anteriores fallan con "client version 1.43 is too old". La lista corta:

Clientes viejos rechazados. Si tenés herramientas o CI apuntando a un client Docker anterior a v25, actualizalos. Como escape temporal existe DOCKER_MIN_API_VERSION=1.24 dockerd (o "min-api-version" en daemon.json), pero es un parche, no una solución.
Docker Content Trust fuera del CLI. La funcionalidad de firma DCT fue removida de la línea de comandos; si dependías de ella para verificar imágenes, revisá alternativas de supply chain.
cgroup v1 deprecado. Sigue soportado hasta mayo de 2029 según las notas, pero el reloj corre: es la misma tendencia que ya vimos en Kubernetes y en Podman 6.0.
Paquetes ARM de 32 bits recortados. Se discontinuaron los paquetes oficiales para Raspbian de 32 bits y los de Debian armhf ahora apuntan sólo a ARMv7. Si servís contenedores en Raspberry Pi viejas, planificá.
Cambio de módulo Go. Para quienes importan Docker como librería, el path github.com/docker/docker deja de recibir updates: hay que migrar a github.com/moby/moby.

¿Qué hago hoy con esto en mis servidores?

Si corrés Docker Engine Community sobre tus propios hosts Linux, el plan sensato es: actualizar con calma, no reinstalar a ciegas y migrar containerd cuando puedas validarlo. Docker aclara que los usuarios de Docker Desktop no tienen que hacer nada, porque el Engine viaja adentro de futuras versiones de Desktop.

Actualizá primero, migrá después. El upgrade in-place respeta tu store actual. Prendé containerd con el flag de features sólo cuando tengas ventana para probar builds y respaldos.
Auditá tus reglas de firewall. Si usabas DOCKER-USER, documentá esas reglas ahora; las vas a necesitar reescribir cuando nftables madure.
Revisá versiones de clientes y CI. El salto de API mínima es lo que más pipelines silenciosos rompe.

Como lectura complementaria en este mismo blog te sirven las notas sobre cómo mapear usuarios con userns-remap en Docker (justo el caso que queda afuera del default de containerd), cómo configurar un registry mirror para Docker Engine (útil para empujar tus imágenes antes de migrar) y cómo limitar y rotar los logs json-file de Docker.

Preguntas frecuentes

¿Docker Engine 29 me obliga a migrar a containerd?

No. El containerd image store es el default solo en instalaciones nuevas. Si actualizás un host existente, seguís con overlay2 hasta que actives el opt-in en daemon.json. Docker sí anticipa que el graph driver se removerá en una versión futura.

¿Pierdo mis imágenes al activar containerd?

No se borran, pero se ocultan. Al prender el containerd store, las imágenes y contenedores del store overlay2 quedan en disco pero dejan de verse. Para reusarlas con el nuevo backend hay que empujarlas a un registry con docker push o exportarlas con docker save antes de cambiar.

¿Puedo usar nftables en producción con Docker 29?

No se recomienda todavía. El soporte de nftables en 29.0.0 es experimental y su configuración puede cambiar en próximas versiones. Además no funciona con Swarm y las redes overlay aún no fueron migradas.

¿Cuándo salió Docker Engine 29 y cuál es la API mínima?

Docker Engine 29.0.0 se publicó el 10 de noviembre de 2025. El daemon ahora exige como mínimo la API v1.44 (Moby v25); los clientes anteriores fallan salvo que uses el override DOCKER_MIN_API_VERSION.

¿Qué reemplaza a la cadena DOCKER-USER con nftables?

Bajo nftables, la cadena DOCKER-USER no existe. Agregás tus reglas en tablas separadas con base chains que compartan los mismos tipos y hook points que las cadenas de Docker, y ordenás la ejecución con la priority de cada base chain.

Referencias: anuncio oficial de Docker Engine v29, release notes de la versión 29 y documentación de Docker con nftables.