Esercizio - Creare ambienti temporanei per le richieste pull

Completato

Alcuni membri del team hanno detto di apprezzare il feedback linter automatico di Bicep sulle modifiche al codice prima di inviarle ad altri membri del team per la verifica. A questo punto, si è deciso di fornire ai collaboratori e ai revisori la possibilità di distribuire e rivedere il codice in un ambiente temporaneo.

In questo esercizio si aggiornerà il flusso di lavoro della richiesta pull per distribuire un ambiente temporaneo ogni volta che viene aperta una richiesta pull e ridistribuirlo quando viene eseguito il push del codice nel ramo della richiesta pull. Si creerà anche un altro flusso di lavoro per eliminare automaticamente l'ambiente quando la richiesta pull viene chiusa. Si testeranno le modifiche creando una richiesta pull in modo che il sito Web usi un'immagine del contenitore Docker.

Durante il processo, si eseguiranno queste operazioni:

  • Aggiornare il flusso di lavoro della richiesta pull per distribuire un ambiente temporaneo.
  • Creare un flusso di lavoro di eliminazione della richiesta pull per eliminare l'ambiente temporaneo.
  • Creare una richiesta pull e controllare l'ambiente temporaneo che viene creato.
  • Approvare la richiesta pull e controllare l'ambiente temporaneo che viene eliminato.

Aggiornare il flusso di lavoro della richiesta pull per distribuire un ambiente temporaneo

Per iniziare, è necessario aggiornare il flusso di lavoro pr-validation per creare un ambiente temporaneo.

  1. Nel terminale Visual Studio Code estrarre il ramo principale del repository.

    git checkout main
    
  2. Eseguire il pull dell'ultima versione del codice da GitHub, che include le modifiche unite in un esercizio precedente.

    git pull
    
  3. Aprire il file .github/workflow/pr-validation.yml in Visual Studio Code.

  4. Nella parte superiore del file, sotto l'impostazione name, aggiungere un'impostazione concurrency:

    name: pr-validation
    concurrency: ${{ github.event.number }}
    

    Questa impostazione impedisce a più flussi di lavoro per la stessa richiesta pull di essere eseguiti contemporaneamente, perché potrebbero verificarsi risultati imprevedibili quando si distribuiscono risorse in Azure.

  5. Nella parte superiore del file, nella sezione on che definisce il trigger definire la sezione permissions:

    name: pr-validation
    concurrency: ${{ github.event.number }}
    
    on: pull_request
    
    permissions:
      id-token: write
      contents: read
    
  6. Sotto la sezione permissions aggiungere due nuove variabili di ambiente:

    name: pr-validation
    concurrency: ${{ github.event.number }}
    
    on: pull_request
    
    permissions:
      id-token: write
      contents: read
    
    env:
      resourceGroupName: pr_${{ github.event.number }}
      resourceGroupLocation: westus3
    

    La variabile di ambiente resourceGroupName specifica il nome del gruppo di risorse che deve essere usato per ogni ambiente temporaneo. Ogni gruppo di risorse verrà denominato pr_123, dove 123 è il numero di richiesta pull univoco.

    La variabile di ambiente resourceGroupLocation specifica che gli ambienti temporanei devono essere distribuiti nell'area Stati Uniti occidentali 3 di Azure.

  7. Definire un nuovo processo denominato deploy, sotto il processo lint:

    jobs:
      lint:
        uses: ./.github/workflows/lint.yml
    
      deploy:
        runs-on: ubuntu-latest
        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 }}
    

    Il processo estrae prima tutto il codice nello strumento di esecuzione GitHub e quindi accede all'ambiente di Azure.

    Suggerimento

    I file YAML sono sensibili al rientro. Se si digita o si incolla questo codice, assicurarsi che il rientro sia corretto. Più avanti in questo esercizio verrà visualizzata la definizione completa del flusso di lavoro YAML in modo da verificare la corrispondenza del file.

  8. Aggiungere un passaggio per creare il gruppo di risorse con il nome definito nella variabile di ambiente:

    - uses: Azure/cli@v1
      name: Create resource group
      with:
        inlineScript: |
          az group create \
            --name ${{ env.resourceGroupName }} \
            --location ${{ env.resourceGroupLocation }}
    
  9. Dopo il passaggio di creazione del gruppo di risorse, aggiungere un passaggio per distribuire il file Bicep nel gruppo di risorse:

    - uses: azure/arm-deploy@v1
      id: deploy
      name: Deploy Bicep file
      with:
        failOnStdErr: false
        deploymentName: ${{ github.run_number }}
        resourceGroupName: ${{ env.resourceGroupName }}
        template: ./deploy/main.bicep
        parameters: >
          environmentType=Test
    
  10. Dopo il passaggio di distribuzione, aggiungere un passaggio per visualizzare l'indirizzo del sito Web dell'ambiente temporaneo nel log del flusso di lavoro:

    - name: Show website hostname
      run: |
        echo "Access the website at this address: https://${{ steps.deploy.outputs.appServiceAppHostName }}"
    
  11. Salvare le modifiche.

  12. Verificare che il file pr-validation.yml sia simile al seguente:

    name: pr-validation
    concurrency: ${{ github.event.number }}
    
    on: pull_request
    
    permissions:
      id-token: write
      contents: read
    
    env:
      resourceGroupName: pr_${{ github.event.number }}
      resourceGroupLocation: westus3
    
    jobs:
      lint:
        uses: ./.github/workflows/lint.yml
    
      deploy:
        runs-on: ubuntu-latest
        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/cli@v1
            name: Create resource group
            with:
              inlineScript: |
                az group create \
                  --name ${{ env.resourceGroupName }} \
                  --location ${{ env.resourceGroupLocation }}
          - uses: azure/arm-deploy@v1
            id: deploy
            name: Deploy Bicep file
            with:
              failOnStdErr: false
              deploymentName: ${{ github.run_number }}
              resourceGroupName: ${{ env.resourceGroupName }}
              template: ./deploy/main.bicep
              parameters: >
                environmentType=Test
          - name: Show website hostname
            run: |
              echo "Access the website at this address: https://${{ steps.deploy.outputs.appServiceAppHostName }}"
    

    In caso contrario, aggiornarlo in modo che corrisponda a questo esempio e salvarlo.

  13. Nel terminale di Visual Studio Code eseguire il commit delle modifiche. Non verrà ancora eseguito il push nel repository remoto.

    git add .
    git commit -m "Update pull request validation workflow to deploy an ephemeral environment"
    

