Installare Podman su AlmaLinux 8 e 9 per eseguire container

Su AlmaLinux 8 e 9 Podman è la scelta più lineare se vuoi eseguire container senza dipendere da un demone centrale. Il punto non è solo “installarlo”, ma farlo funzionare in modo coerente con SELinux, con lo storage locale e con l’esecuzione rootless, che è la modalità che in produzione ti evita parecchi problemi inutili. La differenza pratica tra 8 e 9 non è tanto nel concetto, quanto nelle versioni disponibili, nei pacchetti di supporto e in qualche dettaglio di integrazione con systemd e networking.

© TrgtKLS • Tech, Sicurezza e Strumenti & guide per Webmaster — https://trgtkls.it — tutti i diritti riservati.

Perché Podman su AlmaLinux è una scelta sensata

Podman gira bene su AlmaLinux perché si appoggia a componenti già presenti nel sistema: cgroups, namespaces, SELinux, systemd. Non introduce un servizio daemon sempre attivo come Docker Engine, quindi riduce la superficie di attacco e semplifica alcuni scenari di hardening. Inoltre, su AlmaLinux 8 e 9 la disponibilità nei repository standard è buona e l’aggiornamento segue il ciclo della distribuzione, che per un ambiente server è una cosa da preferire rispetto a installazioni “creative” da repository terzi.

La distinzione importante è questa: se ti serve un motore compatibile con il modo classico di pensare i container, Podman copre il caso d’uso. Se invece stai cercando un orchestratore, un sistema di networking complesso o un ambiente multi-host, Podman da solo non basta. Qui parliamo di esecuzione locale di container su host AlmaLinux, in root o rootless, con attenzione a verifica, persistenza e rollback.

Pacchetti disponibili e differenze tra AlmaLinux 8 e 9

Su AlmaLinux 8 e 9 il pacchetto si installa in modo simile, ma la base systemd, kernel e userland cambia. In pratica, su AlmaLinux 9 hai una piattaforma più recente, con componenti che tendono a essere più allineati all’ecosistema container moderno. Su AlmaLinux 8 puoi avere qualche margine in meno su certe funzionalità o versioni di librerie, ma per l’uso normale non è un blocco.

Il primo controllo da fare è vedere quale versione hai davvero sotto mano e da quali repository arriverà Podman. Non dare per scontato che il nodo sia “8” o “9” solo perché il template lo dice: in ambienti misti capita spesso di trovare differenze di minor release o repo disallineati.

Installazione base con dnf

Prima di installare, conviene aggiornare la metadata dei repository e verificare la release del sistema. I comandi sotto non sono distruttivi e ti dicono subito se stai lavorando sul ramo giusto.

cat /etc/almalinux-release
sudo dnf clean all
sudo dnf makecache
sudo dnf install -y podman

Dopo l’installazione, controlla che il binario sia presente e che la versione sia coerente con quella attesa dal sistema. Il comando utile è semplice, ma serve davvero perché ti dice anche se stai pescando pacchetti da repository inattesi.

podman --version
rpm -q podman

Se il pacchetto non si installa, il problema non è quasi mai Podman in sé: di solito è un repository disabilitato, una macchina senza accesso ai mirror o un sistema non allineato. In quel caso, il primo artefatto da guardare è l’output di `dnf repolist`.

dnf repolist
sudo dnf info podman

Verifica immediata con un container di test

La verifica più utile non è “il comando esiste”, ma “un container parte e produce output”. Il test classico con una immagine minimale è sufficiente per capire se il runtime, il download delle immagini e la rete funzionano. Se il nodo non ha accesso a Internet, puoi usare una registry interna o un’immagine già presente in cache.

podman run --rm docker.io/library/alpine:latest echo ok

Se il comando restituisce `ok`, hai già validato tre cose: il motore funziona, il pull dell’immagine è riuscito e il container è partito correttamente. Se fallisce, il punto debole lo capisci dal messaggio: errore DNS, rete bloccata, repository non raggiungibile, storage locale pieno o problema SELinux.

Rootless: la modalità da preferire quasi sempre

La modalità rootless è quella che ti conviene usare quando non hai un motivo preciso per far girare i container come root. Su AlmaLinux, Podman è progettato per funzionare bene anche come utente non privilegiato, con mapping degli UID, storage sotto la home e networking gestito senza aprire privilegi inutili. Questo riduce l’impatto di un eventuale container compromesso.

Perché funzioni bene, però, l’utente deve avere un set minimo di prerequisiti: subuid e subgid configurati, shell normale, home disponibile e niente policy strane che blocchino user namespaces. Il controllo più veloce è guardare i file di mapping.

grep '^$USER:' /etc/subuid /etc/subgid

Se i mapping non ci sono, aggiungili in modo esplicito. L’operazione è reversibile e localizzata, ma va fatta con attenzione perché stai modificando l’autorizzazione all’uso degli user namespaces per quell’account.

