Infrastruttura come codice

Articolo
05/23/2023

L'infrastruttura come codice (IaC) è una procedura devOps chiave che implica la gestione dell'infrastruttura, ad esempio reti, servizi di calcolo, database, archiviazioni e topologia di connessione, in un modello descrittivo. IaC consente ai team di sviluppare e rilasciare modifiche più velocemente e con maggiore attendibilità. I vantaggi di IaC includono:

Maggiore attendibilità nelle distribuzioni
Possibilità di gestire più ambienti
Miglioramento della comprensione dello stato dell'infrastruttura

Per altre informazioni sui vantaggi dell'uso dell'infrastruttura come codice, vedere Infrastruttura ripetibile.

Strumenti

Esistono due approcci che è possibile eseguire durante l'implementazione dell'infrastruttura come codice.

L'infrastruttura imperativa come codice prevede la scrittura di script in linguaggi come Bash o PowerShell. I comandi di stato che vengono eseguiti in modo esplicito per produrre un risultato desiderato. Quando si usano distribuzioni imperative, è possibile gestire la sequenza di dipendenze, il controllo degli errori e gli aggiornamenti delle risorse.
Infrastruttura dichiarativa come codice implica la scrittura di una definizione che definisce come si vuole che l'ambiente venga visualizzato. In questa definizione si specifica un risultato desiderato anziché il modo in cui si vuole che venga eseguita. Lo strumento consente di capire come eseguire il risultato controllando lo stato corrente, confrontandolo con lo stato di destinazione e quindi applicando le differenze.

Modelli di Azure Resource Manager

Esaminare le informazioni sui modelli di Azure Resource Manager (modelli di Resource Manager).

Bicep

Bicep è un linguaggio specifico di dominio (DSL) che usa la sintassi dichiarativa per distribuire le risorse di Azure. Nei file Bicep si definisce l'infrastruttura che si intende distribuire e le relative proprietà. Rispetto ai modelli di Resource Manager, i file Bicep sono più facili da leggere e scrivere per un pubblico non sviluppatore perché usano una sintassi concisa.

param location string = resourceGroup().location
param storageAccountName string = 'toylaunch${uniqueString(resourceGroup().id)}'
resource storageAccount 'Microsoft.Storage/storageAccounts@2021-06-01' = {
  name: storageAccountName
  location: location
  sku: {
    name: 'Standard_LRS'
  }
  kind: 'StorageV2'
  properties: {
    accessTier: 'Hot'
  }
}

Terraform

Esaminare le informazioni su Terraform.

Interfaccia della riga di comando di Azure

Esaminare le informazioni sull'interfaccia della riga di comando di Azure.

Infrastruttura come moduli di codice

Uno degli obiettivi dell'uso del codice per distribuire l'infrastruttura consiste nell'evitare la duplicazione del lavoro o la creazione di più modelli per gli stessi scopi o simili. I moduli di infrastruttura devono essere riutilizzabili e flessibili e devono avere uno scopo chiaro.

I moduli sono file indipendenti, in genere contenenti set di risorse da distribuire insieme. I moduli consentono di suddividere modelli complessi in set di codice più piccoli e gestibili. È possibile assicurarsi che ogni modulo sia incentrato su un'attività specifica e che tutti i moduli siano riutilizzabili per più distribuzioni e carichi di lavoro.

Moduli Bicep

Bicep consente di creare e chiamare moduli. Una volta creati i moduli, possono essere usati da qualsiasi altro modello Bicep. Un modulo Bicep di alta qualità deve definire più risorse correlate. Ad esempio, quando si definisce una funzione di Azure, si distribuisce in genere un'applicazione specifica, un piano di hosting per tale applicazione e un account di archiviazione per i metadati dell'applicazione. Questi componenti sono definiti separatamente, ma formano un raggruppamento logico delle risorse, quindi è consigliabile considerarli insieme come modulo.

I moduli Bicep usano comunemente:

Parametri da accettare valori da un modulo chiamante.
Valori di output per restituire i risultati a un modulo chiamante.
Risorse da definire uno o più oggetti infrastruttura per un modulo da gestire.

Pubblicare moduli Bicep

Sono disponibili diverse opzioni per la pubblicazione e la condivisione di moduli Bicep.

Registro di sistema pubblico: Il Registro moduli pubblici è ospitato in un registro contenitori Microsoft (MCR). Il codice sorgente e i moduli contenuti vengono archiviati in GitHub.
Registro privato: È possibile usare il Registro Azure Container per pubblicare moduli in un registro privato. Per informazioni sulla pubblicazione di moduli in un Registro di sistema in una pipeline CI/CD, vedere Bicep e GitHub Actions oppure, se si preferisce, Bicep e Azure Pipelines.
Specifica modello: È possibile usare le specifiche del modello per pubblicare moduli Bicep. Le specifiche dei modelli sono destinate a essere modelli completi, ma Bicep consente di usare le specifiche del modello per distribuire i moduli.
Sistema di controllo della versione: È possibile caricare i moduli direttamente dagli strumenti di controllo della versione, ad esempio GitHub o Azure DevOps.

Moduli Terraform

Terraform consente di creare e chiamare moduli. Ogni configurazione terraform ha almeno un modulo, noto come modulo radice, costituito da risorse definite nei .tf file nella directory di lavoro principale. Ogni modulo può chiamare altri moduli, che consente di includere moduli figlio nel file di configurazione principale. I moduli possono anche essere chiamati più volte all'interno della stessa configurazione o da configurazioni diverse.

