Uw implementatie bekijken en goedkeuren

  • 5 minuten

U hebt nu geleerd over werkstroomtaken en hoe u een werkstroomtaak kunt toevoegen om uw Bicep-code te valideren. De volgende stap bij het opbouwen van vertrouwen met uw implementatie is het toevoegen van een andere taak om precies te controleren wat uw implementatie zal veranderen.

In deze les leert u hoe u de wat-als-opdracht in een werkstroom gebruikt. U leert ook hoe u omgevingsbeveiligingsregels toevoegt, zodat u de mogelijkheid hebt om de uitvoer van de opdracht handmatig te controleren voordat de implementatie wordt uitgevoerd.

De wat-als-bewerking

Een Bicep-bestand beschrijft de status waarin u wilt dat uw Azure-omgeving zich aan het einde van een implementatie bevindt. Wanneer u een implementatie verzendt, wijzigt Azure Resource Manager uw Azure-omgeving zodat deze overeenkomt met de status die wordt beschreven in uw Bicep-bestand.

Een implementatie kan ertoe leiden dat nieuwe resources worden geïmplementeerd in uw omgeving of dat bestaande resources worden bijgewerkt. Wanneer u een implementatie uitvoert in de volledige modus, kan dit zelfs leiden tot het verwijderen van bestaande resources.

Wanneer resources worden gemaakt, bijgewerkt of verwijderd, bestaat het risico dat dingen kunnen veranderen op een manier die u niet had verwacht. Het is een goed idee om een extra stap toe te voegen om te controleren wat er precies wordt gemaakt, bijgewerkt en verwijderd. Deze verificatie voegt waarde toe aan uw automatiseringsproces. Wanneer u implementeert in een productieomgeving, is het belangrijk dat u eventuele wijzigingen in uw omgeving bevestigt.

Resource Manager biedt de wat-als-bewerking, die u kunt uitvoeren op uw Bicep-bestand in uw werkstroomtaak:

Diagram van een werkstroom met lint-, validatie- en preview-taken. De preview-taak voert een wat-als-bewerking uit op Azure.

De arm-deploy actie ondersteunt het activeren van de wat-als-bewerking met behulp van de additionalArguments eigenschap:

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

De gemarkeerde code is gelijk aan het uitvoeren van de implementatie met behulp van Azure CLI, waarbij het --what-if argument is opgenomen.

Met de wat-als-bewerking worden geen wijzigingen aangebracht in uw omgeving. In plaats daarvan worden de resources beschreven die worden gemaakt, de resource-eigenschappen die worden bijgewerkt en de resources die worden verwijderd.

Wat-als laat soms zien dat een resource wordt gewijzigd wanneer er daadwerkelijk geen wijziging plaatsvindt. Dit type uitvoer wordt ruis genoemd. We proberen deze problemen te verminderen, maar we hebben uw hulp nodig. Wat-als-problemen melden.

Nadat u de uitvoer van de wat-als-bewerking hebt weergegeven, kunt u bepalen of u door wilt gaan naar de implementatie. Deze stap omvat doorgaans een mens die de uitvoer van de wat-als-opdracht controleert en vervolgens een beslissing neemt over of de geïdentificeerde wijzigingen redelijk zijn. Als een menselijke revisor besluit dat de wijzigingen redelijk zijn, kunnen ze de werkstroomuitvoering handmatig goedkeuren.

Voor meer informatie over de wat-als-opdracht raadpleegt u de microsoft Learn-module Preview van Azure-implementatiewijzigingen met behulp van wat-als.

Omgevingen

In GitHub Actions vertegenwoordigt een omgeving de plaats waar uw oplossing wordt geïmplementeerd. Omgevingen bieden functies die u helpen bij het werken met complexe implementaties. In een toekomstige module leert u meer over omgevingen en hun functies. Voorlopig richten we ons op de mogelijkheid om vereiste revisoren toe te voegen aan uw werkstroom.

U maakt een omgeving met behulp van de GitHub-webinterface. U kunt omgevingen maken wanneer u met een openbare GitHub-opslagplaats werkt of wanneer u een GitHub Enterprise-account gebruikt.

