Compartir a través de

Configuración de una aplicación de Python en Linux para Azure App Service

  • Artículo

En este artículo se describe cómo Azure App Service ejecuta aplicaciones de Python, cómo migrar aplicaciones existentes a Azure y cómo personalizar el comportamiento de App Service cuando es necesario. Las aplicaciones de Python deben implementarse con todos los módulos pip requeridos.

El motor de implementación de App Service activa de manera automática un entorno virtual y ejecuta pip install -r requirements.txt automáticamente cuando se implementa un repositorio de Git o un paquete Zip con la automatización de la compilación habilitada.

En esta guía se incluyen conceptos clave e instrucciones para los desarrolladores de Python que usan un contenedor Linux integrado en App Service. Si nunca ha usado Azure App Service, siga primero el inicio rápido de Python y el tutorial de Python con PostgreSQL.

Puede usar Azure Portal o la CLI de Azure para la configuración:

Nota

Linux es la única opción de sistema operativo para ejecutar aplicaciones de Python en App Service. Python en Windows ya no se admite. Sin embargo, puede crear su propia imagen personalizada de contenedor de Windows y ejecutarla en App Service. Para más información, consulte Uso de una imagen personalizada de Docker.

Configuración de la versión de Python

  • Azure Portal: use la pestaña Configuración general de la página Configuración, como se describe en Configuración de los valores generales para contenedores Linux.

  • CLI de Azure:

    • Muestre la versión actual de Python con az webapp config show:

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

      Reemplace <resource-group-name> y <app-name> por los nombres adecuados para su aplicación web.

    • Establezca la versión de Python con az webapp config set.

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

    • Muestre todas las versiones de Python que se admiten en Azure App Service con az webapp list-runtimes:

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

Para ejecutar una versión no compatible de Python, cree una imagen de su propio imagen de contenedor. Para más información, consulte Uso de una imagen personalizada de Docker.

Personalización de la automatización de compilaciones

El sistema de compilación de App Service, denominado Oryx, realiza los pasos siguientes al implementar la aplicación, si el valor SCM_DO_BUILD_DURING_DEPLOYMENT de la aplicación está establecido en 1:

  1. Ejecute un script anterior a la compilación personalizado si ese paso lo especifica el valor PRE_BUILD_COMMAND. (El script puede a su vez ejecutar otros scripts de Python y Node.js, comandos pip y npm, y herramientas basadas en nodos como Yarn; por ejemplo, yarn install y yarn build).

  2. Ejecute pip install -r requirements.txt. El archivo requirements.txt debe estar dentro de la carpeta raíz del proyecto. De lo contrario, el proceso de compilación notifica el error: "Could not find setup.py or requirements.txt; Not running pip install" (No se pudo encontrar setup.py o requirements.txt; no se ejecutará la instalación de PIP).

  3. Si manage.py se encuentra en la raíz del repositorio (lo que indica una aplicación de Django), ejecute manage.py collectstatic. Sin embargo, si el valor DISABLE_COLLECTSTATIC es true, se omitirá este paso.

  4. Ejecute el script posterior a la compilación personalizado si ese paso lo especifica el valor POST_BUILD_COMMAND. (De nuevo, el script puede ejecutar otros scripts de Python y Node.js, comandos pip y npm, y herramientas basadas en nodos).

De forma predeterminada, los valores PRE_BUILD_COMMAND, POST_BUILD_COMMAND y DISABLE_COLLECTSTATIC están vacíos.

  • Para deshabilitar la ejecución de collectstatic al compilar aplicaciones de Django, establezca DISABLE_COLLECTSTATIC en true.

  • Para ejecutar comandos anteriores a la compilación, establezca el valor PRE_BUILD_COMMAND para que contenga un comando, como echo Pre-build command, o una ruta de acceso a un archivo de script relativa a la raíz del proyecto, como scripts/prebuild.sh. Todos los comandos deben usar rutas de acceso relativas a la carpeta raíz del proyecto.

  • Para ejecutar comandos posteriores a la compilación, establezca el valor POST_BUILD_COMMAND para que contenga un comando, como echo Post-build command, o una ruta de acceso a un archivo de script relativa a la raíz del proyecto, como scripts/postbuild.sh. Todos los comandos deben usar rutas de acceso relativas a la carpeta raíz del proyecto.

