Testare le risorse dopo la distribuzione

6 minuti

Convalidando e visualizzando l'anteprima dell’implementazione di Bicep, sei stato in grado di dimostrare la capacità di implementare correttamente i file Bicep. Ma la distribuzione non è tutto. Al termine della distribuzione, è utile verificare anche che la distribuzione abbia eseguito le operazioni previste.

In questa unità verranno illustrati i test che è possibile eseguire al termine della distribuzione. Si otterranno anche informazioni sul rollback della distribuzione, se il risultato non corrisponde alle aspettative.

Eseguire smoke test e test negativi

Quando si definiscono le risorse in un file Bicep, l'obiettivo non consiste solo nel creare risorse in Azure. Si vuole anche offrire valore all'organizzazione, rispettando al tempo stesso i requisiti dell'organizzazione. Quando si convalida e si visualizza l'anteprima dei file Bicep, ci si assicura che le definizioni delle risorse siano valide. Tuttavia, non sappiamo con certezza se le risorse eseguiranno effettivamente le operazioni richieste.

Si immagini ad esempio di distribuire un nuovo server logico di Azure SQL usando un flusso di lavoro di distribuzione di Bicep. La definizione Bicep per il server è valida, quindi passa i processi di convalida linter e preliminari. Il comando what-if mostra che verrà creato un server, ovvero il comportamento previsto. La distribuzione termina correttamente. Alla fine del processo di distribuzione, tuttavia, potrebbe non essere ancora disponibile un server di database funzionante pronto per l'uso. Il problema può avere diverse cause, tra cui:

Non hai configurato regole del firewall per consentire al traffico di rete di raggiungere il server.
Hai abilitato l'autenticazione di Microsoft Entra nel server quando occorreva non abilitarla o viceversa.

Anche quando si distribuiscono semplicemente file Bicep di base, è consigliabile prendere in considerazione il modo in cui è possibile confermare che le risorse distribuite funzionano effettivamente e rispettano i requisiti specifici. Di seguito sono riportati alcuni esempi del modo in cui è possibile applicare questo principio:

Quando si distribuisce un sito Web, provare a raggiungere l'applicazione Web dal flusso di lavoro. Verificare che il flusso di lavoro si connetta correttamente al sito Web e riceva un codice di risposta valido.
Quando si distribuisce una rete di distribuzione del contenuto (rete CDN), provare a connettersi a una risorsa tramite la rete CDN. Verificare che il flusso di lavoro si connetta correttamente alla rete CDN e riceva un codice di risposta valido.

Questi test sono talvolta chiamati smoke test dell'infrastruttura. Gli smoke test sono un tipo semplice di test progettati per individuare problemi principali nella distribuzione.

Nota

Alcune risorse di Azure non sono facili da raggiungere dagli strumenti di esecuzione di GitHub ospitati. Potrebbe essere necessario prendere in considerazione l'uso di uno strumento di esecuzione self-hosted per eseguire processi degli smoke test, se richiedono l'accesso alle risorse tramite reti private.

È anche consigliabile eseguire test negativi. I test negativi consentono di verificare che le risorse non abbiano un comportamento indesiderato. Quando si distribuisce ad esempio una macchina virtuale, è consigliabile usare Azure Bastion per connettersi in modo sicuro alla macchina virtuale. È possibile aggiungere un test negativo al flusso di lavoro per verificare che non sia possibile connettersi direttamente a una macchina virtuale usando connessione Desktop remoto o SSH.

Importante

L'obiettivo di questi test non è verificare che Bicep abbia implementato correttamente le risorse. Usando Bicep, si presuppone che distribuirà le risorse specificate nei file Bicep. L'obiettivo consiste invece nel verificare che le risorse definite funzionino per la situazione specifica e soddisfino i requisiti.

Eseguire test da flussi di lavoro di GitHub

Esistono molti modi per eseguire test nel flusso di lavoro. In questo modulo viene usato Pester, uno strumento open source che esegue test scritti tramite PowerShell. Pester è preinstallato negli strumenti di esecuzione ospitati in GitHub. Non è necessario eseguire alcuna operazione speciale per usarlo in un passaggio di script.

È possibile scegliere di usare un framework di test diverso o anche scegliere di eseguire i test senza uno strumento di test. Un altro strumento di test da prendere in considerazione, ad esempio, è PSRule per Azure, che include regole e test predefiniti per Azure. Può eseguire la convalida nei modelli ed eseguire anche test sulle risorse di Azure distribuite. Nel riepilogo è disponibile un collegamento a PSRule.

Quando si eseguono test da un flusso di lavoro, eventuali errori di test devono impedire la continuazione del flusso di lavoro. Nell'esercizio successivo si vedrà come usare i flussi di lavoro con gli smoke test dell'infrastruttura.

I risultati dei test vengono scritti nel log del flusso di lavoro. GitHub Marketplace contiene anche operazioni di terze parti che possono visualizzare e tenere traccia dei risultati dei test nel tempo.

Passare i dati tra processi

Quando si divide il flusso di lavoro in più processi, ognuno con la propria responsabilità, è a volte necessario passare i dati tra questi processi. Un processo potrebbe ad esempio creare una risorsa di Azure che deve essere usata da un altro processo. Per poter passare i dati, il secondo processo deve conoscere il nome della risorsa creata. Ad esempio, il processo smoke test deve accedere alle risorse implementate dal processo di implementazione.

