Modifier

Application web de base

Azure App Service
Azure Key Vault
Azure Monitor
Azure SQL Database

Cette architecture montre les composants fondamentaux d’une application web de base. Vous pouvez utiliser l’architecture pour générer une application web, puis personnaliser l’application en fonction de vos besoins.

Architecture

Diagram showing the reference architecture for a basic web application in Azure.

Téléchargez un fichier Visio de cette architecture.

Composants

  • Azure App Service est une plateforme complètement managée qui permet de créer et de déployer des applications cloud. Il vous permet de définir un ensemble de ressources de calcul pour une application web à exécuter, déployer des applications web et configurer des emplacements de déploiement.
  • Un emplacement de déploiement vous permet de planifier un déploiement, puis de l'échanger avec le déploiement de production. De cette façon, vous évitez le déploiement directement dans l’environnement de production. Consultez la section d’ingénierie et de déploiement de mise en production ci-dessous pour obtenir des recommandations spécifiques.
  • Adresse IP : l’application App Service a une adresse IP publique et un nom de domaine. Le nom de domaine est un sous-domaine de azurewebsites.net, tel que contoso.azurewebsites.net.
  • DNS Azure est un service d’hébergement pour les domaines DNS qui offre une résolution de noms à l’aide de l’infrastructure Microsoft Azure. En hébergeant vos domaines dans Azure, vous pouvez gérer vos enregistrements DNS avec les mêmes informations d’identification, les mêmes API, les mêmes outils et la même facturation que vos autres services Azure. Pour utiliser un nom de domaine personnalisé, tel que contoso.com, créez des enregistrements DNS qui mappent le nom de domaine personnalisé sur l’adresse IP. Pour plus d’informations, consultez Configurer un nom de domaine personnalisé dans Azure App Service.
  • Azure SQL Database est une base de données relationnelle en tant que service du cloud. SQL Database partage sa base de code avec le moteur de base de données Microsoft SQL Server. Selon les exigences de votre application, vous pouvez également utiliser Azure Database pour MySQL ou Azure Database pour PostgreSQL. Il s’agit de services de base de données complètement managés basés sur les moteurs de base de données open source MySQL Server et Postgres.
  • Microsoft Entra ID est un service de gestion des identités et des accès cloud qui permet aux employés d’accéder aux applications cloud développées pour votre organisation.
  • Azure Monitor est une solution pour collecter, analyser et agir sur les journaux et les métriques de vos environnements.
  • Azure Key Vault prend en charge la gestion des secrets, la gestion des clés et la gestion des certificats. Il peut stocker les secrets d’application comme les chaînes de connexion de base de données.

Recommandations

Vos exigences peuvent différer de celles de l’architecture décrite et donnée dans le code. Le code se déploie avec des configurations de production. Utilisez les recommandations pour personnaliser votre déploiement pour répondre à vos besoins.

Plan App Service

Le plan App Service a différents niveaux tarifaires. Chaque niveau de tarification prend en charge plusieurs tailles d’instance qui diffèrent par le nombre de cœurs et la quantité de mémoire. Vous pouvez modifier le niveau tarifaire après le déploiement en sélectionnant « Scale-up (App Service Plan) » sur la navigation de gauche. Voici quelques recommandations App Service :

  • Exécutez votre charge de travail de production sur les niveaux tarifaires De base, Standard et Premium. Dans ces trois niveaux, l’application s’exécute sur des instances de machine virtuelle dédiées et dispose de ressources allouées qui peuvent effectuer un scale-out.
  • Utilisez les niveaux Standard et Premier si vous avez besoin de mise à l’échelle automatique et TLS/SSL.
  • Créez un plan de App Service différent pour le test et le développement. Utilisez les niveaux Gratuit et Partagé (préversion) pour les tests et le développement pour optimiser les coûts. Mais n’utilisez pas les niveaux Gratuits et Partagés pour les charges de travail de production. Les ressources partagées ne peuvent pas être mises à l’échelle.
  • Veillez à supprimer des plans que vous n’utilisez pas, tels que les déploiements de test. Les plans App Service sont facturés par seconde. Vous êtes facturé pour les instances dans le plan App Service, même si l’application est arrêtée. Pour plus d’informations sur les plans et la facturation App Service, consultez :

