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

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

  • Статья

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

Подсистема развертывания Службы приложений Azure автоматически активирует виртуальное окружение и запускает команду 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. В противном случае процесс сборки сообщает об ошибке: "Не удалось найти 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.

Примечание.

Параметры 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". Или настройте непрерывное развертывание из Local 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: В следующем примере добавляется --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

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

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

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

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

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

  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

  • В потоке журнала отображается сообщение "Не удалось найти 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. Этот параметр принудительно устанавливает пакеты при развертывании в Служба приложений. Дополнительные сведения см. в этой статье о переносимости виртуальных сред.

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

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

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

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

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

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

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

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

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

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