Podman Quadlet vs Docker Compose per i servizi Linux

Docker Compose e Podman Quadlet risolvono problemi sovrapposti ma provengono da centri di progettazione diversi, e la scelta tra i due dipende dal fatto che si pensi in termini di stack di applicazioni o di servizi Linux.

Questa distinzione è importante per chiunque esegua container su un host Linux oltre a un semplice pomeriggio di sperimentazione. Compose descrive servizi, reti e volumi in un file YAML e li avvia con docker compose up. Quadlet descrive i container in file di unità in stile systemd e permette al gestore dei servizi del sistema di gestire il ciclo di vita.

Entrambi gli approcci funzionano per servizi self-hosted, strumenti interni e server di piccole dimensioni. La scelta giusta dipende dal modello operativo, dalla familiarità del team e dalla preferenza per un formato di stack orientato agli sviluppatori o per un modello di servizio nativo di systemd. Questo confronto copre le differenze pratiche: formati dei file, gestione del ciclo di vita, container rootless, registrazione dei log, aggiornamenti, rete, sicurezza e percorsi di migrazione. Fa parte di Strumenti per sviluppatori: La guida completa ai flussi di lavoro di sviluppo moderni.

Raccomandazione rapida

Usa Docker Compose quando:

• Vuoi il flusso di lavoro multi-container più veloce.
• Usi già Docker Engine.
• Condividi stack con altri sviluppatori.
• Hai bisogno di un familiare compose.yaml per lo sviluppo locale.
• Distribuisci piccoli servizi con Docker su un singolo host.
• Usi esempi Compose esistenti da progetti.

Usa Podman Quadlet quando:

• Vuoi servizi container nativi di systemd.
• Preferisci i container rootless.
• Non vuoi un demone Docker centrale.
• Esegui servizi a lunga esecuzione su un host Linux.
• Vuoi systemctl, journalctl, timer, dipendenze e avvio automatico.
• Stai costruendo un server self-hosted o homelab basato su systemd.
• Vuoi che i container si integrino nel modello di servizio Linux standard.

La regola pratica è:

Docker Compose è meglio per gli stack di applicazioni.
Podman Quadlet è meglio per i servizi Linux.

Non è una legge. È un’impostazione predefinita utile.

Tabella di confronto

Nessuno dei due è Kubernetes. La maggior parte dei servizi piccoli non ha bisogno di un cluster. Hanno bisogno di un modo noioso e comprensibile per avviare, fermare, aggiornare, registrare i log e recuperare.

In cosa Docker Compose è bravo

Docker Compose è uno strumento per definire ed eseguire applicazioni multi-container. Un file Compose tipico descrive servizi, immagini, contesti di build, porte, volumi, reti, variabili d’ambiente, health check, dipendenze e profili.

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

Eseguilo:

docker compose up -d

Controlla lo stato:

docker compose ps

Leggi i log:

docker compose logs -f

Fermalo:

docker compose down

Compose è diretto e produttivo. È particolarmente buono quando l’unità di pensiero è “questa applicazione ha diversi container”. Per un riferimento completo dei comandi e dei modelli di Compose, vedi il Cheat sheet di Docker Compose. Per i comandi Docker oltre a Compose — immagini, volumi, reti e pulizia — vedi il Cheat sheet di Docker.

In cosa Podman Quadlet è bravo

Podman Quadlet è un modo per definire i container Podman usando file in stile systemd. Invece di scrivere manualmente un servizio systemd completo generato, si scrive un file dichiarativo:

[Unit]
Description=Example web container
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

Salvalo come /etc/containers/systemd/example.container, poi ricarica systemd:

sudo systemctl daemon-reload

Avvialo:

sudo systemctl enable --now example.service

Controllalo:

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

L’aspetto principale di Quadlet: il container diventa un normale servizio Linux.

La differenza filosofica

Docker Compose pensa in Stack

Compose chiede: Quali servizi compongono questa applicazione?

Un progetto Compose di solito vive vicino al codice dell’applicazione:

myapp/
  compose.yaml
  .env
  app/
  db/

Avvii il progetto come un’unità:

docker compose up -d

Aggiorni il progetto come un’unità:

docker compose pull
docker compose up -d

Questo è semplice, visibile e portabile.

Podman Quadlet pensa in Servizi

Quadlet chiede: Quali container questo host Linux dovrebbe eseguire come servizi?

