Azure Spring Apps intégré aux zones d’atterrissage

Cette architecture de référence déploie l'architecture de ligne de base Azure Spring Apps dans les zones d'atterrissage Azure.

Dans ce scénario, votre organisation s'attend à ce que la charge de travail utilise des ressources fédérées gérées par des équipes centrales (plateforme). Les exemples de gestion centralisée comprennent la mise en réseau pour la connectivité sur site, la gestion de l'accès à l'identité et les politiques. Cette aide suppose que l'organisation a adopté les zones d'atterrissage Azure pour appliquer une gouvernance cohérente et économiser des coûts sur plusieurs charges de travail.

Les zones clés de la conception technique de cet accélérateur couvrent les choix de conception effectués dans cette architecture. Pour plus d'informations, reportez-vous à Accélérateur de zone d'atterrissage Azure Spring Apps.

Architecture

Le schéma ci-dessous illustre l'architecture de cette approche :

Utilisations courantes de cette architecture :

• Applications privées : applications internes déployées dans des environnements de cloud hybrides.
• Applications publiques : applications accessibles de l'extérieur.

Ces cas d'usage sont similaires, à l'exception de la configuration des règles de sécurité et de trafic.

Composants

Les sections suivantes décrivent les composants de cette architecture. Les composants sont divisés en fonction des responsabilités des propriétaires afin de vous aider à identifier les éléments à partager avec les équipes de la plateforme de l'organisation. Pour obtenir de la documentation sur les services Azure, reportez-vous à Ressources connexes.

Ressources de l'équipe d'application

Votre équipe est responsable de la création et de la maintenance des ressources suivantes.

• Azure Spring Apps Standard est l'hôte de vos applications Java Spring Boot dans Azure.

• Azure Application Gateway Standard_v2 est le proxy inverse l'itinéraire du trafic web entrant vers Azure Spring Apps. Cette référence SKU intègre le pare-feu Azure Web Application Firewall qui inspecte le trafic pour détecter les vulnérabilités de l'Open Web Application Security Project (OWASP).

• Les machines virtuelles Azure interviennent en tant que jump box pour les opérations de gestion.

• Azure Database pour MySQL stocke les données d’application.

• Azure Key Vault stocke les secrets et la configuration, comme une chaîne de connexion à la base de données.

• Log Analytics est une fonctionnalité d'Azure Monitor également appelée Azure Monitor Logs. Log Analytics est le récepteur de surveillance qui stocke les journaux et les mesures provenant de l'application et des services Azure.

• Azure Application Insights est utilisé comme outil APM (Application Performance Management) pour collecter toutes les données de supervision des applications et les stocker directement dans Log Analytics.

Les ressources de la plate-forme appartenant à l'équipe

Cette architecture suppose que les ressources suivantes existent déjà. Ces ressources sont détenues et gérées par les équipes centrales de l'organisation. Pour réduire l'opération de réduction et optimiser les coûts, votre application dépend de ces services.

• Le Pare-feu Azure inspecte et restreint le trafic de sortie.

• Azure Bastion assure un accès sécurisé aux jump box.

• Azure ExpressRoutefournit une connectivité privée entre l'infrastructure locale et l'infrastructure Azure.

• Azure DNSassure la résolution de noms entre différents locaux.

• La passerelle réseau VPN Azure connecte l'application aux équipes distantes dans votre réseau local.

Considérations relatives à l'application

L'implémentation de référence comprend un exemple d'application qui illustre une application microservices typique hébergée dans une instance d'application Azure Spring Apps. Les sections suivantes fournissent des détails sur l'application hébergée. Pour plus d’informations, consultez l'exemple d'échantillon de stock PetClinic.

Détection du service

Dans un modèle de microservices, la capacité de registre de service doit être prise en charge pour le routage des requêtes des utilisateurs et la communication de service à service.

