Lire en anglais

Partager via

Tutoriel : Déployer une application ASP.NET Core et Azure SQL Database sur Azure App Service

  • Article
Choisir une méthode de déploiement

Dans ce tutoriel, vous allez découvrir comment déployer une application ASP.NET Core pilotée par les données sur Azure App Service, et comment vous connecter à une instance d’Azure SQL Database. Vous allez également déployer un Azure Cache pour Redis pour activer le code de mise en cache dans votre application. Azure App Service est un service d’hébergement web hautement évolutif, appliquant des mises à jour correctives automatiques, qui peut déployer facilement des applications sur Windows ou Linux. Bien que ce tutoriel utilise une application ASP.NET Core 8.0, le processus est le même pour les autres versions d’ASP.NET Core.

Dans ce tutoriel, vous allez apprendre à :

  • Créer une architecture App Service, SQL Database et Cache Redis sécurisée par défaut.
  • Sécuriser les secrets de connexion à l’aide d’une identité managée et de références Key Vault.
  • Déployer un exemple d’application ASP.NET Core sur App Service à partir d’un dépôt GitHub.
  • Accéder aux chaînes de connexion App Service et aux paramètres d’application dans le code de l’application.
  • Effectuer des mises à jour, et redéployer le code de l’application.
  • Générer un schéma de base de données en chargeant un bundle de migration.
  • Diffuser des journaux de diagnostic à partir d’Azure.
  • Gérer l’application dans le portail Azure.
  • Approvisionner la même architecture et la déployer à l’aide d’Azure Developer CLI.
  • Optimiser votre workflow de développement avec GitHub Codespaces et GitHub Copilot.

Prérequis

  • Compte Azure avec un abonnement actif. Si vous ne possédez pas de compte Azure, vous pouvez créer un compte gratuit.
  • Un compte GitHub. Vous pouvez aussi en obtenir un gratuitement.
  • Connaissance du développement ASP.NET Core.
  • (Facultatif) Pour essayer GitHub Copilot, un compte GitHub Copilot. Un essai gratuit de 30 jours est disponible.
  • Compte Azure avec un abonnement actif. Si vous ne possédez pas de compte Azure, vous pouvez créer un compte gratuit.
  • Azure Developer CLI installé. Vous pouvez suivre les étapes avec Azure Cloud Shell, car Azure Developer CLI est déjà installé.
  • Connaissance du développement ASP.NET Core.
  • (Facultatif) Pour essayer GitHub Copilot, un compte GitHub Copilot. Un essai gratuit de 30 jours est disponible.

Passer à la fin

Si vous souhaitez simplement voir l’exemple d’application dans ce tutoriel s’exécutant dans Azure, exécutez simplement les commandes suivantes dans Azure Cloud Shell, puis suivez l’invite :

Bash 
dotnet tool install --global dotnet-ef
mkdir msdocs-app-service-sqldb-dotnetcore
cd msdocs-app-service-sqldb-dotnetcore
azd init --template msdocs-app-service-sqldb-dotnetcore
azd up

1. Exécution de l'exemple

Tout d’abord, vous configurez un exemple d’application pilotée par les données comme point de départ. Pour plus de commodité, l’exemple de référentiel inclut une configuration de conteneur de développement. Le conteneur de développement dispose de tout ce dont vous avez besoin pour développer une application, notamment la base de données, le cache et toutes les variables d’environnement nécessaires par l’exemple d’application. Le conteneur de développement peut s’exécuter dans un codespace GitHub, ce qui signifie que vous pouvez exécuter l’exemple sur n’importe quel ordinateur avec un navigateur web.

Étape 1 : Dans une nouvelle fenêtre de navigateur :

  1. Connectez-vous à votre compte GitHub.
  2. Accédez à https://github.com/Azure-Samples/msdocs-app-service-sqldb-dotnetcore/fork.
  3. Désélectionnez Copier la branche principale uniquement. Vous voulez toutes les branches.
  4. Sélectionnez Créer la duplication.

Capture d’écran montrant comment créer une duplication (fork) du même exemple de dépôt GitHub.

Étape 2 : dans la fourche GitHub :

  1. Sélectionnez principal>starter-no-infra pour la branche de démarrage. Cette branche contient uniquement l’exemple de projet et aucun fichier ou configuration lié à Azure.
  2. Sélectionnez Code>Créer un codespace sur starter-no-infra. Il faut quelques minutes pour configurer le codespace.

Capture d’écran montrant comment créer un codespace dans GitHub.

Étape 3 : Dans le terminal codespace :

  1. Exécutez des migrations de base de données avec dotnet ef database update.
  2. Exécutez l’application avec dotnet run.
  3. Lorsque la notification Your application running on port 5093 is available. s’affiche, sélectionnez Ouvrir dans le navigateur. Vous devez voir l’exemple d’application dans un nouvel onglet du navigateur. Pour arrêter l’application, tapez Ctrl+C.

Capture d’écran montrant comment exécuter l’exemple d’application à l’intérieur du codespace GitHub.

Conseil

Vous pouvez interroger GitHub Copilot à propos de ce référentiel. Par exemple :

  • @workspace Que fait ce projet ?
  • @workspace Que fait le dossier .devcontainer ?

Vous rencontrez des problèmes ? Examinez la section Résolution des problèmes.

2. Créer l’App Service, la base de données et le cache

Dans cette étape, vous créez les ressources Azure. Les étapes utilisées dans ce tutoriel créent un ensemble de ressources sécurisées par défaut qui comprennent App Service, Azure SQL Database et Azure Cache. Pour le processus de création, vous devez spécifier :

  • Le nom de l’application web. Il est utilisé dans le cadre du nom DNS de votre application sous la forme https://<app-name>-<hash>.<region>.azurewebsites.net.
  • La Région du monde où l’application sera physiquement exécutée. Il est également utilisé dans le cadre du nom DNS de votre application.
  • La Pile du runtime de l’application. C’est là que vous sélectionnez la version .NET à utiliser pour votre application.
  • Le Plan d’hébergement de l’application. Il s’agit du niveau tarifaire qui inclut l’ensemble des fonctionnalités et la scalabilité de l’application.
  • Le groupe de ressources pour l’application. Un groupe de ressources vous permet de regrouper (dans un conteneur logique) toutes les ressources Azure nécessaires à l’application.

