Contenedores con Podman: guía completa de pods y volúmenes

Si trabajas con contenedores y vienes del mundo Docker, seguro que últimamente has oído hablar de Podman y de sus contenedores y pods como alternativa moderna. No es solo “otro Docker”, sino una herramienta diseñada para ser más ligera, más segura y mucho mejor integrada con el ecosistema Linux y Kubernetes, tanto en servidores como en equipos de desarrollo.

A lo largo de esta guía vamos a ver con calma qué son los contenedores con Podman, cómo se organizan en pods, qué diferencia a Podman de Docker, cómo gestionarlos desde línea de comandos y también qué papel juegan herramientas como podman-compose y Podman Desktop en el ciclo de vida de aplicaciones reales. La idea es que al terminar tengas una visión clara y práctica para usar Podman en tu día a día.

Qué es Podman y en qué se diferencia de Docker

Podman es una herramienta de código abierto para crear y gestionar contenedores y pods en sistemas Linux, mantenida principalmente por Red Hat y distribuida bajo licencia Apache, lo que implica que todos sus componentes pueden usarse sin problemas en entornos comerciales. Aunque nació en Linux, también puede utilizarse en macOS y Windows (a través de WSL2 o Podman Desktop).

A nivel funcional, Podman cumple el mismo objetivo que Docker: ejecutar contenedores OCI de forma sencilla. Usa una interfaz de línea de comandos casi idéntica a la de Docker, hasta el punto de que es habitual definir el alias alias docker=podman para reutilizar scripts sin modificarlos. Sin embargo, internamente la arquitectura es distinta y aquí es donde vienen las ventajas importantes.

La primera diferencia clave es que Podman es “daemonless”, es decir, no depende de un demonio central que controle todos los contenedores. Cada comando que lanzas crea sus propios procesos y no hay un servicio permanente tipo dockerd. Esto suele traducirse en menor consumo de recursos, un modelo de seguridad más simple y una integración más natural con herramientas del sistema como systemd.

Otro aspecto muy relevante es que Podman soporta contenedores rootless de forma nativa, permitiendo que usuarios sin privilegios de administrador ejecuten contenedores sin necesidad de conceder acceso a un socket de root. Esto reduce la superficie de ataque y lo hace especialmente atractivo en servidores multiusuario o entornos empresariales con fuerte control de permisos.

Por último, Podman incluye desde el principio el concepto de pod, inspirado directamente en Kubernetes. Eso significa que puedes agrupar varios contenedores que comparten red y almacenamiento sin necesidad de recurrir a un orquestador externo o a herramientas como docker-compose, aunque también existe podman-compose para quien prefiera ese enfoque declarativo.

Qué es un pod y cómo funciona en Podman

El término pod viene del mundo Kubernetes y se refiere a una “vaina” de contenedores que comparten ciertos recursos. En Kubernetes y también en Podman, un pod se puede entender como una unidad lógica que agrupa uno o varios contenedores que trabajan juntos muy de cerca.

Dentro de un pod, todos los contenedores comparten una única dirección IP y un conjunto de espacios de nombres (namespaces) de red y, opcionalmente, volúmenes de almacenamiento. Esto significa que pueden hablar entre ellos usando localhost o 127.0.0.1, como si fueran procesos distintos dentro de la misma máquina, aunque desde fuera el pod se ve como una sola entidad accesible por una IP y puertos concretos.

En la práctica, esto resulta muy útil para implementar patrones como contenedores sidecar o aplicaciones en las que varios servicios están fuertemente acoplados. Por ejemplo, un servidor web nginx en un contenedor y un PHP-FPM en otro pueden vivir en el mismo pod, compartiendo IP y comunicándose por localhost, pero manteniendo sus procesos y ciclos de vida separados.

Cuando creas un pod con Podman, este introduce un contenedor especial llamado contenedor infra. Este contenedor, basado por defecto en la imagen localhost/podman-pause (o similares como k8s.gcr.io/pause), apenas hace nada más que “dormir”, pero su función es vital: se encarga de mantener los namespaces del pod y de servir como ancla para el resto de contenedores que se conectan a ese pod.

Cada contenedor, tanto si está dentro de un pod como si no, cuenta con un proceso de monitorización llamado conmon. Este pequeño programa en C es el responsable de vigilar el contenedor, gestionar su entrada/salida y permitir que herramientas como Podman se conecten, adjunten o recojan el estado del contenedor en cualquier momento.

Gestión de pods con el comando podman pod

