Podman: l’alternativa a Docker che ogni sysadmin Linux dovrebbe conoscere
Per anni Docker è stato il default indiscusso quando si parlava di container su Linux. Ma l’architettura basata su un daemon centrale che gira come root ha sempre lasciato sul tavolo un problema di superficie d’attacco: se qualcuno compromette dockerd, ha di fatto accesso root all’intero host. Podman nasce proprio per chiudere questo gap, offrendo un motore container daemonless, compatibile con le immagini OCI e con la CLI Docker, che si integra in modo molto più nativo con systemd e con il modello di permessi di Linux.
Vediamo come installarlo, come si differenzia realmente da Docker oltre gli slogan, e come portarlo in produzione con systemd e le Quadlet, che sono probabilmente la ragione migliore per prenderlo sul serio.
Cos’è Podman, in pratica
Podman (da Pod Manager) è un motore container open source senza demone centrale. Ogni container gira come processo figlio dell’utente che lo ha avviato, non come figlio di un servizio di sistema con privilegi elevati. Questo significa che è possibile eseguire container completamente rootless, senza mai invocare sudo, riducendo drasticamente cosa un container compromesso può effettivamente toccare sull’host.
Sotto il cofano Podman usa gli stessi runtime OCI di Docker e parla lo stesso formato immagine, quindi la stragrande maggioranza dei comandi Docker funziona invariata sostituendo semplicemente il nome del binario (o creando un alias docker=podman, oppure installando il pacchetto podman-docker che fa da shim trasparente).
Un concetto che Docker non ha nativamente è quello di pod: gruppi di uno o più container che condividono rete e storage, concettualmente vicini ai pod di Kubernetes. Comodo quando si vogliono far girare insieme più container che devono comunicare come se fossero sulla stessa macchina.
Installazione
# Debian/Ubuntu (Debian 11+, Ubuntu 20.10+)
sudo apt-get update
sudo apt-get -y install podman
# Fedora/CentOS/RHEL 8+
sudo dnf -y install podman
# openSUSE
sudo zypper install podman
# Arch/Manjaro
sudo pacman -S podman
Verifica dell’installazione:
podman --version
podman info
podman run hello-world
Se l’ultimo comando restituisce il messaggio di benvenuto di Podman, l’installazione è a posto.
Uso quotidiano: i comandi non cambiano quasi nulla
Shell interattiva dentro un container Ubuntu:
podman run -it ubuntu bash
Servizio in background, con Nginx esposto sulla porta 8080 dell’host:
podman run -d --name web -p 8080:80 nginx
podman ps
Il resto della CLI ricalca Docker praticamente 1:1: podman pull, podman images, podman stop/start, podman rm/rmi. Dietro le quinte, podman build è in realtà un wrapper attorno a Buildah, mentre lo spostamento di immagini tra registry passa per Skopeo: strumenti separati che Podman orchestra per te, senza che serva conoscerli nel dettaglio per l’uso base.
Dove Docker e Podman divergono davvero
La compatibilità è alta ma non totale, e i problemi emergono quasi sempre dal modello rootless. Il caso più comune sono i bind mount: poiché i container rootless usano user namespace e mapping subuid/subgid, una directory montata dall’host non sempre ha la proprietà che il container si aspetta. Su sistemi con SELinux attivo serve anche il suffisso :z o :Z per far ri-etichettare correttamente i file:
podman run -v /host/path:/container/path:Z myimage
:z minuscolo condivide il volume tra più container, :Z maiuscolo lo rende privato per un singolo container. Se serve far coincidere esattamente la proprietà con quella dell’host, l’opzione --uidmap permette un controllo fine, oppure si può far girare il container in modalità rootful per replicare il comportamento di Docker.Altri attriti da conoscere prima di migrare: l’accesso GPU da container rootless è limitato (NVIDIA richiede nvidia-container-toolkit e setup CDI, con i container da ricreare a ogni aggiornamento driver), e i Docker secrets insieme ad alcune configurazioni di rete non hanno una corrispondenza 1:1. Niente di bloccante, ma va testato prima di assumere che la migrazione sia un semplice “find and replace”.
Container come servizi systemd: le Quadlet
Questo è probabilmente il motivo migliore per scegliere Podman in un contesto server. Invece di lasciare un demone in background a gestire lo stato dei container, si delega tutto a systemd, che diventa responsabile di avvio, riavvio e supervisione, esattamente come per qualsiasi altro servizio di sistema.
Il meccanismo si chiama Quadlet: un file dichiarativo con estensione .container che Podman traduce automaticamente in una unit systemd. Per un servizio utente rootless, il file va in ~/.config/containers/systemd/. Esempio minimo per Nginx:
[Container]
ContainerName=web
Image=docker.io/library/nginx:latest
PublishPort=8080:80
[Install]
WantedBy=default.target
Attivazione:
systemctl --user daemon-reload
systemctl --user start web
Da questo momento il container è gestito da systemd come un servizio qualsiasi: si riavvia in caso di crash, si integra con i log di journald, si può abilitare al boot. Aggiungendo l’etichetta AutoUpdate=registry a un container, inoltre, podman auto-update può controllare periodicamente nuove versioni dell’immagine e riavviare il servizio in automatico, senza bisogno di Watchtower o strumenti equivalenti.
Migrare da Docker Compose
Chi ha un’infrastruttura basata su Compose ha due strade percorribili. La prima è continuare a usare Compose così com’è: il binario standalone docker compose può puntare al socket di Podman senza toccare i file docker-compose.yml esistenti:
systemctl --user enable --now podman.socket
La seconda è convertire i file Compose in Quadlet, così che sia systemd a gestire tutto nativamente. Scrivere le unit a mano è tedioso, quindi conviene usare podlet, un tool che legge un docker-compose.yml e genera i file Quadlet corrispondenti. C’è una curva di apprendimento, ma è comunque più veloce che partire da zero.
Docker resta rilevante
Nonostante i vantaggi di Podman, Docker non sta scomparendo. L’ecosistema attorno a Docker (Compose, Swarm, e tutta la tooling che si integra con esso, inclusi molti sistemi CI/CD già configurati per il socket Docker) resta enorme, e non tutte le piattaforme gestiscono bene le peculiarità rootless di Podman. Se un team è già standardizzato su Docker, spesso ha più senso restare sull’esistente piuttosto che affrontare una migrazione per un guadagno marginale.
Dove Podman convince davvero è quando si parte da zero: setup più sicuro per default, nessun demone da tenere sotto controllo, integrazione diretta con systemd per la gestione del ciclo di vita dei servizi.
Conclusione
Podman è un motore container completo, compatibile con Docker, che funziona senza demone e senza bisogno di privilegi root. Per l’uso quotidiano è quasi un drop-in replacement: si installa dal repository della distribuzione, si usano gli stessi comandi (o si crea l’alias docker=podman), e si ottengono benefici di sicurezza concreti senza dover reimparare nulla. I limiti di compatibilità, soprattutto su bind mount, GPU e secrets, vanno conosciuti e testati prima di una migrazione in produzione, ma per chi sta impostando nuovi ambienti containerizzati su Linux, specialmente se pensa di gestirli con systemd e Quadlet, vale decisamente la pena valutarlo.
Fonte originale: Hayden James, “Docker Alternative: Podman on Linux”, LinuxBlog.io.
This article is inspired by our LinuxCommunity.io forum discussion thread (thanks to users @tmick and @shybry747 for the feedback). Let's walk through
Hayden James (LinuxBlog.io)
Ricarica dallo 0 all'80% in soli 18 minuti per poter effettuare fino a tre ore di riprese
Techpertutti.comGuglielmo Sbano
Registrazione istantanea: ruota il touchscreen per accendere e iniziare a registrare rapidamente
Osmo Pocket 4P è compatibile con una versatile gamma di accessori dell'ecosistema Osmo, per consentirti di ampliare le possibilità creative
Techpertutti.comGuglielmo Sbano
Techpertutti.comGuglielmo Sbano
Cultura
in reply to Semplicemente D. • • •sucaminu
in reply to Semplicemente D. • • •In una sala climatizzata della biblioteca c'è un volume ormai impossibile da consultare se non sei un barone universitario o un alto prelato: il celebre palinsesto contenente le Istituzioni di Gaio.
In quel codice, sotto le righe di un trattato di San Girolamo trascritto nel Medioevo, sono riemersi i caratteri più sottili di un testo giuridico romano, risalente a centinaia di anni prima.
Nel 1816 lo studioso Niebuhr (una sorta di Angelo Mai teutonico) lo scoprì quasi per caso, usando reagenti chimici aggressivi pur di leggerlo e rischiando di distruggerlo."
Durante i bombardamenti del 1945 che rasero al suolo metà della biblioteca, il manoscritto non era lì, perché il monsignore dell'epoca lo aveva caricato a spalla dentro una sacca di tela insieme ai codici più preziosi, portandolo a piedi in una canonica di campagna per salvarlo dalla concreta possibilità dei bombardamenti (Verona infatti era uno snodo strategico perché è l'ultima città italiana prima di addentrarsi nella valle dell'Adige-Isarco, ossia il corridoio principale tra l'Italia e la Germania).
La biblioteca Capitolare non è solo un cimitero di libri antichi, ma una staffetta generazionale e un luogo dove le persone hanno rischiato (a volte hanno letteralmente rischiato la vita) per consegnarci un pezzo di memoria del mondo antico.