Che cos'è l'infrastruttura come codice?

Completato

Viene chiesto di valutare se l'infrastruttura come codice potrebbe essere un approccio valido per il provisioning delle risorse nell'azienda. Si stanno esaminando le opzioni disponibili per la distribuzione, tra cui:

• Azure portal
• Interfaccia della riga di comando di Azure
• Azure PowerShell
• Modelli di Azure Resource Manager (JSON e Bicep)

Si sta cercando un'opzione ripetibile ed è necessario decidere quale tecnologia usare per distribuire l'infrastruttura di Azure.

In questa unità si apprende come e perché l'infrastruttura come codice può aiutare a distribuire l'infrastruttura di Azure in modo automatizzato e ripetibile.

I comandi dell'interfaccia della riga di comando di Azure vengono usati per illustrare i concetti. Vengono fornite altre informazioni sull'uso dei comandi per distribuire le risorse in altri moduli del percorso di apprendimento Bicep.

Definizione dell'infrastruttura come codice

L'azienda progetta nuovi giocattoli da lanciare sul mercato e la maggior parte di essi richiede alcune operazioni di montaggio. Il team di progettazione dell'azienda crea manuali di istruzioni da accludere a ogni giocattolo. Ogni manuale contiene informazioni dettagliate su come assemblare correttamente il giocattolo.

È possibile pensare all'infrastruttura come a codice come a un manuale di istruzioni per l'infrastruttura. Il manuale illustra in dettaglio la configurazione finale delle risorse e come raggiungere tale stato di configurazione.

L'infrastruttura come codice è il processo di automazione del provisioning dell'infrastruttura. Usa un linguaggio di programmazione descrittivo e un sistema di controllo delle versioni simile a quello usato per il codice sorgente. Quando si crea un'applicazione, il codice sorgente genera lo stesso risultato ogni volta che viene compilato. In modo analogo, le distribuzioni di tipo infrastruttura come codice sono automatizzate, coerenti e ripetibili. L'infrastruttura come codice può automatizzare le distribuzioni delle risorse dell'infrastruttura, ad esempio reti virtuali, macchine virtuali, applicazioni e archiviazione.

Tornando al manuale di istruzioni per il nuovo giocattolo, esistono diversi modi per scrivere il manuale di istruzioni. Un'opzione consiste nel descrivere nel dettaglio ogni passaggio del processo di compilazione. Un'altra opzione è visualizzare una vista esplosa dei componenti e delle parti necessarie per assemblare il giocattolo. Più avanti in questa unità vengono illustrate le differenze tra codice imperativo e codice dichiarativo e la loro correlazione con i manuali di istruzioni dell'azienda.

Perché usare l'infrastruttura come codice?

L'adozione di un approccio basato su infrastruttura come codice offre molti vantaggi al provisioning delle risorse. Con l'infrastruttura come codice, è possibile:

• Aumentare l'attendibilità delle distribuzioni.
• Gestire più ambienti.
• Comprendere meglio le risorse cloud.

Aumentare l'attendibilità

Uno dei vantaggi dell'uso dell'infrastruttura come codice è il livello di attendibilità delle distribuzioni derivante dai miglioramenti della coerenza e della sicurezza.

• Integrazione con i processi correnti: Se l'organizzazione usa già procedure standard per lo sviluppo di software, è possibile adottare gli stessi processi per le distribuzioni dell'infrastruttura. Ad esempio, le revisioni paritarie consentono di rilevare i problemi nelle configurazioni che potrebbero essere difficili da rilevare quando si apportano modifiche manuali.

• Coerenza: l'adozione di un approccio basato su infrastruttura come codice consente al team di seguire processi ben definiti per distribuire l'infrastruttura. Seguendo questi processi, la responsabilità passa da un piccolo gruppo di utenti al processo di automazione e agli strumenti. L'infrastruttura come codice consente di ridurre gli errori umani nel provisioning delle risorse e di garantire distribuzioni coerenti.

• Analisi automatizzata: È possibile analizzare le configurazioni dell'infrastruttura come codice con strumenti automatizzati in grado di verificare la presenza di errori nel codice. Gli strumenti automatizzati possono anche rivedere le modifiche proposte per garantire che vengano seguite le procedure relative alla sicurezza e alle prestazioni.

• Gestione dei segreti: molte soluzioni richiedono l'uso di segreti, ad esempio stringhe di connessione, chiavi di crittografia, segreti client e certificati. In Azure, Azure Key Vault è il servizio usato per archiviare in modo sicuro questi segreti. Molti strumenti di infrastruttura come codice possono integrarsi con Key Vault per accedere ai segreti in modo sicuro durante la distribuzione.