Le modèle ARM ci-dessous se déploie sur le niveau tarifaire Standard.

SQL Database

  • Utilisez Azure SQL Database pour réduire la surcharge de gestion. Azure SQL Database crée une construction logique qui joue le rôle d’un point d’administration central pour une collection de bases de données. Cette construction logique réduit la surcharge de gestion. Chaque base de données du groupe est déployée avec un niveau de service spécifique. Au sein de chaque groupe, les bases de données ne peuvent pas partager les ressources. Aucuns frais de calcul ne s’appliquent au serveur mais vous devez spécifier le niveau pour chaque base de données. Ainsi, les performances peuvent être meilleures compte tenu des ressources dédiées, mais le coût peut être plus élevé.
  • Planifiez la capacité et choisissez des niveaux de service et de performances correspondant à vos besoins. SQL Database prend en charge les niveaux de service De base, Standard et Premium, avec au sein de chaque niveau plusieurs niveaux de performances mesurés en unités de transaction de base de données (DTU - Database Transaction Units).

Région

  • Créer le plan App Service et SQL Database dans la même région pour réduire la latence du réseau. Généralement, sélectionnez la région la plus proche de vos utilisateurs.
  • Le groupe de ressources a également une région. Il spécifie où les métadonnées de déploiement sont stockées. Placez le groupe de ressources et ses ressources dans la même région afin d’améliorer la disponibilité lors du déploiement.
  • Utilisez la calculatrice de prix pour estimer les coûts.
  • Pour plus d’informations, consultez la section sur les coûts dans Microsoft Azure Well-Architected Framework.

Considérations

Ces considérations met en œuvre les piliers d’Azure Well-Architected Framework. Les piliers sont un ensemble de principes directeurs qui améliorent la qualité d'une charge de travail. Pour plus d'informations, consultez Microsoft Azure Well-Architected Framework.

Efficacité des performances

Le principal avantage de Azure App Service est la possibilité de mettre à l’échelle votre application en fonction de la charge. Voici quelques considérations à prendre en compte pendant la planification de la mise à l’échelle de votre application.

Mise à l’échelle de l’application App Service

Il existe deux façons de mettre à l’échelle une application App Service :

  • Scale up signifiant la modification de la taille de l’instance. La taille de l’instance détermine la quantité de mémoire et de stockage et le nombre de cœurs pour chaque instance de machine virtuelle. Vous pouvez monter en puissance manuellement en modifiant la taille d’instance ou le niveau du plan.
  • Scale-out, signifiant l’ajout d’instances pour traiter une augmentation de charge. Chaque niveau de tarification possède un nombre d’instances maximal. Vous pouvez effectuer un scale-out manuellement en changeant le nombre d’instances ou en configurant la mise à l’échelle automatique pour qu’Azure ajoute ou supprime automatiquement des instances en fonction des métriques de performances et/ou de planification. Chaque opération de mise à l’échelle se produit vite, généralement en quelques secondes.

Pour activer la mise à l’échelle automatique, créez un profil de mise à l’échelle qui définit le nombre minimal et maximal d’instances. Vous pouvez configurer des profils basées sur la planification pour déclencher des événements de mise à l’échelle. Par exemple, vous pouvez créer des profils différents pour les jours de la semaine et le week-end. Un profil peut contenir des règles pour l’ajout ou la suppression des instances. Par exemple, ajouter deux instances si l’utilisation du processeur est supérieure à 70 % pendant 5 minutes.

