Usa i container per applicare il rigore dell'ingegneria del software ai carichi di lavoro dell'IA

Mentre i carichi di lavoro di IA passano dai prototipi sperimentali agli ambienti di produzione, le aziende affrontano una sfida nota: come proteggere, gestire e governare questi nuovi componenti con lo stesso rigore applicato alle applicazioni software tradizionali? Un elemento chiave risiede in uno strumento che probabilmente la tua organizzazione utilizza già ampiamente: i container, in particolare i container Open Container Initiative (OCI).

Cos'è l'Open Container Initiative?

L'Open Container Initiative definisce specifiche aperte per i formati delle immagini, i runtime dei container e la distribuzione, aiutando le organizzazioni a evitare il vendor lock-in.  I container OCI rappresentano un formato standard di settore per il packaging di applicazioni software, pertanto possono essere eseguiti in modo coerente in diversi ambienti, motori di container (come Docker o Podman) e piattaforme cloud.

Un artefatto OCI è simile a un container, ma invece di archiviare immagini eseguibili, gli artefatti archiviano altri contenuti come file e directory.  I repository di artefatti compatibili con OCI (inclusi Quay, Artifactory, Docker Hub ed i registri dei principali cloud provider) possono archiviare e gestire il controllo delle versioni dei container e degli artefatti OCI.

OCI offre un metodo standardizzato e portabile per il packaging e la distribuzione del software. Effettuando il packaging di modelli di IA, server Model Context Protocol (MCP) ed agenti di IA tramite i container OCI, puoi utilizzare i processi di sicurezza della catena di distribuzione del software, le pipeline CI/CD e l'infrastruttura di orchestrazione dei container esistenti. Questo approccio garantisce allo tecnologie di IA la stessa governance e la stessa verificabilità già applicate ai carichi di lavoro delle applicazioni.

Containerizza i modelli di IA con ModelCar

I modelli linguistici di grandi dimensioni (LLM) e gli altri modelli di IA presentano complessità specifiche relativamente al packaging. Questi modelli consistono in file binari di grandi dimensioni, metadati di configurazione e requisiti specifici per la struttura dei file. In passato, le organizzazioni si sono affidate allo storage di oggetti compatibile con S3 per distribuire i modelli, ma questo approccio crea attriti con i flussi di lavoro basati sui container e i processi di sicurezza esistenti. Ti consigliamo di creare i tuoi modelli di IA in container OCI utilizzando una struttura di file specifica chiamata ModelCar.

Cos'è un container ModelCar?

Un container ModelCar è semplice: i file dei modelli di IA vengono inseriti nella cartella /models all'interno del container. Non sono necessari pacchetti o componenti di runtime aggiuntivi: il container contiene semplicemente gli artefatti del modello in un formato conforme a OCI.

I vantaggi di questo approccio sono notevoli. Dopo aver creato il pacchetto del modello come container, puoi gestirlo utilizzando gli stessi processi di sicurezza della catena di distribuzione del software che utilizzi già per i container delle applicazioni. Puoi generare una distinta base software (SBOM, software bill of materials) e una distinta base IA (AI-BOM) per il container come attività nella pipeline CI/CD. Puoi anche firmare e convalidare il container, generare attestazioni di provenienza che mostrino come il container sia stato creato dal tuo sistema di compilazione affidabile, archiviare il container nel repository degli artefatti OCI interno e configurare i criteri di distribuzione per estrarre i container solo dai repository approvati.

Red Hat Trusted Artifact Signer ti consente di firmare i modelli e di convalidarne l'autenticità e la trasparenza utilizzando Sigstore e Rekor. 

Red Hat OpenShift AI 2.14 e le versioni successive supportano l'erogazione dei modelli direttamente dai container ModelCar utilizzando KServe, eliminando completamente la dipendenza dallo storage compatibile con S3. Questo semplifica la distribuzione, migliora i tempi di avvio del server di inferenza, specialmente quando il container è memorizzato nella cache su un nodo, e fornisce un approccio unificato alla gestione degli artefatti in tutta l'organizzazione.

