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

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

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

В этой статье содержатся основные понятия и инструкции для разработчиков Python, использующих встроенный контейнер Linux в службе приложений. Если вы никогда не использовали службу приложений, сначала выполните краткое руководство по 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, поддерживаемых в службе приложений с помощью az webapp list-runtimes:

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

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

Что происходит с устаревшими средами выполнения в сервисе приложений?

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

Если вы хотите создать приложение с устаревшей версией среды выполнения, которая больше не отображается на портале, используйте Azure CLI, шаблон ARM или Bicep. Эти варианты развертывания позволяют создавать устаревшие среды выполнения, удаленные с портала, но по-прежнему поддерживаются.

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

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

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

1. Запустите пользовательский скрипт предварительной сборки, если этот шаг указан параметром PRE_BUILD_COMMAND . (Скрипт может выполнять другие скрипты Python и Node.js скрипты, команды pip и npm, а также инструменты на основе узлов, yarn install например Yarn, и 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 пусты.

• Чтобы отключить выполнение 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".

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

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

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

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

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

Создайте requirements.txt с помощью поэзии с подключаемым модулем экспорта:

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

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

Создайте requirements.txt с помощью 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. Переменные среды. Если приложению требуются какие-либо переменные среды, создайте эквивалентные параметры приложения службы приложений. Эти параметры службы приложений отображаются в коде в виде переменных среды, как описано в переменных среды Access.

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

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

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

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

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

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

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

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

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

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

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

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

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

   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 выполняются в контейнере Docker Linux, определенном в репозитории GitHub службы приложений. Конфигурации образов можно найти в каталогах, относящихся к версии.

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

• Приложения выполняются 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.

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

Во время запуска служба приложений под управлением контейнера 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 that contains 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: По умолчанию служба приложений считает, что основной модуль приложения Flask называется application.py или app.py. Если основной модуль использует другое имя, необходимо настроить команду запуска. Например, если у вас есть приложение Flask, основной модуль которого hello.py и объект приложения Flask в этом файле называется myapp, это команда:

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

  Если основной модуль находится в подпапке, например веб-сайт, укажите папку с аргументом --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

Замените <app-name> и <resource-group-name> на имена, соответствующие вашему веб-приложению.

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

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

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

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

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

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

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

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

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

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

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

Если вы хотите открыть прямой сеанс SSH с контейнером, приложение должно работать.

Используйте команду az webapp ssh .

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

Чтобы открыть удаленный сеанс SSH с локального компьютера, см. раздел Open SSH session from remote shell.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Убедитесь, что приложение структурировано как служба приложений ожидает 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 для PostgreSQL.

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

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

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

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

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

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

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

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

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