En Podman todo lo relacionado con pods se maneja mediante el subcomando podman pod. Desde aquí puedes crear pods, listar su estado, añadir contenedores, controlar su ciclo de vida o eliminarlos cuando ya no los necesitas.

podman pod create --name pod1

podman pod ps

ID, nombre, estado son las columnas básicas que verás al listar pods; vienen acompañadas por el identificador del contenedor infra asociado.

Para añadir un contenedor nuevo a un pod existente, simplemente añadir un contenedor nuevo al pod se hace indicando el pod al que queremos conectarlo en el momento de crearlo. Un ejemplo típico sería algo como:

podman run -dt --pod pod1 --name web nginx

Con este comando, creamos un contenedor basado en la imagen nginx y lo asociamos al pod pod1. Al arrancar este contenedor principal, el pod pasa al estado “Running”, ya que hay procesos activos dentro de él.

podman ps -a --pod

En la salida veremos columnas como CONTAINER ID, IMAGE, STATUS y una columna POD que indica el ID o nombre del pod. Los identificadores de pod que aparecen aquí coinciden con los que vemos en podman pod ps, lo que facilita cruzar información entre ambas vistas.

Ciclo de vida, logs e información detallada de un pod

Una de las gracias de los pods es que podemos gestionar todos sus contenedores de golpe. Aunque sigues teniendo la opción de parar, arrancar o reiniciar contenedores de forma individual, operar sobre el pod completo simplifica mucho la gestión de aplicaciones compuestas.

podman pod pause NOMBRE_O_ID_DEL_POD

podman pod unpause NOMBRE_O_ID_DEL_POD

podman pod stop NOMBRE_O_ID_DEL_POD

podman pod start NOMBRE_O_ID_DEL_POD

Y si necesitamos reiniciarlos de forma directa, existe también podman pod restart para reiniciar el conjunto de contenedores del pod en un solo paso.

podman pod inspect NOMBRE_O_ID_DEL_POD

En cuanto a los logs, cuando solo hay un contenedor principal en el pod es sencillo: podemos obtener la salida con un simple podman logs sobre ese contenedor. Sin embargo, si el pod contiene varios contenedores, debemos indicar de cuál queremos los registros usando el parámetro -c:

podman pod logs -c NOMBRE_DEL_CONTENEDOR NOMBRE_O_ID_DEL_POD

Para ver los procesos que se ejecutan dentro de todos los contenedores de un pod, también disponemos de comandos que agrupan esa información, permitiendo hacer una especie de “ps distribuido sobre todos los contenedores del mismo pod”. Esto es muy práctico a la hora de depurar errores en aplicaciones multicontenedor.

Eliminación de pods y relación con los contenedores

A la hora de borrar pods es clave recordar que al eliminar un pod se eliminan todos los contenedores que contiene. Por eso, Podman exige que el pod esté parado antes de poder borrarlo con seguridad, evitando eliminar por accidente contenedores en ejecución.

podman pod rm NOMBRE_O_ID_DEL_POD

podman pod rm -f NOMBRE_O_ID_DEL_POD

Cuando acumulamos muchos pods, puede ser útil limpiar de golpe. Hay comandos pensados para eliminar todos los pods detenidos o incluso todos los pods del sistema, tanto detenidos como activos, normalmente combinando opciones como -a o usando subcomandos de “prune” específicos según la versión de Podman.

Red y puertos en los contenedores de un pod

En el plano de red, un pod se comporta como una unidad: todos los contenedores del pod comparten la misma IP. Esa IP es la que se asigna al pod en su conjunto y se conecta a la red que le indiquemos al crearlo.

En entornos rootful, si no especificamos nada, el pod se conecta a la red bridge por defecto de Podman. En cambio, en entornos rootless la opción estándar es la red slirp4netns, que permite exponer servicios hacia el host sin requerir privilegios elevados.

Cuando queremos exponer un servicio al exterior debemos realizar el mapeo de puertos en la creación del pod. Esto se hace utilizando las opciones -p o --publish, indicando el puerto del host y el puerto interno del pod:

podman pod create --name webpod -p 8080:80

podman run -dt --pod webpod --name nginx docker.io/library/nginx

Con esto, cualquier petición a la IP del host en el puerto 8080 llegará al puerto 80 del pod, y de ahí al contenedor nginx. Es importante tener en cuenta que solo puede haber un servicio escuchando en cada puerto que mapeamos, por lo que no podremos tener dos contenedores en el mismo pod ofreciendo servicios en el mismo puerto interno mapeado hacia fuera.