Recommandations pour la mise à l’échelle d’une application web :

  • Limitez la montée en puissance et la baisse autant que possible. Il peut déclencher un redémarrage d’application. À la place du scale out, sélectionnez un niveau et une taille répondant à vos besoins de performances sous une charge normale, puis effectuez un scale-out des instances pour gérer les changements dans le volume de trafic.
  • Activez la mise à l’échelle automatique. Si votre application a une charge de travail régulière et prévisible, créez des profils pour planifier à l’avance le nombre d’instances. Si la charge de travail n’est pas prévisible, faites une mise à l’échelle basée sur des règles pour réagir aux variations de charge. Vous pouvez combiner ces deux approches.
  • Utilisez l’utilisation du processeur pour les règles de mise à l’échelle automatique. L’utilisation de l’UC est généralement une bonne métrique pour les règles de mise à l’échelle. Toutefois, vous devriez tester la charge de votre application, identifier les goulots d’étranglement potentiels et baser vos règles de mise à l’échelle sur ces données.
  • Définissez une période de refroidissement plus courte pour l’ajout d’instances et une période de refroidissement plus longue pour la suppression d’instances. Les règles de mise à l’échelle automatique incluent une période de refroidissement. La période de refroidissement est l’intervalle entre la fin d’une action de mise à l’échelle et le démarrage d’une nouvelle. La période de refroidissement permet de stabiliser le système avant une nouvelle mise à l’échelle. Par exemple, choisissez une période de 5 minutes pour ajouter une instance, mais une période de 60 minutes pour supprimer une instance. Il est préférable d’ajouter de nouvelles instances rapidement en cas de charge importante afin de pouvoir gérer le trafic supplémentaire, puis de réduire progressivement le nombre d’instances.

Mise à l’échelle de bases de données SQL

Si vous avez besoin d’un niveau de service ou de performances supérieur pour SQL Database, vous pouvez monter en puissance les bases de données individuelles sans interruption de l’application.

Pour plus d'informations, consultez Mettre à l'échelle des ressources de base de données unique dans Azure SQL Database.

Fiabilité

Au moment de la rédaction de cet article, le contrat de niveau de service (SLA) d’App Service est de 99,95 %. Le contrat SLA App Service s’applique aux instances uniques et multiples. Le contrat SLA pour SQL Database est de 99,99 % pour les niveaux De base, Standard et Premium.

Sauvegardes

SQL Database fournit la restauration dans le temps et la restauration géographique pour restaurer des pertes de données. Ces fonctionnalités sont disponibles dans tous les niveaux et sont automatiquement activées. Vous n’avez pas besoin de planifier ou de gérer les sauvegardes.

Excellence opérationnelle

Créez des groupes de ressources distincts pour les environnements de production, de développement et de test. Des environnements distincts simplifient la gestion des déploiements, la suppression des déploiements de test et l’attribution des droits d’accès.

Lorsque vous attribuez des ressources aux groupes de ressources, considérez les fonctionnalités suivantes :

  • Cycle de vie. D’une façon générale, placez les ressources avec le même cycle de vie dans un même groupe de ressources.
  • Accès. Vous pouvez utiliser le contrôle d’accès en fonction du rôle Azure (RBAC) pour appliquer des stratégies d’accès aux ressources d’un groupe.
  • Facturation. Vous pouvez afficher les coûts cumulés pour le groupe de ressources.

Pour plus d’informations, consultez Présentation d’Azure Resource Manager.

Configurations d'application

  • Stockez les paramètres de configuration en tant que paramètres de l'application. Définissez les paramètres d’application dans vos modèles Resource Manager ou à l’aide de PowerShell. Lors du runtime, les paramètres d’application sont disponibles pour l’application en tant que variables d’environnement.
  • Ne recherchez jamais des mots de passe, clés d’accès ou chaînes de connexion dans un contrôle de code source. Au lieu de cela, passez les secrets en tant que paramètres dans un script de déploiement qui stocke ces valeurs comme paramètres de l’application.
  • Lorsque vous échangez un emplacement de déploiement, les paramètres d’application sont échangés par défaut. Si vous avez besoin de paramètres de production et de préproduction différents, vous pouvez créer des paramètres d’application spécifiques à un emplacement et qui ne seront pas transférés.

Diagnostics et surveillance

