Tutoriel : Configurer un déploiement continu pour une application web Python dans Azure Container Apps

Cet article fait partie d’une série de tutoriels sur la façon de conteneuriser et de déployer une application web Python sur Azure Container Apps. Container Apps vous permet de déployer des applications conteneurisées sans avoir à gérer une infrastructure complexe.

Dans ce tutoriel, vous allez :

• Configurez le déploiement continu pour une application conteneur à l’aide d’un flux de travail GitHub Actions .
• Apportez une modification à une copie de l’exemple de référentiel pour déclencher le flux de travail GitHub Actions.
• Résolvez les problèmes que vous pouvez rencontrer lors de la configuration du déploiement continu.
• Supprimez les ressources dont vous n’avez pas besoin lorsque vous terminez la série de tutoriels.

Le déploiement continu est lié à la pratique DevOps de l’intégration continue et de la livraison continue (CI/CD), qui est l’automatisation de votre flux de travail de développement d’applications.

Le diagramme suivant met en évidence les tâches de ce didacticiel.

Prérequis

Pour configurer le déploiement continu, vous avez besoin de :

• Les ressources (et leur configuration) que vous avez créées dans le didacticiel précédent, qui inclut une instance de Azure Container Registry et une application conteneur dans Azure Container Apps.

• Un compte GitHub dans lequel vous avez dépliqué l’exemple de code (Django ou Flask) et auquel vous pouvez vous connecter à partir d’Azure Container Apps. (Si vous avez téléchargé l’exemple de code au lieu de la duplication, veillez à envoyer (push) votre dépôt local à votre compte GitHub.)

• En option, Git installé dans votre environnement de développement pour effectuer des modifications de code et les pousser vers votre référentiel dans GitHub. Sinon, vous pouvez apporter les modifications directement dans GitHub.

Configurer le déploiement continu pour un conteneur

Dans le tutoriel précédent, vous avez créé et configuré une application conteneur dans Azure Container Apps. Une partie de la configuration extrayait une image Docker à partir d’une instance Azure Container Registry. L’image conteneur est extraite du Registre lorsque vous créez un conteneur révision, par exemple lorsque vous configurez l’application conteneur pour la première fois.

Dans cette section, vous allez configurer un déploiement continu à l’aide d’un flux de travail GitHub Actions. Avec le déploiement continu, une nouvelle image Docker et une révision du conteneur sont créées en fonction d’un déclencheur. Le déclencheur de ce didacticiel est toute modification apportée à la branche principale de votre référentiel, comme une pull request. Lorsque le flux de travail est déclenché, il crée une image Docker, l’envoie (push) à l’instance Azure Container Registry et met à jour l’application conteneur à une nouvelle révision à l’aide de la nouvelle image.

Azure CLI

Vous pouvez exécuter des commandes Azure CLI dans Azure Cloud Shell ou sur une station de travail où azure CLI est installé.

Si vous exécutez des commandes dans un shell Git Bash sur un ordinateur Windows, saisissez la commande suivante avant de continuer :

export MSYS_NO_PATHCONV=1

1. Créez un principal de service en utilisant la commande az ad sp create-for-rbac :

   az ad sp create-for-rbac \
   --name <app-name> \
   --role Contributor \
   --scopes "/subscriptions/<subscription-ID>/resourceGroups/<resource-group-name>"
   

   Dans la commande :

   • <app-name> est un nom d'affichage facultatif pour le principal de service. Si vous omettez l’option --name, un GUID est généré en tant que nom d’affichage.
   • <ID d’abonnement> est le GUID qui identifie de manière unique votre abonnement dans Azure. Si vous ne connaissez pas votre ID d'abonnement, vous pouvez exécuter la commande az account show et le copier à partir de la propriété id dans la sortie.
   • <resource-group-name> est le nom d’un groupe de ressources qui contient le conteneur d’Azure Container Apps. Le contrôle d’accès basé sur les rôles (RBAC) se fait au niveau du groupe de ressources. Si vous avez suivi les étapes décrites dans le didacticiel précédent, le nom du groupe de ressources est pythoncontainer-rg.

   Enregistrez la sortie de cette commande pour l’étape suivante. En particulier, enregistrez l’ID client (propriétéappId), la clé secrète client (propriétépassword) et l’ID de locataire (propriététenant).