La comunicación entre contenedores del mismo pod se hace simplemente usando localhost o 127.0.0.1. Eso quiere decir que, si dentro del pod un contenedor ofrece un servicio HTTP en el puerto 80, otro contenedor puede acceder a él con una URL del tipo http://127.0.0.1:80 sin preocuparse de IPs ni nombres de host.

Almacenamiento y volúmenes compartidos en pods

Aunque cada contenedor puede tener su propio almacenamiento, es muy habitual que los contenedores de un mismo pod compartan parte del sistema de archivos, especialmente cuando un contenedor genera datos que otro debe servir o procesar.

Cuando creamos el pod, podemos definir puntos de montaje que serán visibles desde todos los contenedores del mismo. Estos montajes pueden ser volúmenes gestionados por Podman o montajes directos de directorios del host (bind mounts), dependiendo de si preferimos delegar en Podman la ruta física o controlarla nosotros.

Un ejemplo muy didáctico es el de un pod llamado pod5 que expone un servidor web en el puerto 8082 del host. En ese pod tenemos dos contenedores:

• Un contenedor principal web basado en nginx, que monta un volumen compartido en /usr/share/nginx/html, su DocumentRoot. Este contenedor se encarga de servir la web.
• Un contenedor auxiliar sidecar, cuya misión es ir modificando periódicamente el archivo index.html dentro del mismo volumen, por ejemplo cada segundo, generando contenido dinámico o mensajes que cambian.

Para ello creamos el pod indicando tanto el puerto como el volumen, y luego añadimos ambos contenedores montando el mismo volumen en rutas adecuadas. Con podman volume podemos gestionar estos volúmenes, y con podman volume inspect ver dónde está físicamente la ruta en el host (por ejemplo, algo como ~/.local/share/containers/storage/volumes/NOMBRE/_data en entornos rootless).

Si preferimos usar bind mounts en lugar de volúmenes, al crear el contenedor podemos montar directamente un directorio del host, añadiendo la opción :z cuando trabajamos con SELinux para que se ajusten automáticamente los contextos de seguridad y no haya problemas de acceso desde el contenedor.

Contenedores con Podman: comandos básicos del día a día

Si nunca has trabajado con Podman (ni con Docker), lo primero es entender que los contenedores son una forma de virtualización ligera. No recrean hardware ni un kernel nuevo, sino que aplican espacios de nombres, cgroups y otras técnicas del kernel para aislar procesos, compartiendo el mismo núcleo que el sistema anfitrión.

Frente a las máquinas virtuales tradicionales, los contenedores suelen consumir menos recursos, arrancan mucho más rápido y permiten densidades mayores, lo que se traduce en despliegues más eficientes. Herramientas como LXC/LXD se centran en contenedores de sistema “completos”, mientras que Podman (y Docker) se enfocan en contenedores mínimalistas para ejecutar servicios concretos como bases de datos, servidores web o aplicaciones de correo.

podman run -dt -p 8080:80/tcp docker.io/library/httpd

En este caso, Podman intenta descargar la imagen docker.io/library/httpd si no existe en local (guardándola en rutas como ~/.local/share/containers/storage para usuarios rootless), crea el contenedor y lo arranca en segundo plano (-dt indica modo detach y pseudo-TTY). El puerto 8080 del host se redirige al 80/tcp del contenedor, de modo que podemos abrir el navegador en 127.0.0.1:8080 y veremos la página por defecto de Apache.

podman ps

y si queremos ver también los que están detenidos añadimos la opción -a. En la salida veremos columnas como CONTAINER ID, IMAGE, COMMAND, STATUS, PORTS y NAME, donde el nombre suele ser un alias legible (por ejemplo xenodochial_newton o uno que hayamos puesto nosotros).

podman stop NOMBRE_O_ID

podman start NOMBRE_O_ID

Y eliminarlos cuando ya no hagan falta con:

podman rm NOMBRE_O_ID

Para gestionar imágenes locales contamos con comandos como:

podman image list

que nos muestra repositorio, tag, ID, tamaño y fecha de creación, y con otros como podman image prune para limpiar imágenes que ya no se están utilizando.

Volúmenes y persistencia de datos en Podman

Las imágenes se diseñan para ser inmutables y contener lo justo para que el servicio arranque, pero los datos de trabajo (webs, bases de datos, ficheros de usuario) necesitan almacenarse en algún sitio que sobreviva a la eliminación de contenedores.

Ahí entran los volúmenes, que permiten que un directorio del host se monte dentro del contenedor. Imagina que queremos guardar el contenido de una web servida por Apache; la imagen espera encontrarlos en /usr/local/apache2/htdocs. Podemos crear un volumen llamado www con:

podman volume create www

y luego lanzar el contenedor así:

podman run -dt --name apache -p 8080:80 -v www:/usr/local/apache2/htdocs docker.io/library/httpd

Con esto, todos los archivos situados en ese volumen serán los que Apache sirva al exterior. Mediante:

podman volume inspect www

podemos ver que el volumen se guarda en una ruta tipo /home/USUARIO/.local/share/containers/storage/volumes/www/_data. Basta con copiar nuestra web ahí para que quede accesible desde el contenedor.

Conjuntos de contenedores con podman-compose

Cuando una aplicación necesita varios servicios (por ejemplo, un WordPress con su base de datos MariaDB), definir y arrancar cada contenedor a mano con podman run y sus múltiples parámetros puede ser bastante pesado y propenso a errores.

Para eso está podman-compose, una herramienta que replica el comportamiento de docker-compose usando ficheros docker-compose.yaml. Ahí declaramos servicios, redes y volúmenes, y luego dejamos que Podman se encargue de levantarlo todo en conjunto.

Un ejemplo típico es un archivo donde definimos dos servicios:

• Servicio web con la imagen docker.io/library/wordpress, que expone el puerto 8080 del host hacia el 80 interno, monta un volumen para los archivos de la web y obtiene variables de entorno para conectarse a la base de datos.
• Servicio db con la imagen docker.io/library/mariadb:10.5, que expone el puerto 6603, monta un volumen para los datos de la base y define credenciales y base de datos inicial.

Ambos servicios se conectan a una misma red llamada wpnet y comparten volúmenes declarados en la sección volumes. Al ejecutar:

podman-compose up

se crean los contenedores, la red, los volúmenes y, además, un pod que agrupa esos contenedores. Un comando podman ps posterior mostrará algo parecido a un contenedor infra (por ejemplo 663f84f58792-infra) junto a los contenedores wordpress_db_1 y wordpress_web_1.

Si listamos los pods con:

podman pod ls

veremos una entrada para ese pod (por ejemplo llamado wordpress) con su POD ID, estado y número de contenedores. Desde ahí podemos detener o arrancar de golpe todo el conjunto con podman pod stop y podman pod start, sin preocuparnos de que arranquen en el orden correcto.

Los volúmenes asociados a este stack los veremos con podman volume ls (por ejemplo wordpress_wordpress y wordpress_wpdbvol), y las imágenes implicadas aparecerán en podman image ls (WordPress, MariaDB y la imagen infra/pause usada para el pod).

Instalación de Podman en Linux, macOS y Windows

Instalar Podman hoy en día es bastante directo porque las distribuciones modernas ya lo incluyen en sus repositorios. En sistemas basados en Debian o Ubuntu, la secuencia típica sería:

sudo apt update
sudo apt install -y podman

En otras distribuciones como Fedora, CentOS Stream u openSUSE se utilizan los gestores de paquetes propios (DNF, Zypper, etc.), pero la idea es la misma: instalar el paquete podman directamente desde los repos oficiales.

En macOS, al ser un sistema tipo Unix, la integración también es cómoda. La forma más común es usar Homebrew, ejecutando:

brew install podman

En paralelo, existe Podman Desktop para quienes prefieren una interfaz gráfica. Esta aplicación instala y configura Podman bajo el capó y ofrece una GUI para gestionar contenedores, imágenes y pods sin tirar tanto de terminal.

En Windows el camino pasa casi siempre por WSL2 y una distribución Linux dentro de ese entorno (como Ubuntu). Una vez tengas WSL2 y la distro instalada, entras en esa shell de Linux y sigues los mismos pasos de instalación que en una distro clásica. Podman Desktop también puede usarse en Windows, pero seguirá necesitando el subsistema WSL2 por debajo para que todo funcione correctamente.

Para comprobar que la instalación ha ido bien basta con ejecutar:

podman --version

y confirmar que devuelve un número de versión y no un error de comando no encontrado.

Administración de redes y pods desde la CLI

Además de los subcomandos centrados en contenedores, Podman dispone de una API de red muy similar a la de Docker. Con podman network ls podemos ver las redes disponibles (bridge por defecto, slirp4netns en rootless, redes personalizadas, etc.).

podman network create mi_red

podman run -d --network mi_red nginx

Esto permite que distintos grupos de contenedores tengan redes independientes, con políticas y reglas de aislamiento diferenciadas, lo que es útil en entornos de desarrollo avanzados o en despliegues con múltiples aplicaciones en la misma máquina.

