Поделиться через

Настройка контейнера клиента в Службе приложений Azure

  • Статья

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

Это краткое описание содержит основные понятия и инструкции для работы с контейнерами приложений Windows в Службе приложений. Новые пользователи службы приложение Azure должны следовать краткому руководству по пользовательскому контейнеру и руководству.

Это краткое описание содержит основные понятия и инструкции для работы с контейнерами приложений Linux в Службе приложений. Если вы не знакомы со службой приложение Azure, следуйте краткому руководству и руководству по пользовательскому контейнеру. Сведения о контейнерах на стороне (предварительная версия) см. в руководстве по настройке контейнера на стороне для пользовательского контейнера в службе приложение Azure (предварительная версия).

Примечание.

Субъект-служба больше не поддерживается для проверки подлинности на вытягивании образа контейнера Windows. Рекомендуется использовать управляемое удостоверение для контейнеров Windows и Linux.

Поддерживаемые родительские образы

Вам нужно выбрать правильный родительский (базовый) образ для платформы, которую вы хотите использовать:

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

Изменение образа Docker пользовательского контейнера

Чтобы изменить текущий образ Docker существующего пользовательского контейнера на новый образ, выполните следующую команду:

az webapp config container set --name <app-name> --resource-group <group-name> --docker-custom-image-name <docker-hub-repo>/<image>

Использование образа из частного реестра

Чтобы использовать образ из частного реестра, например реестра контейнеров Azure, выполните следующую команду:

az webapp config container set --name <app-name> --resource-group <group-name> --docker-custom-image-name <image-name> --docker-registry-server-url <private-repo-url> --docker-registry-server-user <username> --docker-registry-server-password <password>

Для имени пользователя> и< пароля> укажите учетные данные входа для учетной записи частного реестра.<

Использование управляемого удостоверения для извлечения образа из Реестра контейнеров Azure (ACR)

Выполните следующие действия, чтобы настроить веб-приложение для извлечения из Реестр контейнеров Azure (ACR) с помощью управляемого удостоверения. Действия используют управляемое удостоверение, назначаемое системой, но также можно использовать назначаемое пользователем управляемое удостоверение.

  1. Включите управляемое удостоверение, назначаемое системой для веб-приложения, выполнив команду az webapp identity assign.

    az webapp identity assign --resource-group <group-name> --name <app-name> --query principalId --output tsv

    Замените <app-name> значением, которое вы использовали на предыдущем шаге. Выходные данные команды (отфильтрованы --query по --output аргументам) — это идентификатор субъекта-службы назначенного удостоверения.

  2. Получите идентификатор ресурса Реестра контейнеров Azure:

    az acr show --resource-group <group-name> --name <registry-name> --query id --output tsv

    Замените <registry-name> именем своего реестра. Выходные данные команды (отфильтрованы --query по --output аргументам) — это идентификатор ресурса Реестр контейнеров Azure.

  3. Предоставьте управляемому удостоверению разрешение на доступ к реестру контейнеров.

    az role assignment create --assignee <principal-id> --scope <registry-resource-id> --role "AcrPull"

    Измените следующие значения:

    • <principal-id> на идентификатор субъекта-службы, полученный командой az webapp identity assign;
    • <registry-resource-id> на идентификатор реестра контейнеров из команды az acr show

    Дополнительные сведения об этих разрешениях см. в статье Общие сведения об управлении доступом на основе ролей (RBAC) для ресурсов Azure.

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

    az webapp config set --resource-group <group-name> --name <app-name> --generic-configurations '{"acrUseManagedIdentityCreds": true}'

    Измените следующие значения:

    • замените <app-name> именем веб-приложения.

    Совет

    Если вы используете консоль PowerShell для выполнения команд, необходимо экранировать строки в аргументе --generic-configurations в этом и следующем шаге. Например: --generic-configurations '{\"acrUseManagedIdentityCreds\": true'

  5. (Необязательно) Если приложение использует управляемое удостоверение, назначаемое пользователем, убедитесь, что удостоверение настроено в веб-приложении, а затем задайте acrUserManagedIdentityID свойство, чтобы указать его идентификатор клиента:

    az identity show --resource-group <group-name> --name <identity-name> --query clientId --output tsv

    Замените параметр <identity-name> назначаемого пользователем управляемого удостоверения и используйте выходные данные <client-id> для настройки идентификатора этого удостоверения.

    az  webapp config set --resource-group <group-name> --name <app-name> --generic-configurations '{"acrUserManagedIdentityID": "<client-id>"}'

