Condividi tramite

Eseguire la distribuzione nell'infrastruttura di Azure con GitHub Actions

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 il 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: I team possono essere autorizzati a implementare la propria infrastruttura utilizzando 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.

Architecture

Panoramica dell'architettura dell'uso di CI/CD per distribuire Azure

Flusso di dati

  1. Creare un nuovo ramo e archiviare le modifiche del codice IaC necessarie.
  2. Creare una Pull Request (PR) in GitHub una volta pronti per effettuare il merge delle modifiche nel vostro 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 what-if di Bicep verrà eseguita per generare un'anteprima delle modifiche che verranno apportate nel tuo ambiente Azure.
  4. Una volta esaminata in modo appropriato, la pull request può essere integrata nel 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 dell'approvazione necessari che devono approvare le distribuzioni in produzione. Puoi anche 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 Connect (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

    Annotazioni

    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.

Utilizza 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 di 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 configura una regola di protezione e aggiungi gli approvatori desiderati che devono approvare i rilasci in produzione. Puoi anche 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 di Terraform del passaggio 1. Configurare quindi le credenziali federate per consentire a GitHub di usare l'identità usando OpenID Connect (OIDC). Per istruzioni dettagliate, vedere la documentazione di Azure .

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

    • Impostare Entity Type a Environment e utilizzare il nome del ambiente production.

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

    • Impostare Entity Type su Pull Request.
    • Configurare Entity Type a Branch e utilizzare il nome del ramo main.

  4. Aggiungere segreti GitHub

    Annotazioni

    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 dell'applicazione (client) della registrazione dell'applicazione 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 sovrascriverà il segreto del repository durante la fase di distribuzione nell'ambiente production quando sono necessarie autorizzazioni elevate di lettura/scrittura.

Distribuire con GitHub Actions

Usare Bicep

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

  1. Unit test di bicep

    Questo flusso di lavoro viene eseguito su ogni commit ed è composto da un set di unit test nel codice dell'infrastruttura. Esegue bicep build per trasformare il bicep in un modello ARM. 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. Bicep What-If/Deploy

    Questo flusso di lavoro viene attivato per ogni pull request e per ogni commit nel ramo principale. La fase di what-if del flusso di lavoro viene usata per comprendere l'impatto delle modifiche IaC nell'ambiente di Azure eseguendo what-if. Questo report viene quindi allegato al pull request per una facile revisione. La fase di distribuzione si svolge dopo l'analisi ipotetica quando il flusso di lavoro viene attivato da un push sul ramo principale. Questa fase applicherà il modello in Azure dopo l'approvazione di una revisione manuale.

Utilizza 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 passato al lint e segua le migliori pratiche 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 attivato per ogni pull request e per ogni commit nel ramo principale. La fase di pianificazione del flusso di lavoro viene usata per comprendere l'impatto delle modifiche IaC nell'ambiente di Azure eseguendo terraform plan. Questo report viene quindi allegato al pull request 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 di deriva di 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.

  • Last updated on