Definiera containerjobb (YAML)

Azure DevOps Services | Azure DevOps Server 2022 – Azure DevOps Server 2019

Som standard körs jobb på värddatorn där agenten är installerad. Detta är praktiskt och passar vanligtvis bra för projekt som precis har börjat använda Azure Pipelines. Med tiden kanske du vill ha mer kontroll över kontexten där dina aktiviteter körs. YAML-pipelines erbjuder containerjobb för den här kontrollnivån.

På Linux- och Windows-agenter kan jobb köras på värden eller i en container. (På macOS och Red Hat Enterprise Linux 6 är containerjobb inte tillgängliga.) Containrar tillhandahåller isolering från värden och gör att du kan fästa specifika versioner av verktyg och beroenden. Värdjobb kräver mindre inledande installation och infrastruktur att underhålla.

Containrar erbjuder en enkel abstraktion över värdoperativsystemet. Du kan välja de exakta versionerna av operativsystem, verktyg och beroenden som bygget kräver. När du anger en container i pipelinen hämtar och startar agenten först containern. Sedan körs varje steg i jobbet i containern. Du kan inte ha kapslade containrar. Containrar stöds inte när en agent redan körs i en container.

Om du behöver detaljerad kontroll på den enskilda stegnivån kan du med stegmål välja container eller värd för varje steg.

Krav

Linux-baserade containrar

Azure Pipelines-systemet kräver några saker i Linux-baserade containrar:

• Bash
• glibc-baserad
• Kan köra Node.js (som agenten tillhandahåller)
• Definierar inte en ENTRYPOINT
• USER har åtkomst till groupadd och andra behörighetskommandon utan sudo

Och på din agentvärd:

• Kontrollera att Docker är installerat
• Agenten måste ha behörighet att komma åt Docker-daemonen

Se till att containern har var och en av dessa verktyg tillgängliga. Vissa av de avskalade containrar som är tillgängliga på Docker Hub, särskilt de som är baserade på Alpine Linux, uppfyller inte dessa minimikrav. Containrar med en ENTRYPOINT kanske inte fungerar, eftersom Azure Pipelines kommer att docker create vara en väntande container och docker exec en serie kommandon, som förväntar sig att containern alltid är igång.

Kommentar

För Windows-baserade Linux-containrar måste Node.js vara förinstallerade.

Windows-container

Azure Pipelines kan också köra Windows-containrar. Windows Server version 1803 eller senare krävs. Docker måste vara installerat. Kontrollera att din pipelines-agent har behörighet att komma åt Docker-daemonen.

Windows-containern måste ha stöd för att köra Node.js. En grundläggande Windows Nano Server-container saknar beroenden som krävs för att köra Node.

Värdbaserade agenter

Endast windows-2019 och ubuntu-* avbildningar har stöd för att köra containrar. MacOS-avbildningen stöder inte containrar som körs.

Enskilt jobb

Ett enkelt exempel:

pool:
  vmImage: 'ubuntu-latest'

container: ubuntu:18.04

steps:
- script: printenv

Detta instruerar systemet att hämta avbildningen ubuntu som taggats 18.04 från Docker Hub och sedan starta containern. När kommandot printenv körs sker det i containern ubuntu:18.04 .

Ett Windows-exempel:

pool:
  vmImage: 'windows-2019'

container: mcr.microsoft.com/windows/servercore:ltsc2019

steps:
- script: set

Kommentar

Windows kräver att kernelversionen av värden och containern matchar. Eftersom det här exemplet använder Windows 2019-avbildningen använder vi taggen 2019 för containern.

Flera jobb

Containrar är också användbara för att köra samma steg i flera jobb. I följande exempel körs samma steg i flera versioner av Ubuntu Linux. (Och vi behöver inte nämna nyckelordet jobs , eftersom det bara finns ett definierat enda jobb.)

pool:
  vmImage: 'ubuntu-latest'

strategy:
  matrix:
    ubuntu16:
      containerImage: ubuntu:16.04
    ubuntu18:
      containerImage: ubuntu:18.04
    ubuntu20:
      containerImage: ubuntu:20.04

container: $[ variables['containerImage'] ]

steps:
- script: printenv

Slutpunkter

Containrar kan finnas i andra register än offentliga Docker Hub-register. Om du vill vara värd för en avbildning i Azure Container Registry eller ett annat privat containerregister (inklusive ett privat Docker Hub-register) lägger du till en tjänstanslutning till det privata registret. Sedan kan du referera till den i en containerspecifikation:

container:
  image: registry:ubuntu1804
  endpoint: private_dockerhub_connection

steps:
- script: echo hello

eller

container:
  image: myprivate.azurecr.io/windowsservercore:1803
  endpoint: my_acr_connection

