Effettuare il provisioning di microservizi e distribuirli in modo prevedibile in Azure

Questa esercitazione illustra come effettuare il provisioning di un'applicazione costituita da microservizi e come distribuirla nel servizio app di Azure come un'unità singola e in modo prevedibile usando modelli di gruppo di risorse JSON e script di PowerShell.

Quando si effettua il provisioning e si distribuiscono applicazioni su vasta scala costituite la microservizi altamente disaccoppiati, ripetibilità e prevedibilità sono fondamentali. Servizio app di Azure consente di creare microservizi che includono app Web, back-end per dispositivi mobili e app per le API. Gestione risorse di Azure consente di gestire tutti i microservizi come unità, insieme alle dipendenze delle risorse, ad esempio le impostazioni di controllo del codice sorgente e del database. A questo punto è possibile distribuire l'applicazione usando modelli JSON e semplici script di PowerShell.

Contenuto dell'esercitazione

In questa esercitazione si distribuirà un'applicazione che include:

  • Due app del servizio app (ovvero due microservizi)
  • Un database SQL di back-end
  • Impostazioni dell'app, stringhe di connessione e controllo del codice sorgente
  • Application Insights, avvisi, impostazioni di scalabilità automatica

Strumenti da usare

In questa esercitazione si useranno gli strumenti seguenti. Non essendo una discussione completa sugli strumenti, verrà considerato solo lo scenario end-to-end, fornendo una breve introduzione per ogni strumento e dove è possibile trovare altre informazioni specifiche.

Modelli di Gestione risorse di Azure (JSON)

Ogni volta che si crea, ad esempio, un'app nel servizio app di Azure, Azure Resource Manager usa un modello JSON per creare l'intero gruppo di risorse con le risorse del componente. Un modello complesso disponibile in Azure Marketplace può includere il database, account di archiviazione, il piano di servizio app, la stessa app, regole di avviso, impostazioni dell'app, impostazioni di scalabilità automatica e altro ancora. Tutti questi modelli sono disponibili tramite PowerShell. Per altre informazioni sui modelli Azure Resource Manager, vedere Creazione di Azure Resource Manager modelli

Azure SDK 2.6 per Visual Studio

L'SDK più recente include miglioramenti a livello di supporto per i modelli di Gestione risorse di Azure nell'editor JSON. È possibile usarlo per creare rapidamente da zero un modello di gruppo di risorse o aprire un modello JSON esistente (ad esempio, un modello della raccolta scaricato) per modificarlo, popolare il file di parametri e distribuire il gruppo di risorse direttamente da una soluzione del gruppo di risorse di Azure.

Per altre informazioni, vedere Azure SDK 2.6 per Visual Studio.

Azure PowerShell 0.8.0 o versione successiva

A partire dalla versione 0.8.0, l'installazione di Azure PowerShell include il modulo Gestione risorse di Azure, oltre al modulo Azure. Il nuovo modulo permette di creare script per la distribuzione di gruppi di risorse.

Per altre informazioni, vedere Uso di Azure PowerShell con Azure Resource Manager

Azure Resource Explorer

Questo strumento in anteprima consente di esplorare le definizioni JSON di tutti i gruppi di risorse nella sottoscrizione e delle singole risorse. Con lo strumento è possibile modificare le definizioni JSON di una risorsa, eliminare l'intera gerarchia di risorse e crearne di nuove. Le informazioni immediatamente disponibili in questo strumento sono molto utili per la creazione di modelli perché mostrano quali proprietà è necessario impostare per un particolare tipo di risorsa, i valori corretti e così via. È anche possibile creare il gruppo di risorse nel portale di Azuree quindi esaminarne le definizioni JSON nello strumento explorer per facilitare la creazione di modelli per il gruppo di risorse.

Pulsante Deploy to Azure per la distribuzione in Azure

Se si usa GitHub per il controllo del codice sorgente, è possibile inserire nel file README.MD un pulsante Deploy to Azure , che abilita un'interfaccia utente di distribuzione in Azure pronta all'uso. Mentre si può procedere in questo modo per qualsiasi app semplice, è possibile estendere questa opzione per abilitare la distribuzione di un intero gruppo di risorse inserendo un file azuredeploy.json nella radice del repository. Questo file JSON, che contiene il modello di gruppo di risorse, verrà usato dal pulsante Deploy to Azure per creare il gruppo di risorse. Per un esempio vedere ToDoApp , l'app di esempio che verrà usata in questa esercitazione.

Ottenere il modello del gruppo di risorse di esempio

