Application web de base

Azure App Service

Azure Monitor

Azure SQL Database

Cet article fournit une architecture de base pour vous aider à découvrir comment exécuter des applications web sur Azure App Service dans une seule région.

Important

Cette architecture n’est pas destinée aux applications de production. Il sert de configuration d’introduction pour l’apprentissage et la preuve de concept (POC). Pour concevoir une application App Service de production, consultez l’application web redondante interzone hautement disponible de référence.

Architecture

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

Flux de travail

Le workflow suivant correspond au diagramme précédent.

Un utilisateur émet une requête HTTPS sur le domaine par défaut d’App Service sur azurewebsites.net. Ce domaine pointe automatiquement vers l’adresse IP publique intégrée de votre application App Service. La connexion TLS (Transport Layer Security) est établie directement du client vers App Service. Azure gère entièrement le certificat.
L’authentification simple, qui est une fonctionnalité d’App Service, garantit que l’utilisateur qui accède au site est authentifié à l’aide de Microsoft Entra ID.
Le code de votre application déployé sur App Service traite la requête. Par exemple, ce code peut se connecter à une instance de Azure SQL Database à l'aide d'un chaîne de connexion configuré dans App Service en tant que paramètre d'application.
Les informations sur la requête d’origine adressée à App Service et l’appel à SQL Database sont consignées dans Application Insights.

Composants

Microsoft Entra ID est un service de gestion des identités et des accès cloud qui fournit des fonctionnalités d’authentification et d’autorisation. Dans cette architecture, elle s’intègre à App Service via Easy Auth pour garantir l’authentification pour les utilisateurs qui accèdent à l’application web. Il simplifie également le processus d’authentification sans nécessiter de modifications significatives du code.
App Service est une plateforme managée pour la création, le déploiement et la mise à l’échelle d’applications web. Dans cette architecture, elle héberge le code de l’application web, gère les requêtes HTTPS sur le domaine par défaut azurewebsites.net et se connecte à SQL Database via des chaînes de connexion configurées.
Azure Monitor est un service de supervision qui collecte, analyse et agit sur les données de télémétrie à partir d’environnements cloud et locaux. Dans cette architecture, elle capture et stocke des informations sur les demandes adressées à App Service et les appels à SQL Database via l’intégration d’Application Insights.
SQL Database est un service de base de données relationnelle managé qui fournit des fonctionnalités SQL Server dans le cloud. Dans cette architecture, elle sert de couche de stockage de données, ce qui permet à l’application App Service de se connecter via des chaînes de connexion définies dans les paramètres de l’application.

Considérations

Ces considérations implémentent les piliers d’Azure Well-Architected Framework, un ensemble de principes directeurs que vous pouvez utiliser pour améliorer la qualité d’une charge de travail. Pour plus d’informations, consultez Well-Architected Framework.

Les composants répertoriés dans cette architecture sont liés aux guides de services Well-Architected. Les guides de service détaillent les recommandations et les considérations pour des services spécifiques. Cette section étend cette aide en mettant en évidence les recommandations clés Well-Architected Framework et les considérations qui s’appliquent à cette architecture.

Cette architecture de base est conçue uniquement à des fins d’évaluation et d’apprentissage. Il hiérarchise la simplicité et l’efficacité des coûts par rapport aux fonctionnalités de niveau production. Les sections suivantes mettent en évidence les principales limitations de cette architecture et fournissent des recommandations et des considérations pour vous aider à planifier des déploiements plus robustes.

Fiabilité

La fiabilité permet de s’assurer que votre application peut respecter les engagements que vous prenez à vos clients. Pour en savoir plus, consultez Liste de contrôle de l'examen de la conception pour la fiabilité.

Cette architecture n’est pas conçue pour les déploiements de production. Les fonctionnalités de fiabilité critiques suivantes sont omises dans cette architecture :

Le plan App Service est configuré pour le niveau Standard, qui n'inclut pas la prise en charge de Azure zones de disponibilité. App Service devient indisponible si un problème se produit avec l’instance, le rack ou le centre de données qui héberge l’instance.
SQL Database est configuré pour le niveau De base, qui ne prend pas en charge la redondance de zone. Par conséquent, les données ne sont pas répliquées dans les zones de disponibilité Azure, ce qui risque la perte de données engagées si une panne se produit.
Les déploiements sur cette architecture peuvent entraîner un temps d’arrêt pour les déploiements d’applications, car la plupart des techniques de déploiement nécessitent que toutes les instances en cours d’exécution soient redémarrées. Les utilisateurs peuvent rencontrer des erreurs 503 pendant ce processus. Ce temps d’arrêt de déploiement est résolu dans l’architecture de base via 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é causés par des ressources de calcul insuffisantes, vous devez surprovisionner pour garantir une capacité suffisante pour gérer la demande simultanée maximale.

Pour plus d’informations sur la façon de surmonter ces problèmes de fiabilité, consultez l’application web de référence hautement disponible et redondante entre zones - Fiabilité.

