Utiliser CI/CD avec GitHub Actions pour déployer une application web Python sur Azure App Service sur Linux

  • Article

Utilisez la plateforme d’intégration continue GitHub Actions et de livraison continue (CI/CD) 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 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 case activée de sécurité et un déploiement multistages.

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

Si vous avez déjà une application web Python à utiliser, assurez-vous qu’elle est validée dans un référentiel GitHub.

Si vous avez besoin de travailler avec une application, vous pouvez dupliquer et cloner le référentiel à l’adresse https://github.com/Microsoft/python-sample-vscode-flask-tutorial. Le code provient du tutoriel Flask dans Visual Studio Code.

Remarque

Si votre application utilise Django et une base de données SQLite, elle ne fonctionnera pas pour ce didacticiel. Si votre application Django utilise une base de données distincte comme PostgreSQL, vous pouvez l’utiliser avec ce tutoriel. Pour plus d’informations sur Django, consultez les considérations relatives à Django plus loin dans cet article.

Créer la cible Azure App Service

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 les étapes suivantes, vous allez utiliser az webapp jusqu’à créer App Service et effectuer le premier déploiement de votre application.

Étape 1. Connectez-vous au portail Azure à l’adressehttps://portal.azure.com.

Étape 2. Ouvrez Azure CLI en sélectionnant l’icône Cloud Shell dans la barre d’outils du portail.

Screenshot showing how to open Azure Cloud Shell in Azure portal.

Étape 3. Dans Cloud Shell, sélectionnez Bash dans la liste déroulante.

Screenshot showing an Azure Cloud Shell Bash shell in Azure portal.

Étape 4. Dans Cloud Shell, clonez votre dépôt à l’aide du clone Git. Par exemple, si vous utilisez l’exemple d’application Flask, la commande est la suivante :

git clone https://github.com/<github-user>/python-sample-vscode-flask-tutorial.git

Remplacez <github-user> par le nom du compte GitHub où vous avez dépliqué le dépôt. Si vous utilisez un autre dépôt d’application, ce dépôt est l’endroit où vous allez configurer GitHub Actions.

Remarque

Le Cloud Shell est soutenu par un compte de stockage Azure dans un groupe de ressources appelé cloud-shell-storage-<your-region>. Ce compte de stockage contient une image du système de fichiers du Cloud Shell, qui stocke le référentiel cloné. Ce stockage entraîne un petit coût. Vous pouvez supprimer le compte de stockage à la fin de cet article, ainsi que d’autres ressources que vous créez.

Conseil

Pour coller dans le Cloud Shell, utilisez Ctrl+Maj+V ou cliquez avec le bouton droit et sélectionnez Coller dans le menu contextuel.

Étape 5. Dans Cloud Shell, remplacez le répertoire dans le dossier de référentiel qui possède votre application Python afin que la commande az webapp up reconnaisse l’application en tant que Python. Pour l’exemple d’application Flask :

cd python-sample-vscode-flask-tutorial

Étape 6. Dans Cloud Shell, utilisez az webapp up pour créer un App Service et déployer initialement votre application.

az webapp up --name <app-service-name> --runtime "PYTHON:3.9"

Spécifiez un nom 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.

Permet az webapp list-runtimes d’obtenir la liste des runtimes disponibles. Utilisez le PYTHON|X.Y format, où X.Y se trouve la version de Python.

Vous pouvez également spécifier l’emplacement de l’App Service avec le --location paramètre. Utilisez la az account list-locations --output table commande pour obtenir la liste des emplacements disponibles.

Étape 7. Si votre application utilise une commande de démarrage personnalisée, utilisez la configuration az webapp à l’aide de cette commande. Si votre application n’a pas de commande de démarrage personnalisée, ignorez cette étape.

Par exemple, l’application python-sample-vscode-flask-tutorial contient un fichier nommé startup.txt qui contient une commande de démarrage que vous pouvez utiliser comme suit :

az webapp config set \
  --resource-group <resource-group-name> \
  --name <app-service-name> \
  --startup-file startup.txt

Vous trouverez le nom du groupe de ressources à partir de la sortie de la commande précédente az webapp up . Le nom du groupe de ressources commence par <azure-account-name>_rg_.

Étape 8 : Pour afficher l’application en cours d’exécution, ouvrez un navigateur et accédez à http:// app-service-name.azurewebsites.net><.

Si vous voyez une page générique, attendez quelques secondes que le App Service démarre, puis actualisez la page. Si vous continuez à voir la page générique, case activée que vous avez déployée à partir du dossier approprié. Par exemple, si vous utilisez l’exemple d’application Flask, le dossier est python-sample-vscode-flask-tutorial. En outre, pour l’exemple d’application Flask, case activée que vous définissez correctement la commande de démarrage.

Configurer le déploiement continu dans App Service

Dans les étapes ci-dessous, vous allez configurer le déploiement continu (CD), ce qui signifie qu’un nouveau déploiement de code se produit lorsqu’un flux de travail est déclenché. Le déclencheur de ce didacticiel est toute modification apportée à la branche principale de votre référentiel, par exemple avec une demande de tirage (PULL Request).

Étape 1. Ajoutez GitHub Action avec la commande az webapp deployment github-actions add .

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 invites pour terminer l’authentification.

S’il existe un fichier de flux de travail existant qui est en conflit avec le nom qu’App Service utilise, vous êtes invité à choisir s’il faut remplacer. Utilisez le --force paramètre pour remplacer sans demander.

Que fait la commande add :

  • Crée un fichier de flux de travail : .github/workflows/<workflow-name.yml> dans votre dépôt ; le nom du fichier contiendra le nom de votre App Service.
  • Récupère un profil de publication avec des secrets pour votre 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.

