Containerizzazione 2025: Perché containerd 2.0 e eBPF Cambiano Tutto

Il panorama della containerizzazione, perennemente dinamico, ha visto una serie di progressi pratici e solidi tra la fine del 2024 e il 2025. Come sviluppatori senior, siamo oltre il "ciclo dell'hype" e immersi nelle trincee, valutando le funzionalità che offrono vantaggi operativi tangibili e affrontano vincoli del mondo reale. L'anno passato ha consolidato diverse tendenze: una spinta incessante per una maggiore sicurezza lungo tutta la supply chain, miglioramenti fondamentali nell'efficienza runtime, un significativo salto in avanti nell'ergonomia della build per implementazioni multi-architettura e l'emergere di WebAssembly come alternativa credibile, sebbene nascente, per carichi di lavoro specifici. Ecco un'analisi approfondita degli sviluppi che contano davvero.

La Nuova Fondazione: containerd 2.0 e eBPF

containerd 2.0: La Fondazione CRI Riorganizzata

La fondazione del nostro mondo containerizzato, il runtime dei container, ha visto un'evoluzione significativa, in particolare con il rilascio di containerd 2.0 alla fine del 2024. Non si tratta semplicemente di un aggiornamento incrementale; è una stabilizzazione strategica e un miglioramento delle capacità principali sette anni dopo il suo rilascio 1.0. Il passaggio da dockershim in Kubernetes v1.24 ha portato containerd e CRI-O in primo piano, proprio come i moderni strumenti CLI stanno ridefinendo l'esperienza dello sviluppatore nel 2025.

containerd 2.0 introduce diverse funzionalità chiave nel canale stabile che meritano una stretta attenzione. La Node Resource Interface (NRI) è ora abilitata per impostazione predefinita, fornendo un potente meccanismo di estensione per personalizzare le configurazioni dei container a basso livello. Ciò consente un controllo più granulare sull'allocazione delle risorse e sull'applicazione delle policy, simile ai webhook di ammissione mutanti ma operante direttamente a livello di runtime. Gli sviluppatori possono sfruttare i plugin NRI per iniettare configurazioni runtime specifiche o applicare policy di gestione delle risorse personalizzate dinamicamente, una funzionalità che in precedenza era più complessa da implementare senza modifiche dirette al runtime.

Inoltre, containerd 2.0 supporta ora i plugin Image Verifier. Questo è davvero impressionante perché consente l'applicazione di policy sulle immagini al momento del pull dell'immagine. Pensaci: invece di scansionare le immagini solo durante CI/CD o al deployment, ora puoi avere containerd stesso che invoca un plugin esterno (che può essere qualsiasi eseguibile binario o script) per convalidare l'integrità o la conformità di un'immagine prima che venga completamente scaricata ed eseguita. Questo si integra direttamente con il transfer service (stabilizzato in 2.0), anche se si nota che il plugin CRI non è ancora completamente integrato, quindi il suo impatto immediato sui deployment di Kubernetes potrebbe essere limitato fino a quando non verrà implementato. Tuttavia, per gli utenti diretti di containerd, questo è un solido passo avanti per la sicurezza della supply chain al confine del runtime. Sul fronte della sicurezza, containerd v2.2.0 include anche correzioni per vulnerabilità critiche come CVE-2024-25621 e CVE-2025-64329, insieme a runc v1.3.3 che affronta CVE-2025-31133, CVE-2025-52565 e CVE-2025-52881, dimostrando un continuo impegno nel rafforzare i componenti principali.

L'Ascesa di eBPF: Controllo a Livello di Kernel per Networking e Osservabilità

Stavo aspettando che eBPF raggiungesse la sua piena maturità nell'ecosistema dei container, e la fine del 2024 e il 2025 hanno mantenuto le promesse. L'integrazione di eBPF (extended Berkeley Packet Filter) negli stack di networking e osservabilità di Kubernetes è passata da una curiosità sperimentale a una tecnologia fondamentale. eBPF consente a programmi sandboxati di essere eseguiti direttamente all'interno del kernel Linux, attivati da vari eventi, offrendo prestazioni e flessibilità senza precedenti senza l'overhead dei tradizionali cambi di contesto kernel-user-space.

Per il networking, i plugin Container Network Interface (CNI) basati su eBPF come Cilium e Calico stanno attivamente sostituendo o offrendo alternative superiori agli approcci basati su iptables. Il vantaggio principale risiede nell'efficiente elaborazione dei pacchetti. Invece di attraversare complesse catene iptables per ogni pacchetto, i programmi eBPF possono prendere decisioni di routing e policy direttamente in un punto precedente dello stack di rete del kernel. Ciò riduce drasticamente l'overhead della CPU e la latenza, soprattutto in cluster Kubernetes di grandi dimensioni. Progetti come Cilium hanno fatto avanzare il networking dei container, sostituendo iptables con efficienti datapaths eBPF, e il suo status laureato con CNCF e l'inclusione in progetti come OpenTelemetry lo rendono uno standard de facto per la gestione delle policy di rete.

