Настройка приложения Python в Linux для Службы приложений Azure

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

Подсистема развертывания службы приложений автоматически активирует виртуальную среду и запускает pip install -r requirements.txt для вас при развертывании репозитория Git или при развертывании zip-пакетас включенной автоматизацией сборки.

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

Для настройки можно использовать портал Azure или Azure CLI.

• портал Azure, используйте страницу параметров>конфигурации приложения, как описано в разделе "Настройка приложения в Службе приложений" в портале Azure.

• В Azure CLI можно действовать двумя способами:

  • выполнять команды в Azure Cloud Shell;
  • запустить выполнение команд локально, установив последнюю версию Azure CLI, а затем войти в Azure с помощью команды az login.

Настройка версии Python

• портал Azure. Используйте вкладку "Общие параметры" на странице "Конфигурация", как описано в разделе "Настройка общих параметров для контейнеров Linux".

• Azure CLI.

  • Отобразите текущую версию Python с помощью команды az webapp config show.

    az webapp config show --resource-group <resource-group-name> --name <app-name> --query linuxFxVersion
    

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

  • Задайте версию Python с помощью команды az webapp config set.

    az webapp config set --resource-group <resource-group-name> --name <app-name> --linux-fx-version "PYTHON|3.11"
    

  • Отобразите все версии Python, поддерживаемые в Службе приложений Azure, с помощью команды az webapp list-runtimes.

    az webapp list-runtimes --os linux | grep PYTHON
    

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

Настройка автоматизации сборки

система сборки Службы приложений под названием Oryx выполняет следующие действия в процессе развертывания приложения, если параметру SCM_DO_BUILD_DURING_DEPLOYMENT приложения присвоено значение 1:

1. Запустите пользовательский скрипт предварительной сборки, если этот шаг указан параметром PRE_BUILD_COMMAND . (Этот скрипт может вызывать другие скрипты Python и Node.js, команды pip и npm, а также YARN и прочие средства на основе Node, например yarn install и yarn build.)

2. Запустите pip install -r requirements.txt. В корневой папке проекта должен присутствовать файл requirements.txt. В противном случае процесс сборки сообщает об ошибке: "Не удалось найти setup.py или requirements.txt; Не выполняется установка pip".

3. Если manage.py находится в корне репозитория (что характерно для приложения Django), запускает manage.py collectstatic. Однако если для параметра DISABLE_COLLECTSTATIC задано значение true, этот шаг пропускается.

4. Запустите пользовательский скрипт после сборки, если этот шаг указан параметром POST_BUILD_COMMAND . (Этот скрипт также может вызывать другие скрипты Python и Node.js, команды pip и npm и средства на основе Node.)

По умолчанию параметры PRE_BUILD_COMMAND, POST_BUILD_COMMAND и DISABLE_COLLECTSTATIC пусты.

• Чтобы отключить выполнение сбора статических файлов при создании приложений Django, задайте для параметра DISABLE_COLLECTSTATIC значение true.

• Чтобы выполнить команды предварительной сборки, установите параметр PRE_BUILD_COMMAND для содержимого команды, например echo Pre-build command, или укажите путь к файлу сценария относительно корня вашего проекта, например scripts/prebuild.sh. Во всех командах должны использоваться относительные пути к корневой папке проекта.

• Чтобы выполнить команды после сборки, укажите в параметре POST_BUILD_COMMAND либо команду, например echo Post-build command, либо путь к файлу скрипта относительно корневого каталога проекта, например scripts/postbuild.sh. Во всех командах должны использоваться относительные пути к корневой папке проекта.

Другие параметры, которые настраивают автоматизацию сборки, см. в разделе "Конфигурация Oryx".

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

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

Создайте requirements.txt из pyproject.toml

В данный момент служба приложений не поддерживает pyproject.toml напрямую. Если вы используете такие инструменты, как Poetry или uv, рекомендуется сгенерировать совместимый requirements.txt перед развертыванием в корневом каталоге вашего проекта.

Использование поэзии

Использование Poetry с подключаемым модулем экспорта:

poetry export -f requirements.txt --output requirements.txt --without-hashes

Использование uv

Использование uv:

uv export --format requirements-txt --no-hashes --output-file requirements.txt

Миграция существующих приложений в Azure

Существующие веб-приложения можно повторно развернуть в Azure следующим образом:

1. Исходный репозиторий: сохраняйте исходный код в подходящем репозитории, например GitHub, что позволяет настроить непрерывное развертывание позже в этом процессе.

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

