Visualizzare in anteprima e approvare la distribuzione

Completato

Sono stati illustrati i processi del flusso di lavoro e come è possibile aggiungere un processo del flusso di lavoro per convalidare il codice Bicep. Il passaggio successivo per una distribuzione più attendibile consiste nell'aggiungere un altro processo per verificare esattamente quali elementi verranno modificati dalla distribuzione.

In questa unità verrà illustrato come usare il comando di simulazione in un flusso di lavoro. Verrà inoltre spiegato come aggiungere regole di protezione dell'ambiente in modo da poter verificare manualmente l'output del comando prima dell'esecuzione della distribuzione.

Operazione di simulazione

Un file Bicep descrive lo stato in cui si vuole che l'ambiente di Azure si trovi alla fine di una distribuzione. Quando si invia una distribuzione, Azure Resource Manager modifica l'ambiente di Azure affinché corrisponda allo stato descritto nel file Bicep.

Una distribuzione può comportare la distribuzione di nuove risorse nell'ambiente o l'aggiornamento di risorse esistenti. Quando si esegue una distribuzione in modalità completa, può anche comportare l'eliminazione delle risorse esistenti.

Ogni volta che le risorse vengono create, aggiornate o eliminate, esiste il rischio che l'ambiente cambi in modo imprevisto. È consigliabile aggiungere un passaggio aggiuntivo per verificare esattamente cosa verrà creato, aggiornato ed eliminato. Questa verifica aggiunge valore al processo di automazione. Quando si esegue la distribuzione in un ambiente di produzione, è importante verificare le modifiche apportate all'ambiente.

Resource Manager fornisce l'operazione di simulazione, che è possibile eseguire nel file Bicep all'interno del processo del flusso di lavoro:

L'azione arm-deploy supporta l'attivazione dell'operazione di simulazione usando la proprietà additionalArguments:

jobs:
  preview:
     runs-on: ubuntu-latest
     needs: [lint, validate]
     steps: 
     - uses: azure/login@v1
       name: Sign in to Azure
       with:
        client-id: ${{ secrets.AZURE_CLIENT_ID }}
        tenant-id: ${{ secrets.AZURE_TENANT_ID }}
        subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
     - uses: azure/arm-deploy@v1
       name: Run what-if
       with:
         failOnStdErr: false
         resourceGroupName: ${{ env.AZURE_RESOURCEGROUP_NAME }}
         template: deploy/main.bicep
         parameters: >
           environmentType=${{ env.ENVIRONMENT_TYPE }}
         additionalArguments: --what-if

Il codice evidenziato equivale a eseguire la distribuzione usando l'interfaccia della riga di comando di Azure, con l'argomento --what-if incluso.

L'operazione di simulazione non modifica in alcun modo l'ambiente. Descrive invece le risorse che verranno create, le proprietà delle risorse che verranno aggiornate e le risorse che verranno eliminate.

L'operazione di simulazione a volte mostra che una risorsa cambierà quando in realtà non verrà apportata alcuna modifica. Questo tipo di output viene chiamato rumore. Il team Microsoft è impegnato a limitare questi problemi, ma a questo scopo ha bisogno dell'aiuto degli utenti, Segnalare i problemi di simulazione.

Dopo aver visualizzato l'output dell'operazione di simulazione, è possibile determinare se procedere con la distribuzione. Questo passaggio comporta in genere una revisione umana dell'output del comando di simulazione per stabilire se le modifiche identificate sono ragionevoli. Se un revisore umano decide che le modifiche sono ragionevoli, è possibile approvare manualmente l'esecuzione del flusso di lavoro.

Per altre informazioni sul comando di simulazione, vedere il modulo di Microsoft Learn Visualizzare in anteprima le modifiche alla distribuzione di Azure con l'operazione di simulazione.

Ambienti

In GitHub Actions un ambiente rappresenta la posizione in cui viene distribuita la soluzione. Gli ambienti offrono funzionalità che consentono di gestire distribuzioni complesse. In un modulo futuro verranno illustrate altre informazioni sugli ambienti e sulle relative funzionalità. Per il momento, ci si concentra sulla possibilità di aggiungere i revisori necessari al flusso di lavoro.

Per creare un ambiente, usare l'interfaccia Web GitHub. È possibile creare ambienti quando si usa un repository GitHub pubblico o quando si usa un account GitHub Enterprise.

