Podman Quadlet frente a Docker Compose para servicios en Linux

Docker Compose y Podman Quadlet resuelven problemas superpuestos, pero provienen de diferentes filosofías de diseño. Elegir entre ellos depende de si piensas en términos de pilas de aplicaciones o de servicios de Linux.

Esta distinción es importante para cualquiera que ejecute contenedores en un anfitrión de Linux más allá de una tarde de experimentación. Compose describe servicios, redes y volúmenes en un archivo YAML y los inicia con docker compose up. Quadlet describe contenedores en archivos de unidad estilo systemd y permite que el gestor de servicios del sistema controle el ciclo de vida.

Ambos enfoques funcionan para servicios autohospedados, herramientas internas y servidores pequeños. La elección correcta depende de tu modelo operativo, la familiaridad del equipo y de si prefieres un formato de pila amigable para desarrolladores o un modelo de servicio nativo de systemd. Esta comparación cubre las diferencias prácticas: formatos de archivo, propiedad del ciclo de vida, contenedores sin privilegios de root (rootless), registro de eventos (logging), actualizaciones, redes, seguridad y vías de migración. Forma parte de Herramientas de Desarrollo: La Guía Completa para Flujos de Trabajo Modernos.

Recomendación Rápida

Usa Docker Compose cuando:

• Buscas el flujo de trabajo multitenedor más rápido.
• Ya utilizas Docker Engine.
• Compartes pilas con otros desarrolladores.
• Necesitas un compose.yaml familiar para el desarrollo local.
• Despliegas servicios pequeños con Docker en un solo anfitrión.
• Utilizas ejemplos existentes de Compose de proyectos.

Usa Podman Quadlet cuando:

• Buscas servicios de contenedores nativos de systemd.
• Prefieres contenedores sin privilegios de root (rootless).
• No deseas un daemon central de Docker.
• Ejecutas servicios de larga duración en un anfitrión Linux.
• Quieres usar systemctl, journalctl, temporizadores, dependencias e inicio automático.
• Estás construyendo un servidor autohospedado o un laboratorio doméstico (homelab) basado en systemd.
• Quieres que los contenedores se integren en el modelo de servicio normal de Linux.

La regla práctica:

Docker Compose es mejor para pilas de aplicaciones.
Podman Quadlet es mejor para servicios de Linux.

Esto no es una ley. Es un valor predeterminado útil.

Tabla de Comparación

Ninguno de los dos es Kubernetes. La mayoría de los servicios pequeños no necesitan un clúster. Necesitan una forma aburrida y comprensible de iniciar, detener, actualizar, registrar eventos y recuperarse.

En Qué Es Bueno Docker Compose

Docker Compose es una herramienta para definir y ejecutar aplicaciones multitenedor. Un archivo Compose típico describe servicios, imágenes, contextos de compilación, puertos, volúmenes, redes, variables de entorno, comprobaciones de estado (health checks), dependencias y perfiles.

services:
  web:
    image: nginx:stable
    ports:
      - "8080:80"
    restart: unless-stopped
    volumes:
      - ./html:/usr/share/nginx/html:ro

  redis:
    image: redis:7
    restart: unless-stopped

Ejecútalo:

docker compose up -d

Verifica el estado:

docker compose ps

Lee los registros:

docker compose logs -f

Deténlo:

docker compose down

Compose es directo y productivo. Es especialmente bueno cuando la unidad de pensamiento es “esta aplicación tiene varios contenedores”. Para una referencia completa de comandos y patrones de Compose, consulta la Hoja de Trucos de Docker Compose. Para comandos de Docker más allá de Compose: imágenes, volúmenes, redes y limpieza, consulta la Hoja de Trucos de Docker.

En Qué Es Bueno Podman Quadlet

Podman Quadlet es una forma de definir contenedores de Podman utilizando archivos estilo systemd. En lugar de escribir un servicio systemd completo generado a mano, escribes un archivo declarativo:

[Unit]
Description=Contenedor web de ejemplo
After=network-online.target
Wants=network-online.target

[Container]
Image=docker.io/library/nginx:stable
PublishPort=8080:80
Volume=/opt/example/html:/usr/share/nginx/html:ro

[Service]
Restart=always

[Install]
WantedBy=multi-user.target

Guárdalo como /etc/containers/systemd/example.container, luego recarga systemd:

sudo systemctl daemon-reload

Inícialo:

sudo systemctl enable --now example.service

Verifícalo:

systemctl status example.service
journalctl -u example.service -f

La principal atractivo de Quadlet: el contenedor se convierte en un servicio normal de Linux.

La Diferencia Filosófica

Docker Compose Piensa en Pilas

Compose pregunta: ¿Qué servicios componen esta aplicación?

Un proyecto Compose suele vivir cerca del código de la aplicación:

myapp/
  compose.yaml
  .env
  app/
  db/

Inicias el proyecto como una unidad:

docker compose up -d

Actualizas el proyecto como una unidad:

docker compose pull
docker compose up -d

Esto es simple, visible y portable.

Podman Quadlet Piensa en Servicios

Quadlet pregunta: ¿Qué contenedores debe ejecutar este anfitrión Linux como servicios?

Los archivos Quadlet viven en rutas de contenedores relacionadas con systemd:

/etc/containers/systemd/
~/.config/containers/systemd/

Gestionas los servicios generados con systemd:

systemctl status myapp.service
systemctl restart myapp.service
journalctl -u myapp.service -f

Esto se siente más nativo en un servidor Linux. Para patrones generales de servicios systemd, consulta Ejecutar cualquier ejecutable como servicio en Linux.

La Diferencia Importante: ¿Quién Posee el Ciclo de Vida?

Con Docker Compose, Compose posee el ciclo de vida de la aplicación. Con Quadlet, systemd posee el ciclo de vida del servicio.

Esto afecta el comportamiento de inicio, apagado, política de reinicio, orden de dependencias, registros, visibilidad del estado, servicios de usuario, actualizaciones, integración con temporizadores e integración con otros servicios del anfitrión.

Si ya usas systemd para gestionar todo lo demás en el anfitrión, Quadlet encaja perfectamente. Si piensas principalmente en términos de pilas de aplicaciones, Compose suele ser más cómodo.

Docker Compose bajo systemd vs Quadlet

Puedes ejecutar Docker Compose como un servicio systemd. A menudo es un buen patrón. Ejemplo de unidad systemd:

[Unit]
Description=Pila Docker Compose de MyApp
Requires=docker.service
After=docker.service network-online.target
Wants=network-online.target

[Service]
Type=oneshot
RemainAfterExit=yes
WorkingDirectory=/opt/myapp
ExecStart=/usr/bin/docker compose up -d --remove-orphans
ExecReload=/usr/bin/docker compose up -d --remove-orphans
ExecStop=/usr/bin/docker compose down
TimeoutStartSec=0
TimeoutStopSec=120

[Install]
WantedBy=multi-user.target

Esto funciona bien. Pero sigue siendo un envoltorio alrededor de Compose. systemd inicia el comando Compose, mientras que Docker y Compose manejan los contenedores detrás de escenas.

Con Quadlet, la generación de unidades está diseñada para Podman y systemd directamente. Escribes archivos de unidad orientados a contenedores, y systemd gestiona los servicios generados.

La distinción es sutil pero importante:

Docker Compose bajo systemd:
  systemd gestiona un comando Compose.

Podman Quadlet:
  systemd gestiona servicios de contenedores generados.

Para una guía detallada de este patrón, consulta Ejecutar Docker Compose como un Servicio de Linux con systemd.

Comparación de Formatos de Archivo

YAML de Docker Compose

Compose usa YAML. Es compacto, popular y fácil de compartir. También es sensible a la indentación y puede volverse desordenado cuando una pila se vuelve grande.

