Llegamos a la primera gran diferencia entre Docker y Podman, los Pods. En este episodio me vas a acompañar en la migración de un stack sencillo de Docker-Compose a Podman usando Pods. Pero sobre todo, lo que quiero que veamos es la potencia que nos ofrece Podman a la hora de agrupar y gestionar contenedores relacionados entre si, utilizando este concepto de Pods. Esto solo es el aperitivo de lo que tiene que venir.

Olvídate de configurar complejas redes virtuales. Con los pods todo se comunica a través de localhost gracias a la «vaina» y al contenedor invisible Infra. Además, te enseño el truco definitivo para que tu sistema gestione todo el conjunto de forma nativa: pasar de un YAML de Kubernetes a la automatización total con Quadlet y systemd. Si buscas que tus servicios en Linux sean más robustos, elegantes y fáciles de mantener, este es el camino.

Adiós a Docker Compose. Cómo usar PODS en Podman. Paso a Paso

Los Pods son la gran diferencia entre Docker y Podman. Imagina una «vaina» o grupo de contenedores que comparten la misma red, el mismo espacio de nombres y la misma dirección IP. Esto elimina el problema de las redes virtuales en Docker-Compose; aquí, si tienes un WordPress y un MariaDB en el mismo Pod, la aplicación se conecta a la base de datos simplemente llamando a localhost o 127.0.0.1. Además, cada Pod cuenta con un contenedor invisible llamado «infra» que mantiene viva la infraestructura de red aunque los servicios se reinicien.

Lo potente de este concepto es que dejas de gestionar piezas sueltas de Lego para tratar tus servicios como una unidad funcional. Puedes detener, arrancar o ver las estadísticas de consumo de CPU y RAM de todo el stack de un solo golpe. Esto facilita el uso de patrones como el Sidecar, donde servicios como Redis actúan de asistentes de la aplicación principal, quedando blindados dentro de la vaina sin que nadie desde el exterior pueda acceder a ellos. Es, en definitiva, una forma mucho más limpia, segura y profesional de organizar tus servicios en Linux.

En Docker, cada contenedor se comporta como una entidad totalmente independiente con su propia dirección IP. Para que dos servicios (como WordPress y su base de datos) se comuniquen, te ves obligado a crear y gestionar redes virtuales específicas dentro de Docker para que los contenedores puedan «verse» entre sí.

El contenedor Infra

Eel contenedor Infra (también conocido como contenedor de infraestructura o pause container) es un componente técnico esencial para que los Pods funcionen correctamente,

• El guardián del espacio de nombres. Su función principal es crear y mantener vivos el espacio de nombres de red y el espacio de nombres de usuario del Pod.
• Contenedor invisible. Es un contenedor que no realiza tareas de servicio por sí mismo (como una base de datos o un servidor web), sino que actúa de forma transparente para el usuario.
• Persistencia de la red. Al ser el contenedor «infra» el que posee la IP y la configuración de red del Pod, permite que los contenedores de servicio (como WordPress o MariaDB) se reinicien o mueran sin que el Pod pierda su dirección IP o su conectividad.
• Ciclo de vida. El contenedor «infra» es el primero en arrancar cuando haces un podman pod start y el último en detenerse, asegurando que siempre haya una infraestructura de red lista para los demás contenedores del grupo.

Un ejemplo práctico

Para crear un pod, por ejemplo un WordPress con todas sus cosas los pasos son relativamente sencillos.

• Crear el Pod (la vaina)

Lo primero es crear el contenedor que servirá de base y definirá los puertos que estarán expuestos al exterior.

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

Este comando genera el contenedor infra que mantiene la red y el espacio de nombres vivos.

• Añadir los contenedores al Pod

Una vez creada la vaina, vas añadiendo los contenedores indicando específicamente a qué Pod pertenecen con el flag --pod:

• Base de datos: Al ejecutar el comando para MariaDB, incluyes --pod pod-wordpress.
• Aplicación (WordPress): Igualmente, usas --pod pod-wordpress. Aquí es donde ocurre el momento clave: configuras el host de la base de datos como 127.0.0.1 porque ya comparten red.
• Caché (Redis): Se añade siguiendo la misma lógica, permitiendo que WordPress lo vea en 127.0.0.1:6379 sin configuraciones de red adicionales.
• Persistir y automatizar

Para no tener que repetir estos comandos manualmente, utilizas la potencia de Podman para generar un archivo YAML de Kubernetes:

podman generate kube pod-wordpress > pod-wordpress.yaml

Ahora vamos a por la base de datos,

podman run -d --detach \
  --name wp-db \
  --pod pod-wordpress \
  -v wp-db-data:/var/lib/mysql:Z \
  -e MYSQL_ROOT_PASSWORD=atareao_root \
  -e MYSQL_DATABASE=wordpress \
  -e MYSQL_USER=lorenzo \
  -e MYSQL_PASSWORD=atareao_pass \
  mariadb:10.11

Punto a destacar, algo que no vemos con Docker, precisamente reside en --pod pod-wordpress

La aplicación, es decir WordPress

podman run -d --detach \
  --name wp-app \
  --pod pod-wordpress \
  -v wp-app-data:/var/www/html:Z \
  -e WORDPRESS_DB_HOST=127.0.0.1 \
  -e WORDPRESS_DB_USER=lorenzo \
  -e WORDPRESS_DB_PASSWORD=atareao_pass \
  -e WORDPRESS_DB_NAME=wordpress \
  wordpress:latest

Puntos a destacar aquí,

• WORDPRESS_DB_HOST=127.0.0.1. En Docker Compose usarías el nombre del servicio (wp-db). Aquí, al compartir red, WordPress simplemente ataca a su propio localhost. Es más sencillo y elimina problemas de resolución DNS interna.
• El flag :Z en los volúmenes. El :Z es vital para que Podman reetiquete los permisos y el contenedor pueda escribir en el volumen siendo rootless.
• Gestión simplificada. Si haces un podman pod stats pod-wordpress, verás el consumo de CPU y RAM de todo el sitio web como una única unidad. Es una forma muy limpia de monitorizar servicios.

Y para completar el stack, vamos a añadir Redir, siguiendo con la misma lógica que hemos visto hasta el momento,

podman run -d --detach \
  --name wp-redis \
  --pod pod-wordpress \
  redis:7-alpine

A destacar aquí,

• Lo maravilloso de los Pods es que ahora WordPress puede ver a Redis en 127.0.0.1:6379.
• Cero configuración de red. No has tenido que crear una docker network ni enlazar contenedores. Al estar en el mismo Pod, «se huelen» por defecto.
• Seguridad. Nadie desde fuera del pod, puede acceder a Redis. Está blindado dentro de la vaina.
• Escalabilidad. Esto es lo que se conoce como un patrón Sidecar. Redis actúa como un asistente de WordPress. Si WordPress muere, Redis sigue ahí esperando. Si Redis muere, WordPress sigue funcionando (más lento), pero la unidad lógica es inseparable.

Gestión de pods

Esta es una de las mejores partes de trabajar con Pods. Al agrupar los contenedores en una vaina, dejamos de gestionarlos uno a uno como si fueran piezas sueltas de Lego y empiezas a tratarlos como una unidad funcional. Así, en lugar de hacer un stop a WordPress, luego a MariaDB y luego a Redis, lo podemos hacer todo de un solo golpe, como hacíamos con docker-compose,

podman pod stop pod-wordpress

¿Qué sucede por debajo? Podman envía una señal de parada a cada uno de los contenedores del Pod. Es limpio, ordenado y asegura que ninguno se quede «huérfano» consumiendo recursos.

Para volver a levantarlo todo,

podman pod start pod-wordpress

Esto encenderá la infraestructura del Pod (el contenedor infra) y acto seguido arrancará los contenedores de la base de datos, caché y aplicación.

Y para reiniciar el pod, por ejemplo, si has hecho cambios de configuración o notas que algo va lento:

podman pod restart pod-wordpress

Si queremos verificar que todo está funcionando como esperamos,

podman pod ps

Aquí verás cuántos contenedores hay dentro del Pod y cuántos están realmente corriendo (STATUS). Pero si queremos tener información mas detallada del funcionamiento del pod y de los contenedores del pod tenemos las estadísticas,

podman pod stats pod-wordpress

Este comando es oro. Te da la suma de CPU y Memoria de todo el stack. Es perfecto para saber cuánto te está costando realmente mantener ese WordPress con su Redis y su base de datos.