Connectez-vous au portail Azure et procédez comme suit pour créer vos ressources Azure App Service.

Étape 1 : Dans le Portail Azure :

  1. Entrez « base de données d’application web » dans la barre de recherche située en haut du portail Azure.
  2. Sélectionnez l’élément intitulé Application web + Base de données sous le titre Place de marché. Vous pouvez également accéder directement à l’Assistant de création.

Capture d’écran montrant comment utiliser la zone de recherche dans la barre d’outils supérieure pour trouver l’Assistant de création Application web + Base de données.

Étape 2 : Dans la page Créer une application web + base de données, remplissez le formulaire comme suit.

  1. Groupe de ressources : sélectionnez Créer, puis utilisez le nom msdocs-core-sql-tutorial.
  2. Région : toute région Azure près de chez vous.
  3. Nom : msdocs-core-sql-XYZ où XYZ correspond à trois caractères aléatoires. Ce nom doit être unique au sein d’Azure.
  4. Pile d’exécution : .NET 8 (LTS).
  5. Moteur : SQLAzure. Azure SQL Database est un moteur de base de données PaaS (Platform as a Service) complètement managé qui s’exécute toujours sur la dernière version stable de SQL Server.
  6. Ajouter Azure Cache pour Redis ? : Oui.
  7. Nom du plan d’hébergement : Basic. Une fois que vous êtes prêt, vous pouvez effectuer un scale-up vers un niveau tarifaire de production.
  8. Sélectionnez Revoir + créer.
  9. Une fois la validation terminée, sélectionnez Créer.

Capture d’écran montrant comment configurer une nouvelle application et une nouvelle base de données dans l’Assistant Application web + Base de données.

Étape 3 : Le déploiement prend quelques minutes. Une fois le déploiement terminé, sélectionnez le bouton Accéder à la ressource. L’application App Service s’ouvre automatiquement, mais les ressources suivantes sont créées :

  • Groupe de ressources : conteneur pour toutes les ressources créées.
  • Plan App Service : définit les ressources de calcul pour App Service. Un plan Linux est créé sur le niveau De base.
  • App Service : représente votre application et s’exécute dans le plan App Service.
  • Réseau virtuel : intégré à l’application App Service, isole le trafic réseau principal.
  • Points de terminaison privés : points de terminaison d’accès pour le coffre de clés, le serveur de base de données et le cache Redis dans le réseau virtuel.
  • Interfaces réseau : représente les adresses IP privées, une pour chacun des points de terminaison privés.
  • Serveur Azure SQL Database : accessible uniquement derrière son point de terminaison privé.
  • Azure SQL Database : une base de données et un utilisateur sont créés pour vous sur le serveur.
  • Azure Cache pour Redis : accessible uniquement derrière son point de terminaison privé.
  • Coffre de clés : accessible uniquement derrière son point de terminaison privé. Permet de gérer les secrets de l’application App Service.
  • Zones DNS privées : permettent la résolution DNS du coffre de clés, du serveur de base de données et du cache Redis dans le réseau virtuel.

Capture d’écran montrant le processus de déploiement effectué.

3. Secrets de la connexion sécurisée

L’Assistant Création a déjà généré la variable de connectivité pour vous en tant que chaînes de connexion .NET et de paramètres d’application. Toutefois, la meilleure pratique de sécurité consiste à éliminer complètement les secrets d’App Service. Vous allez déplacer vos secrets vers un coffre de clés et modifier votre paramètre d’application sur Références Key Vault à l’aide des connecteurs de services.

Conseil

Pour utiliser l’authentification sans mot de passe, consultez Comment modifier la connexion SQL Database pour utiliser une identité managée à la place ?

Étape 1 : Récupérer la chaîne de connexion existante

  1. Dans le menu de gauche de la page App Service, sélectionnez Paramètres > Variables d’environnement > Chaînes de connexion.
  2. Sélectionnez AZURE_SQL_CONNECTIONSTRING.
  3. Dans Ajouter/Modifier une chaîne de connexion, dans le champ Valeur, recherchez la partie Password= à la fin de la chaîne.
  4. Copiez la chaîne de mot de passe après Password= pour une utilisation ultérieure. Cette chaîne de connexion vous permet de vous connecter à la base de données SQL sécurisée derrière un point de terminaison privé. Toutefois, les secrets sont enregistrés directement dans l’application App Service, ce qui n’est pas le meilleur. De même, la chaîne de connexion du cache Redis sous l’onglet Paramètres de l’application contient un secret. Vous allez changer ça.

Une capture d’écran montrant comment voir la valeur d’un paramètre de l’application.

Étape 2 : Créer un coffre de clés pour la gestion sécurisée des secrets

  1. Dans la barre de recherche supérieure, tapez « coffre de clés », puis sélectionnez Place de marché>Coffre de clés.
  2. Dans Groupe de ressources, sélectionnez msdocs-core-sql-tutorial.
  3. Dans nom du coffre de clés, tapez un nom composé uniquement de lettres et de chiffres.
  4. Dans Région, définissez-la sur le même emplacement en tant que groupe de ressources.

Une capture d’écran montrant comment créer un coffre de clés.

Étape 3 : Sécuriser le coffre de clés avec un point de terminaison privé

  1. Sélectionnez l’onglet Réseau.
  2. Désélectionnez Activer l’accès public.
  3. Séllectionnez Créer un point de terminaison privé.
  4. Dans Groupe de ressources, sélectionnez msdocs-core-sql-tutorial.
  5. Dans la boîte de dialogue, dans Emplacement,sélectionnez le même emplacement que votre application App Service.
  6. Dans Nom, tapez msdocs-core-sql-XYZVvaultEndpoint.
  7. Dans Réseau virtuel, sélectionnez msdocs-core-sql-XYZVnet.
  8. Dans Sous-réseau, msdocs-core-sql-XYZSubnet.
  9. Cliquez sur OK.
  10. Sélectionnez Vérifier + créer, puis sélectionnez Créer. Attendez que le déploiement du coffre de clés se termine. Vous devez voir « Votre déploiement est terminé ».

