Azure Container Instances

Azure Container Instances (ACI) è il modo più rapido per eseguire un carico di lavoro containerizzato in Azure senza gestire server o orchestratori. È sufficiente fornire un'immagine del container: Azure la esegue in pochi secondi su un'infrastruttura condivisa e multi-tenant. ACI è ideale per attività di breve durata, processi batch, agenti di compilazione e carichi di lavoro basati su eventi, per i quali avviare un intero cluster Kubernetes comporterebbe un overhead eccessivo.

Avvii un container ACI con un singolo comando az container create. Specifichi l'immagine, il gruppo di risorse, la CPU e la memoria. ACI esegue il pull dell'immagine, alloca le risorse e avvia il container, in genere entro 5-10 secondi. Ogni istanza del container riceve un fully qualified domain name (FQDN) univoco se assegna un'etichetta per il nome DNS, diventando così immediatamente accessibile da Internet.

Passi la configurazione ai container ACI usando variabili di ambiente specificate al momento della creazione. Per valori sensibili, come chiavi API o password, usi le variabili di ambiente protette: dopo la distribuzione, questi valori non vengono mostrati nel portale Azure né nell'output della CLI, evitando così l'esposizione accidentale nei log o nei registri di controllo. I valori protetti restano comunque accessibili all'interno del container durante l'esecuzione, come normali variabili di ambiente.

ACI fattura in base al secondo, considerando i core CPU e i GB di memoria allocati, senza un periodo minimo di fatturazione. Paga solo quando il container è in esecuzione: non appena si arresta, si interrompe anche la fatturazione. Questo rende ACI estremamente conveniente per i carichi di lavoro di breve durata. È possibile allocare da 0,1 a 4 core CPU e da 0,1 a 16 GB di memoria per ogni gruppo di container, nelle combinazioni supportate.

ACI supporta tre criteri di riavvio che controllano il comportamento del container dopo la sua chiusura. Always (predefinito) riavvia il container ogni volta che si chiude, ed è adatto ai servizi a esecuzione prolungata. Never esegue il container una sola volta e lo lascia nello stato terminato, caratteristica ideale per i processi batch. OnFailure riavvia il container solo quando si chiude con un codice di uscita diverso da zero, risultando utile per i modelli di ripetizione in caso di errore.

Un gruppo di container è un insieme di container che condividono ciclo di vita, rete e archiviazione, in modo simile a un pod Kubernetes. I container dello stesso gruppo condividono un indirizzo IP locale e lo spazio dei nomi delle porte, quindi possono comunicare tramite localhost. Un modello comune consiste nell'inserire nello stesso gruppo un container con l'applicazione principale e un container sidecar, ad esempio un agente di logging o un proxy, definiti tramite un modello YAML o ARM.

Per impostazione predefinita, i container ACI sono senza stato: i dati scritti nel file system del container vanno persi quando il container viene riavviato. Monti una condivisione Azure Files come volume per mantenere i dati tra i riavvii del container o condividerli tra container dello stesso gruppo. Quando crea l'istanza del container, specifichi il nome dell'account di archiviazione, la chiave e il nome della condivisione file.

ACI supporta istanze di container con GPU (K80, V100) per carichi di lavoro di inferenza ML, elaborazione video e calcolo scientifico. Le istanze con GPU sono disponibili in determinate aree e richiedono container Linux. La fatturazione avviene per GPU/secondo, rendendole convenienti negli scenari di inferenza intermittente: si avvia un container con GPU, si esegue il modello e lo si elimina immediatamente, con un costo molto inferiore rispetto a una macchina virtuale con GPU dedicata in esecuzione 24 ore su 24, 7 giorni su 7.

Distribuisca i gruppi di container ACI in una sottorete dedicata all'interno di una VNet per assegnare loro indirizzi IP privati e consentire l'accesso ad altre risorse connesse alla VNet, come database e macchine virtuali, senza esporle a Internet. ACI integrato con una VNet richiede una sottorete dedicata e delegata, delegata a Microsoft.ContainerInstance/containerGroups, e non supporta l'assegnazione di IP pubblici.

ACI si integra con AKS come nodo virtuale tramite il progetto open source Virtual Kubelet. Quando un cluster AKS registra una domanda improvvisa che supera la capacità dei nodi VM, Kubernetes può pianificare i pod su un nodo ACI virtuale, avviando vere istanze di container ACI. In questo modo si ottiene una scalabilità elastica senza dover predisporre in anticipo altri nodi VM e si paga il calcolo ACI solo durante il periodo di picco.

Scelga ACI per attività di breve durata, processi batch, agenti di compilazione CI e container temporanei per i quali l'overhead di Kubernetes non è necessario. Scelga AKS per microservizi multi-container a esecuzione prolungata che richiedono individuazione dei servizi, controlli di integrità, aggiornamenti in sequenza e rete del cluster. Scelga App Service quando desidera le funzionalità tipiche del PaaS, come slot di distribuzione, certificati gestiti e autenticazione integrata, senza dover gestire direttamente la rete dei container.

Verifichi la Sua comprensione dei concetti di Microsoft Azure Fundamentals (AZ-900) trattati in questa lezione.

In questa lezione ha imparato che Azure Container Instances esegue i container in pochi secondi senza gestione dei server, con fatturazione al secondo per CPU e memoria; i gruppi di container consentono a più container di condividere rete e archiviazione come un pod Kubernetes; infine, i criteri di riavvio (Always, Never, OnFailure) controllano il ciclo di vita del container dopo la chiusura. Ora esploreremo i concetti di Kubernetes per Azure.