Condividi tramite

Eseguire la distribuzione nell'infrastruttura di Azure con GitHub Actions

  • Articolo

In questa guida verrà illustrato come usare CI/CD e Infrastructure as Code (IaC) per la distribuzione in Azure con GitHub Actions in modo automatizzato e ripetibile.

Questo articolo offre una panoramica dell'architettura e presenta una soluzione strutturata per la progettazione di un'applicazione in Azure scalabile, sicura, resiliente e a disponibilità elevata. Per visualizzare esempi più reali di architetture cloud e idee sulle soluzioni, esplorare le architetture di Azure.

Vantaggi dell'uso di IaC e automazione per le distribuzioni

Esistono molti modi per eseguire la distribuzione in Azure, tra cui l'portale di Azure, l'interfaccia della riga di comando, l'API e altro ancora. Per questa guida si userà l'automazione IaC e CI/CD. I vantaggi di questo approccio includono:

  • Dichiarativo: quando si definisce l'infrastruttura e il processo di distribuzione nel codice, è possibile controllarne le versioni ed esaminarlo usando il ciclo di vita di sviluppo software standard. IaC consente anche di evitare eventuali deviazioni nella configurazione.

  • Coerenza: seguendo un processo IaC si garantisce che l'intera organizzazione segua un metodo standard e ben definito per distribuire l'infrastruttura che incorpora le procedure consigliate ed è avanzata per soddisfare le esigenze di sicurezza. Tutti i miglioramenti apportati ai modelli centrali possono essere applicati facilmente all'interno dell'organizzazione.

  • Sicurezza: i modelli gestiti centralmente possono essere rafforzati e approvati da un team operativo cloud o da un team di sicurezza per soddisfare gli standard interni.

  • Self-service: Teams può essere autorizzato a distribuire la propria infrastruttura usando modelli gestiti centralmente.

  • Produttività migliorata: usando i modelli standard, i team possono effettuare rapidamente il provisioning di nuovi ambienti senza doversi preoccupare di tutti i dettagli di implementazione.

Altre informazioni sono disponibili nell'infrastruttura ripetibile nel Centro architetture di Azure o nell'infrastruttura come codice nel Centro risorse DevOps.

Architettura

Architecture overview of using CI/CD to deploy Azure

Flusso di dati

  1. Creare un nuovo ramo e archiviare le modifiche del codice IaC necessarie.
  2. Creare una richiesta pull in GitHub dopo aver eseguito il merge delle modifiche nell'ambiente.
  3. Un flusso di lavoro di GitHub Actions verrà attivato per garantire che il codice sia formattato correttamente, coerente internamente e produci un'infrastruttura sicura. Inoltre, un piano Terraform o un'analisi di simulazione Bicep verrà eseguita per generare un'anteprima delle modifiche che verranno apportate nell'ambiente Azure.
  4. Una volta esaminata in modo appropriato, la richiesta pull può essere unita al ramo principale.
  5. Un altro flusso di lavoro di GitHub Actions verrà attivato dal ramo principale ed eseguirà le modifiche usando il provider IaC.
  6. (esclusivo per Terraform) Un flusso di lavoro GitHub Action pianificato regolarmente deve essere eseguito anche per cercare eventuali deviazioni di configurazione nell'ambiente e creare un nuovo problema se vengono rilevate modifiche.

Prerequisiti

