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

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

Развертывание в Azure

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

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

Примечание.

В настоящее время служба приложений требует requirements.txt в корневом каталоге вашего проекта, даже если у вас есть pyproject.toml. См. Раздел "Создание requirements.txt из pyproject.toml" для получения рекомендаций.

Это руководство содержит основные понятия и инструкции для разработчиков Python, которые используют встроенный контейнер Linux в Службе приложений. Если вы никогда не использовали службу приложений Azure, сначала следуйте краткому руководству по Python и Flask, Django или FastAPI с помощью 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.

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

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

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

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

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

Примечание.

При развертывании приложений Python с использованием автоматизации сборки содержимое будет развертываться и обслуживаться из /tmp/<uid>, а не под /home/site/wwwroot. Этот каталог содержимого APP_PATH можно получить через переменную среды. Все дополнительные файлы, созданные во время выполнения программы, должны быть записаны в расположение /home или с помощью собственного хранилища для долговременного хранения. Дополнительные сведения об этом поведении см. здесь.

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

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

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

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

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

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

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

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

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

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

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

Дополнительные сведения о том, как служба приложений выполняет и создает приложения 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, команды az webapp up Azure CLI и Visual Studio Code.

Примечание.

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

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

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

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

Использование Poetry с плагином экспорта:


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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Настройка Django Инструкции для Azure
SECRET_KEY Сохраните значение в параметре службы приложений, как описано в параметрах приложения Access в качестве переменных среды. Можно также сохранить значение в качестве секрета в 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. Кроме того, измените списки 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 и другие средства сборки на основе 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

    Дополнительные сведения см. в разделе "Запуск 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

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

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

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

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

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

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

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

db_server = os.environ['DATABASE_SERVER']

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

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

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

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

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

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

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

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

Замените <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

Примечание.

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

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

После успешного подключения к сеансу 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 для подключения непосредственно к контейнеру службы приложений и убедитесь, что файлы существуют на сайте или 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 Database для PostgreSQL.

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

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

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

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

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

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

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

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