Ces services devraient avoir la capacité de communiquer avec d'autres services. Lorsque de nouvelles instances sont générées, elles sont ajoutées au registre afin qu'elles puissent être découvertes de manière dynamique. Dans cette architecture, Managed Spring Cloud Service Registry (OSS)est activé pour Azure Spring Apps. Ce service tient un registre des instances d'applications en direct, permet l'équilibrage de la charge côté client et découple les fournisseurs de services des clients sans recourir au service de nom de domaine (DNS).

L'instance Azure Spring Apps implémente le modèle de routage de la passerelle, qui fournit un point d'entrée unique pour le trafic externe. La passerelle achemine les requêtes entrantes vers les instances de service actives trouvées dans le registre. Dans cette conception, le modèle est mise en œuvre avec une implémentation open source de Spring Cloud Gateway. Celui-ci offre un ensemble de fonctionnalités comprenant l'authentification et l'autorisation, des fonctions de résilience et la limitation du débit.

Serveur de configuration

Dans le cas des microservices, les données de configuration doivent être séparées du code. Dans cette architecture, Azure Spring Apps Config Server rend possible la gestion des ressources par le biais d'un référentiel enfichable qui prend en charge le stockage local et les référentiels Git.

Redondance

Vous pouvez utiliser des zones de disponibilité lors de la création d'une instance Azure Spring Apps.

Grâce à cette fonctionnalité, Azure Spring Apps répartit automatiquement les ressources fondamentales entre les sections logiques de l'infrastructure Azure sous-jacente. Cette distribution offre un niveau de disponibilité plus élevé et protège contre les défaillances matérielles et les événements de maintenance planifiée.

La redondance de zone veille à ce que les nœuds de machine virtuelle (VM) sous-jacents soient distribués uniformément sur toutes les zones de disponibilité. Cependant, la redondance de zone ne garantit pas une distribution uniforme des instances d'applications. Si une instance d’application échoue en raison d’une panne de la zone où elle se trouve, Azure Spring Apps crée une instance d’application pour cette application sur un nœud situé dans une autre zone de disponibilité.

Si vous activez votre propre ressource dans Azure Spring Apps, par exemple en tant que stockage persistant, veuillez activer la redondance de zone pour cette ressource. Pour plus d’informations, consultez Guide pratique pour activer son propre stockage persistant dans Azure Spring Apps.

Toutes les régions ne prennent pas en charge les zones de disponibilité. Pour voir la liste des régions qui prennent en charge des zones de disponibilité, consultez Régions Azure avec prise en charge des zones de disponibilité.

Extensibilité

Azure Spring Apps offre des capacités de mise à l'échelle automatique qui permettent aux applications de se mettre à l'échelle en fonction de seuils d'indicateur de performance ou pendant une fenêtre de temps spécifique. La mise à l'échelle automatique est recommandée lorsque les applications doivent effectuer un scale-up ou un scale-out en réponse à l'évolution de la demande.

Azure Spring Apps prend également en charge la mise à l'échelle de vos applications manuellement en ajustant le processeur, la mémoire/Go par instance et le nombre d'instances d'applications. Vous pouvez utiliser ce type de mise à l'échelle pour une activité ponctuelle que vous pourriez vouloir effectuer pour certaines applications. Ajustez les valeurs en fonction des besoins de mise à l'échelle de votre application et assurez-vous que vos paramètres ne dépassent pas les limites maximales pour chaque attribut.

Mise en réseau - Éléments à prendre en compte

Dans ce cadre, la charge de travail dépend des ressources détenues par l'équipe de la plateforme pour l'accès aux ressources locales, le contrôle du trafic de sortie, etc. Pour plus d'informations, reportez-vous à l'accélérateur de zone d'atterrissage Azure Spring Apps : topologie du réseau et connectivité.

Topologie du réseau

La topologie du réseau est déterminée par l'équipe de la plateforme. Nous partons du principe que cette architecture utilise une topologie hub-and-spoke.

Réseau virtuel hub

L'abonnement connectivité contient un réseau virtuel hub partagé par l'ensemble de l'organisation. Ce réseau contient des ressources de mise en réseau détenues et gérées par l'équipe de la plateforme. Les ressources suivantes de l'équipe de la plateforme sont concernées par cette architecture :