2. База данных. Если приложение зависит от базы данных, создайте необходимые ресурсы в Azure.

3. Ресурсы службы приложений: создайте группу ресурсов, план службы приложений и веб-приложение службы приложений для размещения вашего приложения. Это можно сделать, выполнив команду az webapp upAzure CLI. Вы также можете создавать и развертывать ресурсы, как показано в руководстве по Flask, Django или FastAPI с помощью PostgreSQL. Замените имена группы ресурсов, плана службы приложений и веб-приложения, чтобы они были более подходящими для вашего приложения.

4. Переменные среды: если вашему приложению требуются переменные среды, создайте эквивалентные параметры службы приложений. Эти параметры службы приложений отображаются в вашем коде как переменные среды, как описано в Доступ к переменным среды.

   • Например, подключения к базе данных часто управляются с помощью таких параметров, как показано в руководстве. Развертывание веб-приложения Django с помощью PostgreSQL — проверка параметров подключения.
   • Сведения об определенных параметрах для конкретных приложений Django см. в разделе Параметры рабочей среды для приложений Django.

5. Запуск приложения. Просмотрите раздел "Процесс запуска контейнера" далее в этой статье, чтобы понять, как Служба приложений пытается запустить приложение. По умолчанию Служба приложений использует веб-сервер Gunicorn, который должен найти объект приложения или папку wsgi.py. Если вам нужно, можно настроить команду запуска.

6. Непрерывное развертывание: настройка непрерывного развертывания из GitHub Actions, Bitbucket или Azure Repos, как описано в статье "Непрерывное развертывание в службе приложение Azure". Или настройте непрерывное развертывание из локального репозитория Git, как описано в статье Локальное развертывание Git для службы приложений Azure.

7. Пользовательские действия. Чтобы выполнить действия в контейнере Служба приложений, в котором размещено приложение, например миграция базы данных Django, можно подключиться к контейнеру через SSH. Пример миграции базы данных Django см. в руководстве . Развертывание веб-приложения Django с помощью PostgreSQL — создание схемы базы данных.

   • При использовании непрерывного развертывания эти действия можно выполнить с помощью команд после сборки, как описано выше в разделе Настройка автоматизации сборки.

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

Параметры рабочей среды для приложений Django

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

В следующей таблице описаны параметры рабочей среды, относящиеся к Azure. Эти параметры определяются в файле setting.py приложения.

Обслуживание статических файлов для приложений Django

Если веб-приложение Django включает статические интерфейсные файлы, сначала следуйте инструкциям по управлению статическими файлами в документации Django.

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

1. Рекомендуем применить переменные среды (при локальной разработке) и параметры приложения (при развертывании в облаке) для динамической передачи значений STATIC_URL и STATIC_ROOT в Django. Например:

   STATIC_URL = os.environ.get("DJANGO_STATIC_URL", "/static/")
   STATIC_ROOT = os.environ.get("DJANGO_STATIC_ROOT", "./static/")    
   

   DJANGO_STATIC_URL и DJANGO_STATIC_ROOT можно изменять по мере необходимости для локальных и облачных сред. Например, если в процессе сборки статических файлов они помещаются в папку с именем django-static, вы можете задать для DJANGO_STATIC_URL значение /django-static/ вместо значения по умолчанию.

2. Если у вас есть выполняемый перед сборкой скрипт, с помощью которого создаются статические файлы в другой папке, включите эту папку в переменную Django STATICFILES_DIRS, чтобы процесс collectstatic в Django смог их найти. Например, если вы запускаете yarn build в папке вашего фронтенда, и yarn создает папку build/static со статическими файлами, включите эту папку вот как:

   FRONTEND_DIR = "path-to-frontend-folder" 
   STATICFILES_DIRS = [os.path.join(FRONTEND_DIR, 'build', 'static')]    
   

   Здесь FRONTEND_DIR используется для построения пути к месту, где запускается средство сборки, такое как yarn. Как обычно, вы можете использовать переменную среды и параметр приложения на свое усмотрение.

3. Добавьте whitenoise в файл requirements.txt. WhiteNoise (whitenoise.evans.io) — это пакет Python, который упрощает обслуживание собственных статических файлов в рабочем приложении Django. WhiteNoise специально обслуживает те файлы, которые находятся в папке, указанной переменной Django STATIC_ROOT .

4. В файле settings.py добавьте следующую строку для WhiteNoise:

   STATICFILES_STORAGE = ('whitenoise.storage.CompressedManifestStaticFilesStorage')
   