Un catalogo di esempi di container ModelCar è disponibile nel repository GitHub, e offre modelli e pratiche consigliate per il packaging di vari tipi di modelli.

Considerazioni sulle dimensioni del modello

Sebbene la specifica OCI non imponga limiti rigidi alle dimensioni delle immagini, esistono vincoli pratici. In genere, i registri dei container supportano immagini dalle dimensioni che variano da diversi GB a decine di GB, e la maggior parte dei registri aziendali gestisce senza problemi immagini fino a 15-20 GB. Per i modelli molto grandi che superano questi limiti pratici, potresti dover considerare tecniche di quantizzazione per ridurre le dimensioni dei file o meccanismi di distribuzione alternativi. Tuttavia, per la maggior parte dei modelli di produzione, in particolare le varianti quantizzate come la virgola mobile a 8 bit (FP8) o il numero intero a 4 bit (INT4), la containerizzazione con ModelCar è pratica ed è consigliata.

Artefatti OCI per i modelli

ModelCar utilizza i container OCI per garantire la massima compatibilità con i sistemi meno recenti che non supportano completamente gli artefatti OCI, ma gli artefatti OCI sono probabilmente una scelta migliore e più efficiente per lo storage dei modelli. 

Gli ingegneri del software possono raggruppare i modelli in artefatti OCI anziché in container e archiviarli nel proprio repository di artefatti OCI. Al momento del deployment, puoi montare l'artefatto OCI direttamente sul pod di distribuzione dei modelli come storage, utilizzando un volume immagine Kubernetes. Il montaggio degli artefatti OCI è attualmente implementato nelle versioni recenti di podman ed il runtime dei container CRI-O, e sono in corso lavori per altri runtime, tra cui Containerd.

Containerizza i server MCP per il deployment aziendale

L'MCP si è affermato come un modo standard per connettere assistenti e agenti di IA con strumenti, sorgenti di dati e API esterni. I server MCP fungono da ponte tra i sistemi di IA e le risorse aziendali, facendo sì che sicurezza e governance diventino elementi fondamentali.

Per i server MCP che condividerai tra i team o distribuirai in ambienti di produzione, ti consigliamo di integrarli in container utilizzando gli stessi strumenti e processi di creazione utilizzati per le altre applicazioni. Questo approccio garantisce coerenza nella gestione, nella distribuzione e nella protezione di questi componenti. Il processo è noto a chiunque abbia applicazioni containerizzate: scrivi un containerfile, crea l'immagine, inviala al registro ed esegui il deployment con Red Hat OpenShift, Kubernetes, Podman o Docker.  Puoi utilizzare gli strumenti di creazione standard per firmare e verificare i server MCP, generare uno SBOM, archiviarli in repository di artefatti OCI e così via.

Come qualsiasi altro software, è possibile che codice dannoso penetri in un server MCP. Analizza e convalida continuamente i server MCP utilizzando Red Hat Trusted Profile Analyzer per identificare vulnerabilità, dipendenze dannose e violazioni delle policy.

Vantaggi dei server MCP containerizzati

Puoi scalare orizzontalmente i server MCP containerizzati per gestire l'aumento del carico, monitorarli utilizzando strumenti di osservabilità standard e gestirli in base ai criteri di sicurezza esistenti.

Il OpenShift Kubernetes MCP server illustra questo modello. Può essere eseguito in locale per lo sviluppo o distribuito nel cluster utilizzando il trasporto Streamable HTTP per l'accesso del team. Il server supporta modalità di accesso configurabili (sola lettura, non distruttivo o accesso completo) e si integra con il controllo degli accessi basato sui ruoli (RBAC) di Kubernetes per l'autorizzazione.

L'ecosistema di server MCP containerizzati si sta già formando. Ad esempio, l'operatore del ciclo di vita MCP facilita il deployment dei server MCP containerizzati e la loro connessione agli agenti tramite una configurazione Kubernetes native. Il Kuadrant MCP Gateway offre funzionalità di sicurezza avanzate per le aziende. Altri strumenti comuni, come Docker, funzionano anche con i server MCP nei container.

Quando non containerizzare i server MCP