Puede encontrar otros valores que personalicen la automatización de la compilación en Configuración de Oryx.

Para acceder a los registros de compilación e implementación, consulte Acceso a los registros de implementación.

Para más información sobre cómo App Service ejecuta y compila aplicaciones de Python en Linux, consulte Cómo Oryx detecta y compila aplicaciones de Python.

Nota

Los valores PRE_BUILD_SCRIPT_PATH y POST_BUILD_SCRIPT_PATH son idénticos a PRE_BUILD_COMMAND y POST_BUILD_COMMAND, que se pueden usar como valores heredados.

Un valor denominado SCM_DO_BUILD_DURING_DEPLOYMENT, si contiene true o 1, desencadena una compilación de Oryx durante la implementación. El valor es true cuando se implementa con Git, el comando az webapp up de la CLI de Azure y Visual Studio Code.

Nota:

Use siempre rutas de acceso relativas en todos los scripts anteriores y posteriores a la compilación, ya que el contenedor de compilación en el que se ejecuta Oryx es diferente del contenedor en tiempo de ejecución en el que se ejecuta la aplicación. Nunca confíe en la ubicación exacta de la carpeta de proyecto de la aplicación dentro del contenedor (por ejemplo, si está ubicada en site/wwwroot).

Migración de aplicaciones existentes a Azure

Las aplicaciones web existentes se pueden volver a implementar en Azure de la siguiente manera:

  1. Repositorio de origen: mantenga el código fuente en un repositorio adecuado como GitHub, que permite configurar la implementación continua más adelante en este proceso.

    • El archivo requirements.txt debe estar en la raíz del repositorio para que App Service instale automáticamente los paquetes necesarios.

  2. Base de datos: si la aplicación depende de una base de datos, cree también los recursos necesarios en Azure.

  3. Recursos de App Service: cree un grupo de recursos, un plan de App Service y una aplicación web de App Service para hospedar la aplicación. Puede hacerlo fácilmente mediante la ejecución del comando az webapp up de la CLI de Azure. O bien, puede crear e implementar recursos como se indica en Tutorial: Implementación de una aplicación web Python Django o Flask con PostgreSQL. Reemplace los nombres del grupo de recursos, el plan de App Service y la aplicación web para adaptarlos mejor a la aplicación.

  4. Variables de entorno: si la aplicación requiere alguna variable de entorno, cree una configuración de aplicación de App Service equivalente. Estos valores de App Service se muestra en el código como variables de entorno, como se describe en Acceso a variables de entorno.

  5. Inicio de la aplicación: revise la sección Proceso de inicio del contenedor más adelante en este artículo para entender cómo App Service intenta ejecutar la aplicación. App Service usa el servidor web Gunicorn de forma predeterminada, que debe poder encontrar el objeto de aplicación o la carpeta wsgi.py. Si es necesario, puede personalizar el comando de inicio.

  6. Implementación continua: configure la implementación continua desde GitHub Actions, Bitbucket o Azure Repos como se indica en el artículo Implementación continua en Azure App Service. O bien, configure la implementación continua desde Git local como se describe en el artículo Implementación de Git local en Azure App Service.

  7. Acciones personalizadas: para realizar acciones en el contenedor de App Service que hospeda la aplicación, como migraciones de base de datos de Django, puede conectarse al contenedor mediante SSH. Para obtener un ejemplo de cómo ejecutar migraciones de base de datos de Django, consulte Tutorial: Implementación de una aplicación web Django con PostgreSQL: generación de un esquema de base de datos.

Una vez realizados estos pasos, debe poder confirmar los cambios en el repositorio de origen y hacer que dichas actualizaciones se implementen automáticamente en App Service.

Configuración de producción para aplicaciones de Django

En un entorno de producción como Azure App Service, las aplicaciones de Django deben seguir la lista de comprobación de implementación de Django.

En la tabla siguiente se describe la configuración de producción que es pertinente para Azure. Esta configuración se define en el archivo setting.py de la aplicación.