Capture d’écran montrant comment sécuriser un coffre de clés avec un point de terminaison privé.

Étape 4 :

  1. Dans la barre de recherche supérieure, tapez msdocs-core-sql, puis sélectionnez la ressource App Service appelée msdocs-core-sql-XYZ.
  2. Sur la page App Service, dans le menu de gauche, sélectionnez Paramètres > Connecteur de services. Il existe déjà deux connecteurs, que l’Assistant Création d’application a créés pour vous.
  3. Cochez la case en regard du connecteur SQL Database, puis sélectionnez Modifier.
  4. Sélectionnez l’onglet Authentification.
  5. Dans Mot de passe, collez le mot de passe que vous avez copié précédemment.
  6. Sélectionnez Stocker le secret dans Key Vault.
  7. Sous Connexion du coffre de clés, sélectionnez Créer. Une boîte de dialogue Créer une connexion est ouverte en haut de la boîte de dialogue d’édition.

Capture d’écran montrant comment modifier un connecteur de services SQL Database avec une connexion de coffre de clés.

Étape 5 : Établir la connexion Key Vault

  1. Dans la boîte de dialogue Créer une connexion pour la connexion Key Vault, dans Key Vault, sélectionnez le coffre de clés que vous avez créé précédemment.
  2. Sélectionnez Vérifier + créer.
  3. Lorsque la validation terminée, sélectionnez Créer.

Capture d’écran montrant comment configurer un connecteur de services Key Vault.

Étape 6 : finaliser les paramètres du connecteur de base de données SQL

  1. Vous revenez dans la boîte de dialogue d’édition pour defaultConnector. Sous l’onglet Authentification, attendez que le connecteur de coffre de clés soit créé. Une fois l’opération terminée, la liste déroulante Connexion Key Vault effectue automatiquement la sélection.
  2. Sélectionnez Suivant : Réseau.
  3. Cliquez sur Enregistrer. Attendez que la notification Mise à jour réussie s’affiche.

Capture d’écran montrant la connexion du coffre de clés sélectionnée dans le connecteur de services SQL Database.

Étape 7 : configurer le connecteur Redis pour utiliser les secrets Key Vault

  1. Dans la page Connecteurs de service, cochez la case en regard du connecteur Cache pour Redis, puis sélectionnez Modifier.
  2. Sélectionnez l’onglet Authentification.
  3. Sélectionnez Stocker le secret dans Key Vault.
  4. Sous Connexion Key Vault, sélectionnez le coffre de clés que vous avez créé.
  5. Sélectionnez Suivant : Réseau.
  6. Sélectionnez Configurer des règles de pare-feu pour activer l’accès au service cible. L’Assistant Création d’application a déjà sécurisé la base de données SQL avec un point de terminaison privé.
  7. Cliquez sur Enregistrer. Attendez que la notification Mise à jour réussie s’affiche.

Capture d’écran montrant comment modifier le connecteur de services Cache pour Redis avec une connexion de coffre de clés.

Étape 8 : vérifier l’intégration de Key Vault

  1. Depuis le menu de gauche, sélectionnez Paramètres > Variables d’environnement > Chaînes de connexion à nouveau.
  2. En regard de AZURE_SQL_CONNECTIONSTRING, sélectionnez Afficher la valeur. La valeur doit être @Microsoft.KeyVault(...), ce qui signifie qu’il s’agit d’une référence coffre de clés, car le secret est maintenant managé dans le coffre de clés.
  3. Pour vérifier la chaîne de connexion Redis, sélectionnez l’onglet Paramètre d’application. En regard de AZURE_REDIS_CONNECTIONSTRING, sélectionnez Afficher la valeur. La valeur doit également être @Microsoft.KeyVault(...).

Capture d’écran montrant comment afficher la valeur de la chaîne de connexion .NET dans Azure.

En résumé, le processus de sécurisation de vos secrets de connexion est complexe :

  • Récupération des secrets de connexion dans les variables d'environnement de l'application App Service.
  • Création d’un coffre de clés
  • Création d'une connexion Key Vault avec l'identité gérée attribuée par le système.
  • Mise à jour des connecteurs de service pour stocker les secrets dans le coffre de clés.

4. Déployer l’exemple de code

Dans cette étape, vous configurez le déploiement GitHub avec GitHub Actions. Cette méthode fait partie des nombreuses façons de déployer sur App Service, mais elle permet également de bénéficier d’une intégration continue dans votre processus de déploiement. Par défaut, chaque git push vers votre référentiel GitHub lance l’action de build et de déploiement.

Étape 1 : Dans le menu de gauche, sélectionnez Déploiement>Centre de déploiement.

Capture d’écran montrant comment ouvrir le centre de déploiement dans App Service.

Étape 2 : Dans la page Centre de déploiement :

  1. Dans Source, sélectionnez GitHub. Par défaut, GitHub Actions est sélectionné en tant que fournisseur de build.
  2. Connectez-vous à votre compte GitHub et suivez l’invite pour autoriser Azure.
  3. Dans Organisation, sélectionnez votre compte.
  4. Dans Dépôt, sélectionnez msdocs-app-service-sqldb-dotnetcore.
  5. Dans Branche, sélectionnez starter-no-infra. Il s’agit de la même branche que celle dans laquelle vous avez travaillé avec votre exemple d’application, sans fichiers ou configuration liés à Azure.
  6. Pour le Type d’authentification, sélectionnez Identité affectée par l’utilisateur.
  7. Dans le menu principal, sélectionnez Enregistrer. App Service valide un fichier de flux de travail dans le référentiel GitHub choisi, au sein du répertoire .github/workflows. Par défaut, le centre de déploiement crée une identité affectée par l’utilisateur pour que le flux de travail s’authentifie à l’aide de Microsoft Entra (authentification OIDC). Pour des options d’authentification alternatives, consultez Déployer sur App Service à l’aide de GitHub Actions.

Capture d’écran montrant comment configurer les pratiques CI/CD avec GitHub Actions.

Étape 3 : De retour dans le codespace GitHub de votre exemple de duplication, exécutez git pull origin starter-no-infra. Cela extrait le fichier de workflow nouvellement validé dans votre espace de code.

Capture d’écran montrant git pull à l’intérieur d’un codespace GitHub.

Étape 4 (Option 1 : avec GitHub Copilot) :

  1. Démarrez une nouvelle session de conversation en sélectionnant la vue Conversation, puis en sélectionnant +.
  2. Demandez « @workspace Comment l’application se connecte-t-elle à la base de données et au cache ? ». Copilot peut vous donner des explications sur la classe MyDatabaseContext et sa configuration dans Program.cs.
  3. Demandez « En mode production, je souhaite que l’application utilise la chaîne de connexion appelée AZURE_SQL_CONNECTIONSTRING pour la base de données ainsi que le paramètre d’application appelé AZURE_REDIS_CONNECTIONSTRING* ». Copilot peut vous faire une suggestion de code similaire à celle présentée dans les étapes de l’Option 2 : sans GitHub Copilot ci-dessous, et même vous demander d’effectuer le changement dans le fichier Program.cs.
  4. Ouvrez Program.cs dans l’Explorateur, puis ajoutez la suggestion de code. GitHub Copilot ne vous donne pas la même réponse à chaque fois, et elle n’est pas toujours correcte. Vous devrez peut-être poser plus de questions pour affiner sa réponse. Pour obtenir des conseils, consultez Que puis-je faire avec GitHub Copilot dans mon codespace ?

Capture d’écran montrant comment poser une question dans une nouvelle session de conversation GitHub Copilot.

Étape 4 (Option 2 : sans GitHub Copilot) :

  1. Ouvrez Program.cs dans l’Explorateur.
  2. Recherchez le code commenté (lignes 12 à 21), puis supprimez les marques de commentaire. Ce code se connecte à la base de données à l’aide de AZURE_SQL_CONNECTIONSTRING, puis se connecte au Cache Redis via le paramètre d’application AZURE_REDIS_CONNECTIONSTRING.

Capture d’écran montrant un codespace GitHub et le fichier Program.cs ouverts.

Étape 5 (Option 1 : avec GitHub Copilot) :

  1. Ouvrez .github/workflows/starter-no-infra_msdocs-core-sql-XYZ dans l’Explorateur. Ce fichier a été créé par l’Assistant Création App Service.
  2. Mettez en surbrillance l’étape dotnet publish, puis sélectionnez .
  3. Demandez à Copilot : « Installe dotnet ef, puis créez un bundle de migration dans le même dossier de sortie. »
  4. Si la suggestion est acceptable, sélectionnez Accepter. GitHub Copilot ne vous donne pas la même réponse à chaque fois, et elle n’est pas toujours correcte. Vous devrez peut-être poser plus de questions pour affiner sa réponse. Pour obtenir des conseils, consultez Que puis-je faire avec GitHub Copilot dans mon codespace ?

Capture d’écran montrant l’utilisation de GitHub Copilot dans un fichier de workflow GitHub.

Étape 5 (Option 2 : sans GitHub Copilot) :

  1. Ouvrez .github/workflows/starter-no-infra_msdocs-core-sql-XYZ dans l’Explorateur. Ce fichier a été créé par l’Assistant Création App Service.
  2. Sous l’étape dotnet publish, ajoutez une étape pour installer l’outil Entity Framework Core avec la commande dotnet tool install -g dotnet-ef --version 8.*.
  3. Sous la nouvelle étape, ajoutez une autre étape pour générer un bundle de migration de base de données dans le package de déploiement : dotnet ef migrations bundle --runtime linux-x64 -o ${{env.DOTNET_ROOT}}/myapp/migrationsbundle. Le bundle de migration est un exécutable autonome que vous pouvez exécuter dans l’environnement de production sans avoir besoin du SDK .NET. Le conteneur linux App Service a uniquement le runtime .NET, et non le SDK .NET.

Capture d’écran montrant les étapes ajoutées au fichier de workflow GitHub pour le bundle de migration de base de données.

Étape 6 :

  1. Sélectionnez l’extension Contrôle de code source.
  2. Dans la zone de texte, tapez un message de commit comme Configure Azure database and cache connections. Vous pouvez également sélectionner , puis laisser GitHub Copilot générer un message de commit à votre place.
  3. Sélectionnez Valider, puis confirmez en choisissant Oui.
  4. Sélectionnez Synchroniser les modifications 1, puis confirmez en choisissant OK.

Capture d’écran montrant les modifications actuellement commitées et poussées vers GitHub.

Étape 7 : De retour dans la page Centre de déploiement du Portail Azure :

  1. Sélectionnez l’onglet Journaux, puis Actualiser pour voir la nouvelle exécution du déploiement.
  2. Dans l’élément de journal de l’exécution du déploiement, sélectionnez l’entrée Générer/déployer des journaux avec l’horodatage le plus récent.

Capture d’écran montrant comment ouvrir les journaux de déploiement dans le centre de déploiement.

Étape 8 : Vous êtes dirigé vers votre référentiel GitHub dans lequel vous voyez l’action GitHub en cours d’exécution. Le fichier de workflow définit deux étapes distinctes : la build et le déploiement. Attendez que l’exécution de GitHub affiche l’état Opération réussie. Cela prend environ 5 minutes.

Capture d’écran montrant une exécution GitHub en cours.

Vous rencontrez des problèmes ? Examinez la section Résolution des problèmes.

5. Générer le schéma de la base de données

La base de données SQL étant protégée par le réseau virtuel, le moyen le plus simple d’exécuter les migrations de base de données dotnet est d’utiliser une session SSH avec le conteneur Linux dans App Service.

Étape 1 : De retour dans la page App Service, dans le menu de gauche,

  1. Sélectionnez Outils de développement>SSH.
  2. Sélectionnez Go.

Capture d’écran montrant comment ouvrir l’interpréteur de commandes SSH de votre application à partir du portail Azure.

Étape 2 : dans la session SSH :

  1. Exécutez cd /home/site/wwwroot. Voici tous vos fichiers déployés.
  2. Exécutez le bundle de migration généré par le workflow GitHub, avec la commande ./migrationsbundle -- --environment Production. Si l’opération réussit, App Service se connecte avec succès à la base de données SQL. N’oubliez pas que --environment Production correspond aux changements liés au code que vous avez apportés dans Program.cs.

Capture d’écran montrant les commandes à exécuter dans l’interpréteur de commandes SSH et ce qu’elles font.

Dans la session SSH, seuls les changements apportés aux fichiers dans /home peuvent être conservés au-delà des redémarrages de l’application. Les modifications effectuées en dehors de /home ne sont pas conservées.

Vous rencontrez des problèmes ? Examinez la section Résolution des problèmes.

6. Accéder à l’application

Étape 1 : Dans la page App Service :

  1. Dans le menu de gauche, sélectionnez Vue d’ensemble.
  2. Sélectionnez l’URL de votre application.

Capture d’écran montrant comment lancer une application App Service à partir du portail Azure.

Étape 2 : Ajoutez quelques tâches à la liste. Félicitations, vous exécutez une application web dans Azure App Service, avec une connectivité sécurisée à Azure SQL Database.

Capture d’écran de l’application .NET Core exécutée dans App Service.

Conseil

L’exemple d’application implémente le modèle cache-aside. Lorsque vous consultez un affichage de données pour la deuxième fois ou que vous rechargez la même page après avoir apporté des modifications aux données, le temps de traitement dans la page web affiche un temps beaucoup plus rapide, car il charge les données à partir du cache au lieu de la base de données.

7. Diffuser les journaux de diagnostic

Azure App Service capture tous les journaux de la console pour vous aider à diagnostiquer les problèmes liés à votre application. L’exemple d’application inclut le code journalisation dans chacun de ses points de terminaison pour illustrer cette capacité.

Étape 1 : Dans la page App Service :

  1. Dans le menu de gauche, sélectionnez Monitoring>Journaux App Service.
  2. Sous Application Logging, sélectionnez Système de fichiers.
  3. Dans le menu principal, sélectionnez Enregistrer.

Capture d’écran montrant comment activer les journaux natifs dans App Service à partir du portail Azure.

Étape 2 : Dans le menu de gauche, sélectionnez Flux de journaux. Les journaux de votre application (notamment les journaux de plateforme et ceux issus de l’intérieur du conteneur) apparaissent.

Capture d’écran montrant comment afficher le flux de journal dans le portail Azure.

8. Nettoyer les ressources

Lorsque vous avez terminé, vous pouvez supprimer toutes les ressources de votre abonnement Azure en supprimant le groupe de ressources.

Étape 1 : Dans la barre de recherche située en haut du Portail Microsoft Azure :

  1. Entrez le nom du groupe de ressources.
  2. Sélectionnez le groupe de ressources.

Capture d’écran montrant comment rechercher un groupe de ressources dans le portail Azure et y accéder.

Étape 2 : Sur la page Groupe de ressources, sélectionnez Supprimer un groupe de ressources.

Capture d’écran montrant l’emplacement du bouton Supprimer le groupe de ressources dans le portail Azure.

Étape 3 :

  1. Entrer le nom du groupe de ressources pour confirmer la suppression.
  2. Sélectionnez Supprimer.

Capture d’écran montrant la boîte de dialogue de confirmation de la suppression d’un groupe de ressources sur le Portail Azure. :

2. Créer des ressources Azure et déployer un exemple d’application

Dans cette étape, vous allez créer les ressources Azure et déployer un exemple d’application dans App Service sur Linux. Les étapes utilisées dans ce tutoriel créent un ensemble de ressources sécurisées par défaut, qui incluent App Service, Azure SQL Database et Azure Cache pour Redis.

Le conteneur de développement dispose déjà d’Azure Developer CLI (AZD).

  1. Depuis la racine du référentiel, exécutez azd init.

    Bash 
    azd init --template dotnet-app-service-sqldb-infra

  2. Lorsque vous y êtes invité, fournissez les réponses suivantes :

    Question Réponse
    Le répertoire actif n’est pas vide. Voulez-vous initialiser un projet ici dans «<votre-répertoire>» ? Y
    Que souhaitez-vous faire de ces fichiers ? Conserver mes fichiers existants inchangés
    Entrer un nom pour le nouvel environnement Tapez un nom unique. Le modèle AZD utilise ce nom dans le cadre du nom DNS de votre application web dans Azure (<app-name>-<hash>.azurewebsites.net). Les caractères alphanumériques et les traits d’union sont autorisés.

  3. Connectez-vous à Azure en exécutant la commande azd auth login et en suivant l’invite :

    Bash 
    azd auth login

  4. Créez les ressources Azure nécessaires et déployer le code de l’application avec la commande azd up. Suivez l’invite pour sélectionner l’abonnement et l’emplacement souhaités pour les ressources Azure.

    Bash 
    azd up

    La commande azd up prend environ 15 minutes (le cache Redis prend le plus de temps). Il compile et déploie également le code de votre application, mais vous allez modifier votre code ultérieurement pour utiliser App Service. Pendant son exécution, la commande fournit des messages sur le processus d’approvisionnement et de déploiement, y compris un lien vers le déploiement dans Azure. Une fois l’opération terminée, la commande affiche également un lien vers l’application de déploiement.

    Ce modèle AZD contient des fichiers (azure.yaml et le répertoire infra) qui génèrent une architecture sécurisée par défaut avec les ressources Azure suivantes :

    • Groupe de ressources : conteneur pour toutes les ressources créées.
    • Plan App Service : définit les ressources de calcul pour App Service. Un plan Linux est créé sur le niveau De base.
    • App Service : représente votre application et s’exécute dans le plan App Service.
    • Réseau virtuel : intégré à l’application App Service, isole le trafic réseau principal.
    • Points de terminaison privés : points de terminaison d’accès pour le coffre de clés, le serveur de base de données et le cache Redis dans le réseau virtuel.
    • Interfaces réseau : représente les adresses IP privées, une pour chacun des points de terminaison privés.
    • Serveur Azure SQL Database : accessible uniquement derrière son point de terminaison privé.
    • Azure SQL Database : une base de données et un utilisateur sont créés pour vous sur le serveur.
    • Azure Cache pour Redis : accessible uniquement derrière son point de terminaison privé.
    • Coffre de clés : accessible uniquement derrière son point de terminaison privé. Permet de gérer les secrets de l’application App Service.
    • Zones DNS privées : permettent la résolution DNS du coffre de clés, du serveur de base de données et du cache Redis dans le réseau virtuel.

    Une fois que la commande a fini de créer les ressources et de déployer le code de l’application pour la première fois, l’exemple d’application déployé ne fonctionne pas encore, car vous devez apporter de petits changements pour qu’il se connecte à la base de données dans Azure.

Vous rencontrez des problèmes ? Examinez la section Résolution des problèmes.

3. Vérifier les chaînes de connexion

Conseil

La chaîne de connexion de base de données SQL par défaut utilise l’authentification SQL. Pour une authentification sans mot de passe plus sécurisée, consultez Comment changer la connexion SQL Database pour utiliser une identité managée à la place ?

Le modèle AZD utilisé a généré les variables de connectivité pour vous en tant que paramètres d’application et les restitue sur le terminal pour plus de facilité. Les paramètres d’application sont un moyen de préserver les secrets de connexion hors de votre référentiel de code.

  1. Dans la sortie AZD, recherchez les paramètres AZURE_SQL_CONNECTIONSTRING et AZURE_REDIS_CONNECTIONSTRING. Seuls les noms des paramètres sont affichés. Ils ressemblent à ceci dans la sortie AZD :

     App Service app has the following connection strings:
     - AZURE_SQL_CONNECTIONSTRING
     - AZURE_REDIS_CONNECTIONSTRING
     - AZURE_KEYVAULT_RESOURCEENDPOINT
     - AZURE_KEYVAULT_SCOPE

    AZURE_SQL_CONNECTIONSTRING contient la chaîne de connexion à SQL Database dans Azure, et AZURE_REDIS_CONNECTIONSTRING contient la chaîne de connexion au Cache Redis Azure. Vous devrez les utiliser plus tard dans votre code.

  2. Pour votre commodité, le modèle AZD affiche le lien direct vers la page des paramètres d’application de l’application. Recherchez le lien et ouvrez-le dans un nouvel onglet de navigateur.

Vous rencontrez des problèmes ? Examinez la section Résolution des problèmes.

4. Modifier l’exemple de code et effectuer au redéploiement

  1. Dans le codespace GitHub, démarrez une nouvelle session de conversation en sélectionnant la vue Conversation, puis en sélectionnant +.

  2. Demandez « @workspace Comment l’application se connecte-t-elle à la base de données et au cache ? ». Copilot peut vous donner des explications sur la classe MyDatabaseContext et sa configuration dans Program.cs.

  3. Demandez « En mode production, je souhaite que l’application utilise la chaîne de connexion appelée AZURE_SQL_CONNECTIONSTRING pour la base de données ainsi que le paramètre d’application appelé AZURE_REDIS_CONNECTIONSTRING* ». Copilot peut vous faire une suggestion de code similaire à celle présentée dans les étapes de l’Option 2 : sans GitHub Copilot ci-dessous, et même vous demander d’effectuer le changement dans le fichier Program.cs.

  4. Ouvrez Program.cs dans l’Explorateur, puis ajoutez la suggestion de code.

    GitHub Copilot ne vous donne pas la même réponse à chaque fois, et elle n’est pas toujours correcte. Vous devrez peut-être poser plus de questions pour affiner sa réponse. Pour obtenir des conseils, consultez Que puis-je faire avec GitHub Copilot dans mon codespace ?

Avant de déployer ces changements, vous devez toujours générer un bundle de migration.

Vous rencontrez des problèmes ? Examinez la section Résolution des problèmes.

5. Générer le schéma de la base de données

Dans la mesure où la base de données SQL Database est protégée par le réseau virtuel, le moyen le plus simple d’exécuter des migrations de base de données consiste à ouvrir une session SSH avec le conteneur App Service. Toutefois, les conteneurs App Service Linux ne disposent pas du kit SDK .NET. Le moyen le plus simple d’exécuter des migrations de base de données consiste donc à charger un bundle de migration autonome.

  1. Générez un bundle de migration pour votre projet avec la commande suivante :

    Bash 
    dotnet ef migrations bundle --runtime linux-x64 -o migrationsbundle

    Conseil

    L’exemple d’application (consultez DotNetCoreSqlDb.csproj) est configuré pour inclure ce fichier migrationsbundle. Durant la phase azd package, migrationsbundle va être ajouté au package de déploiement.

  2. Déployez tous les changements avec azd up.

    Bash 
    azd up

  3. Dans la sortie AZD, retrouvez l’URL de la session SSH et accédez-y dans le navigateur. Cela ressemble à ceci dans la sortie :

     Open SSH session to App Service container at: https://<app-name>.scm.azurewebsites.net/webssh/host

  4. Dans la session SSH, exécutez les commandes suivantes :

    Bash 
    cd /home/site/wwwroot
./migrationsbundle -- --environment Production

    Si cela réussit, App Service se connecte avec succès à la base de données. N’oubliez pas que --environment Production correspond aux changements liés au code que vous avez apportés dans Program.cs.

    Notes

    Seules les modifications apportées aux fichiers dans /home peuvent être conservées au-delà des redémarrages d’application. Les modifications effectuées en dehors de /home ne sont pas conservées.

Vous rencontrez des problèmes ? Examinez la section Résolution des problèmes.

6. Accéder à l’application

  1. Dans la sortie AZD, retrouvez l’URL de votre application et accédez-y dans le navigateur. L’URL ressemble à ceci dans la sortie AZD :

     Deploying services (azd deploy)

   (✓) Done: Deploying service web
   - Endpoint: https://<app-name>-<hash>.azurewebsites.net/

  2. Ajoutez quelques tâches à la liste.

    Capture d’écran de l’application web ASP.NET Core avec SQL Database s’exécutant dans Azure, et montrant les tâches.

    Félicitations, vous exécutez une application web dans Azure App Service, avec une connectivité sécurisée à Azure SQL Database.

Vous rencontrez des problèmes ? Examinez la section Résolution des problèmes.

7. Diffuser les journaux de diagnostic

Azure App Service peut capturer les journaux de la console pour vous aider à diagnostiquer les problèmes liés à votre application. Pour plus de facilité, le modèle AZD a déjà activé la journalisation sur le système de fichiers local et expédie les journaux vers un espace de travail Log Analytics.

L’exemple d’application comprend des instructions de journalisation standard pour illustrer cette fonctionnalité, comme le montre l’extrait de code suivant :

C# 
public async Task<IActionResult> Index()
{
    var todoItems = await _cache.GetAsync(_TodoItemsCacheKey);
    if (todoItems != null)
    {
        _logger.LogInformation("Data from cache.");
        var todoList = JsonConvert.DeserializeObject<List<Todo>>(Encoding.UTF8.GetString(todoItems));
        return View(todoList);
    }
    else
    {
        _logger.LogInformation("Data from database.");
        var todoList = await _context.Todo.ToListAsync();
        var serializedTodoList = JsonConvert.SerializeObject(todoList);
        await _cache.SetAsync(_TodoItemsCacheKey, Encoding.UTF8.GetBytes(serializedTodoList));
        return View(todoList);
    }
}

Dans la sortie AZD, retrouvez le lien pour diffuser en continu les journaux App Service et accédez-y dans le navigateur. Le lien ressemble à ceci dans la sortie AZD :

Stream App Service logs at: https://portal.azure.com/#@/resource/subscriptions/<subscription-guid>/resourceGroups/<group-name>/providers/Microsoft.Web/sites/<app-name>/logStream

Découvrez plus en détail la journalisation dans les applications .NET à travers la série Activer Azure Monitor OpenTelemetry pour les applications .NET, Node.js, Python et Java.

Vous rencontrez des problèmes ? Examinez la section Résolution des problèmes.

8. Nettoyer les ressources

Pour supprimer toutes les ressources Azure dans le présent environnement de déploiement, exécutez azd down et suivez les invites.

Bash 
azd down

Dépannage

La vue de déploiement du portail pour Azure SQL Database affiche un état de conflit

Selon votre abonnement et la région sélectionnée, vous pouvez voir que l’état du déploiement d’Azure SQL Database est Conflict ainsi que le message suivant dans les détails de l’opération :

Location '<region>' is not accepting creation of new Windows Azure SQL Database servers at this time.

Cette erreur est probablement due à une limite de votre abonnement pour la région que vous sélectionnez. Essayez de choisir une autre région pour votre déploiement.

Dans le portail Azure, l’IU de flux de journaux de l’application web affiche des erreurs réseau

Vous pouvez être amené à voir cette erreur :

Unable to open a connection to your app. This may be due to any network security groups or IP restriction rules that you have placed on your app. To use log streaming, please make sure you are able to access your app directly from your current network.

Il s’agit généralement d’une erreur temporaire au premier démarrage de l’application. Patientez quelques minutes, puis vérifiez à nouveau.

La session SSH dans le navigateur affiche SSH CONN CLOSED

Le démarrage du conteneur Linux prend quelques minutes. Patientez quelques minutes, puis vérifiez à nouveau.

La page de flux de journaux du portail affiche Connected! mais pas le moindre journal

Une fois que vous avez configuré les journaux de diagnostic, l’application redémarre. Vous devrez peut-être actualiser la page pour que les changements prennent effet dans le navigateur.

Forum aux questions

Quel est le coût de cette configuration ?

Le prix des ressources créées est calculé comme suit :

  • Le plan App Service est créé au niveau De base. Il peut faire l’objet d’un scale-up ou d’un scale-down. Consultez la tarification App Service.
  • La base de données Azure SQL est créée au niveau serverless à usage général sur du matériel de série Standard avec le nombre minimal de cœurs. Il engendre un faible coût et peut être distribué dans d’autres régions. Vous pouvez baisser encore plus les coûts en réduisant sa taille maximale, ou vous pouvez lui appliquer un scale-up en ajustant le niveau de service, le niveau de calcul, la configuration matérielle, le nombre de cœurs, la taille de la base de données et la redondance de zone. Consultez Tarification Azure SQL Database.
  • L’Azure Cache pour Redis est créé au niveau De base avec la taille minimale du cache. Ce niveau a un faible coût. Vous pouvez le mettre à l’échelle vers des niveaux de performances plus élevés pour une disponibilité, un clustering et d’autres fonctionnalités plus avancés. Consultez Prix Azure Cache pour Redis.
  • Le réseau virtuel n’entraîne pas de frais, sauf si vous configurez des fonctionnalités supplémentaires, telles que le peering. Consultez Tarification du réseau virtuel Azure.
  • La zone DNS privée entraîne des frais minimes. Consultez la tarification d’Azure DNS.