• Le pare-feu Azure contrôle le trafic sortant vers Internet.
• Azure Bastion sécurise l'accès aux jump box.

Réseau virtuel Spoke

La zone d'atterrissage de l'application possède au moins un réseau virtuel déjà approvisionné qui est homologué sur le réseau central. Vous possédez les ressources de ce réseau, comme l'équilibreur de charge qui achemine et protège les connexions HTTP/s entrantes vers Azure Spring Apps depuis Internet.

Le réseau virtuel préprovisionné et les peerings doivent pouvoir prendre en charge la croissance attendue de la charge de travail. Faites une estimation de la taille du réseau virtuel et évaluez régulièrement les besoins avec l'équipe de la plateforme. Pour plus d’informations, consultez la Configuration requise pour le réseau virtuel.

Injection VNet et sous-réseau

Azure Spring Apps est déployé sur le réseau via le processus d'injection de réseau virtuel. Ce processus isole l'application d'Internet, des systèmes dans les réseaux privés, d'autres services Azure et même du runtime du service. En fonction des règles du réseau, le trafic entrant et sortant de l'application est autorisé ou refusé.

L'isolement est assuré par les sous-réseaux. La responsabilité de l'allocation des sous-réseaux dans le réseau virtuel en rayon vous incombe. Azure Spring Apps nécessite deux sous-réseaux dédiés pour l'exécution du service et pour les applications Java Spring Boot.

Les sous-réseaux doivent être dédiés à une seule instance Azure Spring Apps. Les instances multiples ne peuvent pas partager les mêmes sous-réseaux.

La taille minimale de chaque sous-réseau est de /28. Le volume réel dépend du nombre d'instances d'application qu'Azure Spring Apps peut prendre en charge. Pour plus d'informations, reportez-vous à Utilisation de plages de sous-réseaux plus petites.

Contrôles de réseau

Azure Application Gateway avec le pare-feu d'applications web restreint le trafic entrant vers le réseau virtuel spoke depuis l'internet. Les règles du pare-feu d'applications web autorisent ou refusent les connexions HTTP/s.

Le trafic au sein du réseau est contrôlé par l'utilisation de groupes de sécurité réseau (NSG) sur les sous-réseaux. Les NSG filtrent le trafic en fonction des adresses IP et des ports configurés. Dans cette conception, les NSG sont placés sur tous les sous-réseaux. Le sous-réseau Azure Bastion autorise le trafic HTTPS en provenance d'Internet, des services de passerelle, des équilibreurs de charge et du réseau virtuel. À partir du sous-réseau, seules les communications RDP et SSH vers les réseaux virtuels sont autorisées.

Les liaisons privées sont exploitées pour contrôler la connectivité entre Azure Spring Apps et d'autres services Azure comme l'accès au coffre de clés et à la base de données. Les points de terminaison privés sont placés dans un sous-réseau distinct.

Les enregistrements DNS de l'hôte de l'application doivent être stockés dans le DNS privé Azure pour garantir une disponibilité continue en cas de défaillance géographique.

Bien que l'abonnement de connectivité dispose de zones DNS privées, créez vos propres zones DNS privées Azure pour prendre en charge les services auxquels accèdent les points de terminaisons privés.

Afin de prévenir les attaques par exfiltration de données, le trafic sortant du réseau virtuel doit être limité. Ce trafic est acheminé via le Pare-feu Azure centralisé (tronçon suivant) qui autorise ou refuse le flux à l'aide d'un nom de domaine complet (FQDN).

Gestion de l’identité et de l’accès

La mise en œuvre de l'identité de la charge de travail doit s'aligner sur les meilleures pratiques de l'organisation afin de garantir que l'application n'enfreigne pas les limites de la sécurité ou de la gouvernance de l'organisation. Pour plus d'informations, reportez-vous à Accélérateur de la zone d'atterrissage d'Azure Spring Apps : gestion des identités et des accès.

