Introducción

Si trabajas con contenedores, probablemente conoces Docker. Pero en los últimos años ha surgido un competidor interesante: Podman. Desarrollado por Red Hat, Podman promete hacer todo lo que hace Docker, pero de manera diferente y, según algunos, mejor.

En este artículo analizaremos las diferencias reales entre ambos, sin fanatismos, para ayudarte a entender qué herramienta es la adecuada para ti.

¿Qué es Podman?

Podman (Pod Manager) es una herramienta para gestionar contenedores y pods, desarrollada por Red Hat como alternativa open source a Docker. ¿Su característica principal? No necesita un daemon en ejecución.

El nombre “Podman” viene del concepto de “pod”, el mismo usado en Kubernetes: un grupo de contenedores que comparten recursos.

La Diferencia Fundamental: Daemon vs Daemonless

Docker: Arquitectura Cliente-Servidor

Docker funciona con un daemon (dockerd) siempre ejecutándose en segundo plano:

1
2
3
4
┌──────────────┐     ┌──────────────┐     ┌──────────────┐
│ Docker CLI   │ ──► │ Docker Daemon│ ──► │  Contenedor  │
│ (cliente)    │     │ (dockerd)    │     │              │
└──────────────┘     └──────────────┘     └──────────────┘
  • El daemon se ejecuta como root
  • Todos los comandos pasan a través del daemon
  • Si el daemon falla, pierdes el acceso a los contenedores

Podman: Arquitectura Fork-Exec

Podman no tiene daemon. Cada comando crea directamente el proceso del contenedor:

1
2
3
4
┌──────────────┐     ┌──────────────┐
│ Podman CLI   │ ──► │  Contenedor  │
│              │     │              │
└──────────────┘     └──────────────┘
  • Sin proceso en segundo plano
  • Los contenedores son hijos directos del comando Podman
  • Cada usuario gestiona sus propios contenedores

Comparación Detallada

1. Seguridad: Rootless por Defecto

Docker:

  • El daemon se ejecuta tradicionalmente como root
  • Modo rootless disponible pero no por defecto
  • Un exploit en el daemon = acceso root al sistema

Podman:

  • Rootless por defecto
  • Cada usuario tiene sus propios contenedores aislados
  • Ningún daemon privilegiado que atacar
1
2
3
4
5
# Podman: contenedores sin privilegios root
podman run -it alpine sh

# Docker: requiere grupo docker o sudo (tradicionalmente)
sudo docker run -it alpine sh

Ganador en seguridad: Podman

2. Compatibilidad de Comandos

Buenas noticias: la sintaxis es casi idéntica.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
# Docker
docker run -d -p 8080:80 nginx
docker ps
docker images
docker build -t mi-app .

# Podman (¡mismos comandos!)
podman run -d -p 8080:80 nginx
podman ps
podman images
podman build -t mi-app .

Puedes crear un alias para una transición sin dolor:

1
alias docker=podman

Compatibilidad: Casi total para el uso diario

3. Docker Compose vs Podman Compose

Docker Compose es el estándar de facto para orquestar múltiples contenedores en desarrollo.

Podman ofrece dos opciones:

  1. podman-compose: reimplementación en Python
  2. podman compose: integrado en versiones recientes (usa Compose spec)
1
2
3
4
5
# Con Podman reciente
podman compose up -d

# Con podman-compose (instalación separada)
podman-compose up -d

Nota: La compatibilidad es buena pero no perfecta. Algunos archivos docker-compose.yml podrían requerir pequeños ajustes.

4. Gestión de Imágenes

Ambos usan el mismo formato de imágenes (OCI), por lo que puedes:

  • Usar las mismas imágenes de Docker Hub
  • Construir imágenes con el mismo Dockerfile
  • Transferir imágenes entre Docker y Podman
1
2
3
4
5
6
7
8
# Podman puede usar imágenes de Docker Hub
podman pull docker.io/library/nginx

# Guardar una imagen
podman save -o nginx.tar nginx

# Cargarla en Docker
docker load -i nginx.tar

5. Pods: Una Característica Exclusiva de Podman

Podman soporta nativamente los pods, grupos de contenedores que comparten namespace de red:

1
2
3
4
5
6
7
8
# Crear un pod
podman pod create --name mi-pod -p 8080:80