Nadat u een omgeving hebt gemaakt, kunt u ernaar verwijzen in alle taken in uw werkstroom:

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 }}

Notitie

Wanneer de workloadidentiteit van uw implementatiewerkstroom communiceert met Resource Manager in een omgeving, heeft deze een federatieve referentie nodig die is geconfigureerd met de naam van de omgeving. In toekomstige modules leert u meer over omgevingen. Wanneer u de oefeningen voor deze module uitvoert, maakt u de benodigde federatieve referenties.

Omgevingsbeveiligingsregels

Nadat u een omgeving hebt gemaakt, kunt u beveiligingsregels definiëren. Beveiligingsregels worden gebruikt om te controleren of aan voorwaarden moet worden voldaan voordat een stap de omgeving kan gebruiken. De vereiste beveiligingsregel voor revisoren is een type controle waarvoor een mens een handmatige goedkeuring vereist.

Beveiligingsregels worden gedefinieerd in de omgeving, niet in de werkstroom. Auteurs van het YAML-bestand van de werkstroom kunnen deze beveiligingsregels niet verwijderen of toevoegen. Alleen de beheerders van een opslagplaats of de accounteigenaar kunnen omgevingen en hun beveiligingsregels beheren.

Omgevingsbeveiligingsregels helpen ervoor te zorgen dat de juiste personen betrokken zijn bij het implementatieproces.

Hoe werken omgevingsbeveiligingsregels?

Wanneer u een omgeving koppelt aan een stap, worden de beveiligingsregels van de omgeving geëvalueerd net voordat de stap begint.

Een vereiste revisor is één type beveiligingsregel. Wanneer u een vereiste revisorbeveiligingsregel configureert, wijst u een of meer GitHub-gebruikers toe die de voortzetting van uw werkstroom moeten goedkeuren.

Omgevingen bieden ook andere soorten beveiligingsregels. U kunt bijvoorbeeld de Git-vertakkingen beperken die kunnen worden geïmplementeerd in specifieke omgevingen. We bespreken alleen de vereiste revisorenregel in deze module, maar we bieden koppelingen naar meer informatie over andere beveiligingsregels in de samenvatting.

Nadat uw werkstroom is gestart en een stap heeft bereikt waarvoor een revisor is vereist, wordt de werkstroomuitvoering onderbroken. Alle gebruikers die zijn aangewezen als revisoren, ontvangen een bericht in GitHub en per e-mail.

Revisoren kunnen de werkstroomlogboeken inspecteren, zoals de wijzigingen die door de wat-als-bewerking worden gedetecteerd. Op basis van deze informatie worden de wijzigingen vervolgens goedgekeurd of geweigerd. Als ze de wijziging goedkeuren, wordt de werkstroom hervat. Als ze weigeren of als ze niet reageren binnen de time-outperiode, mislukt de taak.

Diagram van een werkstroom met lint-, validatie-, preview- en implementatietaken, met een goedkeuringscontrole vóór de implementatietaak.

Het belang van goede praktijken

De omgevingsfunctie in GitHub biedt u de mogelijkheid om uw implementaties te koppelen aan een omgeving en vervolgens neemt de implementatie de beveiligingsregels over die zijn gedefinieerd door de beheerder van de omgeving. Er is echter niets om te vereisen dat nieuwe werkstromen omgevingen gebruiken.

Het is belangrijk dat een organisatie goede procedures tot stand brengt om uw werkstroomdefinities te controleren. Configureer uw opslagplaats bijvoorbeeld om pull-aanvraagbeoordelingen te vereisen voor wijzigingen in uw hoofdbranch met behulp van vertakkingsbeveiligingsregels. In een toekomstige module leert u meer over dit concept.

U kunt ook geheimen toevoegen aan een omgeving. Op die manier kan het geheim alleen worden gebruikt in een taak die ook gebruikmaakt van de omgeving. Door omgevingsbeveiligingsregels en -geheimen te combineren, kunt u ervoor zorgen dat uw werkstroombeveiliging behouden blijft.