Bicep-bestanden implementeren met behulp van een pijplijn

Voltooid

Nu u een basispijplijn hebt gemaakt, kunt u de pijplijn instellen om uw Bicep-bestanden te implementeren. In deze les leert u hoe u Bicep-code implementeert vanuit een pijplijn en hoe u de implementatiestappen instelt.

Notitie

De opdrachten in deze les worden weergegeven om concepten te illustreren. Voer de opdrachten nog niet uit. U oefent wat u hier binnenkort leert.

Serviceverbindingen

Wanneer u een Bicep-bestand implementeert vanaf uw eigen computer, gebruikt u de Azure CLI of Azure PowerShell. Voordat u uw code kunt implementeren, meldt u zich aan bij Azure. Meestal vragen de hulpprogramma's u om uw e-mailadres en wachtwoord in een browser in te voeren. Nadat uw referenties zijn geverifieerd, worden uw machtigingen voor het implementeren van resources bevestigd en kunt u de hulpprogramma's gebruiken om uw Bicep-bestand te implementeren.

Implementatie per pijplijn vereist ook verificatie. Omdat pijplijnen worden uitgevoerd zonder menselijke tussenkomst, verifiëren pijplijnen zich bij Azure met behulp van een service-principal. De referenties van een service-principal bestaan uit een toepassings-id en een geheim, meestal een sleutel of een certificaat. In Azure Pipelines gebruikt u een serviceverbinding om deze referenties veilig op te slaan, zodat uw pijplijn deze kan gebruiken. Een serviceverbinding bevat ook enkele andere informatie om uw pijplijn te helpen bij het identificeren van de Azure-omgeving waarin u wilt implementeren.

Tip

In deze module gebruikt u Azure DevOps om automatisch een service-principal te maken wanneer er een serviceverbinding wordt gemaakt. De module Uw Azure-implementatiepijplijn verifiëren met behulp van service-principals biedt een gedetailleerdere uitleg van service-principals, inclusief hoe ze werken, evenals hoe u ze maakt, rollen toewijst en beheert.

Wanneer u een serviceverbinding maakt, noemt u de verbinding. Stappen verwijzen naar de serviceverbinding met behulp van deze naam, zodat uw YAML-pijplijncode geen geheime informatie hoeft te bevatten.

Wanneer uw pijplijn wordt gestart, heeft de agent die uw implementatiestappen uitvoert toegang tot de serviceverbinding, inclusief de referenties. In een pijplijnstap worden de referenties gebruikt om u aan te melden bij Azure, net zoals u zich zelf aanmeldt. Vervolgens gebruiken de acties die in de stap zijn gedefinieerd de identiteit van de service-principal.

U moet ervoor zorgen dat uw service-principal over de machtigingen beschikt die nodig zijn om uw implementatiestappen uit te voeren. U moet bijvoorbeeld de rol Inzender voor de resourcegroep waaraan uw resources worden geïmplementeerd, toewijzen aan de service-principal.

Waarschuwing

Het lijkt misschien gemakkelijker om de referenties van uw service-principal op te slaan in uw YAML-bestand en meld u vervolgens aan met behulp van de az login opdracht. U moet deze methode nooit gebruiken om uw service-principal te verifiëren. Referenties in een YAML-bestand worden opgeslagen in duidelijke tekst. Iedereen die toegang heeft tot uw opslagplaats, kan de referenties bekijken en gebruiken. Zelfs als u de toegang tot uw Azure DevOps-organisatie en -project beperkt wanneer iemand uw opslagplaats kloont, bevindt het YAML-bestand met de referenties zich op de computer van die persoon. Het is belangrijk om een serviceverbinding te gebruiken wanneer u met Azure werkt vanuit een pijplijn. Serviceverbindingen bieden ook andere functies voor beveiliging en toegangsbeheer.

Serviceverbindingen worden gemaakt in uw Azure DevOps-project. Eén serviceverbinding kan worden gedeeld door meerdere pijplijnen. Het is echter meestal een goed idee om een serviceverbinding en de bijbehorende service-principal in te stellen voor elke pijplijn en elke omgeving waarnaar u implementeert. Deze procedure helpt de beveiliging van uw pijplijnen te verbeteren en vermindert de kans dat resources per ongeluk in een andere omgeving worden geïmplementeerd of geconfigureerd dan u verwacht.