La relación entre redes y pods es muy flexible: al crear un pod podemos especificar a qué red se conecta, cómo se publican sus puertos y qué políticas de acceso se aplican, lo cual encaja muy bien con la forma en que más tarde se migra a escenarios Kubernetes.

Integración con Kubernetes y generación de YAML

Uno de los puntos fuertes de Podman es que acerca mucho el mundo del desarrollo local al de Kubernetes. Aunque no necesitas un clúster para trabajar con pods en tu máquina, si en algún momento decides dar el salto puedes reutilizar gran parte de lo que ya tienes.

podman generate kube MI_POD > mi_pod.yaml

Ese archivo mi_pod.yaml puede servir directamente como base para desplegar la misma aplicación en un clúster de Kubernetes real, ajustando lo que sea necesario. También podemos ir en sentido inverso y crear recursos de Podman a partir de un manifiesto K8s mediante:

podman kube play mi_pod.yaml

Este puente hace que sea muy natural comenzar con Podman en entornos de desarrollo o staging, y más adelante mover las mismas cargas de trabajo a Kubernetes sin rehacer toda la configuración desde cero.

Podman Desktop: interfaz gráfica, depuración y ecosistema

Para quienes prefieren evitar tanto comando o quieren una experiencia visual sobre sus contenedores, Podman Desktop es una GUI multiplataforma y de código abierto que se integra con Podman y, en muchos casos, también con Kubernetes.

Desde esta interfaz puedes crear, arrancar, parar, reiniciar e inspeccionar contenedores con un par de clics, ver sus logs en tiempo real, comprobar el uso de CPU, memoria y disco, y abrir una terminal interactiva dentro de un contenedor para depurar problemas o ejecutar comandos puntuales.

Una de sus funciones más cómodas es el asistente para construir imágenes. En lugar de pelearte con opciones en la CLI, Podman Desktop te guía paso a paso en la selección de imágenes base, dependencias y configuraciones, admitiendo incluso construcciones multi-stage para reducir el tamaño final de las imágenes y mejorar el rendimiento.

La herramienta también ofrece una vista integrada para recursos de Kubernetes como pods, deployments o services. De este modo es posible monitorizar un clúster, revisar el estado de las aplicaciones y ajustar límites de recursos sin salir de la misma aplicación, lo que viene de lujo en entornos de desarrollo cloud native.

Además, Podman Desktop cuenta con un ecosistema de plugins y compatibilidad con muchas extensiones pensadas originalmente para Docker Desktop, lo que facilita la transición de una plataforma a la otra en equipos que ya estaban muy acostumbrados a trabajar de forma gráfica.

Buenas prácticas, seguridad y automatización con Podman

Para sacarle todo el partido a Podman conviene seguir una serie de buenas prácticas, sobre todo en entornos donde la seguridad y el rendimiento importan. Una de las más recomendables es usar contenedores rootless siempre que sea viable, ejecutando Podman como usuario normal y evitando conceder más privilegios de los estrictamente necesarios.

Otra costumbre muy útil es aprovechar la compatibilidad de la CLI de Docker. Si ya tienes un montón de scripts y pipelines que llaman a docker, puedes definir un alias:

alias docker=podman

y seguir usando exactamente los mismos comandos que antes, pero delegando en Podman por debajo. Esto simplifica mucho migraciones graduales en equipos de desarrollo o CI/CD donde cambiar todos los scripts de golpe sería un drama.

En cuanto a la gestión del espacio, conviene hacer limpiezas periódicas de recursos no utilizados. Comandos como:

podman image prune
podman container prune

eliminan imágenes y contenedores que ya no están en uso, ayudando a evitar que el almacenamiento del host se llene de restos de pruebas y despliegues antiguos.

Por último, en entornos empresariales es interesante integrar Podman con herramientas de CI/CD, gestión de configuración y soluciones de seguridad. Al ser de código abierto y apoyar estándares OCI, encaja muy bien en pipelines con GitHub Actions, GitLab CI, Jenkins y similares, permitiendo construir, firmar y desplegar imágenes sin depender de Docker.

Con todo lo anterior en mente, Podman se convierte en una opción muy sólida tanto para quienes ya manejan Docker como para los que se inician ahora en el mundo de los contenedores, ofreciendo una combinación de seguridad, compatibilidad, integración con Kubernetes y facilidad de uso que lo hace especialmente atractivo para proyectos modernos, entornos de desarrollo y despliegues en producción.