Étape 2. Obtenez les détails d’une configuration de déploiement de contrôle de code source avec la commande az webapp deployment source show .

az webapp deployment source show \
  --name <app-service-name> \
  --resource-group <resource-group-name>

Dans la sortie de la commande, confirmez les valeurs pour les propriétés et branch les repoUrl propriétés. Ces valeurs doivent correspondre aux valeurs que vous avez spécifiées à l’étape précédente.

Flux de travail et actions GitHub expliqués

Un flux de travail est défini par 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. Chaque travail à son tour est un ensemble d’étapes. Enfin, chaque étape est un script shell ou une action.

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

Action Description
case activée out Consultez le référentiel sur un exécuteur, un agent GitHub Actions.
setup-python Installez Python sur l’exécuteur.
appservice-build Créez l’application web.
webapps-deploy Déployez l’application web à l’aide d’informations d’identification de profil de publication pour l’authentification 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 flux de travail est déclenché sur les événements 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 que Application OAuth autorisé pour votre compte GitHub. App Service utilise l’accès autorisé pour créer un fichier YML d’action GitHub dans .github/workflows/<workflow-name.yml>. Vous pouvez voir vos applications autorisées et révoquer des autorisations sous vos comptes GitHub Paramètres, sous Integrations/Applications.

Screenshot showing how to view authorized OAuth Apps for a GitHub account.

Secret du profil de publication de flux de travail

Dans le fichier de flux de travail .github/workflows/<workflow-name.yml> ajouté au dépôt, vous verrez un espace réservé pour publier les informations d’identification du profil nécessaires au travail de déploiement du flux de travail. Les informations de profil de publication sont stockées chiffrées dans le référentiel Paramètres, sous Sécurité/Actions.

Screenshot showing how to view action secrets in GitHub.

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

Exécuter le workflow

Vous allez maintenant tester le flux de travail en apportant une modification au dépôt.

Étape 1. Accédez à votre fourche de l’exemple de référentiel (ou le référentiel que vous avez utilisé) et sélectionnez la branche que vous avez définie dans le cadre du déclencheur.

Screenshot showing how to go to the repo and branch where the GitHub Actions workflow is defined.

Étape 2. Apportez une petite modification.

Par exemple, si vous avez utilisé le didacticiel VS Code Flask, vous pouvez

  • Accédez au fichier /hello-app/templates/home.html de la branche de déclencheur.
  • Sélectionnez Modifier et ajoutez le texte « Redéployé ! ».

Étape 3. Validez la modification directement sur la branche dans laquelle vous travaillez.

  • En haut à droite de la page que vous modifiez, sélectionnez le bouton Valider les modifications ... La fenêtre Valider les modifications s’ouvre. Dans la fenêtre Valider les modifications , modifiez le message de validation si vous le souhaitez, puis sélectionnez le bouton Valider les modifications .
  • La validation lance le flux de travail GitHub Actions.

Vous pouvez également lancer le flux de travail manuellement.

Étape 1. Accédez à l’onglet Actions du référentiel configuré pour le déploiement continu.

Étape 2. 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 d’un flux de travail ayant échoué

Pour case activée l’état d’un flux de travail, accédez à l’onglet Actions du référentiel. Lorsque vous explorez le fichier de flux de travail créé dans ce didacticiel, vous verrez deux travaux « générer » et « déployer ». Pour un travail ayant échoué, examinez la sortie des tâches de travail pour une indication de l’échec. Voici certains problèmes courants :

  • 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’en utilisant la commande az webapp up comme indiqué dans cet article.

  • Si vous avez provisionné le service d’application via le portail, l’action de génération SCM_DO_BUILD_DURING_DEPLOYMENT paramètre n’a peut-être pas été définie. 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 avec « Délai d’expiration de la négociation TLS », exécutez le flux de travail manuellement en sélectionnant Déclencher le déploiement automatique sous l’onglet Actions du référentiel pour voir 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 ce didacticiel, le fichier de flux de travail (.github/workflows/<workflow-name.yml>) est créé automatiquement pour vous. Si vous l’avez modifié, supprimez les modifications pour voir si elles provoquent l’échec.

Exécuter un script post-déploiement

Un script de post-déploiement peut, par exemple, définir des variables d’environnement attendues par le code de l’application. Ajoutez le script dans le code de l’application et exécutez-le à l’aide de la commande de démarrage.

Pour éviter les valeurs de variables codées en dur dans votre fichier YML de flux de travail, vous pouvez les utiliser dans l’interface web GitHub, puis faire référence au nom de la variable 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 Secrets chiffrés dans GitHub Docs.

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, empêchant les lectures et les écritures. Ce comportement n’affecte pas une base de données externe.

Comme décrit dans l’article Configurer l’application Python sur App Service - Processus de démarrage du conteneur, App Service recherche automatiquement un fichier wsgi.py dans votre code d’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, l’extrait de 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 python manage.py migrate de la commande après le déploiement du 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 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é, qu’il s’agisse d’enregistrer ou de supprimer le fichier.

Déconnectez GitHub Actions avec Azure CLI az webapp deployment github-actions remove command.

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

Nettoyer les ressources

Pour éviter d’entraîner des frais sur les ressources Azure créées dans ce tutoriel, supprimez le groupe de ressources qui contient le App Service et le plan App Service.

Partout où Azure CLI est installé, y compris Azure Cloud Shell, vous pouvez utiliser la commande az group delete pour supprimer le groupe de ressources.

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

Pour supprimer le compte de stockage qui gère le système de fichiers pour Cloud Shell, ce qui entraîne des frais mensuels réduits, 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.

Si vous avez supprimé le groupe de ressources Azure, envisagez également 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, supprimez le fichier .github/workflows/<workflow-name.yml>.
  • Dans les paramètres du référentiel, 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.