Non tutti i server MCP traggono vantaggio dalla containerizzazione. La specifica MCP supporta due meccanismi di trasporto principali: stdio (input/output standard) e trasporti basati su HTTP (inclusi Streamable HTTP e il trasporto Server-Sent Events (SSE) esistente). Questa distinzione è importante per le decisioni di deployment.

I server MCP basati su stdio comunicano attraverso flussi di processo, mentre il client di IA genera il server come sottoprocesso. Questo modello funziona bene per scenari con utente singolo: un assistente di programmazione per sviluppatori, uno strumento di produttività locale o uno script di automazione personale. In questi casi, il server MCP viene eseguito sul laptop dell'utente, accede a file ed risorse locali e si arresta quando non è più necessario. La containerizzazione dei server MCP stdio aumenta la complessità, senza vantaggi significativi per questi scenari di utilizzo locali con utente singolo.

I server MCP basati su HTTP, invece, vengono eseguiti come processi indipendenti in grado di gestire contemporaneamente più connessioni client. Espongono gli endpoint di rete e funzionano più come i servizi web tradizionali. Questi server sono candidati naturali per la containerizzazione e beneficiano di distribuzione, scalabilità e gestione centralizzate.

Il framework decisionale è il seguente. 

• Per ambienti condivisi o di produzione: se condividi il server MCP con un team, se vi accedi tramite una rete o se lo distribuisci in un ambiente server, containerizzalo.
• Per gli agenti containerizzati: se l'agente viene eseguito in un container, un server MCP basato su stdio deve essere eseguito nello stesso container dell'agente, mentre un server MCP basato su HTTP deve essere eseguito in un container separato.
• Per utente singolo, uso locale: se un server MCP viene eseguito in locale sulla macchina di uno sviluppatore utilizzando il trasporto stdio, la containerizzazione è facoltativa e potrebbe aggiungere un sovraccarico non necessario. 

Containerizza le Agent Skills

Le capacità degli agenti sono emerse come alternativa e complemento ai server MCP. Si tratta di "cartelle di istruzioni, script e risorse che gli agenti possono individuare e utilizzare per eseguire operazioni in modo più accurato ed efficiente". La specifica per le capacità ne prevede la pacchettizzazione come file zip. 

Puoi estendere il tuo sistema di sviluppo al fine di raggruppare le capacità in container o artefatti OCI, proprio come i modelli e i server MCP. Quindi, puoi firmare e verificare le capacità, generare uno SBOM, archiviarle nei repository degli artefatti OCI, scaricarle e allegarle ai Pod proprio come i modelli. Poiché le capacità possono contenere script che possono essere specifici della piattaforma, OCI dispone anche di funzionalità per fornire un set di file diverso per ciascuna piattaforma. Se le applicazioni abilitate per le competenze non funzionano ancora con i container o gli artefatti OCI, puoi utilizzare l'utility a riga di comando ORAS per estrarre una capacità nella directory corretta. 

In alternativa, in futuro le capacità potrebbero essere gestite utilizzando i gestori di pacchetti, in modo simile a come vengono gestite altre librerie condivise per vari linguaggi di programmazione. In questo caso, le capacità verrebbero importate e utilizzate all'interno dei container, ma non necessariamente distribuite come container. 

Si tratta di una tecnologia emergente, quindi segui gli sviluppi futuri. 

Containerizza gli agenti di IA

Gli agenti di IA (sistemi autonomi in grado di pianificare ed eseguire attività in più fasi utilizzando modelli di IA e altri strumenti) rappresentano la prossima evoluzione delle applicazioni di IA. Man mano che gli agenti passano dai prototipi alla produzione, le aziende hanno bisogno di un approccio strutturato alla loro creazione, distribuzione e gestione.

Il progetto Kagenti fornisce un framework Kubernetes-native proprio per questo scopo. Kagenti funziona con qualsiasi framework di agenti o SDK e offre componenti modulari per la distribuzione in produzione. In sostanza, Kagenti tratta gli agenti come carichi di lavoro containerizzati che puoi definire in modo dichiarativo utilizzando risorse Kubernetes personalizzate.

