Поделиться через


Задания контейнеров в конвейерах YAML

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

В этой статье объясняются контейнерные задания в Azure Pipelines. Контейнеры являются упрощенными абстракциями из операционной системы узла, которые предоставляют все необходимые элементы для запуска задания в определенной среде.

По умолчанию задания Azure Pipelines выполняются непосредственно на агентах , установленных на хост-компьютерах. Размещенные задания агента удобны, требуют мало начальной настройки или обслуживания инфраструктуры и хорошо подходят для базовых проектов. Чтобы получить точные версии операционных систем, инструментов и зависимостей, можно определить и запустить задания конвейера в контейнерах.

Для задания контейнера агент сначала извлекает и запускает контейнер, а затем выполняет каждый шаг задания внутри контейнера. Если вам нужен более подробный контроль отдельных шагов сборки, можно использовать целевые объекты шагов для выбора контейнера или узла для каждого шага.

Требования к заданиям контейнеров

  • Конвейер на основе YAML. Классические конвейеры не поддерживают задания контейнеров.
  • Размещенный агент Windows или Ubuntu. Агенты MacOS не поддерживают контейнеры. Сведения об использовании агентов Linux, отличных от Ubuntu, см. в разделе контейнеров на основе Nonglibc.
  • Docker, установленный на агенте, с разрешением на доступ к управляющей программе Docker.
  • Агент, работающий непосредственно на узле, еще не внутри контейнера. Вложенные контейнеры не поддерживаются.

Контейнеры на основе Linux также имеют следующие требования:

  • Установлен Bash.
  • Библиотека GNU C (glibc)на основе. Для контейнеров nonglibc требуется добавленная настройка. Дополнительные сведения см. в разделе "Контейнеры на основе Nonglibc".
  • Нет ENTRYPOINT. Контейнеры с ENTRYPOINT неработает, так как docker exec ожидает, что контейнер всегда выполняется.
  • USER предоставляется доступ к groupadd и другим привилегированным командам без использования sudo.
  • Возможность запуска Node.js, которую предоставляет агент.

    Примечание.

    Node.js необходимо предварительно установить для контейнеров Linux на узлах Windows.

Некоторые облегченнные контейнеры, доступные в Docker Hub, особенно контейнеры на базе Alpine Linux, не удовлетворяют этим требованиям. Дополнительные сведения см. в разделе "Контейнеры на основе Nonglibc".

Одно задание

В следующем примере определяется контейнер одно заданий Windows или Linux.

В этом примере система сообщает системе получить изображение, ubuntu помеченное 18.04 из Docker Hub , а затем запустить контейнер. Команда printenv выполняется внутри ubuntu:18.04 контейнера.

pool:
  vmImage: 'ubuntu-latest'

container: ubuntu:18.04

steps:
- script: printenv

Несколько заданий

Контейнеры можно использовать для выполнения одного шага в нескольких заданиях. В следующем примере выполняется один и тот же шаг в нескольких версиях Ubuntu Linux. Вам не нужно использовать ключевое jobs слово, так как определено только одно задание.

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

Несколько заданий на одном узле агента

Задание контейнера использует файл конфигурации Docker базового агента узла для авторизации реестра образов. Этот файл выходит из системы в конце инициализации контейнера реестра Docker.

Извлечение образа реестра для заданий контейнеров может быть запрещено для несанкционированной проверки подлинности, если другое задание, выполняемое параллельно на агенте, уже выйдите из файла конфигурации Docker. Решением является установка переменной среды Docker, вызываемой DOCKER_CONFIG для каждого пула агентов, работающего в размещенном агенте.

DOCKER_CONFIG Экспортируйте сценарий runsvc.sh каждого пула агентов следующим образом:

export DOCKER_CONFIG=./.docker

Параметры запуска

Свойство можно использовать options для указания параметров запуска контейнера.

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

steps:
- script: echo hello

Выполните команду docker create --help , чтобы получить список параметров, которые можно передать в вызов Docker. Не все эти параметры гарантированно работают с Azure Pipelines. Сначала проверьте, можно ли использовать container свойство для той же цели.

Дополнительные сведения см. в справочнике по команде docker create и определению resources.container.container в справочнике по схеме YAML для Azure Pipelines.

Определение контейнера для повторного использования

Следующий пример YAML определяет контейнеры в resources разделе, а затем ссылается на них по назначенным псевдонимам. Ключевое jobs слово используется для ясности.

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

Конечные точки служб

Контейнеры можно размещать в реестрах, отличных от общедоступного Центра Docker. Чтобы разместить образ в Реестр контейнеров Azure или другом частном реестре контейнеров, включая частный реестр Docker Hub, добавьте подключение к службе для доступа к реестру. Затем можно ссылаться на конечную точку в определении контейнера.

Частное подключение Docker Hub:

container:
  image: registry:ubuntu1804
  endpoint: private_dockerhub_connection

Подключение к реестру контейнеров Azure:

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

Примечание.

Azure Pipelines не может настроить подключение к службе для реестра контейнеров Amazon Elastic Container Registry (ECR), так как Amazon ECR требует других клиентских средств для преобразования учетных данных Amazon Web Services (AWS), которые можно использовать для проверки подлинности Docker.

Контейнеры на основе nonglibc

Размещенные агенты Azure Pipelines предоставляют Node.js, необходимые для выполнения задач и сценариев. Версия Node.js компилируется в среду выполнения C, используемую в размещенном облаке, обычно glibc. Некоторые варианты Linux используют другие среды выполнения C. Например, в Alpine Linux используется musl. Дополнительные сведения см. в разделе "Размещенные корпорацией Майкрософт агенты".

Если вы хотите использовать контейнер на основе nonglibc в конвейере, необходимо:

  • Предоставьте собственную копию Node.js.
  • Добавьте метку в изображение, указывающее на расположение Node.js двоичного файла.
  • bashУкажите зависимости , sudowhichи groupadd Azure Pipelines.

Предоставьте свой собственный Node.js

Если вы используете контейнер на основе nonglibc, необходимо добавить двоичный файл Node в контейнер. Node.js 18 является безопасным выбором. Начните с node:18-alpine изображения.

Перенаправление агента в Node.js

Агент считывает метку "com.azure.dev.pipelines.handler.node.path"контейнера. Если эта метка существует, это должен быть путь к Node.js двоичному файлу.

Например, в образ на основе node:18-alpine добавьте следующую строку в ваш Dockerfile:

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

Добавление необходимых пакетов

Azure Pipelines требует, чтобы система на основе Bash устанавливала общие административные пакеты. В Alpine Linux нет нескольких необходимых пакетов. Установите bash, sudoи shadow для покрытия основных потребностей.

RUN apk add bash sudo shadow

Если вы зависите от всех встроенных задач или задач Marketplace, укажите необходимые двоичные файлы.

Полный пример 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" ]