Zadania kontenera w potokach YAML

Azure DevOps Services | Azure DevOps Server 2022 — Azure DevOps Server 2019

W tym artykule opisano zadania kontenera w usłudze Azure Pipelines.

Domyślnie zadania usługi Azure Pipelines są uruchamiane bezpośrednio na maszynach hosta, na których jest zainstalowany agent. Zadania hostowanego agenta są wygodne, wymagają niewielkiej początkowej konfiguracji i infrastruktury do utrzymania i są dobrze dopasowane do podstawowych projektów.

Jeśli chcesz mieć większą kontrolę nad kontekstem zadania, możesz zdefiniować i uruchomić zadania w kontenerach. Kontenery to uproszczona abstrakcja systemu operacyjnego hosta, która zapewnia izolację od hosta. Po uruchomieniu zadań w kontenerach można wybrać dokładne wersje systemów operacyjnych, narzędzi i zależności wymaganych przez kompilację.

Agenci systemów Linux i Windows mogą uruchamiać zadania potoku bezpośrednio na hoście lub w kontenerach. Zadania kontenera nie są dostępne w systemie macOS.

W przypadku zadania kontenera agent najpierw pobiera i uruchamia kontener. Następnie każdy krok zadania jest uruchamiany wewnątrz kontenera.

Jeśli potrzebujesz szczegółowej kontroli na poziomie poszczególnych kroków kompilacji, cele kroków umożliwiają wybranie kontenera lub hosta dla każdego kroku.

Wymagania wstępne

• Użyj potoku YAML. Potoki klasyczne nie obsługują zadań kontenera.
• Użyj hostowanego agenta systemu Windows lub Ubuntu. Tylko windows-* agenci obsługują ubuntu-* uruchamianie kontenerów. Agenci macos-* nie obsługują uruchomionych kontenerów.
• Agent jest skonfigurowany dla zadań kontenera.
  • Agenci systemu Windows i Linux muszą mieć zainstalowaną platformę Docker i muszą mieć uprawnienia dostępu do demona platformy Docker.
  • Kontenery nie są obsługiwane, gdy agent jest już uruchomiony w kontenerze. Nie można mieć zagnieżdżonych kontenerów.

Dodatkowe wymagania dotyczące kontenera

Linux

Kontenery oparte na systemie Linux mają następujące wymagania. Aby uzyskać obejścia, zobacz Kontenery oparte na protokole Nonglibc.

• Zainstalowano powłokę Bash
• Biblioteka GNU C (glibc) oparta na
• Nie ENTRYPOINT
• Zapewnianie USER dostępu do groupadd i innych uprzywilejowanych poleceń bez użycia sudo
• Można uruchomić Node.js, które udostępnia agent

  Uwaga

  Node.js muszą być wstępnie zainstalowane dla kontenerów systemu Linux na hostach systemu Windows.

Niektóre kontenery usunięte dostępne w usłudze Docker Hub, zwłaszcza kontenery oparte na systemie Alpine Linux, nie spełniają tych wymagań. Kontenery z kontenerem ENTRYPOINT mogą nie działać, ponieważ usługa Azure Pipelines docker create i docker exec oczekuje, że kontener jest zawsze uruchomiony.

Windows

Kontenery systemu Windows muszą spełniać następujące wymagania:

• Windows Server w wersji 1803 lub nowszej
• Pasujące wersje hosta i jądra kontenera
• Można uruchomić Node.js

  Uwaga

  Podstawowy kontener systemu Windows Nano Server nie ma wymaganych zależności do uruchomienia Node.js.

Przykłady pojedynczych zadań

W poniższych przykładach zdefiniowano kontener systemu Windows lub Linux dla pojedynczego zadania.

Linux

Poniższy prosty przykład definiuje kontener systemu Linux:

pool:
  vmImage: 'ubuntu-latest'

container: ubuntu:18.04

steps:
- script: printenv

Powyższy przykład informuje system o pobraniu ubuntu obrazu oznakowanego 18.04 z usługi Docker Hub , a następnie uruchomieniu kontenera. Polecenie printenv jest uruchamiane wewnątrz kontenera ubuntu:18.04 .

Windows

W poniższym przykładzie zdefiniowano kontener systemu Windows:

pool:
  vmImage: 'windows-2019'

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

steps:
- script: set

W przypadku systemu Windows wersja jądra hosta i kontenera musi być zgodna. Ponieważ w poprzednim przykładzie użyto obrazu hosta systemu Windows 2019, używa 2019 on tagu dla kontenera.

Wiele zadań

Za pomocą kontenerów można uruchomić ten sam krok w wielu zadaniach. Poniższy przykład uruchamia ten sam krok w wielu wersjach systemu Ubuntu Linux. Nie musisz wspominać o słowie jobs kluczowym, ponieważ zdefiniowano tylko jedno zadanie.

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

Wiele zadań z pulami agentów na jednym hoście agenta

Zadanie kontenera używa pliku konfiguracji platformy Docker podstawowego agenta hosta do autoryzacji rejestru obrazów. Ten plik wy wylogował się na końcu inicjowania kontenera rejestru platformy Docker. Ściąganie obrazu rejestru dla kolejnych zadań kontenera może zostać odrzucone, unauthorized authentication ponieważ inne zadanie uruchomione równolegle już wylogowuje plik konfiguracji platformy Docker.

Rozwiązaniem jest ustawienie zmiennej środowiskowej platformy DOCKER_CONFIG Docker specyficznej dla każdej puli agentów uruchomionej na hostowanym agencie. Wyeksportuj DOCKER_CONFIG skrypt runsvc.sh każdej puli agentów w następujący sposób:

export DOCKER_CONFIG=./.docker

Opcje uruchamiania

Możesz określić options , aby kontrolować uruchamianie kontenera, jak w poniższym przykładzie:

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

steps:
- script: echo hello

Uruchomienie docker create --help umożliwia wyświetlenie listy opcji, które można przekazać do wywołania platformy Docker. Nie wszystkie te opcje są gwarantowane do pracy z usługą Azure DevOps. Najpierw sprawdź, czy możesz użyć container właściwości, aby osiągnąć ten sam cel.

Aby uzyskać więcej informacji, zobacz dokumentację polecenia docker create i definicję resources.containers.container w dokumentacji schematu YAML usługi Azure DevOps.

Definicja kontenera wielokrotnego użytku

Poniższy przykład definiuje kontenery w resources sekcji, a następnie odwołuje się do nich za pomocą przypisanych aliasów. Słowo jobs kluczowe jest jawnie wymienione w celu uzyskania jasności.

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

Punkty końcowe usługi

Kontenery można hostować w innych rejestrach niż w publicznej usłudze Docker Hub. Aby hostować obraz w usłudze Azure Container Registry lub innym prywatnym rejestrze kontenerów, w tym prywatnym rejestrze usługi Docker Hub, dodaj połączenie usługi w celu uzyskania dostępu do rejestru. Następnie możesz odwołać się do punktu końcowego w definicji kontenera.

Prywatne połączenie z usługą Docker Hub:

container:
  image: registry:ubuntu1804
  endpoint: private_dockerhub_connection

Połączenie usługi Azure Container Registry:

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

Uwaga

Usługa Azure Pipelines nie może skonfigurować połączenia usługi dla usługi Amazon Elastic Container Registry (ECR), ponieważ usługa Amazon ECR wymaga innych narzędzi klienckich do konwertowania poświadczeń platformy AWS na coś, czego platforma Docker może używać do uwierzytelniania.

Kontenery oparte na języku nonglibc

Agent usługi Azure Pipelines dostarcza kopię Node.js, która jest wymagana do uruchamiania zadań i skryptów. Aby dowiedzieć się, w której wersji Node.js dla hostowanego agenta, zobacz Agenci hostowani przez firmę Microsoft.

Wersja Node.js kompiluje się względem środowiska uruchomieniowego języka C używanego w chmurze hostowanej, zazwyczaj glibc. Niektóre warianty systemu Linux używają innych środowisk uruchomieniowych języka C. Na przykład alpine Linux używa musl.

Jeśli chcesz użyć kontenera opartego na formacie nonglibc, musisz:

• Podaj własną kopię Node.js.
• Dodaj etykietę do obrazu z informacją o tym, gdzie agent znajdzie Node.js binarny.
• Podaj inne zależności, od których zależy usługa Azure Pipelines: bash, , sudowhichi groupadd.

Podaj własne Node.js

Jeśli używasz kontenera opartego na języku nonglibc, odpowiadasz za dodanie pliku binarnego Node do kontenera. Node.js 18 jest bezpiecznym wyborem. Zacznij od node:18-alpine obrazu.

Poinformuj agenta o Node.js

Agent odczytuje etykietę "com.azure.dev.pipelines.handler.node.path"kontenera . Jeśli ta etykieta istnieje, musi być ścieżką do pliku binarnego Node.js.

Na przykład na obrazie opartym na node:18-alpinepliku dodaj następujący wiersz do pliku Dockerfile:

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

Dodawanie wymaganych pakietów

Usługa Azure Pipelines zakłada, że system oparty na powłoce Bash z zainstalowanymi typowymi pakietami administracyjnymi. Alpine Linux w szczególności nie zawiera kilku potrzebnych pakietów. Zainstaluj program bash, sudoi shadow , aby uwzględnić podstawowe potrzeby.

RUN apk add bash sudo shadow

Jeśli zależysz od dowolnych zadań wbudowanych lub w witrynie Marketplace, podaj również wymagane pliki binarne.

Pełny przykład pliku Dockerfile

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

Powiązana zawartość

• Zadania usługi Azure Pipelines
• Agenci usługi Azure Pipelines
• YaML schema resources.containers.container definition