sudo usermod --add-subuids 100000-165535 --add-subgids 100000-165535 nomeutente

Dopo la modifica, esci e rientra con l’utente, poi rilancia un test rootless. Se vuoi un controllo più esplicito, verifica anche lo storage per utente.

podman info --format '{{.Store.GraphRoot}}'
podman info --format '{{.Host.Security.Rootless}}'

Storage locale: dove finiscono immagini e container

Podman usa uno storage locale che dipende dal contesto di esecuzione. In rootless di solito trovi i dati sotto la home dell’utente, mentre in root possono finire sotto `/var/lib/containers/`. Questa distinzione conta perché in un server saturo o con quota stretta lo storage è una delle prime cause di fallimento apparentemente “misterioso”.

Prima di iniziare a usare Podman in modo serio, controlla spazio e inode. Un filesystem pieno può far fallire il pull dell’immagine, la creazione del layer o l’avvio del container. Il sintomo non è sempre chiaro, ma lo stato del disco sì.

df -h
df -ih
podman system df

Se devi ripulire risorse inutilizzate, fallo con criterio. Su un host condiviso non usare comandi di prune alla cieca senza sapere quali container o immagini sono ancora necessari. La regola pratica è: prima inventario, poi pulizia, poi verifica.

Avvio di un container con porta pubblicata

Un caso tipico è pubblicare una porta verso l’host. Con Podman il mapping è semplice, ma bisogna ricordare che SELinux e firewall possono incidere più del runtime stesso. Se la porta è esposta ma il servizio non risponde, il problema potrebbe stare nel container, nel binding o nelle policy locali.

podman run -d --name webtest -p 8080:80 docker.io/library/nginx:alpine

Verifica subito il container e lo stato della porta. Non aspettare che il servizio venga “scoperto” da altri test: controllalo tu per primo.

podman ps
curl -I http://127.0.0.1:8080

Se il `curl` fallisce ma il container è in esecuzione, guarda i log del container e poi il firewall. Su AlmaLinux 8 e 9 il firewall di default è spesso `firewalld`, quindi la porta potrebbe essere raggiungibile in locale ma non dall’esterno.

podman logs webtest
sudo firewall-cmd --list-ports
sudo firewall-cmd --add-port=8080/tcp --permanent
sudo firewall-cmd --reload

systemd e avvio automatico dei container

Uno dei vantaggi di Podman è la possibilità di integrare i container con systemd senza inventare wrapper strani. Per un servizio persistente, il modello più pulito è generare un’unità systemd o usare un’unità utente rootless. Questo ti dà restart, ordering e visibilità nel journal come per qualunque altro servizio del sistema.

Per generare un’unità da un container già definito, puoi usare il comando dedicato. Il risultato è un file che puoi versionare e controllare come qualsiasi altra configurazione.

podman generate systemd --name webtest --files --new

Se vuoi un avvio rootless con systemd utente, il passaggio successivo è collocare il file nel posto corretto e abilitare il servizio utente. In quel caso il controllo del percorso è fondamentale, perché un errore di home o di permessi ti blocca senza messaggi particolarmente espliciti.

mkdir -p ~/.config/systemd/user
mv container-webtest.service ~/.config/systemd/user/
systemctl --user daemon-reload
systemctl --user enable --now container-webtest.service

Se il servizio deve restare attivo anche dopo il logout, abilita il lingering per l’utente. È una scelta da fare con cognizione, non per abitudine, perché cambia il comportamento del login manager e del lifecycle del servizio utente.

sudo loginctl enable-linger nomeutente

Rete: ponti, DNS e casi in cui il container “non vede” il mondo

La rete è uno dei punti dove si perde più tempo del necessario. Se il container non risolve i nomi o non raggiunge l’esterno, non partire subito con ipotesi esotiche: controlla prima la risoluzione DNS, poi il routing e infine eventuali regole firewall o policy SELinux. Nel rootless il comportamento può essere diverso dal rootful, soprattutto se usi networking slirp4netns o configurazioni personalizzate.

Per un test rapido, entra nel container e prova una risoluzione e una connessione HTTP base. Se il container non ha strumenti installati, usa un’immagine di debug oppure lancia un container temporaneo con tool minimi.

podman run --rm -it docker.io/library/alpine:latest sh
# dentro il container:
# cat /etc/resolv.conf
# wget -qO- https://example.com | head

Se la rete interna funziona ma il nome host del container non è quello atteso, controlla anche l’opzione `--hostname` o il file di configurazione dell’applicazione. Non confondere il nome del container con il DNS esterno: sono due cose diverse e spesso gli operatori le mischiano quando fanno troubleshooting veloce.

SELinux: non disattivarlo, interpretalo