Si la charge de travail nécessite une architecture active ou active-passive multirégion, consultez les approches d’application App Service multirégion pour la récupération d’urgence.

Sécurité

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

Cette architecture n’est pas conçue pour les déploiements de production. Les fonctionnalités de sécurité critiques suivantes ont été omises dans cette architecture, ainsi que d’autres recommandations et considérations de 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 qu’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 plus d’informations sur la façon dont l’implémentation du réseau privé garantit les caractéristiques de sécurité suivantes, consultez l’application web de référence hautement disponible et redondante entre zones – Mise en réseau. L’implémentation d’un réseau privé permet d’atténuer ces risques en fournissant les fonctionnalités de sécurité suivantes :
- Point d’entrée sécurisé unique pour le trafic client.
- Le trafic réseau est filtré à la fois au niveau du paquet et au niveau du déni de service distribué (DDoS).
- L’exfiltration des données est réduite en conservant le trafic dans Azure à l’aide de Azure Private Link.
- 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 de déploiement de Azure Web Application Firewall. L'application Web n'est pas protégée contre les exploits et vulnérabilités courants. Pour voir comment Azure Web Application Firewall pouvez être implémenté avec Azure Application Gateway dans une architecture App Services, consultez l’implémentation baseline.
Cette architecture de base stocke les secrets tels que le SQL Server chaîne de connexion dans les paramètres de l’application. Les paramètres de l’application sont chiffrés par défaut. Toutefois, lorsque vous passez à la production, envisagez de stocker des secrets dans Azure Key Vault pour améliorer la gouvernance. Pour renforcer la sécurité et réduire la surcharge de gestion des secrets, envisagez d’utiliser l’identité managée pour l’authentification au lieu d’incorporer des secrets dans des chaînes de connexion.
Le débogage à distance et les points de terminaison Kudu peuvent rester activés pendant le développement ou la phase POC. Lorsque vous passez à la production, vous devez désactiver les plans de contrôle, les déploiements et les accès à distance inutiles.
Les méthodes d’authentification locales pour les déploiements de sites FTP (File Transfer Protocol) et SCM (Source Control Management) peuvent rester activées pendant la phase de développement ou de POC. Lorsque vous passez à la production, vous devez désactiver l'authentification locale pour ces points de terminaison.
Vous n'avez pas besoin d'activer Microsoft Defender pour App Service dans la phase POC. Lorsque vous passez à la production, vous devez activer Defender pour que l'App Service génère des recommandations de sécurité. Vous devez implémenter ces recommandations pour augmenter votre posture de sécurité et détecter plusieurs menaces pour votre déploiement App Service.
App Service inclut un point de terminaison SSL (Secure Sockets Layer) sur un sous-domaine de azurewebsites.net sans frais supplémentaires. Les requêtes HTTP sont redirigées vers le point de terminaison HTTPS par défaut. Pour les déploiements de production, un domaine personnalisé est généralement utilisé avec Application Gateway ou Gestion des API devant votre déploiement App Service.
Utilisez le mécanisme d’authentification intégré pour App Service. Easy Auth simplifie le processus d’intégration de 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 pour SQL Server à l’aide d’un mot de passe dans un chaîne de connexion. Envisagez d’utiliser identité managée pour vous authentifier auprès de SQL Server.

Pour plus d’informations, consultez Sécuriser une application dans App Service.

Optimisation des coûts

L’optimisation des coûts se concentre sur les moyens de réduire les dépenses inutiles et d’améliorer l’efficacité opérationnelle. Pour plus d’informations, consultez liste de vérification de la révision de conception pour l’optimisation des coûts.

Cette architecture optimise les coûts par le biais des nombreux compromis par rapport aux autres piliers de l’infrastructure Well-Architected. Ces compromis sont spécifiquement faits pour s’aligner sur les objectifs d’apprentissage et de POC de cette architecture. Les économies de coûts par rapport à une architecture mieux adaptée à la production, telle que l’application web hautement disponible avec redondance interzones, résultent principalement des choix suivants :

Une instance unique de l'App Service, sans activation de la mise à l’échelle automatique
Niveau tarifaire standard pour App Service
Aucun certificat TLS personnalisé ou adresse IP statique
Aucun pare-feu d’applications web (WAF)
Aucun compte de stockage dédié pour le déploiement d’applications
Niveau tarifaire de base pour SQL Database, sans stratégies de rétention de sauvegarde
Aucun composant Microsoft Defender pour le Cloud
Aucun contrôle de sortie du trafic réseau via un pare-feu
Aucun point de terminaison privé
Durée minimale de conservation des journaux et des journaux d’activité dans Azure Monitor journaux

Pour afficher le coût estimé de cette architecture, consultez l’estimation de la calculatrice de prix qui utilise les composants de cette architecture. Le coût de cette architecture peut généralement être réduit davantage à l’aide d’un abonnement Azure Dev/Test, qui serait un type d’abonnement idéal pour les PC comme celui-ci.

Excellence opérationnelle