Ecco come scaricarlo.

  1. Passare all'esempio di servizio app ToDoApp .

  2. Nel file readme.md fare clic su Deploy to Azure.

  3. Verrà aperto il sito deploy-to-azure e verrà chiesto di immettere i parametri di distribuzione. Come si noterà, la maggior parte dei campi è già popolata con il nome del repository e alcune stringhe casuali. È possibile modificare tutti i campi, se lo si desidera, ma le uniche informazioni che è necessario immettere sono l'accesso amministrativo e la password di SQL Server, quindi fare clic su Next.

    Mostra i parametri di distribuzione di input nel sito deploy-to-azure.

  4. Fare quindi clic su Deploy per avviare il processo di distribuzione. Al termine del processo, fare clic sul collegamento http://todoappXXXX.azurewebsites.net per accedere all'applicazione distribuita.

    Mostra il processo di distribuzione dell'applicazione.

    La visualizzazione dell'interfaccia utente sarà un po' lenta alla prima esplorazione, perché le app sono in fase di avvio, ma l'applicazione è di sicuro completamente funzionante.

  5. Tornando alla pagina di distribuzione, fare clic sul collegamento Gestisci per visualizzare la nuova applicazione nel portale di Azure.

  6. Nell'elenco a discesa Informazioni di base fare clic sul collegamento del gruppo di risorse. Notare anche che l'app è già connessa al repository GitHub in Progetto esterno.

    Mostra il collegamento Gruppo di risorse nella sezione a discesa Informazioni di base.

  7. Nel pannello del gruppo di risorse si noterà che il gruppo include già due app e un database SQL.

    Visualizza le risorse disponibili nel gruppo di risorse.

Tutto ciò che si è appena visto in pochi minuti è un'applicazione di microservizi completamente distribuita, con tutti i componenti, le dipendenze, le impostazioni, il database e la pubblicazione continua configurati da un'orchestrazione automatizzata in Gestione risorse di Azure. Tutte le operazioni sono state eseguite da due elementi:

  • Il pulsante Deploy to Azure
  • Il file azuredeploy.json nella radice del repository

È possibile distribuire la stessa applicazione decine, centinaia o migliaia di volte e avere ogni volta esattamente la stessa configurazione. La ripetibilità e la prevedibilità di questo approccio consentono di distribuire applicazioni su vasta scala in modo semplice e affidabile.

Esaminare (o modificare) AZUREDEPLOY.JSON

A questo punto si esaminerà come è stato configurato il repository GitHub. Si userà l'editor JSON incluso in Azure .NET SDK, quindi se Azure .NET SDK 2.6non è già installato, installarlo ora.

  1. Clonare il repository ToDoApp con lo strumento git preferito. Nella schermata seguente questa operazione viene eseguita con Team Explorer in Visual Studio 2013.

    Illustra come usare uno strumento Git per clonare il repository ToDoApp.

  2. Dalla radice del repository aprire azuredeploy.json in Visual Studio. Se il riquadro Struttura JSON non è visibile, è necessario installare Azure .NET SDK.

    Mostra il riquadro Struttura JSON in Visual Studio.

Non verranno descritti tutti i dettagli del formato JSON, ma nella sezione Altre risorse sono disponibili collegamenti per l'apprendimento del linguaggio del modello di gruppo di risorse. In questa esercitazione verranno illustrate solo le interessanti funzionalità che possono semplificare le attività iniziali per creare un modello personalizzato per la distribuzione di app.

Parametri

Nella sezione dei parametri è possibile osservare che la maggior parte di essi corrisponde all'input richiesto tramite il pulsante Deploy to Azure . Il sito aperto tramite il pulsante Deploy to Azure popola l'interfaccia utente di input usando i parametri definiti nel file azuredeploy.json. Questi parametri sono usati in tutte le definizioni di risorse, ad esempio nomi delle risorse, valori delle proprietà e così via.

Risorse

Come si può vedere, nel nodo delle risorse sono definite 4 risorse di primo livello, quali un'istanza di SQL Server, un piano di servizio app e due app.

Piano di servizio app

Si inizierà con una semplice risorsa a livello di radice in JSON. In Struttura JSON fare clic sul piano di servizio app denominato [hostingPlanName] per evidenziare il codice JSON corrispondente.

Mostra la sezione [hostingPlanName] del codice JSON.

Si noti che l'elemento type specifica la stringa per un piano di servizio app (che molto tempo fa era definito server farm), altri elementi e proprietà sono compilati con i parametri definiti nel file JSON e questa risorsa non include risorse annidate.

Nota

