Использование пакетной службы Azure для запуска рабочих нагрузок контейнеров

Пакетная служба Azure позволяет выполнять и масштабировать большие количества заданий в пакетной обработке данных в Azure. Такие задачи могут выполняться напрямую на виртуальных машинах (узлах) в пуле пакетной службы. Кроме того, пул пакетной службы можно настроить для выполнения задач в совместимых с Docker контейнерах на узлах. В этой статье показано, как создать пул вычислительных узлов, которые поддерживают выполнение задач контейнера, и как выполнять эти задачи в пуле.

В приведенных здесь примерах кода используются пакетные пакеты .NET и Python SDK. Также для создания пулов пакетной службы с включенными контейнерами и выполнения задач в контейнере можно использовать другие пакеты SDK пакетной службы и средства, включая портал Azure.

Зачем нужны контейнеры?

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

Необходимые компоненты

Вам нужно иметь представление о контейнере, а также знать, как создать пул пакетной службы и задание.

• Версии SDK. Пакеты SDK для пакетной службы поддерживают образы контейнеров в таких версиях:

  • REST API пакетной службы версии 2017-09-01.6.0;
  • пакет SDK для .NET пакетной службы версии 8.0.0;
  • пакет SDK для Python пакетной службы версии 4.0;
  • пакет SDK для Java пакетной службы версии 3.0;
  • пакет SDK для Node.js пакетной службы версии 3.0.

• Учетные записи. В своей подписке Azure необходимо создать учетную запись пакетной службы и при необходимости создать учетную запись службы хранилища Azure.

• Поддерживаемый образ виртуальной машины: контейнеры поддерживаются только в пулах, созданных с помощью конфигурации виртуальной машины, из поддерживаемого образа (указанного в следующем разделе). Если вы предоставляете пользовательский образ, ознакомьтесь с рекомендациями в следующем разделе и требованиями к использованию управляемого образа для создания настраиваемого пула образов.

В настоящее время containerConfiguration требуется Type передать свойство, а поддерживаемые значения: ContainerType.DockerCompatible и ContainerType.CriCompatible.

Помните о следующих ограничениях:

• Пакетная служба обеспечивает поддержку удаленного прямого доступа к памяти (RDMA) только для контейнеров, работающих в пулах Linux.
• Для рабочих нагрузок контейнеров Windows следует выбрать размер многоядерных виртуальных машин для пула.

Поддерживаемые образы виртуальных машин

Чтобы создать пул вычислительных узлов виртуальной машины для рабочих нагрузок контейнера, используйте один из поддерживаемых образов Windows или Linux, указанных ниже. Дополнительные сведения об образах Marketplace, совместимых с пакетной службой, см. в разделе Список образов виртуальных машин.

Поддержка Windows

Пакетная служба поддерживает образы Windows Server, назначения которых поддерживают контейнеры. API для перечисления всех поддерживаемых образов в пакетной службе обозначает DockerCompatible возможность, если образ поддерживает контейнеры Docker. Пакетная служба позволяет, но не поддерживает напрямую изображения, опубликованные Mirantis с возможностью, как DockerCompatibleуказано. Эти образы могут быть развернуты только в учетной записи пакетной службы распределения пула подписок пользователей.

Вы также можете создать пользовательский образ для включения функциональных возможностей контейнеров в Windows.

Поддержка Linux

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

• Издатель: microsoft-dsvm
  • Предложение: ubuntu-hpc
• Издатель: almalinux
  • Предложение: 8-hpc-gen1
  • Предложение: 8-hpc-gen2

Альтернативные параметры изображения

В настоящее время существуют другие образы, опубликованные с помощью microsoft-azure-batch таких рабочих нагрузок контейнеров:

• Издатель: microsoft-azure-batch
  • Предложение: ubuntu-server-container
  • Предложение: ubuntu-server-container-rdma (для использования исключительно на номерах SKU виртуальных машин с Infiniband)

Примечания.

Корень данных Docker из указанных выше изображений находится в разных местах:

