Déployer des applications web Python sur App Service à l’aide de GitHub Actions (Linux)

Cet article explique comment utiliser la plateforme d’intégration continue et de livraison continue (CI/CD) dans GitHub Actions pour déployer une application web Python sur Azure App Service sur Linux. Votre workflow GitHub Actions génère automatiquement le code et le déploie sur l’instance App Service chaque fois qu’il existe une validation dans le référentiel. Vous pouvez ajouter d’autres automatisations dans votre workflow GitHub Actions, telles que des scripts de test, des vérifications de sécurité et un déploiement multistages.

Créer un référentiel pour le code d’application

Pour suivre les procédures décrites dans cet article, vous avez besoin d’une application web Python validée dans un dépôt GitHub.

Application existante : pour utiliser une application web Python existante, vérifiez que l’application est validée dans un dépôt GitHub.
Nouvelle application : si vous avez besoin d’une nouvelle application web Python, vous pouvez fork et cloner le https://github.com/Microsoft/python-sample-vscode-flask-tutorial dépôt GitHub. L’exemple de code prend en charge le didacticiel Flask dans Visual Studio Code et fournit une application Python fonctionnelle.

Remarque

Si votre application utilise Django et une base de données SQLite , elle ne fonctionnera pas pour ces procédures. SQLite n’est pas pris en charge dans la plupart des environnements hébergés dans le cloud en raison de ses limitations de stockage basées sur des fichiers locaux. Envisagez de passer à une base de données compatible avec le cloud, telle que PostgreSQL ou Azure Cosmos DB. Pour plus d’informations, consultez Consulter les considérations relatives à Django plus loin dans cet article.

Créer une instance App Service cible

Le moyen le plus rapide de créer une instance App Service consiste à utiliser l’interface de ligne de commande Azure (CLI) via Azure Cloud Shell interactif. Cloud Shell inclut Git et Azure CLI. Dans la procédure suivante, vous utilisez la commande az webapp up pour créer l’instance App Service et effectuer le déploiement initial de votre application.

Connectez-vous au portail Azure à l’adressehttps://portal.azure.com.
Ouvrez Azure CLI en sélectionnant l’option Cloud Shell dans la barre d’outils du portail :
Dans Cloud Shell, sélectionnez l’option Bash dans le menu déroulant :
Dans Cloud Shell, clonez votre dépôt à l’aide de la commande git clone .

Conseil / Astuce

Pour coller des commandes ou du texte dans Cloud Shell, utilisez le raccourci clavier Ctrl+Maj+V , ou cliquez avec le bouton droit et sélectionnez Coller dans le menu contextuel.
- Pour l’exemple d’application Flask, vous pouvez utiliser la commande suivante. Remplacez la <github-user> partie par le nom du compte GitHub où vous avez dépliqué le dépôt :
```
git clone https://github.com/<github-user>/python-sample-vscode-flask-tutorial.git
```
- Si votre application se trouve dans un autre dépôt, configurez GitHub Actions pour le dépôt particulier. Remplacez la <github-user> partie par le nom du compte GitHub où vous avez dépliqué le dépôt et indiquez le nom réel du dépôt dans l’espace <repo-name> réservé :
```
git clone https://github.com/<github-user>/<repo-name>.git
```
Remarque

Cloud Shell est soutenu par un compte de stockage Azure dans un groupe de ressources nommé cloud-shell-storage-your-region<>. Ce compte de stockage contient une image du système de fichiers Cloud Shell, qui stocke le référentiel cloné. Il y a un petit coût pour ce stockage. Vous pouvez supprimer le compte de stockage une fois cet article terminé, ainsi que d’autres ressources que vous créez.
Dans Cloud Shell, remplacez le répertoire dans le dossier du référentiel de votre application Python. Par conséquent, la commande az webapp up reconnaît l’application en tant que Python. Pour l’exemple d’application Flask, vous utilisez la commande suivante :
```
cd python-sample-vscode-flask-tutorial
```
Dans Cloud Shell, utilisez la commande az webapp up pour créer une instance App Service et effectuer le déploiement initial de votre application :
```
az webapp up --name <app-service-name> --runtime "PYTHON:3.9"
```
- Pour l’espace réservé <app-service-name>, spécifiez un nom d'App Service unique dans Azure. Le nom doit comporter 3 à 60 caractères et ne peut contenir que des lettres, des chiffres et des traits d’union. Le nom doit commencer par une lettre, et se terminer par une lettre ou un chiffre.
- Pour obtenir la liste des runtimes disponibles sur votre système, utilisez la az webapp list-runtimes commande.
- Lorsque vous entrez la valeur d’exécution dans la commande, utilisez le format PYTHON:X.Y, où X.Y est la version principale et mineure de Python.
- Vous pouvez également spécifier l’emplacement de région de l’instance App Service à l’aide du --location paramètre. Pour obtenir la liste des emplacements disponibles, utilisez la az account list-locations --output table commande.
Si votre application a un script de démarrage personnalisé, utilisez la commande az webapp config pour lancer le script.
- Si votre application n’a pas de script de démarrage personnalisé, passez à l’étape suivante.
- Pour l’exemple d’application Flask, vous devez accéder au script de démarrage dans le fichier startup.txt en exécutant la commande suivante :
```
az webapp config set \
   --resource-group <resource-group-name> \
   --name <app-service-name> \
   --startup-file startup.txt
```
  Fournissez le nom de votre groupe de ressources et le nom de l’instance App Service dans les espaces réservés <resource-group-name> et <app-service-name>. Pour rechercher le nom du groupe de ressources, vérifiez la sortie de la commande précédente az webapp up . Le nom du groupe de ressources inclut le nom du compte Azure suivi du suffixe _rg , comme dans <azure-account-name>_rg_.
