Modifier

Partager via

Déployer une application métier en utilisant Azure App Service Environment v3

Azure App Service
Azure DNS
Azure Monitor
Azure Log Analytics
Azure Key Vault

Pour les clients soumis à une gouvernance et des restrictions fortes liées à la conformité, il est important d’avoir un environnement isolé et dédié, en particulier pour les applications métier. Si la sécurité figure au premier plan, ces applications critiques nécessitent aussi la possibilité d’être mises à l’échelle et de fonctionner dans des scénarios avec une utilisation élevée de la mémoire ou un grand nombre de requêtes par seconde. Cette solution fournit un exemple de la façon dont vous pouvez héberger des applications métier. Vous pouvez utiliser l’environnement App Service pour garantir que la sécurité et les performances sont abordées simultanément. Lors du déploiement de cette solution, vous avez la possibilité d’utiliser des ressources existantes dans votre zone d’atterrissage Azure, qui représente vos ressources dans le réseau virtuel « Hub ». Vous pouvez aussi déployer cette solution en tant que charge de travail autonome.

Remarque

Cet article fournit une architecture déployable qui s’aligne sur les instructions du Cloud Adoption Framework pour App Service dans les zones d’atterrissage Azure.

Architecture

Diagramme montrant l’architecture du déploiement App Service Environment v3.

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

Workflow

Il existe trois flux avec des légendes dans cette architecture : Opérations (orange), Déploiement (vert) et Utilisateur (violet).

Operations

  1. Les opérateurs ou administrateurs souhaiteront effectuer des tâches d’administration sur le serveur d’intégration continue/déploiement continu (CI/CD) ou sur le point de terminaison Kudu pour l’environnement App Service. Tout d’abord, ils devront se connecter à l’hôte Azure Bastion.
  2. En utilisant l’hôte Azure Bastion, l’opérateur ou l’administrateur peut ensuite utiliser le protocole de bureau à distance (RDP) pour accéder au serveur jumpbox.
  3. À partir du serveur jumpbox, l’opérateur ou l’administrateur peut se connecter au serveur CI/CD via RDP et effectuer les tâches nécessaires, comme les mises à niveau de l’agent, les mises à niveau du système d’exploitation, etc. L’opérateur ou l’administrateur peut également se connecter depuis le serveur jumpbox au point de terminaison Kudu de l’instance App Service Environment, pour effectuer des tâches administratives ou un dépannage avancé.

Déploiement

  1. Le déploiement de la solution est effectué via le serveur de l’agent CI/CD. L’agent DevOps sur ce serveur va se connecter à Azure Pipelines lors de l’exécution d’un nouveau déploiement.
  2. Les artefacts seront ensuite déployés sur le service d’application en se connectant à l’App Service Environment via l’appairage de réseaux virtuels (peering).

Utilisateur

  1. Les utilisateurs peuvent se connecter au service App Service déployé sur le réseau de l’entreprise. Ils peuvent utiliser Azure ExpressRoute ou un VPN si nécessaire, et/ou sur n’importe quel appairage de réseaux virtuels Azure applicable.

Composants

