Capire Azure Arc

Uno degli annunci più interessanti alla conferenza Ignite 2019 di Microsoft è stato Azure Arc, un nuovo strumento di gestione per infrastrutture di applicazioni cloud ibride. Basandosi sui concetti di Azure, Arc è progettato per consentire di gestire le risorse locali dal portale di Azure, distribuendo policy e servizi su macchine virtuali e Kubernetes. Include anche versioni containerizzate del database SQL di Azure e PostgreSQL Hyperscale per offrire alle applicazioni ibride basate su Kubernetes opzioni di dati coerenti con Azure.

Azure Arc estende il modello di Azure Resource Manager fino ai server e ai cluster Kubernetes. È progettato per gestire le risorse in modo simile a un cloud ovunque si trovino, trattando gli strumenti per le risorse di Azure come il tuo piano di controllo. Ciò lo pone a un livello molto più alto rispetto alla maggior parte degli strumenti di gestione. Ad esempio, se lo utilizzi con macchine virtuali in esecuzione su una rete Windows Server, gestirai le VM con gli strumenti di gestione Hyper-V e la configurazione del server e le applicazioni in esecuzione su di esse con Azure Arc.

Utilizzo di Azure Arc con i server

"Ovunque si trovino" è un principio chiave alla base di Azure Arc. Con il suo focus sulla gestione delle applicazioni, è indipendente dall'infrastruttura. Le VM che gestisce possono essere eseguite nel tuo data center, in una struttura di hosting o come server virtuali in un ambiente gestito e condiviso.

La gestione del server con Azure Arc è ora in anteprima pubblica, con un agente macchina connesso per Windows e Linux per gestire la connessione al servizio Azure Arc. Una volta connesso al cloud, puoi iniziare a gestirlo come se fosse una risorsa di Azure, parte di un gruppo di risorse. Ciò consente di distribuire criteri basati su PowerShell ai server connessi, sfruttando il lavoro svolto per fornire la gestione just-in-time e la configurazione dello stato desiderata. I server gestiti avranno bisogno della connettività ad Azure Arc, su SSL.

I server gestiti da Azure Arc non devono essere server fisici; possono essere macchine virtuali. Ciò consente di precaricare l'agente nelle immagini di base della VM prima che vengano distribuite. Come parte della configurazione del servizio, Azure Arc genera uno script personalizzato che verrà eseguito su server non connessi, scaricando e installando l'agente, prima di connettersi ad Azure e aggiungere il server come risorsa.

Gestione delle applicazioni Kubernetes in Azure Arc

Microsoft non ha ancora reso disponibile il supporto per Kubernetes di Azure Arc nell'anteprima pubblica; è ancora limitato all'anteprima dell'accesso privato del servizio. Tuttavia, Gabe Monroy, direttore del prodotto per Azure Application Platform, ne ha fatto una breve dimostrazione a Ignite.

Utilizzando il portale di Azure, Monroy ha mostrato per la prima volta un cluster Kubernetes in esecuzione gestito tramite policy basate su ARM di Azure. La politica iniziale che ha utilizzato controllava le porte di rete utilizzate dal cluster, bloccando le porte non necessarie per ridurre la superficie di attacco del cluster. La stessa policy potrebbe essere utilizzata per gestire tutti i cluster nell'infrastruttura globale di un'azienda. Scrivere le politiche una volta e utilizzarle molte volte in questo modo riduce al minimo il rischio di errori; testando in anticipo tutti i criteri, puoi essere certo che funzioneranno quando verranno distribuiti a livello globale.

L'altro vantaggio di un approccio basato su criteri è che puoi bloccare i cluster se non sono conformi. Fino a quando un cluster non segnala di essere conforme a tutti i criteri, il team di sviluppo dell'applicazione non può distribuire il codice. Con l'agente Azure Arc distribuito a tutti i cluster Kubernetes nella rete, hai un pannello di controllo per gestire tutti i criteri e tutte le distribuzioni.