U kunt ook uw serviceverbinding zo instellen dat deze alleen in specifieke pijplijnen kan worden gebruikt. Wanneer u bijvoorbeeld een serviceverbinding maakt die wordt geïmplementeerd in de productieomgeving van uw website, is het een goed idee om ervoor te zorgen dat alleen de pijplijn van uw website deze serviceverbinding kan gebruiken. Als u een serviceverbinding met specifieke pijplijnen beperkt, voorkomt u dat iemand anders per ongeluk dezelfde serviceverbinding voor een ander project gebruikt en uw productiewebsite mogelijk uitvalt.

Een Bicep-bestand implementeren met behulp van de azure-resourcegroepimplementatietaak

Wanneer u een Bicep-bestand vanuit een pijplijn wilt implementeren, kunt u de implementatietaak van de Azure-resourcegroep gebruiken. Hier volgt een voorbeeld van het configureren van een stap voor het gebruik van de taak:

- task: AzureResourceManagerTemplateDeployment@3
  inputs:
    connectedServiceName: 'MyServiceConnection'
    location: 'westus3'
    resourceGroupName: Example
    csmFile: deploy/main.bicep
    overrideParameters: >
        -parameterName parameterValue

De eerste regel geeft aan AzureResourceManagerTemplateDeployment@3. Azure Pipelines geeft aan dat de taak die u voor deze stap wilt gebruiken de naam AzureResourceManagerTemplateDeploymentheeft en u de versie 3 van de taak wilt gebruiken.

Wanneer u de azure-resourcegroepimplementatietaak gebruikt, geeft u invoer op om de taak te laten weten wat u moet doen. Hier volgen enkele invoer die u kunt opgeven wanneer u de taak gebruikt:

• connectedServiceName is de naam van de serviceverbinding die moet worden gebruikt.
• location moet worden opgegeven, ook al wordt de waarde mogelijk niet gebruikt. De azure-resourcegroepimplementatietaak kan ook een resourcegroep voor u maken en als dat het geval is, moet deze weten in welke Azure-regio de resourcegroep moet worden gemaakt. In deze module geeft u de location invoerwaarde op, maar de waarde wordt niet gebruikt.
• resourceGroupName hiermee geeft u de naam op van de resourcegroep waarnaar het Bicep-bestand moet worden geïmplementeerd.
• overrideParameters bevat parameterwaarden die u tijdens de implementatie wilt doorgeven aan uw Bicep-bestand.

Wanneer de taak wordt gestart, wordt de serviceverbinding gebruikt om u aan te melden bij Azure. Op het moment dat de taak de implementatie uitvoert die u hebt opgegeven, is de taak geverifieerd. U hoeft niet uit te voeren az login.

Azure CLI- en Azure PowerShell-opdrachten uitvoeren

Twee van de nuttigste ingebouwde taken in Azure Pipelines zijn de Azure CLI- en Azure PowerShell-taken. U kunt deze taken gebruiken om een of meer Azure CLI- of PowerShell-opdrachten uit te voeren.

In toekomstige Microsoft Learn-modules ziet u hoe u met de Azure CLI-opdracht meer onderdelen van uw implementatieproces vanuit een pijplijn kunt automatiseren.

Variabelen

Uw pijplijnen bevatten vaak waarden die u gescheiden wilt houden van uw YAML-bestand. Wanneer u bijvoorbeeld een Bicep-bestand implementeert in een resourcegroep, geeft u de naam van de resourcegroep op. De naam van de resourcegroep is waarschijnlijk anders wanneer u in verschillende omgevingen implementeert. Mogelijk moet u ook parameters opgeven voor uw Bicep-bestanden, inclusief geheimen, zoals wachtwoorden voor databaseservers. Sla deze waarden niet op in uw YAML-pijplijnbestand of ergens anders in uw Git-opslagplaats. Gebruik variabelen om de beveiliging te verbeteren en uw pijplijndefinities herbruikbaar te maken.

Een variabele maken

De webinterface van Azure Pipelines heeft een editor die u kunt gebruiken om variabelen voor uw pijplijn te maken:

U kunt een variabelewaarde voor Azure Pipelines instellen als geheim. Wanneer u een variabelewaarde instelt als geheim, kunt u de waarde niet weergeven nadat u deze hebt ingesteld. Azure Pipelines is ontworpen om geen geheime waarden in uw pijplijnlogboeken weer te geven.

Waarschuwing

