Partager via

Configurer une application Python Linux pour Azure App Service

Déployer dans Azure

Cet article explique comment Azure App Service exécute des applications Python, comment migrer des applications existantes vers Azure et comment personnaliser le comportement d’App Service si nécessaire. Les applications Python doivent être déployées avec tous les modules pip nécessaires.

Le moteur de déploiement App Service active automatiquement un environnement virtuel et installe des dépendances à partir d’un dépôt , requirements.txtou pyproject.toml d’un setup.pyfichier lorsque vous déployez un référentiel Git ou lorsque vous déployez un package zipavec l’automatisation de build activée.

Cet article fournit des concepts clés et des instructions aux développeurs Python qui utilisent un conteneur Linux intégré dans App Service. Si vous n’avez jamais utilisé App Service, commencez par suivre le guide de démarrage rapide Python et le tutoriel Flask, Django ou FastAPI avec PostgreSQL.

Vous pouvez utiliser soit le portail Azure soit Azure CLI pour la configuration :

  • Portail Azure. Dans le volet gauche de l’application, sélectionnez Paramètres>Variables d’environnement ouParamètres>Configuration, comme décrit dans Configurer une application App Service dans le Portail Azure.

  • Azure CLI. Vous avez le choix entre deux options.

    • Exécutez des commandes dans Azure Cloud Shell.
    • Exécutez les commandes en local en installant la dernière version de l’interface Azure CLI et en vous connectant à Azure à l’aide de la commande az login.

Remarque

Linux est le seul système d’exploitation permettant d’exécuter des applications Python dans App Service. Python sur Windows n’est plus pris en charge. Vous pouvez toutefois créer votre propre image de conteneur Windows personnalisée et l’exécuter dans App Service. Pour plus d’informations, consultez Utiliser une image Docker personnalisée.

Configurer la version de Python

  • Portail Azure : utilisez l’onglet Paramètres généraux de la page Configuration, comme décrit dans Configurer les paramètres généraux pour les conteneurs Linux.

  • Azure CLI :

    • Affichez la version actuelle de Python à l’aide de az webapp config show :

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

      Remplacez et <resource-group-name> utilisez <app-name> les noms appropriés pour votre application web.

    • Définissez la version de Python à l’aide du jeu de configuration az webapp :

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

    • Affichez toutes les versions Python prises en charge dans App Service à l’aide de az webapp list-runtimes :

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

Vous pouvez exécuter une version non prise en charge de Python en créant votre propre image de conteneur. Pour plus d’informations, consultez Utiliser une image Docker personnalisée.

Que se passe-t-il pour les runtimes obsolètes dans App Service ?

Les runtimes obsolètes sont déconseillés par l’organisation de maintenance ou présentent des vulnérabilités importantes. En conséquence, ils sont supprimés de la création et de la configuration des pages dans le portail. Lorsqu’un runtime obsolète est masqué dans le portail, toute application qui utilise toujours ce runtime continue à s’exécuter.

Si vous souhaitez créer une application avec une version d’exécution obsolète qui n’est plus affichée sur le portail, utilisez Azure CLI, un modèle ARM ou Bicep. Ces alternatives de déploiement vous permettent de créer des moteurs d’exécution obsolètes qui ont été supprimés du portail, mais qui sont toujours pris en charge.

Si un runtime est entièrement supprimé de la plateforme App Service, le propriétaire de votre abonnement Azure reçoit un e-mail avant la suppression.

Personnaliser l’automatisation de la construction

Remarque

Lorsque les applications Python sont déployées avec l’automatisation de la compilation, le contenu est déployé et servi à partir de /tmp/<uid>, et non sous /home/site/wwwroot. Vous pouvez accéder à ce répertoire de contenu à l’aide de la variable d’environnement APP_PATH. Vous devez enregistrer tous les fichiers supplémentaires créés lors de l’exécution dans un emplacement sous /home ou en utilisant Bring Your Own Storage pour la persistance. Pour plus d’informations sur ce comportement, consultez Modifications apportées au build Python.

