Application web de base

Cet article présente une architecture de base destinée à l'apprentissage de l'exécution d'applications Web sur Azure App Service dans une seule région.

Architecture

Figure 1 : Architecture Azure App Service de base

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

Workflow

1. Un utilisateur émet une requête HTTPS vers le domaine par défaut de l'App Service sur azurewebsites.net. Ce domaine pointe automatiquement vers l'IP publique intégrée de votre App Service. La connexion TLS est établie depuis le client directement vers l'app service. La certification est entièrement gérée par Azure.
2. Easy Auth, une fonctionnalité d'Azure App Service, garantit que l'utilisateur qui accède au site est authentifié avec Microsoft Entra ID.
3. Le code de votre application déployé sur App Service traite la requête. Par exemple, ce code peut se connecter à une instance d'Azure SQL Database, à l'aide d'une chaîne de connexion configurée dans l'App Service configuré en tant que paramètre d'application.
4. Les informations relatives à la requête originale adressée à App Service et à l'appel à Azure SQL Database sont journalisées dans Application Insights.

Composants

• Microsoft Entra ID est un service de gestion des identités et des accès basé sur le cloud. Il fournit un seul plan de contrôle d’identité pour gérer les autorisations et les rôles pour les utilisateurs qui accèdent à votre application web. Il s’intègre à App Service et simplifie l’authentification et l’autorisation pour les applications web.
• App Service est une plateforme complètement managée permettant de créer, déployer et mettre à l’échelle des applications web.
• Azure Monitor est un service de supervision qui collecte, analyse et agit sur les données de télémétrie dans votre déploiement.
• Azure SQL Database est un service de base de données relationnelle managé pour données relationnelles.

Recommandations et considérations

Les composants énumérés dans cette architecture sont liés aux guides de service Azure Well-Architected. Les guides de service détaillent les recommandations et les considérations pour des services spécifiques. Cette section prolonge ces conseils en soulignant les principales recommandations et considérations du cadre Azure Well-Architected Framework qui s'appliquent à cette architecture. Pour plus d’informations, consultez Microsoft Azure Well-Architected Framework.

Cette architecture de base n'est pas destinée à être déployée en production. L'architecture privilégie la simplicité et la rentabilité par rapport à la fonctionnalité pour vous permettre d'évaluer et d'apprendre Azure App Service. Les sections suivantes décrivent certaines lacunes de cette architecture de base, ainsi que les recommandations et considérations qui s'y rapportent.

Fiabilité

La fiabilité permet de s’assurer que votre application tient vos engagements auprès de vos clients. Pour en savoir plus, consultez Liste de contrôle de l'examen de la conception pour la fiabilité.

Comme cette architecture n'est pas conçue pour des déploiements en production, vous trouverez ci-dessous certaines des fonctionnalités de fiabilité critiques qui sont omises dans cette architecture :

• Le plan de service d'application est configuré pour le niveau Standard, qui ne dispose pas de la prise en charge de la zone de disponibilité Azure. L'App Service devient indisponible en cas de problème avec l'instance, le rack ou le centre de données hébergeant l'instance.
• La base de données Azure SQL est configurée pour le niveau Basic, qui ne prend pas en charge la redondance de zone. Cela signifie que les données ne sont pas répliquées à travers les zones de disponibilité Azure, ce qui risque d'entraîner la perte des données engagées en cas de panne.
• Les déploiements de cette architecture peuvent entraîner des temps d'arrêt lors du déploiement d'applications, car la plupart des techniques de déploiement nécessitent le redémarrage de toutes les instances en cours d'exécution. Les utilisateurs peuvent rencontrer des erreurs 503 au cours de ce processus. Cet aspect est pris en compte dans l'architecture de base par le biais d'emplacements de déploiement. Une conception soignée des applications, la gestion des schémas et la manipulation de la configuration des applications sont nécessaires pour prendre en charge le déploiement simultané d'emplacements. Utilisez ce POC pour concevoir et valider votre approche de déploiement de production basée sur les emplacements.
• La mise à l'échelle automatique n'est pas activée dans cette architecture de base. Pour éviter les problèmes de fiabilité dus au manque de ressources de calcul disponibles, vous devez surprovisionner pour toujours fonctionner avec suffisamment de ressources de calcul pour gérer la capacité maximale simultanée.

