Üzembehelyezési feladatok

Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022

Fontos

• A feladat- és szakasznevek nem ütköznek fenntartott kulcsszavakkal (például deployment feladattípus esetén)
• A fázisok minden feladatának egyedi névvel kell rendelkeznie.

Azt javasoljuk, hogy YAML-folyamatokban az üzembehelyezési lépéseket egy speciális, üzembehelyezési feladatnak nevezett feladattípusban helyezze el. Az üzembehelyezési feladat olyan lépések gyűjteménye, amelyek sorban vannak futtatva a környezeten. Egy üzembehelyezési feladat és egy hagyományos feladat ugyanabban a szakaszban is létezhet. Az Azure DevOps támogatja a runOnce, a rolling és a kanári stratégiákat.

Az üzembehelyezési feladatok a következő előnyökkel járnak:

• Üzembehelyezési előzmények: Megkapja a folyamatok üzembehelyezési előzményeit, egészen az üzembe helyezés adott erőforrásáig és állapotáig a naplózáshoz.
• Üzembehelyezési stratégia alkalmazása: Ön szabja meg az alkalmazás bevezetésének módját.

Az üzembehelyezési feladatok nem klónozzák automatikusan a forrásadattárat. A feladatban lévő forrásadattárat a következővel checkout: selftekintheti meg: .

Feljegyzés

Ez a cikk az üzembe helyezéssel kapcsolatos feladatokra összpontosít. Az Azure-ban folyamatok használatával történő üzembe helyezésről az Üzembe helyezés az Azure-ban – áttekintés című témakörben olvashat.

Séma

Nyissa meg a YAML-sémát a jobs.deployment és a jobs.deployment.environment definíciók megtekintéséhez .

Virtuális gépek esetében nem kell készletet definiálnia. Bármelyik lépés, amelyet a virtuálisgép-erőforrással rendelkező üzembehelyezési feladatban definiál, az adott virtuális gépen fut, nem pedig a kapcsolt ügynök ellen. Más erőforrástípusok, például a Kubernetes esetében meg kell határoznia egy készletet, hogy a tevékenységek futhassák az adott gépen.

Üzembe helyezési stratégiák

Alkalmazásfrissítések telepítésekor fontos, hogy a frissítés kézbesítéséhez használt technika a következő lesz:

• Inicializálás engedélyezése.
• Telepítse a frissítést.
• Forgalom átirányítása a frissített verzióra.
• Tesztelje a frissített verziót az útválasztási forgalom után.
• Hiba esetén futtassa a lépéseket az utolsó ismert jó verzióra való visszaállításhoz.

Ezt olyan életciklus-horgok használatával érjük el, amelyek az üzembe helyezés során futtathatnak lépéseket. Az életciklus-horgok mindegyike ügynökfeladatként vagy kiszolgálói feladatként (vagy a jövőben tárolóként vagy érvényesítési feladatként) oldható fel az pool attribútumtól függően. Alapértelmezés szerint az életciklus-horgok öröklik a feladat pool által megadott deployment értéket.

Az üzembehelyezési feladatok a rendszerváltozót $(Pipeline.Workspace) használják.

Az életciklus-horgok leírása

preDeploy: Az erőforrások inicializálására szolgáló lépések futtatására szolgál az alkalmazás üzembe helyezése előtt.

deploy: Az alkalmazás üzembe helyezésének lépéseinek futtatására szolgál. A letöltési feladat (artifact download task) automatikusan be lesz illesztve csak az üzembe helyezési feladatokhoz tartozó deploy horogba. Az összetevők letöltésének leállításához használja - download: none vagy válassza ki a letölteni kívánt összetevőket a Folyamatösszetevő letöltése feladat megadásával.

routeTraffic: A frissített verzió felé történő forgalmat kiszolgáló lépések futtatására szolgál.

postRouteTraffic: A forgalom irányítása után futtatja a lépéseket. Ezek a feladatok általában meghatározott időközönként figyelik a frissített verzió állapotát.

on: failure vagy on: success: A visszaállítási műveletek vagy a törlés lépéseinek futtatására szolgál.

RunOnce üzembehelyezési stratégia

A runOnce a legegyszerűbb üzembehelyezési stratégia, amely az összes életciklus-horgot, nevezetesen preDeploydeployrouteTraffic, és postRouteTrafficegyszer hajtja végre. Ezután vagy on:success végrehajtja vagy on:failure végrehajtja.

strategy: 
    runOnce:
      preDeploy:        
        pool: [ server | pool ] # See pool schema.        
        steps:
        - script: [ script | bash | pwsh | powershell | checkout | task | templateReference ]
      deploy:          
        pool: [ server | pool ] # See pool schema.        
        steps:
        ...
      routeTraffic:         
        pool: [ server | pool ]         
        steps:
        ...        
      postRouteTraffic:          
        pool: [ server | pool ]        
        steps:
        ...
      on:
        failure:         
          pool: [ server | pool ]           
          steps:
          ...
        success:          
          pool: [ server | pool ]           
          steps:
          ...

Ha saját üzemeltetésű ügynököket használ, a munkaterület tiszta beállításaival megtisztíthatja az üzembehelyezési munkaterületet.

  jobs:
  - deployment: MyDeploy
    pool:
      vmImage: 'ubuntu-latest'
    workspace:
      clean: all
    environment: staging

Szakaszos üzembe helyezési stratégia

A működés közbeni üzembe helyezés az alkalmazás előző verziójának példányait az alkalmazás új verziójának példányaival helyettesíti az egyes iterációkban rögzített virtuális gépeken (gördülő készleten).

Jelenleg csak a virtuálisgép-erőforrások gördülő stratégiáját támogatjuk.

Egy gördülő üzembe helyezés például általában megvárja az egyes virtuális gépek üzembe helyezését, mielőtt továbblép a következő üzembe helyezési csoportra. Az egyes iterációk után állapot-ellenőrzést végezhet, és ha jelentős probléma merül fel, a működés közbeni üzembe helyezés leállítható.

A gördülő üzemelő példányok a csomópont alatti rolling: kulcsszó strategy: megadásával konfigurálhatók. A strategy.name változó ebben a stratégiai blokkban érhető el, amely a stratégia nevét veszi fel. Ebben az esetben gördül.

strategy:
  rolling:
    maxParallel: [ number or percentage as x% ]
    preDeploy:        
      steps:
      - script: [ script | bash | pwsh | powershell | checkout | task | templateReference ]
    deploy:          
      steps:
      ...
    routeTraffic:         
      steps:
      ...        
    postRouteTraffic:          
      steps:
      ...
    on:
      failure:         
        steps:
        ...
      success:          
        steps:
        ...

Minden életciklus-horog támogatott, és az életciklus-horogfeladatok az egyes virtuális gépeken való futtatáshoz jönnek létre.

preDeploy, deploy, routeTrafficés postRouteTraffic a rendszer a megadott kötegméretenként egyszer hajtja maxParallelvégre. Ezután vagy on: success végrehajtja vagy on: failure végrehajtja.

Ezzel maxParallel: <# or % of VMs>szabályozhatja, hogy hány virtuálisgép-célpéldány legyen párhuzamosan üzembe helyezve. Ez biztosítja, hogy az alkalmazás ezeken a gépeken fusson, és képes kezelni a kéréseket, miközben az üzembe helyezés a többi gépen történik, ami csökkenti az általános állásidőt.

Feljegyzés

A funkció néhány ismert hiányosságot tartalmaz. Például, ha újrapróbál egy fázist, az ismét lefuttatja az üzembe helyezést az összes virtuális gépen, és nem csupán a sikertelen célokon.

Tesztcsoportos üzembe helyezési stratégia