• Controllo di accesso: con le distribuzioni basate su infrastruttura come codice è possibile usare identità gestite o account del servizio per automatizzare il provisioning delle risorse. Questo processo garantisce che solo queste identità possano modificare le risorse cloud. Consente inoltre di evitare la distribuzione di configurazioni non corrette nell'ambiente di produzione. Se necessario, è possibile sostituire questo processo usando un account di accesso di emergenza, spesso denominato account break-glass, o usando la funzionalità Privileged Identity Management di Microsoft Entra ID.

• Evitare la deriva della configurazione: Idempotenza è un termine spesso associato all'infrastruttura come codice. Quando un'operazione è idempotente, significa che genera lo stesso risultato ogni volta che viene eseguita. Se si scelgono strumenti che utilizzano operazioni idempotenti, è possibile evitare la deriva della configurazione.

Come esempio di idempotenza, prendere in considerazione il comando dell'interfaccia della riga di comando di Azure seguente. Il comando seguente crea un gruppo di risorse di Azure denominato storage-resource-group nell'area Stati Uniti orientali.

az group create \
  --name storage-resource-group \
  --location eastus

Se si esegue questo comando una seconda volta, si ottiene esattamente lo stesso output perché questo comando dell'interfaccia della riga di comando di Azure è stato progettato per essere idempotente. Non viene visualizzato un errore o un gruppo di risorse duplicato.

Quando si usa l'infrastruttura come codice, è possibile ridistribuire l'ambiente in ogni versione della soluzione. Queste versioni possono incorporare piccole modifiche alla configurazione o anche aggiornamenti significativi. Questo processo consente di evitare la deriva della configurazione. Se viene apportata una modifica accidentale a una risorsa, è possibile correggerla ridistribuendo la configurazione. Seguendo questo approccio, si documenta l'ambiente usando il codice.

Gestire più ambienti

Molte organizzazioni gestiscono più ambienti di applicazioni. Gli sviluppatori dell'azienda di giocattoli possono avere più versioni del codice dell'applicazione in pronte in un repository per il rilascio in ambienti diversi. Gli ambienti possono essere, ad esempio, sviluppo, testing e produzione. Alcune organizzazioni gestiscono più ambienti di produzione per le applicazioni che vengono distribuite a livello globale. Altre organizzazioni, ad esempio i fornitori di software indipendenti (ISV), gestiscono ambienti multi-tenant per i propri clienti.

Ecco alcuni dei modi principali in cui l'infrastruttura come codice può aiutare a gestire gli ambienti:

• Provisioning dei nuovi ambienti: uno dei principali vantaggi del cloud computing è la possibilità di sfruttare la scalabilità. L'infrastruttura come codice può essere utile per ridimensionare usando più istanze dell'applicazione. Queste istanze possono essere utili durante i periodi di maggiore carico oppure è possibile distribuirle per gli utenti in altre aree del mondo. Questa agilità rappresenta un vantaggio anche quando si testa l'applicazione, ad esempio durante i test di penetrazione, i test di carico e i test di bug. Con una codebase ben definita, è possibile effettuare dinamicamente il provisioning dei nuovi ambienti in modo coerente.

• Ambienti non di produzione: Un problema comune che le organizzazioni devono affrontare è la differenziazione tra ambienti di produzione e ambienti non di produzione. Quando il provisioning delle risorse viene effettuato manualmente in ambienti separati, è possibile che le configurazioni finali non corrispondano. Ad esempio, quando si distribuisce una nuova funzionalità in un ambiente non di produzione che è diverso dall'ambiente di produzione. È possibile che la nuova funzionalità non funzioni come previsto nell'ambiente di produzione a causa delle differenze tra i due ambienti. L'uso dell'infrastruttura come codice consente di ridurre al minimo questi problemi. È possibile usare gli stessi file di configurazione per ogni ambiente, ma specificare parametri di input diversi per creare univocità.

• Ripristino di emergenza: in alcune situazioni l'infrastruttura come codice può essere usata come parte del piano di ripristino di emergenza di un'organizzazione. Ad esempio, potrebbe essere necessario creare nuovamente l'ambiente in un'altra area geografica a causa di un'interruzione del servizio. Usando l'infrastruttura come codice, è possibile effettuare rapidamente il provisioning di una nuova istanza in cui eseguire il failover anziché distribuire e riconfigurare manualmente tutti gli elementi.

Comprendere meglio le risorse cloud

L'infrastruttura come codice consente di comprendere meglio lo stato delle risorse cloud:

• Audit trail: le modifiche alle configurazioni basate su infrastruttura come codice sono incluse nel controllo della versione, come avviene per il codice sorgente dell'applicazione. Queste modifiche vengono rilevate negli strumenti, ad esempio con la cronologia delle versioni di Git. "Audit trail" significa che è possibile esaminare i dettagli di ogni modifica, verificando chi ha apportato la modifica e quando è stata apportata.

• Documentazione: è possibile usare molte configurazioni basate su infrastruttura come codice per aggiungere metadati, ad esempio i commenti, che descrivono lo scopo del codice nella configurazione. Se l'organizzazione segue già un processo di documentazione del codice, prendere in considerazione l'adozione di queste stesse procedure con il codice dell'infrastruttura.