Dopo aver creato un ambiente, è possibile farvi riferimento in tutti i processi del flusso di lavoro:

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3
    - name: 'Lint Bicep template'
      run: az bicep build --file deploy/main.bicep

  validate:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3
    - uses: azure/login@v1
      with:
        client-id: ${{ secrets.AZURE_CLIENT_ID }}
        tenant-id: ${{ secrets.AZURE_TENANT_ID }}
        subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
    - uses: azure/arm-deploy@v1
      with:
        deploymentName: ${{ github.run_number }}
        resourceGroupName: ${{ env.AZURE_RESOURCEGROUP_NAME }}
        template: ./deploy/main.bicep
        parameters: environmentType=${{ env.ENVIRONMENT_TYPE }}
        deploymentMode: Validate

  deploy:
    runs-on: ubuntu-latest
    environment: MyAzureEnvironment
    needs: [lint, validate]
    steps:
    - uses: actions/checkout@v3
    - uses: azure/login@v1
      with:
        client-id: ${{ secrets.AZURE_CLIENT_ID }}
        tenant-id: ${{ secrets.AZURE_TENANT_ID }}
        subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
    - uses: azure/arm-deploy@v1
      with:
        deploymentName: ${{ github.run_number }}
        resourceGroupName: ${{ env.AZURE_RESOURCEGROUP_NAME }}
        template: ./deploy/main.bicep
        parameters: environmentType=${{ env.ENVIRONMENT_TYPE }}

Nota

Quando l'identità dei carichi di lavoro del flusso di lavoro di distribuzione interagisce con Resource Manager all'interno di un ambiente, sono necessarie credenziali federate configurate con il nome dell'ambiente. Gli ambienti verranno spiegati più in dettaglio in moduli futuri. Durante l'esecuzione degli esercizi relativi a questo modulo, si creeranno le credenziali federate necessarie.

Regole di protezione dell'ambiente

Dopo aver creato un ambiente, è possibile definire le regole di protezione. Le regole di protezione permettono di verificare le condizioni che devono essere soddisfatte prima che un passaggio possa usare l'ambiente. La regola di protezione revisori obbligatori è un tipo di controllo che richiede a un utente di fornire un'approvazione manuale.

Le regole di protezione vengono definite nell'ambiente, non nel flusso di lavoro. Gli autori del file YAML del flusso di lavoro non possono rimuovere o aggiungere queste regole di protezione. Solo gli amministratori di un repository o il proprietario dell'account possono gestire gli ambienti e le relative regole di protezione.

Le regole di protezione dell'ambiente consentono di garantire che nel processo di distribuzione siano coinvolte le persone appropriate.

Come funzionano le regole di protezione dell'ambiente?

Quando si associa un ambiente a un passaggio, le regole di protezione dell'ambiente vengono valutate subito prima dell'inizio del passaggio.

Un revisore obbligatorio è un tipo di regola di protezione. Quando si configura una regola di protezione revisore obbligatorio, si assegna uno o più utenti GitHub che devono approvare la continuazione del flusso di lavoro.

Gli ambienti forniscono anche altri tipi di regole di protezione. Ad esempio, è possibile limitare i rami Git che possono essere distribuiti in ambienti specifici. In questo modulo viene illustrata solo la regola revisori obbligatori, ma nel riepilogo vengono forniti collegamenti ad altre informazioni sulle altre regole di protezione.

Quando il flusso di lavoro inizia e raggiunge un passaggio che richiede un revisore, l'esecuzione del flusso di lavoro viene sospesa. A tutti gli utenti designati come revisori viene inviato un messaggio in GitHub e tramite posta elettronica.

I revisori possono esaminare i log del flusso di lavoro, ad esempio le modifiche rilevate dall'operazione di simulazione. In base a queste informazioni, approvano o rifiutano la modifica. Se approvano la modifica, il flusso di lavoro riprende. Se la rifiutano o se non rispondono entro il periodo di timeout, il processo ha esito negativo.

L'importanza delle procedure consigliate

La funzionalità degli ambienti in GitHub consentono di collegare le distribuzioni a un ambiente e quindi la distribuzione eredita le regole di protezione definite dall'amministratore dell'ambiente. Tuttavia, non sono previste regole che richiedano che i nuovi flussi di lavoro usino gli ambienti.

È importante che l'organizzazione stabilisca procedure consigliate per esaminare le definizioni dei flussi di lavoro. Ad esempio, configurare il repository in modo da richiedere revisioni delle richieste pull per tutte le modifiche apportate al ramo principale usando le regole di protezione del ramo. Questo concetto verrà spiegato più in dettaglio in un modulo futuro.

È anche possibile aggiungere segreti a un ambiente. In questo modo il segreto può essere usato solo in un processo che usa anche l'ambiente. Combinando le regole di protezione dell'ambiente e i segreti, è possibile garantire la sicurezza del flusso di lavoro.