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 praticaPodman (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 podmanVerifica dell’installazione:

podman --version
podman info
podman run hello-worldSe l’ultimo comando restituisce il messaggio di benvenuto di Podman, l’installazione è a posto.

Uso quotidiano: i comandi non cambiano quasi nullaShell interattiva dentro un container Ubuntu:

podman run -it ubuntu bashServizio in background, con Nginx esposto sulla porta 8080 dell’host:

podman run -d --name web -p 8080:80 nginx
podman psIl 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 davveroLa 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 QuadletQuesto è 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.targetAttivazione:

systemctl --user daemon-reload
systemctl --user start webDa 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 ComposeChi 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.socketLa 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 rilevanteNonostante 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.

ConclusionePodman è 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.

Il problema delle Throughput Unit staticheChi ha già lavorato con Azure Event Grid Namespaces conosce bene il concetto di Throughput Unit (TU): ogni TU definisce una capacità fissa di ingress/egress per gli eventi, di publish MQTT e di connessioni client MQTT. Fino ad oggi, il numero di TU andava impostato in fase di creazione del namespace e poi regolato manualmente ogni volta che il pattern di traffico cambiava — tipicamente sovradimensionando “per sicurezza” durante i picchi, con conseguente spreco di capacità (e di budget) nei periodi di bassa attività.

Microsoft ha da poco introdotto in public preview la funzionalità Autoscale per Event Grid Namespaces (tier Standard), che elimina questa gestione manuale: il servizio monitora il carico e regola automaticamente le TU tra un minimo e un massimo configurati dall’amministratore.

Come funziona AutoscaleIl funzionamento è deliberatamente semplice, in linea con la filosofia “meno configurazione, più automazione” che Azure sta applicando a diversi servizi PaaS. Event Grid valuta continuamente l’utilizzo su quattro categorie:

Event ingress: tasso di eventi in ingresso sui namespace topic HTTP.

Event egress: tasso di eventi in uscita verso i sottoscrittori.

MQTT publish rate (inbound/outbound): frequenza dei messaggi pubblicati e ricevuti sul broker MQTT.

MQTT client count: numero di client MQTT registrati e connessi.

Quando una qualunque di queste metriche supera la soglia di scale-up, il servizio aggiunge automaticamente Throughput Unit. Quando tutte le categorie scendono sotto la soglia di scale-down, le TU in eccesso vengono rilasciate. L’amministratore non definisce policy o soglie personalizzate: si limita a impostare i limiti minimo e massimo di TU, e Event Grid gestisce internamente le decisioni di scaling.

Un richiamo ai concetti di namespacePer chi non ha ancora familiarità con il modello a namespace di Event Grid (distinto dai topic “classici” di Event Grid Basic), vale la pena ricordare la struttura:

Un namespace è un contenitore di gestione che espone un FQDN unico e due endpoint: uno HTTP per i namespace topic, uno MQTT per scenari IoT.

I namespace topic supportano sia la pull delivery (il consumer si collega ed estrae i messaggi con semantica queue-like) sia la push delivery (attualmente verso Event Hubs come destinazione).

Gli eventi pubblicati devono rispettare lo standard CloudEvents 1.0 del CNCF, con binding HTTP e formato JSON.

Autoscale agisce a livello di namespace, quindi tutte le risorse contenute (topic, topic space MQTT, client, client group) beneficiano della stessa capacità elastica senza bisogno di scaling indipendente per ciascuna.

Abilitare Autoscale: portale, ARM e REST APILa funzionalità, essendo in preview, va abilitata esplicitamente. Dal portale Azure basta aprire il namespace Event Grid, andare nella sezione di configurazione della capacità e attivare l’opzione Autoscale specificando TU minime e massime.

Per chi gestisce l’infrastruttura as code, lo stesso risultato si ottiene via ARM template (o Bicep) impostando le proprietà di scaling sulla risorsa del namespace:

{
 "type": "Microsoft.EventGrid/namespaces",
 "apiVersion": "2025-04-01-preview",
 "name": "ns-iot-produzione",
 "location": "westeurope",
 "sku": {
 "name": "Standard",
 "capacity": 4
 },
 "properties": {
 "isZoneRedundant": true,
 "topicsConfiguration": {},
 "publicNetworkAccess": "Enabled",
 "topicSpacesConfiguration": {
 "state": "Enabled"
 }
 }
}Nota: al momento della stesura la configurazione fine di Autoscale (min/max TU) va completata tramite portale o REST API dedicata, poiché lo schema ARM per questa preview è ancora in evoluzione — vale la pena controllare la pagina di supporto ufficiale prima di automatizzare il deployment in pipeline CI/CD.

Via REST API, la capacità del namespace si legge e modifica sulla stessa risorsa esposta dall’API di gestione di Event Grid:

GET https://management.azure.com/subscriptions/{subId}/resourceGroups/{rg}/providers/Microsoft.EventGrid/namespaces/{namespaceName}?api-version=2025-04-01-previewQuando ha senso usarloAutoscale è pensato in particolare per due categorie di carico che chi lavora con architetture event-driven conosce bene:

Workload IoT con MQTT: il numero di dispositivi connessi e il fan-out delle sottoscrizioni possono variare rapidamente (pensiamo a una flotta di sensori che si riattiva tutta insieme dopo un’interruzione di rete). Dimensionare le TU staticamente per il picco significa pagare capacità inutilizzata per la maggior parte del tempo.

Event broker con traffico “a burst”: pipeline di ingestion che ricevono ondate di eventi correlate a batch job, deployment, o processi di business con picchi orari/giornalieri (fine mese, chiusura contabile, campagne marketing).

Per i .NET developer che costruiscono microservizi basati su eventi, questo significa poter progettare la sottoscrizione a namespace topic senza dover stimare a priori il traffico di picco con lo stesso margine di sicurezza richiesto finora — riducendo sia il rischio di throttling sotto carico sia i costi nei periodi di quiete.

ConclusioneAutoscale per Event Grid Namespaces arriva in un’area, il messaging event-driven, dove il dimensionamento manuale è da sempre un compromesso scomodo tra costo e resilienza. Essendo ancora in public preview, prima di adottarlo su workload di produzione critici vale la pena testarlo su un namespace non critico, verificando i tempi di reazione dello scaling automatico sotto carico reale e monitorando le metriche di throttling durante la fase di transizione tra un livello di TU e l’altro.

Fonte: Petri IT Knowledgebase – Azure Event Grid Namespaces Add Autoscale for Dynamic Messaging Workloads; concetti tecnici da Microsoft Learn – Concepts for Event Grid namespace topics

Chi gestisce ambienti SQL Server on-premises conosce bene il problema: la migrazione verso il cloud richiede quasi sempre di mettere insieme tool diversi per la valutazione, il trasferimento dei dati, il monitoraggio e infine il cutover. Ogni fase ha strumenti propri, competenze diverse e margini di errore che si sommano. Con l’annuncio della disponibilità generale (GA) della migrazione a SQL Server su macchine virtuali Azure tramite Azure Arc, Microsoft porta l’intero ciclo di vita della migrazione dentro un’unica esperienza guidata nel portale Azure, lo stesso modello già usato per le migrazioni verso Azure SQL Managed Instance.

Per chi amministra data center misti, con carichi legacy e SQL Server sparsi su fisico e virtuale, questa novità merita attenzione: non è solo un annuncio di marketing, ma un cambio concreto di flusso di lavoro operativo.

Cos’è cambiato con la GAFino a poco tempo fa, chi voleva spostare un’istanza SQL Server su una VM Azure doveva combinare Azure Migrate, Database Migration Service e strumenti di backup/restore manuali, gestendo ciascuno con logiche e dashboard separate. Con la funzionalità di migrazione integrata in Azure Arc, il processo si consolida in quattro fasi accessibili da un singolo pannello, il Database Migration, associato all’istanza SQL Server abilitata da Arc:

Assess source instance — valutazione di leggibilità e readiness dell’istanza sorgente

Select target — scelta o creazione della VM SQL Server di destinazione

Migrate data — trasferimento effettivo dei database

Monitor and cutover — monitoraggio della sincronizzazione e passaggio finale in produzione

La discovery delle istanze e la generazione dei report di readiness avvengono automaticamente ogni fine settimana, ma possono essere lanciate anche manualmente, senza configurazioni aggiuntive: la funzione è disponibile di default per tutte le istanze SQL Server abilitate da Arc a partire da SQL Server 2012 (11.x).

Copilot integrato nel flusso di migrazioneUna parte interessante della nuova esperienza è l’integrazione di Microsoft Copilot direttamente nel pannello di migrazione. Non si tratta di un chatbot generico: interroga la knowledge base Microsoft nel contesto specifico della vostra migrazione e risponde a richieste operative come:

Come vengono eseguite le valutazioni?
Aiutami a confrontare le opzioni di destinazione
Avvia la migrazione
Aiutami a scegliere il metodo di migrazione corretto
Monitora la migrazione in corso
Completa la migrazionePer un DBA che gestisce decine di istanze, questo significa poter chiedere direttamente nel pannello “quale VM SKU è consigliata per questo carico?” invece di andare a cercare tabelle di sizing nella documentazione.

Come funziona la migrazione via backup e restoreIl meccanismo sotto il cofano non è nuovo per chi ha familiarità con le migrazioni SQL Server classiche: si basa su backup e restore con log shipping continuo, pensato per supportare scenari di migrazione online con downtime minimo.

Viene eseguito un backup completo del database sorgente

Il backup viene caricato su un account di Azure Blob Storage intermedio

Il backup viene ripristinato sull’istanza SQL Server target sulla VM Azure

I backup dei log delle transazioni vengono caricati in continuo sullo stesso storage e applicati automaticamente al database target, mantenendolo sincronizzato

Al momento del cutover, Azure Arc applica l’ultimo backup caricato e porta online il database target

Un vincolo operativo da tenere a mente in fase di progettazione: l’account di Azure Blob Storage e la VM SQL Server target devono trovarsi nella stessa region Azure. È un dettaglio facile da trascurare se si pianifica la migrazione partendo dalla region “storica” dell’organizzazione invece che da quella scelta per il nuovo carico.

Prerequisiti praticiUna subscription Azure attiva

L’istanza SQL Server deve essere abilitata da Azure Arc con l’estensione più recente installata (l’estensione si aggiorna indipendentemente da SQL Server, quindi va controllata separatamente)

L’ambiente sorgente preparato secondo le linee guida ufficiali, incluso l’upload iniziale dei backup nello storage account

Per verificare rapidamente la versione dell’istanza sorgente prima di avviare l’assessment, un semplice controllo T-SQL è sempre un buon punto di partenza:

SELECT SERVERPROPERTY('ProductVersion') AS Versione,
SERVERPROPERTY('Edition') AS Edizione,
SERVERPROPERTY('EngineEdition') AS TipoMotore;Cosa considerare prima di partireIl pannello di monitoraggio e cutover mostra in tempo reale quali database sono migrati con successo, quali sono ancora in corso, il metodo di migrazione scelto, la durata della sincronizzazione e i log dettagliati. Quando lo stato passa a “Ready for cutover”, si può decidere il momento esatto del passaggio in produzione selezionando Cutover, con opzioni diverse in base al metodo di migrazione utilizzato.

Va detto che, come per ogni migrazione basata su backup/restore, restano da valutare a parte gli aspetti di sizing della VM di destinazione (storage, IOPS, memoria per il buffer pool), la licenza SQL Server (Hybrid Benefit se applicabile) e la strategia di alta disponibilità post-migrazione, che questo strumento non copre direttamente ma per cui l’assessment fornisce indicazioni.

ConclusionePortare discovery, assessment, migrazione e monitoraggio in un’unica dashboard riduce sensibilmente l’attrito operativo delle migrazioni SQL Server verso Azure, soprattutto per i team che gestiscono ambienti ibridi complessi con decine o centinaia di istanze. Non elimina la necessità di pianificazione — region, sizing e licensing restano decisioni da prendere a monte — ma consolida in un solo posto ciò che prima richiedeva più tool scollegati tra loro. Per chi ha già istanze abilitate da Azure Arc, vale la pena aggiornare l’estensione e lanciare un primo assessment anche solo per farsi un’idea della readiness del proprio parco macchine.

Fonte: Petri IT Knowledgebase e documentazione Microsoft Learn.