Om komplette udrulninger

Fuldført

Pipelines er fleksible værktøjer, som du kan konfigurere på mange forskellige måder, så de passer til dine behov. I dette undermodul lærer du, hvordan du bruger pipelines til at udrulle en hel løsning, herunder konfiguration af Azure-infrastrukturen, og hvordan du udfører andre udrulningshandlinger.

Hvor mange pipelines?

I nogle organisationer er det team, der administrerer Azure-miljøet, forskelligt fra det team, der udvikler den kode, der kører i miljøet. I disse situationer er det ofte fristende at oprette flere pipelines, der hver især ejes af det team, der er ansvarlig for det pågældende område. Du kan f.eks. oprette én pipeline for at udrulle den Bicep-kode, der udruller dit websteds Azure-ressourcer, og en anden pipeline, der installerer webstedsprogrammet.

Selvom denne fremgangsmåde kan give dig en vis fleksibilitet i den måde, du administrerer pipelines på, kan det være en udfordring at holde alt synkroniseret. Lad os f.eks. antage, at dit webstedsteam har brug for en ny indstilling i appen Azure App Service for at aktivere en funktion, som det bygger. Programinstallationspipelinen kan ikke køre, før infrastrukturinstallationspipelinen er fuldført. Det kan også blive kompliceret at sende data, f.eks. navnene på Azure-ressourcer, der er oprettet af din infrastrukturpipeline, mellem pipelinerne.

I stedet er det ofte bedre at oprette en enkelt pipeline, der udruller alt, hvad der kræves til din løsning, selvom forskellige personer eller forskellige teams administrerer komponenterne. Du kan bruge værktøjer som Git og Azure DevOps til at koordinere dit arbejde. Når der tilføjes en ny funktion, kan du bruge en forgrening til at foretage de nødvendige ændringer af din Bicep-fil. Og når ændringen er klar til at blive integreret og udgivet, udfører en enkelt pipeline alle de trin, der er nødvendige for at bygge og installere løsningen. En enkelt pipeline reducerer risikoen for, at tingene ikke synkroniseres.

Drikkepenge

Når du bygger kode til din løsning, skal du sandsynligvis udrulle den ofte, så du kan teste, hvordan den fungerer. Du kan opleve, at udrulningen af infrastrukturen sammen med programkoden får pipelinen til at køre langsomt og hæmmer dine fremskridt.

Hvis du er i denne position, kan du overveje at deaktivere udrulningen af infrastrukturen for dit udviklingsmiljø. Du kan bruge stifiltre, pipelineskabeloner og betingelser til at opnå dette. Du bør dog lade hele udrulningssekvensen være intakt for dine andre miljøer.

Kontrolflade og dataflade

Mange Azure-ressourcer leverer to forskellige fly, du kan få adgang til. Det kontrolplan udruller og konfigurerer ressourcen. Det dataplan giver dig adgang til ressourcens funktionalitet.

Når du opretter og installerer Bicep-filer, interagerer du med kontrolfladen. I Azure er kontrolflyet Azure Resource Manager. Du kan bruge Resource Manager til at definere konfigurationen af hver af dine ressourcer.

Men din pipeline skal ofte gøre mere end blot at interagere med kontrolflade. Det kan f.eks. være, at du skal udføre andre opgaver:

• Upload en blob til en lagerkonto.
• Rediger et databaseskema.
• Foretag et API-kald til en tredjepartstjeneste.
• Udløs opdateringen af en model til maskinel indlæring.
• Udrul et websted til en Azure App Service-app.
• Udrul software på en virtuel maskine.
• Registrer en DNS-post (Domain Name Server) hos en tredjepartsudbyder.

Når du overvejer en end-to-end-pipeline, skal du normalt udrulle dine Azure-ressourcer og derefter udføre en række handlinger i forhold til dataplanerne for disse ressourcer. Nogle gange kaldes disse handlinger sidste mile af installationen, fordi du udfører det meste af udrulningen ved hjælp af kontrolplanet, og der er kun en lille mængde konfiguration tilbage.

Seddel