DevOps

  • Utilisez des modèles ARM pour déployer des ressources Azure et leurs dépendances. Le modèle ARM associé déploie une seule application web. Toutes les ressources sont isolées dans la même charge de travail de base. Cet isolement facilite l'association des ressources spécifiques de la charge de travail à une équipe. L’équipe peut ensuite gérer indépendamment tous les aspects de ces ressources. Cet isolement permet à l'équipe DevOps d'effectuer une intégration et une livraison continues (CI/CD).
  • Utilisez différents modèles ARM et intégrez-les aux services Azure DevOps. Cette configuration vous permet de créer différents environnements en quelques minutes. Par exemple, vous pouvez répliquer des scénarios de type production ou des environnements de test de charge uniquement si nécessaire et économiser sur le coût.
  • Provisionnez plusieurs instances de l’application web. Vous ne souhaitez pas que votre application web dépende d’une seule instance et peut-être créer un point de défaillance unique. Avoir plusieurs instances améliore la résilience et la scalabilité.

Pour plus d'informations, consultez la section DevOps d'Azure Well-Architected Framework.

Mise en production et déploiement

  • Utilisez les modèles Azure Resource Manager pour approvisionner des ressources Azure. Les modèles facilitent l’automatisation des déploiements via PowerShell ou l’interface de ligne de commande Azure.
  • Déployer l’application (code, binaires et fichiers de contenu). Vous disposez de plusieurs options, notamment le déploiement depuis un référentiel Git local, à l’aide de Visual Studio ou bien un déploiement continu à partir du contrôle de code source dans le cloud. Voir Déploiement de votre application dans Azure App Service

Une application App Service a toujours un emplacement de déploiement nommé production. L’emplacement de production représente le site de production en direct. Nous vous recommandons de créer un emplacement de préproduction pour le déploiement des mises à jour. Voici plusieurs avantages de l’utilisation d’un emplacement de préproduction :

  • Vous pouvez vérifier la réussite du déploiement avant de le permuter en production.
  • Le déploiement vers un emplacement de préproduction garantit la préparation de toutes les instances avant de le permuter en production. Un grand nombre d’applications présentent un temps de préparation et de démarrage à froid important.
  • La création d’un troisième emplacement pour stocker le dernier déploiement correct. Après avoir échangé les emplacements de préproduction et de production, déplacez le déploiement de production précédent (maintenant à l’emplacement de préproduction) vers l’emplacement du dernier déploiement correct. Ainsi, vous pouvez rapidement revenir à la dernière version correcte si vous détectez un problème plus tard.

Swapping slots for production and staging deployments

  • Si vous restaurez une version précédente, assurez-vous que toutes les modifications de schéma de la base de données sont rétrocompatibles.
  • N’utilisez pas d’emplacements de votre déploiement de production pour des tests, car toutes les applications appartenant au même plan App Service partagent les mêmes instances de machine virtuelle. Par exemple, des tests de charge peuvent dégrader le site de production réelle. Utilisez plutôt des plans App Service distincts pour la production et le test. En plaçant les déploiements de test dans un plan séparé, vous les isolez de la version de production.

Sécurité

Cette section répertorie les considérations relatives à la sécurité qui sont spécifiques aux services Azure décrits dans cet article. Il ne s’agit pas d’une liste complète de bonnes pratiques relatives à la sécurité. Pour accéder à des considérations supplémentaires sur la sécurité, consultez Sécuriser une application dans Azure App Service.

Audit de base de données SQL

L’audit peut vous aider à respecter une conformité réglementaire et à découvrir des discordances et irrégularités susceptibles d’indiquer des problèmes pour l’entreprise ou des violations de la sécurité. Consultez Prise en main de l'audit de base de données SQL.

Emplacements de déploiement

Chaque emplacement de déploiement possède une adresse IP publique. Sécuriser les emplacements hors production à l’aide de la connexion Microsoft Entra afin que seuls les membres de vos équipes de DevOps et de développement puissent atteindre ces points de terminaison.

Journalisation

Les journaux d’activité ne devrez jamais enregistrer les mots de passe des utilisateurs ou d’autres informations qui peuvent être utilisées pour valider l’usurpation d’identité. Retirez ces détails des données avant de les stocker.