Le système de compilation App Service, appelé Oryx, effectue les étapes suivantes lorsque vous déployez votre application, si le paramètre SCM_DO_BUILD_DURING_DEPLOYMENT de l’application est défini sur 1 :

  1. Exécutez un script de prégénération personnalisé si cette étape est spécifiée par le paramètre PRE_BUILD_COMMAND. (Le script peut lui-même exécuter d’autres scripts Python et Node.js, des commandes pip et npm, ainsi que des outils basés sur Node tels que Yarn, par exemple yarn install, et yarn build).

  2. Installez les dépendances. Le système de génération recherche les fichiers suivants dans la racine du projet :

    • requirements.txt: Exécute pip install -r requirements.txt.
    • pyproject.toml avec uv.lock : utilise uv.
    • pyproject.toml avec poetry.lock : Utilise poetry.
    • pyproject.toml : utilise poetry.
    • setup.py : Exécution pip install ..

    Remarque

    Si pyproject.toml est présent, mais uv.lock est manquant, App Service utilise par défaut la poésie, même si poetry.lock est également manquant. Pour utiliser uv, vous devez inclure uv.lock dans votre déploiement.

    Si aucun de ces fichiers n’est trouvé, le processus de génération signale l’erreur « Impossible de trouver setup.py ou requirements.txt; Pas d’installation pip en cours d’exécution. »

  3. Si manage.py se trouve à la racine du référentiel (ce qui indique une application Django), exécutez manage.py collectstatic. En revanche, si le paramètre DISABLE_COLLECTSTATIC a la valeur true, cette étape est ignorée.

  4. Exécutez un script personnalisé après la compilation, si cette étape est spécifiée dans le paramètre POST_BUILD_COMMAND. (Là encore, le script peut exécuter d’autres scripts Python et Node.js, des commandes pip et npm ainsi que des outils Node.)

Par défaut, les paramètres PRE_BUILD_COMMAND, POST_BUILD_COMMAND et DISABLE_COLLECTSTATIC sont vides.

  • Pour désactiver l’exécution de collectstatic lors de la compilation d’applications Django, définissez le paramètre DISABLE_COLLECTSTATIC sur true.

  • Pour exécuter des commandes de prégénération, définissez le paramètre PRE_BUILD_COMMAND pour qu’il contienne soit une commande, comme echo Pre-build command, soit un chemin d’accès à un fichier de script par rapport à la racine de votre projet, comme scripts/prebuild.sh. Toutes les commandes doivent utiliser des chemins d’accès relatifs au dossier racine du projet.

  • Pour exécuter des commandes de post-génération, définissez le paramètre POST_BUILD_COMMAND pour qu’il contienne soit une commande, comme echo Post-build command, soit un chemin d’accès à un fichier de script par rapport à la racine de votre projet, comme scripts/postbuild.sh. Toutes les commandes doivent utiliser des chemins d’accès qui sont relatifs au dossier racine du projet.

Pour plus d’informations sur les autres paramètres permettant de personnaliser l’automatisation de la compilation, consultez Configuration d’Oryx.

Pour plus d’informations sur l’accès aux journaux de compilation et de déploiement, consultez Accéder aux journaux de déploiement.

Pour plus d’informations sur la façon dont App Service exécute et génère les applications Python dans Linux, consultez Comment Oryx détecte et génère les applications Python.

Remarque

Les paramètres PRE_BUILD_SCRIPT_PATH et POST_BUILD_SCRIPT_PATH sont identiques à PRE_BUILD_COMMAND et POST_BUILD_COMMAND et sont pris en charge pour des raisons d’héritage.

Un paramètre nommé SCM_DO_BUILD_DURING_DEPLOYMENT, s’il contient true ou 1, déclenche une génération Oryx pendant le déploiement. Le paramètre a la valeur true quand vous déployez avec Git, la commande Azure CLI az webapp up et Visual Studio Code.

Remarque

Utilisez toujours des chemins relatifs dans tous les scripts pré-compilation et post-compilation, car le conteneur de compilation dans lequel Oryx s’exécute est différent du conteneur d’exécution dans lequel l’application s’exécute. Ne vous fiez jamais à l’emplacement exact du dossier de votre projet d’application dans le conteneur (qui est placé, par exemple, sous site/wwwroot).

Migrer des applications existantes vers Azure