La solution utilise les services Azure suivants :

  • Azure App Service Environment v3 (ASEv3) est une fonctionnalité d’Azure App Service, et est un service monolocataire pour les clients qui nécessitent un système à grande échelle, un isolement réseau, une sécurité et/ou une utilisation élevée de la mémoire. Les applications sont hébergées dans des plans App Service qui sont créés dans l’App Service Environment v3, avec des options d’utilisation de différents niveaux dans un plan de service Isolated V2. Comparé à une version antérieure de l’App Service Environment, de nombreuses améliorations ont été apportées, notamment, mais sans s’y limiter, la dépendance au réseau, le temps de mise à l’échelle et la suppression des frais de timbre. Cette solution utilise App Service Environment v3 configuré pour l’accès interne.

  • Azure Private DNS vous permet de gérer et de résoudre les noms de domaine dans un réseau virtuel, sans qu’il soit nécessaire d’ajouter une solution DNS personnalisée. Une zone Azure Private DNS peut être alignée sur un ou plusieurs réseaux virtuels via des liaisons de réseau virtuel. En raison de la nature interne de l’App Service Environment v3 utilisée dans cette architecture de référence, une zone DNS privée est nécessaire pour résoudre les noms de domaine des applications hébergées sur l’App Service Environment.

  • Azure Application Insights est une fonctionnalité d’Azure Monitor qui permet aux développeurs de détecter les anomalies, de diagnostiquer les problèmes et de comprendre les modèles d’utilisation. Application Insights offre une gestion et une supervision extensibles des performances des applications pour les applications web en production. Différentes plateformes sont prises en charge, y compris .NET, Node.js, Java et Python. Les applications hébergées dans Azure, localement, dans un environnement hybride ou dans d’autres clouds publics sont prises en charge. Application Insights est incluse dans cette architecture de référence pour superviser les comportements de l’application déployée.

  • Azure Log Analytics est une fonctionnalité d’Azure Monitor qui vous permet de modifier et d’exécuter des requêtes de journal avec des données dans les journaux Azure Monitor, éventuellement à partir du portail Azure. Les développeurs peuvent exécuter des requêtes simples sur un ensemble d’enregistrements ou utiliser Log Analytics pour effectuer une analyse avancée. Ils peuvent ensuite visualiser les résultats. Log Analytics est configuré dans le cadre de cette architecture de référence pour agréger tous les journaux de supervision à des fins d’analyse et de production de rapports.

  • Machines virtuelles Azure est une ressource informatique évolutive à la demande qui peut être utilisée pour héberger plusieurs charges de travail différentes. Dans cette architecture de référence, les machines virtuelles sont utilisées pour fournir un serveur jumpbox de gestion, et un hôte pour l’agent DevOps ou l’exécuteur GitHub.

  • Azure Key Vault est un service cloud qui stocke et accède de façon sécurisée à des secrets, qui peuvent aller de clés d’API et de mots de passe à des certificats et des clés de chiffrement. Un coffre de clés Azure est déployé dans le cadre de l’infrastructure de cette architecture pour faciliter la gestion des secrets pour les déploiements de code futurs.

  • Azure Bastion est une plateforme en tant que service (PaaS) provisionnée dans le réseau virtuel des développeurs. Il fournit une connectivité RDP/SSH sécurisée aux machines virtuelles des développeurs sur TLS, à partir du portail Azure. Avec Azure Bastion, les machines virtuelles n’ont plus besoin d’une adresse IP publique pour se connecter via RDP/SSH. Cette architecture de référence utilise Azure Bastion pour accéder au serveur de l’agent DevOps ou de l’exécuteur GitHub, ou au serveur jumpbox de gestion.

Autres solutions

Envisagez d’ajouter une passerelle Azure Application Gateway avant l’instance App Service, afin de fournir des fonctionnalités de pare-feu d’applications web pour protéger les applications web contre les attaques et vulnérabilités courantes.

Un exécuteur GitHub auto-hébergé peut être utilisé à la place de l’agent auto-hébergé Azure DevOps.

Considérations

Ces considérations implémentent les piliers d’Azure Well-Architected Framework qui est un ensemble de principes directeurs qui permettent d’améliorer la qualité d’une charge de travail. Pour plus d’informations, consultez Microsoft Azure Well-Architected Framework.

Fiabilité

La fiabilité permet de s’assurer que votre application tient vos engagements auprès de vos clients. Pour plus d’informations, consultez la page Vue d’ensemble du pilier de fiabilité.

  • Tenez compte de vos besoins en matière de redondance de zone dans cette implémentation de référence ainsi que des fonctionnalités de redondance de zone des autres services Azure dans votre solution. L’App Service Environment v3 prend en charge la redondance de zone en répartissant les instances dans les trois zones de la région cible. Cette configuration ne peut être définie qu’au moment de la création de l’App Service Environment et elle peut ne pas être disponible dans toutes les régions. Pour plus d’informations, consultez Prise en charge des zones de disponibilité pour App Service Environment. Cette implémentation de référence implémente la redondance de zone, mais vous pouvez la modifier en clonant ce dépôt et en définissant la propriété zoneRedundant sur false.

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 plus d’informations, consultez Vue d’ensemble du pilier Sécurité.

  • Utilisez les restrictions d’accès appropriées afin que le service App Service soit accessible seulement depuis des emplacements valides. Par exemple, si le service d’application héberge des API et qu’il est piloté par APIM, vous pouvez configurer une restriction d’accès afin que le service d’application soit accessible seulement depuis APIM.
  • Étant donné que cette implémentation de référence déploie un App Service Environment dans un réseau virtuel (appelé App Service Environment interne), toutes les applications déployées dans l’App Service Environment sont intrinsèquement isolées du réseau, à l’échelle du réseau virtuel.
  • Stockez les secrets d’application (informations d’identification de base de données, jetons d’API et clés privées) dans Azure Key Vault. Configurez votre application App Service pour y accéder de façon sécurisée avec une identité managée. Déterminez quand utiliser Azure Key Vault ou Azure App Configuration.