Notare anche che il valore apiVersion indica ad Azure quale versione dell'API REST usare con la definizione delle risorse JSON e può influire sulla formattazione della risorsa all'interno di {}.

SQL Server

Fare quindi clic sulla risorsa di SQL Server denominata SQLServer in Struttura JSON.

Mostra la SQL Server denominata SQLServer nella struttura JSON.

Nel codice JSON evidenziato notare quando indicato di seguito:

  • Per usare i parametri, assicurarsi che le risorse create siano denominate e configurate in modo coerente tra di esse.

  • La risorsa SQLServer ha due risorse annidate, ognuna con un valore diverso per type.

  • Le risorse annidate in “resources”: […], dove sono definite le regole di database e del firewall, includono un elemento dependsOn che specifica l'ID risorsa della risorsa SQLServer a livello di radice. Questo elemento indica a Gestione risorse di Azure che "prima di creare questa risorsa, deve esistere già l'altra risorsa e se l'altra risorsa è definita nel modello, dev'essere creata prima quella".

    Nota

    Per altre informazioni sull'uso della funzione resourceId(), vedere Funzioni del modello di Azure Resource Manager.

  • L'elemento dependsOn indica a Gestione risorse di Azure quali risorse possono essere create in parallelo e quali devono essere create in sequenza.

app del servizio app

Si passerà ora alle app effettive, che sono più complesse. Fare clic sull'app [variables('apiSiteName')] in Struttura JSON per evidenziare il relativo codice JSON. Come si noterà, diventa tutto molto più interessante. A questo scopo, le funzionalità verranno descritte una per una:

Risorsa radice

L'app dipende da due diverse risorse. Ciò significa che Azure Resource Manager creerà l'app solo dopo la creazione del piano di servizio app e dell'istanza di SQL Server.

Mostra le dipendenze dell'app nel piano di servizio app e nell SQL Server istanza.

Impostazioni app

Le impostazioni dell'app vengono definite anche come risorsa annidata.

Mostra le impostazioni dell'app definite come risorsa annidata nel codice JSON.

Nell'elemento properties per config/appsettings sono disponibili due impostazioni app nel formato "<name>" : "<value>".

  • PROJECT è un' impostazione KUDU che indica alla distribuzione di Azure quale progetto usare in una soluzione di Visual Studio con più progetti. Più avanti verrà illustrato come configurare il controllo del codice sorgente, ma poiché il codice di ToDoApp è una soluzione di Visual Studio con più progetti, questa impostazione è necessaria.
  • clientUrl è semplicemente un'impostazione app usata dal codice dell'applicazione.
Stringhe di connessione

Le stringhe di connessione vengono definite anche come risorsa annidata.

Illustra come le stringhe di connessione vengono definite come risorsa annidata nel codice JSON.

Nell'elemento properties per config/connectionstrings ogni stringa di connessione è definita anche come coppia nome/valore con il formato specifico "<name>" : {"value": "…", "type": "…"}. Per l'elemento type i valori possibili sono MySql, SQLServer, SQLAzure e Custom.

Suggerimento

Per un elenco definitivo di tipi di stringhe di connessione, eseguire il comando seguente in Azure PowerShell: [Enum]::GetNames("Microsoft.WindowsAzure.Commands.Utilities.Websites.Services.WebEntities.DatabaseType")

Controllo del codice sorgente