Vous pouvez redéployer des applications web existantes sur Azure de la manière suivante :

  1. Référentiel source. Conservez votre code source dans un référentiel adapté, tel que GitHub, qui vous permettra de mettre en place un déploiement continu plus tard dans ce processus.

    • Votre fichier de dépendance (tel que requirements.txt, pyproject.toml ou setup.py) doit être à la racine de votre référentiel si vous souhaitez qu’App Service installe automatiquement les packages nécessaires.

  2. Base de données. Si votre application dépend d’une base de données, créez également les ressources nécessaires sur Azure.

  3. Ressources App Service. Pour héberger votre application, créez un groupe de ressources, un plan App Service et une application web App Service. Vous pouvez créer facilement ces ressources en exécutant la commande Azure CLI az webapp up. Vous pouvez également créer et déployer des ressources comme indiqué dans les tutoriels Flask, Django ou FastAPI avec PostgreSQL. Remplacez les noms du groupe de ressources, du plan App Service et de l’application web par des noms adaptés à votre application.

  4. Variables d’environnement. Si votre application nécessite des variables d’environnement, créez des paramètres d’application App Service équivalents. Ces paramètres App Service apparaissent dans votre code sous forme de variables d’environnement, comme décrit dans Accéder aux variables d’environnement.

  5. Démarrage de l’application. Pour plus d’informations sur la manière dont App Service tente d’exécuter votre application, consultez la section Processus de démarrage du conteneur plus loin dans cet article. App Service utilise par défaut le serveur web Gunicorn. Gunicorn doit pouvoir trouver votre objet d’application ou votre dossier wsgi.py. Si nécessaire, vous pouvez personnaliser la commande de démarrage.

  6. Déploiement continu. Configurez le déploiement continu à partir de GitHub Actions, Bitbucket ou Azure Repos comme décrit dans l’article Déploiement continu vers Azure App Service. Sinon, configurez un déploiement continu à partir de Git local, comme décrit dans l’article Déploiement Git local vers Azure App Service.

  7. Actions personnalisées. Pour effectuer des actions dans le conteneur App Service qui héberge votre application, telles que les migrations de base de données Django, vous pouvez vous connecter au conteneur via SSH. Pour un exemple d’exécution des migrations de base de données Django, consultez le Tutoriel : Déployer une application web Django avec PostgreSQL.

    • Lorsque vous utilisez le déploiement continu, vous pouvez effectuer ces actions à l’aide de commandes post-compilation, comme décrit précédemment dans la section Personnaliser l’automatisation de build.

Une fois ces étapes terminées, vous devez être en mesure de valider les modifications apportées à votre dépôt source et de faire en sorte que ces mises à jour soient déployées automatiquement dans App Service.

Paramètres de production pour les applications Django

Pour un environnement de production tel qu’App Service, les applications Django doivent suivre les recommandations fournies dans la liste de contrôle déploiement de Django.

Le tableau suivant décrit les paramètres de production qui s’appliquent à Azure. Ces paramètres sont définis dans le fichier setting.py de l’application.

Paramètre Django Instructions pour Azure
SECRET_KEY Stockez la valeur dans un paramètre App Service, comme décrit dans Accéder aux paramètres de l’application en tant que variables d’environnement. Vous pouvez également stocker la valeur en tant que secret dans Azure Key Vault.
DEBUG Créez un paramètre DEBUG sur App Service avec la valeur 0 (false), puis chargez la valeur en tant que variable d’environnement. Dans votre environnement de développement, créez une variable d’environnement DEBUG avec la valeur 1 (true).
ALLOWED_HOSTS En production, Django vous oblige à inclure l’URL de l’application dans le tableau ALLOWED_HOSTS de settings.py. Vous pouvez récupérer cette URL lors de l’exécution à l’aide du code os.environ['WEBSITE_HOSTNAME']. App Service définit automatiquement la variable d’environnement WEBSITE_HOSTNAME sur l’URL de l’application.
DATABASES Définissez les paramètres dans App Service pour la connexion de base de données et chargez-les en tant que variables d’environnement pour remplir le dictionnaire DATABASES. Vous pouvez également stocker les valeurs (en particulier le nom d’utilisateur et le mot de passe) en tant que secrets Key Vault.

Distribuer des fichiers statiques pour les applications Django

Si votre application web Django comprend des fichiers front-end statiques, suivez d’abord les instructions relatives à la gestion des fichiers statiques dans la documentation de Django.

Pour App Service, vous devez apporter ensuite les modifications suivantes :

  1. Envisagez d’utiliser des variables d’environnement (pour le développement local) et les paramètres de l’application (lors du déploiement dans le cloud) pour définir dynamiquement les variables Django STATIC_URL et STATIC_ROOT. Par exemple :

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

    Vous pouvez changer DJANGO_STATIC_URL et DJANGO_STATIC_ROOT si nécessaire pour vos environnements locaux et cloud. Par exemple, si le processus de compilation de vos fichiers statiques les place dans un dossier nommé django-static, vous pouvez définir DJANGO_STATIC_URL sur /django-static/ afin d’éviter d’utiliser la valeur par défaut.

  2. Si vous avez un script prébuild qui génère des fichiers statiques dans un autre dossier, incluez ce dossier dans la variable Django STATICFILES_DIRS pour que le processus collectstatic de Django les trouve. Par exemple, si vous exécutez yarn build dans votre dossier frontal et que Yarn génère un dossier build/static contenant des fichiers statiques, incluez ce dossier comme indiqué ici :

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

    Dans ce code, FRONTEND_DIR est utilisé pour créer un chemin vers l’emplacement où un outil de compilation tel que Yarn est exécuté. Si vous le souhaitez, vous pouvez à nouveau utiliser une variable d’environnement et un paramètre d’application.

  3. Ajoutez whitenoise à votre fichier requirements.txt. WhiteNoise (whitenoise.evans.io) est un package Python qui permet à une application de production Django de distribuer facilement ses propres fichiers statiques. WhiteNoise sert les fichiers qui se trouvent dans le dossier spécifié par la variable Django STATIC_ROOT.

  4. Dans votre fichier settings.py, ajoutez la ligne suivante pour WhiteNoise :

    STATICFILES_STORAGE = ('whitenoise.storage.CompressedManifestStaticFilesStorage')

  5. Modifiez les listes MIDDLEWARE et INSTALLED_APPS pour inclure 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.
]

Distribuer des fichiers statiques pour les applications Flask

Si votre application web Flask comprend des fichiers front-end statiques, suivez d’abord les instructions de la section gestion des fichiers statiques dans la documentation Flask. Pour obtenir un exemple de distribution de fichiers statiques dans une application Flask, consultez l’exemple d’application Flask sur GitHub.

Pour distribuer des fichiers statiques directement à partir d’une route sur votre application, vous pouvez utiliser la méthode send_from_directory :

from flask import send_from_directory

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

Caractéristiques du conteneur

Quand elles sont déployées dans App Service, les applications Python s’exécutent dans un conteneur Linux Docker qui est défini dans le dépôt GitHub Python d’App Service. Vous trouverez les configurations d’image dans les répertoires spécifiques à chaque version.

Ce conteneur présente les caractéristiques suivantes :

  • Les applications sont exécutées par le serveur HTTP Gunicorn WSGI avec les arguments supplémentaires --bind=0.0.0.0 --timeout 600.

  • Par défaut, l’image de conteneur de base inclut uniquement l’infrastructure web Flask, mais le conteneur prend en charge d’autres infrastructures conformes à WSGI et compatibles avec Python 3.6 et versions ultérieures, telles que Django.

  • Pour installer d’autres packages, tels que Django, créez un fichierrequirements.txt, pyproject.toml ou setup.py à la racine de votre projet qui spécifie vos dépendances directes. App Service installe alors automatiquement ces dépendances pendant le déploiement de votre projet.

    Le fichier de dépendance doit se trouver dans la racine du projet ou les dépendances ne seront pas installées. Si ce fichier ne se trouve pas à la racine, le processus de compilation signale l’erreur « Could not find setup.py or requirements.txt; Not running pip install. » (Impossible de trouver setup.py ou requirements.txt ; pip install n’est pas exécuté.) Si vous rencontrez cette erreur, vérifiez l’emplacement de votre fichier de exigences.

  • App Service définit automatiquement une variable d’environnement nommée WEBSITE_HOSTNAME qui contient l’URL de l’application web, telle que msdocs-hello-world.azurewebsites.net. Il définit également WEBSITE_SITE_NAME, qui contient le nom de votre application, tel que msdocs-hello-world.

  • npm et Node.js sont installés dans le conteneur afin que vous puissiez exécuter des outils de compilation basés sur Node, tels que Yarn.

