Определение заданий контейнеров (YAML)
Azure DevOps Services | Azure DevOps Server 2022 — Azure DevOps Server 2019
По умолчанию задания выполняются на хост-компьютере, где установлен агент. Это удобно и обычно хорошо подходит для проектов, которые только начинают внедрять Azure Pipelines. С течением времени вы можете найти, что требуется больше контроля над контекстом, в котором выполняются задачи. Конвейеры YAML предлагают задания контейнера для этого уровня управления.
В агентах Linux и Windows задания могут выполняться на узле или в контейнере. (В macOS и Red Hat Enterprise Linux 6 задания контейнеров недоступны.) Контейнеры обеспечивают изоляцию от узла и позволяют закреплять определенные версии средств и зависимостей. Для обслуживания заданий узлов требуется менее начальная настройка и инфраструктура.
Контейнеры предлагают упрощенную абстракцию по операционной системе узла. Вы можете выбрать точные версии операционных систем, инструментов и зависимостей, необходимых для сборки. При указании контейнера в конвейере агент сначала получит и запустите контейнер. Затем каждый шаг задания будет выполняться внутри контейнера. У вас нет вложенных контейнеров. Контейнеры не поддерживаются, если агент уже работает в контейнере.
Если вам нужен точный контроль на отдельном уровне шага, целевые объекты шагов позволяют выбрать контейнер или узел для каждого шага.
Требования
Контейнеры под управлением 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 в контейнер.
Узел 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
Если вы зависите от любых задач 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
Обратная связь
https://aka.ms/ContentUserFeedback.
Ожидается в ближайшее время: в течение 2024 года мы постепенно откажемся от GitHub Issues как механизма обратной связи для контента и заменим его новой системой обратной связи. Дополнительные сведения см. в разделеОтправить и просмотреть отзыв по