Все задано, а веб-приложение теперь использует управляемое удостоверение для извлечения из Реестр контейнеров Azure.

Использование образа из реестра, защищенного в сети

Чтобы подключиться и извлечь из реестра в виртуальной сети или локальной сети, приложение должно интегрироваться с виртуальной сетью (VNET). Интеграция виртуальной сети также необходима для Реестр контейнеров Azure с частной конечной точкой. При настройке разрешения сети и DNS можно включить маршрутизацию извлечения образа через виртуальную сеть, настроив vnetImagePullEnabled параметр сайта:

az resource update --resource-group <group-name> --name <app-name> --resource-type "Microsoft.Web/sites" --set properties.vnetImagePullEnabled [true|false]

Я не вижу обновленный контейнер

Если изменить параметры контейнера Docker, чтобы указать на новый контейнер, может потребоваться несколько минут, прежде чем приложение обслуживает HTTP-запросы из нового контейнера. Во время извлечения и запуска нового контейнера Служба приложений продолжит обслуживать запросы из старого контейнера. Служба приложений начинает отправлять запросы на новый контейнер только после его запуска и готовности к приему запросов.

Как хранятся образы контейнеров

При первом запуске пользовательского образа Docker в Службе приложений она выполняет операцию docker pull и извлекает все слои образа. Эти слои хранятся на диске, например при использовании Docker в локальной среде. При каждом перезапуске приложения Служба приложений выполняет операцию docker pull, но извлекает только слои, которые были изменены. Если изменений нет, Служба приложений использует существующие слои на локальном диске.

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

Настройка номера порта

По умолчанию Служба приложений предполагает, что ваш пользовательский контейнер прослушивает порт 80. Если контейнер прослушивает другой порт, настройте соответствующим образом параметр WEBSITES_PORT приложения в приложении Службы приложений. Его можно задать с помощью Cloud Shell. В Bash:

az webapp config appsettings set --resource-group <group-name> --name <app-name> --settings WEBSITES_PORT=8000

В PowerShell:

Set-AzWebApp -ResourceGroupName <group-name> -Name <app-name> -AppSettings @{"WEBSITES_PORT"="8000"}

В настоящее время Служба приложений позволяет контейнеру предоставлять для HTTP-запросов только один порт.

Настройка переменных среды

Настраиваемый контейнер может использовать переменные среды, которые необходимо предоставить внешним образом. Их можно передать с помощью Cloud Shell. В Bash:

az webapp config appsettings set --resource-group <group-name> --name <app-name> --settings DB_HOST="myownserver.mysql.database.azure.com"

В PowerShell:

Set-AzWebApp -ResourceGroupName <group-name> -Name <app-name> -AppSettings @{"DB_HOST"="myownserver.mysql.database.azure.com"}

При запуске приложения параметры приложения Службы приложений автоматически подставляются в процесс как переменные среды. Вы можете проверить переменные среды контейнера с помощью URL-адреса https://<app-name>.scm.azurewebsites.net/Env.

Если приложение использует образы из частного реестра или из Docker Hub, учетные данные для доступа к репозиторию сохраняются в переменных среды DOCKER_REGISTRY_SERVER_URL, DOCKER_REGISTRY_SERVER_USERNAME и DOCKER_REGISTRY_SERVER_PASSWORD. Из-за угроз для безопасности приложению не предоставляется ни одно из этих зарезервированных имен переменных.

Для контейнеров на базе IIS или платформы .NET Framework (4.0 и более поздних версий) они автоматически добавляются Службой приложений в System.ConfigurationManager в качестве параметров приложения .NET и строки подключения. Для любого другого языка или платформы они предоставляются процессу как переменные среды с одним из следующих соответствующих префиксов:

  • APPSETTING_
  • SQLCONTR_
  • MYSQLCONTR_
  • SQLAZURECOSTR_
  • POSTGRESQLCONTR_
  • CUSTOMCONNSTR_

Этот метод работает как для приложений с одним контейнером, так и для приложений с несколькими контейнерами, где переменные среды указаны в файле docker-compose.yml.

Использование постоянного хранилища

Вы можете использовать каталог C:\home в файловой системе своего пользовательского контейнера для сохранения файлов между перезапусками и совместного доступа к ним в экземплярах. Каталог C:\home позволяет обеспечить пользовательскому контейнеру доступ к постоянному хранилищу.

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