Oltre alle prestazioni, eBPF migliora profondamente l'osservabilità. Collegando programmi eBPF a chiamate di sistema, eventi di rete e attività di processo, gli sviluppatori possono acquisire dati di telemetria dettagliati direttamente dal kernel in tempo reale. Ciò fornisce una visibilità granulare sul comportamento dei container, sui flussi di rete e sulle chiamate di sistema senza richiedere proxy sidecar intrusivi o strumentazione dell'applicazione. Ad esempio, un programma eBPF può monitorare tutte le connessioni di rete avviate da un container specifico, rilevare modelli di accesso a file insoliti o tracciare le chiamate di sistema, offrendo un potente strumento sia per il debug delle prestazioni che per il rilevamento delle minacce alla sicurezza in tempo reale.

Modernizzazione del Build e del Workflow di Sviluppo

BuildKit 2.0 & Docker Build Cloud: Build Più Intelligenti, Più Veloci e Più Sicuri

Se stai ancora trattando docker build come una scatola nera, ti stai perdendo qualcosa. BuildKit è stato il builder predefinito in Docker Engine dalla versione 23.0, e BuildKit 2.0, insieme a Docker Build Cloud, rappresenta un significativo passo avanti nel modo in cui costruiamo le immagini dei container. BuildKit 2.0 non riguarda solo la velocità; è un cambiamento di paradigma verso pipeline di build più sicure, portabili e ottimizzate in modo intelligente.

Una delle caratteristiche principali di BuildKit 2.0 è la Federated Caching. La caching basata su registro (--cache-from) è sempre stata un po' lenta e ad alta intensità di rete. Federated Caching, tuttavia, introduce un meccanismo di caching peer-to-peer, consentendo ai tuoi agenti di build di formare un cluster di cache distribuito. Quando un agente costruisce un layer, può essere immediatamente disponibile per gli altri sulla stessa rete senza un viaggio di andata e ritorno a un registro remoto. Questo riduce drasticamente i tempi di build per i team, soprattutto nelle architetture a microservizi in cui le immagini di base vengono ricostruite frequentemente, trasformando una pausa caffè in un rapido aggiornamento.

Altrettanto entusiasmante è l'introduzione di Native WASM Build Steps. Complessi comandi RUN che coinvolgono curl, tar e sed sono notoriamente inclini a build instabili e insicure. BuildKit 2.0 affronta questo problema consentendo ai moduli WebAssembly (WASM) di essere utilizzati come passaggi di build nativi. Invece di concatenare comandi shell, puoi utilizzare un binario WASM precompilato e sandboxato per eseguire attività come il recupero di asset, la generazione di codice o il linting. Questo offre esecuzione sandboxata e portabilità migliorata, rendendo le tue build più affidabili e sicure. Inoltre, BuildKit 2.0 si integra profondamente con le moderne pratiche di sicurezza, generando automaticamente attestazioni SLSA e firmando le immagini utilizzando Sigstore/Cosign come parte nativa del processo di build.

A complemento di BuildKit 2.0, Docker Build Cloud, lanciato a gennaio 2024, mira ad accelerare le build scaricandole sul cloud. Questo servizio sfrutta il calcolo cloud e la cache per ottenere tempi di build fino a 39 volte più veloci rispetto alle build locali. Offre supporto nativo per build multi-architettura (AMD64, ARM64) eliminando la necessità di emulazione lenta o di mantenere builder nativi multipli. Il comando docker buildx build --platform linux/amd64,linux/arm64 -t myregistry/my-app:latest --push . rende la build per più architetture senza problemi.

Docker Compose v5: Elevare i Workflow di Sviluppo Locale