• Для образа HPC или microsoft-dsvm (предложение: ubuntu-hpcи т. д.) корневой каталог данных Docker не изменяется из значения по умолчанию Docker, который является /var/lib/docker в Linux и C:\ProgramData\Docker в Windows. Эти папки находятся на диске ОС.

Для опубликованных образов, отличных от пакетной службы, диск ОС может быстро заполниться по мере скачивания образов контейнеров.

Потенциальные решения для клиентов

Измените корневой каталог данных Docker в задаче запуска при создании пула в BatchExplorer. Ниже приведен пример команды Start Task:

1)  sudo systemctl stop docker
2)  sudo vi /lib/systemd/system/docker.service
    +++
    FROM:
    ExecStart=/usr/bin/docker daemon -H fd://
    TO:
    ExecStart=/usr/bin/docker daemon -g /new/path/docker -H fd://
    +++
3)  sudo systemctl daemon-reload
4)  sudo systemctl start docker

Эти образы поддерживаются только в пулах пакетной службы Azure и предназначены для выполнения контейнеров Docker. Они содержат следующее:

• Предустановленная среда выполнения контейнера, совместимая с Docker, Moby.
• Предварительно установленные драйверы GPU NVIDIA и среда выполнения контейнера NVIDIA для упрощения развертывания на виртуальных машинах серии N Azure.
• Образы виртуальных машин с суффиксом -rdma предварительно настроены с поддержкой размеров виртуальных машин InfiniBand RDMA. Эти образы виртуальных машин не должны использоваться с размерами виртуальных машин, которые не поддерживают InfiniBand.

Вы также можете создать пользовательские образы , совместимые с контейнерами пакетной службы, в одном из дистрибутивов Linux, совместимых с пакетной службой. Для поддержки Docker на пользовательском образе установите подходящую среду выполнения, совместимую с Docker, например версию Docker или Mirantis Container Runtime. Установка только средства, совместимого с Docker-CLI, недостаточно; Требуется среда выполнения, совместимая с подсистемой Docker.

Дополнительные рекомендации по использованию пользовательского образа Linux:

• Чтобы воспользоваться высокой производительностью GPU виртуальных машин Azure серии N для пользовательского образа, предварительно установите драйверы NVIDIA. Кроме того, необходимо установить служебную программу подсистемы Docker для GPU NVIDIA — NVIDIA Docker.
• Для доступа к сети Azure RDMA используйте размер виртуальной машины с поддержкой RDMA. Необходимые драйверы RDMA установлены в образах CentOS HPC и Ubuntu, поддерживаемых пакетной службой. Для выполнения рабочих нагрузок MPI может потребоваться дополнительная конфигурация. См. статью "Использование экземпляров RDMA или GPU" в пуле пакетной службы.

Конфигурация контейнера для пула пакетной службы

Чтобы включить пул пакетной службы для выполнения рабочих нагрузок контейнера, необходимо указать параметр ContainerConfiguration в пуле объекта VirtualMachineConfiguration. В этой статье содержатся ссылки на справочник по API пакетной службы .NET. Соответствующие параметры находятся в API Python пакетной службы.

Можно создать пул с включенным контейнером с предварительно загруженными образами контейнеров или без них, как показано в следующих примерах. Процесс извлечения (или предварительной выборки) позволяет предварительно загрузить образы контейнеров из Docker Hub или другого реестра контейнеров в Интернете. Чтобы обеспечить высокую производительность, используйте реестр контейнеров Azure в одном регионе с учетной записью пакетной службы.

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

Пул без предварительно полученных образов контейнеров

Для настройки пула с включенным контейнером без предварительно полученных контейнерных образов определите объекты ContainerConfiguration и VirtualMachineConfiguration, как показано в следующих примерах. В этих примерах используется образ ОС сервера Ubuntu для контейнерных пулов пакетной службы Azure из Marketplace.

Примечание: Версия сервера Ubuntu, используемая в примере, предназначена для целей иллюстрации. Вы можете изменить node_agent_sku_id на используемую версию.

image_ref_to_use = batch.models.ImageReference(
    publisher='microsoft-dsvm',
    offer='ubuntu-hpc',
    sku='2204',
    version='latest')

"""
Specify container configuration. This is required even though there are no prefetched images.
"""