Voyez comment surmonter ces problèmes de fiabilité dans la section relative à la fiabilité de l'application Web hautement disponible en zone redondante de Baseline.

Si cette charge de travail nécessite à terme une architecture active-active ou active-passive multirégionale, consultez Application Web multirégionale hautement disponible pour obtenir des conseils sur le déploiement de votre charge de travail hébergée par App Service dans plusieurs régions

Sécurité

La sécurité fournit des garanties contre les attaques délibérées, et contre l’utilisation abusive de vos données et systèmes importants. Pour en savoir plus, consultez Liste de contrôle de l'examen de la conception pour la sécurité.

Cette architecture n'étant pas conçue pour des déploiements en production, vous trouverez ci-dessous certaines des fonctionnalités de sécurité critiques qui ont été omises dans cette architecture, ainsi que d'autres recommandations et considérations relatives à la fiabilité :

• Cette architecture de base n'implémente pas la confidentialité du réseau. Les plans de données et de gestion des ressources, tels que Azure App Service et Azure SQL Server, sont accessibles sur l'internet public. L'absence de réseau privé augmente considérablement la surface d'attaque de votre architecture. Pour savoir comment la mise en place d'un réseau privé garantit les fonctionnalités de sécurité suivantes, consultez la section relative au réseau de l'application Web à redondance de zone hautement disponible de Baseline :

  • Point d’entrée sécurisé unique pour le trafic client
  • Le trafic réseau est filtré à la fois au niveau des paquets et au niveau DDoS.
  • L’exfiltration de données est minimisée en conservant le trafic dans Azure via une liaison privée
  • Les ressources réseau sont logiquement regroupées et isolées les unes des autres par segmentation du réseau.

• Cette architecture de base n'inclut pas le déploiement du pare-feu Azure Web Application Firewall. L'application Web n'est pas protégée contre les exploits et vulnérabilités courants. Consultez l'implémentation de base pour voir comment le Web Application Firewall peut être mis en œuvre avec Azure Application Gateway dans une architecture Azure App Services.

• Cette architecture de base stocke des secrets tels que la chaîne de connexion d'Azure SQL Server dans les paramètres de l'application. Bien que les paramètres de l'application soient chiffrés, lorsque vous passez à la production, envisagez de stocker les secrets dans Azure Key Vault pour une gouvernance accrue. Une solution encore meilleure consiste à utiliser l'identité gérée pour l'authentification et à ne pas stocker de secrets dans la chaîne de connexion.

• Laisser le débogage à distance et les points de terminaison Kudu activés pendant le développement ou la phase de validation du concept est une bonne chose. Lorsque vous passez à la production, vous devez désactiver les plans de contrôle, les déploiements et les accès à distance inutiles.

• L'activation des méthodes d'authentification locale pour les déploiements de sites FTP et SCM est acceptable pendant la phase de développement ou de validation de principe. Lorsque vous passez à la production, vous devez désactiver l'authentification locale pour ces points de terminaison.

• Il n'est pas nécessaire d'activer Microsoft Defender pour App Service dans la phase de validation du concept. Lorsque vous passez à la production, vous devez activer Defender for App Service pour générer des recommandations de sécurité que vous devriez mettre en œuvre pour améliorer votre posture de sécurité et détecter les menaces multiples pour votre App Service.

• Azure App Service inclut un point de terminaison SSL sur un sous-domaine de azurewebsites.net sans coût supplémentaire. Les requêtes HTTP sont redirigées vers le point de terminaison HTTPS par défaut. Pour les déploiements en production, vous utiliserez généralement un domaine personnalisé associé à la passerelle d'application ou à la gestion des API devant votre déploiement App Service.

• Utilisez le mécanisme d’authentification intégré pour App Service (« EasyAuth »). EasyAuth simplifie le processus d’intégration des fournisseurs d’identité dans votre application web. Il gère l’authentification en dehors de votre application web, de sorte que vous n’avez pas à apporter de modifications significatives au code.