Processus de démarrage du conteneur

Lors du démarrage, App Service sur un conteneur Linux exécute les étapes suivantes :

  1. Utilisez une commande de démarrage personnalisée si une telle commande est fournie.
  2. Vérifiez l’existence d’une application Django, et démarrez Gunicorn pour celle-ci si elle est détectée.
  3. Vérifiez l’existence d’une application Flask, et démarrez Gunicorn pour celle-ci si elle est détectée.
  4. Si aucune autre application n’est trouvée, démarrer une application par défaut qui est créée dans le conteneur.

Les sections suivantes fournissent des autres détails sur chaque option.

Application Django

Pour les applications Django, App Service recherche un fichier nommé wsgi.py dans le code de votre application, puis exécute Gunicorn à l’aide de la commande suivante :

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

Si vous souhaitez un contrôle plus précis sur la commande de démarrage, utilisez une commande de démarrage personnalisée, remplacez <module> par le nom du dossier qui contient wsgi.py, puis ajoutez un argument --chdir si ce module ne se trouve pas à la racine du projet. Par exemple, si votre fichier wsgi.py se trouve sous knboard/backend/config à la racine de votre projet, utilisez les arguments --chdir knboard/backend config.wsgi.

Pour activer la journalisation de la production, ajoutez les paramètres --access-logfile et --error-logfile, comme indiqué dans les exemples de commandes de démarrage personnalisées .

Application Flask

Pour Flask, App Service recherche un fichier nommé application.py ou app.py et démarre Gunicorn comme ceci :

# 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 votre module d’application principale est contenu dans un autre fichier, utilisez un autre nom pour l’objet d’application. Si vous souhaitez fournir d’autres arguments à Gunicorn, utilisez une commande de démarrage personnalisée.

Comportement par défaut

Si le service App Service ne trouve pas de commande personnalisée, d’application Django ou d’application Flask, il exécute une application par défaut en lecture seule, située dans le dossier opt/defaultsite et illustrée dans l’image suivante.

Si vous avez déployé du code et que vous voyez toujours l’application par défaut, consultez Résolution des problèmes – L’application n’apparaît pas.

Capture d’écran de la page web App Service sur Linux par défaut.

Commande de démarrage personnalisée

Vous pouvez contrôler le comportement de démarrage du conteneur en fournissant soit une commande de démarrage personnalisée, soit plusieurs commandes dans un fichier de commandes de démarrage. Un fichier de commande de démarrage peut porter le nom de votre choix, par exemple startup.sh, startup.cmd ou startup.txt.

Toutes les commandes doivent utiliser des chemins d’accès qui sont relatifs au dossier racine du projet.

Pour spécifier une commande de démarrage ou un fichier de commandes :

  • Portail Azure. Dans le volet gauche de la page de l’application, sous Paramètres, sélectionnez Configuration, puis Paramètres généraux. Dans la zone Commande de démarrage, saisissez soit le texte complet de votre commande de démarrage, soit le nom de votre fichier de commande de démarrage. Sélectionnez ensuite Enregistrer pour appliquer les modifications. Consultez Configurer les paramètres généraux pour les conteneurs Linux.

  • Azure CLI. Pour définir la commande de démarrage ou le fichier, utilisez la commande az webapp config set avec le paramètre --startup-file :

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

    Remplacez <custom-command> par le texte complet de votre commande de démarrage ou par le nom de votre fichier de commandes de démarrage.

App Service ignore toutes les erreurs qui se produisent lors du traitement d’une commande ou d’un fichier de démarrage personnalisé, puis poursuit son processus de démarrage en recherchant les applications Django et Flask. Si vous n’observez pas le comportement attendu, vérifiez que votre commande ou fichier de démarrage ne contient aucune erreur et qu’un fichier de commande de démarrage est déployé dans App Service avec le code de votre application. Vous pouvez aussi consulter les journaux de diagnostic pour obtenir plus d’informations. Vous pouvez également consulter la page Diagnostiquer et résoudre les problèmes de l’application sur le Portail Azure.

Exemples de commandes de démarrage

  • Ajout d’arguments Gunicorn : l’exemple suivant ajoute l’argument --workers=4 à une ligne de commande Gunicorn pour démarrer une application 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

    Pour plus d’informations, consultez Exécution de Gunicorn. Si vous utilisez des règles de mise à l’échelle automatique pour augmenter ou réduire la capacité de votre application web, vous devez également définir de manière dynamique le nombre de Workers Gunicorn à l’aide de la variable d’environnement NUM_CORES dans votre commande de démarrage. Par exemple : --workers $((($NUM_CORES*2)+1)). Pour plus d'informations sur le paramétrage du nombre recommandé de travailleurs Gunicorn, consultez la FAQ de Gunicorn.

  • Activez la journalisation de production pour Django : ajoutez les arguments --access-logfile '-' et --error-logfile '-' à la ligne de commande :

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

    Ces journaux s’affichent dans le flux de journaux App Service.

    Pour plus d’informations, consultez Journalisation Gunicorn.

  • Module principal Flask personnalisé : par défaut, App Service considère que le module principal d’une application Flask est application.py ou app.py. Si votre module principal utilise un nom différent, vous devez personnaliser la commande de démarrage. Par exemple, si vous avez une application Flask dont le module principal est hello.py et que l’objet de l’application Flask dans ce fichier est nommé myapp, voici la commande à utiliser :

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

    Si votre module principal se trouve dans un sous-dossier, tel que website, spécifiez ce dossier à l’aide de l’argument --chdir :

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

  • Utilisez un serveur non Gunicorn : pour utiliser un autre serveur web, tel que aiohttp, utilisez la commande appropriée en tant que commande de démarrage ou dans le fichier de commandes de démarrage :

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

Accéder aux paramètres d’application en tant que variables d’environnement

Les paramètres de l’application sont des valeurs stockées dans le cloud spécifiquement pour votre application, comme décrit dans Configurer les paramètres de l’application. Ces paramètres sont disponibles dans le code de votre application sous forme de variables d’environnement et accessibles via le modèle standard os.environ.

Par exemple, si vous créez un paramètre d’application appelé DATABASE_SERVER, le code suivant récupère la valeur de ce paramètre :

db_server = os.environ['DATABASE_SERVER']

Détecter une session HTTPS

Dans App Service, une terminaison TLS/SSL se produit au niveau des équilibreurs de charge réseau. Toutes les requêtes HTTPS accèdent donc à votre application en tant que requêtes HTTP non chiffrées. Si la logique de votre application doit vérifier si les requêtes utilisateur sont chiffrées, inspectez l’en-tête X-Forwarded-Proto :

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

Les frameworks web populaires vous permettent d’accéder aux informations X-Forwarded-* dans votre modèle d’application standard. Par exemple, dans Django, vous pouvez utiliser SECURE_PROXY_SSL_HEADER pour configurer Django afin qu’il utilise l’en-tête X-Forwarded-Proto.

Accéder aux journaux de diagnostic

Vous pouvez accéder aux journaux de la console qui sont générés à partir du conteneur.

Pour activer la journalisation des conteneurs, exécutez la commande suivante :

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

Remplacez les valeurs <app-name> et <resource-group-name> par des noms appropriés pour votre application web.

Après avoir activé la journalisation des conteneurs, exécutez la commande suivante pour afficher le flux de journaux :

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

Si les logs de console ne s’affichent pas immédiatement, revérifiez dans 30 secondes.

Pour arrêter le streaming des logs (journaux) à tout moment, utilisez le raccourci clavier Ctrl+C.

Pour accéder aux journaux dans le Portail Azure, sélectionnez Surveillance>Flux de journaux dans le volet gauche de votre application.

Accéder aux journaux de déploiement

Lorsque vous déployez votre code, App Service exécute le processus de compilation décrit précédemment dans la section Personnaliser l’automatisation de build. Comme la construction s’exécute dans son propre conteneur, les journaux de construction sont stockés séparément des journaux de diagnostic de l’application.

Utilisez les étapes suivantes pour accéder aux journaux de déploiement :

  1. Sur la page du Portail Azure dédiée à votre application web, sélectionnez Déploiement>Centre de déploiement dans le volet gauche.
  2. Sous l’onglet Journaux, sélectionnez l’ID de validation pour la validation la plus récente.
  3. Sur la page Détails du journal qui s’affiche, sélectionnez le lien Afficher les journaux qui apparaît à côté de Build Oryx en cours d’exécution.