I file Quadlet vivono nei percorsi dei container relativi a systemd:

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

Gestisci i servizi generati con systemd:

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

Questo sembra più nativo su un server Linux. Per i modelli di servizio systemd in generale, vedi Esegui qualsiasi eseguibile come servizio in Linux.

La differenza importante: Chi gestisce il ciclo di vita?

Con Docker Compose, Compose gestisce il ciclo di vita dell’applicazione. Con Quadlet, systemd gestisce il ciclo di vita del servizio.

Questo influenza il comportamento di avvio, il comportamento di arresto, la politica di riavvio, l’ordinamento delle dipendenze, i log, la visibilità dello stato di salute, i servizi utente, gli aggiornamenti, l’integrazione con i timer e l’integrazione con altri servizi dell’host.

Se usi già systemd per gestire tutto il resto sull’host, Quadlet si integra perfettamente. Se pensi principalmente in termini di stack di applicazioni, Compose è di solito più confortevole.

Docker Compose sotto systemd vs Quadlet

Puoi eseguire Docker Compose come servizio systemd. Spesso è un buon modello. Esempio di unità systemd:

[Unit]
Description=MyApp Docker Compose stack
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

Questo funziona bene. Ma è ancora un wrapper intorno a Compose. systemd avvia il comando Compose, mentre Docker e Compose gestiscono i container dietro le quinte.

Con Quadlet, la generazione delle unità è progettata per Podman e systemd direttamente. Si scrivono file di unità orientati ai container e systemd gestisce i servizi generati.

La distinzione è sottile ma importante:

Docker Compose sotto systemd:
  systemd gestisce un comando Compose.

Podman Quadlet:
  systemd gestisce i servizi container generati.

Per un’esplorazione dettagliata di questo modello, vedi Esegui Docker Compose come servizio Linux con systemd.

Confronto dei formati dei file

YAML di Docker Compose

Compose usa YAML. È compatto, popolare e facile da condividere. È anche sensibile agli spazi bianchi e può diventare disordinato quando uno stack diventa 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:

File di unità Quadlet

Quadlet usa file simili a systemd. Sono più verbosi quando hai molti servizi, ma leggibili se conosci già systemd.

[Unit]
Description=Example app container
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

E un file di volume:

[Volume]
VolumeName=app-data

Salvati come app.container e app-data.volume nella directory dei container systemd appropriata.

Mappatura dei concetti di Docker Compose in Quadlet

La migrazione è concettualmente semplice ma non meccanica. Compose descrive uno stack. Quadlet descrive servizi.

Container Rootless

I container rootless sono uno dei motivi più forti per guardare a Podman e Quadlet.

Con Docker, molti utenti si aggiungono al gruppo docker. È conveniente, ma l’accesso al demone Docker è efficacemente un accesso potente all’host. Su una workstation personale, ciò può essere accettabile. Su server condivisi, merita più cautela.

Podman è stato progettato con l’uso rootless come flusso di lavoro di prima classe. Un Quadlet rootless vive nella directory di configurazione dell’utente:

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

Poi gestiscilo con systemd utente:

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

Per permettere al servizio utente di continuare a funzionare dopo il logout:

sudo loginctl enable-linger "$USER"

Questo è un modello pulito per servizi posseduti dall’utente.

Confronto Rootless

Rootless non è magia. Ha compromessi riguardo alla rete, al comportamento privilegiato e alle porte basse. Ma per servizi a lunga esecuzione posseduti dall’utente, Quadlet è un modello molto elegante.

Avvio e comportamento al boot

Docker Compose

Compose da solo non crea un servizio di avvio. Di solito ci si affida alle politiche di riavvio di Docker, a un wrapper systemd intorno a docker compose up -d, a uno script di distribuzione o a uno strumento di livello superiore.

Esempio di politica di riavvio Compose:

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

Un wrapper systemd ti dà un servizio a livello di host. Questo è buono, ma è ancora un wrapper extra. Vedi Esegui Docker Compose come servizio Linux con systemd per il modello completo.

Podman Quadlet

Quadlet è già orientato a systemd. Abilita all’avvio:

sudo systemctl enable myapp.service

Per rootless:

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

Il comportamento di avvio non è un’aggiunta. È il modello.

Comportamento di riavvio

Compose usa comunemente restart: unless-stopped in YAML. Quadlet usa comunemente il comportamento di riavvio di systemd:

[Service]
Restart=always

Oppure:

[Service]
Restart=on-failure

Questo spinge la logica di riavvio nel gestore dei servizi. La preferenza: usa le politiche di riavvio di Compose/Docker per gli stack Compose, usa le politiche di riavvio di systemd per Quadlet e non impilare troppi supervisori. Mantieni un proprietario chiaro del comportamento di riavvio.

Confronto dei log

Log di Docker Compose

docker compose logs -f
docker compose logs -f app

Questo è eccellente per gli sviluppatori.

Log di Quadlet

I servizi Quadlet usano i log di systemd:

journalctl -u app.service -f

Per unità rootless:

journalctl --user -u app.service -f

Puoi ancora usare i log di Podman:

podman logs -f container-name

Per le operazioni del server, l’integrazione con journalctl è un grande vantaggio. I tuoi container si integrano nello stesso flusso di lavoro dei log degli altri servizi Linux.

Aggiornamenti

Aggiornamento di Docker Compose

Un flusso di aggiornamento comune:

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

Facile da avvolgere in uno 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

Aggiornamento di Podman Quadlet

Un flusso manuale semplificato:

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

Oppure per rootless:

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

Podman può supportare flussi di lavoro di aggiornamento automatico quando i container sono configurati con le etichette e la politica delle immagini giuste. Il vantaggio di Quadlet non è che gli aggiornamenti siano sempre più semplici. Il vantaggio è che gli aggiornamenti sono nativi del gestore dei servizi.

Filosofia degli aggiornamenti automatici

Gli aggiornamenti automatici sono convenienti. Sono anche un rischio. Per servizi homelab a basso rischio, gli aggiornamenti automatici dei container possono andare bene. Per database, app con stato o servizi aziendali, il flusso preferito è:

1. Backup.
2. Pull.
3. Ricrea o riavvia.
4. Controlla la salute.
5. Pulisci dopo.

Compose rende questo esplicito. Quadlet e Podman possono renderlo nativo di systemd. Nessuno dei due strumenti elimina la necessità di un piano di rollback.

Volumi e dati persistenti

Volumi Compose

Compose supporta volumi nominati:

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

volumes:
  db-data:

E bind mount:

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

Volumi Quadlet

Quadlet può usare bind mount:

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

Oppure un file .volume:

[Volume]
VolumeName=app-data

Poi riferiscilo:

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

Compose è più compatto per lo storage a livello di stack. Quadlet è più allineato con unità di servizio gestite in modo indipendente.

Segreti e file di ambiente

Compose

Compose spesso usa env_file o environment in YAML. Per un piccolo servizio privato, .env è comune. Per sistemi seri, tratta .env come sensibile e tienilo fuori da Git.

Quadlet

Quadlet può usare:

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

Restringi i permessi:

chmod 600 /opt/app/app.env

Né Compose né Quadlet sono un sistema completo di gestione dei segreti di per sé. Non confondere “non nella riga di comando” con “sicuro”.

Rete

Rete Compose

Compose crea una rete di progetto predefinita e dà ai servizi nomi DNS basati sui nomi dei servizi:

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

  db:
    image: postgres:16

L’app può di solito raggiungere il database su db. La rete multi-container dell’app sembra naturale. Questa è una delle caratteristiche più forti di Compose.

Rete Quadlet

Quadlet può definire reti separatamente con file .network o usare le opzioni di rete di Podman:

[Network]
NetworkName=appnet

File del container:

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

Questo è più esplicito e simile a systemd. Per uno o due container, va bene. Per un grande stack di app, Compose è spesso più facile da leggere.

Pod

Podman ha un concetto di pod nativo. Questo è importante se ti piace il modello mentale di Kubernetes dove più container condividono uno spazio dei nomi di rete e un confine del ciclo di vita. Quadlet supporta i file .pod:

[Pod]
PodName=myapp
PublishPort=8080:8080

Un container può unirsi a quel pod:

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

Compose non ha lo stesso modello di pod. Ha servizi su reti. Per la maggior parte delle semplici app web, le reti Compose sono sufficienti. Per gli utenti di Podman che apprezzano il raggruppamento in stile pod, Quadlet è una corrispondenza migliore.

Flussi di lavoro di build

Compose è di solito migliore quando si costruiscono immagini come parte del flusso di lavoro dell’applicazione locale:

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

Poi:

docker compose up --build