Su AlmaLinux SELinux è parte del quadro normale, non un elemento opzionale da spegnere quando qualcosa non va. Se un container non riesce a leggere o scrivere su un volume bind-mountato, la prima verifica sensata è guardare gli avvisi di audit, non passare direttamente a `setenforce 0`.

Per i volumi montati, il contesto corretto spesso si risolve con le etichette `:Z` o `:z`, a seconda che il volume sia dedicato o condiviso. È una soluzione più pulita rispetto a disabilitare la protezione globale.

podman run --rm -v /srv/appdata:/data:Z alpine sh -c 'echo test > /data/prova.txt'

Se il test fallisce, controlla il log di audit e cerca i denial correlati. Il comando utile è questo:

sudo ausearch -m avc -ts recent

Il vantaggio di questo approccio è che non stai “spegnendo il problema”: stai correggendo il contesto di accesso. In un ambiente server è la differenza tra un fix serio e un workaround che apre un buco inutile.

Gestione immagini e aggiornamenti

Podman non impone una strategia di aggiornamento, quindi devi definirla tu. La pratica più pulita è trattare le immagini come artefatti versionati: tag espliciti, pull controllato, riavvio pianificato, verifica finale. Evita di usare `latest` come riferimento operativo se il container ha un ruolo importante; è troppo facile introdurre un cambio invisibile.

podman pull docker.io/library/nginx:1.27-alpine
podman images
podman inspect docker.io/library/nginx:1.27-alpine | head

Se devi sostituire un container in esecuzione, fai prima una copia della configurazione, poi avvia il nuovo container con nome diverso, verifica, e solo dopo rimuovi il precedente. Questa sequenza riduce il rischio di downtime evitabile e ti lascia un rollback semplice: ripartire con il container vecchio o con il tag precedente.

Problemi tipici e come leggerli senza perdere tempo

Ci sono alcuni sintomi che si ripetono spesso. Se il pull fallisce, guarda DNS e connettività. Se il container parte ma non risponde, guarda binding, porte e firewall. Se un volume non si monta o l’applicazione non scrive, guarda SELinux e permessi. Se l’avvio fallisce in rootless, controlla subuid/subgid e i limiti del servizio utente.

Un controllo sintetico utile è raccogliere stato, log e configurazione minima in un colpo solo.

podman ps -a
podman logs NOME_CONTAINER
podman inspect NOME_CONTAINER --format '{{.State.Status}} {{.HostConfig.NetworkMode}}'

Se lavori su un host di produzione, aggiungi anche un controllo delle risorse: CPU, RAM, disco e limiti del container. Molti problemi che sembrano di runtime sono in realtà saturazione dell’host.

free -h
top -b -n 1 | head -20
podman stats --no-stream

Quando usare Podman e quando no

Usa Podman quando vuoi container locali, integrazione semplice con systemd, rootless come opzione normale e una gestione meno invasiva del runtime. È adatto a web service, job schedulati, stack applicativi piccoli o medi e ambienti dove vuoi contenere il rischio operativo.

Non usarlo come scorciatoia per problemi di architettura più grandi. Se ti servono scheduling distribuito, service discovery complesso, scaling automatico o policy avanzate multi-host, il livello giusto è un orchestratore, non il runtime singolo. Podman è ottimo nel suo perimetro, ma non va forzato fuori contesto.

Sequenza consigliata per un’installazione pulita

Se vuoi una procedura pratica e ripetibile, questa è una sequenza sensata da seguire su AlmaLinux 8 o 9:

1. Verifica release e repository con cat /etc/almalinux-release e dnf repolist.
2. Installa Podman con sudo dnf install -y podman.
3. Controlla la versione con podman --version.
4. Lancia un container di test con podman run --rm alpine echo ok.
5. Se usi rootless, verifica /etc/subuid e /etc/subgid.
6. Testa rete, porta pubblicata e log del container prima di passare a carichi reali.
7. Se serve persistenza, genera un’unità systemd e versiona il file.

Questa sequenza sembra banale, ma evita il classico errore di installare il runtime e poi scoprire troppo tardi che il nodo non ha spazio, il firewall blocca la porta o SELinux sta negando l’accesso a un volume. In altre parole: installazione sì, ma con un minimo di disciplina operativa.

Note operative finali per ambienti server

La parte più importante non è il comando di installazione, ma il modello di gestione che metti intorno a Podman. In produzione conviene avere immagini con tag espliciti, unità systemd controllate, log consultabili, volumi con contesto SELinux corretto e una procedura di rollback già nota. Se questi pezzi mancano, il runtime in sé non ti salva.

Su AlmaLinux 8 e 9 Podman è abbastanza maturo da essere usato senza complicazioni inutili, a patto di non trattarlo come una scatola magica. Lo installi, lo verifichi, lo integri con systemd, controlli storage e rete, e solo dopo lo usi per servizi veri. È il modo più solido per evitare container che “sembrano partire” ma poi si rompono al primo dettaglio di produzione.