Standaard verdoezelt Azure Pipelines geheime variabelewaarden in pijplijnlogboeken, maar u moet ook goede procedures volgen. Uw pijplijnstappen hebben toegang tot alle variabele waarden, inclusief geheimen. Als uw pijplijn een stap bevat waarmee een veilige variabele niet veilig wordt verwerkt, is het mogelijk dat de geheime variabele wordt weergegeven in de pijplijnlogboeken.

U kunt gebruikers een variabelewaarde laten overschrijven wanneer ze uw pijplijn handmatig uitvoeren. De waarde die een gebruiker opgeeft, wordt alleen gebruikt voor die specifieke pijplijnuitvoering. Variabele onderdrukkingen kunnen handig zijn wanneer u uw pijplijn test.

Een variabele gebruiken in uw pijplijn

Nadat u een variabele hebt gemaakt, gebruikt u een specifieke syntaxis om te verwijzen naar de variabele in het YAML-bestand van uw pijplijn:

- task: AzureResourceManagerTemplateDeployment@3
  inputs:
    connectedServiceName: $(ServiceConnectionName)
    location: $(DeploymentDefaultLocation)
    resourceGroupName: $(ResourceGroupName)
    csmFile: deploy/main.bicep
    overrideParameters: >
      -environmentType $(EnvironmentType)

De bestandsindeling van de pijplijndefinitie bevat een speciale $(VariableName) syntaxis. U kunt naar elke variabele verwijzen door deze methode te gebruiken, ongeacht of deze geheim is of niet.

Tip

In het voorgaande voorbeeld ziet u dat de naam van het Bicep-bestand niet is opgeslagen in een variabele. Net als Bicep-parameters hoeft u voor alles geen variabelen te maken. Het is een goed idee om variabelen te maken voor alles wat kan veranderen tussen omgevingen en voor alles wat geheim is. Omdat de pijplijn altijd hetzelfde sjabloonbestand gebruikt, hoeft u geen variabele voor het pad te maken.

Systeemvariabelen

Azure Pipelines maakt ook gebruik van systeemvariabelen. Systeemvariabelen bevatten vooraf gedefinieerde informatie die u mogelijk wilt gebruiken in uw pijplijn. Hier volgen enkele systeemvariabelen die u in uw pijplijn kunt gebruiken:

• Build.BuildNumber is de unieke id voor uw pijplijnuitvoering. Ondanks de naam is de Build.BuildNumber waarde vaak een tekenreeks en geen getal. U kunt deze variabele gebruiken om uw Azure-implementatie een naam te geven, zodat u de implementatie kunt bijhouden in de specifieke pijplijnuitvoering die deze heeft geactiveerd.
• Agent.BuildDirectory is het pad in het bestandssysteem van uw agentcomputer waarin de bestanden van de pijplijnuitvoering worden opgeslagen. Deze informatie kan handig zijn als u wilt verwijzen naar bestanden op de buildagent.

Variabelen maken in het YAML-bestand van uw pijplijn

Naast het gebruik van de Azure Pipelines-webinterface om variabelen te maken, kunt u variabelewaarden instellen in het YAML-bestand van uw pijplijn. U kunt deze optie gebruiken wanneer u waarden hebt die niet geheim zijn, wanneer de waarden in uw opslagplaats kunnen worden opgeslagen en wanneer u variabele waarden op één plaats in het bestand wilt bewaren, zodat u deze in de hele pijplijndefinitie kunt raadplegen. U kunt deze methode gebruiken om wijzigingen in de variabele in uw versiebeheersysteem bij te houden.

Als u een variabele wilt instellen in uw YAML-bestand, voegt u een variables sectie toe:

trigger: none

pool:
  vmImage: ubuntu-latest

variables:
  ServiceConnectionName: 'MyServiceConnection'
  EnvironmentType: 'Test'
  ResourceGroupName: 'MyResourceGroup'
  DeploymentDefaultLocation: 'westus3'

jobs:
- job:
  steps:
  - task: AzureResourceManagerTemplateDeployment@3
    inputs:
      connectedServiceName: $(ServiceConnectionName)
      location: $(DeploymentDefaultLocation)
      resourceGroupName: $(ResourceGroupName)
      csmFile: deploy/main.bicep
      overrideParameters: >
        -environmentType $(EnvironmentType)

In dit pijplijnvoorbeeld worden vier variabelen gedefinieerd: ServiceConnectionName, EnvironmentType, ResourceGroupNameen DeploymentDefaultLocation.

Verderop in deze module ziet u hoe u variabelen kunt combineren die zijn gedefinieerd op verschillende plaatsen in één pijplijn.