• Utilisez une identité managée pour les identités de charge de travail. Identité managée permet aux développeurs de ne plus avoir à gérer les informations d’authentification. L'architecture de base s'authentifie auprès de SQL Server via le mot de passe dans une chaîne de connexion. Envisagez d'utiliser l'identité gérée pour vous authentifier auprès d'Azure SQL Server.

Pour accéder à des considérations supplémentaires sur la sécurité, consultez Sécuriser une application dans Azure App Service.

Excellence opérationnelle

L’excellence opérationnelle couvre les processus d’exploitation qui déploient une application et maintiennent son fonctionnement en production. Pour plus d’informations, consultez la Liste de contrôle de l'examen de la conception pour l'excellence opérationnelle.

Les sections suivantes fournissent des conseils autour de la configuration, de la surveillance et du déploiement de votre application App Service.

Configurations d'application

L'architecture de base n'étant pas destinée à la production, elle utilise la configuration App Service pour stocker les valeurs de configuration et les secrets. Stocker des secrets dans la configuration d'App Service est une bonne chose pour la phase de PoC. Vous n'utilisez pas de vrais secrets et n'avez pas besoin de la gouvernance des secrets qu'exigent les charges de travail de production.

Vous trouverez ci-dessous des recommandations et des considérations relatives à la configuration :

• Commencez par utiliser la configuration App Service pour stocker les valeurs de configuration et les chaînes de connexion dans les déploiements de validation de principe. Les paramètres de l'app et les chaînes de connexion sont chiffrés et déchiffrés juste avant d'être injectés dans votre application lors de son démarrage.
• Lorsque vous passez à la phase de production, stockez vos secrets dans Azure Key Vault. L'utilisation d'Azure Key Vault améliore la gouvernance des secrets de deux manières :
  • L'externalisation de votre stockage de secrets vers Azure Key Vault vous permet de centraliser votre stockage de secrets. Vous disposez d'un seul endroit pour gérer les secrets.
  • En utilisant Azure Key Vault, vous êtes en mesure de journaliser chaque interaction avec les secrets, y compris chaque fois qu'un secret est consulté.
• Lorsque vous passez à la production, vous pouvez maintenir votre utilisation d'Azure Key Vault et de la configuration d'App Service en utilisant des références Key Vault.

Diagnostics et surveillance

Pendant la phase de validation du concept, il est important de comprendre quels journaux et quelles mesures sont disponibles pour être capturés. Vous trouverez ci-dessous des recommandations et des considérations relatives à la surveillance lors de la phase de validation du concept :

• Activez la journalisation des diagnostics pour toutes les sources de journaux des éléments. La configuration de l'utilisation de tous les paramètres de diagnostic vous aide à comprendre quels journaux et mesures sont fournis d'emblée et quelles sont les lacunes que vous devrez combler à l'aide d'un cadre de journalisation dans le code de votre application. Lorsque vous passez à la production, vous devez éliminer les sources de journaux qui n'apportent pas de valeur ajoutée et qui ajoutent du bruit et des coûts au récepteur de journaux de votre charge de travail.
• Configurez la journalisation pour utiliser Azure Log Analytics. Azure Log Analytics vous fournit une plateforme évolutive pour centraliser les journaux qui sont faciles à interroger.
• Utilisez Application Insights ou un autre outil de gestion des performances des applications (APM) pour émettre de la télémétrie et des journaux afin de surveiller les performances des applications.

Déploiement

Vous trouverez ci-dessous des conseils pour le déploiement de votre application App Service.

• Suivez les conseils de CI/CD pour Azure Web Apps avec Azure Pipelines pour automatiser le déploiement de votre application. Commencez à construire votre logique de déploiement lors de la phase PoC. La mise en œuvre de CI/CD au début du processus de développement vous permet d'itérer rapidement et en toute sécurité sur votre application au fur et à mesure que vous avancez vers la production.
• Utilisez des modèles ARM pour déployer des ressources Azure et leurs dépendances. Il est important de commencer ce processus lors de la phase PoC. Au fur et à mesure que vous progressez vers la production, vous souhaitez pouvoir déployer automatiquement votre infrastructure.
• Utilisez différents modèles ARM et intégrez-les aux services Azure DevOps. Cette configuration vous permet de créer différents environnements. 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.

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