# Añadir contenedores al pod
podman run -d --pod mi-pod nginx
podman run -d --pod mi-pod redis

# Los contenedores en el pod se comunican via localhost

Esto es útil para:

  • Simular pods de Kubernetes en local
  • Agrupar contenedores relacionados
  • Simplificar la comunicación entre servicios

Docker no tiene un equivalente directo (usa las networks).

6. Integración con Systemd

Podman se integra nativamente con systemd, el sistema init de Linux:

1
2
3
4
5
# Generar un archivo service systemd desde un contenedor
podman generate systemd --name mi-contenedor > mi-contenedor.service

# Habilitar el contenedor al inicio del sistema
systemctl --user enable mi-contenedor.service

Esto permite gestionar los contenedores como servicios normales del sistema, sin necesidad de un daemon separado.

7. Rendimiento

El rendimiento es comparable en la mayoría de los casos:

AspectoDockerPodman
Inicio contenedorLigeramente más rápidoLigeramente más lento
Memoria base~50-100 MB (daemon)~0 MB (sin daemon)
Build imágenesRápido (BuildKit)Comparable
I/O discoExcelenteExcelente

La diferencia es despreciable para la mayoría de los usos.

Tabla Resumen

CaracterísticaDockerPodman
DaemonNo
Rootless por defectoNo
Compatibilidad comandos-99%
Docker ComposeNativoVia podman-compose
Pods nativosNo
Integración systemdLimitadaNativa
Soporte KubernetesDocker DesktopNativo
GUI DesktopDocker DesktopPodman Desktop
PlataformasLinux, Win, MacLinux, Win, Mac
LicenciaApache 2.0Apache 2.0

Cuándo Elegir Docker

Docker sigue siendo la mejor opción si:

  • Trabajas en equipo que ya usa Docker
  • Necesitas Docker Compose con compatibilidad perfecta
  • Usas Docker Desktop y sus funcionalidades (Kubernetes integrado, extensiones)
  • Sigues tutoriales y documentación (casi todos usan Docker)
  • Necesitas soporte comercial

Cuándo Elegir Podman

Podman es preferible si:

  • La seguridad es prioritaria (entornos enterprise, producción)
  • Trabajas en RHEL, CentOS, Fedora (integración nativa)
  • Quieres contenedores rootless sin configuraciones extra
  • Necesitas gestionar contenedores como servicios systemd
  • Estás aprendiendo Kubernetes (los pods son una ventaja)
  • No quieres un daemon siempre ejecutándose

Migración de Docker a Podman

Si quieres probar Podman manteniendo la compatibilidad:

1. Instala Podman

1
2
3
4
5
6
7
8
# Fedora/RHEL
sudo dnf install podman

# Ubuntu/Debian
sudo apt install podman

# Mac (con Homebrew)
brew install podman

2. Crea el Alias

1
2
# En tu .bashrc o .zshrc
alias docker=podman

3. Prueba Tus Workflows

La mayoría de los comandos funcionarán idénticamente. Verifica:

  • Build de imágenes
  • Docker Compose (usa podman compose o podman-compose)
  • Volúmenes y networks

4. Resuelve las Incompatibilidades

Las más comunes:

  • Algunos flags específicos de Docker no existen
  • El socket Docker (/var/run/docker.sock) no existe por defecto
  • Algunas integraciones CI/CD podrían requerir ajustes

¿Pueden Coexistir?

¡Sí! Docker y Podman pueden convivir en el mismo sistema. Usan almacenamiento separado, así que los contenedores e imágenes no se comparten, pero puedes usar ambos para propósitos diferentes.

Conclusiones

No hay un ganador absoluto. La elección depende del contexto:

  • Docker sigue siendo el estándar de facto, con el ecosistema más maduro y la documentación más abundante
  • Podman ofrece ventajas concretas en términos de seguridad y arquitectura, especialmente en entornos enterprise

¿Mi consejo? Si empiezas desde cero, prueba ambos. La compatibilidad de comandos hace que el cambio sea indoloro. Si ya estás en un ecosistema Docker consolidado, no hay urgencia de migrar, pero vale la pena vigilar Podman para proyectos futuros.

Lo bueno es que lo que aprendas con uno se aplica casi completamente al otro.