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

  • Статья

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

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

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

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

Примечание

Linux — это единственный вариант операционной системы для запуска приложений Python в Служба приложений. Python в Windows больше не поддерживается. Однако вы можете создать собственный пользовательский образ контейнера Windows и запустить его в Служба приложений. Дополнительные сведения см. в статье об использовании пользовательского образа Docker.

Настройка версии 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.

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

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

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

  2. Выполните pip install -r requirements.txt. В корневой папке проекта должен присутствовать файл requirements.txt. В противном случае в процессе сборки будет выведено сообщение об ошибке: Could not find setup.py or requirements.txt; Not running pip install (Не удалось найти 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.

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

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

Примечание

Параметры PRE_BUILD_SCRIPT_PATH и POST_BUILD_SCRIPT_PATH идентичны PRE_BUILD_COMMAND и POST_BUILD_COMMAND и поддерживаются из соображений совместимости с прежними версиями.

Если параметр с именем SCM_DO_BUILD_DURING_DEPLOYMENT содержит значение true или 1, он запускает сборку в Oryx во время развертывания. Этот параметр имеет значение true при развертывании с помощью Git, команды Azure CLI, az webapp up и Visual Studio Code.

Примечание

Во всех скриптах, выполняемых до и после сборки, следует всегда использовать относительные пути, поскольку контейнер сборки, в котором выполняется Oryx, отличается от контейнера среды выполнения, в котором выполняется приложение. Никогда не полагайтесь на точное размещение папки проекта приложения в контейнере (например, размещение в папке site/wwwroot).

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

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

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

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

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

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

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

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

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

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

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

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

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

В такой рабочей среде, как Служба приложений Azure, для приложений Django необходимо придерживаться контрольного списка развертывания (djangoproject.com).

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

Настройка Django Инструкции для Azure
SECRET_KEY Сохраните значение в настройках Службы приложений, как описано в разделе Доступ к параметрам приложения в виде переменных среды. Можно также сохранить значение в качестве секрета в Azure Key Vault.
DEBUG Создайте параметр DEBUG в Службе приложений со значением 0 (false), а затем загрузите значение как переменную среды. В среде разработки создайте переменную среды DEBUG со значением 1 (true).
ALLOWED_HOSTS В рабочей среде для Django требуется включить URL-адрес приложения в массив ALLOWED_HOSTS в settings.py. Этот URL-адрес можно получить во время выполнения с помощью кода os.environ['WEBSITE_HOSTNAME']. Служба приложений автоматически задает в качестве значения переменной среды WEBSITE_HOSTNAME URL-адрес приложения.
DATABASES Определите параметры в Службе приложений для подключения к базе данных и загрузите их в виде переменных среды, чтобы заполнить словарь DATABASES. Можно также сохранить значения (особенно имя пользователя и пароль) в виде секретов Azure Key Vault.

Выдача статических файлов для приложений 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. Также включите Whitenoise в списки MIDDLEWARE и INSTALLED_APPS:

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

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

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

  • По умолчанию базовый образ контейнера включает в себя только веб-платформу 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 (как показано на следующем изображении).

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

Снимок экрана: веб-страница Служба приложений в Linux по умолчанию.

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

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

Для управления поведением при запуске контейнера можно указать в файле команд запуска пользовательскую команду запуска или несколько команд. Для файла команд запуска можно использовать любое выбранное имя, например 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. В следующем примере в командную строку Gunicorn для запуска приложения Django добавляется --workers=4.

    # <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

    Дополнительные сведения см. в статье Running Gunicorn (Запуск Gunicorn) (docs.gunicorn.org). Если вы используете правила автоматического масштабирования для увеличения и уменьшения масштаба веб-приложения, необходимо также динамически задать количество рабочих ролей 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 (docs.gunicorn.org).

  • Пользовательский основной модуль Flask. По умолчанию Служба приложений предполагает, что основной модуль приложения 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

В Службе приложений Azure завершение TLS/SSL-запросов (wikipedia.org) происходит в подсистемах балансировки нагрузки сети, поэтому все 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.

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

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

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

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

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

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

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

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

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

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

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

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

SSL-подключение

Примечание

Любые изменения, внесенные не в каталоге /home, сохраняются в самом контейнере и не применяются до перезапуска приложения.

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

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

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

Как правило, при устранении неполадок прежде всего нужно проверить данные диагностики Службы приложений:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • В потоке журналов отображается сообщение Could not find setup.py or requirements.txt; Not running pip install (Не удалось найти 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, а не облачную базу данных, например PostgreSQL для Azure.

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

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

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

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

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

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

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

Дополнительные ресурсы