• Sistema unificato: spesso, quando uno sviluppatore sta lavorando a una nuova funzionalità, deve apportare modifiche al codice dell'applicazione e al codice dell'infrastruttura. Usando un sistema comune, l'organizzazione può comprendere meglio la relazione tra le applicazioni e l'infrastruttura.

• Migliore comprensione dell'infrastruttura cloud: quando si usa il portale di Azure per effettuare il provisioning delle risorse, molti dei processi vengono astratti dalla visualizzazione. L'infrastruttura come codice consente di comprendere meglio il funzionamento di Azure e come risolvere i problemi che potrebbero verificarsi. Ad esempio, quando si crea una macchina virtuale usando il portale di Azure, alcune risorse create vengono astratte dalla visualizzazione. I dischi gestiti e le schede di interfaccia di rete vengono distribuiti dietro le quinte. Quando si distribuisce la stessa macchina virtuale usando l'infrastruttura come codice, si ha il controllo completo su tutte le risorse create.

Codice imperativo e codice dichiarativo

È possibile scrivere un manuale di istruzioni per il montaggio del nuovo giocattolo in modi diversi. Quando si automatizza la distribuzione dei servizi e dell'infrastruttura, si possono adottare due approcci: imperativo e dichiarativo.

• Con il codice imperativo si esegue una sequenza di comandi, in un ordine specifico, per ottenere una configurazione finale. Questo processo definisce le operazioni che il codice deve eseguire e come deve essere svolta l'attività. L'approccio imperativo è simile a un manuale di istruzioni passo-passo.

• Con il codice dichiarativo si specifica solo la configurazione finale. Il codice non definisce la modalità con cui si svolge l'attività. L'approccio dichiarativo è simile al manuale di istruzioni con la visualizzazione esplosa.

Quando si sceglie tra un approccio imperativo e un approccio dichiarativo al provisioning delle risorse, tenere in considerazione gli strumenti che potrebbero essere già in uso nell'organizzazione. Considerare anche quale approccio può essere più adatto alle proprie competenze.

Codice imperativo

In Azure un approccio con codice imperativo viene ottenuto a livello di programmazione usando un linguaggio di scripting, ad esempio Bash o Azure PowerShell. Gli script eseguono una serie di passaggi per creare, modificare e persino rimuovere le risorse.

Questo esempio illustra due comandi dell'interfaccia della riga di comando di Azure che creano un gruppo di risorse e un account di archiviazione.

#!/usr/bin/env bash
az group create \
  --name storage-resource-group \
  --location eastus

az storage account create \
  --name mystorageaccount \
  --resource-group storage-resource-group \
  --location eastus \
  --sku Standard_LRS \
  --kind StorageV2 \
  --access-tier Hot \
  --https-only true

Il primo comando crea un gruppo di risorse denominato storage-resource-group nell'area Stati Uniti orientali. Il secondo comando crea un account di archiviazione denominato mystorageaccount nel gruppo di risorse storage-resource-group creato nel primo comando. Il secondo comando configura anche un paio di proprietà per l'account di archiviazione, tra cui il tipo di account di archiviazione e il relativo livello di accesso.

È possibile usare un approccio imperativo per automatizzare completamente il provisioning delle risorse, ma l'approccio presenta alcuni svantaggi. Man mano che l'architettura matura, gli script possono diventare complessi da gestire. I comandi possono essere aggiornati o deprecati tramite le revisioni degli script esistenti.

Codice dichiarativo

In Azure un approccio con codice dichiarativo si ottiene usando i modelli. Sono disponibili molti tipi di modelli, tra cui:

• JSON
• Bicep
• Ansible, di RedHat
• Terraform, di HashiCorp

Nota

Questo modulo si concentra sull'uso dei modelli Bicep.

Esaminare l'esempio seguente di un modello Bicep che configura un account di archiviazione. La configurazione dell'account di archiviazione corrisponde all'esempio dell'interfaccia della riga di comando di Azure:

resource storageAccount 'Microsoft.Storage/storageAccounts@2203-05-01' = {
  name: 'mystorageaccount'
  location: 'eastus'
  sku: {
    name: 'Standard_LRS'
  }
  kind: 'StorageV2'
  properties: {
    accessTier: 'Hot'
    supportsHttpsTrafficOnly: true
  }
}

Nella sezione delle risorse è definita la configurazione dell'account di archiviazione. Questa sezione contiene il nome, la posizione e le proprietà dell'account di archiviazione, inclusi SKU e tipo di account.

Si potrebbe notare che il modello Bicep non specifica come si distribuisce l'account di archiviazione. Specifica solo l'aspetto che deve avere l'account di archiviazione. Sarà Azure a decidere quali passaggi eseguire dietro le quinte per creare questo account di archiviazione o per aggiornarlo in modo che corrisponda alla specifica.