Si el episodio 766 hizo que te explotara la cabeza con el concepto de Pods en Podman, este episodio te va a llevar directamente al siguiente nivel. Por que vamos a completar la integración total con Systemd. Y es que los pods te permiten agrupar contenedores, pero ¿que pasa cuando quieres actualizar una sola pieza?¿ O cuando quieres que Linux se encargue de gestionar la salud de cada una de esas piezas? Ahí es donde Systemd entra en juego.

Quadlets. La pieza secreta de Podman que cambiará tu servidor para siempre

¿Que son los Quadlets?

Quadlets es el nombre que recibe el conjunto de extensiones para systemd que permiten gestionar contenedores Podman como si fueran servicios nativos de systemd. Esto significa que puedes arrancar, parar, reiniciar y monitorizar tus contenedores utilizando los comandos estándar de systemd (systemctl), lo que facilita enormemente la administración de tus aplicaciones en contenedores.

Quadlet te permite escribir archivos de configuración muy sencillos, tipo ini, y systemd se encarga de traducirlos directamente en unidades de servicios reales.

Tipos de Quadlets

Existen distintos tipos de Quadlets, cada uno diseñado para un propósito específico,

• .container .Define un contenedor individual. Es el sustituto directo del comando podman run.
• .volume .Define un volumen persistente. Systemd se asegura de que el almacenamiento esté listo antes que el contenedor.
• .network .Crea redes virtuales personalizadas. Permite que los contenedores se hablen por nombre de DNS.
• .kube .La joya de la corona. Permite que systemd gestione un archivo YAML de Kubernetes (como el Pod de WordPress que vimos).
• .pod .Define un Pod de Podman de forma nativa (aunque hoy en día se prefiere usar .kube por su portabilidad).
• .image .Permite gestionar la descarga y existencia de una imagen específica como un servicio.

El flujo de trabajo de los Qualets

Gestión de Quadlets con Systemd

Para gestionar los Quadlets, la clave es entender que has delegado el mando en systemd. Ya no usas los comandos de podman directamente para arrancar o parar; usas systemctl. La lista de comandos fundamentales para trabajar con quadlets es la siguiente,

Cada vez que crees, borres o modifiques un archivo .container, .volume o .network, tienes que decirle a systemd que vuelva a traducirlos. Pero esto es algo habitual cuando trabajas con systemd. Cada vez que cambias un service tienes que reacargar el demonio. Así que,

systemctl --user daemon-reload

Un caso práctico

Para que veas la potencia de los Quadlets, vamos a ver un ejemplo práctico. Vamos a crear un stack completo de WordPress con su base de datos MariaDB y Redis para caché, todo gestionado por systemd.

Ubicación de los archivos

Todos los archivos de configuración (Quadlets) deben guardarse en el directorio de usuario específico para que SystemD los reconozca. En mi caso, se encuentran en ~/.config/containers/systemd/.

Definición de la Red y los Volúmenes

Antes de los contenedores, se deben definir los recursos que compartirán:

• Red: Se crea un archivo .network (por ejemplo, wp-network.network) con etiquetas como app=WordPress.

[Network]
Label=app=wordpress
Internal=false

• Volúmenes: Se crean archivos .volume para la persistencia de datos, como wp-app-data.volume para los archivos de WordPress y wp-db-data.volume para la base de datos. Los dos tienen exactamente el mismo contenido,

[Volume]
Label=app=wordpress

Configuración de la Base de Datos (MariaDB)

Se crea un archivo .container para MariaDB definiendo:

• La imagen a utilizar.
• La vinculación al volumen de datos (wp-db-data.volume).
• La conexión a la red (wp-network.network).
• Las variables de entorno necesarias (en texto plano por ahora, a la espera del episodio sobre secretos).

[Unit]
Description=Base de Datos MariaDB para WordPress

[Container]
Image=docker.io/library/mariadb:10.11
ContainerName=wp-mariadb
Environment=MYSQL_ROOT_PASSWORD=atareao_root
Environment=MYSQL_DATABASE=wordpress
Environment=MYSQL_USER=lorenzo
Environment=MYSQL_PASSWORD=atareao_pass
Volume=wp-db-data.volume:/var/lib/mysql:Z
Network=wp-network.network

[Service]
Restart=always

[Install]
WantedBy=default.target

Configuración del Caché (Redis)

Se define un contenedor simple para Redis en un archivo .container:

• Se especifica la imagen y el nombre del contenedor.
• Se conecta a la misma red para que WordPress pueda localizarlo.

 cat wp-redis.container 
[Unit]
Description=Caché Redis para WordPress

[Container]
Image=docker.io/library/redis:7-alpine
ContainerName=wp-redis
Network=wp-network.network
# Si sale una versión nueva en el registro, se actualizará solo
AutoUpdate=registry

[Service]
Restart=always

[Install]
WantedBy=default.target

Configuración del Contenedor de WordPress

Este es el componente principal y requiere definir dependencias en su archivo .container:

• Unidad (Unit): Se añaden las directivas After y Requires apuntando a los servicios de MariaDB y Redis para asegurar el orden correcto de arranque.
• Publicación de puertos: Se mapea el puerto (ej. del 8080 al 80) para acceder vía navegador.
• Variables de entorno: Incluye la configuración para conectar con la base de datos y Redis.
• Auto-actualización: Se puede añadir la variable AutoUpdate para que Podman gestione las nuevas versiones de la imagen automáticamente.

[Unit]
Description=Aplicación WordPress
# No arranca hasta que la red, la DB y Redis estén listos
After=wp-network.network wp-mariadb.service wp-redis.service
Requires=wp-mariadb.service wp-redis.service

[Container]
Image=docker.io/library/wordpress:latest
ContainerName=wp-app
# Conexión por nombre de host gracias a la red compartida
Environment=WORDPRESS_DB_HOST=wp-mariadb
Environment=WORDPRESS_DB_USER=lorenzo
Environment=WORDPRESS_DB_PASSWORD=atareao_pass
Environment=WORDPRESS_DB_NAME=wordpress
Environment="WORDPRESS_CONFIG_EXTRA=define('WP_REDIS_HOST', 'wp-redis');"
Network=wp-network.network
# Exponemos el puerto al host para poder navegar
PublishPort=8080:80
Volume=wp-app-data.volume:/var/www/html:Z
AutoUpdate=registry

[Service]
Restart=always

[Install]
WantedBy=default.target

Despliegue y Ejecución

Una vez creados los archivos, se siguen estos comandos de SystemD:

• Recargar SystemD: systemctl --user daemon-reload para que el sistema detecte los nuevos Quadlets.
• Arrancar el stack: Al ejecutar systemctl --user start wordpress, SystemD arrancará automáticamente la red, los volúmenes y los contenedores dependientes (MariaDB y Redis) debido a las directivas de dependencia configuradas.
• Verificación: Se puede comprobar el estado con systemctl --user status wordpress o acceder a localhost:8080 para finalizar la instalación visual de WordPress.

Ajustes posteriores (Caché de Redis)

Si el plugin de Redis en WordPress no detecta el servidor inicialmente por estar en redes distintas a la local, se debe modificar el archivo de WordPress para incluir la variable de configuración extra que apunte al nombre del contenedor Redis, recargar el demonio y reiniciar el servicio.

Gestión diaria con Systemd

• Arranque y Parada. Como hemos configurado dependencias en el archivo de WordPress, al gestionar el servicio principal, arrastras a los demás:
• Arrancar todo el stack:

systemctl --user start wordpress.service

• Parar WordPress:

systemctl --user stop wordpress.service

• Habilitar para que arranque solo al el equipo:

systemctl --user enable wordpress.service

• Inspección. Para Ver si todo está funcionando correctamente,

systemctl --user status wordpress.service

• Ver los logs en tiempo real (El sustituto de podman logs -f):

journalctl --user -u wordpress.service -f

Esto es mejor que los logs de Podman y Docker, porque journalctl guarda los logs de forma persistente y los rota automáticamente cuando alcanzan un tamaño determinado.

• Gestión de actualizaciones automáticas. Como hemos puesto AutoUpdate=registry en los archivos, puedes forzar la actualización o ver el estado,
• Comprobar si hay versiones nuevas y actualizar ya:

podman auto-update

• Ver el histórico de actualizaciones:

podman auto-update --dry-run

• Si quieres borrar un servicio: Borras el archivo .container de la carpeta y haces un daemon-reload. Systemd se encarga de detener y eliminar el contenedor por ti.
• Listar solo los servicios de Quadlet:

systemctl --user list-units "*.service" | grep -E "wordpress|mariadb|redis"

Conclusión

La conclusión es que los quadlets son, sin duda, la pieza que faltaba para cerrar el círculo y lograr la integración total de nuestros contenedores con SystemD. Para mí ha sido el argumento definitivo para decantarme por Podman, ya que me permite gestionar toda mi infraestructura —redes, volúmenes y servicios— mediante código de una forma brutalmente sencilla y nativa, olvidándome de herramientas externas para los logs o las actualizaciones. Estoy tan convencido de su potencial que ya he iniciado la migración de mis servicios, porque tener esa capacidad de control de versiones y esa robustez en el arranque es, sencillamente, espectacular.