2. Configurez GitHub Actions à l’aide de la commande az containerapp github-action add :

   az containerapp github-action add \
   --resource-group <resource-group-name> \
   --name python-container-app \
   --repo-url <https://github.com/userid/repo> \
   --branch main \
   --registry-url <registry-name>.azurecr.io \
   --service-principal-client-id <client-id> \
   --service-principal-tenant-id <tenant-id> \
   --service-principal-client-secret <client-secret> \
   --login-with-github
   

   Dans la commande :

   • <resource-group-name> est le nom du groupe de ressources. Dans ce tutoriel, il s’agit de pythoncontainer-rg.
   • <https://github.com/userid/repo> est l’URL de votre référentiel GitHub. Dans ce tutoriel, il s’agit de https://github.com/userid/msdocs-python-django-azure-container-apps ou de https://github.com/userid/msdocs-python-flask-azure-container-apps. Dans ces URL, userid est votre ID d’utilisateur GitHub.
   • <nom du registre> est l’instance Azure Container Registry existante que vous avez créée dans le didacticiel précédent, ou une instance que vous pouvez utiliser.
   • <client-id> est la valeur de la propriété appId de la commande az ad sp create-for-rbac précédente. L’ID est un GUID sous la forme de 00000000-0000-0000-0000-00000000.
   • <"id de locataire"> correspond à la valeur de la propriété tenant issue de la commande précédente az ad sp create-for-rbac. L’ID est également un GUID similaire à l’ID client.
   • <client-secret> est la valeur de la propriété password de la commande précédente az ad sp create-for-rbac.

Portail Azure

1. Dans le portail Azure , accédez à l’application conteneur pour laquelle vous souhaitez configurer le déploiement continu. Dans le menu du service, sélectionnez Déploiement continu.

   

2. Autoriser Azure Container Apps à accéder à votre compte GitHub :

   1. Sélectionnez Se connecter avec GitHub.
   2. Dans la boîte de dialogue d’autorisation, sélectionnez Autoriser azureAppService.

   

   Conseil

   Vous pouvez révoquer l’accès Container Apps au compte GitHub à partir de la section de sécurité de votre compte.

3. Configurez les détails du déploiement continu :

   • Organisation: utilisez votre nom d’utilisateur GitHub.
   • Référentiel (Repository) : sélectionnez le fork de l’application d’exemple. (Si vous avez initialement téléchargé le code d’exemple dans votre environnement de développement, poussez le référentiel sur GitHub.)
   • Branche : sélectionnez main.
   • Source du référentiel: Sélectionnez Azure Container Registry.
   • Registry: sélectionnez l’instance Azure Container Registry que vous avez créée dans le didacticiel précédent.
   • image: sélectionnez le nom de l’image Docker. Dans ce tutoriel, c’est python-container-app.
   • Principal de service : Laissez Créer nouveau (Create new) et laissez le processus de création générer un nouveau principal de service.

   Sélectionnez Démarrer le déploiement continu (Start continuous deployment) pour finaliser la configuration.

   

4. Passez en revue les informations relatives au déploiement continu.

   Les informations incluent un lien vers le fichier de flux de travail GitHub Actions créé. Azure Container Apps a enregistré le fichier dans votre référentiel.

   

Dans la configuration du déploiement continu, un principal de service permet à GitHub Actions d’accéder aux ressources Azure et de les modifier. Les rôles attribués au principal de service limitent l’accès aux ressources. Le principal de service s’est vu attribuer le rôle intégré Contributeur sur le groupe de ressources qui contient l’application conteneur.

Si vous avez suivi les étapes pour le portail, le principal de service a été automatiquement créé pour vous. Si vous avez suivi les étapes pour Azure CLI, vous avez créé explicitement le principal de service avant de configurer le déploiement continu.

Redéployer l’application web avec GitHub Actions

Dans cette section, vous apportez une modification à votre copie forkée (dupliquée) du référentiel d’exemple. Après cela, vous pouvez confirmer que la modification est automatiquement déployée sur le site web.

Si vous ne l'avez pas encore fait, créez une fourche du référentiel d'exemples (Django ou Flask). Vous pouvez modifier votre code directement dans GitHub ou dans votre environnement de développement via une ligne de commande avec Git.

GitHub

1. Allez dans votre fourche du référentiel d'exemples et commencez dans la branche principale.

   

2. Apportez une modification :

   1. Rendez-vous dans le fichier /templates/base.html. (Pour Django, le chemin est restaurant_review/templates/restaurant_review/base.html.)
   2. Sélectionnez Modifier et remplacez l’expression Azure Restaurant Review par Azure Restaurant Review - Redeployed.

   

