Dela via

Containerjobb i YAML-pipelines

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

I den här artikeln beskrivs containerjobb i Azure Pipelines. Containrar är lätta abstraktioner från värdoperativsystemet som tillhandahåller alla nödvändiga element för att köra ett jobb i en viss miljö.

Som standard körs Azure Pipelines-jobb direkt på agenter som är installerade på värddatorer. Värdbaserade agentjobb är praktiska, kräver lite inledande installation eller infrastrukturunderhåll och passar bra för grundläggande projekt. Om du vill ha mer kontroll över aktivitetskontexten kan du definiera och köra pipelinejobb i containrar för att få de exakta versionerna av operativsystem, verktyg och beroenden som du vill använda.

För ett containerjobb hämtar och startar agenten först containern och kör sedan varje steg i jobbet i containern. Om du behöver mer detaljerad kontroll över enskilda byggsteg kan du använda stegmål för att välja en container eller värd för varje steg.

Krav för containerjobb

  • En YAML-baserad pipeline. Klassiska pipelines stöder inte containerjobb.
  • En värdbaserad Windows- eller Ubuntu-agent. MacOS-agenter stöder inte containrar. För att använda icke-Ubuntu Linux-agenter, se Ickeglibc-baserade containrar.
  • Docker installerat på agenten med behörighet att komma åt Docker-daemon.
  • Klientagenten körs direkt på värddatorn, och inte befinner sig i en container. Kapslade containrar stöds inte.

Linux-baserade containrar har också följande krav:

  • Bash har installerats.
  • GNU C-bibliotek (glibc)-baserat. Nonglibc-kontainrar kräver ytterligare konfiguration. För mer information, se nicht glibc-baserade containrar.
  • Nej ENTRYPOINT. Containrar med en ENTRYPOINT kanske inte fungerar, eftersom docker exec förväntar sig att containern alltid körs.
  • USER med åtkomst till groupadd och andra privilegierade kommandon utan att använda sudo.
  • Möjlighet att köra Node.js, som agenten tillhandahåller.

    Anteckning

    Node.js måste förinstalleras för Linux-containrar på Windows-värdar.

Vissa avskalade containrar som är tillgängliga på Docker Hub, särskilt containrar baserade på Alpine Linux, uppfyller inte dessa krav. För mer information, se nicht glibc-baserade containrar.

Enskilt jobb

I följande exempel definieras en Windows- eller Linux-container med ett enda jobb.

I det här exemplet uppmanas systemet att hämta avbildningen ubuntu som taggats 18.04 från Docker Hub och sedan starta containern. Kommandot printenv körs i containern ubuntu:18.04 .

pool:
  vmImage: 'ubuntu-latest'

container: ubuntu:18.04

steps:
- script: printenv

Flera jobb

Du kan använda containrar för att köra samma steg i flera jobb. I följande exempel körs samma steg i flera versioner av Ubuntu Linux. Du behöver inte använda nyckelordet jobs eftersom endast ett enda jobb har definierats.

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

Flera jobb på en och samma agentvärd

Ett containerjobb använder den underliggande värdagentens Docker-konfigurationsfil för auktorisering av avbildningsregister. Den här filen loggar ut i slutet av initieringen av Docker-registercontainern.

Hämtningar av registeravbildningar för containerjobb kan nekas för obehörig autentisering om ett annat jobb som körs parallellt på agenten redan har loggat ut Docker-konfigurationsfilen. Lösningen är att ange en Docker-miljövariabel som anropas DOCKER_CONFIG för varje agentpool som körs på den värdbaserade agenten.

Exportera DOCKER_CONFIG i varje agentpools runsvc.sh-skript enligt följande:

export DOCKER_CONFIG=./.docker

Startalternativ

Du kan använda egenskapen options för att ange alternativ för start av container.

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

steps:
- script: echo hello

Kör docker create --help för att hämta listan över alternativ som du kan skicka till Docker-anrop. Alla dessa alternativ är inte garanterade att fungera med Azure Pipelines. Kontrollera först om du kan använda en container egenskap för samma ändamål.

Mer information finns i kommandoreferensen för att skapa docker-containern och definitionen resources.containers.container i YAML-schemareferensen för Azure Pipelines.

Definition av återanvändbar container

Följande YAML-exempel definierar containrarna i resources avsnittet och refererar sedan till dem efter deras tilldelade alias. Nyckelordet jobs används 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

Slutpunkter för tjänster

Du kan vara värd för containrar i andra register än offentlig Docker Hub. 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 för att få åtkomst till registret. Sedan kan du referera till slutpunkten i containerdefinitionen.

Privat Docker Hub-anslutning:

container:
  image: registry:ubuntu1804
  endpoint: private_dockerhub_connection

Anslutning till Azure Container Registry:

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

Anteckning

Azure Pipelines kan inte konfigurera en tjänstanslutning för Amazon Elastic Container Registry (ECR), eftersom Amazon ECR kräver att andra klientverktyg för att konvertera AWS-autentiseringsuppgifter (Amazon Web Services) kan användas för Docker-autentisering.

Icke-glibc-baserade containrar

De värdbaserade Azure Pipelines-agenterna tillhandahåller Node.js, vilket krävs för att köra uppgifter och skript. Den Node.js versionen kompileras mot C-körningen som används i det värdbaserade molnet, vanligtvis glibc. Vissa Linux-varianter använder andra C-körtidsbibliotek. Alpine Linux använder musltill exempel . Mer information finns i agenter som hostas av Microsoft.

För att använda en container som inte är glibc-baserad i en pipeline behöver du:

  • Ange en egen kopia av Node.js.
  • Lägg till en etikett i bilden som pekar på platsen för Node.js binärfilen.
  • Ange beroenden för bash, sudo, which och groupadd Azure Pipelines.

Tillhandahåll din egen Node.js

Om du använder en icke-glibc-baserad container måste du lägga till en Node-binärfil i containern. Node.js 18 är ett säkert val. Börja från bilden node:18-alpine .

Dirigera agenten till Node.js

Agenten läser containeretiketten "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 bild baserad på node:18-alpine, lägger du till följande rad i din Dockerfile:

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

Lägga till nödvändiga paket

Azure Pipelines kräver att ett Bash-baserat system har vanliga administrativa paket installerade. Alpine Linux har inte flera av de paket som behövs. Installera bash, sudooch shadow för att täcka grundläggande behov.

RUN apk add bash sudo shadow

Om du är beroende av inbyggda uppgifter eller Marketplace-uppgifter anger du även de binärfiler som de behöver.

Fullständigt Dockerfile-exempel

FROM node:18-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" ]

Relaterat innehåll

  • Last updated on