L’excellence opérationnelle couvre les processus d’exploitation qui déploient une application et la conservent 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 sur la configuration, la surveillance et le 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. Vous pouvez stocker des secrets dans la configuration App Service pendant la phase POC. Vous n’utilisez pas de secrets réels et n’avez pas besoin de gouvernance des secrets dont les charges de travail de production nécessitent.

Tenez compte des recommandations et considérations de configuration suivantes :

Commencez par utiliser la configuration App Service pour stocker les valeurs de configuration et les chaînes de connexion dans les déploiements POC. Les paramètres de l’application et les chaînes de connexion sont chiffrés et déchiffrés immédiatement avant d’être injectés dans votre application au démarrage.
Lorsque vous passez à la production, stockez vos secrets dans Key Vault. Key Vault améliore la gouvernance des secrets de deux façons :
- L’externalisation de vos secrets à Key Vault fournit un emplacement unique et centralisé pour la gestion sécurisée des secrets.
- En utilisant Key Vault, vous pouvez journaliser toutes les interactions avec les secrets, y compris chaque fois qu’un secret est accessible.
Lorsque vous passez à la production, vous pouvez conserver votre utilisation de Key Vault et de configuration App Service à l’aide de références Key Vault.

conteneurs

Vous pouvez utiliser l’architecture de base pour déployer du code pris en charge directement sur des instances Windows ou Linux. App Service est également une plateforme d’hébergement de conteneurs que vous pouvez utiliser pour exécuter votre application web conteneurisée. App Service fournit différents conteneurs intégrés. Les applications personnalisées ou à plusieurs conteneurs permettent d’affiner l’environnement d’exécution ou de prendre en charge les langages de code qui ne sont pas pris en charge en mode natif. Cette approche nécessite l’introduction d’un registre de conteneurs.

Plan de contrôle

Pendant la phase POC, familiarisez-vous avec le plan de contrôle App Service, qui est accessible via le service Kudu. Ce service fournit des API de déploiement courantes, telles que les déploiements ZIP, et expose les journaux bruts et les variables d’environnement.

Si vous utilisez des conteneurs, vérifiez que vous comprenez la capacité de Kudu à ouvrir une session SSH (Secure Shell) sur un conteneur pour prendre en charge les fonctionnalités de débogage avancées.

Diagnostics et surveillance

Pendant la phase POC, il est important de comprendre quels journaux et métriques peuvent être capturés. Tenez compte des recommandations et idées suivantes pour la surveillance dans la phase POC :

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 permet de comprendre les journaux et les métriques qui vous sont fournis prêts à l'emploi et vous aide à identifier les lacunes que vous devez combler à l’aide d’un framework de journalisation dans votre code d’application. Lorsque vous passez à la production, éliminez les sources de logs qui n'apportent pas de valeur mais génèrent du bruit et augmentent les coûts pour le récepteur de logs de votre charge de travail.
Configurez la journalisation pour utiliser Azure Log Analytics. Azure Log Analytics vous fournit une plateforme évolutive pour centraliser la journalisation facile à interroger.
Utilisez Application Insights ou un autre outil de gestion des performances des applications (APM) pour émettre des données de télémétrie et des journaux pour surveiller les performances des applications.

Déploiement

Les points suivants fournissent des conseils pour déployer 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 à créer votre logique de déploiement dans la phase POC. L’implémentation de l’intégration continue et de la livraison continue (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 passez à la production.
Utilisez Azure Resource Manager modèles (modèles ARM) pour déployer des ressources Azure et leurs dépendances. Il est important de démarrer ce processus dans 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 à Azure DevOps Services. 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 les principes de conception de l’excellence opérationnelle.

Efficacité des performances

L’efficacité des performances fait référence à la capacité de votre charge de travail à mettre à l’échelle pour répondre efficacement aux demandes des utilisateurs. 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 les déploiements de production, cette section décrit certaines des fonctionnalités critiques d’efficacité des performances qui ont été omises dans cette architecture, ainsi que d’autres recommandations et considérations.

Un résultat de votre POC doit être une sélection de référence SKU que vous estimez adaptée à votre charge de travail. Concevez votre charge de travail pour répondre efficacement à la demande via la mise à l’échelle horizontale en ajustant le nombre d’instances de calcul déployées dans le plan App Service. Ne concevez pas le système pour qu’il dépende de la modification de la référence SKU de calcul pour s’aligner sur la demande.

Le déploiement d’App Service dans cette architecture de base n’a pas de mise à l’échelle automatique implémentée. Le service n’effectue pas de scale-out dynamique ou de scale-in 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 la mise à l’échelle automatique basée sur des règles. Dans le cadre de votre processus POC, déterminez des paramètres de mise à l’échelle automatique efficaces adaptés aux besoins des ressources de votre code d’application et aux modèles d’utilisation attendus.
- Pour les déploiements de production, tenez compte des niveaux Premium qui prennent en charge la mise à l’échelle 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.

Étapes suivantes

Tutoriels de déploiement :

Documentation du produit :

Modules d'apprentissage Microsoft

Commentaires

Cette page a-t-elle été utile ?