Pour afficher l’application en cours d’exécution, ouvrez un navigateur et accédez au point de terminaison de déploiement de votre instance App Service. Dans l’URL suivante, remplacez l’espace <app-service-name> réservé par le nom de votre instance App Service :
```
http://<app-service-name>.azurewebsites.net
```
Si vous voyez une page générique, attendez quelques secondes que l’instance App Service démarre et actualisez la page.
- Si vous continuez à voir une page générique, vérifiez que vous avez déployé à partir du dossier approprié.
- Pour l’exemple d’application Flask, vérifiez que vous avez déployé à partir du dossier python-sample-vscode-flask-tutorial . Vérifiez également que vous définissez correctement la commande de démarrage.

Configurer le déploiement continu dans App Service

Dans la procédure suivante, vous configurez la livraison continue (CD), ce qui signifie qu’un nouveau déploiement de code se produit chaque fois qu’un flux de travail se déclenche. Le déclencheur de l’exemple d’article est toute modification apportée à la branche principale de votre référentiel, par exemple avec une demande de tirage (pull request).

Dans Cloud Shell, vérifiez que vous êtes dans le répertoire racine de votre système (~) et non dans un sous-dossier d’application, tel que python-sample-vscode-flask-tutorial.
Ajoutez GitHub Actions avec la commande az webapp deployment github-actions add . Remplacez les espaces réservés par vos valeurs spécifiques :
```
az webapp deployment github-actions add \
  --repo "<github-user>/<github-repo>" \
  --resource-group <resource-group-name> \
  --branch <branch-name> \
  --name <app-service-name> \
  --login-with-github
```
- Le --login-with-github paramètre utilise une méthode interactive pour récupérer un jeton d’accès personnel. Suivez les instructions et complétez l’authentification.
- Si le système rencontre un fichier de flux de travail existant portant le même nom d'instance "App Service", suivez les étapes indiquées pour choisir si vous souhaitez remplacer le flux de travail. Vous pouvez utiliser le --force paramètre avec la commande pour remplacer automatiquement les flux de travail en conflit.
La add commande effectue les tâches suivantes :
- Crée un fichier de flux de travail sur le chemin .github/workflows/<workflow-name>.yml dans votre dépôt. Le nom de fichier contient le nom de votre instance App Service.
- Récupère un profil de publication avec des secrets pour votre instance App Service et l’ajoute en tant que secret d’action GitHub. Le nom du secret commence par AZUREAPPSERVICE_PUBLISHPROFILE_. Ce secret est référencé dans le fichier de flux de travail.
Obtenez les détails d’une configuration de déploiement de contrôle de code source avec la commande az webapp deployment source show . Remplacez les paramètres d’espace réservé par vos valeurs spécifiques :
```
az webapp deployment source show \
  --name <app-service-name> \
  --resource-group <resource-group-name>
```
Dans la sortie de commande, confirmez les valeurs pour les propriétés repoUrl et branch. Ces valeurs doivent correspondre aux valeurs que vous avez spécifiées avec la add commande.

Examiner le flux de travail et les actions GitHub

Une définition de flux de travail est spécifiée dans un fichier YAML (.yml) dans le chemin /.github/workflows/ de votre dépôt. Ce fichier YAML contient les différentes étapes et paramètres qui composent le flux de travail, un processus automatisé associé à un dépôt GitHub. Vous pouvez générer, tester, empaqueter, publier et déployer n’importe quel projet sur GitHub avec un flux de travail.

Chaque flux de travail est constitué d’un ou plusieurs travaux, et chaque travail est un ensemble d’étapes. Chaque étape est un script shell ou une action. Chaque travail a une section Action dans le fichier de flux de travail.