Microsoft Entra ID est recommandé pour authentifier les utilisateurs et les services qui interagissent avec l’instance d’application Azure Spring Apps.

L’approche recommandée consiste à activer les identités managées Microsoft Entra pour les ressources Azure pour l’application afin de permettre à l’application de s’authentifier auprès d’autres services. Dans cette architecture, les identités managées attribuées par le système sont utilisées pour faciliter la gestion.

Pour l'autorisation, utilisez le contrôle d'accès basé sur les rôles (RBAC) d'Azure en appliquant le principe du moindre privilège lors de l'octroi des permissions.

Surveillance - Éléments à prendre en compte

La plateforme de zone d'atterrissage Azure fournit des ressources d'observabilité partagées dans le cadre des abonnements de gestion. Il est toutefois recommandé d'approvisionner vos propres ressources d'analyse afin de simplifier la gestion globale de la charge de travail. Pour plus d'informations, reportez-vous à Accélérateur de zone d'atterrissage Azure Spring Apps : contrôler les opérations.

Cette architecture crée les ressources suivantes :

• Azure Application Insights est le service d'analyse des performances des solutions des applications Application Performance Monitoring, (APM) et est entièrement intégré dans le service par le biais d'un agent Java. Cet agent fournit une visibilité sur toutes les applications déployées et les dépendances sans nécessiter de code supplémentaire.
• L'espace de travail Azure Log Analytics est le récepteur unifié de tous les enregistrements et mesures collectés à partir des services Azure et de l'application.

Configurez l'instance Azure Spring Apps pour qu'elle envoie les journaux de diagnostic de l'application à l'espace de travail Log Analytics approvisionné. Pour plus d’informations, consultez la sectionSurveiller les applications de bout en bout.

Collecter des journaux et des mesures pour d'autres services Azure. Les diagnostics de démarrage sont activés pour la jump box, de sorte que vous pouvez capturer des événements lorsque la machine virtuelle démarre.

Configurez les paramètres de diagnostic pour envoyer les journaux de toutes les autres ressources Azure vers un espace de travail Log Analytics. Les journaux de ressources ne sont pas collectés tant qu’ils ne sont pas routés vers une destination. Chaque ressource Azure requiert son propre paramètre de diagnostic.

Corrélation de données provenant de plusieurs espaces de travail

Les journaux d'activité et les mesures générés par la charge de travail et ses composants d'infrastructure sont enregistrés dans l'espace de travail Log Analytics de la charge de travail. Cependant, les journaux et les mesures générés par les services centralisés comme Active Directory et le Pare-feu Azure sont sauvegardés dans un espace de travail central de Log Analytics géré par les équipes de la plateforme. La mise en corrélation de données provenant de différents récepteurs peut s'avérer complexe.

Prenons le cas d'un flux d'utilisateurs dont la charge de travail a des dépendances sur des services centralisés. Une partie des données peut être collectée au niveau de la charge de travail et exportée vers l'espace de travail central Log Analytics où elle est mise en corrélation avec les journaux de la plateforme.

Cependant, d'autres entrées peuvent n'exister que dans l'espace de travail de la charge de travail pour des raisons de volume de données, d'interopérabilité des formats ou de contraintes de sécurité. Les enregistrements non corrélés qui existent dans deux espaces de travail ou plus pour un même flux d'utilisateurs peuvent rendre plus difficile la résolution de certains problèmes. Ces complexités supplémentaires obligent les équipes à travailler ensemble pour résoudre les incidents liés aux applications.

Familiarisez vous bien avec les procédures mises en place par votre organisation pour faciliter ce type de collaboration. En cas d'incident de sécurité, il peut être demandé aux administrateurs de la charge de travail d'examiner les enregistrements de leurs systèmes pour y déceler des signes d'activité malveillante ou de fournir des copies de leurs enregistrements aux gestionnaires d'incidents en vue d'une analyse plus approfondie. Lorsque les administrateurs de la charge de travail trouvent une résolution des problèmes d'application, ils peuvent avoir besoin de l'aide des administrateurs de la plateforme pour corréler les entrées d'enregistrement provenant du réseau de l'entreprise, de la sécurité ou d'autres services de la plateforme.