SSL

Une application App Service comprend un point de terminaison SSL sur un sous-domaine de azurewebsites.net sans coût supplémentaire. Le point de terminaison SSL comprend un certificat générique pour le domaine *.azurewebsites.net. Si vous utilisez un nom de domaine personnalisé, vous devez fournir un certificat correspondant au domaine personnalisé. L’approche la plus simple est d’acheter un certificat directement via le portail Azure. Vous pouvez également importer des certificats à partir d’autres autorités de certification. Pour plus d’informations, consultez Acheter et configurer un certificat SSL pour votre service Azure App Service.

HTTPS n’est pas activé par défaut dans le déploiement du modèle ARM. Comme meilleure pratique de sécurité, votre application doit appliquer le protocole HTTPS en redirigeant les requêtes HTTP. Vous pouvez implémenter le HTTPS à l'intérieur de votre application ou utiliser une règle de réécriture d'URL, comme décrit dans Activer le protocole HTTPS pour une application dans Azure App Service.

Authentification

Nous vous recommandons l’authentification via un fournisseur d’identité (IDP), tels que Microsoft Entra ID, Facebook, Google, ou Twitter. Utilisez OAuth 2 ou OpenID Connect (OIDC) pour le flux d’authentification. Microsoft Entra ID fournit des fonctionnalités permettant de gérer les utilisateurs et les groupes, créer des rôles d’application, intégrer vos identités locales et consommer des services principaux tels que Microsoft 365 et Skype pour entreprises.

Évitez que l’application gère directement les informations d’identification et des connexions. Cela crée une surface d’attaque potentielle. Au minimum, vous avez besoin d’une confirmation par e-mail, de la récupération de mot de passe et de l’authentification multifacteur, de la validation de la force du mot de passe et du stockage des hachages de mot de passe de manière sécurisée. Les grands fournisseurs d’identité gèrent tous ces éléments pour vous et supervisent et améliorent constamment leurs pratiques de sécurité.

Envisagez l'utilisation de l'authentification App Service pour implémenter le flux d'authentification OAuth ou OIDC. Avantages de l’authentification App Service :

  • Simple à configurer.
  • Aucun code n’est requis pour les scénarios d’authentification simples.
  • Prend en charge la délégation d’autorisation à l’aide des jetons d’accès OAuth afin de consommer des ressources pour le compte de l’utilisateur.
  • Fournit un cache de jeton intégré.

Certaines limitations de l’authentification App Service :

  • Options de personnalisation limitées.
  • L’autorisation déléguée est limitée à une ressource principale par ouverture de session.
  • Si vous utilisez plusieurs fournisseurs d’identité, il n’existe aucun mécanisme intégré pour la découverte du domaine d’accueil.
  • Pour les scénarios d’architecture mutualisée, l’application doit implémenter la logique pour valider l’émetteur du jeton.

Déployer ce scénario

Cette architecture comprend un plan Azure App Service et une application vide. Elle utilise Azure SQL Database, Azure Key Vault pour stocker la chaîne de connexion à la base de données et Azure Monitor pour la journalisation, la supervision et les alertes.

Utilisez la commande suivante pour créer un groupe de ressources pour le déploiement. Sélectionnez le bouton Essayer pour utiliser un interpréteur de commandes incorporé.

az group create --name basic-web-app --location eastus

Exécutez la commande suivante pour déployer l’application web et l’infrastructure de prise en charge. Quand vous y êtes invité, entrez un nom d’utilisateur et un mot de passe. Ces valeurs sont utilisées pour accéder à l’instance Azure SQL Database.

az deployment group create --resource-group basic-web-app  \
    --template-uri https://raw.githubusercontent.com/mspnp/samples/master/solutions/basic-web-app/azuredeploy.json

Pour obtenir des informations détaillées et d’autres options de déploiement, consultez les modèles ARM utilisés pour déployer cette solution.

Modèle ARM d’application web de base

Étapes suivantes

Conseils de dépannage de votre application :

Documentation du produit :

Modules Microsoft Learn :