Docker Compose è sempre stato il cavallo di battaglia per lo sviluppo multi-container locale, ma l'evoluzione recente, culminata in Compose v5 a dicembre 2025, lo ha reso uno strumento ancora più potente e integrato. Il cambiamento strutturale più significativo è stata l'integrazione completa di docker compose (l'implementazione basata su Go) direttamente nella Docker CLI, deprecando ufficialmente il vecchio docker-compose basato su Python (con il trattino).

Una delle funzionalità che stavo aspettando è docker compose watch. Questo comando traccia i file e aggiorna automaticamente i container in esecuzione nel momento in cui un file viene salvato, eliminando la necessità di cicli manuali docker compose up o restart. Per uno sviluppatore di applicazioni web, ciò significa un ciclo di feedback stretto: write-save-view avviene in pochi secondi, perfetto per iterare sugli endpoint API o sulle anteprime front-end live. Puoi abilitarlo con una semplice etichetta nel tuo compose.yml:

services:
  web:
    build: .
    ports:
      - "80:80"
    labels:
      com.docker.compose.watch: "true" # Abilita la modalità watch per questo servizio

Altri miglioramenti significativi della CLI includono docker compose attach per il debug, docker compose stats per il monitoraggio in tempo reale dell'utilizzo delle risorse e docker compose cp per copiare facilmente i file tra l'host e un container di servizio. Il campo version in docker-compose.yml è ora completamente deprecato; i file Compose moderni dovrebbero ometterlo, iniziando direttamente con il blocco services:. Compose v5 introduce anche un nuovo SDK Go ufficiale, che fornisce un'API completa per integrare la funzionalità Compose direttamente nelle applicazioni.

AI/ML e l'Evoluzione di Docker Desktop

Il Pivot AI/ML di Docker Desktop: Oltre la Semplice Containerizzazione

Docker Desktop continua a evolversi come una workstation di sviluppo completa e le sue funzionalità nel 2025 mostrano un chiaro pivot verso il supporto dei workflow di sviluppo AI/ML. Oltre alla sua funzione principale di fornire un Docker Engine e un cluster Kubernetes locali, Docker Desktop sta ora integrando strumenti che affrontano direttamente i punti critici degli sviluppatori AI.

La funzionalità Model Runner, ad esempio, mira a semplificare l'esecuzione locale di LLM. L'esecuzione di modelli AI localmente spesso comporta la gestione di ambienti Python, installazioni CUDA, formati di modelli specifici e dipendenze complesse. Docker's Model Runner astrae gran parte di questa complessità, consentendo agli sviluppatori di scaricare ed eseguire modelli con un semplice comando docker model pull ai/llama3.2:1B-Q8_0 (a partire da Docker Desktop 4.40+). Questo è davvero impressionante perché abbassa la barriera all'ingresso per sperimentare con modelli linguistici di grandi dimensioni e altre applicazioni AI, fornendo un ambiente containerizzato coerente per l'esecuzione del modello.

Per i carichi di lavoro che superano le risorse della macchina locale, Docker Offload fornisce un modo semplice per eseguire modelli e container su GPU cloud. Questo libera gli sviluppatori dai vincoli di infrastruttura scaricando attività ad alta intensità di calcolo, come modelli linguistici di grandi dimensioni e orchestrazione multi-agente, su ambienti cloud ad alte prestazioni. Inoltre, il MCP Toolkit (per lo sviluppo di agenti AI) e Docker Debug (per un debug migliorato con container di debug snelli) completano le capacità ampliate di Docker Desktop, rendendolo uno strumento più versatile per lo sviluppo moderno e ad alta intensità di risorse.

Rafforzare la Supply Chain e la Privacy dei Dati

Sicurezza Avanzata delle Immagini e Immagini Rinforzate

La crescente dipendenza dai componenti open source significa che le immagini dei container sono un punto di controllo primario per la sicurezza della supply chain del software e Docker ha significativamente intensificato il suo impegno nel 2024-2025. Oltre il 90% delle applicazioni moderne dipende da open source e le immagini dei container possono includere centinaia di dipendenze, rendendo il layer dell'immagine una delle superfici di attacco più grandi e meno visibili.

Docker Scout (precedentemente Docker Scan) è ora un elemento centrale di questa strategia, offrendo un'analisi continua delle vulnerabilità per repository Scout-enabled illimitati all'interno dei piani Docker Team e Business. Fornisce informazioni in tempo reale sul rischio dell'immagine e raccomandazioni per la correzione, integrandosi perfettamente con la Docker CLI e le pipeline CI/CD. Questo approccio "shift-left" è fondamentale, consentendo agli sviluppatori di identificare e risolvere le vulnerabilità nelle prime fasi del ciclo di sviluppo, impedendo che immagini insicure raggiungano la produzione.

Uno sviluppo particolarmente incisivo è la decisione di Docker di rendere Docker Hardened Images gratuite per tutti. Queste immagini forniscono una base sicura per impostazione predefinita, riducendo l'attrito tra la velocità di sviluppo e la sicurezza. Sono dotate di supporto del ciclo di vita esteso, aiutando le aziende a rimanere conformi e a mitigare i rischi di fine vita. Questa mossa segnala l'impegno di Docker nel fissare un nuovo standard per l'intero ecosistema dei container, rendendo la sicurezza un'aspettativa di base piuttosto che una funzionalità premium.

Container Confidenziali: Portare Fiducia in Ambienti Non Affidabili

Per i carichi di lavoro altamente sensibili, il concetto di Container Confidenziali (CoCo) è maturato significativamente, passando da una ricerca di nicchia a implementazioni pratiche. CoCo è un progetto sandbox CNCF che mira a consentire il calcolo confidenziale nativo del cloud sfruttando gli ambienti di esecuzione affidabili (TEE) per proteggere i container e i dati. Questo è un punto di svolta per la privacy dei dati, soprattutto nei settori regolamentati o per l'elaborazione di informazioni di identificazione personale (PII).

L'idea di base è creare enclave sicure all'interno di un processore, che proteggono i dati elaborati dall'ambiente circostante, incluso il CPU, l'hypervisor e persino gli amministratori del cloud. Tecnologie come Intel SGX, Intel TDX e AMD SEV formano la base hardware, crittografando la memoria del container e impedendo che i dati in memoria siano in testo chiaro. Questo approccio "black box" garantisce che i workflow sensibili siano protetti da accessi non autorizzati.

L'obiettivo del progetto CoCo è standardizzare il calcolo confidenziale a livello di container e semplificarne il consumo in Kubernetes. Ciò significa che gli utenti di Kubernetes possono distribuire carichi di lavoro di container confidenziali utilizzando workflow e strumenti familiari, senza la necessità di una conoscenza approfondita delle tecnologie di calcolo confidenziale sottostanti. Sebbene ancora in anteprima per alcuni provider cloud e con un overhead di prestazioni intrinseco dovuto all'isolamento aggiuntivo, la capacità di raggiungere un nuovo livello di riservatezza e integrità dei dati impedendo la leggibilità dei dati in memoria è un progresso potente.

La Realtà di Wasm e la Strada da Percorrere

La Sfumatura di Wasm: Una Storia di Due Implementazioni

WebAssembly (Wasm) nell'ecosistema dei container presenta un'interessante dualità. Da un lato, l'introduzione di Native WASM Build Steps da parte di BuildKit 2.0 è un'evoluzione convincente per migliorare la sicurezza e la portabilità della build. Qui, i moduli Wasm vengono utilizzati all'interno del processo di build per eseguire attività specifiche, offrendo un'alternativa sandboxata ed efficiente agli script shell tradizionali. Questo è un progresso pratico e solido che affronta problemi reali di affidabilità e sicurezza della build.

Tuttavia, la storia di Wasm come runtime di container diretto all'interno di Docker Desktop sembra prendere una direzione diversa. Le note di rilascio di Docker Desktop 4.55.0 del dicembre 2025 affermano esplicitamente che i carichi di lavoro Wasm verranno deprecati e rimossi in una futura release di Docker Desktop. Questa è una realtà cruciale. Mentre runwasi esiste come progetto non core di containerd per uno shim WASM, la decisione di Docker per Desktop suggerisce che l'esecuzione diretta di Wasm potrebbe non aver soddisfatto l'adozione o la fattibilità tecnica prevista per i workflow di sviluppo generali all'interno del loro prodotto Desktop.

Conclusione: La Strada da Percorrere

Che anno è stato! I progressi in Docker, containerd e Kubernetes alla fine del 2024 e durante il 2025 sono a dir poco impressionanti. Abbiamo visto containerd 2.0 consolidare il suo ruolo come fondamento robusto ed estensibile per i runtime dei container, offrendo nuovi hook potenti come NRI e plugin di verifica delle immagini. L'ascesa di eBPF ha fondamentalmente rimodellato il modo in cui pensiamo al networking, all'osservabilità e alla sicurezza dei container, portando l'efficienza e la visibilità a livello di kernel nel mainstream.

Per gli sviluppatori, Docker Compose v5 e le nuove funzionalità AI/ML-focused di Docker Desktop come Model Runner e Docker Offload dimostrano un impegno per lo snellimento dei workflow oltre la semplice gestione dei container, abbracciando le tendenze emergenti. E forse, cosa più importante, la costante attenzione alla sicurezza della supply chain, esemplificata dall'analisi continua di Docker Scout e dalla disponibilità di Docker Hardened Images gratuite, sta stabilendo un livello più elevato di fiducia nei nostri artefatti software. Sebbene alcune funzionalità, come l'esecuzione diretta di Wasm in Docker Desktop, siano soggette a rivalutazione, la traiettoria generale è chiara: i container stanno diventando più sicuri, più performanti e più integrati nei paradigmi di sviluppo avanzati di oggi e di domani.