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

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

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

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

Для вашего пользовательского образа Windows выберите нужный родительский образ (базовый образ) для фреймворка, который вы хотите.

• Для развертывания приложений .NET Framework используйте родительский образ, основанный на выпуске канала долгосрочного обслуживания (LTSC) Windows Server 2019 Core.
• Чтобы развернуть приложения .NET Core, используйте родительский образ на основе выпуска Windows Server 2019 Nano Annual Channel (AC).

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

• mcr.microsoft.com/windows/servercore:ltsc2022
• mcr.microsoft.com/windows/servercore:ltsc2019
• mcr.microsoft.com/dotnet/framework/aspnet:4.8-windowsservercore-ltsc2022
• mcr.microsoft.com/dotnet/framework/aspnet:4.8-windowsservercore-ltsc2019
• mcr.microsoft.com/dotnet/runtime:6.0-nanoserver-ltsc2022
• mcr.microsoft.com/dotnet/runtime:6.0-nanoserver-1809
• mcr.microsoft.com/dotnet/aspnet:6.0-nanoserver-ltsc2022
• mcr.microsoft.com/dotnet/aspnet:6.0-nanoserver-1809

Для контейнеров на основе IIS или .NET Framework (4.0 или более поздней версии) учетные данные автоматически добавляются в System.ConfigurationManager службой App Service в качестве параметров приложения .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}

Настройка введения ключа компьютера 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
• Куду
• API Kudu
• Azure Monitor

На портале Azure

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

Из 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 плана Службы приложений.

Это значение можно изменить, указав 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 ГБ. Дополнительные сведения о доступном объеме памяти см. в разделе плана службы "Премиум" версии 3в ценах на службу приложений.

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

По умолчанию контейнер 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 на портале Azure или используйте портал 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.

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

Настройка поведения пинга работоспособности системы

Служба приложений считает, что контейнер успешно запущен, если он запускается и отвечает на 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"}

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

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

Групповые управляемые учетные записи служб (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. Замените последнюю команду в соответствии с языком проекта или стеком:

   • Debian
   • Альпийский

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

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

   • Debian
   • Альпийский

   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.

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

• Использование постоянного хранилища в Docker Compose
• Ограничения предварительной версии
• Параметры Docker Compose

Использование постоянного хранилища в 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.

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

• Приказ
• точка входа
• окружающая среда
• Изображение
• порты
• перезагрузка
• услуги
• тома (сопоставление с хранилищем Azure не поддерживается)

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

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

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

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

Игнорировать сообщение робота933456 в журналах

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

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 указывает, что путь не существует, и он сигнализирует службе приложений о том, что контейнер работоспособен и готов реагировать на запросы.