Kagenti utilizza Shipwright e Buildah per creare gli agenti nei container. Se la tua organizzazione utilizza Tekton o Jenkins per i processi CI/CD, puoi aggiungere un'attività Buildah simile alle pipeline esistenti. Come accade per i modelli di IA ed i server MCP, puoi utilizzare i tuoi strumenti di creazione standard per firmare e verificare i container degli agenti, generare uno SBOM, archiviarli nei repository degli artefatti OCI e così via.

Come i server MCP, puoi sfruttare la scalabilità orizzontale degli agenti containerizzati per gestire l'aumento del carico, monitorarli utilizzando strumenti di osservabilità standard e gestirli in base ai criteri di sicurezza esistenti.  Puoi anche analizzare e convalidare continuamente i tuoi agenti utilizzando Red Hat Trusted Profile Analyzer per identificare vulnerabilità, dipendenze dannose e violazioni dei criteri.

Agenti e sub-agenti per utente singolo

Analogamente ai server MCP, non tutti gli agenti richiedono la containerizzazione. Gli agenti eseguiti in locale sul laptop di un singolo utente, come i sub-agenti generati da un assistente di programmazione o gli agenti di automazione personali, potrebbero non necessitare del sovraccarico della pacchettizzazione dei container e della distribuzione su Kubernetes. Questi agenti leggeri vengono spesso eseguiti come sottoprocessi di un'applicazione principale e condividono il contesto di sicurezza di tale applicazione.

In questi scenari a utente singolo, devi concentrarti sulla verifica che l'applicazione principale (l'IDE, l'assistente di programmazione o lo strumento di automazione) sia adeguatamente protetta, anziché containerizzare ogni sottocomponente. La gestione aziendale di questi agenti locali è un settore in evoluzione e le organizzazioni dovrebbero monitorare gli sviluppi relativi ai framework e agli strumenti degli agenti.

Container per il sandboxing

Poiché gli agenti, i server MCP ed i modelli che scrivono ed eseguono codice introducono nuove vulnerabilità, è consigliabile limitarne l'accesso ai sistemi e circoscrivere i danni che possono causare. A volte questa pratica viene definita "sandboxing degli agenti" o "sandboxing del codice". 

Puoi distribuire il software containerizzato con criteri di rete che limitano la comunicazione con i servizi esterni, dall'apertura e dal blocco delle porte fino all'inserimento in allow-list di siti web e servizi specifici. Le funzionalità RBAC e service mesh di Kubernetes offrono un controllo granulare degli accessi. In genere, i container OpenShift vengono eseguiti senza autorizzazioni root, limitando l'accesso ai dati ed alle risorse di elaborazione.  

I container presentano inoltre limiti all'utilizzo di CPU e memoria. Sulle workstation degli sviluppatori, Podman esegue i propri container senza autorizzazioni root per impostazione predefinita e ne limita l'accesso alla rete e al file system. OpenShift offre da tempo l'isolamento dei container e la versione Red Hat di Podman Desktop consente l'isolamento dei container anche sulle workstation degli sviluppatori.

Un'altra preoccupazione riguarda l'elaborazione incontrollata da parte degli agenti, che può portare a un attacco Denial of Service. Con OpenShift, gli amministratori dei cluster possono impostare quote di risorse per ogni spazio dei nomi, limitando le risorse di GPU, CPU, memoria e storage che un singolo progetto può utilizzare. Con quote di risorse ragionevoli, un agente fuori controllo non può sottrarre risorse del cluster ad altri carichi di lavoro.

Sebbene possano essere eseguiti su un laptop personale, abbiamo riscontrato che spesso vale la pena eseguire gli assistenti di programmazione e gli agenti personali in un container. Quando esegui un agente in un container sandbox, questo non può danneggiare i documenti importanti sul laptop o accedere a dati che non desideri vengano utilizzati. Ciò significa che puoi pre-approvare azioni comuni come la lettura/scrittura di file, consentire all'agente di operare con meno supervisione e rivedere semplicemente il risultato finale dell'attività assegnata.