Il file Bicep distribuisce le risorse, in modo da poter accedere alle proprietà delle risorse e pubblicarle come output della distribuzione. Quando esegui la distribuzione Bicep tramite l'azione arm-deploy, questa azione archivierà gli output di implementazione Bicep negli output dei passaggi. Il processo che include l'azione arm-deploy potrà quindi pubblicare questi output dei passaggi come output del processo. Il processo fa riferimento alla proprietà del id passaggio, impostata su deploy:

deploy:
  runs-on: ubuntu-latest
  environment: Website
  needs: preview
  outputs:
    appServiceAppHostName: ${{ steps.deploy.outputs.appServiceAppHostName }}
  steps:
  - uses: actions/checkout@v3
  - 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
    id: deploy
    name: Deploy website
    with:
      deploymentName: ${{ github.run_number }}
      resourceGroupName: ${{ env.AZURE_RESOURCEGROUP_NAME }}
      template: ./deploy/main.bicep
      parameters: environmentType=${{ env.ENVIRONMENT_TYPE }}

È possibile accedere all'output di un processo in qualsiasi processo successivo, purché dipenda dal processo che produce l'output:

smoke-test:
  runs-on: ubuntu-latest
  needs: deploy
  steps:
  - uses: actions/checkout@v3
  - run: |
      $container = New-PesterContainer `
        -Path 'deploy/Website.Tests.ps1' `
        -Data @{ HostName = '${{needs.deploy.outputs.appServiceAppHostName}}' }
      Invoke-Pester `
        -Container $container `
        -CI
    name: Run smoke tests
    shell: pwsh

È anche possibile passare output da uno script del flusso di lavoro usando una sintassi speciale. Nel sommario è disponibile un collegamento ad altre informazioni.

Altri tipi di test

I test funzionali e i test di integrazione vengono spesso usati per confermare che le risorse implementate si comportino come previsto. Un test di integrazione potrebbe ad esempio connettersi al sito Web e inviare una transazione di test e quindi attendere la conferma del completamento corretto della transazione. Usando i test di integrazione, è possibile testare la soluzione compilata dal team insieme all'infrastruttura su cui è in esecuzione. In un modulo futuro si vedrà come è possibile aggiungere questi tipi di test al flusso di lavoro.

È anche possibile eseguire altri tipi di test da un flusso di lavoro di distribuzione, inclusi i test delle prestazioni e i test di penetrazione della sicurezza. Questi test non rientrano nell'ambito di questo modulo, ma possono aggiungere molto valore a un processo di distribuzione automatizzato.

Rollback o roll forward

Si supponga che il flusso di lavoro distribuisca correttamente le risorse, ma che i test abbiano esito negativo. Come si deve procedere?

In precedenza in questo modulo si è appreso che GitHub Actions consente di creare processi di rollback eseguiti quando un processo precedente ha esito negativo. È possibile usare questo approccio per creare un processo di rollback quando il processo di test segnala un risultato imprevisto. È anche possibile eseguire manualmente il rollback delle modifiche o eseguire nuovamente l'intero flusso di lavoro se ritieni che l'errore sia dovuto a un problema temporaneo che è stato risolto.

Nota

Quando invii un’implementazione ad Azure Resource Manager, puoi richiedere che Resource Manager riesegua automaticamente l'ultima implementazione corretta in caso di esito negativo. A questo scopo, usare il parametro --rollback-on-error quando si invia la distribuzione tramite il comando az deployment group create dell'interfaccia della riga di comando di Azure.

È ad esempio possibile aggiungere un processo di rollback al flusso di lavoro. Il processo di rollback viene eseguito quando il processo dello smoke test ha esito negativo:

rollback: 
  runs-on: ubuntu-latest
  needs: smoke-test
  if: ${{ always() && needs.smoke-test.result == 'failure' }}
  steps:
  - run: |
      echo "Performing rollback steps..."

Il processo dipende dal processo dello smoke test. Viene eseguito solo quando lo smoke test ha esito negativo. Per impostazione predefinita, GitHub Actions arresta il flusso di lavoro quando un processo precedente ha esito negativo. La condizione if include un controllo always() per eseguire l'override di questo comportamento. Senza always() nell'espressione, il processo di rollback verrà ignorato ogni volta che un processo precedente ha esito negativo.

Risulta spesso difficile definire i passaggi che devono essere eseguiti da un processo di rollback. Le distribuzioni Bicep sono generalmente complesse e non è facile eseguire il rollback delle modifiche. È particolarmente difficile eseguire il rollback quando la distribuzione include altri componenti.

Si supponga, ad esempio, che il flusso di lavoro distribuisca un file Bicep che definisce un database Azure SQL e quindi aggiunga alcuni dati al database. Quando viene eseguito il rollback della distribuzione, è necessario eliminare i dati? Anche il database deve essere rimosso? È difficile prevedere il modo in cui ogni errore e ogni rollback potrebbe influire sull'ambiente in esecuzione.

Per questo motivo, molte organizzazioni preferiscono eseguire il roll forward, ovvero correggere rapidamente il motivo dell'errore e quindi ripetere la distribuzione. Creando un processo di implementazione automatizzato di alta qualità e seguendo tutte le procedure consigliate apprese in questi percorsi di apprendimento, sarai in grado di risolvere rapidamente i problemi e implementare di nuovo i file Bicep, mantenendo al tempo stesso una qualità elevata.

Suggerimento

Uno dei principi di una mentalità DevOps consiste nell'imparare dagli errori. Se è necessario eseguire il rollback di un’implementazione, considera attentamente il motivo per cui si è verificato l'errore e aggiungi test automatizzati prima dell'avvio dell’implementazione per rilevare lo stesso problema, se si verifica in futuro.