Distribuire un flusso di lavoro di App per la logica di Azure con un modello di Resource Manager
Se si usa Azure già da un po', Azure Resource Manager dovrebbe essere un concetto noto. Analizziamo il ruolo di Resource Manager e definiamo cosa costituisce un modello di Resource Manager.
Che cos'è Azure Resource Manager?
Azure Resource Manager è l'interfaccia per gestire e organizzare le risorse cloud. Si può pensare a Resource Manager come a un modo per distribuire le risorse cloud.
Se si ha familiarità con i gruppi di risorse di Azure, si saprà che consentono di considerare set di risorse correlate come una singola unità. Resource Manager organizza i gruppi di risorse che consentono di distribuire, gestire ed eliminare tutte le risorse in un'unica azione.
Si pensi ai modelli finanziari eseguiti per gli analisti. Per eseguire un modello, potrebbe essere necessario uno o più macchine virtuali (VM), un database per archiviare i dati e una rete virtuale per consentire la connettività tra tutti i componenti. Con Resource Manager queste risorse possono essere distribuite nello stesso gruppo di risorse e gestite e monitorate insieme. Al termine sarà possibile eliminare tutte le risorse in un gruppo di risorse in un'unica operazione.
Cosa sono i modelli di Azure Resource Manager?
Un modello di Resource Manager definisce esattamente tutte le risorse di Resource Manager in una distribuzione. È possibile distribuire un modello di Resource Manager in un gruppo di risorse in un'unica operazione.
Un modello di Resource Manager è un file JSON, il che lo rende una forma di automazione dichiarativa. L'automazione dichiarativa indica che si possono definire le risorse necessarie, ma non come crearle. In altre parole, si definiscono gli elementi necessari e Resource Manager deve assicurarsi che le risorse vengano distribuite correttamente.
L'automazione dichiarativa è simile al modo in cui i Web browser visualizzano i file HTML. Il file HTML descrive quali elementi vengono visualizzati nella pagina, ma non come visualizzarli. Il modo in cui visualizzarli è responsabilità del Web browser.
Nota
I modelli di Resource Manager a volte sono noti anche come modelli ARM. È tuttavia preferibile usare i nomi completi: modelli di Azure Resource Manager o modelli di Resource Manager.
Perché usare i modelli di Resource Manager?
L'uso dei modelli di Resource Manager rende le distribuzioni più rapide e ripetibili. Ad esempio non è più necessario creare una macchina virtuale nel portale, attenderne il completamento, creare la successiva e così via. Resource Manager si occupa dell'intera distribuzione.
Altri vantaggi da considerare sono i seguenti:
I modelli migliorano la coerenza.
I modelli di Resource Manager offrono un linguaggio comune per descrivere le distribuzioni. Indipendentemente dagli strumenti o SDK usati per distribuire il modello, la struttura, il formato e le espressioni all'interno del modello rimangono invariati.
I modelli favoriscono la configurazione di distribuzioni complesse.
I modelli consentono di distribuire più risorse nell'ordine corretto. È ad esempio opportuno evitare di distribuire una macchina virtuale prima di creare un'interfaccia di rete o un disco del sistema operativo. Resource Manager esegue il mapping di ogni risorsa e delle relative risorse dipendenti e crea prima le risorse dipendenti. Il mapping delle dipendenze garantisce che la distribuzione venga eseguita nell'ordine corretto.
I modelli riducono le attività manuali, soggette a errori.
La creazione e la connessione manuali delle risorse possono richiedere molto tempo e sono più soggette al rischio di errori. Resource Manager garantisce che le distribuzioni vengano eseguite allo stesso modo ogni volta.
I modelli sono codice.
I modelli esprimono i requisiti tramite codice. Si pensi a un modello come un tipo di infrastruttura come codice che è possibile condividere, testare e modificare come qualsiasi altro componente software. Inoltre, poiché i modelli sono codice, è possibile creare una registrazione cartacea da seguire. Il codice del modello documenta la distribuzione. La maggior parte degli utenti gestisce i modelli con un certo tipo di controllo della versione, ad esempio Git. Quando si modifica il modello, la cronologia delle revisioni documenta anche il modo in cui il modello (e la distribuzione) si è evoluto nel tempo.
I modelli promuovono il riutilizzo.
Il modello può contenere parametri compilati in fase di esecuzione. Un parametro può definire un nome utente o una password, un nome di dominio e così via. I parametri del modello consentono di creare più versioni dell'infrastruttura, ad esempio gestione temporanea e produzione, usando comunque lo stesso identico modello.
I modelli sono collegabili.
È possibile collegare i modelli di Resource Manager tra loro per renderli automaticamente modulari. È possibile scrivere modelli di entità minore, ognuno dei quali definisce una parte di una soluzione, per poi combinarli e creare un sistema completo.
I modelli eseguiti dagli analisti finanziari sono univoci, ma si noteranno alcuni schemi nell'infrastruttura sottostante. La maggior parte dei modelli richiede ad esempio un database per archiviare i dati. Molti modelli usano gli stessi linguaggi di programmazione, framework e sistemi operativi per eseguire i dettagli. È possibile definire modelli che descrivono ogni singolo componente, ad esempio calcolo, archiviazione e rete. I componenti possono essere quindi combinati per soddisfare le esigenze specifiche di ogni analista.
Che cosa contiene un modello di Resource Manager?
Nota
Di seguito vengono illustrati alcuni esempi di codice per dare un'idea di come è strutturata ogni sezione. Non preoccuparsi se tutto ciò risulta poco familiare. È possibile esaminare i modelli degli altri e scrivere il proprio man mano che si acquisisce maggiore esperienza pratica.
È possibile che sia già stato usato JavaScript Object Notation (JSON) per inviare dati tra server e applicazioni Web. Anche JSON rappresenta un modo diffuso per descrivere la configurazione di applicazioni e infrastruttura.
JSON consente di esprimere i dati archiviati come un oggetto, ad esempio una macchina virtuale, in formato di testo. Un documento JSON è essenzialmente una raccolta di coppie chiave-valore. Ogni chiave è una stringa. Il valore della chiave può essere una stringa, un numero, un'espressione booleana, un elenco di valori o un oggetto, ovvero una raccolta di altre coppie chiave-valore.
Un modello di Resource Manager può contenere le sezioni seguenti:
{
"$schema": "http://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
"contentVersion": "",
"parameters": { },
"variables": { },
"functions": [ ],
"resources": [ ],
"outputs": { }
}
Anche se queste sezioni vengono espresse usando JSON, non sono correlate al linguaggio JSON effettivo. Ogni sezione verrà ora analizzata in modo più dettagliato.
Parametri
In questa sezione si specificano i valori configurabili quando viene eseguito il modello. È ad esempio possibile consentire agli utenti del modello di specificare un nome utente, una password o un nome di dominio.
Di seguito è riportato un esempio che illustra due parametri: uno per il nome utente di una macchina virtuale e uno per la relativa password.
"parameters": {
"adminUsername": {
"type": "string",
"metadata": {
"description": "Username for the Virtual Machine."
}
},
"adminPassword": {
"type": "securestring",
"metadata": {
"description": "Password for the Virtual Machine."
}
}
}
Variabili
In questa sezione si definiscono i valori usati in tutto il modello. Le variabili possono semplificare la gestione dei modelli. Si potrebbe ad esempio definire una volta un nome account di archiviazione come variabile e usare tale variabile in tutto il modello. Se il nome dell'account di archiviazione cambia, è sufficiente aggiornare la variabile.
Di seguito è riportato un esempio con alcune variabili che descrivono le funzionalità di rete per una macchina virtuale.
"variables": {
"nicName": "myVMNic",
"addressPrefix": "10.0.0.0/16",
"subnetName": "Subnet",
"subnetPrefix": "10.0.0.0/24",
"publicIPAddressName": "myPublicIP",
"virtualNetworkName": "MyVNET"
}
Funzioni
In questa sezione si definiscono le procedure che non si intende ripetere in tutto il modello. Come le variabili, le funzioni possono semplificare la gestione dei modelli. Di seguito è riportato un esempio che crea una funzione per creare un nome univoco che può essere usato quando si creano risorse con requisiti di denominazione univoci a livello globale.
"functions": [
{
"namespace": "contoso",
"members": {
"uniqueName": {
"parameters": [
{
"name": "namePrefix",
"type": "string"
}
],
"output": {
"type": "string",
"value": "[concat(toLower(parameters('namePrefix')), uniqueString(resourceGroup().id))]"
}
}
}
}
],
Risorse
In questa sezione si definiscono le risorse di Azure che costituiscono la distribuzione.
Di seguito è riportato un esempio che crea una risorsa di indirizzi IP pubblici.
{
"type": "Microsoft.Network/publicIPAddresses",
"name": "[variables('publicIPAddressName')]",
"location": "[parameters('location')]",
"apiVersion": "2018-08-01",
"properties": {
"publicIPAllocationMethod": "Dynamic",
"dnsSettings": {
"domainNameLabel": "[parameters('dnsLabelPrefix')]"
}
}
}
Qui il tipo di risorsa è Microsoft.Network/publicIPAddresses. Il nome viene letto dalla sezione delle variabili e la posizione (o area di Azure) viene letta dalla sezione dei parametri.
Poiché i tipi di risorse possono cambiare nel tempo, apiVersion fa riferimento alla versione del tipo di risorsa da usare. Nel momento in cui i tipi di risorse cambiano e si evolvono, è possibile modificare i modelli per renderli compatibili con le funzionalità più recenti.
Output
In questa sezione si definiscono eventuali informazioni da ricevere quando viene eseguito il modello. Si potrebbe ad esempio ricevere l'indirizzo IP o il valore FQDN della macchina virtuale, informazioni sconosciute fino all'esecuzione della distribuzione.
Nell'esempio seguente viene illustrato un output denominato hostname. Il valore FQDN viene letto dalle impostazioni dell'indirizzo IP pubblico della macchina virtuale.
"outputs": {
"hostname": {
"type": "string",
"value": "[reference(variables('publicIPAddressName')).dnsSettings.fqdn]"
}
}
Come si distribuisce un flusso di lavoro di App per la logica di Azure in un modello?
Un flusso di lavoro di App per la logica di Azure è una risorsa di Azure. Per distribuirlo in un modello è quindi possibile aggiungerlo all'elenco di risorse da distribuire nella sezione resources del modello di Resource Manager. Che cosa si deve aggiungere esattamente alla sezione resources per definire il flusso di lavoro? È necessario aggiungere la definizione JSON del flusso di lavoro. Il frammento di codice JSON seguente mostra infatti un modello di Resource Manager da usare per distribuire il flusso di lavoro di base descritto nell'unità precedente. Come indicato dall'evidenziazione, la sezione resources contiene la definizione completa del flusso di lavoro.
{
"$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {},
"variables": {},
"resources": [
{
"type": "Microsoft.Logic/workflows",
"apiVersion": "2017-07-01",
"name": "HelloLogicAppsTemplate",
"location": "westus2",
"properties": {
"state": "Enabled",
"definition": {
"$schema": "https://schema.management.azure.com/providers/Microsoft.Logic/schemas/2016-06-01/workflowdefinition.json#",
"contentVersion": "1.0.0.0",
"parameters": {},
"triggers": {
"manual": {
"type": "Request",
"kind": "Http",
"inputs": {
"method": "GET",
"schema": {}
}
}
},
"actions": {
"Response": {
"runAfter": {},
"type": "Response",
"kind": "Http",
"inputs": {
"body": "Hello Logic Apps Template!",
"statusCode": 200
}
}
},
"outputs": {}
},
"parameters": {}
}
}
],
"outputs": {
"logicAppUrl": {
"type": "string",
"value": "[listCallbackURL(concat(resourceId('Microsoft.Logic/workflows/', 'HelloLogicAppsTemplate'), '/triggers/manual'), '2017-07-01').value]"
}
}
}
Per distribuire questo modello è possibile usare uno dei metodi seguenti:
- Distribuire tramite il portale di Azure.
- Distribuire tramite il modulo
Azdi PowerShell. - Distribuire dall'interfaccia della riga di comando di Azure
In questo modulo si eseguirà la distribuzione di modelli tramite l'interfaccia della riga di comando di Azure e i comandi az deployment group.
Come scrivere un modello di Resource Manager?
Sono numerosi gli approcci alla scrittura di modelli di Resource Manager. Sebbene sia possibile scrivere un modello da zero, è più comune iniziare con un modello esistente e modificarlo in base alle esigenze.
Ecco alcuni modi per ottenere un modello di base:
- Usare il portale di Azure per creare un modello basato sulle risorse in un gruppo esistente.
- Iniziare con un modello creato dall'utente o dal team per uno scopo simile.
- Avviare un modello di Avvio rapido di Azure. Le informazioni su come fare si troveranno nell'unità successiva.
Indipendentemente dall'approccio scelto, la scrittura di un modello implica l'uso di un editor di testo. È possibile usare il proprio editor preferito, ma l'estensione strumenti di Azure Resource Manager di Visual Studio Code è progettata appositamente per la creazione di modelli. Questa estensione semplifica la navigazione nel codice del modello e garantisce il completamento automatico per molte attività comuni.
Durante l'esplorazione e la scrittura dei modelli, consultare la documentazione per comprendere i tipi di risorse disponibili e come usarli.
Nell'unità successiva si esaminerà e si distribuirà un modello esistente dall'interfaccia della riga di comando di Azure.