Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
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иgroupaddAzure 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" ]