Valor de Django Instrucciones para Azure
SECRET_KEY Almacene el valor en un valor de configuración de App Service, como se describe en Acceso a la configuración de la aplicación como variables de entorno. Como alternativa, almacene el valor como un secreto en Azure Key Vault.
DEBUG Cree un valor DEBUG en App Service con el valor 0 (false) y, luego, cargue el valor como una variable de entorno. En el entorno de desarrollo, cree una variable de entorno DEBUG con el valor 1 (true).
ALLOWED_HOSTS En producción, Django necesita que incluya la dirección URL de la aplicación en la matriz ALLOWED_HOSTS de settings.py. Puede recuperar esta dirección URL en tiempo de ejecución con el código os.environ['WEBSITE_HOSTNAME']. App Service establece automáticamente la variable de entorno WEBSITE_HOSTNAME en la dirección URL de la aplicación.
DATABASES Defina la configuración en App Service para la conexión de base de datos y cárguela como variables de entorno para rellenar el diccionario DATABASES. También puede almacenar los valores (especialmente el nombre de usuario y la contraseña) como secretos de Azure Key Vault.

Servicio de archivos estáticos para aplicaciones Django

Si la aplicación web de Django incluye archivos de front-end estáticos, siga primero las instrucciones de administración de archivos estáticos en la documentación de Django.

Para App Service, haga las siguientes modificaciones:

  1. Considere la posibilidad de usar variables de entorno (para el entorno de desarrollo local) y la configuración de aplicaciones (para el entorno en la nube) para establecer dinámicamente las variables STATIC_URL y STATIC_ROOT de Django. Por ejemplo:

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

    DJANGO_STATIC_URL y DJANGO_STATIC_ROOT pueden cambiar según sea necesario para los entornos local y en la nube. Por ejemplo, si el proceso de compilación de los archivos estáticos los coloca en una carpeta denominada django-static, puede establecer DJANGO_STATIC_URL en /django-static/ para evitar usar el valor predeterminado.

  2. Si tiene un script anterior a la compilación que genera archivos estáticos en una carpeta diferente, incluya esa carpeta en la variable STATICFILES_DIRS de Django para que el proceso collectstatic de Django los encuentre. Por ejemplo, si ejecuta yarn build en la carpeta front-end y Yarn genera una carpeta build/static que contiene archivos estáticos, incluya esa carpeta tal y como se indica a continuación:

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

    En este caso, se usa FRONTEND_DIR para crear una ruta de acceso a la ubicación en la que se ejecuta una herramienta de compilación como yarn. Puede volver a usar una variable de entorno y la configuración de la aplicación según sus necesidades.

  3. Agregue whitenoise al archivo requirements.txt. WhiteNoise (whitenoise.evans.io) es un paquete de Python que facilita que una aplicación Django de producción pueda servir sus propios archivos estáticos. WhiteNoise concretamente sirve los archivos que se encuentran en la carpeta especificada por la variable STATIC_ROOT de Django.

  4. En el archivo settings.py, agregue la línea siguiente para WhiteNoise:

    STATICFILES_STORAGE = ('whitenoise.storage.CompressedManifestStaticFilesStorage')

  5. Modifique también las listas de MIDDLEWARE y INSTALLED_APPS para incluir 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
]

Servicio de archivos estáticos para aplicaciones Flask

Si la aplicación web de Flask incluye archivos front-end estáticos, siga primero las instrucciones de administración de archivos estáticos en la documentación de Flask. Para obtener un ejemplo de servicio de archivos estáticos en una aplicación de Flask, vea la aplicación Flask de ejemplo en GitHub.

Para atender archivos estáticos directamente desde una ruta en la aplicación, puede usar el método send_from_directory:

from flask import send_from_directory

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

Características del contenedor

Cuando se implementan en App Service, las aplicaciones de Python se ejecutan en un contenedor de Docker de Linux que se define en el repositorio de GitHub App Service Python. Puede encontrar las configuraciones de imagen dentro de los directorios específicos de la versión.

Este contenedor tiene las siguientes características:

  • Las aplicaciones se ejecutan mediante el servidor HTTP de WSGI de Gunicorn, mediante los argumentos adicionales --bind=0.0.0.0 --timeout 600.

  • De forma predeterminada, la imagen base del contenedor incluye solo la plataforma web Flask, pero el contenedor admite otras plataformas que son compatibles con WSGI y Python 3.6, como Django.

  • Para instalar otros paquetes, como Django, cree un archivo requirements.txt en la raíz del proyecto que especifique las dependencias directas. A continuación, App Service instala automáticamente esas dependencias al implementar el proyecto.

    Para que se instalen esas dependencias, el archivo requirements.txtdebe estar en la raíz del proyecto. De lo contrario, el proceso de compilación informa del error: "No se pudo encontrar setup.py o requirements.txt; no se está ejecutando la instalación de pip". Si encuentra este error, compruebe la ubicación de su archivo de requisitos.

  • App Service define automáticamente una variable de entorno llamada WEBSITE_HOSTNAME con la dirección URL de la aplicación web, por ejemplo, msdocs-hello-world.azurewebsites.net. También define WEBSITE_SITE_NAME con el nombre de la aplicación, por ejemplo, msdocs-hello-world.

  • npm y Node.js se instalan en el contenedor para que pueda ejecutar herramientas de compilación basadas en nodos, como Yarn.

Proceso de inicio del contenedor

Durante el inicio, la instancia de App Service en el contenedor de Linux ejecuta los siguientes pasos:

  1. Use un comando de inicio personalizado, si se proporciona.
  2. Compruebe la existencia de una aplicación de Django e inicie Gunicorn para ella si se detecta.
  3. Compruebe la existencia de una aplicación de Flask e inicie Gunicorn para ella si se detecta.
  4. Si no se encuentra ninguna otra aplicación, inicia una aplicación predeterminada que está integrada en el contenedor.

En las secciones siguientes se proporcionan más detalles para cada opción.

Aplicación de Django

Para las aplicaciones de Django, App Service busca un archivo denominado wsgi.py en el código de la aplicación y, a continuación, ejecuta Gunicorn mediante el comando siguiente:

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

Si quiere un control más específico sobre el comando de inicio, use un comando de inicio personalizado, reemplace <module> por el nombre de la carpeta que contiene wsgi.pyy agregue un argumento --chdir si ese módulo no está en la raíz del proyecto. Por ejemplo, si wsgi.py se encuentra en knboard/backend/config de la raíz del proyecto, use los argumentos --chdir knboard/backend config.wsgi.

Para habilitar el registro de producción, agregue los parámetros --access-logfile y --error-logfile como se muestra en los ejemplos de los comandos de inicio personalizados.

Aplicación de Flask

En el caso de Flask, App Service busca un archivo denominado application.py o app.py e inicia Gunicorn como se indica a continuación:

# 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

Si el módulo principal de la aplicación está contenido en otro archivo, use otro nombre para el objeto de aplicación. Si quiere proporcionar otros argumentos a Gunicorn, use un comando de inicio personalizado.

Comportamiento predeterminado

Si App Service no encuentra un comando personalizado, una aplicación de Django o una aplicación de Flask, se ejecutará una aplicación predeterminada de solo lectura, ubicada en la carpeta opt/defaultsite como se muestra en la siguiente imagen.

Si ha implementado el código y sigue viendo la aplicación predeterminada, consulte Solución de problemas: la aplicación no aparece.

Captura de pantalla de la página web de App Service dla systemu Linux predeterminada.

Personalización del comando de inicio

Puede controlar el comportamiento de inicio del contenedor proporcionando un comando de inicio personalizado o varios comandos en un archivo de comandos de inicio. Un archivo de comandos de inicio puede usar cualquier nombre que elija, por ejemplo, startup.sh, startup.cmd, startup. txt, etc.

Todos los comandos deben usar rutas de acceso relativas a la carpeta raíz del proyecto.

Para especificar un comando de inicio o un archivo de comandos:

  • Azure Portal: seleccione la página Configuración de la aplicación y, luego, elija Configuración general. En el campo Comando de inicio, coloque el texto completo del comando de inicio o el nombre del archivo de comandos de inicio. Luego, seleccione Guardar para aplicar los cambios. En el caso de contenedores Linux, consulte Configuración general.

  • CLI de Azure: use el comando az webapp config set con el parámetro --startup-file para establecer el comando de inicio o el archivo de comandos de inicio:

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

    Reemplace <custom-command> por el texto completo del comando de inicio o por el nombre del archivo de comandos de inicio.

App Service omite los errores que se producen al procesar un comando de inicio personalizado o un archivo de comandos de inicio personalizados y continúa su proceso de inicio buscando aplicaciones de Django y Flask. Si no ve el comportamiento que espera, compruebe que el comando de inicio o el archivo de comandos de inicio no tengan errores y que el archivo de comandos de inicio esté implementado en App Service junto con el código de la aplicación. También puede consultar los registros de diagnóstico para más información. Consulte también la página Diagnosticar y solucionar de problemas en Azure Portal.

Comandos de inicio de ejemplo

  • Argumentos de Gunicorn agregados: en el ejemplo siguiente se agrega el argumento --workers=4 a una línea de comandos de Gunicorn para iniciar una aplicación de 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

    Para más información, vea Ejecución de Gunicorn. Si usa reglas de escalabilidad automática para escalar y reducir verticalmente la aplicación web, también debe establecer dinámicamente el número de trabajos de Gunicorn mediante la variable de entorno NUM_CORES en el comando de inicio, por ejemplo: --workers $((($NUM_CORES*2)+1)). Para más información sobre cómo establecer el número recomendado de trabajos de Gunicorn, vea Preguntas más frecuentes sobre Gunicorn.

  • Habilitar el registro de producción para Django: agregue los argumentos --access-logfile '-' y --error-logfile '-' a la línea de comandos:

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

    Estos registros aparecerán en la secuencia de registro de App Service.

    Para más información, vea Registro de Gunicorn.

  • Personalizar el módulo principal de Flask: de forma predeterminada, App Service supone que el módulo principal de una aplicación de Flask es application.py o app.py. Si el módulo principal utiliza un nombre diferente, debe personalizar el comando de inicio. Por ejemplo, si tiene una aplicación de Flask cuyo módulo principal es hello.py y el objeto de aplicación de Flask en ese archivo se denomina myapp, el comando es como sigue:

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

    Si el módulo principal está en una subcarpeta como, por ejemplo, website especifique esa carpeta con el argumento --chdir:

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

  • Usar un servidor que no sea de Gunicorn: para usar un servidor web diferente, como aiohttp, utilice el comando adecuado como comando de inicio o en el archivo de comandos de inicio:

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

Acceso a la configuración de la aplicación como variables de entorno

La configuración de la aplicación son valores almacenados en la nube específicamente para la aplicación, como se describe en Configuración de valores de la aplicación. Esta configuración está disponible para el código de la aplicación como variables de entorno y se puede acceder a ella mediante el patrón estándar os.environ.

Por ejemplo, si ha creado una configuración de aplicación llamada DATABASE_SERVER, el código siguiente recupera el valor de esa configuración:

db_server = os.environ['DATABASE_SERVER']

Detección de sesión de HTTPS

En App Service, la terminación de TLS/SSL se produce en los equilibradores de carga de red, por lo que todas las solicitudes HTTPS llegan a la aplicación como solicitudes HTTP sin cifrar. Si su aplicación lógica necesita comprobar si las solicitudes de usuario están cifradas, inspeccione el encabezado X-Forwarded-Proto.

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

Los marcos web más usados le permiten acceder a la información de X-Forwarded-* en el patrón de aplicación estándar. Por ejemplo, en Django, puede usar SECURE_PROXY_SSL_HEADER para indicar a Django que use el encabezado X-Forwarded-Proto.

Acceso a los registros de diagnóstico

Puede acceder a los registros de consola generados desde dentro del contenedor.

En primer lugar, active el registro de contenedores mediante la ejecución del siguiente comando:

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

Reemplace <app-name> y <resource-group-name> por los nombres adecuados para su aplicación web.

Una vez que se active el registro de contenedor, ejecute el siguiente comando para ver el flujo del registro:

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

Si no ve los registros de la consola de inmediato, vuelve a comprobarlo en 30 segundos.

Para detener el streaming de registro en cualquier momento, escriba Ctrl+C.

Los archivos de registro también se pueden inspeccionar en un explorador en https://<app-name>.scm.azurewebsites.net/api/logs/docker.

Para acceder a los registros mediante Azure Portal, seleccione Supervisión>Secuencia de registro en el menú izquierdo de la aplicación.

Acceso a los registros de implementación

Al implementar el código, App Service realiza el proceso de compilación descrito anteriormente en la sección Personalización de la automatización de compilaciones. Dado que la compilación se ejecuta en su propio contenedor, los registros de compilación se almacenan de forma independiente de los registros de diagnóstico de la aplicación.

