Compartir a través de

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

Implementación en Azure

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 automáticamente un entorno virtual e instala dependencias desde un requirements.txtarchivo , pyproject.tomlo setup.py al implementar un repositorio de Git o al implementar un paquete ZIPcon la automatización de compilación habilitada.

En este artículo se proporcionan conceptos clave e instrucciones para desarrolladores de Python que usan un contenedor Linux integrado en App Service. Si nunca ha usado App Service, complete primero el Inicio rápido de Python y el tutorial de Flask, Django o FastAPI 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. Pero puede compilar una imagen propia de contenedor personalizada de Windows y ejecutarla en App Service. Para más información, vea 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 general para contenedores de Linux.

  • CLI de Azure:

    • Muestre la versión actual de Python mediante 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 la aplicación web.

    • Establezca la versión de Python mediante az webapp config set:

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

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

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

Puede ejecutar una versión no compatible de Python mediante la creación una imagen de contenedor propia. Para más información, vea Uso de una imagen personalizada de Docker.

¿Qué ocurre con los tiempos de ejecución obsoletos en App Service?

Los tiempos de ejecución obsoletos están en desuso por parte de la organización de mantenimiento o tienen vulnerabilidades significativas. En consecuencia, se eliminan de las páginas de creación y configuración en el portal. Cuando un tiempo de ejecución obsoleto está oculto en el portal, cualquier aplicación que siga usando ese tiempo de ejecución continúa ejecutándose.

Si quiere crear una aplicación con una versión de runtime obsoleta que ya no se muestra en el portal, use la CLI de Azure, una plantilla de ARM o Bicep. Estas alternativas de implementación le permiten crear entornos de ejecución en desuso que se quitan del portal, pero que todavía se admiten.

Si un entorno de ejecución se quita completamente de la plataforma de App Service, el propietario de la suscripción de Azure recibe un aviso por correo electrónico antes de la eliminación.

Personalización de la automatización de compilaciones

Nota:

