Üzembehelyezési feladatok

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

Fontos

• A feladat- és szakasznevek nem tartalmazhatnak kulcsszavakat (például: deployment).
• 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 forrásadattárat a feladaton belül is kiveheti a következővel checkout: self: .

Megjegyzé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.

Schema

Az üzembe helyezési feladat megadásához az alábbi teljes szintaxist kell megadni:

jobs:
- deployment: string   # name of the deployment job, A-Z, a-z, 0-9, and underscore. The word "deploy" is a keyword and is unsupported as the deployment name.
  displayName: string  # friendly name to display in the UI
  pool:                # not required for virtual machine resources
    name: string       # Use only global level variables for defining a pool name. Stage/job level variables are not supported to define pool name.
    demands: string | [ string ]
  workspace:
    clean: outputs | resources | all # what to clean up before the job runs
  dependsOn: string
  condition: string
  continueOnError: boolean                # 'true' if future jobs should run even if this job fails; defaults to 'false'
  container: containerReference # container to run this job inside
  services: { string: string | container } # container resources to run as a service container
  timeoutInMinutes: nonEmptyString        # how long to run the job before automatically cancelling
  cancelTimeoutInMinutes: nonEmptyString  # how much time to give 'run always even if cancelled tasks' before killing them
  variables: # several syntaxes, see specific section
  environment: string  # target environment name and optionally a resource name to record the deployment history; format: <environment-name>.<resource-name>
  strategy:
    runOnce:    #rolling, canary are the other strategies that are supported
      deploy:
        steps: [ script | bash | pwsh | powershell | checkout | task | templateReference ]

A tulajdonsághoz environment részletesebb, alternatív szintaxis is használható.

environment:
    name: string # Name of environment.
    resourceName: string # Name of resource.
    resourceId: string # Id of resource.
    resourceType: string # Type of environment resource.
    tags: string # List of tag filters.

Virtuális gépek esetében nem kell készletet definiálnia. A virtuálisgép-erőforrással rendelkező üzembehelyezési feladatban definiált lépések az adott virtuális gépen futnak, nem pedig a készlet ügynöke 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 pool feladat által megadott értéket deployment .

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. Az összetevő-feladat letöltése automatikusan csak a horogba kerül üzembe deploy helyezési feladatokhoz. 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

runOncea 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 strategy: kulcsszó rolling: 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.

Megjegyzés:

A funkció néhány ismert hiányosságot tartalmaz. Ha például újrapróbálkozott egy fázissal, az újrafuttatja az üzembe helyezést az összes virtuális gépen, nem csak 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éből eredő 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 failure a success 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.

Megjegyzé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@0
          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.

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 a párhuzamosan üzembe helyezhető célok számát határozza meg. 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 siker é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@0 
          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 arra, hogy automatikusan injektáljanak minden egyéni lépést (például biztonságirés-ellenőrzőt) az összes üzembe helyezési feladat életciklus-horogvégrehajtására . 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['<job-name>_<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
      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.myOutputVar'] ]
      myOutputVarTwo: $[ dependencies.A2.outputs['Deploy_vmsfortesting.setvarStepTwo.myOutputVarTwo'] ]
    
    steps:
    - script: "echo $(myOutputVarTwo)"
      name: echovartwo

Amikor egy üzembe helyezési feladatból ad ki egy változót, a következő feladatból való hivatkozás különböző 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)

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?

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