Le impostazioni di controllo del codice sorgente vengono definite anche come risorsa annidata. Gestione risorse di Azure usa questa risorsa per configurare la pubblicazione continua (vedere più avanti l'avvertenza per IsManualIntegration ) e anche per l'avvio automatico della distribuzione del codice applicazione durante l'elaborazione del file JSON.

Illustra come le impostazioni del controllo del codice sorgente vengono definite come risorsa annidata nel codice JSON.

RepoUrl e branch devono essere abbastanza intuitive e puntare al repository Git e al nome del ramo dal quale viene eseguita la pubblicazione. Anche in questo caso, sono definite dai parametri di input.

Si noti che nell'elemento dependsOn, oltre alla risorsa app stessa, sourcecontrols/web dipende anche da config/appsettings e config/connectionstrings. Il motivo è che dopo la configurazione di sourcecontrols/web , il processo di distribuzione di Azure tenta automaticamente di distribuire, compilare e avviare il codice dell'applicazione. L'inserimento di questa dipendenza consente di assicurare l'accesso dell'applicazione alle impostazioni delle app e alle impostazioni di connessione necessarie prima di eseguire il codice dell'applicazione.

Nota

Notare anche che IsManualIntegration è impostata su true. Questa proprietà è necessaria nell'esercitazione, perché non si è effettivamente il proprietario del repository GitHub e quindi non è possibile concedere ad Azure l'autorizzazione per configurare la pubblicazione continua da ToDoApp, (ovvero eseguire il push degli aggiornamenti automatici del repository ad Azure). È possibile usare il valore predefinito false per il repository specificato solo se le credenziali GitHub del proprietario sono già state configurate nel portale di Azure . In altre parole, se in precedenza è stato impostato il controllo del codice sorgente in GitHub o BitBucket per qualsiasi app nel Portale di Azure usando le proprie credenziali utente, Azure memorizzerà le credenziali e le userà ogni volta che in seguito si distribuirà un'app da GitHub o BitBucket. Tuttavia, se questa operazione non è ancora stata eseguita, la distribuzione del modello JSON non riuscirà quando Azure Resource Manager tenta di configurare le impostazioni di controllo del codice sorgente dell'app, perché non può connettersi a GitHub o BitBucket con le credenziali del proprietario del repository.

Confrontare il modello JSON con il gruppo di risorse distribuite

Qui è possibile scorrere tutti i pannelli dell'app nel portale di Azure, ma esiste un altro strumento altrettanto, se non più, utile. Passare allo strumento di anteprima di Esplora risorse di Azure che fornisce una rappresentazione JSON di tutti i gruppi di risorse nelle proprie sottoscrizioni, così come esistono effettivamente nel back-end di Azure. È anche possibile vedere in che modo la gerarchia JSON del gruppo di risorse in Azure corrisponde alla gerarchia nel file modello usato per crearla.

Ad esempio, se si passa allo strumento Esplora risorse di Azure e si espandono i nodi nello strumento, si vedranno il gruppo di risorse e le risorse a livello di radice raccolte nei rispettivi tipi di risorse.

Visualizzare il gruppo di risorse e le risorse a livello radice nello strumento Esplora risorse di Azure espanso.

Se si esegue il drill-down fino a un'app, dovrebbero essere visibili i dettagli di configurazione dell'app analoghi alla schermata seguente:

Eseguire il drill-down per visualizzare i dettagli di configurazione nell'app.

Anche in questo caso, le risorse annidate avranno una gerarchia molto simile a quelle nel file modello JSON e saranno visualizzate impostazioni app, stringhe di connessione e così via, adeguatamente riflesse nel riquadro JSON. L'assenza di impostazioni a questo punto può indicare un problema con il file JSON e può contribuire a risolvere i problemi del file modello JSON.

Distribuire manualmente il modello di gruppo di risorse

Il pulsante Deploy to Azure è molto utile, ma consente di distribuire il modello di gruppo di risorse in azuredeploy.json solo se è già stato effettuato il push di azuredeploy.json a GitHub. Azure .NET SDK fornisce anche gli strumenti per la distribuzione di qualsiasi file modello JSON direttamente dal computer locale. A questo scopo, eseguire la procedura seguente.

  1. In Visual Studio fare clic su File > Nuovo > Progetto.

  2. Fare clic su Visual C# > Cloud Azure > Resource Group e quindi su OK.

    Creare un nuovo progetto come gruppo di risorse di Azure in Azure .NET SDK.

  3. In Seleziona modello di Azure selezionare Modello vuoto e fare clic su OK.

  4. Trascinare azuredeploy.json nella cartella Modello del nuovo progetto.

    Mostra il risultato del trascinamento azuredeploy.jsfile nella cartella Modello del progetto.

  5. Da Esplora soluzioni aprire il file azuredeploy.json copiato.

  6. Ai fini di questa dimostrazione, si aggiungeranno al file JSON alcune risorse standard di Application Insights, facendo clic su Aggiungi risorsa. Se si è interessati solo alla distribuzione del file JSON, ignorare i passaggi relativi alla distribuzione.

    Mostra il pulsante Aggiungi risorsa che è possibile usare per aggiungere risorse di Application Insight standard al file JSON.

  7. Selezionare Application Insights per app Web, assicurarsi che siano selezionati un piano di servizio app esistente e un'app e quindi fare clic su Aggiungi.

    Mostra la selezione di Impostazioni applicazione Insights app Web, Nome, Piano di servizio app e App Web.

    A questo punto saranno visualizzate diverse nuove risorse che, a seconda della risorsa e delle operazioni che esegue, presentano dipendenze dal piano di servizio app o dall'app. Queste risorse non sono abilitate dalla relativa definizione esistente, perciò si procederà alla modifica.

    Visualizzare le nuove risorse con dipendenze dal piano di servizio app o dall'app.

  8. In Struttura JSON fare clic su appInsights AutoScale per evidenziare il relativo codice JSON. Questa è l'impostazione della scalabilità per il piano di servizio app.

  9. Nel codice JSON evidenziato individuare le proprietà location e enabled e impostarle come illustrato di seguito.

    Mostra la posizione e le proprietà abilitate nel codice JSON di scalabilità automatica di appInsights e i valori su cui è necessario impostarle.

  10. In Struttura JSON fare clic su CPUHigh appInsights per evidenziare il relativo codice JSON. Si tratta di un avviso.

  11. Individuare le proprietà location e isEnabled e impostarle come illustrato di seguito. Eseguire la stessa operazione per gli altri tre avvisi (lampadine viola).

    Mostra le proprietà location e isEnabled nel codice JSON CPUHigh appInsights e i valori su cui è necessario impostarli.

  12. A questo punto si è pronti per la distribuzione. Fare clic con il pulsante destro del mouse sul progetto e scegliere > Distribuisci nuova distribuzione.

    Illustra come distribuire il nuovo progetto.

  13. Accedere al proprio account Azure, se non si è già connessi.

  14. Selezionare un gruppo di risorse esistente nella sottoscrizione o creare un nuovo gruppo, selezionare azuredeploy.json, quindi fare clic su Modifica parametri.

    Illustra come modificare i parametri nel azuredeploy.jsfile.

    A questo punto si sarà in grado di modificare tutti i parametri definiti nel file modello in una tabella. I parametri che definiscono i valori predefiniti avranno già i relativi valori predefiniti e i parametri che definiscono un elenco di valori consentiti saranno visualizzati come elenchi a discesa.

    Mostra i parametri che definiscono un elenco di valori consentiti come elenchi a discesa.

  15. Compilare tutti i parametri vuoti e usare l' indirizzo del repository GitHub per ToDoApp in repoUrl. Fare quindi clic su Salva.

    Mostra i parametri appena compilati per l'azuredeploy.jsnel file.

    Nota

    La scalabilità automatica è una funzionalità offerta nel livello Standard o superiore e gli avvisi a livello di piano sono funzionalità offerte nel livello Basic o superiore. Sarà necessario impostare il parametro sku su Standard o Premium per visualizzare tutte le nuove risorse di Application Insights evidenziate.

  16. Fare clic su Distribuisci. Se è stata selezionata l'opzione Salva password, la password verrà salvata nel file di parametri come testo normale. In caso contrario, verrà richiesto di immettere la password del database durante il processo di distribuzione.

La procedura è terminata. A questo punto basta passare al portale di Azure e allo strumento Esplora risorse di Azure per visualizzare i nuovi avvisi e le impostazioni di scalabilità automatica aggiunte all'applicazione JSON distribuita.

I passaggi in questa sezione hanno eseguito principalmente le operazioni seguenti:

  1. Preparazione del file modello
  2. Creazione di un file di parametri da usare con il file modello
  3. Distribuzione del file modello con il file di parametri

L'ultimo passaggio viene eseguito facilmente da un cmdlet di PowerShell. Per vedere le operazioni eseguite da Visual Studio durante la distribuzione dell'applicazione, aprire Scripts\Deploy-AzureResourceGroup.ps1. In questo file è presente una quantità elevata di codice, ma verrà evidenziato solo tutto il codice pertinente e necessario per la distribuzione del file modello con il file di parametri.

Mostra il codice pertinente nello script che è necessario usare per distribuire il file modello con il file di parametri.

L'ultimo cmdlet, New-AzureResourceGroup, è quello che esegue effettivamente l'azione. Tutto questo serve a dimostrare che con strumenti appropriati, distribuire l'applicazione cloud in modo prevedibile è relativamente semplice. Ogni volta che si esegue il cmdlet sullo stesso modello con lo stesso file di parametri si otterrà lo stesso risultato.

Riepilogo

In DevOps la ripetibilità e la prevedibilità sono fondamentali per la riuscita della distribuzione di un'applicazione su vasta scala costituita da microservizi. In questa esercitazione è stata distribuita in Azure un'applicazione con due microservizi come singolo gruppo di risorse usando il modello di Gestione risorse di Azure. È auspicabile che si siano acquisite le conoscenze necessarie per iniziare a convertire l'applicazione in Azure in un modello, in modo da poterne effettuare il provisioning e distribuirla in modo prevedibile.

Altre risorse

Passaggi successivi

Per informazioni sulla sintassi e le proprietà JSON per i tipi di risorsa distribuiti in questo articolo, vedere: