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

Cet article fait partie d’un tutoriel 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 gérer une infrastructure complexe.

Dans cette partie du tutoriel, vous allez apprendre à configurer le déploiement continu ou la livraison (CD) pour l’application conteneur. CD fait partie de la pratique DevOps de l’intégration continue /livraison continue (CI/CD), qui est l’automatisation de votre flux de travail de développement d’applications. Plus précisément, vous utilisez GitHub Actions pour le déploiement continu.

Ce diagramme de service met en évidence les composants abordés dans cet article : configuration de CI/CD.

Prérequis

Pour configurer le déploiement continu, vous avez besoin des éléments suivants :

• Les ressources et leur configuration créées dans l’article précédent de cette série de tutoriels, qui comprend un Registre de conteneurs Azure 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.)

• Si vous le souhaitez, Git installé dans votre environnement de développement pour apporter des modifications de code et envoyer (push) à votre dépôt dans GitHub. Vous pouvez également apporter les modifications directement dans GitHub.

Configurer le CD pour un conteneur

Dans un article précédent de ce tutoriel, vous avez créé et configuré une application conteneur dans Azure Container Apps. Une partie de la configuration a extrait une image Docker à partir d’un registre de conteneurs Azure. L’image conteneur est extraite du Registre lors de la création d’une révision de conteneur, 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 de 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, par exemple avec une demande de tirage (PULL Request). Lorsqu’il est déclenché, le flux de travail crée une image Docker, l’envoie (push) à Azure Container Registry et met à jour l’application conteneur vers une nouvelle révision à l’aide de la nouvelle image.

Azure CLI

Les commandes Azure CLI peuvent être exécutées dans Azure Cloud Shell ou sur une station de travail dans laquelle l’interface Azure CLI est installée.

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

export MSYS_NO_PATHCONV=1

Étape 1. Créez un principal de service avec 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>"

Où :

• <app-name> est un nom complet facultatif pour le principal de service. Si vous quittez l’option --name , un GUID est généré comme nom d’affichage.
• <subscription-ID> 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 la copier à partir de la propriété dans la id sortie.
• <resource-group-name> est le nom d’un groupe de ressources qui contient le conteneur Azure Container Apps. Le contrôle d’accès en fonction du rôle (RBAC) est au niveau du groupe de ressources. Si vous avez suivi les étapes décrites dans l’article précédent de ce didacticiel, le nom du groupe de ressources est pythoncontainer-rg.

Enregistrez la sortie de cette commande pour l’étape suivante, en particulier l’ID client (appId propriété), le secret client (password propriété) et l’ID de locataire (tenant propriété).

Étape 2. Configurez GitHub Actions avec az containerapp github-action add command.

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

Où :

• <resource-group-name> est le nom du groupe de ressources. Si vous suivez ce tutoriel, il s’agit de « pythoncontainer-rg ».
• <https://github.com/userid/repo> est l’URL de votre dépôt GitHub. Si vous suivez les étapes décrites dans ce tutoriel, il s’agit de l’id https://github.com/userid/msdocs-python-django-azure-container-appshttps://github.com/userid/msdocs-python-flask-azure-container-appsuserid d’utilisateur GitHub.
• <registry-name> est le registre de conteneurs existant que vous avez créé pour ce didacticiel, ou celui que vous pouvez utiliser.
• <client-id> est la valeur de la appId propriété de la commande précédente az ad sp create-for-rbac . L’ID est un GUID de la forme 00000000-0000-0000-0000-0000-000000000.
• <tenant-id> est la valeur de la tenant propriété 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 password propriété de la commande précédente az ad sp create-for-rbac .

Azure portal

Étape 1. Dans le Portail Azure, accédez à l’application conteneur pour laquelle vous souhaitez configurer le déploiement continu et sélectionnez la ressource de déploiement continu.

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

• Sélectionnez Se connecter avec GitHub.
• Dans la fenêtre contextuelle d’autorisation, sélectionnez AuthorizeAppService.

L’accès à l’application conteneur à l’accès GitHub peut être révoqué en accédant à la section de sécurité de votre compte et en révoquant l’accès.

Étape 3. Après la connexion avec GitHub, configurez les détails du déploiement continu.

• L’organisation → utiliser votre nom d’utilisateur GitHub.
• Dépôt → Sélectionner la duplication de l’exemple d’application. (Si vous avez initialement téléchargé l’exemple de code dans votre environnement de développement, envoyez le dépôt à GitHub.)
• Branche → Sélectionner principal.
• Source du référentiel → Sélectionner Azure Container Registry.
• Registry → Sélectionnez Azure Container Registry que vous avez créé précédemment dans le tutoriel.
• Image → Sélectionner le nom de l’image Docker. Si vous suivez le tutoriel, il s’agit de « python-container-app ».
• Le principal de service → laisser créer et laisser le processus de création créer un principal de service.

Sélectionnez Démarrer le déploiement continu pour terminer la configuration.

Étape 4. Passez en revue les informations de déploiement continu.

Une fois le déploiement continu configuré, vous trouverez un lien vers le fichier de flux de travail GitHub Actions créé. Azure Container Apps case activée le fichier dans votre dépôt.

Dans la configuration du déploiement continu, un principal de service est utilisé pour permettre à GitHub Actions d’accéder aux ressources Azure et de les modifier. L’accès aux ressources est limité par les rôles attribués au principal de service. Le principal de service a été affecté au rôle Contributeur intégré sur le groupe de ressources contenant l’application conteneur.

Si vous avez suivi les étapes du portail, le principal de service a été créé automatiquement 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 une application web avec GitHub Actions

Dans cette section, vous apportez une modification à votre copie forked du référentiel d’exemples et vérifiez que la modification est automatiquement déployée sur le site web.

Si ce n’est déjà fait, faites une duplication du dépôt d’exemples (Django ou Flask). Vous pouvez modifier votre code directement dans GitHub ou dans votre environnement de développement à partir d’une ligne de commande avec Git.

GitHub

Étape 1. Accédez à votre fourche du référentiel d’exemples et démarrez dans la branche principale .

Étape 2. Apportez la modification souhaitée.

• Accédez au fichier /templates/base.html . (Pour Django, le chemin est : restaurant_review/templates/restaurant_review/base.html.)
• Sélectionnez Modifier et remplacez l’expression « Azure Restaurant Review » par « Azure Restaurant Review - Redéployé ».

Étape 3. Validez la modification directement dans la branche principale .

• En bas de la page que vous modifiez, sélectionnez le bouton Valider .
• La validation lance le flux de travail GitHub Actions.

Ligne de commande

Si vous ne l’avez pas déjà fait, utilisez cette option git clone pour extraire votre référentiel dupliqué vers votre environnement de développement et modifier le répertoire vers le référentiel.

Étape 1. Commencez en main.

git checkout main
git pull

Étape 2. Apportez la modification souhaitée.

Accédez au fichier ./templates/base.html (./restaurant_review/templates/restaruant_review/base.html pour Django) et remplacez l’expression « Azure Restaurant Review » par « Azure Restaurant Review - Redéployé ».

Étape 3. Validez et transmettez la modification à GitHub.

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

La première fois à l’aide de git, vous devrez peut-être définir des variables globales « user.name » et « user.email ». Pour plus d’informations, consultez l’aide pour git-config.

L’envoi de modifications à la branche principale lance le flux de travail GitHub Actions.

Remarque

Nous avons montré une modification directement dans la branche principale . Dans les flux de travail logiciels classiques, vous allez apporter une modification à une branche autre que principale , puis créer une demande de tirage (PULL) pour fusionner ces modifications dans la branche principale. Les demandes de tirage démarrent également le flux de travail.

Présentation des GitHub Actions

Affichage de l’historique des flux de travail

GitHub

Étape 1. Sur GitHub, accédez à votre duplication du référentiel d’exemples et ouvrez l’onglet Actions .

Ligne de commande

Ces étapes utilisent l’interface CLI GitHub.

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

gh workflow view

Cette commande vous invite à sélectionner un flux de travail, puis donne une vue d’ensemble des exécutions récentes de ce flux de travail.

Remarque

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

Si vous avez plusieurs paramètres distants configurés, vous serez peut-être invité à vous exécuter gh repo set-default pour sélectionner une dépôt distant par défaut. Sélectionnez votre fourche dans les options présentées.

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

Étape 2. Accédez à GitHub pour plus d’informations sur l’exécution du flux de travail.

gh workflow view --web

Secrets de flux de travail

Dans le fichier de flux de travail .github/workflows/<workflow-name>.yml qui a été ajouté au dépôt, vous verrez des espaces réservés pour les informations d’identification nécessaires aux travaux de mise à jour de l’application de build et de conteneur du flux de travail. Les informations d’identification sont stockées chiffrées dans le référentiel Paramètres sous Actions des secrets de sécurité/et des variables./

Si les informations d’identification changent, vous pouvez la 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 Secrets chiffrés dans la documentation GitHub.

Applications autorisées OAuth

Lorsque vous configurez un déploiement continu, vous autorisez Azure Container Apps en tant que Application OAuth autorisé pour votre compte GitHub. Container Apps utilise l’accès autorisé pour créer un fichier YML GitHub Actions dans .github/workflows/<workflow-name>.yml. Vous pouvez voir vos applications autorisées et révoquer des autorisations sous Applications Integrations/ de votre compte.

Conseils de dépannage

Erreurs lors de la configuration d’un principal de service avec la commande Azure CLI az ad sp create-for-rba .

• Vous recevez une erreur contenant « InvalidSchema : Aucune carte de connexion n’a été trouvée ».

  • Vérifiez l’interpréteur de commandes dans lequel vous êtes en cours d’exécution. Si vous utilisez l’interpréteur de commandes Bash, définissez les variables MSYS_NO_PATHCONV comme suit 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 git bash Shell, aucune carte de connexion n’a été trouvée.

• Vous recevez une erreur contenant « Plusieurs applications ont le même nom d’affichage ».

  • Cette erreur indique que le nom est déjà pris pour le principal de service. Choisissez un autre nom ou laissez l’argument --name et un GUID sera généré automatiquement en tant que nom d’affichage.

Échec du flux de travail GitHub Actions.

• Pour case activée 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 son fichier de flux de travail. Il doit y avoir deux travaux « build » et « deploy ». Pour un travail ayant échoué, examinez la sortie des tâches du travail pour rechercher des problèmes.
• 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 un 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. Vous n’avez pas besoin de modifier ce fichier pour ce didacticiel. Si vous l’avez fait, rétablissez vos modifications et essayez le flux de travail.

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

• Dans GitHub : case activée que le flux de travail GitHub Actions s’est exécuté et que vous case activée modifié la modification dans la branche qui déclenche le flux de travail.
• Dans Portail Azure : case activée Azure Container Registry pour voir si une nouvelle image Docker a été créée avec un horodatage après votre modification de la branche.
• Dans Portail Azure : case activée les journaux de l’application conteneur. S’il existe une erreur de programmation, vous le verrez ici.
  • Accéder à l’application conteneur | Gestion des révisions | <conteneur> actif | Détails de révision | Journaux de la console
  • Choisissez l’ordre des colonnes pour afficher « Heure générée », « Stream_s » et « Log_s ». Triez les journaux en premier et recherchez les messages stderr et stdout Python dans la colonne « Stream_s ». La sortie Python « print » sera des messages stdout .
• Avec Azure CLI, utilisez la commande az containerapp logs show .

Que se passe-t-il quand je déconnecte le déploiement continu ?

• L’arrêt du déploiement continu signifie déconnecter votre application conteneur de votre dépôt. Pour vous déconnecter :

  • Dans Portail Azure, accédez à l’application conteneur, sélectionnez la ressource de déploiement continu, sélectionnez Déconnecter.
  • Avec Azure CLI, utilisez la commande az container app github-action remove .

• Après la déconnexion, dans votre dépôt GitHub :

  • Le fichier .github/workflows/<workflow-name>.yml est supprimé de votre dépôt.
  • Les clés secrètes ne sont pas supprimées.
  • Azure Container Apps reste un Application OAuth autorisé pour votre compte GitHub.

• Après la déconnexion, dans Azure :

  • Le conteneur est laissé avec le dernier conteneur déployé. Vous pouvez reconnecter l’application conteneur avec Azure Container Registry afin que les nouvelles révisions de conteneur récupèrent la dernière image.
  • Les principaux de service créés et utilisés pour le déploiement continu ne sont pas supprimés.

Étapes suivantes

Si vous avez terminé avec le didacticiel et que vous ne souhaitez pas entraîner de coûts supplémentaires, supprimez les ressources utilisées. La suppression d’un groupe de ressources supprime toutes les ressources du groupe et constitue le moyen le plus rapide de supprimer des ressources. Pour obtenir un exemple de suppression de groupes de ressources, consultez le didacticiel Containerize propre up.

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

• Définir des règles de mise à l’échelle dans Azure Container Apps

• Lier des noms de domaine et des certificats personnalisés dans Azure Container Apps

• Superviser une application dans Azure Container Apps