services:
  app:
    image: ghcr.io/example/app:1.0.0
    restart: unless-stopped
    ports:
      - "8080:8080"
    environment:
      APP_ENV: production
    volumes:
      - app-data:/data

volumes:
  app-data:

Archivos de Unidad Quadlet

Quadlet usa archivos estilo systemd. Son más verbosos cuando tienes muchos servicios, pero legibles si ya entiendes systemd.

[Unit]
Description=Contenedor de aplicación de ejemplo
After=network-online.target
Wants=network-online.target

[Container]
Image=ghcr.io/example/app:1.0.0
PublishPort=8080:8080
Environment=APP_ENV=production
Volume=app-data.volume:/data

[Service]
Restart=always

[Install]
WantedBy=multi-user.target

Y un archivo de volumen:

[Volume]
VolumeName=app-data

Guardados como app.container y app-data.volume en el directorio de contenedores systemd correspondiente.

Mapeo de Conceptos de Docker Compose a Quadlet

La migración es conceptualmente simple pero no mecánica. Compose describe una pila. Quadlet describe servicios.

Contenedores Rootless (Sin Privilegios de Root)

Los contenedores rootless son una de las razones más fuertes para mirar hacia Podman y Quadlet.

Con Docker, muchos usuarios se añaden al grupo docker. Eso es conveniente, pero el acceso al daemon de Docker es efectivamente un acceso potente al anfitrión. En una estación de trabajo personal, eso puede ser aceptable. En servidores compartidos, merece más precaución.

Podman fue diseñado con el uso rootless como un flujo de trabajo de primera clase. Un Quadlet rootless vive bajo el directorio de configuración del usuario:

~/.config/containers/systemd/whoami.container

Luego gestiónalo con systemd de usuario:

systemctl --user daemon-reload
systemctl --user enable --now whoami.service
systemctl --user status whoami.service
journalctl --user -u whoami.service -f

Para permitir que el servicio del usuario siga funcionando después del cierre de sesión:

sudo loginctl enable-linger "$USER"

Este es un modelo limpio para servicios propiedad del usuario.

Comparación Rootless

Rootless no es magia. Tiene compensaciones en redes, comportamiento privilegiado y puertos bajos. Pero para servicios de larga duración propiedad del usuario, Quadlet es un modelo muy elegante.

Comportamiento de Inicio y Arranque

Docker Compose

Compose por sí solo no crea un servicio de arranque. Generalmente te basas en políticas de reinicio de Docker, un envoltorio systemd alrededor de docker compose up -d, un script de despliegue o una herramienta de nivel superior.

Ejemplo de política de reinicio de Compose:

services:
  app:
    image: example/app:stable
    restart: unless-stopped

Un envoltorio systemd te da un servicio a nivel de anfitrión. Eso es bueno, pero sigue siendo un envoltorio extra. Consulta Ejecutar Docker Compose como un Servicio de Linux con systemd para el patrón completo.

Podman Quadlet

Quadlet ya está orientado a systemd. Habilita en el arranque:

sudo systemctl enable myapp.service

Para rootless:

systemctl --user enable myapp.service
sudo loginctl enable-linger "$USER"

El comportamiento de arranque no es un complemento. Es el modelo.

Comportamiento de Reinicio

Compose usa comúnmente restart: unless-stopped en YAML. Quadlet usa comúnmente el comportamiento de reinicio de systemd:

[Service]
Restart=always

O:

[Service]
Restart=on-failure

Esto mueve la lógica de reinicio al gestor de servicios. La preferencia: usa políticas de reinicio de Compose/Docker para pilas Compose, usa políticas de reinicio de systemd para Quadlet, y no apiles demasiados supervisores. Mantén un propietario claro del comportamiento de reinicio.

Comparación de Registros (Logging)

Registros de Docker Compose

docker compose logs -f
docker compose logs -f app

Esto es excelente para los desarrolladores.

Registros de Quadlet

Los servicios Quadlet usan registros de systemd:

journalctl -u app.service -f