Les problèmes de génération, tels que les dépendances incorrectes dans votre fichier de dépendances et les erreurs dans les scripts pré-génération ou post-génération, apparaissent dans ces journaux. Les erreurs s’affichent également si votre fichier de dépendance n’est pas trouvé dans le dossier racine de votre projet.

Ouvrir une session SSH dans un navigateur

Si vous souhaitez ouvrir une session SSH directe avec votre conteneur, votre application doit être en cours d’exécution.

Utilisez la commande az webapp ssh .

Si vous n’êtes pas authentifié, vous devez vous authentifier avec votre abonnement Azure pour vous connecter. Une fois authentifié, vous voyez apparaître un interpréteur de commandes dans votre navigateur, qui vous permet d’exécuter des commandes dans votre conteneur.

Connexion SSH

Remarque

Toutes les modifications que vous apportez en dehors du /home répertoire sont stockées dans le conteneur lui-même et ne sont pas conservées au-delà d’un redémarrage de l’application.

Pour ouvrir une session SSH à distance à partir de votre machine locale, consultez Ouvrir une session SSH à partir d’un interpréteur de commandes à distance.

Lorsque vous êtes correctement connecté à la session SSH, vous devez voir le message « CONNEXION SSH ÉTABLIE » en bas de la fenêtre. Si vous voyez des erreurs telles que « SSH_CONNECTION_CLOSED » ou un message qui indique que le conteneur redémarre, une erreur empêche peut-être le conteneur de l’application de démarrer. Pour plus d’informations sur la recherche des problèmes éventuels, consultez la section Résolution des problèmes.

Réécritures d’URL

Lors du déploiement d’applications Python sur App Service pour Linux, vous devrez peut-être gérer les réécritures d’URL au sein de votre application. Cette méthode est particulièrement utile pour garantir que des modèles d’URL spécifiques soient redirigés vers les points de terminaison appropriés sans dépendre des configurations de serveurs web externes. Pour les applications Flask, vous pouvez utiliser des processeurs d’URL et des intergiciels personnalisés pour y parvenir. Dans les applications Django, le répartiteur d’URL permet une gestion efficace des réécritures d’URL.

Dépannage

En général, la première étape de dépannage consiste à utiliser les diagnostics d’App Service :

  1. Sur la page du Portail Azure dédiée à votre application web, sélectionnez Diagnostiquer et résoudre les problèmes dans le volet gauche.
  2. Sélectionnez Disponibilité et performances.
  3. Examinez les informations contenues dans les Journaux d’application, les Incidents de conteneur et les Problèmes de conteneur, où apparaissent les problèmes les plus courants.

Consultez ensuite les journaux de déploiement et les journaux des applications à la recherche de messages d’erreur. Ces journaux identifient souvent des problèmes particuliers pouvant empêcher le déploiement ou le démarrage de l’application. Par exemple, la build peut échouer si votre fichier de dépendance n’est pas présent dans votre dossier racine de projet.

Les sections suivantes fournissent des conseils par rapport à des problèmes spécifiques.

L’application n’apparaît pas

  • Vous voyez l’application par défaut après le déploiement du code de votre propre application. L’application par défaut s’affiche soit parce que vous n’avez pas déployé le code de votre application sur App Service, soit parce qu’App Service n’a pas réussi à trouver le code de votre application et a exécuté l’application par défaut à la place.

    • Redémarrez l’application, attendez 20 secondes, puis vérifiez à nouveau l’application.

    • Utilisez SSH pour vous connecter directement au conteneur App Service et vérifier que vos fichiers existent sous site/wwwroot. Si vos fichiers n’existent pas, suivez les étapes suivantes :

      1. Créez un paramètre d’application nommé SCM_DO_BUILD_DURING_DEPLOYMENT avec une valeur 1 redéployez votre code, attendez quelques minutes, puis essayez à nouveau d’accéder à l’application. Pour plus d’informations sur la création de paramètres d’application, consultez Configurer une application App Service dans le portail Azure.
      2. Passez en revue votre processus de déploiement, vérifiez les journaux de déploiement, corrigez les erreurs et redéployez l’application.

    • Si vos fichiers existent, App Service n’a pas pu identifier votre fichier de démarrage. Assurez-vous que votre application est structurée conformément aux attentes d’App Service pour Django ou Flask, ou utilisez une commande de démarrage personnalisée.

  • Le message « Service Unavailable » (Service indisponible) s’affiche dans le navigateur. Le navigateur a expiré en attente d’une réponse d’App Service. Cela signifie qu’App Service a démarré le serveur Gunicorn, mais que l’application elle-même n’a pas démarré. Cette condition peut indiquer que les arguments Gunicorn sont incorrects ou qu’il y a une erreur dans le code de l’application.

    • Actualisez le navigateur, en particulier si vous utilisez les niveaux tarifaires les plus bas pour votre plan App Service. Par exemple, l’application peut prendre plus de temps à démarrer lorsque vous utilisez des niveaux gratuits, et devenir réactive après avoir actualisé le navigateur.

    • Vérifiez que votre application est structurée conformément aux attentes d’App Service pour Django ou Flask, ou utilisez une commande de démarrage personnalisée.

    • Examinez le flux de journal d’application pour les messages d’erreur. Les journaux affichent les erreurs présentes dans le code de l’application.