Siga estos pasos para acceder a los registros de implementación:

  1. En Azure Portal, en la aplicación web, seleccione Implementación>Centro de implementación en el menú de la izquierda.
  2. En la pestaña Registros, seleccione el Id. de confirmación de la confirmación más reciente.
  3. En la página Detalles del registro que aparece, seleccione el vínculo Mostrar registros que aparece junto a "Running Oryx Build..." (Ejecución de compilación de Oryx).

Los problemas de compilación, como las dependencias incorrectas del archivo requirements.txt y los errores en los scripts anteriores o posteriores a la compilación aparecerán en estos registros. También aparecen errores si el archivo de requisitos no se llama exactamente requirements.txt o no aparece en la carpeta raíz del proyecto.

Abrir sesión SSH en el explorador

Para que una sesión de SSH directa sea abierta con el contenedor, la aplicación debe estar en ejecución.

Pegue la siguiente dirección URL en el explorador y reemplace <app-name> por el nombre de la aplicación:

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

Si aún no está autenticado, será preciso que se autentique con su suscripción a Azure para conectarse. Una vez autenticado, verá un shell del explorador en el que puede ejecutar comandos dentro del contenedor.

Conexión SSH

Nota

Los cambios que realice fuera del directorio /home se almacenan en el propio contenedor y no se conservan después del primer reinicio de la aplicación.

Para abrir una sesión remota de SSH desde un equipo local, consulte Abrir sesión SSH desde un shell remoto.

Cuando esté conectado correctamente a la sesión de SSH, debería ver el mensaje "Conexión SSH establecida" en la parte inferior de la ventana. Si ve errores como "SSH_CONNECTION_CLOSED" o un mensaje que indica que el contenedor se está reiniciando, es posible que un error impida el inicio del contenedor de la aplicación. Consulte Solución de problemas para conocer los pasos para investigar los posibles problemas.

Reescrituras de direcciones URL

Al implementar aplicaciones de Python en Azure App Service para Linux, es posible que tenga que controlar las reescrituras de direcciones URL dentro de la aplicación. Esto es especialmente útil para garantizar que los patrones de las direcciones URL específicos se redirigen a los puntos de conexión correctos sin tener que depender de configuraciones de servidores web externas. En las aplicaciones de Flask, para lograrlo se pueden usar procesadores de direcciones URL y middleware personalizado. En el caso de las aplicaciones de Django, el sólido distribuidor de direcciones URL permite una administración eficaz de las reescrituras de direcciones URL.

Solución de problemas

En general, el primer paso en la solución de problemas es usar los diagnósticos de App Service:

  1. En Azure Portal, en la aplicación web, seleccione Diagnosticar y solucionar problemas en el menú de la izquierda.
  2. Seleccione Availability and Performance (Disponibilidad y rendimiento).
  3. Examine la información de las opciones Registros de aplicación, Bloqueo de contenedor y Problemas de contenedor, donde se mostrarán los problemas más comunes.

A continuación, examine los registros de implementación y los registros de aplicación en busca de mensajes de error. Estos registros a menudo identifican problemas específicos que pueden impedir la implementación de la aplicación o el inicio de la aplicación. Por ejemplo, se puede producir un error en la compilación si el archivo requirements.txt tiene un nombre de archivo incorrecto o no está presente en la carpeta raíz del proyecto.

En las secciones siguientes se proporcionan otras instrucciones para problemas específicos.

La aplicación no aparece

  • Ve la aplicación predeterminada después de implementar su propio código de aplicación. La aplicación predeterminada aparece porque no ha implementado el código de la aplicación en App Service o porque App Service no ha encontrado el código de la aplicación y ha ejecutado la aplicación predeterminada en su lugar.

    • Reinicie App Service, espere 15-20 segundos y vuelva a comprobar la aplicación.

    • Use SSH para conectarse directamente al contenedor de App Service y compruebe que los archivos existen en site/wwwroot. Si los archivos no existen, siga estos pasos:

      1. Cree una configuración de aplicación llamada SCM_DO_BUILD_DURING_DEPLOYMENT con el valor 1, vuelva a implementar el código, espere unos minutos y, a continuación, intente acceder a la aplicación de nuevo. Para más información sobre cómo crear la configuración de la aplicación, consulte Configurar una aplicación de App Service en Azure Portal.
      2. Revise el proceso de implementación, compruebe los registros de implementación, corrija los errores y vuelva a implementar la aplicación.

    • Si existen los archivos, App Service no fue capaz de identificar el archivo de inicio específico. Compruebe que la aplicación está estructurada como espera App Service para Django o Flask, o use un comando de inicio personalizado.

  • Verá el mensaje "Servicio no disponible" en el explorador. El explorador ha agotado el tiempo de espera de una respuesta de App Service, lo que indica que App Service inició el servidor Gunicorn, pero la aplicación en sí no se inició. Esta condición podría indicar que los argumentos de Gunicorn son incorrectos o que hay un error en el código de la aplicación.

    • Actualice el explorador, especialmente si usa los planes de tarifa más bajos en el plan de App Service. Es posible que la aplicación tarde más en iniciarse si usa niveles gratis, por ejemplo, y comienza a tener capacidad de respuesta después de actualizar el explorador.

    • Compruebe que la aplicación está estructurada como espera App Service para Django o Flask, o use un comando de inicio personalizado.

    • Examine la secuencia de registro de la aplicación para ver si hay mensajes de error. Los registros mostrarán los errores en el código de la aplicación.

No se pudo encontrar setup.py o requirements.txt

  • La secuencia de registro muestra "Could not find setup.py or requirements.txt; Not running pip install" (No se pudo encontrar setup.py o requirements.txt; no se ejecutará la instalación de PIP). : el proceso de compilación de Oryx no ha podido encontrar el archivo requirements.txt.

    • Conéctese al contenedor de la aplicación web mediante SSH y compruebe que el archivo requirements.txt tiene el nombre correcto y existe directamente en site/wwwroot. Si no existe, asegúrese de que el archivo exista en el repositorio y que esté incluido en la implementación. Si existe en una carpeta distinta, muévalo a la raíz.

ModuleNotFoundError cuando se inicia la aplicación

Si ve un error como ModuleNotFoundError: No module named 'example', significa que Python no ha podido encontrar uno o varios de los módulos al iniciarse la aplicación. Este error suele ocurrir si implementa el entorno virtual con el código. Los entornos virtuales no son portables, por lo que no se deben implementar con el código de la aplicación. En su lugar, permita que Oryx cree un entorno virtual e instale los paquetes en la aplicación web mediante la creación de una configuración de aplicación, SCM_DO_BUILD_DURING_DEPLOYMENT, que se establezca en 1. Esta configuración obligará a Oryx a instalar los paquetes cada vez que realice la implementación en App Service. Para más información, vea este artículo sobre portabilidad del entorno virtual.

La base de datos está bloqueada

Al intentar ejecutar migraciones de base de datos con una aplicación de Django, es posible que vea "sqlite3. OperationalError: database is locked." (sqlite3. OperationalError: la base de datos está bloqueada) El error indica que la aplicación usa una base de datos de SQLite para la que Django está configurado de manera predeterminada, en lugar de usar una base de datos en la nube como Azure Database for PostgreSQL.

Compruebe la variable DATABASES en el archivo settings.py de la aplicación para asegurarse de que la aplicación usa una base de datos en la nube, en lugar de SQLite.

Si encuentra este error con el ejemplo de Tutorial: Implementación de una aplicación web de Django con PostgreSQL, compruebe que ha completado los pasos descritos en Verificación de la configuración de conexión.

Otros problemas

  • Las contraseñas no aparecen en la sesión SSH cuando se escriben: por motivos de seguridad, la sesión SSH mantiene la contraseña oculta mientras escribe. Pero los caracteres se registran, de modo que escriba la contraseña como de costumbre y presione Entrar cuando haya terminado.

  • Los comandos de la sesión SSH parecen estar cortados: es posible que el editor no ajuste las líneas de los comandos, pero se deberían ejecutar correctamente.

  • Los recursos estáticos no aparecen en una aplicación de Django: asegúrese de que ha habilitado el módulo WhiteNoise.

  • Aparece el mensaje "Error irrecuperable: se requiere una conexión SSL" : compruebe los nombres de usuario y las contraseñas usados para acceder a los recursos (como las bases de datos) desde dentro de la aplicación.

Contenido relacionado