A Canary üzembe helyezési stratégiája egy fejlett üzembehelyezési stratégia, amely segít csökkenteni az alkalmazások új verzióinak bevezetésében jelentkező kockázatokat. Ezzel a stratégiával először a kiszolgálók egy kis részhalmazát módosíthatja. Az új verzióba vetett nagyobb bizalommal több kiszolgálóra is kiadhatja az infrastruktúrában, és nagyobb forgalmat irányíthat hozzá.

strategy: 
    canary:
      increments: [ number ]
      preDeploy:        
        pool: [ server | pool ] # See pool schema.        
        steps:
        - script: [ script | bash | pwsh | powershell | checkout | task | templateReference ]
      deploy:          
        pool: [ server | pool ] # See pool schema.        
        steps:
        ...
      routeTraffic:         
        pool: [ server | pool ]         
        steps:
        ...        
      postRouteTraffic:          
        pool: [ server | pool ]        
        steps:
        ...
      on:
        failure:         
          pool: [ server | pool ]           
          steps:
          ...
        success:          
          pool: [ server | pool ]           
          steps:
          ...

A Canary üzembehelyezési stratégiája támogatja az preDeploy életciklus horgot (egyszer hajtja végre), és iterál a deploy, routeTrafficés postRouteTraffic életciklus horgokkal. Ezután kilép a horoggal vagy success a failure horoggal.

Ebben a stratégiában a következő változók érhetők el:

strategy.name: A stratégia neve. Például: kanári.
strategy.action: A Kubernetes-fürtön végrehajtandó művelet. Üzembe helyezés, előléptetés vagy elutasítás.
strategy.increment: Az aktuális interakcióban használt növekményes érték. Ez a változó csak a deploy, routeTrafficés postRouteTraffic életciklus horgokban érhető el.

Példák

RunOnce üzembehelyezési stratégia

Az alábbi YAML-kódrészlet egy üzembe helyezési feladat egyszerű használatát mutatja be az üzembe helyezési runOnce stratégia használatával. A példa tartalmaz egy kivételi lépést.

jobs:
  # Track deployments on the environment.
  - deployment: DeployWeb
    displayName: deploy Web App
    pool:
      vmImage: 'ubuntu-latest'
    # Creates an environment if it doesn't exist.
    environment: 'smarthotel-dev'
    strategy:
      # Default deployment strategy, more coming...
      runOnce:
        deploy:
          steps:
            - checkout: self
            - script: echo my first deployment

A feladat minden futtatásakor a rendszer rögzíti az üzembe helyezési előzményeket a smarthotel-dev környezeten.

Feljegyzés

• Üres erőforrásokkal rendelkező környezetet is létrehozhat, és ezt absztrakt rendszerhéjként használhatja az üzembe helyezési előzmények rögzítéséhez, ahogy az előző példában is látható.

A következő példa bemutatja, hogyan hivatkozhat egy folyamat egy környezetre és egy üzembe helyezési feladat célként használandó erőforrására is.

