Udostępnij przez


Zadania kontenerowe w potokach YAML

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

W tym artykule opisano zadania kontenera w usłudze Azure Pipelines. Kontenery to lekkie abstrakcje z systemu operacyjnego hosta, które zapewniają wszystkie elementy niezbędne do uruchomienia zadania w określonym środowisku.

Domyślnie zadania usługi Azure Pipelines są uruchamiane bezpośrednio na agentach zainstalowanych na maszynach hosta. Zadania hostowanego agenta są wygodne, wymagają niewielkiej początkowej konfiguracji lub konserwacji infrastruktury i są odpowiednie dla podstawowych projektów. Aby uzyskać większą kontrolę nad kontekstem zadania, możesz zdefiniować i uruchomić zadania potoku w kontenerach, aby uzyskać dokładne wersje systemów operacyjnych, narzędzi i zależności.

W przypadku zadania kontenera agent najpierw pobiera i uruchamia kontener, a następnie uruchamia każdy krok zadania wewnątrz kontenera. Jeśli potrzebujesz bardziej szczegółowej kontroli poszczególnych kroków kompilacji, możesz użyć elementów docelowych kroków , aby wybrać kontener lub host dla każdego kroku.

Wymagania dotyczące zadań kontenera

  • Potok oparty na języku YAML. Klasyczne potoki nie obsługują zadań kontenera.
  • Agent hostowany w systemie Windows lub Ubuntu. Agenci systemu MacOS nie obsługują kontenerów. Aby użyć agentów innych niż Ubuntu Linux, zobacz Kontenery oparte na protokole Nonglibc.
  • Platforma Docker zainstalowana na agencie z uprawnieniami dostępu do demona platformy Docker.
  • Agent uruchomiony bezpośrednio na hoście, jeszcze nie wewnątrz kontenera. Zagnieżdżone kontenery nie są obsługiwane.

Kontenery oparte na systemie Linux mają również następujące wymagania:

  • Zainstalowano powłokę Bash.
  • Biblioteka GNU C (glibc)-based. Kontenery nonglibc wymagają dodania konfiguracji. Aby uzyskać więcej informacji, zobacz Kontenery oparte na protokole Nonglibc.
  • Nie ENTRYPOINT. Kontenery z kontenerem ENTRYPOINT mogą nie działać, ponieważ narzędzie docker exec oczekuje, że kontener będzie zawsze uruchomiony.
  • USER zapewniany z dostępem do groupadd innych uprzywilejowanych poleceń bez używania polecenia sudo.
  • Możliwość uruchamiania Node.js, który zapewnia 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ń. Aby uzyskać więcej informacji, zobacz Kontenery oparte na protokole Nonglibc.

Jedno zadanie

W poniższym przykładzie zdefiniowano kontener pojedynczego zadania systemu Windows lub Linux.

Ten 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 .

pool:
  vmImage: 'ubuntu-latest'

container: ubuntu:18.04

steps:
- script: printenv

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 używać słowa kluczowego jobs , 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ń na jednym hoście agenta

Zadanie kontenera korzysta z pliku konfiguracji Dockera na podstawowym agencie hosta do autoryzacji rejestru obrazów. Ten plik kończy działanie po zakończeniu inicjalizacji kontenera rejestru Docker.

Ściąganie obrazu rejestru dla zadań kontenera może zostać odrzucone w przypadku nieautoryzowanego uwierzytelniania, jeśli inne zadanie uruchomione równolegle w agencie już wylogowało plik konfiguracji platformy Docker. Rozwiązaniem jest ustawienie zmiennej środowiskowej platformy Docker wywoływanej DOCKER_CONFIG dla każdej puli agentów uruchomionej na hostowanym agencie.

Wyeksportuj DOCKER_CONFIG w skrypcie runsvc.sh każdej puli agentów w następujący sposób:

export DOCKER_CONFIG=./.docker

Opcje uruchamiania

Za pomocą właściwości można określić opcje uruchamiania options kontenera.

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

steps:
- script: echo hello

Uruchom polecenie , docker create --help aby uzyskać listę opcji, które można przekazać do wywołania platformy Docker. Nie wszystkie te opcje są gwarantowane do pracy z usługą Azure Pipelines. Najpierw sprawdź, czy możesz użyć container właściwości w tym samym celu.

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

Definicja kontenera wielokrotnego użytku

Poniższy przykład YAML definiuje kontenery w resources sekcji, a następnie odwołuje się do nich za pomocą przypisanych aliasów. Słowo jobs kluczowe jest używane do 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 rejestrach innych niż publiczna usługa 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 z usługą dla usługi Amazon Elastic Container Registry (ECR), ponieważ usługa Amazon ECR wymaga innych narzędzi klienckich do konwertowania poświadczeń usług Amazon Web Services (AWS) na potrzeby uwierzytelniania platformy Docker.

Kontenery niezależne od glibc

Hostowani agenci usługi Azure Pipelines dostarczają Node.js, który jest wymagany do uruchamiania zadań i skryptów. Wersja Node.js jest kompilowana 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 polecenia musl. Aby uzyskać więcej informacji, zobacz Agenci hostowani przez firmę Microsoft.

Jeśli chcesz użyć kontenera opartego na języku nonglibc w potoku, musisz:

  • Podaj własną kopię Node.js.
  • Dodaj etykietę do obrazu wskazującą lokalizację pliku binarnego Node.js.
  • bashPodaj zależności , sudo, whichi groupadd Azure Pipelines.

Użyj własnego Node.js

Jeśli używasz kontenera opartego na języku nonglibc, musisz dodać plik binarny Node do kontenera. Node.js 18 jest bezpiecznym wyborem. Zacznij od node:18-alpine obrazu.

Kierowanie agenta do 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 w obrazie opartym na node:18-alpine, 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 wymaga, aby system oparty na powłoce Bash miał zainstalowane typowe pakiety administracyjne. Alpine Linux nie ma kilku wymaganych pakietów. Zainstaluj program bash, sudoi shadow , aby uwzględnić podstawowe potrzeby.

RUN apk add bash sudo shadow

Jeśli zależysz od jakichkolwiek wbudowanych zadań lub witryny 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" ]