steps:
- script: echo hello

Andra containerregister kan också fungera. Amazon ECR fungerar inte för närvarande eftersom det finns andra klientverktyg som krävs för att konvertera AWS-autentiseringsuppgifter till något som Docker kan använda för att autentisera.

Kommentar

Red Hat Enterprise Linux 6-versionen av agenten kör inte containerjobbet. Välj en annan Linux-smak, till exempel Red Hat Enterprise Linux 7 eller senare.

Alternativ

Om du behöver styra start av container kan du ange options.

container:
  image: ubuntu:18.04
  options: --hostname container-test --ip 192.168.0.1

steps:
- script: echo hello

Körning docker create --help ger dig en lista över alternativ som kan skickas till Docker-anrop. Alla dessa alternativ är inte garanterade att fungera med Azure DevOps. Kontrollera först om du kan använda en containeregenskap för att uppnå samma mål. Mer information finns resources.containers.container i YAML-schemat och kommandoreferensendocker create.

Återanvändbar containerdefinition

I följande exempel definieras containrarna i avsnittet resurser. Varje container refereras sedan senare genom att referera till dess tilldelade alias. (Här listar vi uttryckligen nyckelordet jobs för tydlighetens skull.)

resources:
  containers:
  - container: u16
    image: ubuntu:16.04

  - container: u18
    image: ubuntu:18.04

  - container: u20
    image: ubuntu:20.04

jobs:
- job: RunInContainer
  pool:
    vmImage: 'ubuntu-latest'

  strategy:
    matrix:
      ubuntu16:
        containerResource: u16
      ubuntu18:
        containerResource: u18
      ubuntu20:
        containerResource: u20

  container: $[ variables['containerResource'] ]

  steps:
  - script: printenv

Icke-glibc-baserade containrar

Azure Pipelines-agenten tillhandahåller en kopia av Node.js som krävs för att köra uppgifter och skript. Information om vilken version av Node.js för en värdbaserad agent finns i Microsoft-värdbaserade agenter. Versionen av Node.js kompileras mot den C-körning som vi använder i vårt värdbaserade moln, vanligtvis glibc. Vissa varianter av Linux använder andra C-körningar. Alpine Linux använder till exempel musl.

Om du vill använda en icke-glibc-baserad container som en jobbcontainer måste du ordna några saker på egen hand. Först måste du ange en egen kopia av Node.js. För det andra måste du lägga till en etikett i avbildningen som talar om för agenten var Node.js binärfil ska hittas. Slutligen kommer inte stock Alpine med andra beroenden som Azure Pipelines är beroende av: bash, sudo, som och groupadd.

Ta med egna Node.js

Du ansvarar för att lägga till en Node-binärfil i containern. Nod 18 är ett säkert val. Du kan börja från bilden node:18-alpine .

Berätta för agenten om Node.js

Agenten läser en containeretikett "com.azure.dev.pipelines.handler.node.path". Om den här etiketten finns måste den vara sökvägen till Node.js binärfilen. I en avbildning som baseras på node:18-alpinelägger du till den här raden i Dockerfile:

LABEL "com.azure.dev.pipelines.agent.handler.node.path"="/usr/local/bin/node"

Lägg till krav

Azure Pipelines förutsätter ett Bash-baserat system med vanliga administrationspaket installerade. I synnerhet Alpine Linux levereras inte med flera av de paket som behövs. Installation av bash, sudooch shadow täcker de grundläggande behoven.

RUN apk add bash sudo shadow

Om du är beroende av några inkorgs- eller Marketplace-uppgifter måste du också ange de binärfiler som krävs.

Fullständigt exempel på en Dockerfile

FROM node:10-alpine

RUN apk add --no-cache --virtual .pipeline-deps readline linux-pam \
  && apk add bash sudo shadow \
  && apk del .pipeline-deps

LABEL "com.azure.dev.pipelines.agent.handler.node.path"="/usr/local/bin/node"

CMD [ "node" ]

Flera jobb med agentpooler på en enda värdbaserad agent

Containerjobbet använder den underliggande värdagenten Docker config.json för avbildningsregisterauktorisering, som loggar ut i slutet av Initieringen av Docker-registercontainern. Efterföljande hämtningsauktorisering för registeravbildningar kan nekas för "obehörig autentisering" eftersom Docker-config.json fil som registrerats i systemet för autentisering redan har loggats ut av ett av de andra containerjobben som körs parallellt.

Lösningen är att ange miljövariabeln DOCKER_CONFIG Docker som är specifik för varje agentpooltjänst som körs på den värdbaserade agenten. DOCKER_CONFIG Exportera i varje agentpools runsvc.sh skript:

#insert anything to set up env when running as a service
export DOCKER_CONFIG=./.docker