Cuando las aplicaciones de Python se implementan con automatización de compilación, el contenido se implementa y se sirve desde /tmp/<uid>, no en /home/site/wwwroot. Puede acceder a este directorio de contenido mediante la variable de entorno APP_PATH. Debe escribir los archivos adicionales creados en tiempo de ejecución en una ubicación en /home o mediante Bring Your Own Storage para la persistencia. Para más información sobre este comportamiento, vea Cambios de compilación de Python.

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

  1. Ejecute un script personalizado previo a la compilación si ese paso está especificado por la configuración PRE_BUILD_COMMAND. (El script puede ejecutar otros scripts de Python y Node.js, comandos pip y npm, y herramientas basadas en Node como Yarn, por ejemplo, yarn install y yarn build).

  2. Instale las dependencias. El sistema de compilación comprueba los siguientes archivos en la raíz del proyecto:

    • requirements.txt: Ejecuta pip install -r requirements.txt.
    • pyproject.toml con uv.lock: usa uv.
    • pyproject.toml con poetry.lock: usa poetry.
    • pyproject.toml: usa poetry.
    • setup.py: ejecuta pip install ..

    Nota:

    Si pyproject.toml está presente, pero falta uv.lock, el App Service predetermina el uso de Poetry, incluso si también falta poetry.lock. Para usar uv, debe incluir uv.lock en la implementación.

    Si no se encuentra ninguno de estos archivos, el proceso de compilación notifica el error "No se pudo encontrar setup.py o requirements.txt; No se está ejecutando pip install".

  3. Si manage.py se encuentra en la raíz del repositorio (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 un script posterior a la compilación personalizado, si ese paso se especifica en 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 el valor 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.

Para obtener información sobre otras opciones que personalizan la automatización de compilación, vea Configuración de Oryx.

Para obtener información sobre cómo acceder a los registros de compilación e implementación, vea 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 porque 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

Puede volver a implementar aplicaciones web existentes en Azure de la siguiente manera:

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

    • El archivo de dependencia (como requirements.txt, pyproject.toml o setup.py) debe estar en la raíz del repositorio si desea 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 crear estos recursos fácilmente mediante la ejecución del comando az webapp upde la CLI de Azure. También puede crear e implementar recursos como se muestra en el tutorial Flask, Django o FastAPI con PostgreSQL. Reemplace los nombres del grupo de recursos, el plan de App Service y la aplicación web por los nombres adecuados para 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. Estas configuraciones de App Service se muestran para su 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 obtener información sobre cómo App Service intenta ejecutar la aplicación. App Service usa el servidor web Gunicorn de manera predeterminada. Gunicorn debe ser capaz de encontrar el objeto de la 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 Acciones de GitHub, Bitbucket o Azure Repos, como se describe 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 dentro del contenedor de App Service en el que se hospeda la aplicación, como las migraciones de base de datos de Django, puede conectarse al contenedor mediante SSH. Para obtener un ejemplo de ejecución de migraciones de bases de datos de Django, vea Tutorial: Implementación de una aplicación web de Django con PostgreSQL.

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

Para un entorno de producción como App Service, las aplicaciones de Django deben seguir las instrucciones de 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.

Configuración de Django Instrucciones para Azure
SECRET_KEY Almacene el valor en una 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 una configuración DEBUG en App Service con el valor 0 (false) y, después, 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 mediante 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 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 desarrollo local) y la configuración de la aplicación (al implementar 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 se ejecuta yarn build en la carpeta de front-end y Yarn genera una carpeta build/static que contiene archivos estáticos, incluya esa carpeta como se muestra aquí:

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

    En este código, se usa FRONTEND_DIR para crear una ruta de acceso a donde se ejecuta una herramienta de compilación como Yarn. Puede usar de nuevo una variable de entorno y una configuración de aplicación si quiere.

  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 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 las listas 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 de front-end estáticos, siga primero las instrucciones de administración de archivos estáticos de 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 en los directorios específicos de la versión.

Este contenedor tiene las siguientes características:

  • El servidor HTTP WSGI Gunicorn ejecuta aplicaciones con los argumentos adicionales --bind=0.0.0.0 --timeout 600.

  • De manera predeterminada, la imagen de contenedor base solo incluye el marco web de Flask, pero el contenedor admite otros marcos compatibles con WSGI y con Python 3.6 y versiones posteriores, como Django.

  • Para instalar otros paquetes, como Django, cree un requirements.txt, pyproject.toml o setup.py archivo 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.

    El archivo de dependencia debe estar en la raíz del proyecto o no se instalarán las dependencias. Si este archivo no está en la raíz, el proceso de compilación notifica el error "No se pudo encontrar setup.py o requirements.txt; No se está ejecutando pip install". Si se produce este error, compruebe la ubicación del archivo de requisitos.

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

  • npm y Node.js se instalan en el contenedor para poder 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 si existe una aplicación de Django e inicie Gunicorn para ella si se detecta una.
  3. Compruebe si existe una aplicación de Flask e inicie Gunicorn para ella si se detecta una.
  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

En el caso de las aplicaciones de Django, App Service busca un archivo denominado wsgi.py en el código de la aplicación y, después, 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 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, ejecuta una aplicación de solo lectura predeterminada, ubicada en la carpeta opt/defaultsite y 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 predeterminada de App Service en Linux.

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 el nombre que elija, como startup.sh, startup.cmd o startup.txt.

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. En Configuración en el panel izquierdo de la página de la aplicación, seleccione Configuración y después Configuración general. En el cuadro Comando de inicio, escriba 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 archivo o el comando 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 archivo o comando de inicio personalizado y, después, continúa su proceso de inicio buscando aplicaciones de Django y Flask. Si no ve el comportamiento esperado, compruebe que el comando de inicio o el archivo no tienen errores y que se implementa un archivo de comandos de inicio 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. Además, puede comprobar la página Diagnosticar y resolver problemas de la aplicación 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 that contains wsgi.py.
gunicorn --bind=0.0.0.0 --timeout 600 --workers=4 --chdir <module_path> <module>.wsgi

    Para obtener más información, vea Running Gunicorn. Si usa reglas de escalado automático 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, consulte Registro de logs 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 usa 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, este es el comando:

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

    Si el módulo principal está en una subcarpeta, como 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 que se almacenan en la nube específicamente para la aplicación, como se describe en Configuración de la aplicación. Esta configuración está disponible para el código de la aplicación como variables de entorno y se accede a ella a través del patrón estándar os.environ.

Por ejemplo, si crea una configuración de aplicación denominada 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 la lógica de la aplicación 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 populares le permiten acceder a la información X-Forwarded-* en el patrón de aplicación estándar. Por ejemplo, en Django puede usar SECURE_PROXY_SSL_HEADER a fin de configurar Django para usar el encabezado X-Forwarded-Proto.

Acceso a los registros de diagnóstico

Puede acceder a los registros de consola que se generan desde dentro del contenedor.

Para activar el registro de contenedores, ejecute el siguiente comando:

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

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

Después de activar el registro de contenedores, ejecute el siguiente comando para ver la secuencia de registro:

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

Si los registros de consola no aparecen inmediatamente, vuelva a comprobar en 30 segundos.

Para detener el streaming de registros en cualquier momento, use el método abreviado de teclado Ctrl+C.

Para acceder a los registros en Azure Portal, seleccione Supervisión>Flujo de registro en el panel 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 la compilación. 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 la página de Azure Portal de la aplicación web, seleccione Implementación>Centro de implementación en el panel izquierdo.
  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 Ejecución de la compilación oryx.

Los problemas de compilación, como las dependencias incorrectas en el archivo de dependencia y los errores en scripts anteriores o posteriores a la compilación, aparecen en estos registros. Los errores también aparecen si el archivo de dependencia no se encuentra en la carpeta raíz del proyecto.

Apertura de la sesión SSH en un explorador

Si quiere abrir una sesión SSH directa con el contenedor, la aplicación debe estar en ejecución.

Use el comando az webapp ssh .

Si no se ha autenticado, debe autenticarse con la suscripción de Azure para conectarse. Cuando se autentica, verá un shell en el explorador donde puede ejecutar comandos dentro del contenedor.

Conexión SSH

Nota:

Los cambios que realice fuera del /home directorio se almacenan en el propio contenedor y no se conservan más allá de un 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 que se inicie el contenedor de aplicaciones. Vea Solución de problemas para obtener información sobre cómo investigar posibles problemas.

Reescritura de URL

Al implementar aplicaciones de Python en App Service para Linux, es posible que tenga que controlar las reescrituras de direcciones URL dentro de la aplicación. Este método es especialmente útil para garantizar que los patrones de dirección URL específicos se redirigen a los puntos de conexión correctos sin depender de configuraciones de servidor web externos. En el caso de las aplicaciones de Flask, puede usar procesadores de direcciones URL y middleware personalizado para lograrlo. En las aplicaciones de Django, el 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 la página de Azure Portal de la aplicación web, seleccione Diagnosticar y resolver problemas en el panel izquierdo.
  2. Seleccione Availability and Performance (Disponibilidad y rendimiento).
  3. Examine la información de Registros de aplicaciones, Bloqueos de contenedor y Problemas de contenedor, donde aparecen 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, la compilación puede producir un error si el archivo de dependencia 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. Aparece la aplicación predeterminada porque no ha implementado el código de la aplicación en App Service o porque App Service no pudo encontrar el código de la aplicación y, en su lugar, ha ejecutado la aplicación predeterminada.

    • Reinicie la aplicación, espere 20 segundos y vuelva a comprobarla.

    • 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 denominada SCM_DO_BUILD_DURING_DEPLOYMENT con un valor de 1, vuelva a implementar el código, espere unos minutos y vuelva a intentar acceder a la aplicación. 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 los archivos existen, App Service no ha podido identificar el archivo de inicio. Asegúrese de que la aplicación está estructurada como App Service espera para Django o Flask, o use un comando de inicio personalizado.

  • Verá el mensaje "Servicio no disponible" en el explorador. El explorador agota el tiempo de espera de una respuesta de App Service. Esto indica que App Service ha iniciado el servidor Gunicorn, pero la propia aplicación no se ha iniciado. 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. La aplicación puede tardar más tiempo en iniciarse cuando se usan niveles gratuitos, por ejemplo, y responder después de actualizar el explorador.

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

    • Examine el flujo de registro de la aplicación para ver los 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

  • El flujo de registro muestra "No se pudo encontrar setup.py o requirements.txt; no se está ejecutando pip install". El proceso de compilación de Oryx no pudo encontrar tu archivo requirements.txt, pyproject.toml o setup.py.

    • Conéctese al contenedor de la aplicación web a través de SSH y compruebe que el archivo de dependencia se llama correctamente 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', Python no pudo encontrar uno o varios de los módulos cuando se inició la aplicación. Este error suele ocurrir si despliega su entorno virtual junto con su 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 obliga a Oryx a instalar los paquetes siempre 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: la base de datos está bloqueada". El error indica que la aplicación usa una base de datos 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, por lo 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 sea comandos de ajuste de palabras, pero deben seguir ejecutándose correctamente.

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

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

Contenido relacionado

  • Last updated on