3. En bas de la page que vous modifiez, assurez-vous que Valider directement sur la branche principale (Commit directly to the main branch) est sélectionné. Ensuite, sélectionnez le bouton Valider les modifications (Commit changes).

   

Le commit déclenche le flux de travail GitHub Actions.

Ligne de commande

Si vous ne l'avez pas encore fait, utilisez git clone pour tirer votre référentiel forké vers votre environnement de développement et changez de répertoire vers le référentiel. Effectuez ensuite les étapes suivantes :

1. Commencez dans main :

   git checkout main
   git pull
   

2. Apportez la modification souhaitée.

   Accédez au fichier ./templates/base.html (./restaurant_review/templates/restaurant_review/base.html pour Django) et modifiez l’expression Azure Restaurant Review en Azure Restaurant Review - Redeployed.

3. Validez et envoyez (push) la modification à GitHub :

   git commit -a -m "Redeploy with title change."
   git push
   

La première fois que vous utilisez Git, vous devrez peut-être définir les variables globales user.name et user.email. Pour plus d’informations, consultez l’aide pour git-config.

L’envoi de modifications à la branche principale démarre le flux de travail des GitHub Actions.

Remarque

Ce tutoriel montre comment apporter une modification directement dans la branche principale. Dans les flux de travail logiciels classiques, vous apportez une modification dans une branche autre que la branche principale, puis créez une pull request pour fusionner la modification dans la branche principale. Les pull requests lancent également le processus de travail.

Comprendre GitHub Actions

Affichage de l’historique du flux de travail

Si vous devez afficher l’historique des flux de travail, utilisez l’une des procédures suivantes.

GitHub

Sur GitHub, accédez à votre fork du dépôt d'exemple et ouvrez l'onglet Actions.

Ligne de commande

Ces étapes utilisent la ligne de commande GitHub .

1. Obtenez un résumé de votre flux de travail. Exécutez la commande suivante dans le dossier contenant votre clone :

   gh workflow view
   

   Cette commande vous invite à sélectionner un flux de travail, puis fournit un aperçu des exécutions récentes de ce flux.

   Remarque

   La première fois que vous utilisez gh, vous pouvez être invité à vous authentifier. Suivez les invites de l’interface de ligne de commande (CLI) GitHub pour vous authentifier.

   Si vous avez configuré plus d’un référentiel distant, il se peut qu’on vous demande d’exécuter gh repo set-default pour sélectionner un référentiel distant par défaut. Sélectionnez votre fourche dans les options présentées.

   Vous pouvez exécuter la commande gh workflow view depuis n’importe quel dossier sans avoir à définir un référentiel par défaut en ajoutant le paramètre --repo [HOST/]OWNER/REPO.

2. Accédez à GitHub pour plus d’informations sur une exécution de flux de travail :

   gh workflow view --web
   

Secrets de flux de travail

Le fichier de flux de travail .github/workflows/<workflow-name>.yml qui a été ajouté au référentiel comprend des espaces réservés pour les informations d’identification nécessaires aux tâches de build et de mise à jour de l’application conteneur du flux de travail. Les informations d’identification sont chiffrées et stockées dans la zone Paramètres du référentiel , sous Sécurité Secrets et variablesActions.

Si les informations d’identification changent, vous pouvez les mettre à jour ici. Par exemple, si les mots de passe Azure Container Registry sont régénérés, vous devez mettre à jour la valeur REGISTRY_PASSWORD. Pour plus d’informations, consultez Les Secrets chiffrés dans la documentation GitHub.

Applications autorisées OAuth

Lorsque vous configurez un déploiement continu, vous désignez Azure Container Apps en tant qu’application OAuth autorisée pour votre compte GitHub. Container Apps utilise l’accès autorisé pour créer un fichier YAML GitHub Actions dans .github/workflows/<nom de flux de travail>.yml. Vous pouvez afficher vos applications autorisées et révoquer des autorisations dans votre compte, sous Integrations>Applications.

Dépanner

Vous obtenez des erreurs lors de la configuration d’un principal de service via Azure CLI

Cette section peut vous aider à résoudre les erreurs que vous obtenez lors de la configuration d’un principal de service à l’aide de la commande Azure CLI az ad sp create-for-rba.

Si vous obtenez une erreur qui contient « InvalidSchema: Aucun adaptateur de connexion n’a été trouvé » :

