Delen via

Containertaken in YAML-pijplijnen

  • Artikel

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

In dit artikel worden containertaken in Azure Pipelines uitgelegd.

Standaard worden Azure Pipelines-taken rechtstreeks uitgevoerd op de hostmachines waarop de agent is geïnstalleerd. Gehoste agenttaken zijn handig, vereisen weinig initiële installatie en infrastructuur om te onderhouden en zijn geschikt voor basisprojecten.

Als u meer controle wilt over de taakcontext, kunt u taken definiëren en uitvoeren in containers. Containers zijn een lichtgewicht abstractie boven het hostbesturingssysteem die isolatie biedt van de host. Wanneer u taken uitvoert in containers, kunt u de exacte versies van besturingssystemen, hulpprogramma's en afhankelijkheden selecteren die uw build nodig heeft.

Linux- en Windows-agents kunnen pijplijntaken rechtstreeks op de host of in containers uitvoeren. Containertaken zijn niet beschikbaar op het besturingssysteem macOS.

Voor een containertaak haalt de agent eerst de container op en start deze. Vervolgens wordt elke stap van de taak uitgevoerd in de container.

Als u gedetailleerde controle nodig hebt op het niveau van de afzonderlijke buildstap, kunt u met stapdoelen een container of host voor elke stap kiezen.

Voorwaarden

  • Gebruik een YAML-pijplijn. Klassieke pijplijnen bieden geen ondersteuning voor containertaken.
  • Gebruik een gehoste Windows- of Ubuntu-agent. Alleen windows-* en ubuntu-* agents ondersteunen actieve containers. De macos-* agents bieden geen ondersteuning voor draaiende containers.
  • Uw agent is ingesteld voor containertaken.
    • Windows- en Linux-agents moeten Docker hebben geïnstalleerd en moeten zijn gemachtigd om toegang te krijgen tot de Docker-daemon.
    • Containers worden niet ondersteund wanneer de agent al in een container wordt uitgevoerd. U kunt geen geneste containers hebben.

Aanvullende containervereisten

Op Linux gebaseerde containers hebben de volgende vereisten. Voor tijdelijke oplossingen, zie op Nonglibc gebaseerde containers.

  • Bash geïnstalleerd
  • GNU C Library (glibc)-gebaseerd
  • Nee ENTRYPOINT
  • Toegang verlenen aan USER tot groupadd en andere bevoegde opdrachten zonder gebruik te maken van sudo
  • Kan Node.js uitvoeren, die de agent biedt

    Notitie

    Node.js moet vooraf zijn geïnstalleerd voor Linux-containers op Windows-hosts.

Sommige uitgeklede containers die staan op Docker Hub, vooral containers op basis van Alpine Linux, voldoen niet aan deze vereisten. Containers met een container ENTRYPOINT werken mogelijk niet omdat Azure Pipelines docker create en docker exec verwachten dat de container altijd actief is.

Voorbeelden van één taak

In de volgende voorbeelden wordt een Windows- of Linux-container voor één taak gedefinieerd.

In het volgende eenvoudige voorbeeld wordt een Linux-container gedefinieerd:

pool:
  vmImage: 'ubuntu-latest'

container: ubuntu:18.04

steps:
- script: printenv

In het voorgaande voorbeeld wordt het systeem aangestuurd om de ubuntu image met tag 18.04 op te halen uit Docker Hub en dan de container te starten. De printenv opdracht wordt uitgevoerd in de ubuntu:18.04 container.

Meerdere banen

U kunt containers gebruiken om dezelfde stap in meerdere taken uit te voeren. In het volgende voorbeeld wordt dezelfde stap uitgevoerd in meerdere versies van Ubuntu Linux. U hoeft het jobs trefwoord niet te vermelden omdat er slechts één taak is gedefinieerd.

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

Meerdere taken met agentpools op één agenthost

Een containerjob maakt gebruik van het Docker-configuratiebestand van de onderliggende hostagent voor autorisatie van het imagerepository. Dit bestand wordt afgetekend aan het einde van de initialisatie van de Docker-registercontainer. Het ophalen van registerafbeeldingen voor volgende containertaken kan worden geweigerd voor unauthorized authentication omdat een andere taak die parallel wordt uitgevoerd, het Docker-configuratiebestand al heeft uitgechecked.