5. Кроме того, измените списки MIDDLEWARE и INSTALLED_APPS, чтобы включить WhiteNoise.

   MIDDLEWARE = [                                                                   
       'django.middleware.security.SecurityMiddleware',
       # Add whitenoise middleware after the security middleware                             
       'whitenoise.middleware.WhiteNoiseMiddleware',
       # Other values follow
   ]
   
   INSTALLED_APPS = [
       "whitenoise.runserver_nostatic",
       # Other values follow
   ]
   

Обслуживание статических файлов для приложений Flask

Если веб-приложение Flask содержит статические файлы для интерфейса, сначала выполните инструкции из раздела об управлении статическими файлами в документации по Flask. Для примера подачи статических файлов в приложении Flask смотрите пример приложения Flask на GitHub.

Чтобы выдавать статические файлы непосредственно из маршрута в приложении, можно использовать метод send_from_directory:

from flask import send_from_directory

@app.route('/reports/<path:path>')
def send_report(path):
    return send_from_directory('reports', path)

Характеристики контейнера

При развертывании в Службе приложений приложения Python выполняются в контейнере Linux Docker, который определен в репозитории GitHub App Service для Python. Конфигурации образов можно найти в каталогах для конкретных версий.

Этот контейнер отличается следующими характеристиками.

• Приложения выполняются с помощью HTTP-сервера Gunicorn WSGI, используя дополнительные аргументы --bind=0.0.0.0 --timeout 600.

  • Вы можете указать параметры конфигурации для Gunicorn, настроив команду запуска.

  • Чтобы защитить веб-приложение от случайных или преднамеренных атак DDOS, Gunicorn выполняется за обратным прокси-сервером Nginx, как описано в статье "Развертывание Gunicorn".

• По умолчанию базовый образ контейнера включает в себя только веб-платформу Flask, но контейнер также поддерживает другие платформы, совместимые с WSGI и Python 3.6 и более новых версий, например Django.

• Чтобы установить другие пакеты, например Django, создайте файл requirements.txt в корне проекта, который указывает прямые зависимости. Тогда Служба приложений автоматически установит эти зависимости при развертывании проекта.

  Для установки зависимостей файл requirements.txtдолжен находиться в корневой папке проекта. В противном случае в процессе сборки будет выводиться сообщение об ошибке: "Не удалось найти setup.py или requirements.txt; "Не запущена установка PIP." При возникновении этой ошибки проверьте расположение файла требований.

• Служба приложений автоматически определяет переменную среды с именем WEBSITE_HOSTNAME, используя URL-адрес веб-приложения, например msdocs-hello-world.azurewebsites.net. Она также определяет WEBSITE_SITE_NAME, используя имя приложения, например msdocs-hello-world.

• npm и Node.js устанавливаются в контейнере, что позволяет запускать YARN и другие средства сборки на основе Node.

Процесс запуска контейнера

Во время запуска служба приложений под управлением контейнера Linux выполнит следующие действия.

1. Используйте настраиваемую команду запуска, если она указана.
2. Проверьте наличие приложения Django и запустите Gunicorn для него, если такое приложение обнаружено.
3. Проверьте наличие приложения Flask и запустите Gunicorn для него, если оно обнаружено.
4. Если другие приложения не найдены, запускается приложение по умолчанию, встроенное в контейнер.

В следующих разделах приведены дополнительные сведения для каждого варианта.

Приложение Django

Для приложений Django служба приложений выполняет поиск файла с именем wsgi.py в вашем коде приложения, а затем запускает Gunicorn, используя следующую команду:

# <module> is the name of the folder that contains wsgi.py
gunicorn --bind=0.0.0.0 --timeout 600 <module>.wsgi

Если требуется более конкретный контроль над командой запуска, используйте пользовательскую команду запуска, замените <module> имя папки, содержащей wsgi.py, и добавьте --chdir аргумент, если этот модуль не входит в корневой каталог проекта. Например, если wsgi.py находится во вложенной папке knboard/backend/config корневой папки проекта, используйте аргументы --chdir knboard/backend config.wsgi.

Чтобы включить ведение журнала в рабочей среде, добавьте параметры --access-logfile и --error-logfile, как показано в примерах пользовательских команд запуска.

Приложение Flask

Для Flask Служба приложений выполняет поиск файла с именем application.py или app.py и запускает Gunicorn следующим образом:

# If application.py
gunicorn --bind=0.0.0.0 --timeout 600 application:app

