Podman como alternativa a Docker sin demonio centralizado

Un compañero te escribe de madrugada: tiene un contenedor que se niega a morir. Lo para y sigue ahí. Lo mata y sigue ahí. Al final no le queda otra que reiniciar el demonio entero para recuperar el control y, de paso, se lleva por delante todo lo demás que estaba corriendo en esa máquina. La escena es más habitual de lo que nos gustaría, y tiene un culpable concreto: el demonio central de Docker.

¿Y si ese demonio no tuviera por qué existir?

Ahí entra Podman.

Docker hizo accesible la contenedorización: empaquetar una aplicación con sus dependencias y moverla entre entornos dejó de ser un dolor. Pero lo consiguió apoyándose en un proceso persistente y privilegiado que lo gobierna todo. Podman propone otro camino —sin demonio, sin necesidad de privilegios de administrador y manteniendo la compatibilidad con los comandos de Docker— y eso no es solo un cambio técnico, sino otra forma de entender cómo se gestionan los contenedores en Linux.

Este artículo no es ni un elogio acrítico ni un ataque a Docker. Es un análisis para quien trabaja en sistemas y quiere entender cuándo y por qué Podman puede encajar mejor, y qué se gana —y qué se pierde— al renunciar a la comodidad del demonio centralizado.

El demonio de Docker: la pieza que lo sostiene todo

Docker nació con una promesa clara: abstraer la complejidad para que cualquiera pudiera empaquetar aplicaciones en contenedores ligeros y portables. Para lograrlo introdujo dockerd, un demonio que corre de forma continua y, de manera tradicional, con privilegios de root. Por debajo, ese demonio delega en containerd y este, a su vez, en un runtime compatible con OCI como runc, que es quien finalmente habla con el kernel y arranca el contenedor.

Esa centralización aporta una experiencia cómoda, pero también tres tensiones conocidas:

• Punto único de fallo. Todos los contenedores dependen del mismo proceso. Si dockerd se cuelga, se actualiza mal o consume demasiados recursos, el problema se propaga a todo lo que gestiona.
• Superficie de ataque. Un demonio que históricamente corre como root es un objetivo goloso: una fuga desde un contenedor hacia ese proceso puede traducirse en root sobre el anfitrión.
• Integración con el sistema. Las herramientas clásicas de monitorización y gestión esperan procesos independientes; un proceso maestro que lo orquesta todo se sale de ese modelo.

El demonio es, por tanto, una espada de doble filo: simplifica el día a día, pero introduce fragilidad justo donde más duele, en producción.

Podman: la filosofía sin demonio

Podman replantea el modelo desde la base. No hay demonio. Cuando ejecutas podman run, Podman bifurca y ejecuta (modelo fork/exec) el contenedor como un proceso hijo directo de quien lanzó el comando: tu shell, un servicio de systemd o un runner de integración continua. Cada contenedor queda vigilado por un proceso ligero llamado conmon (container monitor), que se encarga de su ciclo de vida.

La consecuencia más elegante de este diseño es que Podman no necesita estar vivo para que tus contenedores lo estén: si el binario termina, los contenedores que ya estaban en marcha siguen funcionando, porque nunca dependieron de un proceso maestro común.

Sobre esa base, Podman se apoya en mecanismos maduros del kernel:

• Espacios de nombres de usuario (user namespaces) para mapear el UID del contenedor a un rango de identificadores sin privilegios en el anfitrión, definido en /etc/subuid y /etc/subgid.
• cgroups para limitar y contabilizar recursos.
• Un runtime OCI estándar (runc o crun, este último optimizado para cgroup v2).

Y todo ello con una interfaz prácticamente idéntica a la de Docker. La compatibilidad llega al punto de que mucha gente simplemente define alias docker=podman y sigue trabajando como siempre. Los contenedores resultantes son, a efectos prácticos, indistinguibles de los de cualquier otro motor compatible con OCI.

El otro pilar es el modo sin privilegios (rootless). En Podman es la opción por defecto: un usuario normal puede levantar contenedores sin sudo. La diferencia de seguridad es concreta: una fuga desde un contenedor rootful puede dar root en el anfitrión; una fuga desde un contenedor rootless da, como mucho, los permisos de tu usuario sin privilegios. Sigue sin ser deseable, pero la diferencia entre «malo» y «catastrófico» es justamente esa.

Conviene matizar un punto que a veces se cuenta mal: Docker también admite modo rootless desde 2019. La diferencia es que en Docker es una opción que hay que activar (dockerd-rootless-setuptool.sh), levanta un proceso dockerd aparte y arrastra algunas limitaciones; en Podman, lo rootless es el camino principal y todo está pensado alrededor de ello.

La letra pequeña: lo que se gana y lo que se pierde

Renunciar al demonio tiene un precio, y un análisis honesto tiene que ponerlo encima de la mesa.

Persistencia tras reinicios. Como no hay un servicio en segundo plano que se encargue de relanzar contenedores, nada los arranca solos después de un reinicio o un cierre de sesión. La respuesta de Podman es integrarse con systemd: históricamente con podman generate systemd y, en las versiones modernas, con Quadlets (ficheros de unidad declarativos). En rootless, además, necesitas habilitar linger para el usuario (loginctl enable-linger) si quieres que los servicios sobrevivan al cierre de sesión.

Red en modo rootless. Sin privilegios no puedes mapear puertos por debajo del 1024 de forma directa, y la red de contenedores (networking) se resuelve en espacio de usuario mediante slirp4netns o pasta, lo que añade algo de sobrecarga frente al puenteado a nivel de kernel del modo privilegiado.

El socket de Docker. Herramientas que dan por hecho la existencia de /var/run/docker.sock necesitan adaptación. Podman ofrece un socket de API compatible, pero no es algo que esté ahí «por defecto y para todo».

Ninguno de estos puntos es un defecto fatal: son el coste lógico de un modelo más simple y aislado. Pero saber que existen es lo que separa una migración tranquila de una sorpresa a las tres de la mañana.

¿Cuándo elegir Podman?

No se trata de demonizar a Docker ni de idealizar a Podman. El criterio manda.

Podman brilla cuando la seguridad es prioritaria y no quieres un proceso privilegiado corriendo de forma permanente: entornos multiusuario donde varios desarrolladores levantan contenedores sin pisarse, máquinas donde la trazabilidad de procesos importa, o infraestructuras que ya viven en el ecosistema de Red Hat. Y, en contra de un tópico que sigue circulando, Podman está más que listo para producción: en la familia RHEL es el motor por defecto y, con Quadlets y systemd, se gestiona como cualquier otro servicio del sistema.

Docker, por su parte, sigue siendo una opción sólida por inercia y por ecosistema: amplísimo soporte, herramientas integradas como Docker Compose o Swarm, y un Docker Desktop muy pulido. Si tu cadena de herramientas, tu integración continua y la costumbre del equipo ya giran alrededor de Docker, el coste de migrar puede no compensar todavía.

La pregunta útil, por tanto, no es «¿cuál es mejor?», sino «¿qué estoy optimizando?». Si la respuesta es seguridad, simplicidad del árbol de procesos y alineación con Kubernetes, la balanza se inclina hacia Podman.

Ecosistema y curiosidades

Podman es obra de Red Hat, está licenciado bajo Apache 2.0 y vive dentro del proyecto containers, junto a un puñado de herramientas que comparten su filosofía sin demonio:

• Buildah, para construir imágenes OCI.
• Skopeo, para inspeccionar y mover imágenes entre registros.
• CRI-O, el runtime de contenedores pensado para Kubernetes.

Como Podman es nativo de Linux, en macOS y Windows funciona levantando una pequeña máquina virtual con podman machine —exactamente igual que hace Docker Desktop por debajo—. Para quien prefiera interfaz gráfica está Podman Desktop, y para quien venga de Compose existe podman-compose además de la compatibilidad con docker-compose a través del socket de API.

El gesto de fondo es reconocible para cualquiera que venga de Unix: procesos pequeños, independientes y compuestos por el sistema, en lugar de un único proceso que lo gobierna todo. La compatibilidad con el estándar OCI (Open Container Initiative) garantiza que las imágenes se comparten sin ataduras a un ecosistema propietario.

Resumiendo

El demonio de Docker no es un error de diseño: es una decisión que prioriza la comodidad. Podman toma la decisión contraria y prioriza el aislamiento y el control, a cambio de que tú asumas explícitamente cosas que antes te resolvía un proceso en la sombra.

Elegir entre uno y otro no va de modas. Va de entender qué hace cada herramienta cuando nadie mira.

Y esa, más que cualquier comando, es la diferencia entre administrar sistemas y limitarse a ejecutarlos.

Para seguir aprendiendo

• Documentación oficial de Podman — https://docs.podman.io — la referencia imprescindible: arquitectura, modo rootless, integración con systemd y guías paso a paso. Material vivo y actualizado.
• Página del proyecto — https://podman.io — y repositorio en GitHub — https://github.com/containers/podman — instalación, novedades y código fuente.
• Guía de Quadlets — https://docs.podman.io/en/latest/markdown/podman-systemd.unit.5.html — la forma moderna de integrar contenedores con systemd mediante ficheros de unidad declarativos (disponible desde Podman 4.4); resuelve precisamente el «¿qué los arranca tras un reinicio?» del que habla este artículo.
• Cómo mejorar systemd con Quadlet (blog de Red Hat) — https://www.redhat.com/en/blog/quadlet-podman — introducción accesible al porqué y al cómo de los Quadlets, escrita por el equipo que los desarrolla.
• rootlesscontaine.rs — https://rootlesscontaine.rs/getting-started/podman/ — guía centrada en levantar Podman sin privilegios paso a paso, con los detalles de subuid/subgid y reenvío de puertos.
• Open Container Initiative — https://opencontainers.org — los estándares abiertos de imágenes y runtime que explican por qué Podman y Docker son interoperables.
• Proyecto Buildah — https://buildah.io — el complemento de Podman para construir imágenes sin demonio.
• Linux Containers and Virtualization: A Kernel Perspective, de Shashank Mohan Jain (Apress, 2020) — https://link.springer.com/book/10.1007/978-1-4842-6283-2 — un recorrido por lo que ocurre por debajo de la API: namespaces, cgroups y runtimes.