Comment me connecter au serveur Azure SQL Database qui est sécurisé derrière le réseau virtuel avec d’autres outils ?

  • Pour un accès de base à partir d’un outil en ligne de commande, vous pouvez exécuter sqlcmd à partir du terminal SSH de l’application. Le conteneur de l’application n’est pas équipé de sqlcmd. Vous devez donc l’installer manuellement. N’oubliez pas que le client installé ne persiste pas après redémarrage de l’application.
  • Pour vous connecter à partir d’un client SQL Server Management Studio ou de Visual Studio, votre machine doit se trouver dans le réseau virtuel. Par exemple, il peut s’agir d’une machine virtuelle Azure connectée à l’un des sous-réseaux ou d’une machine dans un réseau local disposant d’une connexion VPN de site à site avec le réseau virtuel Azure.

Comment le développement d’applications locales fonctionne-t-il avec GitHub Actions ?

Prenez le fichier de workflow généré automatiquement à partir d’App Service comme exemple, chaque git push lance une nouvelle exécution de build et de déploiement. À partir d’un clone local du dépôt GitHub, vous faites en sorte que les mises à jour souhaitées le poussent vers GitHub. Par exemple :

terminal 
git add .
git commit -m "<some-message>"
git push origin main

Comment déboguer des erreurs pendant le déploiement de GitHub Actions ?

Si une étape échoue dans le fichier de flux de travail GitHub généré automatiquement, essayez de modifier la commande ayant échoué pour générer une sortie plus détaillée. Par exemple, vous pouvez obtenir plus de sorties à partir de l’une des commandes dotnet en ajoutant l’option -v. Validez et envoyez vos modifications pour déclencher un autre déploiement à App Service.

Je n’ai pas les autorisations pour créer une identité affectée par l’utilisateur

Consultez Configurer le déploiement de GitHub Actions à partir du Centre de déploiement.

Comment changer la connexion SQL Database pour utiliser une identité managée à la place ?

La chaîne de connexion par défaut à la base de données SQL est gérée par le connecteur de services. Elle se nomme defaultConnector, et utilise l’authentification SQL. Pour la remplacer par une connexion qui utilise une identité managée, exécutez les commandes suivantes dans Cloud Shell après avoir remplacé les espaces réservés :

Azure CLI 
az extension add --name serviceconnector-passwordless --upgrade
az sql server update --enable-public-network true
az webapp connection delete sql --connection defaultConnector --resource-group <group-name> --name <app-name>
az webapp connection create sql --connection defaultConnector --resource-group <group-name> --name <app-name> --target-resource-group <group-name> --server <database-server-name> --database <database-name> --client-type dotnet --system-identity --config-connstr true
az sql server update --enable-public-network false

Par défaut, la commande az webapp connection create sql --client-type dotnet --system-identity --config-connstr effectue les opérations suivantes :

  • Définit votre utilisateur en tant qu’administrateur Microsoft Entra ID du serveur SQL Database.
  • Crée une identité managée affectée par le système, et lui octroie l’accès à la base de données.
  • Génère une chaîne de connexion sans mot de passe appelée AZURE_SQL_CONNECTIONGSTRING, que votre application utilise déjà à la fin du tutoriel.

Votre application doit désormais disposer d’une connectivité à la base de données SQL. Pour plus d’informations, consultez Tutoriel : Connexion à des bases de données Azure à partir d’App Service sans secrets à l’aide d’une identité managée.

Conseil

Vous ne souhaitez pas activer de connexions via un réseau public ? Vous pouvez ignorer az sql server update --enable-public-network true en exécutant les commandes à partir d’Azure Cloud Shell qui est intégré à votre réseau virtuel, si vous disposez de l’attribution de rôle Propriétaire dans votre abonnement.

Pour octroyer à l’identité l’accès nécessaire à la base de données sécurisée par le réseau virtuel, az webapp connection create sql a besoin d’une connectivité directe avec authentification Entra ID au serveur de base de données. Par défaut, Azure Cloud Shell ne dispose pas de cet accès à la base de données sécurisée par le réseau.

Que puis-je faire avec GitHub Copilot dans mon codespace ?

Vous avez peut-être remarqué que la vue de conversation GitHub Copilot était déjà là pour vous quand vous avez créé le codespace. Pour plus de commodité, nous incluons l’extension de conversation GitHub Copilot dans la définition du conteneur (consultez .devcontainer/devcontainer.json). Cependant, vous avez besoin d’un compte GitHub Copilot (essai gratuit de 30 jours disponible).

Quelques conseils à appliquer quand vous parlez à GitHub Copilot :

  • Dans une session de conversation unique, les questions et réponses s’appuient les unes sur les autres et vous pouvez ajuster vos questions pour affiner la réponse que vous obtenez.
  • Par défaut, GitHub Copilot n’a accès à aucun fichier de votre référentiel. Pour poser des questions sur un fichier, vous devez d’abord l’ouvrir dans l’éditeur.
  • Pour permettre à GitHub Copilot d’accéder à tous les fichiers du référentiel lors de la préparation de ses réponses, commencez votre question par @workspace. Pour plus d’informations, consultez Use the @workspace agent.
  • Dans la session de conversation, GitHub Copilot peut suggérer des modifications et même (avec @workspace) où apporter les modifications, mais il n’est pas autorisé à apporter les modifications pour vous. C’est à vous d’ajouter les changements suggérés et de les tester.

Voici d’autres choses que vous pouvez dire pour affiner la réponse que vous obtenez :

  • Je souhaite que ce code s’exécute uniquement en mode production.
  • Je veux que ce code s’exécute seulement dans Azure App Service et non pas localement.
  • Le paramètre --output-path semble ne pas être pris en charge.

Contenu connexe

Passez au tutoriel suivant pour apprendre à sécuriser votre application avec un domaine personnalisé et un certificat.

  Sécuriser à l’aide d’un domaine personnalisé et d’un certificat

Ou consultez les autres ressources :

Tutoriel : Se connecter à SQL Database à partir d’App Service sans secrets à l’aide d’une identité managée

Configurer une application ASP.NET Core