End-to-end-implementaties begrijpen

Voltooid

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 dergelijke situaties is het vaak verleidelijk om meerdere pijplijnen te maken, elk eigendom van het team dat verantwoordelijk is voor het specifieke gebied. U kunt bijvoorbeeld één pijplijn maken om de Bicep-code te implementeren die de Azure-resources van uw website implementeert en een andere pijplijn waarmee de websitetoepassing wordt geïmplementeerd.

Hoewel deze aanpak u misschien enige flexibiliteit biedt in de manier waarop u de pijplijnen beheert, 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 het bouwt. De implementatiepijplijn van de toepassing kan pas worden uitgevoerd als de infrastructuurimplementatiepijplijn 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 de onderdelen worden beheerd door verschillende personen of verschillende teams. U kunt hulpprogramma's zoals Git en Azure DevOps gebruiken om uw werk te coördineren. Wanneer er 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, waardoor de kans op synchronisatie wordt verminderd.

Tip

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

Als u deze positie hebt, kunt u overwegen om de implementatie van de infrastructuur 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 vlakken voor toegang. Het besturingsvlak implementeert en configureert de resource. Met het gegevensvlak hebt u toegang 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 met het besturingsvlak te communiceren. U moet bijvoorbeeld het volgende doen:

  • 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 bij een externe provider.

Wanneer u een end-to-end-pijplijn beschouwt, moet u gewoonlijk 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.

Notitie

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

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 ze kunnen communiceren met de Azure CLI en Azure PowerShell cmdlets. U maakt een beheerde identiteit voor het implementatiescript dat moet worden gebruikt voor verificatie bij Azure, en Azure richt automatisch de andere resources in die nodig zijn om het implementatiescript uit te voeren.

Implementatiescripts zijn handig wanneer u een eenvoudig script in uw implementatieproces moet uitvoeren. Ze bieden u echter niet eenvoudig toegang tot andere elementen uit uw pijplijn.

U kunt ook uw eigen logica uitvoeren vanuit een implementatiepijplijn. Azure Pipelines biedt een uitgebreid ecosysteem van taken voor veelvoorkomende 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 dit doet, 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 informatie krijgt. In deze module richten we ons op pijplijnscripts en -taken. We koppelen aan meer informatie over Resource Manager implementatiescripts op de pagina Samenvatting aan het einde van de module.

Uitvoerwaarden

Een pijplijn maakt en configureert gewoonlijk uw Azure-resources door een Bicep-bestand te implementeren. De volgende onderdelen van de pijplijn communiceren vervolgens met het gegevensvlak van deze resources. Om te kunnen communiceren met de resources, hebben de pijplijntaken en stappen informatie nodig over de Azure-resource die is 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 bevat. Latere stappen in de pijplijn kunnen de waarde van de uitvoer lezen. Op die manier hoeft uw pijplijndefinitie geen namen of andere gegevens die kunnen veranderen tussen omgevingen of op basis van regels die in uw Bicep-bestand zijn gedefinieerd, te coderen.

Met Azure Pipelines kunt u de waarden van uitvoer doorgeven met behulp van pijplijnvariabelen. U kunt de waarde van een pijplijnvariabele instellen binnen een pijplijnscript. U gebruikt een speciaal opgemaakte logboekuitvoer die Door Azure Pipelines wordt geïnterpreteerd, 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 opent die in een andere taak in dezelfde fase is gemaakt, moet u deze toewijzen om deze toegankelijk te maken voor de taak die deze leest:

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)

U hebt ook toegang tot een variabele in pijplijnfasen. U moet de variabele ook toewijzen, maar u gebruikt een iets 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)

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