En termes de flux de travail configuré avec votre code Python pour le déploiement sur Azure App Service, le flux de travail a les actions suivantes :

Action	Descriptif
paiement	Procédez à l'extraction du référentiel sur un exécuteur, un agent Actions GitHub.
setup-python	Installez Python sur l’exécuteur.
appservice-build	Créez l’application web.
webapps-deploy	Déployez l’application web en utilisant les identifiants du profil de publication pour vous authentifier dans Azure. Les informations d’identification sont stockées dans un secret GitHub.

Le modèle de flux de travail utilisé pour créer le flux de travail est Azure/actions-workflow-samples.

Le workflow est déclenché sur les événements événements d’envoi (push) vers la branche spécifiée. L’événement et la branche sont définis au début du fichier de flux de travail. Par exemple, l’extrait de code suivant montre que le flux de travail est déclenché sur les événements Push vers la branche principale :

on:
  push:
    branches:
    - main

Applications autorisées OAuth

Lorsque vous configurez un déploiement continu, vous autorisez Azure App Service en tant qu’application OAuth autorisée pour votre compte GitHub. App Service utilise l’accès autorisé pour créer un fichier YAML GitHub Action au chemin .github/workflows/workflow-name.yml dans votre dépôt.

Pour afficher vos applications autorisées et révoquer des autorisations sous vos comptes GitHub, accédez à Paramètres>Integrations/Applications :

Capture d’écran montrant comment afficher les applications OAuth autorisées pour un compte GitHub.

Secret de profil de publication de workflow

Dans le fichier de flux de travail .github/workflows/<workflow-name>.yml ajouté à votre dépôt, il existe un espace réservé pour publier les informations d’identification du profil requises pour le travail de déploiement du flux de travail. Les informations de profil de publication sont stockées chiffrées dans le référentiel.

Pour afficher le secret, accédez à Paramètres> Secretsde sécurité>et actions des variables> :

Capture d’écran montrant comment afficher les secrets d’action d’un référentiel dans GitHub.

Dans cet article, l’action GitHub s’authentifie avec des identifiants de profil de publication. Il existe d’autres façons de s’authentifier, par exemple avec un principal de service ou OpenID Connect. Pour plus d’informations, consultez Déployer sur App Service à l’aide de GitHub Actions.

Exécuter et tester le flux de travail

La dernière étape consiste à tester le flux de travail en apportant une modification au dépôt.

Dans un navigateur, accédez à votre fourche du référentiel d’exemples (ou le référentiel que vous avez utilisé), puis sélectionnez la branche que vous avez définie dans le cadre du déclencheur :
Apportez une petite modification à votre application web Python.

Pour le didacticiel Flask, voici un simple changement :
1. Accédez au fichier /hello-app/templates/home.html de la branche de déclencheur.
2. Sélectionnez Modifier (crayon).
3. Dans l’Éditeur, recherchez l’instruction print <p> et ajoutez le texte « Redéployé ! »
Validez la modification directement dans la branche dans laquelle vous travaillez.
1. Dans l’Éditeur, sélectionnez Valider les modifications en haut à droite. La fenêtre Valider les modifications s’ouvre.
2. Dans la fenêtre Valider les modifications , modifiez le message de validation comme vous le souhaitez, puis sélectionnez Valider les modifications.
Le processus de validation déclenche le flux de travail GitHub Actions.

Vous pouvez également déclencher le flux de travail manuellement :

Accédez à l’onglet Actions du référentiel configuré pour le déploiement continu.
Sélectionnez le flux de travail dans la liste des flux de travail, puis sélectionnez Exécuter le flux de travail.

Résolution des problèmes liés aux workflows ayant échoué

Vous pouvez vérifier l’état d’un flux de travail sous l’onglet Actions du dépôt d’application. Lorsque vous examinez le fichier de flux de travail créé dans cet article, vous voyez deux travaux : générer et déployer. En guise de rappel, le flux de travail est basé sur le modèle Azure/actions-workflow-samples .

Pour un travail ayant échoué, examinez la sortie des tâches de travail afin d'obtenir une indication de la défaillance.

Voici quelques problèmes courants à examiner :

Si l’application échoue en raison d’une dépendance manquante, votre fichier requirements.txt n’a pas été traité pendant le déploiement. Ce comportement se produit si vous avez créé l’application web directement sur le portail plutôt qu’à l’aide de la az webapp up commande, comme indiqué dans cet article.
Si vous avez mis en service le service d’application via le portail, le paramètre d’action de génération SCM_DO_BUILD_DURING_DEPLOYMENT peut ne pas être défini. Ce paramètre doit être défini sur true. La az webapp up commande définit automatiquement l’action de génération.
Si vous voyez un message d’erreur concernant le délai d’expiration de la négociation TLS, exécutez le workflow manuellement en sélectionnant Déclencher le déploiement automatique sous l’onglet Actions du référentiel d’application. Vous pouvez déterminer si le délai d’expiration est un problème temporaire.
Si vous configurez le déploiement continu pour l’application conteneur comme indiqué dans cet article, le fichier de flux de travail initial .github/workflows/<workflow-name>.yml est créé automatiquement pour vous. Si vous avez modifié le fichier, supprimez les modifications pour voir s’ils provoquent l’échec.