Para unidades rootless:

journalctl --user -u app.service -f

Aún puedes usar los registros de Podman:

podman logs -f container-name

Para operaciones de servidor, la integración con journalctl es una ventaja importante. Tus contenedores se ajustan al mismo flujo de trabajo de registros que otros servicios de Linux.

Actualizaciones

Actualizando Docker Compose

Un flujo de actualización común:

cd /opt/myapp
docker compose pull
docker compose up -d --remove-orphans
docker image prune -f

Fácil de envolver en un script:

#!/usr/bin/env bash
set -euo pipefail

cd /opt/myapp

docker compose config --quiet
docker compose pull
docker compose up -d --remove-orphans
docker image prune -f
docker compose ps

Actualizando Podman Quadlet

Un flujo manual simplificado:

sudo podman pull ghcr.io/example/app:1.0.1
sudo systemctl restart app.service

O para rootless:

podman pull ghcr.io/example/app:1.0.1
systemctl --user restart app.service

Podman puede soportar flujos de auto-actualización cuando los contenedores están configurados con las etiquetas y la política de imagen correctas. La ventaja de Quadlet no es que las actualizaciones sean siempre más simples. La ventaja es que las actualizaciones son nativas del gestor de servicios.

Filosofía de Auto-Actualización

Las auto-actualizaciones son convenientes. También son un riesgo. Para servicios de laboratorio doméstico de bajo riesgo, las actualizaciones automáticas de contenedores pueden estar bien. Para bases de datos, aplicaciones con estado o servicios empresariales, el flujo preferido es:

1. Realizar copia de seguridad.
2. Descargar (pull).
3. Recrear o reiniciar.
4. Verificar el estado.
5. Limpiar más tarde.

Compose hace esto explícito. Quadlet y Podman pueden hacerlo nativo de systemd. Ninguna herramienta elimina la necesidad de un plan de rollback.

Volúmenes y Datos Persistentes

Volúmenes de Compose

Compose soporta volúmenes nombrados:

services:
  db:
    image: postgres:16
    volumes:
      - db-data:/var/lib/postgresql/data

volumes:
  db-data:

Y montajes bind:

services:
  app:
    image: example/app
    volumes:
      - ./config:/config:ro
      - ./data:/data

Volúmenes de Quadlet

Quadlet puede usar montajes bind:

[Container]
Volume=/opt/app/config:/config:ro
Volume=/opt/app/data:/data

O un archivo .volume:

[Volume]
VolumeName=app-data

Luego referenciarlo:

[Container]
Volume=app-data.volume:/data

Compose es más compacto para el almacenamiento a nivel de pila. Quadlet está más alineado con unidades de servicio gestionadas de forma independiente.

Secretos y Archivos de Entorno

Compose

Compose a menudo usa env_file o environment en YAML. Para un servicio privado pequeño, .env es común. Para sistemas serios, trata .env como sensible y manténlo fuera de Git.

Quadlet

Quadlet puede usar:

[Container]
Environment=APP_ENV=production
EnvironmentFile=/opt/app/app.env

Restringe permisos:

chmod 600 /opt/app/app.env

Ni Compose ni Quadlet son un sistema completo de gestión de secretos por sí mismos. No confundas “no en la línea de comandos” con “seguro”.

Redes

Redes de Compose

Compose crea una red de proyecto predeterminada y da nombres DNS a los servicios basados en los nombres de los servicios:

services:
  app:
    image: example/app
    depends_on:
      - db

  db:
    image: postgres:16

La aplicación generalmente puede alcanzar la base de datos en db. Las redes de aplicaciones multitenedor se sienten naturales. Esta es una de las características más fuertes de Compose.

Redes de Quadlet

Quadlet puede definir redes por separado con archivos .network o usar opciones de red de Podman:

[Network]
NetworkName=appnet

Archivo de contenedor:

[Container]
Image=example/app:stable
Network=appnet.network