conteneurs

L'architecture de base peut être utilisée pour déployer le code pris en charge directement sur des instances Windows ou Linux. Alternativement, App Service est aussi une plateforme d'hébergement de conteneurs pour exécuter votre application Web conteneurisée. Container Apps propose différents conteneurs intégrés. Si vous utilisez des applications personnalisées ou multi-conteneurs pour affiner davantage votre environnement d'exécution ou pour prendre en charge un langage de code non pris en charge de manière native, vous devrez introduire un registre de conteneurs.

Plan de contrôle

Pendant la phase POC, familiarisez-vous avec le plan de contrôle d'Azure App Service tel qu'il est exposé par le biais du service Kudu. Ce service expose les API de déploiement communes, telles que les déploiements ZIP, expose les journaux bruts et les variables d'environnement.

Si vous utilisez des conteneurs, assurez-vous de comprendre la capacité de Kudu à ouvrir une session SSH dans un conteneur pour prendre en charge des capacités de débogage avancées.

Efficacité des performances

L’efficacité des performances est la capacité de votre charge de travail à s’adapter à la demande des utilisateurs de façon efficace. Pour en savoir plus, consultez Liste de vérification de l'examen de la conception pour l'efficacité des performances

Étant donné que cette architecture n'est pas conçue pour des déploiements en production, vous trouverez ci-dessous certaines des fonctionnalités critiques en matière d'efficacité des performances qui ont été omises dans cette architecture, ainsi que d'autres recommandations et considérations.

Votre démonstration de faisabilité doit déboucher sur une sélection d'UGS que vous estimez adaptée à votre charge de travail. Votre charge de travail doit être conçue pour répondre efficacement à la demande par une mise à l'échelle horizontale en ajustant le nombre d'instances de calcul déployées dans l'App Service Plan. Ne concevez pas le système de manière à ce qu'il dépende de la modification de l'UGS de calcul pour s'aligner sur la demande.

• Dans cette architecture de base, l'App Service ne dispose pas d'une mise à l'échelle automatique. Le service n'est pas dynamiquement mis à l'échelle pour rester efficacement aligné sur la demande.
  • Le niveau Standard prend en charge les paramètres de mise à l'échelle automatique pour vous permettre de configurer une mise à l'échelle automatique basée sur des règles. Une partie de votre processus POC doit consister à définir des paramètres de mise à l'échelle automatique efficaces basés sur les besoins en ressources de votre code d'application et les caractéristiques d'utilisation attendues.
  • Pour les déploiements en production, envisagez des niveaux Premium qui prennent en charge l'autoscaling automatique, où la plateforme gère automatiquement les décisions de mise à l'échelle.
• Suivez les conseils pour mettre à l'échelle des bases de données individuelles sans interruption de l'application si vous avez besoin d'un niveau de service ou d'un niveau de performance plus élevé pour SQL Database.

Déployer ce scénario

Ces conseils sont étayés par un exemple de mise en œuvre qui présente une application App Service de base sur Azure.

Étapes suivantes

Ressources associées

• Application web redondante interzone de base
• Application web multirégion hautement disponible

Documentation du produit :

• Présentation d’App Service
• Vue d’ensemble d’Azure Monitor
• Vue d’ensemble du plan Azure App Service
• Présentation de Log Analytics dans Azure Monitor
• Qu’est-ce que Microsoft Entra ID ?
• Qu’est-ce qu’Azure SQL Database ?

Modules Microsoft Learn :

• Configurer et gérer Azure Monitor
• Configurer Microsoft Entra ID
• Configurer Azure Monitor
• Déployer et configurer des serveurs, des instances et des bases de données pour Azure SQL
• Explorer Azure App Service
• Héberger une application web avec Azure App Service
• Héberger votre domaine sur Azure DNS
• Implémenter Azure Key Vault
• Gérer les utilisateurs et les groupes dans Microsoft Entra ID