De oplossing is het instellen van een Docker-omgevingsvariabele DOCKER_CONFIG die specifiek is voor elke agentgroep die wordt uitgevoerd op de gehoste agent. Exporteer de DOCKER_CONFIG in het runsvc.sh script van elke agentpool als volgt:

export DOCKER_CONFIG=./.docker

Opstartopties

U kunt opgeven options om het opstarten van containers te beheren, zoals in het volgende voorbeeld:

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

steps:
- script: echo hello

Het uitvoeren van docker create --help geeft u de lijst met opties die u kunt doorgeven bij het aanroepen van Docker. Niet al deze opties werken gegarandeerd met Azure DevOps. Controleer eerst of u een container eigenschap kunt gebruiken om hetzelfde doel te bereiken.

Zie de docker create-opdrachtreferentie en de definitie resources.containers.container in de naslaginformatie over het YAML-schema van Azure DevOps voor meer informatie.

Herbruikbare containerdefinitie

Het volgende voorbeeld definieert de containers in de resources sectie en verwijst vervolgens naar de containers met hun toegewezen aliassen. Het jobs trefwoord wordt expliciet vermeld voor duidelijkheid.

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

Service-eindpunten

U kunt containers in andere registers hosten dan openbare Docker Hub. Als u een installatiekopie in Azure Container Registry of een ander privécontainerregister wilt hosten, inclusief een privé Docker Hub-register, voegt u een serviceverbinding toe om toegang te krijgen tot het register. Vervolgens kunt u verwijzen naar het eindpunt in de containerdefinitie.

Privé-Docker Hub-verbinding:

container:
  image: registry:ubuntu1804
  endpoint: private_dockerhub_connection

Azure Container Registry-verbinding

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

Notitie

Azure Pipelines kan geen serviceverbinding instellen voor Amazon Elastic Container Registry (ECR), omdat Voor Amazon ECR andere clienthulpprogramma's nodig zijn om AWS-referenties te converteren naar iets dat Docker kan gebruiken om te verifiëren.

Niet-glibc-containers

De Azure Pipelines-agent levert een kopie van Node.js, die nodig is om taken en scripts uit te voeren. Zie door Microsoft gehoste agents voor meer informatie over de versie van Node.js voor een gehoste agent.

De versie van Node.js compileert op basis van de C-runtime die wordt gebruikt in de gehoste cloud, meestal glibc. Sommige Linux-varianten gebruiken andere C-runtimes. Alpine Linux gebruikt bijvoorbeeld musl.

Als u een container wilt gebruiken die niet op glibc is gebaseerd, moet u ervoor zorgen dat u het volgende doet:

  • Lever uw eigen exemplaar van Node.js.
  • Voeg een label toe aan de afbeelding die de agent vertelt waar de Node.js binair bestand moet worden gevonden.
  • Geef andere afhankelijkheden op die afhankelijk zijn van Azure Pipelines: bash, sudo, whichen groupadd.

Lever je eigen Node.js

Als u een container gebruikt die niet op glibc gebaseerd is, bent u verantwoordelijk voor het toevoegen van een Node.js-binaire aan uw container. Node.js 18 is een veilige keuze. Begin met de node:18-alpine afbeelding.

Vertel de agent over Node.js

De agent leest het containerlabel "com.azure.dev.pipelines.handler.node.path". Als dit label bestaat, moet dit het pad naar het binaire Node.js zijn.

Voeg bijvoorbeeld in een image op basis van node:18-alpine de volgende regel toe aan uw Dockerfile:

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

Vereiste pakketten toevoegen

Azure Pipelines gaat ervan uit dat een op Bash gebaseerd systeem met algemene beheerpakketten is geïnstalleerd. Alpine Linux wordt met name niet geleverd met een aantal van de benodigde pakketten. Installeer bash, sudoen shadow om de basisbehoeften te dekken.

RUN apk add bash sudo shadow

Als u afhankelijk bent van in-box- of Marketplace-taken, moet u ook de binaire bestanden verstrekken die daarvoor nodig zijn.

Volledig Dockerfile-voorbeeld

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" ]

Gerelateerde inhoud