Единственным исключением является каталог C:\home\LogFiles, который используется для хранения журналов контейнера и приложения. Эта папка всегда сохраняется при перезапуске приложения, если ведение журнала приложений включено с параметром файловой системы независимо от того, включено или отключено постоянное хранилище. Другими словами, включение или отключение постоянного хранилища не влияет на поведение ведения журнала приложений.

По умолчанию постоянное хранилище включено в пользовательских контейнерах Windows. Чтобы отключить его, задайте для параметра WEBSITES_ENABLE_APP_SERVICE_STORAGE приложения значение false с помощью Cloud Shell. В Bash:

az webapp config appsettings set --resource-group <group-name> --name <app-name> --settings WEBSITES_ENABLE_APP_SERVICE_STORAGE=false

В PowerShell:

Set-AzWebApp -ResourceGroupName <group-name> -Name <app-name> -AppSettings @{"WEBSITES_ENABLE_APP_SERVICE_STORAGE"=false}

Вы можете использовать каталог /home в файловой системе своего пользовательского контейнера для сохранения файлов между перезапусками и совместного доступа к ним в экземплярах. Каталог /home позволяет обеспечить пользовательскому контейнеру доступ к постоянному хранилищу. Сохранение данных в /home рамках квоты дискового пространства, включенной в план Служба приложений.

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

Единственным исключением является каталог /home/LogFiles, который используется для хранения журналов контейнера и приложения. Эта папка всегда сохраняется при перезапуске приложения, если ведение журнала приложений включено с параметром файловой системы независимо от того, включено или отключено постоянное хранилище. Другими словами, включение или отключение постоянного хранилища не влияет на поведение ведения журнала приложений.

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

По умолчанию постоянное хранилище отключено в пользовательских контейнерах Linux. Чтобы включить его, задайте для параметра WEBSITES_ENABLE_APP_SERVICE_STORAGE приложения значение true с помощью Cloud Shell. В Bash:

az webapp config appsettings set --resource-group <group-name> --name <app-name> --settings WEBSITES_ENABLE_APP_SERVICE_STORAGE=true

В PowerShell:

Set-AzWebApp -ResourceGroupName <group-name> -Name <app-name> -AppSettings @{"WEBSITES_ENABLE_APP_SERVICE_STORAGE"=true}

Примечание.

Вы также можете настроить собственное постоянное хранилище.

Обнаружение сеанса HTTPS

Служба приложений прерывает сеансы TLS/SSL на внешних интерфейсах. Это означает, что запросы TLS/SSL никогда не поступают в приложение. Вы не обязаны и не должны реализовывать в своем приложении какую-либо поддержку TLS/SSL.

Внешние интерфейсы находятся в центрах обработки данных Azure. Если вы используете TLS/SSL с приложением, ваш трафик через Интернет всегда безопасно шифруется.

Настройка введения ключа компьютера ASP.NET

Во время запуска контейнера в него вставляются автоматически созданные ключи в качестве ключей компьютера для подпрограмм шифрования ASP.NET. Эти ключи можно найти в контейнере в следующих переменных среды: MACHINEKEY_Decryption, MACHINEKEY_DecryptionKey, MACHINEKEY_ValidationKey, MACHINEKEY_Validation.

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

Подключение к контейнеру

Вы можете подключиться к контейнеру Windows непосредственно для задач диагностики, перейдя к https://<app-name>.scm.azurewebsites.net/ параметру SSH и выбрав его. Устанавливается прямой сеанс SSH с контейнером, в котором можно выполнять команды внутри контейнера.

  • Она работает отдельно от графического браузера, находящегося на более высоком уровне, в котором отображаются только файлы в общем хранилище.
  • В масштабируемом приложении сеанс SSH подключается к одному из экземпляров контейнера. Вы можете выбрать другой экземпляр из раскрывающегося списка Экземпляра в верхнем меню Kudu.
  • Любые изменения, внесенные в контейнер из сеанса SSH, не сохраняются при перезапуске приложения (за исключением изменений в общем хранилище), так как это не является частью образа Docker. Чтобы сохранить такие изменения, как правки в параметрах реестра и установка программного обеспечения, сделайте их частью файла Dockerfile.

Доступ к журналам диагностики