setup.py ou requirements.txt est introuvable

  • Le flux de journal affiche « Impossible de trouver setup.py ou requirements.txt; Pas d’installation pip en cours d’exécution. » Le processus de génération Oryx n’a pas trouvé votre requirements.txt, pyproject.toml ou fichier setup.py .

    • Connectez-vous au conteneur de l’application web via SSH et vérifiez que votre fichier de dépendance est nommé correctement et existe directement sous site/wwwroot. S’il n’existe pas, faites en sorte que le fichier se trouve dans votre référentiel et qu’il soit inclus dans votre déploiement. S’il existe dans un dossier distinct, déplacez-le à la racine.

ModuleNotFoundError au démarrage de l’application

Si vous voyez une erreur telle que ModuleNotFoundError: No module named 'example', Python n’a pas pu trouver un ou plusieurs de vos modules au démarrage de l’application. Cette erreur se produit généralement si vous déployez votre environnement virtuel avec votre code. Les environnements virtuels n’étant pas portables, un environnement virtuel ne doit pas être déployé avec votre code d’application. Laissez plutôt Oryx créer un environnement virtuel et installer vos packages sur l’application web en créant un paramètre d’application, SCM_DO_BUILD_DURING_DEPLOYMENT, et en lui attribuant la valeur 1. Ce paramètre force Oryx à installer vos packages chaque fois que vous effectuez un déploiement vers App Service. Pour plus d’informations, consultez cet article sur la portabilité de l’environnement virtuel.

La base de données est verrouillée

Quand vous tentez d’exécuter des migrations de base de données avec une application Django, vous pouvez voir s’afficher « sqlite3. OperationalError: database is locked." L’erreur indique que votre application utilise une base de données SQLite, pour laquelle Django est configuré par défaut, plutôt qu’une base de données cloud telle qu’Azure Database pour PostgreSQL.

Vérifiez la variable DATABASES dans le fichier settings.py de l’application pour vous assurer que votre application utilise une base de données cloud au lieu de SQLite.

Si cette erreur se produit dans l’exemple du Didacticiel : Déployer une application web Django avec PostgreSQL, vérifiez que vous avez effectué les étapes décrites dans Vérifier les paramètres de connexion.

Autres problèmes

  • Les mots de passe ne s’affichent pas dans la session SSH lorsqu’ils sont tapés : pour des raisons de sécurité, la session SSH maintient le mot de passe masqué en cours de frappe. Les caractères sont toutefois enregistrés. Tapez donc votre mot de passe comme d’habitude et sélectionnez Entrée lorsque vous avez terminé.

  • Les commandes de la session SSH semblent être coupées : il est possible que l’éditeur n’utilise pas de retour automatique à la ligne pour les commandes. Toutefois, celles-ci devraient tout de même s’exécuter correctement.

  • Les ressources statiques n’apparaissent pas dans une application Django: assurez-vous d’avoir activé le module WhiteNoise.

  • Vous voyez le message « Fatal SSL Connection is Required » : vérifiez tous les noms d’utilisateur et mots de passe utilisés pour accéder aux ressources (telles que les bases de données) depuis l’application.

Contenu connexe

  • Last updated on