# If app.py
gunicorn --bind=0.0.0.0 --timeout 600 app:app

Если основной модуль приложения содержится в другом файле, используйте другое имя для объекта приложения. Если вы хотите предоставить другие аргументы Gunicorn, используйте настраиваемую команду запуска.

Поведение по умолчанию

Если в Службе приложений не найдена пользовательская команда, приложение Django или Flask, тогда она запускает приложение по умолчанию с разрешением только для чтения, расположенное в папке opt/defaultsite (как показано на следующем изображении).

Если вы уже развернули код, но по-прежнему видите приложение по умолчанию, перейдите к разделу устранения неполадок (Приложение не отображается).

Настройка команды запуска

Для управления поведением при запуске контейнера можно указать в файле команд запуска пользовательскую команду запуска или несколько команд. Для файла команд запуска можно использовать любое выбранное имя, например startup.sh, startup.cmd, startup.txt и т. д.

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

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

• Портал Azure. Перейдите на страницу Конфигурация приложения, а затем выберите Общие параметры. В поле Команда запуска вставьте полный текст команды запуска либо укажите имя файла команд запуска. Затем нажмите кнопку Сохранить, чтобы применить изменения. Сведения о контейнерах Linux см. в разделе Настройка общих параметров.

• Azure CLI. Используйте команду az webapp config set с параметром --startup-file, чтобы задать команду или файл запуска.

  az webapp config set --resource-group <resource-group-name> --name <app-name> --startup-file "<custom-command>"
  

  Замените <custom-command> полным текстом команды запуска или именем файла команд запуска.

Служба приложений игнорирует все ошибки, происходящие при обработке пользовательской команды или файла запуска, и продолжает процесс запуска путем поиска приложений Django и Flask. Если вы не видите ожидаемого поведения, убедитесь, что команда запуска или файл не содержат ошибок, и что файл команды запуска развертывается в Службе приложений вместе с кодом вашего приложения. Вы также можете проверить журналы диагностики для получения дополнительных сведений . Просмотрите также страницу Диагностика и решение проблем на портале Azure.

Примеры команд запуска

• Аргументы Gunicorn добавлены: следующий пример добавляет аргумент --workers=4 в командную строку Gunicorn для запуска приложения Django.

  # <module-path> is the relative path to the folder that contains the module
  # that contains wsgi.py; <module> is the name of the folder containing wsgi.py.
  gunicorn --bind=0.0.0.0 --timeout 600 --workers=4 --chdir <module_path> <module>.wsgi
  

  Дополнительные сведения см. в разделе «Запуск Gunicorn». Если вы используете правила автоматического масштабирования для масштабирования веб-приложения вверх и вниз, необходимо также динамически задать количество рабочих ролей Gunicorn с помощью NUM_CORES переменной среды в команде запуска, например: --workers $((($NUM_CORES*2)+1)) Дополнительные сведения о настройке рекомендуемого количества работников Gunicorn см. в разделе часто задаваемых вопросов о Gunicorn.

• Включите ведение журнала для Django: добавьте аргументы --access-logfile '-' и --error-logfile '-' в командную строку:

  # '-' for the log files means stdout for --access-logfile and stderr for --error-logfile.
  gunicorn --bind=0.0.0.0 --timeout 600 --workers=4 --chdir <module_path> <module>.wsgi --access-logfile '-' --error-logfile '-'
  

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

  Дополнительные сведения см. в разделе логирование Gunicorn.

• Пользовательский основной модуль Flask: по умолчанию служба App Service считает, что основной модуль Flask-приложения — это application.py или app.py. Если у основного модуля другое имя, необходимо настроить команду запуска. Например, если вы используете приложение Flask, главным модулем которого является hello.py, и объект приложения Flask в этом файле имеет имя myapp, тогда команда будет выглядеть следующим образом:

  gunicorn --bind=0.0.0.0 --timeout 600 hello:myapp
  

  Если главный модуль находится в подпапке, например website, укажите эту подпапку с помощью аргумента --chdir:

  gunicorn --bind=0.0.0.0 --timeout 600 --chdir website hello:myapp
  

• Используйте сервер, отличный от Gunicorn: чтобы использовать другой веб-сервер, например aiohttp, используйте соответствующую команду в качестве команды запуска или в файле команды запуска:

  python3.7 -m aiohttp.web -H localhost -P 8080 package.module:init_func
  

Доступ к параметрам приложения в виде переменных среды