Usare Bicep

  1. Creare ambienti GitHub

    I flussi di lavoro usano ambienti GitHub e segreti per archiviare le informazioni sull'identità di Azure e configurare un processo di approvazione per le distribuzioni. Creare un ambiente denominato production seguendo queste istruzioni. Nell'ambiente production configurare una regola di protezione e aggiungere tutti i responsabili approvazione necessari che devono firmare le distribuzioni di produzione. È anche possibile limitare l'ambiente al ramo principale. Le istruzioni dettagliate sono disponibili qui.

  2. Configurare l'identità di Azure:

    È necessaria un'applicazione Azure Active Directory con autorizzazioni per la distribuzione all'interno della sottoscrizione di Azure. Creare una singola applicazione e concedere le autorizzazioni di lettura/scrittura appropriate nella sottoscrizione di Azure. Configurare quindi le credenziali federate per consentire a GitHub di usare l'identità usando OpenID Connessione (OIDC). Per istruzioni dettagliate, vedere la documentazione di Azure. Sarà necessario aggiungere tre credenziali federate:

    • Impostare Tipo di entità su Environment e usare il nome dell'ambiente production .
    • Impostare Tipo di entità su Pull Request.
    • Impostare Tipo di entità su Branch e usare il nome del main ramo.

  3. Aggiungere segreti GitHub

    Nota

    Anche se nessuno dei dati sulle identità di Azure contiene segreti o credenziali, i segreti di GitHub vengono comunque utilizzati come un modo pratico per parametrizzare le informazioni sull'identità per ogni ambiente.

    Creare i segreti seguenti nel repository usando l'identità di Azure:

    • AZURE_CLIENT_ID : ID applicazione (client) della registrazione dell'app in Azure
    • AZURE_TENANT_ID : ID tenant di Azure Active Directory in cui è definita la registrazione dell'app.
    • AZURE_SUBSCRIPTION_ID : ID sottoscrizione in cui è definita la registrazione dell'app.

    Le istruzioni per aggiungere i segreti al repository sono disponibili qui.

Usare Terraform

  1. Configurare la posizione dello stato di Terraform

    Terraform usa un file di stato per archiviare informazioni sullo stato corrente dell'infrastruttura gestita e sulla configurazione associata. Questo file dovrà essere salvato in modo permanente tra diverse esecuzioni del flusso di lavoro. L'approccio consigliato consiste nell'archiviare questo file in un account Archiviazione di Azure o in un altro back-end remoto simile. In genere, il provisioning di questa risorsa di archiviazione viene eseguito manualmente o tramite un flusso di lavoro separato. Il blocco back-end Terraform dovrà essere aggiornato con il percorso di archiviazione selezionato (vedere qui per la documentazione).

  2. Creare un ambiente GitHub

    I flussi di lavoro usano ambienti GitHub e segreti per archiviare le informazioni sull'identità di Azure e configurare un processo di approvazione per le distribuzioni. Creare un ambiente denominato production seguendo queste istruzioni. Nell'ambiente production configurare una regola di protezione e aggiungere eventuali responsabili approvazione necessari che devono firmare le distribuzioni di produzione. È anche possibile limitare l'ambiente al ramo principale. Le istruzioni dettagliate sono disponibili qui.

  3. Configurare l'identità di Azure:

    È necessaria un'applicazione Azure Active Directory con autorizzazioni per la distribuzione all'interno della sottoscrizione di Azure. Creare un'applicazione separata per un account read-only e read/write e concedere loro le autorizzazioni appropriate nella sottoscrizione di Azure. Inoltre, entrambi i ruoli avranno bisogno di almeno Reader and Data Access autorizzazioni per l'account di archiviazione in cui risiede lo stato terraform del passaggio 1. Configurare quindi le credenziali federate per consentire a GitHub di usare l'identità usando OpenID Connessione (OIDC). Per istruzioni dettagliate, vedere la documentazione di Azure.

    Per l'identità read/write creare una credenziale federata come indicato di seguito:

    • Impostare su Entity TypeEnvironment e usare il nome dell'ambiente production .

    Per l'identità read-only creare due credenziali federate come indicato di seguito:

    • Impostare Entity Type su Pull Request.
    • Impostare su Entity TypeBranch e usare il nome del main ramo.

  4. Aggiungere segreti GitHub

    Nota

    Anche se nessuno dei dati sulle identità di Azure contiene segreti o credenziali, i segreti di GitHub vengono comunque utilizzati come un modo pratico per parametrizzare le informazioni sull'identità per ogni ambiente.

    Creare i segreti seguenti nel repository usando l'identità read-only :

    • AZURE_CLIENT_ID : ID applicazione (client) della registrazione dell'app in Azure
    • AZURE_TENANT_ID : ID tenant di Azure Active Directory in cui è definita la registrazione dell'app.
    • AZURE_SUBSCRIPTION_ID : ID sottoscrizione in cui è definita la registrazione dell'app.

    Le istruzioni per aggiungere i segreti al repository sono disponibili qui.

    Creare un altro segreto nell'ambiente production usando l'identità read-write :

    • AZURE_CLIENT_ID : ID applicazione (client) della registrazione dell'app in Azure

    Le istruzioni per aggiungere i segreti all'ambiente sono disponibili qui. Il segreto dell'ambiente eseguirà l'override del segreto del repository quando si esegue il passaggio di distribuzione nell'ambiente production quando sono necessarie autorizzazioni di lettura/scrittura elevate.

