Определение заданий контейнеров (YAML)

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

По умолчанию задания выполняются на хост-компьютере, где установлен агент. Это удобно и обычно хорошо подходит для проектов, которые только начинают внедрять Azure Pipelines. С течением времени вы можете найти, что требуется больше контроля над контекстом, в котором выполняются задачи. Конвейеры YAML предлагают задания контейнера для этого уровня управления.

В агентах Linux и Windows задания могут выполняться на узле или в контейнере. (В macOS и Red Hat Enterprise Linux 6 задания контейнеров недоступны.) Контейнеры обеспечивают изоляцию от узла и позволяют закреплять определенные версии средств и зависимостей. Для обслуживания заданий узлов требуется менее начальная настройка и инфраструктура.

Контейнеры предлагают упрощенную абстракцию по операционной системе узла. Вы можете выбрать точные версии операционных систем, инструментов и зависимостей, необходимых для сборки. При указании контейнера в конвейере агент сначала получит и запустите контейнер. Затем каждый шаг задания будет выполняться внутри контейнера. У вас нет вложенных контейнеров. Контейнеры не поддерживаются, если агент уже работает в контейнере.

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

Requirements

Контейнеры под управлением Linux

Для системы Azure Pipelines требуется несколько вещей в контейнерах под управлением Linux:

• Bash
• на основе glibc
• Может запускать Node.js (который предоставляет агент)
• Не определяет ENTRYPOINT
• USER имеет доступ к groupadd и другим командам привилегий без sudo

И на узле агента:

• Убедитесь, что Docker установлен
• Агент должен иметь разрешение на доступ к управляющей программе Docker

Убедитесь, что контейнер имеет все эти средства. Некоторые из контейнеров, доступных в Docker Hub, особенно на основе Alpine Linux, не соответствуют этим минимальным требованиям. Контейнеры с ENTRYPOINT ней могут работать, так как Azure Pipelines будет ожидающим контейнером и docker exec рядом команд, которые ожидают, что контейнер всегда docker create работает и работает.

Примечание.

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

Контейнеры Windows

Azure Pipelines также может запускать контейнеры Windows. Требуется Windows Server версии 1803 или более поздней. Необходимо установить Docker. Убедитесь, что агент конвейеров имеет разрешение на доступ к управляющей программе Docker.

Контейнер Windows должен поддерживать запуск Node.js. Базовый контейнер Windows Nano Server отсутствует зависимости, необходимые для запуска Узла.

Размещенные агенты

ubuntu-* Только windows-2019 образы поддерживают выполнение контейнеров. Образ macOS не поддерживает выполнение контейнеров.

Одно задание

Вот простой пример:

pool:
  vmImage: 'ubuntu-latest'

container: ubuntu:18.04

steps:
- script: printenv

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

Пример Windows:

pool:
  vmImage: 'windows-2019'

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

steps:
- script: set

Примечание.

Для Windows требуется, чтобы версия ядра узла и контейнера соответствовала. Так как в этом примере используется образ Windows 2019, мы будем использовать 2019 тег для контейнера.

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

Контейнеры также полезны для выполнения одних и тех же шагов в нескольких заданиях. В следующем примере те же действия выполняются в нескольких версиях 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 Hub. Чтобы разместить образ в Реестр контейнеров Azure или другом частном реестре контейнеров (включая частный реестр Docker Hub), добавьте подключение службы к частному реестру. Затем вы можете ссылаться на него в спецификации контейнера:

container:
  image: registry:ubuntu1804
  endpoint: private_dockerhub_connection

steps:
- script: echo hello

or

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

steps:
- script: echo hello

Другие реестры контейнеров также могут работать. Amazon ECR в настоящее время не работает, так как существуют другие клиентские средства, необходимые для преобразования учетных данных AWS в то, что Docker может использовать для проверки подлинности.

Примечание.

Сборка Red Hat Enterprise Linux 6 агента не будет запускать задание контейнера. Выберите другой вкус Linux, например Red Hat Enterprise Linux 7 или более поздней версии.

Параметры

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

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

steps:
- script: echo hello

При выполнении docker create --help вы получите список параметров, которые можно передать в вызов Docker. Не все эти параметры предоставляются для работы с Azure DevOps. Сначала проверьте, можно ли использовать свойство контейнера для выполнения той же цели. Дополнительные сведения смresources.containers.container. в схеме YAML и справочнике по командамdocker create.

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

В следующем примере контейнеры определены в разделе ресурсов. Затем каждый контейнер ссылается позже, ссылаясь на его назначенный псевдоним. (Здесь мы явно перечислим список 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

Контейнеры, не основанные на glibc

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

Если вы хотите использовать контейнер, отличный от glibc, в качестве контейнера заданий вам потребуется упорядочить несколько вещей самостоятельно. Сначала необходимо указать собственную копию Node.js. Во-вторых, необходимо добавить метку в образ, указывая агенту, где найти двоичный файл Node.js. Наконец, акции Alpine не приходят с другими зависимостями, от которых зависит Azure Pipelines: bash, sudo, которые и группируются.

Создание собственного node.js

Вы несете ответственность за добавление двоичного файла Node в контейнер. Узел 14 — это безопасный выбор. Вы можете начать с node:14-alpine изображения.

Сообщите агенту о Node.js

Агент считывает метку контейнера com.azure.dev.pipelines.handler.node.path. Если эта метка существует, это должен быть путь к двоичному файлу Node.js. Например, на основе изображения node:10-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

Если вы зависите от любых задач in-box или Marketplace, вам также потребуется предоставить необходимые двоичные файлы.

Полный пример Dockerfile

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

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

Задание контейнера использует базовый агент узла Docker config.json для авторизации реестра образов, который выходит из системы в конце инициализации контейнера реестра Docker. Последующий образ реестра вытягивает авторизацию может быть отклонен для "несанкционированной проверки подлинности", так как файл Docker config.json, зарегистрированный в системе для проверки подлинности, уже был удален одним из других заданий контейнеров, выполняемых параллельно.

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

#insert anything to set up env when running as a service
export DOCKER_CONFIG=./.docker