ACI интеграция с функциями Compose

В этом документе описывается преобразовывает приложения, определённого в файле Compose, в объекты ACI. На высоком уровне каждое развертывание Compose сопоставляется с одной группой контейнеров ACI. Каждая служба сопоставляется с контейнером в группе контейнеров. Интеграция Docker ACI не позволяет масштабировать сервисы.

Compose сопоставления полей

В таблице далее перечислены поддерживаемые поля файла Compose и их аналоги ACI.

Легенда:

  • ✓: Реализовано

  • n: ещё не реализовано

  • x: Неприменимо / нет доступных преобразований

Ключи

Карта

Примечания

Сервис

service.service.build

x

Игнорируется. Нет поддержки сборки образа в ACI.

service.cap_add, cap_drop

x

service.command

Переопределить команду контейнера. В ACI указание command переопределит команду образа и точку входа, если в образе определена команда или точка входа.

service.configs

x

service.cgroup_parent

x

service.container_name

x

Имя службы используется в качестве имени контейнера в ACI.

service.credential_spec

x

service.deploy

service.deploy.endpoint_mode

x

service.deploy.mode

x

service.deploy.replicas

x

Для каждой службы запускается только одна реплика.

service.deploy.placement

x

service.deploy.update_config

x

service.deploy.resources

Ограничение: Пределы ресурсов ACI не могут превышать сумму резервирований ресурсов для всех контейнеров в группе контейнеров. Использование ограничений контейнеров, превышающих резервирование контейнеров, приведёт к тому, что контейнеры в одной группе контейнеров будут конкурировать за ресурсы.

service.deploy.restart_policy

Один из: any, none, on- failure. Ограничение: все службы должны иметь одинаковую политику перезапуска. При необходимости будет перезапущена вся группа контейнеров ACI.

service.deploy.labels

x

ACI не имеет меток на уровне контейнера.

service.devices

x

service.depends_on

x

service.dns

x

service.dns_search

x

service.domainname

Сопоставляется с ACI DNSLabelName. Ограничение: все службы должны указывать один и тот же domainname, если он указан. domainname должен быть уникальным глобально в <region>.azurecontainer.io</region>

service.tmpfs

x

service.entrypoint

x

ACI поддерживает только переопределение команды контейнера.

service.env_file

service.environment

service.expose

x

service.extends

x

service.external_links

x

service.extra_hosts

x

service.group_add

x

service.healthcheck

service.hostname

x

service.image

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

service.isolation

x

service.labels

x

ACI не имеет меток на уровне контейнера.

service.links

x

service.logging

x

service.network_mode

x

service.networks

x

Связь между службами реализуется путём определения сопоставления для каждой службы в общем файле /etc/hosts группы контейнеров. Каждая служба может разрешать имена для других служб, и результирующие сетевые вызовы будут перенаправлены на localhost.

service.pid

x

service.ports

В ACI поддерживается только симметричное сопоставление портов. См. Открытие портов.

service.secrets

См. Секреты.

service.security_opt

x

service.stop_grace_period

x

service.stop_signal

x

service.sysctls

x

service.ulimits

x

service.userns_mode

x

service.volumes

Сопоставляется с файловыми ресурсами AZure. См. Постоянные тома.

service.restart

x

Заменено на service.deployment.restart_policy

Том

x

драйвер

См. постоянные тома.

driver_opts

external

x

labels

x

Секрет

x

TBD

x

Config

x

TBD

x

Журналы

Журналы контейнеров можно получает для каждого контейнера с помощью логи Docker <CONTAINER>. The Docker ACI integration does not currently support aggregated logs for containers in a Compose application, see issues/803.

Открытие портов

Когда одна или несколько служб предоставляют порты, вся группа контейнеров ACI будет открыта и получит общедоступный IP-адрес. Поскольку все службы сопоставляются с контейнерами в одной группе контейнеров, только одна служба не может предоставлять данный номер порта. ACI не поддерживает сопоставление портов, поэтому исходный и целевой порты, определённые в файле Compose, должны совпадать.

При предоставлении портов служба также может указывает поле службы domainname для установки имени хоста DNS. domainname будет использоваться для указания имени метки DNS ACI, а группа контейнеров ACI будет доступна по адресу ..azurecontainer.io. Все службы, определяющие доменное имя, должны установить одно и то же значение, поскольку оно применяется ко всей группе контейнеров. `domainname` должно быть уникальным глобально в .azurecontainer.io.