Sondes d’intégrité

Azure Application Gateway utilise des sondes d'intégrité pour s'assurer que le trafic entrant est acheminé vers des instances back-end réactives. Les sondes d'intégrité Azure Spring Apps Readiness, Liveness et Startup sont recommandées. En cas de défaillance, ces sondes d'intégrité peuvent aider à mettre fin à l'opération de manière gracieuse. Pour plus d’informations, consultez Comment configurer le décodeur de sonde d’intégrité.

Considérations relatives à la sécurité

Les équipes centralisées fournissent des contrôles de mise en réseau et d’identité dans le cadre de la plateforme. Cependant, la charge de travail doit présenter des caractéristiques de sécurité afin de réduire la surface d'attaque. Pour plus d'informations, reportez-vous à Accélérateur de zone d'atterrissage Azure Spring Apps : sécurité.

Données au repos

Les données au repos doivent être chiffrées. L'application elle-même est sans état. Toutes les données sont conservées dans une base de données externe. Cette architecture utilise Azure Database pour MySQL. Ce service crypte les données, y compris les sauvegardes et les fichiers temporaires créés lors de l'exécution des requêtes.

Données en transit

Les données en transit doivent être chiffrées. Le trafic entre le navigateur de l'utilisateur et Azure Application Gateway doit être crypté pour garantir que les données restent inchangées pendant le transit. Dans cette architecture, Azure Application Gateway n'accepte que le trafic HTTPS et négocie l'établissement d'une liaison TLS. Cette vérification est effectuée par le biais des règles NSG sur le sous-réseau de l'Application Gateway. Le certificat du protocole TLS est chargé directement lors du déploiement.

Le trafic entre l'Application Gateway et l'instance Azure Spring Apps est re-chiffré pour garantir que seul le trafic sécurisé atteint l'application. Le service runtime Azure Spring Apps reçoit ce trafic et agit en tant que point de terminaison TLS. À partir de là, les communications entre services à l'intérieur de l'application ne sont pas chiffrées. Cependant, la communication avec d'autres services Azure PaaS et le service runtime se fait via TLS.

Vous pouvez choisir de mettre en œuvre la communication TLS de bout en bout via Azure Spring Apps. Prenez en compte les compromis. Cela pourrait avoir un effet négatif sur la latence et les opérations.

Afin d'identifier les vulnérabilités, les données en transit doivent être contrôlées. Web Application Firewall est intégré à l'Application Gateway et permet d'inspecter le trafic en bloquant les vulnérabilités OWASP. Vous pouvez configurer Web Application Firewall web pour qu'il détecte, surveille et enregistre les alertes de menaces. Ou encore, vous pouvez configurer le service pour bloquer les intrusions et les attaques détectées par les règles.

Protection DDoS

Le refus de service distribué (DDoS) peut mettre hors service un système en le surchargeant de requêtes. La protection DDoS de base est activée au niveau de l'infrastructure pour tous les services Azure afin de se défendre contre de telles attaques. Envisagez une mise à niveau vers Azure DDoS Protection Service pour bénéficier de fonctionnalités comme l'analyse, les alertes et la possibilité de définir des ensembles de seuils pour l'application. Pour plus d’informations, consultez les questions fréquemment posées sur le service Azure DDoS Protection.

Gestion des secrets

L’approche de sécurité Zero Trust de Microsoft exige que les secrets, les certificats et les informations d’identification soient stockés dans un coffre sécurisé. Le service recommandé est Azure Key Vault.

En fonction du service Azure et de l'intention, il existe d'autres façons de stocker les secrets. Cette architecture met en œuvre l'approche suivante :

• Les certificats sont chargés lors du déploiement.
• La connexion à MySQL est réalisée à l'aide de Service Connector.