container_conf = batch.models.ContainerConfiguration()

new_pool = batch.models.PoolAddParameter(
    id=pool_id,
    virtual_machine_configuration=batch.models.VirtualMachineConfiguration(
        image_reference=image_ref_to_use,
        container_configuration=container_conf,
        node_agent_sku_id='batch.node.ubuntu 22.04'),
    vm_size='STANDARD_D2S_V3',
    target_dedicated_nodes=1)
...

ImageReference imageReference = new ImageReference(
    publisher: "microsoft-dsvm",
    offer: "ubuntu-hpc",
    sku: "2204",
    version: "latest");

// Specify container configuration. This is required even though there are no prefetched images.
ContainerConfiguration containerConfig = new ContainerConfiguration();

// VM configuration
VirtualMachineConfiguration virtualMachineConfiguration = new VirtualMachineConfiguration(
    imageReference: imageReference,
    nodeAgentSkuId: "batch.node.ubuntu 22.04");
virtualMachineConfiguration.ContainerConfiguration = containerConfig;

// Create pool
CloudPool pool = batchClient.PoolOperations.CreatePool(
    poolId: poolId,
    targetDedicatedComputeNodes: 1,
    virtualMachineSize: "STANDARD_D2S_V3",
    virtualMachineConfiguration: virtualMachineConfiguration);

Предварительное получение образов для конфигурации контейнера

Чтобы предварительно получить образы контейнеров в пуле, добавьте список образов контейнеров (container_image_namesв Python).ContainerConfiguration

В следующем простом примере на Python показано, как предварительно загрузить стандартный образ контейнера Ubuntu из центра Docker.

image_ref_to_use = batch.models.ImageReference(
    publisher='microsoft-dsvm',
    offer='ubuntu-hpc',
    sku='2204',
    version='latest')

"""
Specify container configuration, fetching the official Ubuntu container image from Docker Hub.
"""

container_conf = batch.models.ContainerConfiguration(
    container_image_names=['ubuntu'])

new_pool = batch.models.PoolAddParameter(
    id=pool_id,
    virtual_machine_configuration=batch.models.VirtualMachineConfiguration(
        image_reference=image_ref_to_use,
        container_configuration=container_conf,
        node_agent_sku_id='batch.node.ubuntu 22.04'),
    vm_size='STANDARD_D2S_V3',
    target_dedicated_nodes=1)
...

В следующем примере на C# предполагается, что вы намерены предварительно загрузить образ TensorFlow из центра Docker. Данный пример включает задачу запуска, выполняемую на узле виртуальной машины на узлах пула. Можно запустить стартовую задачу в узле, например, для вставки файлового сервера, доступ к которому можно получить из контейнеров.

ImageReference imageReference = new ImageReference(
    publisher: "microsoft-dsvm",
    offer: "ubuntu-hpc",
    sku: "2204",
    version: "latest");

ContainerRegistry containerRegistry = new ContainerRegistry(
    registryServer: "https://hub.docker.com",
    identityReference: new ComputeNodeIdentityReference() { ResourceId = "/subscriptions/SUB/resourceGroups/RG/providers/Microsoft.ManagedIdentity/userAssignedIdentities/identity-name" }
);

// Specify container configuration, prefetching Docker images
ContainerConfiguration containerConfig = new ContainerConfiguration();
containerConfig.ContainerImageNames = new List<string> { "tensorflow/tensorflow:latest-gpu" };
containerConfig.ContainerRegistries = new List<ContainerRegistry> { containerRegistry };

// VM configuration
VirtualMachineConfiguration virtualMachineConfiguration = new VirtualMachineConfiguration(
    imageReference: imageReference,
    nodeAgentSkuId: "batch.node.ubuntu 22.04");
virtualMachineConfiguration.ContainerConfiguration = containerConfig;

// Set a native host command line start task
StartTask startTaskContainer = new StartTask( commandLine: "<native-host-command-line>" );

// Create pool
CloudPool pool = batchClient.PoolOperations.CreatePool(
    poolId: poolId,
    virtualMachineSize: "Standard_NC6S_V3",
    virtualMachineConfiguration: virtualMachineConfiguration);

// Start the task in the pool
pool.StartTask = startTaskContainer;
...

Предварительно полученные образы из закрытого реестра контейнеров

Можно также выполнять предварительное получение образов контейнеров путем проверки подлинности на сервере закрытого реестра контейнеров. В следующих примерах объекты ContainerConfiguration и VirtualMachineConfiguration предварительно загружают частный образ TensorFlow из частного реестра контейнеров Azure. Здесь используется такая же ссылка на образ, как и в предыдущем примере.

image_ref_to_use = batch.models.ImageReference(
    publisher='microsoft-dsvm',
    offer='ubuntu-hpc',
    sku='2204',
    version='latest')

# Specify a container registry
subscription_id = "yyyy-yyy-yyy-yyy-yyy"
resource_group_name = "TestRG"
user_assigned_identity_name = "testUMI"
resource_id = f"/subscriptions/{subscription_id}/resourceGroups/{resource_group_name}/providers/Microsoft.ManagedIdentity/userAssignedIdentities/{user_assigned_identity_name}"

container_registry = batch.models.ContainerRegistry(
        registry_server="myRegistry.azurecr.io",
        identity_reference = ComputeNodeIdentityReference(resource_id = resource_id))

# Create container configuration, prefetching Docker images from the container registry
container_conf = batch.models.ContainerConfiguration(
        container_image_names = ["myRegistry.azurecr.io/samples/myImage"],
        container_registries =[container_registry])

new_pool = batch.models.PoolAddParameter(
            id="myPool",
            virtual_machine_configuration=batch.models.VirtualMachineConfiguration(
                image_reference=image_ref_to_use,
                container_configuration=container_conf,
                node_agent_sku_id='batch.node.ubuntu 22.04'),
            vm_size='STANDARD_D2S_V3',
            target_dedicated_nodes=1)

// Specify a container registry
ContainerRegistry containerRegistry = new ContainerRegistry(
    registryServer: "myContainerRegistry.azurecr.io",
    identityReference: new ComputeNodeIdentityReference() { ResourceId = "/subscriptions/SUB/resourceGroups/RG/providers/Microsoft.ManagedIdentity/userAssignedIdentities/identity-name" }
);

// Create container configuration, prefetching Docker images from the container registry
ContainerConfiguration containerConfig = new ContainerConfiguration();
containerConfig.ContainerImageNames = new List<string> {
        "myContainerRegistry.azurecr.io/tensorflow/tensorflow:latest-gpu" };
containerConfig.ContainerRegistries = new List<ContainerRegistry> { containerRegistry } );

// VM configuration
VirtualMachineConfiguration virtualMachineConfiguration = new VirtualMachineConfiguration(
    imageReference: imageReference,
    nodeAgentSkuId: "batch.node.ubuntu 22.04");
virtualMachineConfiguration.ContainerConfiguration = containerConfig;

// Create pool
CloudPool pool = batchClient.PoolOperations.CreatePool(
    poolId: poolId,
    targetDedicatedComputeNodes: 2,
    virtualMachineSize: "Standard_NC6S_V3",
    virtualMachineConfiguration: virtualMachineConfiguration);
...

Поддержка управляемого удостоверения для Реестра контейнеров Azure

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

ContainerRegistry containerRegistry = new ContainerRegistry(
    registryServer: "myContainerRegistry.azurecr.io",
    identityReference: new ComputeNodeIdentityReference() { ResourceId = "/subscriptions/SUB/resourceGroups/RG/providers/Microsoft.ManagedIdentity/userAssignedIdentities/identity-name" }
);

// Create container configuration, prefetching Docker images from the container registry
ContainerConfiguration containerConfig = new ContainerConfiguration();
containerConfig.ContainerImageNames = new List<string> {
        "myContainerRegistry.azurecr.io/tensorflow/tensorflow:latest-gpu" };
containerConfig.ContainerRegistries = new List<ContainerRegistry> { containerRegistry } );

// VM configuration
VirtualMachineConfiguration virtualMachineConfiguration = new VirtualMachineConfiguration(
    imageReference: imageReference,
    nodeAgentSkuId: "batch.node.ubuntu 22.04");
virtualMachineConfiguration.ContainerConfiguration = containerConfig;

// Create pool
CloudPool pool = batchClient.PoolOperations.CreatePool(
    poolId: poolId,
    targetDedicatedComputeNodes: 2,
    virtualMachineSize: "Standard_NC6S_V3",
    virtualMachineConfiguration: virtualMachineConfiguration);
...

Параметры контейнера для задачи

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

• Используйте свойство ContainerSettings в классах задач для настройки параметров конкретного контейнера. Эти параметры определяются классом TaskContainerSettings. Параметр --rm контейнера не требует другого --runtime варианта, так как он заботится о пакетной службе.

• При запуске задач на образах контейнеров для задач облака и диспетчера заданий требуются параметры контейнера. Однако начальная задача, задача подготовки заданий и задача выпуска заданий не требуют параметров контейнера (т. е. они могут выполняться в контексте контейнера или непосредственно на узле).

• Для Linux пакетная служба сопоставляет разрешение пользователя или группы с контейнером. Если для доступа к какой-либо папке в контейнере требуется разрешение администратора, вам может потребоваться запустить задачу как область пула с уровнем прав администратора. Это гарантирует, что пакетная служба выполняет задачу в качестве корневого каталога в контексте контейнера. В противном случае у пользователя, отличного от администратора, может не быть доступа к этим папкам.

• Для пулов контейнеров с аппаратным оборудованием с поддержкой GPU пакетная служба автоматически включает GPU для задач контейнера, поэтому не следует включать –gpus аргумент.

Командная строка контейнерной задачи

При выполнении контейнерной задачи пакетная служба автоматически применяет команду docker create, чтобы создать контейнер на основе образа, указанного в задаче. Затем пакетная служба отслеживает выполнение задачи в контейнере.

Как и для обычных задач пакетной службы, для контейнерной задачи вам нужно указать командную строку. Так как пакетная служба автоматически создает контейнер, командная строка указывает только команду или команды, выполняемые в контейнере.

Ниже приведены действия пакетной службы по умолчанию, применяемой к задачам контейнера Docker:

• Пакетная служба запустит контейнер с указанной командной строкой задачи в качестве CMD.
• Пакетная служба не вмешивается в указанную точку ВХОДА образа контейнера.
• Пакетная служба переопределит WORKDIR с рабочим каталогом задачи пакетной службы.

Убедитесь, что вы просматриваете документацию Docker между ENTRYPOINT и CMD, чтобы понять эффекты взаимодействия, которые могут возникнуть, когда образы контейнеров имеют указанную точку ЗАПИСИ, а также укажите командную строку задачи.

Если вы хотите переопределить запись образа контейнера, можно указать --entrypoint <args> аргумент в качестве контейнераRunOption. Ознакомьтесь с необязательными аргументами ContainerRunOptions , которые можно предоставить команде docker create , которую пакет использует для создания и запуска контейнера. Например, чтобы задать для контейнера рабочий каталог, укажите параметр --workdir <directory>.

Ниже приведены некоторые примеры образов контейнеров и параметров контейнера пакетной службы или командных строк задач и их эффект.

• Запись образа контейнера не указана, и командная строка задачи пакетной службы — "/bin/sh -c python myscript.py".
  • Пакет создает контейнер с командной строкой задачи пакетной службы, как указано и запускает его в рабочем каталоге задачи пакетной службы. Это может привести к сбою, если "myscript.py" не в рабочем каталоге задачи пакетной службы.
  • Если командная строка задачи была указана как "/bin/sh -c python /path/to/script/myscript.py", эта задача может работать правильно даже с рабочим каталогом, заданным как рабочий каталог пакетной задачи, если все зависимости для скрипта удовлетворены.
• Запись образа контейнера указывается как "./myscript.sh", а командная строка задачи пакетной службы пуста.
  • Пакет создает контейнер, зависящий от ENTRYPOINT, и запускает его в рабочем каталоге задачи пакетной службы. Эта задача может привести к сбою, если образ контейнера WORKDIR не совпадает с рабочим каталогом задачи пакетной службы, который зависит от различных факторов, таких как операционная система, идентификатор задания, идентификатор задачи и т. д.
  • Если параметр --workdir /path/to/script был указан как контейнерRunOption, эта задача может работать правильно, если все зависимости для скрипта удовлетворены.
• Не указана командная строка задачи пакетной службы "/myscript.sh", а функция WORKDIR переопределяется в ContainerRunOptions как "-workdir /path/to/script".
  • Пакет создает контейнер с рабочим каталогом для "/path/to/script" и выполняет командную строку "./myscript.sh", которая успешно найдена в указанном рабочем каталоге.

Рабочий каталог для задач контейнера

Задача контейнера пакетной службы выполняется в рабочем каталоге в контейнере, аналогично каталогу, который пакет настраивает для обычной (неконтейнерной) задачи. Этот рабочий каталог отличается от WORKDIR , если настроен в образе или рабочий каталог контейнера по умолчанию (C:\ в контейнере Windows или / в контейнере Linux).

Для контейнерной задачи пакетной службы настраивается следующее:

• Все каталоги рекурсивно под AZ_BATCH_NODE_ROOT_DIR узлом узла (корень пакетная служба Azure каталогов) сопоставляются с контейнером.
• Все переменные среды задач сопоставляются с контейнером.
• рабочий каталог задачи AZ_BATCH_TASK_WORKING_DIR на узле настраивается так же, как для обычной задачи, и сопоставляется в контейнере.

Эти сопоставления позволяют работать с контейнерными задачами так же, как и с обычными. Например, вы можете устанавливать приложения с помощью пакетов приложений, обращаться к файлам ресурсов в службе хранилища Azure, настраивать параметры среды для задачи и сохранять выходные файлы задачи после остановки контейнера.

Независимо от того, как параметр WORKDIR установлен для образа контейнера, и stdout.txt stderr.txt они записываются в AZ_BATCH_TASK_DIRобъект .

Устранение неполадок с контейнерными задачами

Если ваша контейнерная задача работает не так, как ожидалось, вам будет полезно получить сведения о конфигурации WORKDIR или ENTRYPOINT для образа контейнера. Чтобы просмотреть конфигурацию, запустите команду docker image inspect.

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

• Используйте в командной строке задачи абсолютный путь. Если для командной строки задачи используется заданное в образе значение ENTRYPOINT по умолчанию, убедитесь, что используется абсолютный путь.
• В параметрах выполнения контейнера для задачи измените рабочую папку, чтобы она соответствовала папке WORKDIR в образе. Например, установите значение --workdir /app.

Примеры контейнерных задач

В приведенном ниже фрагменте кода Python показана базовая командная строка, которая выполняется в контейнере, созданном на основе фиктивного образа из центра Docker. Здесь параметр контейнера --rm означает удаление контейнера после выполнения задачи, а параметр --workdir задает рабочую папку. Эта командная строка переопределяет заданное в контейнере значение ENTRYPOINT, заменяя его простой командой оболочки для создания небольшого файла в рабочей папке задачи на узле.

task_id = 'sampletask'
task_container_settings = batch.models.TaskContainerSettings(
    image_name='myimage',
    container_run_options='--rm --workdir /')
task = batch.models.TaskAddParameter(
    id=task_id,
    command_line='/bin/sh -c \"echo \'hello world\' > $AZ_BATCH_TASK_WORKING_DIR/output.txt\"',
    container_settings=task_container_settings
)

В следующем примере на C# показаны основные параметры контейнера для задачи, выполняемой в облаке:

// Simple container task command
string cmdLine = "c:\\app\\myApp.exe";

TaskContainerSettings cmdContainerSettings = new TaskContainerSettings (
    imageName: "myimage",
    containerRunOptions: "--rm --workdir c:\\app"
    );

CloudTask containerTask = new CloudTask (
    id: "Task1",
    commandline: cmdLine);
containerTask.ContainerSettings = cmdContainerSettings;

Следующие шаги

• Сведения об установке и использовании Docker CE в Linux см. в документации Docker.
• Узнайте, как использовать управляемый образ для создания настраиваемого пула образов.
• Узнайте больше о проекте Moby — платформе для создания контейнерных систем.