Параметры приложения — это значения, хранящиеся в облаке специально для приложения, как описано в разделе "Настройка параметров приложения". Эти параметры доступны для кода приложения в виде переменных среды и вызываются с помощью стандартного шаблона os.environ.

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

db_server = os.environ['DATABASE_SERVER']

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

В Службе приложений завершение TLS/SSL-запросов происходит в подсистеме балансировки нагрузки сети, поэтому все HTTPS-запросы достигают вашего приложения в виде незашифрованных HTTP-запросов. Если логика вашего приложения проверяет, зашифрованы ли пользовательские запросы, проверяйте заголовок X-Forwarded-Proto.

if 'X-Forwarded-Proto' in request.headers and request.headers['X-Forwarded-Proto'] == 'https':
# Do something when HTTPS is used

Популярные веб-платформы позволяют получить доступ к информации X-Forwarded-* в стандартном шаблоне приложения. Например, в Django можно использовать SECURE_PROXY_SSL_HEADER для того, чтобы сообщить Django, чтобы он использовал X-Forwarded-Proto заголовок.

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

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

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

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

Замените #D0 и #D1 именами, подходящими для веб-приложения.

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

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

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

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

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

Чтобы получить доступ к журналам с помощью портала Azure, в приложении в меню слева выберите Мониторинг>Поток журналов.

Доступ к журналам развертывания

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

Чтобы открыть журналы развертывания, выполните указанные ниже действия:

1. На портале Azure для вашего веб-приложения выберите в меню слева Развертывание>Центр развертывания.
2. На вкладке Журналы выберите Идентификатор коммита для последнего коммита.
3. На появившейся странице журнала со сведениями выберите ссылку "Показать журналы", которая отображается рядом с пунктом "Запуск сборки oryx...".

В этих журналах отображаются проблемы со сборкой, такие как неверные зависимости в файле requirements.txt или ошибки в скриптах, выполняемых до или после сборки. Ошибки также отображаются, если файл требований не называется requirements.txt или не отображается в корневой папке проекта.

Открытие сеанса SSH в браузере

Чтобы открыть прямой сеанс SSH с контейнером, ваше приложение должно быть запущено.

Вставьте следующий URL-адрес в браузер и замените <имя> приложения именем приложения:

https://<app-name>.scm.azurewebsites.net/webssh/host

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

Чтобы открыть удаленный сеанс SSH на локальном компьютере см. инструкцию в разделе Открытие сеанса SSH из удаленной оболочки.

После успешного подключения к сеансу SSH в нижней части окна должно отобразиться сообщение SSH CONNECTION ESTABLISHED (SSH-соединение установлено). Если вы видите такие ошибки, как "SSH_CONNECTION_CLOSED", или сообщение о том, что контейнер перезапускается, ошибка может препятствовать запуску контейнера приложения. Действия по исследованию возможных проблем см. в разделе Устранение неполадок.

Перезаписи URL-адресов

При развертывании приложений Python в службе приложение Azure для Linux может потребоваться обрабатывать перезаписи URL-адресов в приложении. Это особенно полезно для обеспечения перенаправления определенных шаблонов URL-адресов на правильные конечные точки без использования конфигураций внешнего веб-сервера. Для приложений Flask можно использовать обработчики URL-адресов и пользовательское ПО промежуточного слоя для этого. В приложениях Django надежный диспетчер URL-адресов позволяет эффективно управлять перезаписями URL-адресов.

Устранение неполадок

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

1. В портале Azure для вашего веб-приложения выберите "Диагностика и решение проблем" в меню слева.
2. Выберите Доступность и производительность.
3. Изучите сведения в журналах приложений, сбоях контейнеров и проблемах с контейнерами, где будут отображаться наиболее распространенные проблемы.

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

В следующих разделах приведены рекомендации по конкретным проблемам.

• Приложение не отображается — отображается приложение по умолчанию
• Приложение не отображается — выдается сообщение "Служба недоступна"
• Не удалось найти setup.py или requirements.txt
• Ошибка ModuleNotFoundError при запуске
• База данных заблокирована
• Пароли не отображаются при вводе в сеансе SSH
• Команды в сеансе SSH обрываются
• Статические ресурсы не отображаются в приложении Django
• Критическое SSL-соединение требуется

