Configurer une application Python Linux pour Azure App Service

  • Article

Cet article explique comment Azure App Service exécute des applications Python, comment vous pouvez migrer des applications existantes vers Azure et comment vous pouvez 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 exécute automatiquement pip install -r requirements.txt quand vous déployez un référentiel Git ou un package zipavec l’automatisation de génération activée.

Ce guide fournit des concepts et des instructions clés aux développeurs Python qui utilisent un conteneur Linux intégré dans App Service. Si vous n’avez jamais utilisé Azure App Service, commencez par suivre le démarrage rapide Python et le tutoriel sur l’utilisation de Python avec PostgreSQL.

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

Notes

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 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 avec az webapp config show :

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

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

    • Définissez la version de Python avec az webapp config set :

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

    • Affichez toutes les versions de Python prises en charge dans Azure App Service avec 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 générant votre propre image conteneur à la place. Pour plus d’informations, consultez Utiliser une image Docker personnalisée.

Personnaliser l’automatisation de la génération

Le système de génération d’App Service, appelé Oryx, effectue les étapes suivantes au moment où vous déployez votre application si le paramètre d’application SCM_DO_BUILD_DURING_DEPLOYMENT est défini sur 1 :

  1. Exécutez un script de prégénération personnalisé s’il est spécifié 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 Node tels que yarn, par exemple yarn install et yarn build.)

  2. Exécutez pip install -r requirements.txt. Le fichier requirements.txt doit être présent dans le dossier racine du projet. Dans le cas contraire, le processus de génération signale l’erreur : « setup.py ou requirements.txt est introuvable. Installation de pip non exécutée ».

  3. Si manage.py se trouve à la racine du dépôt (indiquant 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 de post-génération personnalisé s’il est spécifié par 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 pendant la génération 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 de fichier de script par rapport à la racine de votre projet, comme scripts/prebuild.sh. Toutes les commandes doivent utiliser des chemins relatifs du 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 de fichier de script par rapport à la racine de votre projet, comme scripts/postbuild.sh. Toutes les commandes doivent utiliser des chemins relatifs du dossier racine du projet.

Pour connaître les autres paramètres permettant de personnaliser l’automatisation de la génération, consultez Configuration d’Oryx.

Pour accéder aux journaux de génération 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.

Notes

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.

Notes

Utilisez toujours des chemins relatifs dans tous les scripts de pré et post-génération, car le conteneur de génération dans lequel Oryx s’exécute est différent du conteneur de runtime 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

Les applications web existantes peuvent être redéployées dans Azure comme suit :

  1. Dépôt source : Conservez votre code source dans un dépôt approprié comme GitHub, qui vous permettra de configurer ultérieurement un déploiement continu dans ce processus.

    • Votre fichier requirements.txt doit se trouver à la racine de votre dépôt pour 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 dans Azure.

  3. Ressources App Service : Créez un groupe de ressources, un plan App Service et une application web App Service pour héberger votre application. Vous pouvez le faire facilement en exécutant la commande Azure CLI az webapp up. Vous pouvez aussi créer et déployer des ressources comme indiqué dans Tutoriel : Déploiement d’une application web Python (Django ou Flask) avec PostgreSQL. Remplacez les noms du groupe de ressources, du plan App Service et de l’application web pour qu’ils conviennent mieux à 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 pour votre code comme des variables d’environnement, comme cela est décrit dans Accéder aux variables d’environnement.

  5. Démarrage d’application : Passez en revue la section Processus de démarrage du conteneur, plus loin dans cet article, pour comprendre comment App Service tente d’exécuter votre application. App Service utilise par défaut le serveur web Gunicorn, qui doit être en mesure de trouver votre objet d’application ou le 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 (cf. l’article Déploiement continu sur Azure App Service) ou à partir de Git local (cf. l’article Déploiement Git local sur 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 obtenir un exemple d’exécution des migrations de base de données Django, consultez Tutoriel : Déployer une application web Django avec PostgreSQL – Générer un schéma de base de données.

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 comme Azure App Service, les applications Django doivent respecter la liste de vérification de déploiement de Django (djangoproject.com).

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 d’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 dans 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 impose d’inclure l’URL de l’application dans le tableau ALLOWED_HOSTS de settings.py. Vous pouvez récupérer cette URL au moment de l’exécution avec le 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 (notamment le nom d’utilisateur et le mot de passe) en tant que secrets Azure 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. Pensez à utiliser des variables d’environnement (pour le développement local) et des paramètres d’application (au moment du déploiement sur le cloud) afin de 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 génération de vos fichiers statiques les place dans un dossier nommé django-static, vous pouvez affecter à DJANGO_STATIC_URL la valeur /django-static/ pour é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 front-end et si yarn génère un dossier build/static contenant des fichiers statiques, incluez ce dossier de la façon suivante :

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

    Ici, FRONTEND_DIR permet de créer un chemin vers l’emplacement d’exécution d’un outil de build tel que yarn. Vous pouvez réutiliser une variable d’environnement et un paramètre d’application, si nécessaire.

  3. Ajoutez whitenoise à votre fichier requirements.txt. Whitenoise (whitenoise.evans.io) est un package Python qui permet à une application de production Django de distribuer ses propres fichiers statiques. Whitenoise cible en particulier 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 également 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 relatives à la 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 pour démarrage rapide 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. Les configurations d’images se trouvent dans les répertoires spécifiques des versions.

Ce conteneur présente les caractéristiques suivantes :

  • Les applications sont exécutées à l’aide de Gunicorn WSGI HTTP Server, en utilisant les arguments supplémentaires --bind=0.0.0.0 --timeout 600.

    • Vous pouvez fournir des paramètres de configuration pour Gunicorn en personnalisant la commande de démarrage.

    • Pour protéger votre application web contre les attaques DDOS accidentelles ou délibérées, Gunicorn s’exécute derrière un proxy inverse Nginx, comme décrit dans le document Deploying Gunicorn (docs.gunicorn.org).

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

  • Pour installer des autres packages, tels que Django, créez un fichier requirements.txt à 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 requirements.txtdoit se trouver à la racine du projet pour les dépendances à installer. Dans le cas contraire, le processus de génération signale l’erreur : « setup.py ou requirements.txt est introuvable. Installation de pip non exécutée ». Si vous rencontrez cette erreur, vérifiez l’emplacement de votre fichier requirements.

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

  • npm et Node.js sont installés dans le conteneur pour que vous puissiez exécuter des outils de build Node, par exemple yarn.

Processus de démarrage du conteneur

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

  1. Si elle est fournie, utilisez une commande de démarrage personnalisée.
  2. Vérifiez l’existence d’une application Django et, si elle existe, lancez Gunicorn.
  3. Vérifiez l’existence d’une application Flask et, si elle existe, lancez Gunicorn.
  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 et 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 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 principal est contenu dans un autre fichier, utilisez un nom différent pour l’objet d’application. Si vous souhaitez fournir des arguments supplémentaires à Gunicorn, utilisez une commande de démarrage personnalisée.

Comportement par défaut

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

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.

Screenshot of the default App Service on Linux web page.

Là encore, si vous vous attendez à voir une application déployée à la place de l’application par défaut, consultez Résolution des problèmes – L’application n’apparaît pas.

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. Vous pouvez attribuer le nom de votre choix à un fichier de commandes de démarrage, par exemple startup.sh, startup.cmd, Startup.txt, etc.

Toutes les commandes doivent utiliser des chemins relatifs du dossier racine du projet.

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

  • Portail Azure : sélectionnez la page Configuration de l’application, puis sélectionnez Paramètres généraux. Dans le champ Commande de démarrage, placez soit le texte complet de votre commande de démarrage, soit le nom de votre fichier de commandes 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 : utilisez la commande az webapp config set avec le paramètre --startup-file pour définir la commande de démarrage ou le fichier :

    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 les erreurs qui surviennent lors du traitement d’une commande de démarrage personnalisée ou d’un fichier, puis continue son processus de démarrage en recherchant des applications Django et Flask. Si vous constatez un comportement inattendu, vérifiez que votre commande de démarrage et votre fichier sont exempts d’erreurs et qu’un fichier de commandes de démarrage est déployé dans App Service avec le code de votre application. Vous pouvez aussi consulter les journaux de diagnostic pour plus d’informations. Consultez également la page Diagnostiquer et résoudre les problèmes de l’application sur le portail Azure.

Exemples de commandes de démarrage

  • Arguments Gunicorn ajoutés : l’exemple suivant ajoute --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 containing wsgi.py.
gunicorn --bind=0.0.0.0 --timeout 600 --workers=4 --chdir <module_path> <module>.wsgi

    Pour plus d’informations, consultez Running Gunicorn (Exécuter Gunicorn - docs.gunicorn.org). Si vous utilisez des règles de mise à l’échelle automatique pour mettre à l’échelle votre application web vers le haut et le bas, vous devrez aussi définir dynamiquement 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 la définition du nombre recommandé de Workers, voir le FAQ 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 le document Gunicorn logging (docs.gunicorn.org).

  • 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 se nomme différemment, vous devez personnaliser la commande de démarrage. Par exemple, si vous disposez d’une application Flask dont le module principal est hello.py et que l’objet d’application Flask dans le fichier est nommé myapp, la commande est la suivante :

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

    Si votre module principal est dans un sous-dossier, tel que website, précisez ce dossier grâce à 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 d’application sont des valeurs stockées dans le cloud spécifiquement pour votre application, comme décrit dans Configurer des paramètres d’application. Ces paramètres sont accessibles au code de votre application en tant que variables d’environnement à l’aide du modèle os.environ standard.

Par exemple, si vous avez créé 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 (wikipedia.org) 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 votre logique d’application doit vérifier si les requêtes utilisateur sont chiffrées ou non, 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. Dans Django par exemple, vous pouvez utiliser SECURE_PROXY_SSL_HEADER pour indiquer à Django d’utiliser l’en-tête X-Forwarded-Proto.

Accéder aux journaux de diagnostic

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

Activez d’abord la journalisation du conteneur en exécutant la commande suivante :

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

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

Une fois la journalisation du conteneur activée, exécutez la commande suivante pour voir le flux de journal :

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

Si vous ne voyez pas les journaux d’activité de la console, attendez 30 secondes et vérifiez à nouveau.

Pour arrêter le streaming de journaux à tout moment, appuyez sur Ctrl+C.

Vous pouvez également inspecter les fichiers journaux dans un navigateur sur https://<app-name>.scm.azurewebsites.net/api/logs/docker.

Pour accéder aux journaux via le portail Azure, sélectionnez Supervision>Flux de journaux dans le menu de gauche de votre application.

Accéder aux journaux de déploiement

Lorsque vous déployez votre code, App Service effectue le processus de génération décrit précédemment dans la section Personnaliser l’automatisation de la génération. Comme la build s’exécute dans son propre conteneur, les journaux de génération 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 le Portail Azure dans votre application web, sélectionnez Déploiement>Centre de déploiement dans le menu de gauche.
  2. Sous l’onglet Journaux, sélectionnez l’ID de validation pour la validation la plus récente.
  3. Dans la page Détails des journaux qui s’affiche, sélectionnez le lien Afficher les journaux.. qui apparaît en regard de « Exécution de la génération Oryx... ».

Les problèmes de génération, tels que des dépendances incorrectes dans requirements.txt et des erreurs dans les scripts pré- ou post-build, s’affichent dans ces journaux. Des erreurs s’affichent également si votre fichier de spécifications n’est pas exactement nommé requirements.txt, ou s’il n’apparaît pas dans le dossier racine de votre projet.

Ouvrir une session SSH dans un navigateur

Pour établir une session SSH directe avec votre conteneur, votre application doit être en cours d’exécution.

Collez l’URL suivante dans votre navigateur et remplacez <app-name> par le nom de votre application :

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

Si vous n’êtes pas encore authentifié, vous devez le faire avec votre abonnement Azure pour vous connecter. Une fois authentifié, vous voyez un interpréteur de commandes dans le navigateur, vous permettant d’exécuter des commandes à l’intérieur de votre conteneur.

SSH connection

Remarque

Les modifications apportées en dehors du répertoire /home sont stockées dans le conteneur lui-même et ne sont pas conservées après le redémarrage d’une 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 » (CONNEXION_SSH_FERMÉE) ou un message indiquant que le conteneur est en cours de redémarrage, il est possible qu’une erreur empêche le démarrage du conteneur d’application. Consultez Résolution des problèmes pour connaître les étapes permettant de rechercher la source des problèmes éventuels.

Dépannage

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

  1. Sur le Portail Azure dans votre application web, sélectionnez Diagnostiquer et résoudre les problèmes dans le menu de gauche.
  2. Sélectionnez Disponibilité et performances.
  3. Examinez les informations contenues dans les options Journaux des applications, Incidents de conteneur et Problèmes de conteneur, dans lesquelles s’affichent 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 génération peut échouer si votre fichier requirements.txt a un nom de fichier incorrect, ou s’il n’est pas présent dans le dossier racine de votre 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 trouvé le code de votre application et a exécuté l’application par défaut à la place.

    • Redémarrez App Service, patientez 15 à 20 secondes et vérifiez de 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, effectuez les étapes suivantes :

      1. Créez un paramètre d’application nommé SCM_DO_BUILD_DURING_DEPLOYMENT avec la valeur 1, redéployez votre code, patientez quelques minutes, puis essayez d’accéder de nouveau à 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, cela signifie qu’App Service n’a pas été en mesure d’identifier votre fichier de démarrage. Vérifiez que votre application est structurée selon ce qu’App Service attend pour Django ou Flask, ou bien utilisez une commande de démarrage personnalisée.

  • Le message « Service indisponible » s’affiche dans le navigateur. Le délai d’attente du navigateur a expiré en l’absence d’une réponse d’App Service, ce qui indique qu’App Service a démarré le serveur Gunicorn, mais que l’application elle-même n’a pas démarré. Cette condition peut révéler 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 si vous utilisez des niveaux gratuits et répondre une fois que vous avez actualisé le navigateur.

    • Vérifiez que votre application est structurée selon ce qu’App Service attend pour Django ou Flask, ou bien utilisez une commande de démarrage personnalisée.

    • Examinez le flux des journaux de l’application à la recherche de messages d’erreur. Les journaux affichent toutes les erreurs figurant dans le code de l’application.

setup.py ou requirements.txt est introuvable

  • Le flux de journaux affiche « setup.py ou requirements.txt est introuvable. Installation de pip non exécutée » : Le processus de génération Oryx n’a pas pu trouver votre fichier requirements.txt.

    • Connectez-vous au conteneur de l’application web via SSH et vérifiez que le fichier requirements.txt est nommé correctement et qu’il 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 du type ModuleNotFoundError: No module named 'example', cela signifie que Python n’a pas trouvé 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 sur App Service. Pour plus d’informations, consultez cet article sur la portabilité de l’environnement virtuel.

La base de données est verrouillée

Lorsque vous tentez d’exécuter des migrations de base de données avec une application Django, le message « sqlite3. OperationalError : la base de données est verrouillée. » peut s’afficher. Elle indique que votre application utilise une base de données SQLite pour laquelle l’application Django est configurée par défaut, plutôt qu’une base de données cloud comme PostgreSQL pour Azure.

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 néanmoins enregistrés, par conséquent, tapez votre mot de passe comme d’habitude et appuyez sur Entrée quand vous avez terminé.

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

  • Les ressources statiques n’apparaissent pas dans une application Django : vérifiez que vous avez activé le module Whitenoise.

  • Le message « Irrécupérable : Connexion SSL obligatoire » s’affiche : Vérifiez les noms d’utilisateur et les mots de passe utilisés pour accéder aux ressources (telles que les bases de données) à partir de l’application.

Plus de ressources