È importante notare che non hai un modo per gestire direttamente i server fisici e l'installazione di Kubernetes. Tutto ciò che ti offre il portale di Azure sono le politiche e il codice in esecuzione nel cluster. Puoi usare i criteri per definire come si comporterà un cluster, ma non puoi distribuire nuovi nodi a meno che non siano installati il ​​runtime Kubernetes e l'agente Azure Arc. Non appena un nuovo cluster viene distribuito e connesso ad Azure Arc, i criteri vengono applicati automaticamente, assicurando che i criteri di sicurezza siano in atto senza configurare manualmente tutto.

Un aspetto interessante della dimostrazione è stato un criterio che collegava Azure Arc a GitHub, prendendo di mira gli spazi dei nomi o i cluster Kubernetes e gestendo le distribuzioni da un repository specifico. Utilizzando questo criterio, qualsiasi richiesta di pull al repository attiverebbe la distribuzione di un'applicazione aggiornata. La stessa policy potrebbe essere utilizzata per caricare il codice su un nuovo cluster non appena è stato configurato. Qualsiasi aggiornamento futuro del codice verrà distribuito automaticamente, mantenendo tutti i tuoi siti con le versioni più recenti.

È facile immaginare che un nuovo set di server, precaricato con Kubernetes e l'agente Azure Arc, venga consegnato a un nuovo sito perimetrale. Una volta connessi a una WAN e accesi, caricavano automaticamente i criteri più recenti e, una volta conformi, scaricavano le loro applicazioni e iniziavano a funzionare con un'interazione umana minima.

Presentazione di un nuovo modello di gestione incentrato sul cloud e basato sull'app

È forse meglio pensare ad Azure Arc come il primo di una nuova generazione di strumenti di gestione delle applicazioni basati su criteri, soprattutto quando viene utilizzato per automatizzare le distribuzioni di applicazioni in una rete globale. L'integrazione nel flusso gitops ha senso, utilizzando Arc per attivare le distribuzioni di applicazioni quando una richiesta pull viene unita e assicurando che le politiche di sicurezza appropriate vengano applicate al cluster Kubernetes host o alle macchine virtuali.

Il punto di vista di Microsoft sul cloud è che i sistemi locali non scompariranno e con la crescente importanza delle distribuzioni edge, la definizione di locale crescerà, ciò non significa che quei sistemi locali non dovrebbero trarre vantaggio dalle tecnologie cloud e da modalità di lavoro informate sul cloud. Azure Arc si concentra sull'automazione dell'infrastruttura per un'applicazione, utilizzando criteri per garantire la conformità della sicurezza.

Se ci pensi, questa è un'estensione logica di devops e fa parte del passaggio a un terzo livello di gestione in un ambiente cloud. Concentrandosi sulle infrastrutture virtuali delle applicazioni, sia basate su VM che su container, Azure Arc separa le operazioni delle applicazioni dalle operazioni dell'infrastruttura.

In un ambiente cloud ibrido non è necessario che il team delle applicazioni sappia nulla dell'infrastruttura fisica sottostante. Un team separato avrà invece la responsabilità dei server fisici, dei sistemi operativi host, degli hypervisor e dell'installazione di Kubernetes, con strumenti come Azure Arc utilizzati dal team dell'applicazione per gestire le proprie applicazioni all'edge, nei sistemi iperconvergenti, nei data center tradizionali e in il cloud, tutto dalla stessa console ospitata nel cloud.

Abbiamo cambiato il modo in cui gestiamo l'infrastruttura con container e virtualizzazione e il modo in cui creiamo e gestiamo le applicazioni con devops. Perché non fornire strumenti per unire i due approcci? Con Azure Arc il lato operativo dell'equazione devops ottiene una piattaforma per separare le applicazioni dall'infrastruttura, con la possibilità di gestire e controllare tali applicazioni da un nuovo piano di controllo ospitato nel cloud. È una visione attraente e sarà interessante vedere come Microsoft la offre.