Служба приложений журналы действий узла и действий Docker из контейнера. Журналы узла Docker (журналы платформы) активированы по умолчанию, однако журналы приложений и веб-сервера в контейнере необходимо включить вручную. Дополнительные сведения см. в разделах Включение журнала приложений и Включение журнала веб-сервера.

Получить доступ к журналам Docker можно несколькими способами:

На портале Azure

Журналы Docker отображаются на портале на странице Параметры контейнера приложения. Журналы усечены, но вы можете скачать все журналы, выбрав "Скачать".

Из Kudu

Перейдите к https://<app-name>.scm.azurewebsites.net/DebugConsole папке LogFiles и выберите ее, чтобы просмотреть отдельные файлы журнала. Чтобы скачать весь каталог LogFiles , щелкните значок "Скачать" слева от имени каталога. Доступ к этой папке также можно получить с помощью FTP-клиента.

В терминале SSH невозможно получить доступ к C:\home\LogFiles папке по умолчанию, так как постоянное общее хранилище не включено. Чтобы включить такое поведение в консольном терминале, активируйте постоянное общее хранилище.

Если вы пытаетесь скачать журнал Docker, который в настоящее время используется с помощью FTP-клиента, может возникнуть ошибка из-за блокировки файла.

С помощью API Kudu

Перейдите непосредственно на страницу https://<app-name>.scm.azurewebsites.net/api/logs/docker, чтобы просмотреть метаданные для журналов Docker. В списке может отображаться несколько файлов журнала, а href свойство позволяет скачать файл журнала напрямую.

Чтобы скачать сразу все журналы в одном ZIP-файле, откройте страницу https://<app-name>.scm.azurewebsites.net/api/logs/docker/zip.

Настройка памяти контейнера

По умолчанию все контейнеры Windows, развернутые в службе приложение Azure, настроены ограничения памяти. В следующей таблице перечислены параметры по умолчанию на номер SKU плана Служба приложений.

Ценовая категория плана службы приложений Ограничение памяти по умолчанию для каждого приложения в МБ
P1v3 1024
P1Mv3 1024
P2v3 1536
P2Mv3 1536
P3v3 2048
P3Mv3 2048
P4Mv3 2560
P5Mv3 3072

Это значение можно изменить, задав параметр WEBSITE_MEMORY_LIMIT_MB приложения через Cloud Shell. В Bash:

az webapp config appsettings set --resource-group <group-name> --name <app-name> --settings WEBSITE_MEMORY_LIMIT_MB=2000

В PowerShell:

Set-AzWebApp -ResourceGroupName <group-name> -Name <app-name> -AppSettings @{"WEBSITE_MEMORY_LIMIT_MB"=2000}

Значение определяется в МБ и должно быть не больше общего объема физической памяти узла. Например, в плане Службы приложений с 8 ГБ ОЗУ сумма значений WEBSITE_MEMORY_LIMIT_MB для всех приложений не должна превышать 8 ГБ. Сведения о том, сколько памяти доступно для каждой ценовой категории, можно найти в статье о ценах на Службу приложений в разделе План служб "Премиум" v3.

Настройка количества вычислительных ядер

По умолчанию контейнер Windows выполняется со всеми доступными ядрами для выбранной ценовой категории. Возможно, потребуется уменьшить количество ядер, которые использует промежуточный слот, например. Чтобы уменьшить количество ядер, используемых контейнером, задайте в параметре WEBSITE_CPU_CORES_LIMIT приложения нужное число ядер. Его можно задать с помощью Cloud Shell. В Bash:

az webapp config appsettings set --resource-group <group-name> --name <app-name> --slot staging --settings WEBSITE_CPU_CORES_LIMIT=1

В PowerShell:

Set-AzWebApp -ResourceGroupName <group-name> -Name <app-name> -AppSettings @{"WEBSITE_CPU_CORES_LIMIT"=1}

Примечание.

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