Aggiungere un flusso di lavoro di eliminazione della richiesta pull

È stato creato un flusso di lavoro che distribuisce automaticamente le modifiche in ogni richiesta pull a un gruppo di risorse temporaneo. A questo punto, si configurerà un secondo flusso di lavoro per eliminare gli ambienti temporanei quando non sono più necessari.

  1. Creare un nuovo file denominato pr-closed.yml nella cartella .github/workflow.

    Screenshot of Visual Studio Code that shows the P R closed dot Y M L file within the workflows folder.

  2. Nella parte superiore del file assegnare un nome al flusso di lavoro, configurare la stessa chiave di concorrenza usata nel flusso di lavoro di convalida della richiesta pull, configurare il flusso di lavoro in modo che venga eseguito ogni volta che viene chiusa una richiesta pull e consentire al flusso di lavoro di ottenere un token di accesso:

    name: pr-closed
    concurrency: ${{ github.event.number }}
    
    on:
      pull_request:
        types: [closed]
    
    permissions:
      id-token: write
      contents: read
    
  3. Sotto il codice appena immesso, definire una variabile di ambiente per il nome del gruppo di risorse associato all'ambiente temporaneo della richiesta pull:

    env:
      resourceGroupName: pr_${{ github.event.number }}
    

    Il nome del gruppo di risorse è uguale a quello usato per il flusso di lavoro di convalida della richiesta pull.

  4. Sotto il codice aggiunto definire un nuovo processo denominato remove e configurarlo per l'accesso a Azure:

    jobs:
      remove:
        runs-on: ubuntu-latest
        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 }}
    
  5. All'interno del processo remove definire un passaggio per eliminare il gruppo di risorse usando l'interfaccia della riga di comando di Azure e confermare l'eliminazione usando l'argomento --yes:

    - uses: Azure/cli@v1
      name: Delete resource group
      with:
        inlineScript: |
          az group delete \
            --name ${{ env.resourceGroupName }} \
            --yes
    
  6. Salvare le modifiche.

  7. Verificare che il file pr-closed.yml sia simile al seguente:

    name: pr-closed
    concurrency: ${{ github.event.number }}
    
    on:
      pull_request:
        types: [closed]
    
    permissions:
      id-token: write
      contents: read
    
    env:
      resourceGroupName: pr_${{ github.event.number }}
    
    jobs:
      remove:
        runs-on: ubuntu-latest
        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/cli@v1
            name: Delete resource group
            with:
              inlineScript: |
                az group delete \
                  --name ${{ env.resourceGroupName }} \
                  --yes
    

    In caso contrario, aggiornarlo in modo che corrisponda a questo esempio e salvarlo.

  8. Nel terminale di Visual Studio Code eseguire il commit e il push delle modifiche al repository remoto:

    git add .
    git commit -m 'Add pull request closed workflow'
    git push
    

Aggiornare il file Bicep