jobs:
  - deployment: DeployWeb
    displayName: deploy Web App
    pool:
      vmImage: 'ubuntu-latest'
    # Records deployment against bookings resource - Kubernetes namespace.
    environment: 'smarthotel-dev.bookings'
    strategy: 
      runOnce:
        deploy:
          steps:
            # No need to explicitly pass the connection details.
            - task: KubernetesManifest@1
              displayName: Deploy to Kubernetes cluster
              inputs:
                action: deploy
                namespace: $(k8sNamespace)
                manifests: |
                  $(System.ArtifactsDirectory)/manifests/*
                imagePullSecrets: |
                  $(imagePullSecret)
                containers: |
                  $(containerRegistry)/$(imageRepository):$(tag)

Ez a megközelítés a következő előnyökkel jár:

• A környezet egy adott erőforrásának üzembehelyezési előzményeit rögzíti, nem pedig az előzményeket a környezet összes erőforrásán.
• Az üzembehelyezési feladat lépései automatikusan öröklik az erőforrás kapcsolati adatait (ebben az esetben egy Kubernetes-névteret), smarthotel-dev.bookingsmivel az üzembehelyezési feladat a környezethez van csatolva. Ez azokban az esetekben hasznos, amikor a feladat több lépéséhez ugyanazt a kapcsolati részletet állítja be.

Feljegyzés

Ha privát AKS-fürtöt használ, ellenőrizze, hogy hozzá van kapcsolva a fürt virtuális hálózatához, mivel az API-kiszolgáló végpontja nem publikus IP-címen keresztül érhető el.

Az Azure Pipelines azt javasolja, hogy állítson be egy saját üzemeltetésű ügynököt egy olyan virtuális hálózaton belül, amely hozzáfér a fürt virtuális hálózatához. A részleteket a privát fürthöz való csatlakozás beállításai című témakörben találja.

Szakaszos üzembe helyezési stratégia

A virtuális gépek gördülő stratégiája minden iterációban legfeljebb öt célt frissít. maxParallel meghatározza a párhuzamosan üzembe helyezhető célok számát. A kijelölés a célok abszolút számát vagy százalékos arányát adja meg, amelyeknek bármikor elérhetőnek kell maradniuk, kivéve azokat a célokat, amelyeken üzembe helyezve vannak. Az üzembe helyezés során a sikeresség és a hibafeltételek meghatározására is használható.

jobs:
  - deployment: VMDeploy
    displayName: web
    environment:
      name: smarthotel-dev
      resourceType: VirtualMachine
    strategy:
      rolling:
        maxParallel: 5  # for percentages, mention as x%
        preDeploy:
          steps:
            - download: current
              artifact: drop
            - script: echo initialize, cleanup, backup, install certs
        deploy:
          steps:
            - task: IISWebAppDeploymentOnMachineGroup@0
              displayName: 'Deploy application to Website'
              inputs:
                WebSiteName: 'Default Web Site'
                Package: '$(Pipeline.Workspace)/drop/**/*.zip'
        routeTraffic:
          steps:
            - script: echo routing traffic
        postRouteTraffic:
          steps:
            - script: echo health check post-route traffic
        on:
          failure:
            steps:
              - script: echo Restore from backup! This is on failure
          success:
            steps:
              - script: echo Notify! This is on success

Tesztcsoportos üzembe helyezési stratégia

A következő példában az AKS kanári-stratégiája először 10 százalékos podokkal fogja üzembe helyezni a módosításokat, majd 20 százalékkal, miközben figyeli az állapotot postRouteTraffic. Ha minden jól megy, az 100%-ra fog előléptetni.

jobs:
  - deployment: 
      environment: smarthotel-dev.bookings
      pool: 
        name: smarthotel-devPool
      strategy:                  
        canary:      
          increments: [10, 20]  
          preDeploy:                                     
            steps:           
              - script: initialize, cleanup....
          deploy:             
            steps: 
              - script: echo deploy updates...
              - task: KubernetesManifest@1
                inputs:
                  action: $(strategy.action)
                  namespace: 'default'
                  strategy: $(strategy.name)
                  percentage: $(strategy.increment)
                  manifests: 'manifest.yml'
          postRouteTraffic: 
            pool: server 
            steps:           
              - script: echo monitor application health...
          on: 
            failure: 
              steps: 
                - script: echo clean-up, rollback...
            success: 
              steps: 
                - script: echo checks passed, notify...

Folyamatdetektorok használata a lépések automatikus beszúrásához

A folyamat-dekorátorok az üzembehelyezési feladatokban használhatók az egyéni lépések (például a biztonságirés-ellenőrző) automatikus üzembe helyezéséhez minden üzembe helyezési feladat életciklus-horogvégrehajtásához . Mivel a folyamat-dekorátorok a szervezet összes folyamatára alkalmazhatók, ez a biztonságos üzembehelyezési eljárások kényszerítésének részeként alkalmazható.

Emellett az üzembehelyezési feladatok tárolófeladatként is futtathatók, és ha meg van adva a szolgáltatásoldali autó is.

Kimeneti változók támogatása

Adja meg a kimeneti változókat az üzembehelyezési feladat életciklus-horgaiban , és használja fel őket más alárendelt lépésekben és feladatokban ugyanabban a fázisban.

A változók szakaszok közötti megosztásához adjon ki egy összetevőt egy fázisban, majd használja azt egy későbbi szakaszban, vagy használja a stageDependencies változókban leírt szintaxist.

Az üzembehelyezési stratégiák végrehajtása során az alábbi szintaxissal érheti el a kimeneti változókat a feladatok között.

• RunOnce-stratégia esetén: $[dependencies.<job-name>.outputs['<job-name>.<step-name>.<variable-name>']] (például $[dependencies.JobA.outputs['JobA.StepA.VariableA']])
• RunOnce-stratégia és resourceType esetén: $[dependencies.<job-name>.outputs['Deploy_<resource-name>.<step-name>.<variable-name>']]. (például: $[dependencies.JobA.outputs['Deploy_VM1.StepA.VariableA']])
• Kanári-stratégia esetén:$[dependencies.<job-name>.outputs['<lifecycle-hookname>_<increment-value>.<step-name>.<variable-name>']]
• Gördülő stratégiához:$[dependencies.<job-name>.outputs['<lifecycle-hookname>_<resource-name>.<step-name>.<variable-name>']]

# Set an output variable in a lifecycle hook of a deployment job executing canary strategy.
- deployment: A
  pool:
    vmImage: 'ubuntu-latest'
  environment: staging
  strategy:                  
    canary:      
      increments: [10,20]  # Creates multiple jobs, one for each increment. Output variable can be referenced with this.
      deploy:
        steps:
        - bash: echo "##vso[task.setvariable variable=myOutputVar;isOutput=true]this is the deployment variable value"
          name: setvarStep
        - bash: echo $(setvarStep.myOutputVar)
          name: echovar

# Map the variable from the job.
- job: B
  dependsOn: A
  pool:
    vmImage: 'ubuntu-latest'
  variables:
    myVarFromDeploymentJob: $[ dependencies.A.outputs['deploy_10.setvarStep.myOutputVar'] ]
  steps:
  - script: "echo $(myVarFromDeploymentJob)"
    name: echovar

Feladat runOnce esetén adja meg a feladat nevét az életciklus-horog helyett:

# Set an output variable in a lifecycle hook of a deployment job executing runOnce strategy.
- deployment: A
  pool:
    vmImage: 'ubuntu-latest'
  environment: staging
  strategy:                  
    runOnce:
      deploy:
        steps:
        - bash: echo "##vso[task.setvariable variable=myOutputVar;isOutput=true]this is the deployment variable value"
          name: setvarStep
        - bash: echo $(setvarStep.myOutputVar)
          name: echovar

# Map the variable from the job.
- job: B
  dependsOn: A
  pool:
    vmImage: 'ubuntu-latest'
  variables:
    myVarFromDeploymentJob: $[ dependencies.A.outputs['A.setvarStep.myOutputVar'] ]
  steps:
  - script: "echo $(myVarFromDeploymentJob)"
    name: echovar

Ha környezeteket határoz meg egy üzembehelyezési feladatban, a kimeneti változó szintaxisa a környezet definiálásának módjától függően változik. Ebben a példában rövidített jelölést használ, env1 és env2 a teljes szintaxist egy meghatározott erőforrástípussal tartalmazza.