Como borramos un pod

Para borrar un pod es tan sencillo como ejecutar el siguiente comando, podman pod rm -f pod-wordpress. Con esto, lo borras todo, los contenedores, sus configuraciones y sus procesos desaparecen (aunque los volúmenes externos persisten). Es la forma más rápida de limpiar un entorno de pruebas sin dejar basura por el sistema.

¿Como persistir esto?

Llegados a este punto te estarás preguntado si tenemos que hacer esto cada vez. Pues no, aquí viene la primera parte de la magia. Tienes que ejecutar este comando para que te genere un archivo yaml estándar de kubernetes.

podman generate kube pod-wordpress > pod-wordpress.yaml

• Podman es capaz de leer lo que acaba de escribir. Si borras todo tu Pod, puedes levantarlo idéntico simplemente haciendo podman play kube wordpress.yaml. Es lo más parecido al docker-compose up que existe en el ecosistema nativo de Podman.
• Este YAML es la documentación perfecta de tu infraestructura. Ahí quedan reflejados los volúmenes, las variables de entorno y los puertos. Es la forma ideal de compartir sus despliegues en GitHub o GitLab.
• Aquí es donde conectamos con el siguiente episodio. Quadlet puede usar estos archivos YAML directamente. Pero no quiero adelantarme…

Ahora, aunque haya borrado mi pod, lo puedo recrear fácilmente a través de ese yaml,

podman play kube wordpress.yaml

Podman lee el archivo y, de forma automática,

• Crea el Pod con el nombre y los puertos definidos.
• Crea los volúmenes si no existen.
• Descarga las imágenes (si no las tienes ya).
• Levanta los tres contenedores (WordPress, MariaDB y Redis) con sus variables de entorno.

La guinda del pastel.

Aquí es donde le ponemos la guinda al pastel, wordpress.kube. Para que systemd gestione todo tu stack de WordPress (los tres contenedores a la vez), solo necesitas crear un archivo en ~/.config/containers/systemd/.
El archivo wordpress.kube,

[Unit]
Description=Stack de WordPress (App, DB y Redis) vía Quadlet
After=network-online.target

[Kube]
# Apuntamos al YAML que generamos antes
Yaml=wordpress-stack.yaml

# Si queremos que se pueda acceder desde fuera, 
# aunque el YAML ya suele tener los puertos, podemos reforzarlos aquí
PublishPort=8080:80

[Install]
# Esto hace que arranque solo al iniciar el sistema
WantedBy=default.target

• Simplicidad extrema. No has tenido que definir tres servicios (uno para cada contenedor). Quadlet lee el YAML, entiende que es un Pod con tres piezas y él solo crea las dependencias de systemd necesarias.
• Gestión unificada. Si haces un systemctl --user stop wordpress, systemd se encarga de apagar el Pod completo de forma ordenada.
• Actualizaciones. Si cambias algo en el wordpress-stack.yaml (por ejemplo, subes la versión de Redis), solo tienes que hacer un systemctl --user daemon-reload y un restart. Quadlet detecta el cambio en el YAML y recrea lo que sea necesario.
• Cero scripts de arranque. Te olvidas de los típicos scripts de «arranque al inicio» que solemos hacer en Bash. Esto es nativo de Linux

Indicar que el archivo wordpress-stack.yaml debe estar en la misma carpeta que el archivo .kube (o indicar la ruta completa). Si el usuario tiene los archivos organizados, el despliegue de servicios en Linux se vuelve algo limpio, elegante y, sobre todo, fácil de mantener.

Conclusiones

La gran conclusión de este episodio es que el uso de los Pods en Podman marca un antes y un después en la forma de gestionar infraestructuras locales, ya que nos permite tratar un conjunto de contenedores como una unidad funcional indivisible. Al compartir red y espacio de nombres, simplificamos radicalmente la arquitectura eliminando la necesidad de gestionar redes virtuales complejas, permitiendo que los servicios se comuniquen de forma segura a través de localhost. Además, gracias a la capacidad de Podman para generar archivos de Kubernetes y su integración con Quadlet, logramos una automatización profesional y nativa mediante systemd, elevando nuestros despliegues a un nivel de elegancia y mantenibilidad que difícilmente se alcanza con el Docker-Compose tradicional.