Stratégies d'optimisation des coûts

En raison de la nature de la conception des systèmes distribués, l’expansion de l’infrastructure est une réalité. Cette réalité se traduit par des coûts inattendus et incontrôlables. Azure Spring Apps est construit à l'aide de composants qui sont mis à l'échelle pour répondre à la demande et optimiser les coûts. Le fondement de cette architecture est le service Azure Kubernetes (AKS). Le service est conçu pour réduire la complexité et la surcharge opérationnelle de la gestion de Kubernetes et inclure des gains d'efficacité dans le coût opérationnel du cluster.

Vous pouvez déployer différentes applications et différents types d’applications sur une instance unique d’Azure Spring Apps. Le service prend en charge la mise à l’échelle automatique des applications déclenchées par des métriques ou des planifications qui peuvent améliorer l’utilisation et la rentabilité.

Vous pouvez également utiliser Application Insights et Azure Monitor pour réduire le coût d’exploitation. Grâce à la visibilité fournie par la solution complète de journalisation, vous pouvez implémenter l’automatisation pour mettre à l’échelle les composants du système en temps réel. Vous pouvez également analyser les données de journal pour révéler des inefficacités dans le code d’application que vous pouvez corriger pour améliorer le coût et les performances du système dans leur ensemble.

Déploiement de scénarios

Un déploiement de cette architecture de référence est disponible sur Azure Spring Apps Landing Zone Accelerator sur GitHub. Le déploiement utilise des modèles Terraform.

Les artefacts de ce référentiel fournissent une base que vous pouvez adapter à votre environnement. La mise en œuvre crée un réseau hub avec des ressources partagées comme le Pare-feu Azure à titre d'illustration. Ce regroupement peut être mappé à des abonnements distincts pour la zone d'atterrissage afin de séparer la charge de travail et les fonctions de la plate-forme.

Pour déployer l’architecture, suivez les instructions pas à pas.

Prise en charge de VMware avec le niveau Entreprise

Si vous souhaitez bénéficier d'une assistance VMware Tanzu® managée pour vos déploiements en direct, envisagez de passer au niveau Azure Spring Apps Entreprise. VMware Tanzu® Service Registry est intégré à Azure Spring Apps, ce qui permet la découverte et l'enregistrement de services.

Pour le routage de passerelle, vous pouvez opter pour VMware Spring Cloud Gateway. Celui-ci offre un ensemble de fonctionnalités comprenant l'authentification et l'autorisation, des fonctions de résilience et la limitation du débit.

Dans le niveau Entreprise, Application Configuration Service for Tanzu® permet de gérer les ressources ConfigMap natives de Kubernetes qui sont alimentées à partir des propriétés définies dans un ou plusieurs dépôts Git.

Ce niveau prend en charge d'autres services VMware. Pour plus d’informations, consultez Niveau Entreprise dans la Place de marché Azure.

L’implémentation de référence prend en charge la référence SKU Azure Spring Apps Enterprise comme option de déploiement. Dans cette option, il existe des modifications de l’architecture. Il utilise une instance du serveur flexible Azure Database pour PostgreSQL déployé avec l'intégration au réseau virtuel Azure, ainsi qu'Azure Cache pour Redis avec un point de terminaison privé. L’exemple d’application est l’application Fitness Store.

Étapes suivantes

• Une évaluation des zones de conception de l'accélérateur de la zone d'atterrissage d'Azure Spring Apps est nécessaire.

Ressources associées

Pour obtenir de la documentation sur les services Azure utilisés dans cette architecture, reportez-vous aux articles suivants :

• Azure Spring Apps Enterprise
• Azure Application Gateway v2
• Azure Database pour MySQL
• Azure Key Vault
• Réseau virtuel Azure
• Tables de routage

Pour d'autres scénarios de mise en œuvre, reportez-vous aux articles suivants :

• Déployer Azure Spring Apps dans plusieurs régions
• Exposer des applications Azure Spring Apps par le biais d’un proxy inverse