Questo è estremamente conveniente per lo sviluppo. Quadlet è di solito migliore quando si eseguono immagini già costruite come servizi. Costruisci le immagini con Podman separatamente:

podman build -t localhost/myapp:latest .

Poi riferisci l’immagine:

[Container]
Image=localhost/myapp:latest

Se il tuo flusso di lavoro è “modifica codice, ricostruisci, riavvia stack”, Compose vince. Se il tuo flusso di lavoro è “distribuisci un’immagine nota come servizio Linux”, Quadlet vince.

Portabilità

I file Compose sono ampiamente condivisi. Molti progetti open-source forniscono un compose.yaml o docker-compose.yml. Se un progetto dice “esegui questo con Docker Compose”, di solito puoi iniziare rapidamente con docker compose up -d. Questo è un grande vantaggio pratico.

Quadlet è portabile tra sistemi che hanno Podman, systemd e supporto Quadlet compatibile. Questo è un target più ristretto, ma molto buono per i server Linux moderni. Quadlet non è il formato migliore per condividere un’applicazione con ogni possibile sviluppatore. È un buon formato per descrivere come un host Linux specifico dovrebbe eseguire un servizio containerizzato.

Esperienza dello sviluppatore

Docker Compose vince di solito l’esperienza dello sviluppatore. Più esempi, più tutorial, più template di progetto, build locali più facili, stack in un solo file facile, familiare docker compose up e forte adattamento per le dipendenze di sviluppo. Uno sviluppatore può leggere questo rapidamente:

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

Quadlet può fare cose simili, ma è più orientato alle operazioni. Per lo sviluppo locale, raramente inizierei con Quadlet a meno che l’applicazione stessa non sia specificamente su Podman o systemd.

Esperienza delle operazioni

Quadlet vince spesso l’esperienza delle operazioni su un host Linux. Motivi:

• systemctl nativo
• journalctl nativo
• Servizi utente rootless
• Dipendenze systemd
• Timer systemd
• Comportamento di riavvio di systemd
• Nessun demone Docker centrale
• Migliore integrazione con la gestione dei servizi dell’host

Un amministratore del server può ragionare su:

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

Questo è il normale flusso di lavoro dei servizi Linux.

Modello di sicurezza

Note sulla sicurezza di Docker Compose

Docker Compose di solito parla con il demone Docker. Su un’installazione Docker Linux normale, l’accesso al socket Docker è potente. Un utente che può controllare Docker può spesso montare percorsi dell’host, eseguire container privilegiati o altrimenti ottenere un controllo ampio dell’host. Per le opzioni di installazione tra cui Docker rootless su Ubuntu, vedi Installa Docker su Ubuntu.

Consigli pratici:

• Non esporre casualmente /var/run/docker.sock.
• Tratta il gruppo docker come privilegiato.
• Evita container privilegiati.
• Evita mount dell’host a meno che non siano necessari.
• Tieni i segreti fuori da Git.
• Usa tag delle immagini espliciti per i servizi importanti.
• Rivedi le porte pubblicate.

Note sulla sicurezza di Quadlet

Podman Quadlet si abbina bene con i container rootless e i servizi systemd utente. Questo può ridurre il rischio, soprattutto su host condivisi o server personali dove i servizi non dovrebbero richiedere un demone root.

Consigli pratici:

• Preferisci servizi rootless quando si adattano.
• Usa unità utente per servizi posseduti dall’utente.
• Usa unità di sistema solo quando sono necessari privilegi a livello di host.
• Evita container privilegiati non necessari.
• Tieni i file di ambiente bloccati.
• Pensa attentamente ai bind mount.

Rootless non significa privo di rischi. Significa che il raggio d’esplosione predefinito può essere più piccolo.

Prestazioni

Per la maggior parte dei servizi web, strumenti interni e app self-hosted, le prestazioni non sono il fattore decisivo. Le principali differenze sono operative, non velocità pura. Scegli in base al modello di ciclo di vita, al modello di sicurezza, all’integrazione con l’host, alla familiarità del team, al processo di aggiornamento, alle esigenze di rete e al flusso di lavoro di debug.

Se stai scegliendo tra Compose e Quadlet solo per le prestazioni, probabilmente stai ottimizzando lo strato sbagliato.

Modalità di errore

Modalità di errore di Docker Compose

Problemi comuni:

• Demone Docker non in esecuzione
• Plugin Compose mancante
• Directory del progetto errata
• .env non caricato come previsto
• Binario docker-compose vecchio usato per errore
• Container non ricreati dopo le modifiche alla configurazione
• Container orfani lasciati dopo la rinomina del servizio
• Volumi eliminati con down -v
• Log di Docker che riempiono il disco
• Errori di autorizzazione del socket Docker

Migliori correzioni:

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

Modalità di errore di Podman Quadlet

Problemi comuni:

• File di unità nella directory sbagliata
• Dimenticato systemctl daemon-reload
• Uso di unità di sistema quando erano intese unità utente
• Dimenticato loginctl enable-linger per servizi rootless
• Il pull dell’immagine richiede più tempo del timeout di avvio di systemd
• cgroup v2 non disponibile
• Etichette SELinux o autorizzazioni dei volumi
• Nome del servizio diverso dalle aspettative del file
• Unità di rete o volume non abilitata o riferita correttamente

Migliori correzioni:

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

Per rootless:

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

Esempio di migrazione: da Compose a Quadlet

Inizia con questo servizio Compose:

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

Esegui con Compose:

docker compose up -d

Un equivalente Quadlet approssimativo:

[Unit]
Description=Whoami demo container
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

Salva come /etc/containers/systemd/whoami.container, poi:

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

L’esempio è facile perché è un solo container. Uno stack Compose più grande con database, reti, volumi e passaggi di build ha bisogno di una traduzione più attenta.

Checklist di migrazione

Prima di passare da Compose a Quadlet, chiedi:

[ ] Questo stack è davvero un insieme di servizi host a lunga esecuzione?
[ ] Le immagini sono già costruite e pubblicate?
[ ] Ho bisogno di servizi rootless?
[ ] Voglio dipendenze e timer systemd?
[ ] Volumi e bind mount sono chiaramente compresi?
[ ] Le porte sono documentate?
[ ] I segreti sono gestiti al di fuori di Git?
[ ] C'è un processo di backup e ripristino?
[ ] Posso monitorare i log attraverso journalctl?
[ ] Ho un percorso di rollback?

Se la maggior parte delle risposte è sì, Quadlet potrebbe essere una buona scelta. Se lo stack è principalmente per lo sviluppo locale, Compose è probabilmente ancora migliore.

Quando restare con Docker Compose

Resta con Compose quando:

• Il progetto fornisce già un buon file Compose.
• Hai bisogno del percorso di onboarding più semplice.
• Gli sviluppatori eseguono lo stesso stack localmente.
• Costruisci immagini durante lo sviluppo.
• Vuoi un file YAML per servizi, volumi e reti.
• Vuoi la massima compatibilità con tutorial e comunità.
• Il tuo wrapper systemd attuale funziona bene.

Non c’è premio per migrare uno stack Compose funzionante a Quadlet solo perché Quadlet è più pulito in teoria. Se Compose è noioso e affidabile per il tuo caso d’uso, tienilo.

Quando passare a Podman Quadlet

Passa a Quadlet quando:

• Lo stack è davvero un servizio host.
• Vuoi la gestione dei servizi rootless.
• Preferisci Podman rispetto a Docker.
• Vuoi che systemd gestisca il ciclo di vita.
• Vuoi i log journalctl.
• Vuoi dipendenze di servizio.
• Vuoi servizi utente che sopravvivono al logout.
• Vuoi meno esposizione al demone Docker.
• Stai costruendo un host di self-hosting intorno a systemd.

Quadlet non è “Compose ma migliore”. È un centro di progettazione diverso.

Modelli raccomandati

Modello 1: Sviluppo locale

Usa Docker Compose. Veloce, familiare, portatile, facile da ricostruire, facile per i team.

Modello 2: Self-hosting su singolo host

Usa entrambi. Scegli Compose se il progetto fornisce già un file Compose. Scegli Quadlet se vuoi la gestione dei servizi nativa di systemd. Compose dà un bundle di app migliore; Quadlet dà un servizio Linux migliore.

Modello 3: Servizio rootless posseduto dall’utente

Usa Podman Quadlet. Flusso di lavoro rootless, gestione dei servizi a livello utente, nessun demone Docker centrale.

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

Modello 4: Server singolo simile alla produzione

Usa Docker Compose con un wrapper systemd disciplinato, o usa Quadlet se il tuo team è a suo agio con Podman. Non scegliere in base alla moda. Scegli in base a chi lo gestirà alle 2 del mattino.