Приложение не отображается

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

  • Перезапустите службу приложений, подождите 15–20 секунд и снова проверьте приложение.

  • Используйте SSH для подключения непосредственно к контейнеру Службы приложений и убедитесь, что нужные файлы находятся в каталоге site/wwwroot. Если файлов здесь нет, выполните следующие действия:

    1. Создайте параметр приложения с именем SCM_DO_BUILD_DURING_DEPLOYMENT и значением 1, повторно разверните код, подождите несколько минут и снова попробуйте открыть его. Дополнительные сведения о создании параметров приложений см. в статье Настройка приложения Службы приложений на портале Azure.
    2. Проверьте процесс развертывания, затем проверьте журналы развертывания, исправьте все ошибки и повторно разверните приложение.

  • Если файлы имеются, значит службе приложений не удалось определить конкретный загрузочный файл. Убедитесь, что ваше приложение структурировано в соответствии с ожиданиями App Service для Django или Flask, или используйте пользовательскую команду запуска.

• В браузере появится сообщение "Служба недоступна". В браузере истекло время ожидания ответа от Служба приложений, которое указывает, что Служба приложений запустил сервер Gunicorn, но само приложение не началось. Это может означать, что аргументы Gunicorn неверны или в коде приложения есть ошибка.

  • Обновите браузер, особенно если вы используете самый низкий ценовой уровень в плане службы приложений. Приложение может занять больше времени для запуска при использовании бесплатных уровней, например, и становится адаптивным после обновления браузера.

  • Убедитесь, что ваше приложение структурировано в соответствии с ожиданиями App Service для Django или Flask, или используйте пользовательскую команду запуска.

  • Проверьте, нет ли в потоке журналов приложения сообщений об ошибках. В этих журналах отобразятся любые ошибки в коде приложения.

Не удалось найти setup.py или requirements.txt

• В потоке журнала отображается сообщение "Не удалось найти setup.py или requirements.txt; Не запущена установка pip.": процессу сборки Oryx не удалось найти ваш файл requirements.txt

  • Подключитесь к контейнеру веб-приложения через SSH и убедитесь, что файл requirements.txt имеет правильное имя и размещен в папке site/wwwroot. Если он не существует, убедитесь, что файл существует в репозитории и включен в развертывание. Если он находится в отдельной папке, переместите его в корневую папку.

Ошибка ModuleNotFoundError при запуске приложения

Если вы видите ошибку, например ModuleNotFoundError: No module named 'example', Python не удалось найти один или несколько модулей при запуске приложения. Эта ошибка чаще всего возникает при развертывании виртуальной среды с помощью кода. Виртуальные среды не переносимы, поэтому виртуальная среда не должна быть развернута с кодом приложения. Вместо этого позвольте Oryx создать виртуальную среду и установить пакеты в веб-приложение, создав параметр приложения SCM_DO_BUILD_DURING_DEPLOYMENT и задав для него значение 1. Этот параметр заставит Oryx устанавливать ваши пакеты при каждом развертывании на службе приложений. Дополнительные сведения см. в этой статье о переносимости виртуальной среды.

База данных заблокирована

При попытке выполнить миграцию базы данных с приложением Django может появиться сообщение "sqlite3". "OperationalError: база данных заблокирована." Эта ошибка указывает на то, что ваше приложение использует базу данных SQLite, которую Django настроено использовать по умолчанию, вместо облачной базы данных, например, Azure Database для PostgreSQL.

Проверьте переменную DATABASES в файле приложения settings.py, чтобы убедиться, что приложение использует облачную базу данных вместо SQLite.

Если вы столкнулись с этой ошибкой с примером в руководстве по развертыванию веб-приложения Django с помощью PostgreSQL, убедитесь, что вы выполнили действия, описанные в разделе "Проверка параметров подключения".

Другие проблемы

• Пароли не отображаются в сеансе SSH при вводе: по соображениям безопасности сеанс SSH сохраняет пароль скрытым при вводе. Тем не менее, символы записываются; поэтому введите пароль как обычно и нажмите клавишу Enter.

• Команды в сеансе SSH, по-видимому, обрезаются: редактор может не переносить команды по словам, но они по-прежнему должны выполняться правильно.

• Статические ресурсы не отображаются в приложении Django: убедитесь, что модуль "WhiteNoise" включён.

• Появится сообщение "Критическое SSL-соединение обязательно": проверьте все имена пользователей и пароли, используемые для доступа к ресурсам (например, базам данных) из приложения.

Связанный контент

• Руководство: Приложение Flask с PostgreSQL
• Руководство по приложению Django с PostgreSQL
• Руководство: Приложение FastAPI с PostgreSQL
• Руководство: Развертывание из частного репозитория контейнеров
• Служба приложений под управлением Linux: вопросы и ответы
• Справка по переменным среды и параметрам приложений