Постоянные тома

Тома Docker сопоставляются с файловыми ресурсами Azure. Поддерживается только длинный формат тома Compose, что означает, что тома должны быть определены в разделе volume. Тома определяются с помощью имени, в поле driver должно быть указано значение azure_file, а в поле driver_options должны быть указаны учетная запись хранения и общий файловый ресурс, используемые для тома. Затем служба может ссылаться на том по его имени и указывать целевой путь для монтирования в контейнере.

services:
    myservice:
        image: nginx
        volumes:
        - mydata:/mount/testvolumes

volumes:
  mydata:
    driver: azure_file
    driver_opts:
      share_name: myfileshare
      storage_account_name: mystorageaccount

Синтаксис короткого тома не разрешен для томов ACI, поскольку он был разработан для монтирования привязки локального пути при запуске локальных контейнеров. Файл Compose может определять несколько томов с разными файловыми ресурсами Azure или учетными записями хранения.

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

Секреты

Секреты можно определить в compose-файлах, и потребуются секретные файлы, доступные во время развертывания рядом с compose-файлом. Содержимое секретного файла будет доступно внутри выбранных контейнеров, по умолчанию в /run/secrets/<SECRET_NAME>. Внешние секреты не поддерживаются интеграцией ACI.

services:
    nginx:
        image: nginx
        secrets:
          - mysecret1
    db:
        image: mysql
        secrets:
          - mysecret2

secrets:
  mysecret1:
    file: ./my_secret1.txt
  mysecret2:
    file: ./my_secret2.txt

Контейнер nginx будет иметь secret1, смонтированный как /run/secrets/mysecret1, контейнер db будет иметь secret2, смонтированный как /run/secrets/mysecret2.

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

services:
    nginx:
        image: nginx
        secrets:
          - source: mysecret1
            target: renamedsecret1.txt
    db:
        image: mysql
        secrets:
          - source: mysecret1
            target: /mnt/dbmount/mysecretonmount1.txt
          - source: mysecret2
            target: /mnt/dbmount/mysecretonmount2.txt

secrets:
  mysecret1:
    file: ./my_secret1.txt
  mysecret2:
    file: ./my_secret2.txt

В этом примере секрет службы nginx будет смонтирован в /run/secrets/renamedsecret1.txt, а db будет иметь 2 файла (mysecretonmount1.txt и mysecretonmount2.txt). Оба они должны быть смонтированы в одной папке (/mnt/dbmount/).

Примечание. Относительные пути к файлам не допускаются в целевом

Примечание. Секретные файлы нельзя монтировать в папку рядом с другими существующими файлами.

Контейнерные ресурсы

Резервирование ЦП и памяти и ограничения могут быть установлены в compose. Пределы ресурсов должны быть больше резервирования. В ACI установка ограничений ресурсов, отличных от резервирования ресурсов, приведёт к тому, что контейнеры в одной группе контейнеров будут конкурировать за ресурсы. Пределы ресурсов не могут превышать общее резервирование ресурсов для группы контейнеров. (Поэтому отдельные контейнеры не могут иметь ограничения ресурсов, отличные от резервирования ресурсов)

services:
  db:
    image: mysql
    deploy:
      resources:
        reservations:
          cpus: '2'
          memory: 2G
        limits:
          cpus: '3'
          memory: 3G
  web:
    image: nginx
    deploy:
      resources:
        reservations:
          cpus: '1.5'
          memory: 1.5G

В этом примере контейнеру db будет выделено 2 процессора и 2 ГБ памяти. Будет разрешено использовать до 3 процессоров и 3G памяти, используя часть ресурсов, выделенных веб-контейнеру. По умолчанию для веб-контейнера будут установлены те же значения, что и для резервирования.

Проверки здоровья

Проверка работоспособности может быть описана в разделе healthcheck каждой службы. Это переводится в LivenessProbe в ACI. Если проверка работоспособности завершается неудачей, контейнер считается неработоспособным и завершается. Для автоматического перезапуска контейнера в службе должна быть установлена политика перезапуска, отличная от none. Обратите внимание, что политика перезапуска по умолчанию, если она не установлена, — any.

services:
  web:
    image: nginx
    deploy:
      restart_policy:
        condition: on-failure
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:80"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 40s

Примечание: команда test может быть string или массивом, начинающимся с NONE, CMD, CMD-SHELL или нет. В реализации ACI данные префиксы игнорируются.