• Vérifiez le shell dans lequel vous travaillez. Si vous utilisez un interpréteur de commandes Bash, définissez les variables MSYS_NO_PATHCONV comme export MSYS_NO_PATHCONV=1.

  Pour plus d’informations, consultez le problème GitHub Impossible de créer un principal de service avec Azure CLI à partir de l’interpréteur de commandes Git Bash.

Si vous obtenez une erreur qui contient « Plusieurs applications ont le même nom d’affichage » :

• Le nom est déjà attribué pour le principal de service. Choisissez un autre nom ou quittez l’argument --name. Un GUID sera généré automatiquement comme nom d’affichage.

Échec du flux de travail GitHub Actions

Pour vérifier l’état d’un flux de travail, accédez à l’onglet Actions du référentiel :

• En cas d’échec du flux de travail, explorez le fichier de flux de travail. Il doit y avoir deux tâches : construire et déployer. Pour un job ayant échoué, vérifiez la sortie des tâches du job afin de détecter d’éventuels problèmes.
• Si un message d’erreur contient « TLS handshake timeout », exécutez le flux de travail manuellement. Dans le référentiel, dans l’onglet Actions, sélectionnez Déclencher le déploiement automatique (Trigger auto deployment) pour vérifier si le délai d’expiration est un problème temporaire.
• Si vous avez configuré le déploiement continu pour l’application conteneur comme indiqué dans ce tutoriel, le fichier de flux de travail (.github/workflows/<workflow-name>.yml) est créé automatiquement pour vous. Vous ne devriez pas avoir besoin de modifier ce fichier pour ce tutoriel. Si vous l’avez fait, annulez vos modifications et réessayez le flux de travail.

Le site web n’affiche pas les modifications que vous avez fusionnées dans la branche principale

Dans GitHub :

• Vérifiez que le flux de travail GitHub Actions s’est exécuté et que vous avez vérifié la modification dans la branche qui déclenche le flux de travail.

Dans le portail Azure :

• Vérifiez l’instance Azure Container Registry pour voir si une nouvelle image Docker a été créée avec un horodatage après votre modification de la branche.

• Vérifiez les journaux d’activité de l’application conteneur pour voir s’il existe une erreur de programmation :

  1. Accédez à l’application conteneur, puis accédez à Gestion des révisions><Conteneur actif>>Détails de révision>Journaux de la console.
  2. Choisissez l’ordre des colonnes pour afficher Heure générée (Time Generated), Flux_s (Stream_s) et Journal_s (Log_s).
  3. Triez les logs par les plus récents et recherchez les messages Python stderr et stdout dans la colonne Stream_s. La sortie Python print correspond aux messages stdout.

Dans Azure CLI :

• Utilisez la commande az containerapp logs show.

Vous souhaitez arrêter le déploiement continu

Arrêter le déploiement continu signifie déconnecter votre application conteneur de votre référentiel.

Dans le portail Azure :

• Accédez à l’application conteneur. Dans le menu du service, sélectionnez Déploiement continu, puis sélectionnez Déconnecter.

Dans Azure CLI :

• Utilisez la commande az container app github-action remove.

Après la déconnexion :

• Le fichier .github/workflows/<workflow-name>.yml est supprimé de votre référentiel.
• Les clés secrètes ne sont pas supprimées du dépôt.
• Azure Container Apps reste en tant qu’application OAuth autorisée pour votre compte GitHub.
• Dans Azure, le conteneur est laissé avec le dernier conteneur déployé. Vous pouvez reconnecter l’application conteneur avec l’instance Azure Container Registry afin que les nouvelles révisions de conteneur récupèrent la dernière image.
• Dans Azure, les principaux de service que vous avez créés et utilisés pour le déploiement continu ne sont pas supprimés.

Supprimer des ressources

Si vous avez terminé avec la série de tutoriels et que vous ne souhaitez pas entraîner de coûts supplémentaires, supprimez les ressources que vous avez utilisées.

La suppression d’un groupe de ressources entraîne la suppression de toutes les ressources qu’il contient et constitue le moyen le plus rapide de les supprimer. Pour un exemple de suppression de groupes de ressources, consultez le nettoyage du tutoriel Containerize.

Contenu connexe

Si vous envisagez de créer ce tutoriel, voici quelques étapes suivantes que vous pouvez effectuer :

• Définir des règles de mise à l’échelle dans Azure Container Apps
• Lier les noms de domaine personnalisés et les certificats dans Azure Container Apps
• Superviser une application dans Azure Container Apps