I moduli vengono definiti con tutti gli stessi concetti relativi al linguaggio di configurazione. Usano più comunemente:

Variabili di input per accettare valori da un modulo chiamante.
Valori di output per restituire i risultati a un modulo chiamante.
Risorse da definire uno o più oggetti infrastruttura per un modulo da gestire.

Pubblicazione di moduli Terraform

Sono disponibili diverse opzioni per la pubblicazione e la condivisione di moduli Terraform:

Registro di sistema pubblico: HashiCorp ha un proprio Registro moduli Terraform che consente agli utenti di generare moduli Terraform condivisibili. Attualmente sono disponibili diversi moduli di Azure pubblicati nel Registro moduli Terraform.
Registro privato: È possibile pubblicare facilmente i moduli Terraform in un repository privato, ad esempio Terraform Cloud Private Registry o Registro Azure Container.
Sistema di controllo della versione: È possibile caricare moduli privati direttamente dagli strumenti di controllo della versione come GitHub. Per informazioni sulle origini supportate, vedere Origini del modulo Terraform.

Considerazioni relative alla progettazione

Prendere in considerazione l'uso di IaC durante la distribuzione delle risorse della zona di destinazione in Azure. IaC realizza completamente l'ottimizzazione della distribuzione, riduce lo sforzo di configurazione e automatizza le distribuzioni dell'intero ambiente.
Determinare se è necessario adottare un approccio IaC imperativo o dichiarativo.
- Se si prende un approccio imperativo, i comandi di stato esplicito da eseguire generano il risultato desiderato.
- Se si prende un approccio dichiarativo, specificare il risultato desiderato anziché il modo in cui si vuole farlo.
Prendere in considerazione gli ambiti di distribuzione. Avere una buona conoscenza dei livelli di gestione e della gerarchia di Azure. Ogni distribuzione IaC deve conoscere l'ambito in cui vengono distribuite le risorse di Azure.
Determinare se usare uno strumento IaC nativo di Azure o non nativo di Azure. Alcune informazioni da considerare:
- Gli strumenti nativi di Azure, ad esempio l'interfaccia della riga di comando di Azure, i modelli arm e Bicep sono completamente supportati da Microsoft, che consente di integrare più velocemente le nuove funzionalità.
- Gli strumenti non nativi come Terraform consentono di gestire l'infrastruttura come codice in più provider di cloud come AWS o GCP. Tuttavia, le nuove funzionalità di Azure possono richiedere tempo per essere incluse in non native. Se l'organizzazione è multicloud o l'organizzazione sta già usando e ben usata in Terraform, prendere in considerazione l'uso di Terraform per distribuire le zone di destinazione di Azure.
Poiché i moduli consentono di suddividere modelli complessi in set di codice più piccoli, è consigliabile usare i moduli IaC per le risorse comunemente distribuite insieme. È possibile assicurarsi che ogni modulo sia incentrato su un'attività specifica ed è riutilizzabile per più distribuzioni e carichi di lavoro.
Prendere in considerazione l'adozione di una strategia di pubblicazione per i moduli IaC scegliendo tra registri pubblici, registri privati o un sistema di controllo della versione come un repository Git.
È consigliabile usare una pipeline CI/CD per le distribuzioni IaC. Una pipeline applica il processo riutilizzabile impostato per garantire la qualità delle distribuzioni e dell'ambiente Azure.

Suggerimenti per la progettazione

Adottare un approccio IaC per distribuire, gestire, gestire e supportare le distribuzioni della zona di destinazione di Azure.
Usare gli strumenti nativi di Azure per IaC negli scenari seguenti:
- Si vuole usare solo gli strumenti nativi di Azure. L'organizzazione potrebbe avere un'esperienza di distribuzione del modello ARM o Bicep precedente.
- L'organizzazione vuole avere un supporto immediato per tutte le versioni di anteprima e disponibilità generale dei servizi di Azure.
Usare strumenti non nativi per IaC negli scenari seguenti:
- L'organizzazione attualmente usa Terraform per distribuire l'infrastruttura in altri cloud come AWS o GCP.
- L'organizzazione non deve disporre del supporto immediato per tutte le versioni di anteprima e disponibilità generale dei servizi di Azure.
Usare moduli IaC riutilizzabili per evitare operazioni ripetitive. È possibile condividere moduli nell'organizzazione per distribuire più progetti o carichi di lavoro e gestire codice meno complesso.
Pubblicare e usare moduli IaC dai registri pubblici negli scenari seguenti:
- Si desidera usare moduli per La zona di destinazione di Azure già pubblicata nei registri pubblici. Per altre informazioni, vedere Modulo Terraform zone di destinazione di Azure.
- Si desidera usare moduli gestiti, aggiornati e supportati da Microsoft, Terraform o altri provider di moduli.
  - Assicurarsi di controllare l'istruzione di supporto da qualsiasi provider di moduli valutata.
Pubblicare e usare moduli IaC da registri privati o sistemi di controllo della versione negli scenari seguenti:
- Si desidera creare moduli personalizzati in base ai requisiti dell'organizzazione.
- Si vuole avere il controllo completo di tutte le funzionalità e gestire, aggiornare e pubblicare nuove versioni di moduli.
Usare una pipeline CI/CD per distribuire elementi IaC e garantire la qualità della distribuzione e degli ambienti di Azure.

Share via