stages:
- stage: StageA
  jobs:
  - deployment: A1
    pool:
      vmImage: 'ubuntu-latest'
    environment: env1
    strategy:                  
      runOnce:
        deploy:
          steps:
          - bash: echo "##vso[task.setvariable variable=myOutputVar;isOutput=true]this is the deployment variable value"
            name: setvarStep
          - bash: echo $(System.JobName)
  - deployment: A2
    pool:
      vmImage: 'ubuntu-latest'
    environment: 
      name: env2
      resourceName: vmsfortesting
      resourceType: virtualmachine
    strategy:                  
      runOnce:
        deploy:
          steps:
          - script: echo "##vso[task.setvariable variable=myOutputVarTwo;isOutput=true]this is the second deployment variable value"
            name: setvarStepTwo
  
  - job: B1
    dependsOn: A1
    pool:
      vmImage: 'ubuntu-latest'
    variables:
      myVarFromDeploymentJob: $[ dependencies.A1.outputs['A1.setvarStep.myOutputVar'] ]
      
    steps:
    - script: "echo $(myVarFromDeploymentJob)"
      name: echovar
 
  - job: B2
    dependsOn: A2
    pool:
      vmImage: 'ubuntu-latest'
    variables:
      myVarFromDeploymentJob: $[ dependencies.A2.outputs['A2.setvarStepTwo.myOutputVarTwo'] ]
      myOutputVarTwo: $[ dependencies.A2.outputs['Deploy_vmsfortesting.setvarStepTwo.myOutputVarTwo'] ]
    
    steps:
    - script: "echo $(myOutputVarTwo)"
      name: echovartwo

Ha egy változót az első fázisban lévő feladatból ad ki, a következő szakaszban egy üzembehelyezési feladatból való hivatkozás más szintaxist használ attól függően, hogy szeretne-e változót beállítani, vagy a szakasz feltételeként használni.

stages:
- stage: StageA
  jobs:
  - job: A1
    steps:
      - pwsh: echo "##vso[task.setvariable variable=RunStageB;isOutput=true]true"
        name: setvarStep
      - bash: echo $(System.JobName)

- stage: StageB
  dependsOn: 
    - StageA
 
  # when referring to another stage, stage name is included in variable path
  condition: eq(dependencies.StageA.outputs['A1.setvarStep.RunStageB'], 'true')
  
  # Variables reference syntax differs slightly from inter-stage condition syntax
  variables:
    myOutputVar: $[stageDependencies.StageA.A1.outputs['setvarStep.RunStageB']]
  jobs:
  - deployment: B1
    pool:
      vmImage: 'ubuntu-latest'
    environment: envB
    strategy:                  
      runOnce:
        deploy:
          steps:
          - bash: echo $(myOutputVar)

Amikor egy üzembe helyezési feladatból kimenetel egy változót, a stageDependencies szintaxissal hivatkozzon rá a következő fázisból (például $[stageDependencies.<stage-name>.<job-name>.outputs[Deploy_<resource-name>.<step-name>.<variable-name>]]).

stages:
- stage: StageA
  jobs:
    - deployment: A1
      environment: 
        name:  env1
        resourceName: DevEnvironmentV
        resourceType: virtualMachine
      strategy:
        runOnce:
          deploy:
            steps:
              - script: echo "##vso[task.setvariable variable=myVar;isOutput=true]true"
                name: setvarStep
              - script: |
                  echo "Value of myVar in the same Job : $(setVarStep.myVar)"
                displayName: 'Verify variable in StageA'
- stage: StageB
  dependsOn: StageA

  # Full Variables syntax for inter-stage jobs
  variables:
    myOutputVar: $[stageDependencies.StageA.A1.outputs['Deploy_DevEnvironmentV.setvarStep.myVar']]
  jobs:
  - deployment: B1
    pool:
      vmImage: 'ubuntu-latest'
    environment: envB
    strategy:                  
      runOnce:
        deploy:
          steps:
          - bash: echo $(myOutputVar)

További információ a többfeladatos kimeneti változó beállításáról

GYIK

A folyamat elakadt a "Feladat függőben van..." üzenettel. Hogyan javíthatom ki ezt a problémát?

Ez akkor fordulhat elő, ha két feladat között névütközés van. Ellenőrizze, hogy az ugyanabban a szakaszban lévő üzembehelyezési feladatoknak egyedi neve van-e, és hogy a feladat- és szakasznevek nem tartalmaznak kulcsszavakat. Ha az átnevezés nem oldja meg a problémát, tekintse át a folyamatfuttatások hibaelhárítását.

Támogatottak a dekorátorok az üzembehelyezési csoportokban?

Szám Az üzembehelyezési csoportokban nem használhat dekorátorokat.