Aggiornare quindi il file Bicep in modo che usi un'immagine del contenitore Docker per l'applicazione del sito Web.

  1. Nel terminale Visual Studio Code creare un nuovo ramo per le modifiche eseguendo il comando seguente:

    git checkout -b feature/container-app
    
  2. Aprire il file main.bicep nella cartella deploy.

  3. Aggiornare il valore della variabile appServiceAppLinuxFrameworkVersion:

    var appServiceAppLinuxFrameworkVersion = 'DOCKER|dockersamples/static-site:latest'
    
  4. Salvare le modifiche.

  5. Eseguire il commit e il push delle modifiche nel repository Git eseguendo i comandi seguenti nel terminale di Visual Studio Code:

    git add .
    git commit -m "Use container image for website"
    git push origin feature/container-app
    

Crea una richiesta pull

I flussi di lavoro sono stati definiti per creare e gestire automaticamente gli ambienti temporanei nelle richieste pull. A questo punto, si creerà un'altra richiesta pull per le modifiche Bicep.

  1. Nel browser selezionare Codice e quindi 3 branches (3 rami).

    Screenshot of GitHub that shows the repository's branch list.

  2. In Your branches (I tuoi rami) accanto a feature/container-app selezionare Nuova richiesta pull.

    Screenshot of GitHub that shows the link to create a pull request for the feature slash container app branch.

  3. Selezionare Crea richiesta pull.

Controllare l'ambiente temporaneo che viene creato

  1. Nella pagina dei dettagli della richiesta pull attendere che vengano visualizzati gli elementi di controllo dello stato.

  2. Nell'elenco accanto al processo deploy selezionare Dettagli.

    Screenshot of the GitHub pull request that shows the status check items. The 'Details' link for the 'deploy' job is highlighted.

    Attendere il completamento della distribuzione.

  3. Selezionare Show website hostname (Mostra nome host del sito Web).

  4. Selezionare l'URL nel log.

    Screenshot of the GitHub Actions deployment log. The website URL in the Show website hostname step is highlighted.

    Il sito Web carica e visualizza un messaggio Hello Docker!, che indica che il sito Web è in esecuzione dall'immagine del contenitore definita nella modifica della richiesta pull.

    Screenshot of the website homepage after the deployment is complete.

  5. Facoltativamente, aprire il portale di Azure e passare al gruppo di risorse dell'ambiente temporaneo.

    Esaminare le risorse distribuite: account di archiviazione, servizio app e piano di servizio app.

Unire la richiesta pull

Dopo aver testato la richiesta pull, è possibile unirla nel ramo principale.

  1. Selezionare Richieste pull e la richiesta pull Use container image for website (Usa l'immagine del contenitore per il sito Web).

    Screenshot of GitHub showing the list of open pull requests in the repository.

    I controlli dello stato sono stati superati.

    Screenshot of the GitHub pull request showing that the two status checks have passed.

  2. Selezionare Merge pull request (Unisci la richiesta pull).

  3. Selezionare Confirm merge.

Esaminare l'eliminazione del gruppo di risorse

  1. Nel browser selezionare Azioni e quindi, nel riquadro sinistro, selezionare il flusso di lavoro pr-closed.

    È possibile notare che il flusso di lavoro è stato richiamato automaticamente perché è stata chiusa una richiesta pull.

    Screenshot of the GitHub Actions pane showing that the P R closed workflow is running.

  2. Selezionare il flusso di lavoro per esaminare il log.

    L'eliminazione del gruppo di risorse in Azure da parte del flusso di lavoro potrebbe richiedere alcuni minuti.

    Importante

    Non è necessario attendere il completamento dell'esecuzione del flusso di lavoro. Tuttavia, assicurarsi di aprire il portale di Azure in un secondo momento, sia per verificare che il gruppo di risorse dell'ambiente temporaneo sia stato eliminato correttamente sia per evitare di sostenere i costi per le risorse di Azure.

Pulire le risorse

Al termine del modulo, è possibile eliminare le risorse create:

  • Segreti GitHub

    1. Dal repository GitHub passare a Impostazioni>Segreti e variabili>Azioni.
    2. Selezionare Rimuovi segreto per ogni segreto del repository e seguire le istruzioni.
  • repository di GitHub

    1. Passare a Impostazioni>Generale
    2. Selezionare Elimina questo repository e seguire le istruzioni.
  • Credenziali federate ed entità servizio per le registrazioni delle app Azure.

    1. Nella home page del portale cercare Azure Active Directory e selezionarlo dall'elenco dei servizi.
    2. Passare a Gestisci>Registrazioni app.
    3. In Applicazioni di proprietà selezionare toy-website-auto-review.
    4. Selezionare Elimina e seguire le istruzioni.
    5. Selezionare Applicazioni eliminate per eliminare definitivamente la registrazione dell'app.

    Importante

    È possibile che la registrazione dell'app e i nomi dell’entità servizio siano duplicati. È consigliabile verificare l'ID dell'applicazione per assicurarsi che si stia eliminando la risorsa corretta.