Проверьте скорректированный номер, открыв сеанс SSH на портале или на портале Kudu (https://<app-name>.scm.azurewebsites.net/webssh/host) и введя следующие команды с помощью PowerShell. Каждая команда выводит число.

Get-ComputerInfo | ft CsNumberOfLogicalProcessors # Total number of enabled logical processors. Disabled processors are excluded.
Get-ComputerInfo | ft CsNumberOfProcessors # Number of physical processors.

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

Настройка проверки связи для работоспособности

Служба приложений считает, что контейнер успешно запущен, если он запускается и отвечает на HTTP-запрос проверки связи. Запрос проверки связи содержит заголовок User-Agent= "App Service Hyper-V Container Availability Check". Если контейнер запускается, но не отвечает на запросы через определенное время, Служба приложений регистрирует событие в журнале Docker, заявив, что контейнер не запущен.

Если приложение потребляет много ресурсов, контейнер может не отвечать на HTTP-запросы проверки связи. Чтобы настроить поведение на случай сбоя проверки связи HTTP, установите параметр приложения CONTAINER_AVAILABILITY_CHECK_MODE. Его можно задать с помощью Cloud Shell. В Bash:

az webapp config appsettings set --resource-group <group-name> --name <app-name> --settings CONTAINER_AVAILABILITY_CHECK_MODE="ReportOnly"

В PowerShell:

Set-AzWebApp -ResourceGroupName <group-name> -Name <app-name> -AppSettings @{"CONTAINER_AVAILABILITY_CHECK_MODE"="ReportOnly"}

В таблице ниже приведены возможные значения.

Значение Descriptions
Repair Контейнер перезапускается после трех последовательных проверок доступности.
ReportOnly Значение по умолчанию. Контейнер не перезапускается, но в журналы Docker для него добавляется соответствующее событие после трех последовательных проверок доступности.
Выкл. Доступность не проверяется.

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

Групповые управляемые учетные записи служб (gMSA) в настоящее время не поддерживаются в контейнерах Windows в Службе приложений.

Включение SSH

Secure Shell (SSH) широко используется для удаленного выполнения административных команд из терминала командной строки. Чтобы включить функцию консоли SSH портал Azure с пользовательскими контейнерами, необходимо выполнить следующие действия.

  1. Создайте стандартный sshd_config файл со следующим содержимым и поместите его в корневой каталог проекта приложения:

    Port 			2222
ListenAddress 		0.0.0.0
LoginGraceTime 		180
X11Forwarding 		yes
Ciphers aes128-cbc,3des-cbc,aes256-cbc,aes128-ctr,aes192-ctr,aes256-ctr
MACs hmac-sha1,hmac-sha1-96
StrictModes 		yes
SyslogFacility 		DAEMON
PasswordAuthentication 	yes
PermitEmptyPasswords 	no
PermitRootLogin 	yes
Subsystem sftp internal-sftp

    Примечание.

    Этот файл настраивает OpenSSH и должен включать следующие элементы, чтобы обеспечить соответствие функции SSH портал Azure:

    • Для параметра Port должно быть установлено значение 2222.
    • Ciphers должен содержать по крайней мере один элемент в этом списке: aes128-cbc,3des-cbc,aes256-cbc.
    • MACs должен содержать по крайней мере один элемент в этом списке: hmac-sha1,hmac-sha1-96.

  2. Создайте скрипт точки входа с именем entrypoint.sh (или измените существующий файл точки входа) и добавьте команду для запуска службы SSH вместе с командой запуска приложения. В следующем примере показано, как запустить приложение Python. Замените последнюю команду в соответствии с языком проекта или стеком:

    #!/bin/sh
set -e
service ssh start
exec gunicorn -w 4 -b 0.0.0.0:8000 app:app

  3. Добавьте в Dockerfile следующие инструкции в соответствии с распределением базового образа. Эти инструкции копируют новые файлы, устанавливают сервер OpenSSH, задают правильные разрешения и настраивают настраиваемую точку входа и предоставляют порты, необходимые для сервера приложений и SSH соответственно:

    COPY entrypoint.sh ./

# Start and enable SSH
RUN apt-get update \
    && apt-get install -y --no-install-recommends dialog \
    && apt-get install -y --no-install-recommends openssh-server \
    && echo "root:Docker!" | chpasswd \
    && chmod u+x ./entrypoint.sh
COPY sshd_config /etc/ssh/

EXPOSE 8000 2222

ENTRYPOINT [ "./entrypoint.sh" ]

    Примечание.

    Корневой пароль должен быть точно так Docker! же, как он используется Служба приложений, чтобы разрешить доступ к сеансу SSH с контейнером. Эта конфигурация не допускает внешние подключения к контейнеру. Порт 2222 контейнера доступен только в сети моста частной виртуальной сети и недоступен злоумышленнику в Интернете.

  4. Перестройте и отправьте образ Docker в реестр, а затем проверьте функцию SSH веб-приложения на портал Azure.

Дополнительные сведения об устранении неполадок доступны в блоге службы приложение Azure: включение SSH в веб-приложении Linux для контейнеров

Доступ к журналам диагностики

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

Сначала включите ведение журнала контейнера, выполнив следующую команду:

az webapp log config --name <app-name> --resource-group <resource-group-name> --docker-container-logging filesystem

Замените <app-name> и <resource-group-name> именами, подходящими для вашего веб-приложения.

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

az webapp log tail --name <app-name> --resource-group <resource-group-name>

Если журналы консоли не отображаются, проверьте еще раз через 30 секунд.

Чтобы остановить потоковую передачу журналов, нажмите клавиши CTRL+C.

Вы также можете проверить файлы журнала в браузере на странице https://<app-name>.scm.azurewebsites.net/api/logs/docker.

Настройка приложений с несколькими контейнерами

Примечание.

Контейнеры на стороне (предварительная версия) будут успешными приложениями с несколькими контейнерами в Служба приложений. Сведения о начале работы см. в руководстве по настройке контейнера на стороне для пользовательского контейнера в службе приложение Azure (предварительная версия).

Использование постоянного хранилища в Docker Compose

Для правильной работы приложений с несколькими контейнерами, таких как WordPress, требуется постоянное хранилище. Для его включения в конфигурации Docker Compose должно быть указано место хранения за пределами контейнера. Изменения в местах хранения внутри контейнера не сохраняются после перезапуска приложения.

Чтобы включить постоянное хранилище, установите параметр WEBSITES_ENABLE_APP_SERVICE_STORAGE приложения с помощью команды az webapp config appsettings set в Cloud Shell.

az webapp config appsettings set --resource-group <group-name> --name <app-name> --settings WEBSITES_ENABLE_APP_SERVICE_STORAGE=TRUE

В файле docker-compose.yml сопоставьте параметр volumes с ${WEBAPP_STORAGE_HOME}.

WEBAPP_STORAGE_HOME — это переменная среды в Службе приложений, которая сопоставляется с постоянным хранилищем для вашего приложения. Например:

wordpress:
  image: <image name:tag>
  volumes:
  - "${WEBAPP_STORAGE_HOME}/site/wwwroot:/var/www/html"
  - "${WEBAPP_STORAGE_HOME}/phpmyadmin:/var/www/phpmyadmin"
  - "${WEBAPP_STORAGE_HOME}/LogFiles:/var/log"

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

В настоящее время многоконтейнерные приложения доступны в режиме предварительной версии. Следующие функции платформы Служба приложений не поддерживаются.

  • Проверка подлинности/авторизация
  • управляемые удостоверения.
  • CORS
  • Интеграция виртуальной сети не поддерживается для сценариев Docker Compose
  • Для Docker Compose в Службах приложений Azure сейчас настроено ограничение в 4000 символов.

Параметры Docker Compose

В следующих списках приведены поддерживаемые и неподдерживаемые параметры конфигурации Docker Compose.

Поддерживаемые параметры

Неподдерживаемые параметры

  • build (недопустимо);
  • depends_on (игнорируется)
  • networks (игнорируется);
  • secrets (игнорируется);
  • порты, отличные от 80 и 8080 (игнорируются).
  • переменные среды по умолчанию, такие как $variable and ${variable}, в отличие от переменных в Docker

Ограничения синтаксиса

  • "version x.x" всегда должна быть первой инструкцией YAML в файле
  • В разделе ports должны использоваться числа в кавычках
  • Раздел тома изображения > должен быть кавычек и не может иметь определения разрешений
  • Раздел volumes не должен иметь пустую фигурную скобку после имени тома

Примечание.

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

robots933456 в журналах

В журналах контейнера может отобразиться следующее сообщение:

2019-04-08T14:07:56.641002476Z "-" - - [08/Apr/2019:14:07:56 +0000] "GET /robots933456.txt HTTP/1.1" 404 415 "-" "-"

Это сообщение можно проигнорировать. /robots933456.txt — это фиктивный URL-путь, с помощью которого Служба приложений проверяет, может ли контейнер обслуживать запросы. Ответ 404 означает, что путь не существует. При этом он информирует Службу приложений о том, что контейнер работоспособен и готов отвечать на запросы.

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

Руководство по переносу пользовательского программного обеспечения в Службу приложений Azure с помощью пользовательского контейнера

Руководство по настройке контейнера на стороне для пользовательского контейнера в службе приложение Azure (предварительная версия)

Кроме того, ознакомьтесь с дополнительными ресурсами: