Por qué me cambié de Docker a Podman

 (codesmash.dev)
14 puntos por GN⁺ 2025-09-06 | 8 comentarios | Compartir por WhatsApp
  • A Docker se le ha señalado de forma constante por problemas de vulnerabilidades de seguridad y consumo de recursos debido a su arquitectura con daemon en segundo plano (dockerd)
  • Podman adopta una arquitectura sin daemon, por lo que los contenedores se ejecutan directamente con los permisos del usuario, reduciendo la superficie de ataque y reforzando la estabilidad
  • Con soporte para integración con Systemd, diseño amigable con Kubernetes y herramientas separadas basadas en la filosofía Unix como Buildah/Skopeo, mejora la eficiencia operativa
  • Mantiene una alta compatibilidad con la CLI de Docker, así que con solo alias docker=podman la mayoría de los flujos de trabajo existentes siguen funcionando igual
  • Incluso en entornos reales de operación, simplifica la seguridad y la gestión de recursos, y en proyectos nuevos Podman se está convirtiendo en una opción más razonable y orientada al futuro

Limitaciones de Docker y problemas de seguridad

  • Docker tiene una estructura en la que el daemon dockerd siempre se ejecuta con privilegios de root
    • Si se descubre una vulnerabilidad en el daemon, todo el host puede quedar expuesto al riesgo
  • Casos destacados de incidentes de seguridad
    • 2019: escape de contenedor en runC (CVE-2019-5736)
    • 2022: vulnerabilidad Dirty Pipe de Linux, escape de cgroups v1
    • 2024: “Leaky Vessels” en runC, vulnerabilidad en BuildKit
    • 2024: campaña de cryptojacking mediante exposición de la API de Docker
  • La repetición de estos incidentes deja en evidencia el riesgo estructural de fondo de una arquitectura basada en daemon

La arquitectura daemonless de Podman

  • Podman no utiliza un daemon en segundo plano
    • Al ejecutar podman run, el contenedor funciona como proceso hijo directo de quien ejecuta el comando
    • Como se ejecuta en modo rootless, incluso los privilegios de root dentro del contenedor no pasan de ser permisos de usuario común en el host
  • Ventajas
    • Mayor seguridad: si hay escape del contenedor, se reduce el alcance del daño
    • Más estabilidad: aunque un contenedor falle, los demás no se ven afectados
    • Eficiencia de recursos: al no mantener un daemon innecesario residente, baja el uso de memoria

Funciones diferenciadoras de Podman

  • Integración con Systemd
    • podman generate systemd genera automáticamente archivos unit de systemd
    • Es posible administrar servicios con los comandos estándar de systemctl
  • Afinidad con Kubernetes
    • El concepto de Pod viene integrado de forma nativa, lo que facilita el desarrollo de apps multicontenedor
    • Con podman generate kube se puede generar directamente YAML de Kubernetes
  • Filosofía Unix
    • Podman se enfoca en la ejecución de contenedores, mientras que para construir imágenes se usa Buildah y para la gestión de registros Skopeo
    • Esto permite usar herramientas optimizadas según cada propósito

Proceso de migración y compatibilidad

  • La migración de Docker a Podman es casi sin interrupciones
    • La CLI es compatible, así que se puede usar podman en lugar de docker prácticamente tal cual
    • Los Dockerfile existentes también funcionan sin cambios
  • Diferencias
    • En modo rootless no es posible enlazar puertos por debajo de 1024 → se recomienda usar un reverse proxy
    • Es necesario gestionar los permisos de los volúmenes
    • Las herramientas que dependen del socket de Docker pueden usar el modo de compatibilidad con la API de Docker de Podman

Aplicación en entornos reales y beneficios

  • Después de usar Podman en producción
    • Se reduce la carga de las revisiones de seguridad, con seguridad rootless aplicada por defecto
    • Los patrones de uso de recursos se vuelven más simples y predecibles
  • Docker sigue siendo popular, pero si se trata de proyectos nuevos o hay libertad para elegir tecnología, Podman resulta más adecuado
    • Integración natural con el esquema de administración de Linux
    • Arquitectura orientada a Kubernetes
    • Proporciona un entorno de ejecución de contenedores más seguro y razonable

Resumen de la guía de migración para FastAPI

  • Se puede usar el Dockerfile existente sin cambios
  • Basta con sustituir por podman build y podman run
  • Registrar el servicio en systemd con podman generate systemd
  • Uso de Pods para soportar entornos multiservicio como bases de datos
  • El flujo de trabajo de Docker Compose puede cubrirse con podman-compose o mediante conversión con kompose

Lecturas relacionadas

8 comentarios

 
shortstories 2025-09-09

Aquí dicen que es posible hacer una migración sin interrupciones, pero en un entorno de producción real hay bastantes cosas raras. Por ejemplo, en macOS, como la configuración predeterminada usa compresión zstd, la imagen construida termina ocupando bastante espacio en el registro...
 
codemasterkimc 2025-09-08

Tanto Docker como Podman....

securityContext:
allowPrivilegeEscalation: false
capabilities:
drop:
- ALL

securityContext:
runAsNonRoot: true
runAsUser: UID
 
koxel 2025-09-08

En realidad, la compatibilidad con Docker no es muy buena, así que la experiencia de uso no es tan buena...
Me fui a Podman pensando en usarlo sin root, pero al final regresé a Docker.
Como dijo otra persona, si lo vas a usar con Kubernetes, mejor simplemente usar containerd.
 
click 2025-09-08

Me queda la duda de si, si Docker compose no funciona bien y la ventaja es la compatibilidad con Kubernetes, entonces no sería mejor usar Kubernetes directamente. Yo también intenté usarlo, pero como no funcionó de una sola vez y tampoco podía mapear directamente puertos por debajo de 1024, al final lo uso en combinación con k3s y nerdctl para construir imágenes.
 
ndrgrd 2025-09-07

Aunque desde hace tiempo tengo ganas de cambiarlo, cuando lo intenté antes, a diferencia de lo que decían los desarrolladores, demasiados proyectos de Docker Compose no funcionaban correctamente...
 
afewgoodman 2025-09-07

Ni siquiera soporta redes de Docker.
 
devsepnine 2025-09-07

Tengo entendido que, al igual que Docker, también soporta funciones de red.
¿Hay algo que todavía no funcione bien?
 
GN⁺ 2025-09-06
Opiniones de Hacker News
  • En 2001/2002 tuve que montar una caja de hotspot WiFi. En ese tiempo era fan de OpenBSD y quería hacer la distribución en Python lo más ligera posible. Como quería evitar copias de archivos innecesarias y problemas de dependencias, elegí chroot y el concepto de jail. Mi código de despliegue ejecutaba el software fuera del entorno jail y monitoreaba con ptrace los archivos que abría el proceso. Con esa salida saqué una lista de dependencias y la empaqueté. El resultado fue un despliegue pequeño, inmutable y con mejor seguridad. Cuando apareció Docker me recordó ese enfoque antiguo, y me pregunto si existe alguna herramienta similar que monitoree el uso de archivos de un contenedor Docker para reducir la distribución
    • El mejor pipeline de CI/CD que he usado fue para despliegues freelance de Django. Un hook de post-receive de git automatizaba la compilación de archivos estáticos y el reinicio de httpd en cada git push. Bastaba con hacer git push live master y se desplegaba. He usado mucho Docker, pero ese fue el despliegue más fácil. Entiendo las ventajas de Docker, pero configurar HTTP en Ubuntu u OpenBSD no es tan difícil. Me pregunto si la reproducibilidad propia de Docker realmente vale tanto overhead de administración
    • El primer resultado de Google es slimtoolkit/slim, con 22k estrellas
    • En entornos OpenWrt existe una herramienta llamada ujail; le pasas un ejecutable ELF, analiza las dependencias de bibliotecas necesarias y monta en tmpfs solo los archivos indispensables en modo de solo lectura
      Enlace al código relacionado
  • Podman ha sido una experiencia realmente excelente para mí. Usar Docker me parecía difícil y lleno de trampas, mientras que Podman no se queda atrás en nada. Sobre todo, en la empresa donde trabajo no tenemos que preocuparnos por licencias. Es un ganar-ganar total
    • Me da curiosidad si las licencias realmente eran una preocupación en la empresa. La política de licencias pagas de Docker Desktop es razonable. Es gratis para empresas con menos de 250 empleados o menos de 10 millones de dólares en ingresos. Incluso si la licencia cuesta $90 al año, considerando el salario de un desarrollador en EE. UU. eso no llega ni al costo de un almuerzo. Además, puedes usar herramientas con soporte oficial en todos los OS
    • En realidad, a la empresa no debería preocuparle tanto la licencia. Docker Engine es completamente open source, así que es gratis. Solo Docker Desktop requiere una licencia aparte para uso corporativo. Pero la mayoría de las funciones están disponibles en Docker Engine
    • Podman es mucho mejor que Docker. No tienes que preocuparte por el manejo de permisos de usuarios/grupos ni por los problemas de seguridad de procesos root. Tampoco necesitas enviar datos a un daemon
    • En algunas PCs, el desinstalador de Podman para Windows no elimina correctamente todos los componentes, así que al volver a ejecutarlo aparecen errores. Incluso borrando los servicios manualmente, el problema sigue. Es una molestia bastante frecuente
  • Me gusta mucho Podman, pero no siempre funciona bien con todos los contenedores. Por ejemplo, contenedores grandes como gitlab suelen depender de la historia compleja y las particularidades de Docker, así que en podman a menudo fallan. En general, las imágenes hechas por uno mismo sí suelen correr bien en podman. Para contenedores problemáticos, lo esquivo levantando una VM de incus y ejecutándolos ahí dentro. Tanto Podman como Docker son inconsistentes en la forma de dar acceso a GPU, lo cual es incómodo. Aun así, creo que podman es un poco mejor. Especialmente por rootless, que es una gran ventaja
    • Supongo que la mayoría de los problemas vienen de imágenes que arrancan PID 1 como root. Podman es rootless por defecto, así que eso genera este tipo de inconvenientes. Si quieres usar imágenes basadas en root sin Docker, puedes tener Podman separado en modos rootful y rootless y elegir el entorno deseado con la bandera --connection. Si hace falta, Podman incluso puede crear una VM automáticamente (usando lima). Podman Desktop también tiene una capa de compatibilidad con Docker que ayuda a reducir problemas de compatibilidad
    • Creo que el hecho mismo de que algunos contenedores no funcionen en podman fue lo que motivó la entrada del blog. Si la base de usuarios crece lo suficiente, se volverá costumbre revisar también el entorno podman antes de publicar
    • Nosotros ejecutamos tanto el servidor como los runners de GitLab en podman. Personalmente me gustaría mover los runners a k8s, pero por ahora con Traefik funciona bien
    • Uso mucho funcionalidades relacionadas con buildx; en apariencia también funcionan en podman, pero en la práctica no van bien
  • En Ubuntu, el mayor problema es el soporte de podman. La versión de podman que trae Ubuntu por defecto es demasiado vieja como para usarla enseguida. Yo uso podman v5, GitHub Actions tiene v3 y mis colegas usan docker. Al final aparece la complejidad de tener que hacer que mis scripts funcionen en podman viejo, podman nuevo y docker
    • No hay un repositorio confiable de builds .deb. No existen .deb oficiales, y los que encontré están desactualizados o dicen que ya no van a seguir actualizándose. Entonces queda la pregunta de por qué Podman no facilita más la instalación. Mi impresión es que RedHat no quiere gastar recursos de desarrollo en dar soporte a productos de la competencia. Es entendible, pero fuera del ecosistema RedHat da la sensación de ser ciudadano de segunda
    • Creo que este es el mayor problema. La menor popularidad frente a Docker influye, pero los problemas de desajuste de versiones son una causa mucho más fuerte de que Podman siga siendo algo de nicho. Distribuciones como Ubuntu suelen ofrecer software viejo, y eso debería resolverlo cada mantenedor, pero desde el lado de Podman no se ve un esfuerzo muy activo. Por eso incluso terminé cambiando mi home server a una distro de la familia Red Hat para poder usar Podman moderno
    • El hecho de que no se ofrezcan .deb oficiales de upstream de forma constante impide que podamos usar Podman internamente. Da envidia ver que Docker sí mantiene bien su repo oficial de .deb
    • Esa es una de las razones por las que no uso Ubuntu/Debian: actualizan demasiado lento. Podría usarse vía flatpak, pero este tipo de software estaría mejor si viniera por defecto
    • Como Podman es open source, lugares como Ubuntu pueden empaquetarlo y actualizarlo por su cuenta. También se entiende que RedHat no esté muy dispuesto a encargarse de empaquetar software para la competencia
  • Hace poco me tocó montar un entorno con Podman por trabajo, y fue una de las peores experiencias que he tenido. La combinación de Podman rootless + SELinux + usuario normal dentro del contenedor es un verdadero infierno
    • En realidad, si uno quiere complicarse puede hacerlo con cualquier cosa, pero en la práctica casi todo funciona bien. Estoy corriendo varios servicios (Forgejo, runner, uptime-kuma, etc.) como contenedores rootless detrás de un reverse proxy nginx en máquinas RHEL10 con SELinux activado, y funcionan bien
    • Nunca he sentido las ventajas de rootless. Si la máquina pertenece a un único dominio de seguridad, no pasa nada por correrlo como root; y si no es así, creo que deberías usar un entorno de aislamiento real (por ejemplo, una VM de Firecracker/Kata). Rootless trae sufrimiento y sus beneficios reales me parecen dudosos
    • Yo también pasé por la misma situación en el trabajo, pero si lo resuelves a la manera de podman (ver la documentación), sí se vuelve utilizable. La clave es mirar la documentación de versiones recientes
    • Llevo más de 7 años usando solo podman en Fedora
    • Nuestra organización hizo una migración completa de Docker a Podman y, aunque hubo algo de ruido en el proceso, el equipo de SysDev lo resolvió sin mayores problemas
  • Hay quien dice que si el flujo de trabajo con Docker Compose se vuelve demasiado complejo, hay que convertirlo de inmediato a YAML de Kubernetes, pero por mi experiencia el YAML de K8s es mucho más complejo que docker compose. Y no todo el mundo usa Kubernetes
    • Mi opinión es la contraria. La complejidad de YAML de K8s es parecida a la de docker compose, e incluso a veces más simple. Lo que pasa es que es extremadamente verboso. Un compose de 100 líneas puede dividirse en 20 YAMLs de 50 líneas cada uno. Me gustaría que kubectl tuviera una función sugar para convertir entre YAML simple y complejo
    • Al convertir docker compose a k8s yaml, usar un LLM como capa intermedia funciona sorprendentemente bien. Y por cierto, podman también tiene una función para generar k8s yaml, así que la transición puede ser natural
    • Yo no sé hacer archivos compose, pero sí puedo hacer k8s yaml. Por eso compose me parece más "complejo"
  • El comando podman generate systemd mencionado en el artículo ahora está deprecated. La alternativa son los Podman Quadlets, que funcionan de forma parecida a un docker-compose.yaml definido dentro de un archivo unit de systemd
    • Tiene lógica delegar Compose/orquestación a systemd. Como no es una arquitectura cliente-servidor como Docker sino procesos reales del usuario, encaja claramente mejor
    • El problema es que casi no hay documentación
  • Es difícil mapear contenedores con múltiples UID a un único usuario del host. Por defecto, root dentro del contenedor se mapea al usuario que lo ejecuta en el host, pero últimamente muchas apps empezaron a usar usuarios no root dentro del contenedor (por ejemplo, www-data o el usuario 1000). Esos se mapean a IDs secundarios en el host, y eso hace que al montar volúmenes la propiedad de los archivos quede huérfana y genere mucha confusión. Se extraña una opción simple para mapear todos los UID a un solo usuario, y las opciones actuales (uidmap de crun, userns) no funcionan bien. Tengo dudas sobre la utilidad real del mapeo con IDs secundarios
    • Si entiendo bien, esto es una limitación de los namespaces de Linux. Para que herramientas como Docker o Podman soporten este tipo de mapeo, Linux tendría que soportarlo. La razón por la que el mapeo 1:1 de UID es importante es que, si el usuario 1000 y el 0 dentro del contenedor se mapean al mismo usuario del host, la información de propiedad de archivos se rompe
    • Tal vez valga la pena revisar los montajes idmapped. Solo resuelven el remapeo del sistema de archivos, no las llamadas al kernel
    • Estaría bueno que dentro del contenedor simplemente pudiera funcionar como "uno mismo", y que en los logs también apareciera así el propietario
    • Si usas la opción ignore_chown_errors, puedes mapear root al ID del usuario sin necesidad de mapeos adicionales y aplicarlo de forma simple
  • He intentado migrar a Podman varias veces, pero he fallado en distintos puntos. Primero, el rendimiento de podman en mi VPS pequeño fue mucho peor que el de docker (omito detalles). Segundo, el ecosistema de desarrollo todavía no logra alcanzarlo del todo. Muchas herramientas dependen del socket de Docker, y podman no funciona bien con ellas por temas de permisos o diferencias de compatibilidad de API. Podman no es un reemplazo drop-in perfecto
    • Si usas podman rootless, una red lenta puede deberse a slirp4netns. pasta es una opción más rápida. Docker, por defecto, configura la red con un daemon privilegiado, así que si usas podman como root no debería haber diferencia de rendimiento
    • Los errores de permisos SELinux en podman y quadlet siguen siendo un dolor de cabeza. Muchas veces es más fácil crear un pod con privilegios sobre todo el host, montar solo los /dev necesarios y exponer programas muy limitados en una red aislada
    • Curiosamente, en mis sistemas con pocos recursos podman rindió mucho mejor que docker tanto en desempeño como en uso de recursos. Parece deberse a la diferencia entre crun y runc. Además, podman es más liviano porque no tiene daemon
  • Dejé tanto Docker como Podman y me pasé a FreeBSD Jails
    • Puedes ver más información y herramientas de administración aquí,
      aquí,
      aquí,
      y aquí
    • ¿Puedes ejecutar al instante MS SQL Server o miles de contenedores docker dentro de un jail de FreeBSD? Elegir FreeBSD exige un costo grande (limitaciones de compatibilidad, etc.). Esa es la razón por la que jails no se han masificado
    • La configuración parece bastante extensa; me pregunto si en FreeBSD hay algo como containerd
    • Los jails de FreeBSD son una característica específica de esa distribución
    • Me pregunto qué diferencia hay entre usar un jail de FreeBSD y correr una VM sobre un host Linux