End-to-end-implementaties begrijpen

  • 5 minuten

Pijplijnen zijn flexibele hulpprogramma's die u op veel verschillende manieren kunt configureren om aan uw behoeften te voldoen. In deze les leert u hoe u pijplijnen gebruikt om een volledige oplossing te implementeren, waaronder het configureren van de Azure-infrastructuur en het uitvoeren van andere implementatiebewerkingen.

Hoeveel pijplijnen?

In sommige organisaties verschilt het team dat de Azure-omgeving beheert, van het team dat de code ontwikkelt die in de omgeving wordt uitgevoerd. In deze situaties is het vaak verleidelijk om meerdere pijplijnen te maken, die elk eigendom zijn van het team dat verantwoordelijk is voor het specifieke gebied. U kunt bijvoorbeeld één pijplijn maken om de Bicep-code te implementeren waarmee de Azure-resources van uw website worden geïmplementeerd en een andere pijplijn waarmee de websitetoepassing wordt geïmplementeerd.

Hoewel deze benadering u mogelijk enige flexibiliteit biedt bij het beheren van de pijplijnen, kan het lastig zijn om alles gesynchroniseerd te houden. Stel dat uw websiteteam een nieuwe instelling nodig heeft voor de Azure-app Service-app om een functie in te schakelen die door het team wordt gebouwd. De implementatiepijplijn van de toepassing kan pas worden uitgevoerd als de implementatiepijplijn voor de infrastructuur is voltooid. Het kan ook ingewikkeld worden om gegevens te verzenden, zoals de namen van Azure-resources die zijn gemaakt door uw infrastructuurpijplijn, tussen de pijplijnen.

In plaats daarvan is het vaak beter om één pijplijn te maken waarmee alles wordt geïmplementeerd dat nodig is voor uw oplossing, zelfs als verschillende personen of verschillende teams de onderdelen beheren. U kunt hulpprogramma's zoals Git en Azure DevOps gebruiken om uw werk te coördineren. Wanneer een nieuwe functie wordt toegevoegd, kunt u een vertakking gebruiken om de benodigde wijzigingen aan te brengen in uw Bicep-bestand. En wanneer de wijziging gereed is om te worden geïntegreerd en vrijgegeven, voert één pijplijn alle stappen uit die nodig zijn om de oplossing te bouwen en te implementeren. Eén pijplijn vermindert de kans dat dingen worden gesynchroniseerd.

Tip

Wanneer u code voor uw oplossing bouwt, moet u deze waarschijnlijk regelmatig implementeren, zodat u kunt testen hoe deze werkt. Het kan zijn dat het implementeren van uw infrastructuur samen met uw toepassingscode ervoor zorgt dat uw pijplijn langzaam wordt uitgevoerd en uw voortgang remt.

Als u op deze positie bent, kunt u overwegen om de infrastructuurimplementatie voor uw ontwikkelomgeving uit te schakelen. U kunt padfilters, pijplijnsjablonen en voorwaarden gebruiken om dit te bereiken. U moet echter de volledige implementatievolgorde intact laten voor uw andere omgevingen.

Het besturingsvlak en het gegevensvlak

Veel Azure-resources bieden twee verschillende lagen voor toegang. Het besturingsvlak implementeert en configureert de resource. Met het gegevensvlak kunt u toegang krijgen tot de functionaliteit van de resource.

Wanneer u Bicep-bestanden maakt en implementeert, communiceert u met het besturingsvlak. In Azure is het besturingsvlak Azure Resource Manager. U gebruikt Resource Manager om de configuratie van elk van uw resources te definiëren.

Maar uw pijplijn moet vaak meer doen dan alleen het besturingsvlak te gebruiken. U moet bijvoorbeeld andere taken uitvoeren:

  • Upload een blob naar een opslagaccount.
  • Een databaseschema wijzigen.
  • Maak een API-aanroep naar een service van derden.
  • Activeer de update van een machine learning-model.
  • Een website implementeren in een Azure-app Service-app.
  • Software implementeren op een virtuele machine.
  • Registreer een DNS-vermelding (Domain Name Server) bij een externe provider.

Wanneer u een end-to-end-pijplijn beschouwt, moet u normaal gesproken uw Azure-resources implementeren en vervolgens een reeks bewerkingen uitvoeren op de gegevensvlakken van deze resources. Soms worden deze bewerkingen de laatste mijl van de implementatie genoemd, omdat u het grootste deel van de implementatie uitvoert met behulp van het besturingsvlak en slechts een kleine hoeveelheid configuratie blijft bestaan.

Notitie

Sommige resources hebben geen duidelijke verdeling tussen het besturingsvlak en het gegevensvlak. Deze omvatten Azure Data Factory en Azure API Management. Beide services ondersteunen volledig geautomatiseerde implementaties met bicep, maar hiervoor zijn speciale overwegingen vereist. Aan het einde van de module vindt u koppelingen naar meer informatie op de overzichtspagina.

Gegevensvlakbewerkingen uitvoeren

Wanneer u een implementatiepijplijn maakt die communiceert met het gegevensvlak van uw resources, kunt u een van de volgende drie algemene benaderingen gebruiken:

  • Resource Manager-implementatiescripts.
  • Pijplijnscripts.
  • Pijplijntaken.

Resource Manager-implementatiescripts worden gedefinieerd in uw Bicep-bestand. Ze voeren Bash- of PowerShell-scripts uit en kunnen communiceren met Azure CLI- of Azure PowerShell-cmdlets. U maakt een beheerde identiteit, zodat het implementatiescript kan worden geverifieerd bij Azure en azure automatisch de andere resources in richt en beheert die nodig zijn om het implementatiescript uit te voeren.

Implementatiescripts zijn handig wanneer u een basisscript moet uitvoeren binnen uw implementatieproces. Ze bieden u echter niet eenvoudig toegang tot andere elementen vanuit uw pijplijn.

U kunt ook uw eigen logica uitvoeren vanuit een implementatiepijplijn. Azure Pipelines biedt een uitgebreid ecosysteem van taken voor algemene dingen die u moet doen. Als u geen taak kunt vinden die aan uw behoeften voldoet, kunt u een script gebruiken om uw eigen Bash- of PowerShell-code uit te voeren. Pijplijntaken en scripts worden uitgevoerd vanuit de agent van uw pijplijn. U moet de taak of het script vaak verifiëren bij het gegevensvlak van de service die u gebruikt, en de manier waarop u zich verifieert, is afhankelijk van de service.

Pijplijntaken en -scripts bieden u flexibiliteit en controle. Ze stellen u ook in staat om toegang te krijgen tot pijplijnartefacten, waarover u binnenkort meer te weten komt. In deze module richten we ons op pijplijnscripts en -taken. Aan het einde van de module vindt u een koppeling naar meer informatie over Resource Manager-implementatiescripts op de overzichtspagina.

Uitvoerwaarden

Een pijplijn maakt en configureert doorgaans uw Azure-resources door een Bicep-bestand te implementeren. De volgende onderdelen van de pijplijn communiceren vervolgens met het gegevensvlak van deze resources. Voor interactie met de resources hebben de pijplijntaken en stappen informatie nodig over de Azure-resource die u hebt gemaakt.

Stel dat u een Bicep-bestand hebt waarmee een opslagaccount wordt geïmplementeerd. U wilt dat uw pijplijn het opslagaccount implementeert en vervolgens enkele blobs uploadt naar een blobcontainer in het opslagaccount. De pijplijntaak waarmee de blobs worden geüpload, moet de naam van het opslagaccount kennen waarmee verbinding moet worden gemaakt en de naam van de blobcontainer waarnaar het bestand moet worden geüpload.

Het is raadzaam om het Bicep-bestand te laten beslissen over de namen van uw Azure-resources. Het kan parameters, variabelen of expressies gebruiken om de namen voor het opslagaccount en de blobcontainer te maken. Het Bicep-bestand kan vervolgens een uitvoer weergeven die de naam van elke resource levert. Latere stappen in de pijplijn kunnen de waarde van de uitvoer lezen. Op die manier hoeft uw pijplijndefinitie geen namen of andere informatie vast te leggen die tussen omgevingen kan veranderen. De definitie hoeft ook niet te zijn gebaseerd op regels die zijn gedefinieerd in uw Bicep-bestand.

Met Azure Pipelines kunt u de waarden van uitvoer doorgeven met behulp van pijplijnvariabelen. U kunt de waarde van een pijplijnvariabele instellen in een pijplijnscript. U gebruikt een speciaal opgemaakte logboekuitvoer die Azure Pipelines begrijpt hoe u deze interpreteert, zoals hier wordt weergegeven:

stages:
- stage: Stage1
  jobs:
  - job: Job1
    steps:
      # Set the variable's value.
      - script: |
          echo "##vso[task.setvariable variable=myVariableName;isOutput=true]VariableValue"
        name: Step1

      # Read the variable's value.
      - script:
          echo $(myVariableName)

Wanneer u een variabele in de ene taak maakt, maar deze in dezelfde fase wilt openen in een andere taak, moet u deze toewijzen .

stages:
- stage: Stage2
  jobs:
  - job: Job2
    steps:
      # Set the variable's value.
      - script: |
          echo "##vso[task.setvariable variable=myVariableName;isOutput=true]VariableValue"
        name: Step1

  - job: Job3
    dependsOn: Job2
    variables: # Map the variable to this job.
      myVariableName: $[ dependencies.Job2.outputs['Step1.myVariableName'] ]
    steps:
      # Read the variable's value.
      - script: |
          echo $(myVariableName)

Voor toegang tot een variabele in pijplijnfasen moet u ook de variabele toewijzen , maar u gebruikt een andere syntaxis:

stages:
- stage: Stage2
  jobs:
  - job: Job2
    steps:
      # Set the variable's value.
      - script: |
          echo "##vso[task.setvariable variable=myVariableName;isOutput=true]VariableValue"
        name: Step1

  - job: Job3
    dependsOn: Job2
    variables: # Map the variable to this job.
      myVariableName: $[ dependencies.Job2.outputs['Step1.myVariableName'] ]
    steps:
      # Read the variable's value.
      - script: |
          echo $(myVariableName)

- stage: Stage3
  dependsOn: Stage2
  jobs:
  - job: Job4
    variables: # Map the variable to this stage.
      myVariableName: $[ stageDependencies.Stage2.Job2.outputs['Step1.myVariableName'] ]
    steps:
      # Read the variable's value.
    - script: |
        echo $(myVariableName)

Met bicep-uitvoer en pijplijnvariabelen kunt u een pijplijn met meerdere fasen maken waarmee uw Bicep-code wordt geïmplementeerd en vervolgens verschillende acties op de resources worden uitgevoerd als onderdeel van uw implementatie.