Eseguire la distribuzione con azioni di GitHub

Usare Bicep

Nell'architettura di riferimento sono inclusi due flussi di lavoro principali:

  1. Unit test bicep

    Questo flusso di lavoro viene eseguito su ogni commit ed è composto da un set di unit test nel codice dell'infrastruttura. Esegue la compilazione bicep per compilare il bicep in un modello di Resource Manager. Ciò garantisce che non siano presenti errori di formattazione. Esegue quindi una convalida per assicurarsi che il modello sia distribuibile. Infine, checkov, uno strumento di analisi del codice statico open source per IaC, verrà eseguito per rilevare i problemi di sicurezza e conformità. Se il repository usa GitHub Advanced Security (GHAS), i risultati verranno caricati in GitHub.

  2. Simulazione/distribuzione bicep

    Questo flusso di lavoro viene eseguito su ogni richiesta pull e su ogni commit nel ramo principale. La fase di simulazione del flusso di lavoro viene usata per comprendere l'impatto delle modifiche IaC nell'ambiente Di Azure eseguendo la simulazione. Questo report viene quindi collegato alla richiesta pull per una facile revisione. La fase di distribuzione viene eseguita dopo l'analisi di simulazione quando il flusso di lavoro viene attivato da un push nel ramo main. Questa fase distribuirà il modello in Azure dopo la firma di una revisione manuale.

Usare Terraform

Nell'architettura di riferimento sono inclusi tre flussi di lavoro principali:

  1. Unit test terraform

    Questo flusso di lavoro viene eseguito su ogni commit ed è composto da un set di unit test nel codice dell'infrastruttura. Esegue terraform fmt per assicurarsi che il codice sia correttamente linted e segua le procedure consigliate di terraform. Esegue quindi la convalida terraform per verificare che il codice sia sintatticamente corretto e coerente internamente. Infine, checkov, uno strumento di analisi del codice statico open source per IaC, verrà eseguito per rilevare i problemi di sicurezza e conformità. Se il repository usa GitHub Advanced Security (GHAS), i risultati verranno caricati in GitHub.

  2. Piano Terraform/Applica

    Questo flusso di lavoro viene eseguito su ogni richiesta pull e su ogni commit nel ramo principale. La fase del piano del flusso di lavoro viene usata per comprendere l'impatto delle modifiche IaC nell'ambiente Di Azure eseguendo il piano terraform. Questo report viene quindi collegato alla richiesta pull per una facile revisione. La fase di applicazione viene eseguita dopo il piano quando il flusso di lavoro viene attivato da un push nel ramo principale. Questa fase prenderà il documento di piano e applicherà le modifiche dopo la firma di una revisione manuale se sono presenti modifiche in sospeso all'ambiente.

  3. Rilevamento deriva terraform

    Questo flusso di lavoro viene eseguito periodicamente per analizzare l'ambiente per individuare eventuali deviazioni di configurazione o modifiche apportate all'esterno di Terraform. Se viene rilevata una deviazione, viene generato un problema di GitHub per avvisare i gestori del progetto.