Modello 5: Piattaforma multi-nodo

Usa nessuno dei due come strato finale di orchestrazione. Considera Kubernetes, Nomad, Swarm o una piattaforma gestita. Compose e Quadlet sono eccellenti strumenti per singolo host. Non sono scheduler di cluster.

Albero decisionale pratico

Questo è principalmente per lo sviluppo locale?
  sì:
    usa Docker Compose
  no:
    continua

Il progetto fornisce già un compose.yaml mantenuto?
  sì:
    usa Docker Compose a meno che tu non abbia un motivo forte per migrare
  no:
    continua

Vuoi servizi a lunga esecuzione rootless gestiti da systemd?
  sì:
    usa Podman Quadlet
  no:
    continua

Vuoi la definizione di app multi-container più facile?
  sì:
    usa Docker Compose
  no:
    continua

Vuoi che i container si comportino come normali servizi Linux?
  sì:
    usa Podman Quadlet
  no:
    usa Docker Compose

Comandi affiancati

Incomprensioni comuni

“Quadlet sostituisce Docker Compose”

Non esattamente. Quadlet sostituisce alcuni casi d’uso di Compose, soprattutto servizi Linux a lunga esecuzione. Non sostituisce Compose come formato di stack di applicazioni più facile per gli sviluppatori.

“Docker Compose non è pronto per la produzione”

Troppo ampio. Compose può essere perfettamente ragionevole per sistemi di produzione piccoli se si capiscono backup, aggiornamenti, registrazione dei log, comportamento di riavvio e sicurezza dell’host. Il problema non è Compose. Il problema è fingere che una distribuzione Compose su singolo host abbia le stesse proprietà di un orchestratore di cluster.

“Podman è solo Docker senza demone”

Troppo semplice. Podman ha comandi compatibili con Docker, ma il suo centro di progettazione è diverso: operazione senza demone, flussi di lavoro rootless, pod e integrazione Linux.

“Rootless significa sicuro”

No. Rootless riduce alcuni rischi. Non rende le immagini cattive, i segreti esposti, i bind mount non sicuri o le app vulnerabili sicure.

“systemd è troppo pesante per i container”

systemd è già il gestore dei servizi sulla maggior parte dei server Linux mainstream. Usarlo per gestire container a lunga esecuzione non è strano. Spesso è la cosa noiosa e corretta da fare.

Raccomandazione finale

Usa Docker Compose quando lo stack di applicazioni è la cosa principale. Usa Podman Quadlet quando il servizio Linux è la cosa principale.

Questa distinzione è più utile che argomentare quale strumento sia migliore. Per i flussi di lavoro degli sviluppatori, Compose è difficile da battere. È popolare, leggibile, portabile e supportato da innumerevoli progetti. Per i servizi Linux a lunga esecuzione, Quadlet è tranquillamente eccellente. Rende i container simili a servizi systemd nativi, funziona naturalmente con Podman rootless e si adatta al modello operativo di un host Linux serio.

La divisione preferita:

Sviluppo locale: Docker Compose
Esempi di app portatili: Docker Compose
Stack self-hosted piccoli: Docker Compose o Quadlet
Servizi utente rootless: Podman Quadlet
Servizi host a lunga esecuzione: Podman Quadlet
Orchestrazione multi-nodo: nessuno dei due; usa un orchestratore reale

Non migrare solo per essere moderni. Migra quando il modello di ciclo di vita è migliore. Compose è uno grande strumento di stack. Quadlet è un grande strumento di servizio. La scelta intelligente è usare ciascuno dove il suo modello mentale corrisponde al lavoro.

Riferimenti

• Documentazione Podman Quadlet — riferimento ufficiale Podman Quadlet
• Documentazione Docker Compose — riferimento ufficiale Docker Compose
• Esegui Docker Compose come servizio Linux con systemd — esplorazione dettagliata di Compose come systemd su questo sito
• Cheat sheet di Docker Compose — riferimento comandi e modelli Compose
• Cheat sheet di Docker — riferimento comandi Docker
• Installa Docker su Ubuntu — guida all’installazione di Docker con alternative rootless
• Esegui qualsiasi eseguibile come servizio in Linux — modelli di servizio systemd generali
• Strumenti per sviluppatori: La guida completa ai flussi di lavoro di sviluppo moderni — home del cluster