Nogle ressourcer har ikke en klar opdeling mellem deres kontrolplan og dataplan. Disse omfatter Azure Data Factory og Azure API Management. Begge tjenester understøtter fuldt automatiserede udrulninger ved hjælp af Bicep, men de kræver særlige overvejelser. Du kan finde links til flere oplysninger på siden Oversigt i slutningen af modulet.

Sådan udfører du dataplanhandlinger

Når du opretter en udrulningspipeline, der interagerer med dine ressourcers dataplan, kan du bruge en af tre almindelige metoder:

• Resource Manager-installationsscripts.
• Pipelinescripts.
• Pipelineopgaver.

Resource Manager-installationsscripts er defineret i din Bicep-fil. De kører Bash- eller PowerShell-scripts og kan interagere med Azure CLI- eller Azure PowerShell-cmdlet'er. Du opretter en administreret identitet, så installationsscriptet kan godkendes i Azure, og Azure klargør og administrerer automatisk de andre ressourcer, der skal bruges til at køre installationsscriptet.

Installationsscripts er gode, når du skal køre et grundlæggende script i installationsprocessen. De giver dig dog ikke let adgang til andre elementer fra din pipeline.

Du kan også køre din egen logik fra en udrulningspipeline. Azure Pipelines leverer et omfattende økosystem af opgaver til almindelige ting, du skal gøre. Hvis du ikke kan finde en opgave, der opfylder dine behov, kan du bruge et script til at køre din egen Bash- eller PowerShell-kode. Pipelineopgaver og scripts køres fra pipelinens agent. Du skal ofte godkende opgaven eller scriptet til dataplanet for den tjeneste, du bruger, og den måde, du godkender på, afhænger af tjenesten.

Pipelineopgaver og scripts giver dig fleksibilitet og kontrol. De giver dig også adgang til pipelineartefakter, som du snart får mere at vide om. I dette modul fokuserer vi på pipelinescripts og -opgaver. Vi linker til flere oplysninger om Resource Manager-installationsscripts på siden Oversigt i slutningen af modulet.

Udgange

En pipeline opretter og konfigurerer normalt dine Azure-ressourcer ved at udrulle en Bicep-fil. De efterfølgende dele af pipelinen interagerer derefter med disse ressourcers dataplan. Hvis du vil kunne interagere med ressourcerne, skal pipelineopgaverne og -trinnene have oplysninger om den Azure-ressource, du har oprettet.

Lad os f.eks. antage, at du har en Bicep-fil, der installerer en lagerkonto. Du vil gerne have, at din pipeline udruller lagerkontoen og derefter uploader nogle blobs til en blobobjektbeholder på lagerkontoen. Den pipelineopgave, der uploader blobs, skal kende navnet på den lagerkonto, der skal oprettes forbindelse til, og navnet på den blobobjektbeholder, filen skal uploades til.

Det er god praksis at få Bicep-filen til at beslutte navnene på dine Azure-ressourcer. Den kan bruge parametre, variabler eller udtryk til at oprette navnene på lagerkontoen og blobobjektbeholderen. Bicep-filen kan derefter vise et output, der angiver hver ressources navn. Senere trin i pipelinen kan læse værdien af outputtet. På den måde behøver din pipelinedefinition ikke at kode navne eller andre oplysninger, der kan ændre sig mellem miljøer. Definitionen behøver heller ikke at være baseret på regler, der er defineret i din Bicep-fil.

Med Azure Pipelines kan du overføre outputværdierne ved hjælp af pipelinevariabler. Du kan angive værdien af en pipelinevariabel i et pipelinescript. Du bruger et specielt formateret logoutput, som Azure Pipelines forstår at fortolke, som vist her:

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)

Når du opretter en variabel i ét job, men vil have adgang til den i et andet job i samme fase, skal du tilknytte den.

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)

Hvis du vil have adgang til en variabel på tværs af pipelinefaser, skal du også tilknytte variablen, men du bruger en anden syntaks:

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)

Ved hjælp af Bicep-output og pipelinevariabler kan du oprette en pipeline i fleretages, der udruller din Bicep-kode og derefter udfører forskellige handlinger på ressourcerne som en del af udrulningen.