Optimisation des coûts

L’optimisation des coûts consiste à examiner les moyens de réduire les dépenses inutiles et d’améliorer l’efficacité opérationnelle. Pour plus d’informations, consultez Vue d’ensemble du pilier d’optimisation des coûts.

  • Bien qu’il n’y ait pas de frais de timbre pour une instance App Service Environment v3, des frais sont facturés lorsqu’aucun plan App Service n’est configuré au sein de l’instance App Service Environment v3. Ces frais sont facturés au même taux qu’une instance Windows I1v2 pour la région dans laquelle l’instance App Service Environment v3 est déployée.
  • Quand il est configuré pour être redondant interzone, le modèle de facturation est ajusté pour tenir compte de l’infrastructure sous-jacente déployée dans cette configuration. Vous pouvez être redevable pour des instances supplémentaires, conformément aux tarifs d’ASEv3.
  • Pour les plans App Service v3 d’App Service Environment (connus sous le nom de plans App Service Isolated V2), utilisez les Réservations Azure et le plan d’économies Azure pour calcul avec un contrat d’un an ou de trois ans et bénéficiez d’économies significatives par rapport aux prix à la consommation. Pour plus d’informations, consultez Comment les remises de réservation s’appliquent aux instances Isolé v2.

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 Vue d’ensemble du pilier Excellence opérationnelle.

  • Utilisez Application Insights ou une autre solution de gestion des performances des applications pour superviser et découvrir comment votre application se comporte dans différents environnements.
    • Il existe deux façons d’activer Application Insights. Pour les différents environnements, collectez les données de télémétrie dans des instances différentes d’Application Insights.
    • Si votre application a plusieurs composants séparés en différents services, vous pouvez examiner leur comportement quand ils fonctionnent ensemble. Collectez leurs données de télémétrie dans la même instance Application Insights, mais étiquetez-les avec des noms de rôles cloud différents.
    • Exportez les données Application Insights dans un espace de travail Azure Log Analytics. Nous vous recommandons d’utiliser un même espace de travail pour l’organisation.
    • Incluez des tableaux de bord opérationnels dans la conception des applications et des fonctionnalités pour être sûr que la solution peut être prise en charge en production.
    • Implémentez des vérifications d’intégrité pour vos points de terminaison, puis utilisez-les pour les sondes d’intégrité, les vérifications de dépendance et les tests de disponibilité.
  • Envisagez d’utiliser des préfixes et des suffixes avec des conventions bien définies pour identifier de façon univoque chaque ressource déployée. Ces conventions de nommage évitent les conflits quand vous déployez des solutions les unes à côté des autres, et améliorent l’agilité et la productivité globales de l’équipe.
  • Selon la configuration réseau, App Service peut ne pas être accessible depuis l’Internet public, et l’utilisation d’agents hébergés publics ne fonctionnera pas pour les déploiements. Dans ce scénario, utilisez des agents auto-hébergés.

Déployer ce scénario

Pour commencer et pour mieux comprendre les spécificités de cette implémentation, passez en revue les ressources d’implémentation de référence, dans le Guide de l’utilisateur pour le déploiement de l’implémentation de référence.

  • Nous vous recommandons de cloner ce dépôt et de modifier les ressources d’implémentation de référence en fonction de vos besoins et des instructions spécifiques pour la zone d’atterrissage de votre organisation.
  • Avant de déployer, vérifiez que le principal de service utilisé pour déployer la solution dispose des autorisations nécessaires pour créer les types de ressources que nous avons listés ci-dessus.
  • Prenez en compte le service CI/CD que vous utiliserez pour déployer l’implémentation de référence. Comme cette implémentation de référence est un App Service Environment interne, vous aurez besoin d’un agent auto-hébergé pour exécuter les pipelines de déploiement. Vous avez le choix entre utiliser un agent DevOps et un exécuteur GitHub. Reportez-vous au guide de l’utilisateur sur les valeurs de configuration spécifiques requises.
  • Considérez les régions dans lesquelles vous envisagez de déployer cette implémentation de référence. Consultez la liste des régions ASEv3 pour vous assurer que les régions sélectionnées sont activées pour le déploiement.

Contributeurs

Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.

Auteurs principaux :

Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.

Étapes suivantes

En savoir plus sur ces services clés :