Partager via

Configurer un fichier de démarrage personnalisé pour les applications Python sur Azure App Service

Dans cet article, vous allez découvrir quand et comment configurer un fichier de démarrage personnalisé pour une application web Python hébergée sur Azure App Service. Bien qu’un fichier de démarrage ne soit pas requis pour le développement local, Azure App Service exécute votre application web déployée dans un conteneur Docker qui peut utiliser les commandes de démarrage si elles sont fournies.

Vous avez besoin d’un fichier de démarrage personnalisé dans les situations suivantes :

  • Arguments Gunicorn personnalisés : vous souhaitez démarrer le serveur web par défaut Gunicorn avec des arguments supplémentaires au-delà de ses valeurs par défaut, qui sont --bind=0.0.0.0 --timeout 600.

  • Autres frameworks ou serveurs : votre application est créée avec une infrastructure autre que Flask ou Django, ou vous souhaitez utiliser un autre serveur web en plus de Gunicorn.

  • Structure d’application Flask non standard : vous disposez d’une application Flask dont le fichier de code principal est nommé autre queapp.py ou application.py*, ou l’objet d’application est nommé autre chose que app.

En d’autres termes, une commande de démarrage personnalisée est requise, sauf si votre projet a un fichier app.py ou application.py dans le dossier racine avec un objet d’application Flask nommé app.

Pour plus d’informations, consultez Configurer python Apps - Processus de démarrage de conteneur.

Créer un fichier de démarrage

Lorsque vous avez besoin d’un fichier de démarrage personnalisé, procédez comme suit :

  1. Créez un fichier dans votre projet nommé startup.txt, startup.sh ou un autre nom de votre choix qui contient vos commandes de démarrage. Pour plus d’informations sur Django, Flask et d’autres frameworks, consultez les sections ultérieures de cet article.

    Un fichier de démarrage peut inclure plusieurs commandes si nécessaire.

  2. Validez le fichier dans votre référentiel de code afin qu’il puisse être déployé avec le reste de l’application.

  3. Dans Visual Studio Code, sélectionnez l’icône Azure dans la barre d’activités, développez RESSOURCES, recherchez et développez votre abonnement, développez App Services, cliquez avec le bouton droit sur App Service, puis sélectionnez Ouvrir dans le portail.

  4. Dans le portail Azure, dans la page Configuration de l’App Service, sélectionnez Paramètres généraux, entrez le nom de votre fichier de démarrage (par exemple ,startup.txt ou startup.sh) sousCommande de démarrage des > de pile, puis sélectionnez Enregistrer.

    Remarque

    Au lieu d’utiliser un fichier de commande de démarrage, vous pouvez placer la commande de démarrage elle-même directement dans le champ Commande de démarrage sur le portail Azure. L’utilisation d’un fichier de commande de démarrage est recommandée, car elle stocke votre configuration dans votre référentiel. Cela permet au contrôle de version de suivre les modifications et simplifie le redéploiement vers d’autres instances Azure App Service.

  5. Sélectionnez Continuer quand vous êtes invité à redémarrer App Service.

    Si vous accédez à votre site Azure App Service avant de déployer votre code d’application, une « erreur d’application » s’affiche, car aucun code n’est disponible pour traiter la demande.

Commandes de démarrage Django

Par défaut, Azure App Service localise le dossier contenant votre fichier wsgi.py et démarre Gunicorn avec la commande suivante :

# <module> is the folder that contains wsgi.py. If you need to use a subfolder,
# specify the parent of <module> using --chdir.
gunicorn --bind=0.0.0.0 --timeout 600 <module>.wsgi

Si vous souhaitez modifier des arguments Gunicorn, tels que l’augmentation de la valeur de délai d’expiration à 1 200 secondes(--timeout 1200), créez un fichier de commande de démarrage personnalisé. Cela vous permet de remplacer les paramètres par défaut par vos exigences spécifiques. Pour plus d’informations, consultez le processus de démarrage de conteneur - Application Django.

Commandes de démarrage Flask

Par défaut, App Service sur Linux suppose que votre application Flask répond au critear suivant :

  • L’appelant WSGI est nommé app.
  • Le code de l’application est contenu dans un fichier nommé application.py ou app.py.
  • Le fichier d’application se trouve dans le dossier racine de l’application.

Si votre projet diffère de cette structure, votre commande de démarrage personnalisée doit identifier l’emplacement de l’objet d’application dans le fichier de format  :app_object :

  • Nom de fichier et/ou nom d’objet d’application différents : si le fichier de code principal de l’application est hello.py et que l’objet d’application est nommé myapp, la commande de démarrage est la suivante :

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

  • Le fichier de démarrage se trouve dans un sous-dossier : si le fichier de démarrage est myapp/website.py et que l’objet d’application est app, utilisez l’argument de --chdir Gunicorn pour spécifier le dossier, puis nommez le fichier de démarrage et l’objet d’application comme d’habitude :

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

  • Le fichier de démarrage se trouve dans un module : dans le code python-sample-vscode-flask-tutorial , le fichier de démarrage webapp.py est contenu dans le dossier hello_app, qui est lui-même un module avec un fichier __init__.py . L’objet d’application est nommé app et est défini dans __init__.py et webapp.py utilise une importation relative.

    En raison de cette disposition, pointer Gunicorn vers webapp:app produit l'erreur « Tentative d’importation relative dans un module non package » et l’application ne réussit pas à démarrer.

    Dans ce cas, créez un fichier d'interposition qui importe l'objet de l'application à partir du module, puis faites lancer l'application par Gunicorn à l'aide du fichier d'interposition. Le code python-sample-vscode-flask-tutorial , par exemple, contient startup.py avec le contenu suivant :

    from hello_app.webapp import app

    La commande de démarrage est ensuite :

    gunicorn --bind=0.0.0.0 --workers=4 startup:app

Pour plus d’informations, consultez le processus de démarrage de conteneur - Application Flask.

Autres frameworks et serveurs web

Le conteneur App Service qui exécute des applications Python a Django et Flask installés par défaut, ainsi que le serveur web Gunicorn.

Pour utiliser une infrastructure autre que Django ou Flask (comme Falcon, FastAPI, etc.) ou pour utiliser un autre serveur web :

  • Incluez l’infrastructure et/ou le serveur web dans votre fichier requirements.txt .

  • Dans votre commande de démarrage, identifiez l’appelant WSGI comme décrit dans la section précédente de Flask.

  • Pour lancer un serveur web autre que Gunicorn, utilisez une python -m commande au lieu d’appeler directement le serveur. Par exemple, la commande suivante démarre le serveur uvicorn , en supposant que l’appelant WSGI est nommé app et se trouve dans application.py :

    python -m uvicorn application:app --host 0.0.0.0

    Vous utilisez python -m parce que les serveurs web installés via requirements.txt ne sont pas ajoutés à l’environnement global Python et ne peuvent donc pas être appelés directement. La python -m commande appelle le serveur à partir de l’environnement virtuel actuel.