Exécuter un script post-déploiement

Un script post-déploiement peut effectuer plusieurs tâches, telles que la définition de variables d’environnement attendues par le code de l’application. Vous ajoutez le script dans le cadre du code de l’application et exécutez le script à l’aide de la commande de démarrage.

Pour éviter les valeurs de variables codées en dur dans votre fichier YAML de flux de travail, envisagez de configurer les variables dans GitHub et de faire référence aux noms des variables dans le script. Vous pouvez créer des secrets chiffrés pour un référentiel ou pour un environnement (référentiel de comptes). Pour plus d’informations, consultez Utilisation des secrets dans GitHub Actions.

Examiner les considérations relatives à Django

Comme indiqué précédemment dans cet article, vous pouvez utiliser GitHub Actions pour déployer des applications Django sur Azure App Service sur Linux, si vous utilisez une base de données distincte. Vous ne pouvez pas utiliser une base de données SQLite, car App Service verrouille le fichier db.sqlite3 , ce qui empêche les lectures et les écritures. Ce comportement n’affecte pas une base de données externe.

L’article Configurer l’application Python sur App Service - Processus de démarrage de conteneur décrit comment App Service recherche automatiquement un fichier wsgi.py dans le code de votre application, qui contient généralement l’objet d’application. Lorsque vous avez utilisé la webapp config set commande pour définir la commande de démarrage, vous avez utilisé le --startup-file paramètre pour spécifier le fichier qui contient l’objet d’application. La webapp config set commande n’est pas disponible dans l’action webapps-deploy. Au lieu de cela, vous pouvez utiliser le startup-command paramètre pour spécifier la commande de démarrage. Par exemple, le code suivant montre comment spécifier la commande de démarrage dans le fichier de flux de travail :

startup-command: startup.txt

Lorsque vous utilisez Django, vous souhaitez généralement migrer les modèles de données à l’aide de la python manage.py migrate commande après avoir déployé le code de l’application. Vous pouvez exécuter la commande migrate dans un script post-déploiement.

Déconnecter GitHub Actions

La déconnexion de GitHub Actions de votre instance App Service vous permet de reconfigurer le déploiement de l’application. Vous pouvez choisir ce qui se passe dans votre fichier de flux de travail après vous être déconnecté, et si vous souhaitez enregistrer ou supprimer le fichier.

Azure CLI
portail Azure

Déconnectez GitHub Actions avec la commande azure CLI az webapp deployment github-actions remove suivante. Remplacez les espaces réservés par vos valeurs spécifiques :

az webapp deployment github-actions remove \
  --repo "<github-username>/<github-repo>" \
  --resource-group <resource-group-name> \
  --branch <branch-name> \
  --name <app-service-name> \
  --login-with-github

Nettoyer les ressources

Pour éviter les frais liés aux ressources Azure créées dans cet article, supprimez le groupe de ressources qui contient l’instance App Service et le plan App Service.

Azure CLI
portail Azure

N’importe où l’interface de ligne de commande Azure est installée, y compris Azure Cloud Shell, vous pouvez utiliser la commande az group delete pour supprimer un groupe de ressources :

az group delete --name <resource-group-name>

Supprimer le compte de stockage

Pour supprimer le compte de stockage qui gère le système de fichiers pour Cloud Shell, ce qui entraîne une petite charge mensuelle, supprimez le groupe de ressources qui commence par cloud-shell-storage-. Si vous êtes le seul utilisateur du groupe, il est sûr de supprimer le groupe de ressources. S’il existe d’autres utilisateurs, vous pouvez supprimer un compte de stockage dans le groupe de ressources.

Mettre à jour le compte et le dépôt GitHub

Si vous supprimez le groupe de ressources Azure, envisagez d’apporter les modifications suivantes au compte GitHub et au référentiel connectés pour le déploiement continu :

Dans le référentiel d’applications, supprimez le fichier .github/workflows/<workflow-name>.yml .
Dans les paramètres du référentiel d’applications, supprimez la clé secrète AZUREAPPSERVICE_PUBLISHPROFILE_ créée pour le flux de travail.
Dans les paramètres du compte GitHub, supprimez Azure App Service en tant qu’application Oauth autorisée pour votre compte GitHub.

Rétroaction

Cette page vous a-t-elle été utile ?

Last updated on 2025-06-27