Esto es más explícito y estilo systemd. Para uno o dos contenedores, está bien. Para una pila de aplicaciones grande, Compose a menudo es más fácil de leer.

Pods (Grupos)

Podman tiene un concepto nativo de pod. Eso importa si te gusta el modelo mental de Kubernetes donde múltiples contenedores comparten un espacio de nombres de red y un límite de ciclo de vida. Quadlet soporta archivos .pod:

[Pod]
PodName=myapp
PublishPort=8080:8080

Un contenedor puede unirse a ese pod:

[Container]
Image=ghcr.io/example/app:stable
Pod=myapp.pod

Compose no tiene el mismo modelo de pod. Tiene servicios en redes. Para la mayoría de las aplicaciones web simples, las redes de Compose son suficientes. Para usuarios de Podman que gustan del agrupamiento estilo pod, Quadlet es una mejor opción.

Flujos de Trabajo de Compilación

Compose suele ser mejor cuando compilas imágenes como parte del flujo de trabajo de la aplicación local:

services:
  app:
    build:
      context: .
      dockerfile: Dockerfile
    ports:
      - "8080:8080"

Entonces:

docker compose up --build

Esto es extremadamente conveniente para el desarrollo. Quadlet suele ser mejor cuando ejecutas imágenes ya compiladas como servicios. Compila imágenes con Podman por separado:

podman build -t localhost/myapp:latest .

Luego referencia la imagen:

[Container]
Image=localhost/myapp:latest

Si tu flujo de trabajo es “editar código, recompilar, reiniciar pila”, Compose gana. Si tu flujo de trabajo es “desplegar una imagen conocida como un servicio de Linux”, Quadlet gana.

Portabilidad

Los archivos Compose se comparten ampliamente. Muchos proyectos de código abierto proporcionan un compose.yaml o docker-compose.yml. Si un proyecto dice “ejecuta esto con Docker Compose”, generalmente puedes empezar rápidamente con docker compose up -d. Esta es una ventaja práctica importante.

Quadlet es portable entre sistemas que tienen Podman, systemd y soporte Quadlet compatible. Eso es un objetivo más estrecho, pero muy bueno para servidores Linux modernos. Quadlet no es el mejor formato para compartir una aplicación con cada posible desarrollador. Es un buen formato para describir cómo un anfitrión Linux específico debe ejecutar un servicio en contenedor.

Experiencia del Desarrollador

Docker Compose generalmente gana en experiencia del desarrollador. Más ejemplos, más tutoriales, más plantillas de proyecto, compilaciones locales más fáciles, pila de un solo archivo fácil, docker compose up familiar y fuerte ajuste para dependencias de desarrollo. Un desarrollador puede leer esto rápidamente:

services:
  db:
    image: postgres:16
  redis:
    image: redis:7
  app:
    build: .

Quadlet puede hacer cosas similares, pero está más moldeado para operaciones. Para el desarrollo local, raramente empezaría con Quadlet a menos que la aplicación en sí sea específicamente sobre Podman o systemd.

Experiencia de Operaciones

Quadlet a menudo gana en experiencia de operaciones en un anfitrión Linux. Razones:

• systemctl nativo
• journalctl nativo
• Servicios de usuario rootless
• Dependencias de systemd
• Temporizadores de systemd
• Comportamiento de reinicio de systemd
• Sin daemon central de Docker
• Mejor ajuste con la gestión de servicios del anfitrión

Un administrador de servidor puede razonar sobre:

systemctl status app.service
journalctl -u app.service -f
systemctl restart app.service

Ese es el flujo de trabajo normal de servicios de Linux.

Modelo de Seguridad

Notas de Seguridad de Docker Compose

Docker Compose generalmente habla con el daemon de Docker. En una instalación normal de Docker en Linux, el acceso al socket de Docker es potente. Un usuario que puede controlar Docker a menudo puede montar rutas del anfitrión, ejecutar contenedores privilegiados o de otro modo obtener un control amplio del anfitrión. Para opciones de instalación incluyendo Docker rootless en Ubuntu, consulta Instalar Docker en Ubuntu.

Consejo práctico:

• No expongas casualmente /var/run/docker.sock.
• Trata al grupo docker como privilegiado.
• Evita contenedores privilegiados.
• Evita montajes del anfitrión a menos que sean necesarios.
• Mantén los secretos fuera de Git.
• Usa etiquetas de imagen explícitas para servicios importantes.
• Revisa los puertos publicados.

Notas de Seguridad de Quadlet

Podman Quadlet se empareja bien con contenedores rootless y servicios systemd de usuario. Esto puede reducir el riesgo, especialmente en anfitriones compartidos o servidores personales donde los servicios no deberían requerir un daemon de root.

Consejo práctico:

• Prefiere servicios rootless cuando encajen.
• Usa unidades de usuario para servicios propiedad del usuario.
• Usa unidades de sistema solo cuando se necesiten privilegios a nivel de anfitrión.
• Evita contenedores privilegiados innecesarios.
• Mantén los archivos de entorno bloqueados.
• Piensa cuidadosamente sobre los montajes bind.

Rootless no significa libre de riesgo. Significa que el radio de explosión predeterminado puede ser más pequeño.

Rendimiento

Para la mayoría de los servicios web, herramientas internas y aplicaciones autohospedadas, el rendimiento no es el factor decisivo. Las diferencias principales son operativas, no de velocidad pura. Elige basado en el modelo de ciclo de vida, modelo de seguridad, integración con el anfitrión, familiaridad del equipo, proceso de actualización, necesidades de redes y flujo de trabajo de depuración.

Si estás eligiendo entre Compose y Quadlet solo por rendimiento, probablemente estás optimizando la capa incorrecta.

Modos de Fallo

Modos de Fallo de Docker Compose

Problemas comunes:

• Daemon de Docker no ejecutándose
• Plugin de Compose faltante
• Directorio de proyecto incorrecto
• .env no cargado como se esperaba
• Binario antiguo docker-compose usado por accidente
• Contenedores no recreados después de cambios de configuración
• Contenedores huérfanos dejados después de renombrar servicio
• Volúmenes eliminados con down -v
• Registros de Docker llenando el disco
• Errores de permiso del socket de Docker

Mejores soluciones:

docker compose config
docker compose ps
docker compose logs -f
docker compose up -d --remove-orphans

Modos de Fallo de Podman Quadlet

Problemas comunes:

• Archivo de unidad en el directorio incorrecto
• Olvidaste systemctl daemon-reload
• Usando unidades de sistema cuando se pretendían unidades de usuario
• Olvidaste loginctl enable-linger para servicios rootless
• La descarga de imagen toma más tiempo que el tiempo de espera de inicio de systemd
• cgroup v2 no disponible
• Etiquetas SELinux o permisos de volumen
• El nombre del servicio difiere de las expectativas del archivo
• Unidad de red o volumen no habilitada o referenciada correctamente

Mejores soluciones:

systemctl status app.service
journalctl -u app.service -f
systemctl daemon-reload
podman ps -a
podman logs container-name

Para rootless:

systemctl --user status app.service
journalctl --user -u app.service -f

Ejemplo de Migración: De Compose a Quadlet

Empieza con este servicio Compose:

services:
  whoami:
    image: traefik/whoami:v1.10
    restart: unless-stopped
    ports:
      - "8080:80"
    environment:
      WHOAMI_NAME: compose-demo

Ejecuta con Compose:

docker compose up -d

Un equivalente Quadlet aproximado:

[Unit]
Description=Contenedor demo Whoami
After=network-online.target
Wants=network-online.target

[Container]
Image=docker.io/traefik/whoami:v1.10
PublishPort=8080:80
Environment=WHOAMI_NAME=quadlet-demo

[Service]
Restart=always

[Install]
WantedBy=multi-user.target

Guarda como /etc/containers/systemd/whoami.container, entonces:

sudo systemctl daemon-reload
sudo systemctl enable --now whoami.service
sudo systemctl status whoami.service

El ejemplo es fácil porque es un solo contenedor. Una pila Compose más grande con bases de datos, redes, volúmenes y pasos de compilación necesita una traducción más cuidadosa.

Lista de Verificación de Migración

Antes de moverte de Compose a Quadlet, pregunta:

[ ] ¿Es esta pila realmente un conjunto de servicios de anfitrión de larga ejecución?
[ ] ¿Están las imágenes ya compiladas y publicadas?
[ ] ¿Necesito servicios rootless?
[ ] ¿Quiero dependencias y temporizadores de systemd?
[ ] ¿Están los volúmenes y montajes bind claramente entendidos?
[ ] ¿Están documentados los puertos?
[ ] ¿Se manejan los secretos fuera de Git?
[ ] ¿Existe un proceso de copia de seguridad y restauración?
[ ] ¿Puedo monitorear registros a través de journalctl?
[ ] ¿Tengo una ruta de rollback?

Si la mayoría de las respuestas son sí, Quadlet puede ser un buen ajuste. Si la pila es principalmente para desarrollo local, Compose probablemente sigue siendo mejor.

Cuando Permanecer con Docker Compose

Permanece con Compose cuando:

• El proyecto ya entrega un buen archivo Compose.
• Necesitas la vía de incorporación más fácil.
• Los desarrolladores ejecutan la misma pila localmente.
• Compilas imágenes durante el desarrollo.
• Quieres un solo archivo YAML para servicios, volúmenes y redes.
• Quieres la máxima compatibilidad con tutoriales y la comunidad.
• Tu envoltorio systemd actual funciona bien.

No hay premio por migrar una pila Compose funcional a Quadlet solo porque Quadlet es más limpio en teoría. Si Compose es aburrido y fiable para tu caso de uso, manténlo.

Cuando Moverse a Podman Quadlet

Múvete a Quadlet cuando:

• La pila es realmente un servicio de anfitrión.
• Quieres gestión de servicios rootless.
• Prefieres Podman sobre Docker.
• Quieres que systemd posea el ciclo de vida.
• Quieres registros de journalctl.
• Quieres dependencias de servicio.
• Quieres servicios de usuario que sobrevivan al cierre de sesión.
• Quieres menos exposición al daemon de Docker.
• Estás construyendo un anfitrión de autohospedaje alrededor de systemd.

Quadlet no es “Compose pero mejor”. Es un centro de diseño diferente.

Patrones Recomendados

Patrón 1: Desarrollo Local

Usa Docker Compose. Rápido, familiar, portable, fácil de reconstruir, fácil para equipos.

Patrón 2: Autohospedaje en un Solo Anfitrión

Usa cualquiera. Elige Compose si el proyecto ya proporciona un archivo Compose. Elige Quadlet si quieres gestión de servicios nativa de systemd. Compose da un mejor paquete de aplicación; Quadlet da un mejor servicio de Linux.

Patrón 3: Servicio Rootless Propiedad del Usuario

Usa Podman Quadlet. Flujo de trabajo rootless, gestión de servicios a nivel de usuario, sin daemon central de Docker.

~/.config/containers/systemd/app.container
systemctl --user enable --now app.service
loginctl enable-linger

Patrón 4: Servidor Único Similar a Producción

Usa Docker Compose con un envoltorio systemd disciplinado, o usa Quadlet si tu equipo está cómodo con Podman. No elijas basado en la moda. Elige basado en quién lo operará a las 2 AM.

Patrón 5: Plataforma Multi-Nodo

Usa ninguno como capa final de orquestación. Considera Kubernetes, Nomad, Swarm o una plataforma gestionada. Compose y Quadlet son herramientas excelentes para un solo anfitrión. No son planificadores de clúster.

Árbol de Decisión Práctico

¿Es esto principalmente para desarrollo local?
  sí:
    usa Docker Compose
  no:
    continúa

¿El proyecto ya proporciona un compose.yaml mantenido?
  sí:
    usa Docker Compose a menos que tengas una razón fuerte para migrar
  no:
    continúa

¿Quieres servicios de larga ejecución rootless gestionados por systemd?
  sí:
    usa Podman Quadlet
  no:
    continúa

¿Quieres la definición de aplicación multitenedor más fácil?
  sí:
    usa Docker Compose
  no:
    continúa

¿Quieres que los contenedores se comporten como servicios normales de Linux?
  sí:
    usa Podman Quadlet
  no:
    usa Docker Compose

Comandos Lado a Lado

Malentendidos Comunes

“Quadlet Reemplaza Docker Compose”

No exactamente. Quadlet reemplaza algunos casos de uso de Compose, especialmente servicios de Linux de larga ejecución. No reemplaza a Compose como el formato de pila de aplicaciones más fácil para desarrolladores.

“Docker Compose No Está Listo para Producción”

Demasiado amplio. Compose puede ser perfectamente razonable para sistemas de producción pequeños si entiendes copias de seguridad, actualizaciones, registros, comportamiento de reinicio y seguridad del anfitrión. El problema no es Compose. El problema es fingir que un despliegue Compose de un solo anfitrión tiene las mismas propiedades que un orquestador de clúster.

“Podman Es Solo Docker Sin el Daemon”

Demasiado simple. Podman tiene comandos compatibles con Docker, pero su centro de diseño es diferente: operación sin daemon, flujos de trabajo rootless, pods e integración con Linux.

“Rootless Significa Seguro”

No. Rootless reduce algunos riesgos. No hace que imágenes malas, secretos expuestos, montajes bind inseguros o aplicaciones vulnerables sean seguros.

“systemd Es Demasiado Pesado para Contenedores”

systemd ya es el gestor de servicios en la mayoría de los servidores Linux principales. Usarlo para gestionar contenedores de larga ejecución no es extraño. A menudo es la cosa aburrida y correcta que hacer.

Recomendación Final

Usa Docker Compose cuando la pila de aplicaciones sea lo principal. Usa Podman Quadlet cuando el servicio de Linux sea lo principal.

Esa distinción es más útil que discutir qué herramienta es mejor. Para flujos de trabajo de desarrolladores, Compose es difícil de vencer. Es popular, legible, portable y soportado por innumerables proyectos. Para servicios de Linux de larga ejecución, Quadlet es silenciosamente excelente. Hace que los contenedores se sientan como servicios nativos de systemd, funciona naturalmente con Podman rootless y se ajusta al modelo operativo de un anfitrión Linux serio.

La división preferida:

Desarrollo local: Docker Compose
Ejemplos de aplicaciones portátiles: Docker Compose
Pilas autohospedadas pequeñas: Docker Compose o Quadlet
Servicios de usuario rootless: Podman Quadlet
Servicios de anfitrión de larga ejecución: Podman Quadlet
Orquestación multi-nodo: ninguno; usa un orquestador real

No migres solo para estar al día. Migra cuando el modelo de ciclo de vida sea mejor. Compose es una gran herramienta de pilas. Quadlet es una gran herramienta de servicios. La elección inteligente es usar cada uno donde su modelo mental coincida con el trabajo.

Referencias

• Documentación de Podman Quadlet — referencia oficial de Podman Quadlet
• Documentación de Docker Compose — referencia oficial de Docker Compose
• Ejecutar Docker Compose como un Servicio de Linux con systemd — guía detallada de Compose-como-systemd en este sitio
• Hoja de Trucos de Docker Compose — referencia de comandos y patrones de Compose
• Hoja de Trucos de Docker — referencia de comandos de Docker
• Instalar Docker en Ubuntu — guía de instalación de Docker con alternativas rootless
• Ejecutar cualquier ejecutable como servicio en Linux — patrones generales de servicios systemd
• Herramientas de Desarrollo: La Guía Completa para Flujos de Trabajo Modernos — página principal del clúster