Spcnet.it

2026-07-30 08:49:45

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.

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)}

404 Media

2026-07-27 23:43:57

Wikimedia Waits Until After Its Massive Conference to Say It Won’t Voluntarily Recognize Union

The Wikimedia Foundation waited until the days following its largest worldwide conference to issue a statement saying it would not voluntarily recognize a union of its workers.

Last week, Wiki Workers United, which is organized through the Communication Workers Union and represents U.S. workers at the nonprofit Wikimedia Foundation, requested voluntary recognition of their union. Wiki Workers United said that it had secured a “supermajority of union-eligible workers who have signed union authorization cards.” A group of more than 1,100 Wikipedia editors have also signed a letter of support for the union.

On Monday, just days after the massive Wikimania Conference concluded in Paris, the Wikimedia Foundation announced it would not voluntarily recognize the union and said the union would have to conduct a vote as overseen by the National Labor Relations Board.

“The Foundation’s responsibility is to ensure that they can make their own choice freely,” the foundation wrote in the statement. “So that every eligible employee has an equal voice, we believe a secret-ballot election conducted by the National Labor Relations Board is the appropriate path forward.”

“We have heard a range of views from staff, including concerns from those who have felt pressured to support union efforts and those who are confused by the unionization process,” the foundation added in a frequently asked questions section. “We have also seen a misunderstanding around what the union can do for global staff and Wikimedia movement communities.”

The Wikimedia Foundation’s statement and its frequently asked questions section is full of very carefully-worded language that is common among companies and organizations that have fought against unionization. For example, the FAQ includes a long section about the benefits that Wikimedia Foundation already offers its staff, and the statement suggests that there is a “wide range of views on unionization” among employees.

Wikipedians immediately took issue with the timing of the statement and the language of it. On a talk page discussing the statement, the Wikimedia Foundation is getting hammered for the timing of the statement and the statement itself.

“What a shameful decision to tie the process to the willingness of Trump-controlled NLRB. Everyone involved in denying the voluntary recognition should resign in disgrace or be driven out,” one editor wrote.

“The fact that this response came exactly 1 day after Wikimania shows that you are afraid of being confronted,” another wrote.

“This is an extremely disappointing statement. It says that ‘Foundation leadership respects the right of staff to unionize, if they choose to do so. That decision rests with them.’ But that decision has been made - by a supermajority of US-based staff. The only thing standing between the US WWU and recognition is WMF executive leadership, who could recognize the union today if they cared to,” a third wrote.

“As a U.S. trained labor lawyer and past organizer with WWU, this statement, alongside the WMF’s public facing community post reek of union-busting disinformation. What’s critical for the community to know is that a supermajority of the workers already did vote by signing a card. This ‘extra step’ is just a delay tactic that employers are advised to do when they don’t want a union,” a fourth wrote. “These WMF workers have already been extremely brave by expressly affirming their commitment to a union. Years of efforts to get this accomplished. This is not some rash decision by them. Moreover, the community supports their union too! It literally makes no sense as to why WMF thought this was the right decision here in this critical moment.”

At Wikimania in Paris, the Wikimedia Foundation’s Chief Executive Officer Bernadette Meehan was asked about voluntarily recognizing the union. Meehan said “our focus is on executing and helping the core organizing team execute a great event. We will respond to that particular request when we have a chance to review it.”

“We are supportive and we support employees’ right to unionize. The context is complicated because we operate in multiple different places,” she added. “We respect the right if it is the majority will of eligible staffers to unionize.”

The Wikimedia Foundation did not immediately respond to a request for comment.

Wikimedia Foundation Statement on US unionization request – Wikimedia Foundation

The Wikimedia Foundation responds to the Communication Workers of America's (CWA) request for unionization.

^{Wikimedia Foundation}

Gabardino

2026-07-25 16:33:33

l Paese: salari da fame, potere d'acquisto più basso di 35 anni fa, liste d'attesa di anni nella sanità pubblica, gasolio a 2.2 al litro.

Il governo Meloni: legge anti maranza.