Puoi anche avviare più agenti contemporaneamente e lasciare che svolgano il proprio lavoro in parallelo, senza interferenze. Puoi distribuire agenti a lunga esecuzione nel tuo spazio dei nomi personale in OpenShift, chiudere il laptop e tornare a casa mentre gli agenti continuano a lavorare per te. Puoi anche salvare il container dell'agente per preservarne lo stato e ripristinarlo in un secondo momento. Due progetti emergenti in quest'area sono paude per gli agenti di programmazione e openclaw-installer per OpenClaw.

Vantaggi della containerizzazione dei carichi di lavoro IA

La containerizzazione dei tuoi componenti di IA (modelli, server MCP e agenti) offre vantaggi significativi che si riflettono su tutta l'organizzazione.

Sicurezza della catena di approvvigionamento del software

È possibile firmare, attestare e verificare i container prima della distribuzione. Puoi richiedere che tutti i componenti di IA siano creati dai sistemi CI/CD che preferisci, scansionati per individuare le vulnerabilità e archiviati in registri approvati. Le attestazioni di provenienza forniscono un audit trail che mostra esattamente come ogni artefatto è stato prodotto.

Controllo delle versioni e rollback

Le immagini dei container sono immutabili e dotate di tag. Puoi distribuire versioni specifiche, eseguire il rollback alle versioni precedenti in caso di problemi e mantenere una cronologia chiara di cosa è stato distribuito e quando.

Distribuzione coerente

La stessa immagine container viene eseguita in modo identico negli ambienti di sviluppo, staging e produzione, riducendo il rischio che i file non vengano copiati correttamente da un ambiente all'altro.

Osservabilità

I carichi di lavoro containerizzati si integrano con l'infrastruttura di monitoraggio e registrazione esistente. Kagenti, ad esempio, supporta il tracciamento OpenTelemetry (OTEL) pronto all'uso, consentendoti di monitorare le operazioni degli agenti utilizzando lo stack di osservabilità standard.

Isolamento e controllo degli accessi

Infine, i container offrono funzionalità avanzate per il sandboxing, che aiutano a contenere la portata di qualsiasi problema.

Uno sguardo al futuro: identità dei carichi di lavoro e zero trust

La containerizzazione getta le basi per modelli di sicurezza più avanzati. Il progetto Kagenti sta valutando l'integrazione con SPIFFE/SPIRE per identità dei carichi di lavoro e architettura zero trust per agenti e server MCP. Sebbene si tratti di funzionalità emergenti, la containerizzazione dei componenti di IA e l'esecuzione su Kubernetes semplifica notevolmente l'adozione di queste funzioni di sicurezza man mano che maturano.

L'identità del carico di lavoro garantisce che ogni agente o server MCP disponga di un'identità crittograficamente verificabile, consentendo una comunicazione sicura tra servizi senza segreti condivisi. I principi zero trust (non fidarsi mai, verificare sempre) diventano pratici da implementare quando i componenti di IA sono containerizzati e possono essere integrati con l'infrastruttura di gestione delle identità e degli accessi esistente.

Considerazioni finali

I container OCI offrono un approccio collaudato e standardizzato alla creazione di pacchetti e alla distribuzione del software che si estende naturalmente ai carichi di lavoro IA. Containerizzando i tuoi modelli di IA, i server MCP ed gli agenti, offri allo stack di IA gli stessi livelli di governance, sicurezza e maturità operativa che già applichi alle tue applicazioni.

L'aspetto più importante è riconoscere quando la containerizzazione aggiunge valore. I container sono essenziali per distribuzioni di produzione condivise e collegate in rete. Per l'utilizzo locale e per singoli utenti, i container sono facoltativi, ma offrono sandboxing e portabilità su più dispositivi: sviluppi una sola volta ed esegui ovunque. Questo approccio pragmatico ti consente di applicare il giusto livello di governance a ciascun componente, evitando inutili complessità.

Red Hat OpenShift AI, Red Hat Trusted Artifact Signer, Red Hat Trusted Profile Analyzer e la versione Red Hat di Podman offrono una base solida per gestire i tuoi carichi di lavoro AI, dalla fase di test a quella di produzione. Red Hat aggiunge il supporto enterprise agli strumenti open source con community attive per aiutarti a stare al passo con gli ultimi sviluppi dell'IA.