I container sono una tecnologia che ha impattato notevolmente la distribuzione degli applicativi, dei database e dei servizi negli scenari virtualizzati, siano essi di tipo public o private cloud. Garantiscono indipendenza dall'hosting e affidabilità nella distribuzione, togliendoci il brutto compito di distribuire i binari manualmente e, molto spesso, a commettere errori. Dato il numero elevato di container, gli orchestrator permettono di gestire le istanze e le dimensioni dei container, gestendo automaticamente bilanciamenti di carico ed eventuali down dei nodi che si possono presentare. All'interno di Microsoft Azure disponiamo quindi di un servizio di nome Azure Container Service (ACS) che offre i principali orchestratori, come Kubernetes e DC/OS e Docker Swarm, per disporre di un cluster dove istanziare i nostri container.
Sono così leggeri e flessibili da prestarsi anche per altri scenari, come per esempio il testing, necessità nelle quali non necessitiamo delle funzioni avanzate offerte da un ochestrator, ma semplicemente vogliamo mettere in moto uno o più container. Azure Container Instance (ACI) è il servizio giusto per questa esigenza, perché con pochi semplici passi ci permette di istanziare uno o più container all'interno della stessa macchina.
Questa operazione è possibile per esempio direttamente dal portale, andando nella relativa sezione. Facendo nuova istanza ci viene proposto un wizard per indicare un nome del container, il percorso pubblico o privato e se vogliamo esporre pubblicamente il container.
Possiamo poi indicare informazioni basilari della macchina, quali CPU e RAM, quali porte esporre ed eventuali variabili d'ambiente.
Concludendo il wizard otteniamo in pochi secondi il nostro container funzionante che risponderà direttamente al DNS name label specificato, come per esempio ricciolo.westeurope.azurecontainer.io. Dal portale la gestione possiamo poi di monitorare i consumi ed eventualmente cancellare il gruppo.
Possiamo fare altrettanto anche da riga di comando, come per esempio da CLI.
az container create -g group --name ricciolo --image kitematic/hello-world-nginx --ports 80 --os-type Linux --cpu 1 --memory 1 --dns-name-label ricciolo
Lo scopo di ACI è quello di essere immediato nel fornire un'istanza del container ed altrettanto veloce nel distruggerla, dato che il pricing principalmente si basa sul tempo (al secondo) di utilizzo per la RAM e le CPU utilizzate.
Sebbene abbiamo parlato di group, in realtà fino ad ora abbiamo inserito un solo container. Possiamo inserire più container e condividere le stesse risorse e la stessa rete, a patto di usare porte diverse. Purtroppo il portale e CLI non supportano questa possibilità ed è necessario sfruttare ARM. Per ulteriori informazioni rimandiamo alla documentazione ufficiale: https://docs.microsoft.com/en-us/azure/container-instances/container-instances-container-groups
Commenti
Per inserire un commento, devi avere un account.
Fai il login e torna a questa pagina, oppure registrati alla nostra community.
Approfondimenti
Reactive form tipizzati con FormBuilder in Angular
Creare gruppi di client per Event Grid MQTT
Sfruttare MQTT in cloud e in edge con Azure Event Grid
Creare un'applicazione React e configurare Tailwind CSS
Utilizzare politiche di resiliency con Azure Container App
Utilizzare database e servizi con gli add-on di Container App
Short-circuiting della Pipeline in ASP.NET Core
Installare le Web App site extension tramite una pipeline di Azure DevOps
Creazione di componenti personalizzati in React.js con Tailwind CSS
Gestire errori funzionali tramite exception in ASP.NET Core Web API
Disabilitare automaticamente un workflow di GitHub
Supportare il sorting di dati tabellari in Blazor con QuickGrid
I più letti di oggi
- Miglioramenti nelle performance di Angular 16
- Ottimizzare le performance delle collection con le classi FrozenSet e FrozenDictionary
- HTML5 con CSS e JavaScript
- ecco tutte le novità pubblicate sui nostri siti questa settimana: https://aspit.co/wkly buon week-end!
- Ottimizzazione dei block template in Angular 17
- Disabilitare automaticamente un workflow di GitHub (parte 2)