Déploiement d’entreprise avec Azure App Service Environment

Cette architecture de référence illustre une charge de travail d’entreprise courante qui utilise App Service Environment version 3. Il décrit également les meilleures pratiques pour renforcer la sécurité de la charge de travail.

Une implémentation de référence de cette architecture est disponible sur GitHub.

Architecture

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

Workflow

App Service Environment version 3 offre des fonctionnalités différentes des versions antérieures et des avantages par rapport à ces versions. Pour plus d’informations, voir Différences de fonctionnalités. Vous pouvez déployer App Service Environment de deux manières :

• En tant qu’App Service Environment externe avec une adresse IP publique
• En tant qu’App Service Environment interne avec une adresse IP interne qui appartient à l’équilibreur de charge interne (ILB)

Cette architecture de référence déploie une application web d’entreprise dans un App Service Environment interne, également appelé App Service Environment ILB. Utilisez un App Service Environment ILB lorsque votre scénario vous oblige à :

• Héberger des applications intranet avec une sécurité renforcée dans le cloud et y accéder via un VPN de site à site ou Azure ExpressRoute.
• Fournir une couche de protection pour les applications à l’aide d’un pare-feu d’applications web (WAF).
• héberger des applications dans le cloud qui ne figurent pas dans les serveurs DNS publics ;
• Créer des applications principales isolées d’Internet auxquelles vos applications frontales peuvent s’intégrer en toute sécurité.

Un App Service Environment doit toujours être déployé dans son propre sous-réseau au sein du réseau virtuel de l’entreprise pour permettre un contrôle étroit du trafic entrant et sortant. Au sein de ce sous-réseau, les applications App Service sont déployées dans un ou plusieurs plans App Service, qui est constitue un ensemble de ressources physiques nécessaires pour faire fonctionner l’application. En fonction de la complexité et des ressources nécessaires, un plan App Service peut être partagé entre plusieurs applications. Cette implémentation de référence déploie une application web nommée Voting App (application de vote), qui interagit avec une API web privée et une fonction. Elle déploie également une application web fictive appelée Test App pour illustrer les déploiements multi-applications. Chaque application App Service est hébergée dans son propre plan d’App Service, ce qui permet à chacune d’être mise à l’échelle indépendamment si nécessaire. Toutes les ressources requises par ces applications hébergées, telles que le stockage et le calcul, ainsi que les besoins de mise à l’échelle sont entièrement managés par l’infrastructure App Service Environment.

Dans cette implémentation, l’application de vote simple permet aux utilisateurs d’afficher les entrées existantes ou de créer de nouvelles entrées, ainsi que de voter sur les entrées existantes. L’API web est utilisée pour la création et la récupération des entrées et des votes. Les données elles-mêmes sont stockées dans une base de données SQL Server. Pour illustrer les mises à jour asynchrones de données, l’application web met en file d’attente les votes récemment ajoutés dans une instance Service Bus. La fonction récupère les votes mis en file d’attente et met à jour la base de données SQL. Azure Cosmos DB est utilisé pour stocker une publicité factice, que l’application web récupère pour l’afficher dans le navigateur. L’application utilise Azure Cache pour Redis dans le cadre de la gestion du cache. Azure Cache pour Redis de niveau Premium est utilisé, ce qui permet de configurer le même réseau virtuel que l’App Service Environment, dans son propre sous-réseau. Cela permet de renforcer la sécurité et l’isolement du cache.

Les applications web sont les seuls composants accessibles à Internet via Application Gateway. L’API et la fonction sont inaccessibles à partir d’un client Internet. Le trafic entrant est protégé par un pare-feu d’applications web configuré sur Application Gateway.

Composants

Les services suivants sont essentiels pour verrouiller l’App Service Environment dans cette architecture :

• Le réseau virtuel Azure est un réseau Azure cloud privé détenu par une entreprise. Il offre une sécurité et une isolation améliorées basées sur le réseau. App Service Environment est un déploiement App Service dans un sous-réseau du réseau virtuel appartenant à l’entreprise. Il permet à l’entreprise de contrôler étroitement cet espace réseau et les ressources auxquelles elle accède, en utilisant les groupes de sécurité réseau et les points de terminaison privés.

• Application Gateway est un équilibreur de charge du trafic web au niveau des applications, avec déchargement TLS/SSL et pare-feu d’applications web (WAF). Il écoute le trafic sur une adresse IP publique et achemine celui-ci vers le point de terminaison d’application dans l’environnement App Service Environment ILB. Comme il s’agit d’un routage au niveau de l’application, il peut acheminer le trafic vers plusieurs applications au sein du même environnement App Service Environment ILB. Pour plus d’informations, consultez Hébergement de plusieurs sites Application Gateway.

• Pare-feu Azure est utilisé pour restreindre le trafic sortant de l’application web. Le trafic sortant qui ne traverse pas les canaux de point de terminaison privé et une table de routage requise par l’App Service Environment est dirigé vers le sous-réseau de pare-feu. Par souci de simplicité, cette architecture configure tous les points de terminaison privés sur le sous-réseau des services.

• Microsoft Entra ID ou Microsoft Entra ID fournit la gestion des droits d’accès et des autorisations aux ressources et services Azure. Identités managées attribue des identités aux services et aux applications, qui sont gérés automatiquement par Microsoft Entra ID. Ces identités peuvent être utilisées pour s’authentifier auprès de n’importe quel service qui prend en charge l’authentification Microsoft Entra. Il n’est donc pas nécessaire de configurer explicitement les informations d’identification pour ces applications. Cette architecture attribue une identité managée à l’application web.

• Azure Key Vault stocke l’ensemble des clés secrètes et des informations d’identification requis par les applications. Utilisez cette option plutôt que de stocker les clés secrètes directement dans l’application.

• GitHub Actions fournit des fonctionnalités d’intégration continue et de déploiement continu dans cette architecture. App Service Environment se trouve dans le réseau virtuel. Une machine virtuelle doit donc être utilisée comme serveur de rebond dans le réseau virtuel pour déployer les applications dans les plans App Service. L’action génère les applications en dehors du réseau virtuel. Pour une sécurité renforcée et une connectivité RDP/SSH fluide, envisagez d’utiliser la nouvelle version d’Azure Bastion pour la jumpbox.

Configuration multisite

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

L’environnement App Service Environment interne peut héberger plusieurs applications web et API avec des points de terminaison HTTP. Ces applications sont inaccessibles depuis l’internet public car l’adresse IP ILB n’est accessible que depuis le Réseau virtuel Microsoft Azure. Application Gateway permet d’exposer sélectivement ces applications à l’internet. App Service Environment affecte une URL par défaut à chaque application App Service en tant que <default-appName>.<app-service-environment-domain>.appserviceenvironment.net. Une zone DNS privée est créée qui mappe le nom de domaine App Service Environment à l’adresse IP ILB App Service Environment. Cela évite d’utiliser un DNS personnalisé pour accéder aux applications au sein du réseau virtuel.

Application Gateway est configuré de telle sorte qu’un écouteur écoute sur le port HTTPS les demandes adressées à l’adresse IP de la passerelle. Par souci de simplicité, cette implémentation n’utilise pas d’inscription de nom DNS public. Il vous oblige à modifier le fichier localhost sur votre ordinateur pour pointer une URL choisie arbitrairement vers l’adresse IP Application Gateway. Par souci de simplicité, l’écouteur utilise un certificat auto-signé pour traiter ces requêtes. Application Gateway possède des pools principaux pour chaque URL par défaut de l’application App Service. Une règle d’acheminement est configurée pour connecter l’écouteur au pool principal. Des paramètres HTTP sont créés pour déterminer si la connexion entre la passerelle et l’environnement App Service Environment sera chiffrée. Ces paramètres sont également utilisés pour remplacer l’en-tête d’hôte HTTP entrant par un nom d’hôte choisi à partir du pool principal. Cette implémentation utilise des certificats par défaut créés pour les URL de l’application App Service Environment par défaut, qui sont approuvées par la passerelle. La requête est redirigée vers l’URL par défaut de l’application correspondante. Le DNS privé lié au réseau virtuel transmet cette requête à l’adresse IP ILB. App Service Environment le transfère ensuite au service d’application demandé. Toute communication HTTP au sein des applications de l’environnement App Service Environment passe par le DNS privé. Notez que l’écouteur, le pool principal, la règle d’acheminement et les paramètres HTTP doivent être configurés sur la passerelle applicative pour chaque application App Service Environment.

Passez en revue appgw.bicep et dns.bicep pour découvrir comment ces configurations sont effectuées pour autoriser plusieurs sites. L’application web nommée testapp est une application vide créée pour illustrer cette configuration. Ces fichiers JSON sont accessibles depuis le script de déploiement commands_std.azcli. Ils sont également accessibles par commands_ha.azcli, qui est utilisé pour un déploiement de App Service Environment multisite à haute disponibilité.

Détails du scénario

Azure App Service est un service PaaS utilisé pour héberger une variété d’applications sur Azure : applications web, applications API, fonctions et applications mobiles. App Service Environment permet aux entreprises de déployer leurs applications App Service dans un sous-réseau de leur propre réseau virtuel Azure, en fournissant un environnement isolé, hautement scalable et dédié pour leurs charges de travail dans le cloud.

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.

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é.

Environnement App Service

Un environnement App Service Environment interne est déployé dans le réseau virtuel de l’entreprise, caché de l’internet public. Il permet à l’entreprise de verrouiller ses services de base, tels que les API et les fonctions web, au niveau du réseau. Toute application App Service Environment avec un point de terminaison HTTP est accessible via l’ILB depuis le réseau virtuel. Application Gateway est configuré pour transmettre les requêtes à l’application web par l’intermédiaire de l’ILB. L’application web elle-même passe par l’ILB pour accéder à l’API. Les composants principaux critiques, c’est-à-dire l’API et la fonction, sont effectivement inaccessibles depuis l’Internet public.

Pour chaque App Service, des certificats par défaut définissent le nom de domaine par défaut attribué par App Service Environment. Ce certificat, qui peut être requis dans certains scénarios, permet de renforcer la sécurité du trafic entre la passerelle et l’application. Ces certificats ne sont pas visibles via le navigateur client. Il ne peut répondre qu’aux certificats configurés sur Application Gateway.

Application Gateway

L’implémentation de référence configure Application Gateway par programme dans le fichier appgw.bicep. Le fichier commands_std.azcli utilise cette configuration lors du déploiement de la passerelle :

az deployment group create --resource-group $RGNAME --template-file templates/appgw.bicep --parameters vnetName=$VNET_NAME appgwSubnetAddressPrefix=$APPGW_PREFIX appgwApplications=@appgwApps.parameters.json
APPGW_PUBLIC_IP=$(az deployment group show -g $RGNAME -n appgw --query properties.outputs.appGwPublicIpAddress.value -o tsv)

Chiffrement

Comme décrit dans Présentation de la terminaison TLS et du chiffrement TLS de bout en bout avec Application Gateway, Application Gateway peut utiliser le protocole Transport Layer Security (TLS)/Secure Sockets Layer (SSL) pour chiffrer et protéger tout le trafic des navigateurs web. Le chiffrement peut être configuré comme suit :

• Le chiffrement s’est terminé au niveau de la passerelle. Dans ce cas, les pools principaux sont configurés pour le protocole HTTP. Le chiffrement s’arrête au niveau de la passerelle et le trafic entre la passerelle et l’app service n’est pas chiffré. Le chiffrement étant gourmand en ressources processeur, le trafic non chiffré en arrière-plan améliore les performances et permet la gestion simplifiée des certificats. Cela offre un niveau de sécurité raisonnable puisque le backend est sécurisé en raison de la configuration du réseau.

• Chiffrement de bout en bout. Dans certains scénarios, comme les exigences spécifiques de sécurité ou de conformité, il peut être nécessaire de chiffrer le trafic entre la passerelle et l’application. Pour cela, vous devez utiliser une connexion HTTPS et configurer des certificats au niveau du pool principal.

Cette implémentation de référence utilise des certificats auto-signés pour Application Gateway. Pour le code de production, il convient d’utiliser un certificat délivré par une autorité de certification. Pour obtenir la liste des types de certificat pris en charge, consultez Certificats pris en charge pour un arrêt TLS. Consultez Configurer une passerelle d’application avec un arrêt TLS à l’aide du Portail Azure pour apprendre à créer un chiffrement avec terminaison Gateway. Les lignes de code suivantes de appgw.bicep permettent de configurer ce programme :

          httpListeners: [for item in appgwApplications: {
          name: '${appgwListenerName}${item.name}'
          properties: {
            frontendIPConfiguration: {
              id: '${appgwId}/frontendIPConfigurations/${appgwFrontendName}'
            }
            frontendPort: {
              id: '${appgwId}/frontendPorts/port_443'
            }
            protocol: 'Https'
            sslCertificate: {
              id: '${appgwId}/sslCertificates/${appgwSslCertificateName}${item.name}'
            }
            hostName: item.hostName
            requireServerNameIndication: true
          }
        }]

L’implémentation de référence illustre le chiffrement de bout en bout pour le trafic entre Application Gateway et les applications web sur le App Service Environment. Les certificats SSL par défaut sont utilisés. Les pools principaux de cette implémentation sont configurés pour rediriger le trafic HTTPS avec le nom d’hôte remplacé par les noms de domaine par défaut associés aux applications web. Application Gateway approuve les certificats SSL par défaut, car ils sont émis par Microsoft. Consultez Configurer App Service avec Application Gateway pour en savoir plus sur la façon dont ces configurations sont définies. Le code suivant de appgw.bicep montre comment cela est configuré dans l’implémentation de référence :

        backendHttpSettingsCollection: [for item in appgwApplications: {
        name: '${appgwHttpSettingsName}${item.name}'
        properties: {
          port: 443
          protocol: 'Https'
          cookieBasedAffinity: 'Disabled'
          pickHostNameFromBackendAddress: true
          requestTimeout: 20
          probe: {
            id: '${appgwId}/probes/${appgwHealthProbeName}${item.name}'
          }
        }
      }]

Pare-feu d’applications web

Le pare-feu d’applications Web (WAF) sur Application Gateway protège les applications web contre les attaques malveillantes, telles que l’injection SQL. Il est également intégré à Azure Monitor pour surveiller les attaques à l’aide d’un journal en temps réel. Le WAF doit être activé sur la passerelle, comme décrit dans Créer une passerelle d’application avec un pare-feu d’applications web à l’aide du Portail Azure. L’implémentation de référence permet de programmer le pare-feu d’applications web dans le fichier appgw.bicep avec l’extrait suivant :

        webApplicationFirewallConfiguration: {
        enabled: true
        firewallMode: 'Detection'
        ruleSetType: 'OWASP'
        ruleSetVersion: '3.0'
      }

Réseau virtuel

Les groupes de sécurité réseau peuvent être associés à un ou plusieurs sous-réseaux dans le réseau virtuel. Il s’agit de règles de sécurité qui autorisent ou interdisent le trafic entre les différentes ressources Azure. Cette architecture associe un groupe de sécurité réseau distinct pour chaque sous-réseau. Cela permet d’affiner ces règles par sous-réseau, en fonction du ou des services contenus dans ce sous-réseau. Par exemple, consultez la configuration de "type": "Microsoft.Network/networkSecurityGroups" dans le fichier ase.bicep pour le groupe de sécurité réseau pour le sous-réseau App Service Environment, et dans le fichier appgw.bicep pour le groupe de sécurité réseau pour le sous-réseau Application Gateway.

Les points de terminaison privés permettent une connectivité privée à sécurité renforcée entre les clients et les services Azure sur un réseau privé. Ils fournissent une adresse IP accessible en privé pour le service Azure, ce qui permet une sécurité renforcée du trafic vers une ressource Azure Private Link. La plateforme valide les connexions réseau, en autorisant uniquement celles qui se connectent à la ressource Private Link spécifiée. Les points de terminaison privés prennent en charge les stratégies réseau telles que les groupes de sécurité réseau, les itinéraires définis par l’utilisateur et les groupes de sécurité d’application. Pour améliorer la sécurité, vous devez activer les points de terminaison privés pour tout service Azure qui les prend en charge. Vous pouvez ensuite améliorer la sécurité du service dans le réseau virtuel en désactivant l’accès public, ce qui bloque efficacement tout accès à partir de l’Internet public. Cette architecture configure les points de terminaison privés pour les services qui la prennent en charge : Azure Service Bus, SQL Server, Key Vault et Azure Cosmos DB. Vous pouvez voir la configuration dans privatendpoints.bicep.

Pour activer les points de terminaison privés, vous devez également configurer des zones DNS privées. Pour plus d’informations, consultez Configuration DNS des points de terminaison privés Azure.

Pare-feu

Pare-feu Azure et les points de terminaison privés sont complémentaires. Les points de terminaison privés permettent de protéger les ressources en autorisant uniquement le trafic provenant de votre réseau virtuel. Pare-feu Azure vous permet de restreindre le trafic sortant de vos applications. Il est recommandé de laisser tout le trafic sortant traverser le sous-réseau de pare-feu, y compris le trafic de point de terminaison privé. Cela permet une meilleure analyse du trafic sortant. Par souci de simplicité, cette architecture de référence configure tous les points de terminaison privés sur le sous-réseau de service et non pas sur le sous-réseau du pare-feu.

Pour savoir comment Pare-feu Azure s’intègre à App Service Environment, consultez Configuration de Pare-feu Azure avec votre App Service Environment. Tout trafic qui ne passe pas par les points de terminaison privés et la table de routage de réseau virtuel est surveillé et contrôlé par le pare-feu.

Microsoft Entra ID

Microsoft Entra ID fournit des fonctionnalités de sécurité pour authentifier les applications et autoriser l’accès aux ressources. Cette architecture de référence utilise deux fonctionnalités clés de Microsoft Entra ID : les identités managées et le contrôle d’accès en fonction du rôle Azure.

Sur les applications cloud, les informations d’identification requises pour s’authentifier auprès des services cloud doivent être sécurisées. Idéalement, les informations d’identification ne doivent jamais s’afficher sur les stations de travail de développement ou ne sont jamais archivées dans le contrôle de code source. Azure Key Vault permet de stocker des informations d’identification et des clés secrètes de manière sécurisée. Toutefois, l’application doit s’authentifier auprès de Key Vault pour les récupérer. Les identités managées pour les ressources Azure fournissent aux services Azure une identité automatiquement gérée dans Microsoft Entra ID. Cette identité permet de vous authentifier sur n’importe quel service prenant en charge l’authentification Microsoft Entra, y compris Key Vault, sans avoir d’informations d’identification dans l’application.

Le contrôle d’accès en fonction du rôle Azure (RBAC Azure) gère l’accès aux ressources Azure. notamment :

• L’entité qui a l’accès : utilisateur, identité managée, principal de sécurité.
• Le type d’accès dont il dispose : propriétaire, contributeur, lecteur, administrateur.
• L’étendue de l’accès : ressource, groupe de ressources, abonnement ou groupe de gestion.

Vous pouvez verrouiller l’accès aux applications App Service Environment contrôlant étroitement le rôle requis et le type d’accès pour chaque application. De cette façon, plusieurs applications peuvent être déployées sur le même App Service Environment par différentes équipes de développement. Par exemple, le serveur frontal peut être géré par une équipe et le serveur principal par une autre. Vous pouvez utiliser la fonctionnalité RBAC Azure pour limiter l’accès de chaque équipe à la ou aux applications sur lesquelles elle travaille. Examinez les différents rôles personnalisés Azure pour créer des rôles adaptés à votre organisation.

Key Vault

Certains services prennent en charge les identités managées, mais ils utilisent RBAC Azure pour configurer des autorisations d’accès à l’application. Par exemple, examinez les rôles intégrés de Service Bus ainsi que RBAC Azure dans Azure Cosmos DB. L’accès Propriétaire à l’abonnement est nécessaire pour accorder ces autorisations même si le personnel disposant d’un accès Contributeur peut déployer ces services. Pour permettre à une équipe plus étendue de développeurs de pouvoir exécuter les scripts de déploiement, la meilleure option consiste à utiliser les stratégies de contrôle d’accès natives du service :

• Pour Service Bus, il s’agit des signatures d’accès partagé.
• Pour Azure Cosmos DB, il s’agit de clés.

Les chaînes de connexion pour ces stratégies de contrôle d’accès sont ensuite stockées dans Key Vault. Le coffre lui-même est accessible par des identités managées, ce qui nécessite RBAC Azure. Définissez la stratégie d’accès de ces chaînes de connexion de manière appropriée. Par exemple, en lecture seule pour le serveur principal, en écriture seule pour le serveur frontal, etc., au lieu d’utiliser la stratégie d’accès racine par défaut.

Le code suivant dans services.bicep montre la configuration Key Vault pour ces services :

      resource keyVaultName_CosmosKey 'Microsoft.KeyVault/vaults/secrets@2022-07-01' = {
      parent: keyVaultName
      name: 'CosmosKey'
      properties: {
        value: cosmosName.listKeys().primaryMasterKey 
      }
    }

      resource keyVaultName_ServiceBusListenerConnectionString 'Microsoft.KeyVault/vaults/secrets@2022-07-01' = {
      parent: keyVaultName
      name: 'ServiceBusListenerConnectionString'
      properties: {
        value: listKeys(serviceBusName_ListenerSharedAccessKey.id, '2021-11-01').primaryConnectionString
      }
    }

      resource keyVaultName_ServiceBusSenderConnectionString 'Microsoft.KeyVault/vaults/secrets@2022-07-01' = {
      parent: keyVaultName
      name: 'ServiceBusSenderConnectionString'
      properties: {
        value: listKeys(serviceBusName_SenderSharedAccessKey.id, '2021-11-01').primaryConnectionString
      }
    }

Ces valeurs de chaînes de connexion sont accessibles par les applications, qui se réfèrent à la paire clé/valeur du coffre de clés. Cette opération est effectuée dans le fichier sites.bicep, comme le montre le code suivant pour Voting App :

  properties: {
    enabled: true
    hostingEnvironmentProfile: {
      id:aseId
    }
    serverFarmId: votingWebPlanName.id
    siteConfig: {
      appSettings: [
        {
          name: 'ConnectionStrings:sbConnectionString'
          value: '@Microsoft.KeyVault(SecretUri=${reference(resourceId('Microsoft.KeyVault/vaults/secrets', keyVaultName, serviceBusSenderConnectionStringSecretName), '2022-07-01').secretUriWithVersion})'
        }
        {
          name: 'ConnectionStrings:RedisConnectionString'
          value: '@Microsoft.KeyVault(SecretUri=${reference(keyVaultName_redisSecretName.id, '2022-07-01').secretUriWithVersion})'
        }
        {
          name: 'ConnectionStrings:CosmosKey'
          value: '@Microsoft.KeyVault(SecretUri=${reference(resourceId('Microsoft.KeyVault/vaults/secrets', keyVaultName, cosmosKeySecretName), '2022-07-01').secretUriWithVersion})'
        }
      ]
    }
  }

La fonction accède également à la chaîne de connexion de l’écouteur Service Bus de la même manière.

Extensibilité

Concevoir des applications évolutives

L’application dans cette architecture de référence est structurée de manière à ce que les composants individuels puissent être mis à l’échelle en fonction de l’utilisation. Chaque application web, API et fonction est déployée dans son propre App Service. Vous pouvez surveiller chaque application pour détecter tout goulet d’étranglement au niveau des performances, puis la mettre à l’échelle si nécessaire.

Mise à l’échelle automatique d’Application Gateway

La mise à l’échelle automatique peut être activée sur Azure Application Gateway V2. Cela permet à Application Gateway d’augmenter ou de diminuer sa capacité en fonction des modèles de charge du trafic. Cette architecture de référence configure autoscaleConfiguration dans le fichier appgw.bicep pour mettre à l’échelle entre zéro et 10 instances supplémentaires. Consultez Mise à l’échelle d’Application Gateway et de WAF v2 pour plus de détails.

Déploiement

Les scripts de déploiement dans cette architecture de référence sont utilisés pour déployer App Service Environment, d’autres services et les applications à l’intérieur d’App Service Environment. Une fois ces applications déployées, les entreprises peuvent souhaiter disposer d’un plan d’intégration et de déploiement continus pour la maintenance et les mises à jour des applications. Cette section présente quelques-unes des méthodes couramment utilisées par les développeurs pour les applications CI/CD d’App Service Environment.

Les applications peuvent être déployées dans un App Service Environment interne uniquement à partir du réseau virtuel. Les trois méthodes suivantes sont largement utilisées pour déployer les applications App Service Environment :

• Manuellement à l’intérieur du réseau virtuel : créez une machine virtuelle à l’intérieur du réseau virtuel d’App Service Environment avec les outils nécessaires pour le déploiement. Ouvrez la connexion RDP à la VM en utilisant une configuration NSG. Copiez vos artefacts de code dans la machine virtuelle, construisez et déployez dans le sous-réseau App Service Environment. Il s’agit d’un moyen simple de configurer un environnement de développement et de test initial. Il n’est cependant pas recommandé pour les environnements de production car il ne peut pas augmenter le débit de déploiement requis.

• Connexion de point à site à partir du poste de travail local : cela vous permet d’étendre votre réseau virtuel App Service Environment à votre machine de développement et de déployer à partir de là. Il s’agit d’une autre façon de configurer un environnement de développement initial, qui n’est pas recommandée pour la production.

• À l’aide d’Azure Pipelines  : implémente un pipeline CI/CD complet, se terminant par un agent situé dans le réseau virtuel. Cela est idéal pour les environnements de production nécessitant un débit élevé de déploiement. Le pipeline de build reste entièrement à l’extérieur du réseau virtuel. Le pipeline de déploiement copie les objets générés sur l’agent de build à l’intérieur du réseau virtuel, puis effectue le déploiement sur le sous-réseau App Service Environment. Pour plus d’informations, lisez cette discussion sur l’agent de build autohébergé entre les pipelines et le réseau virtuel App Service Environment.

Azure Pipelines est recommandé pour les environnements de production. Le scriptage de CI/CD à l’aide du schéma YAML Azure Pipelines permet d’automatiser les processus de construction et de déploiement. Le script azure-pipelines.yml implémente un pipeline CI/CD pour l’application Web dans cette implémentation de référence. Il existe des scripts CI/CD similaires pour l’API web ainsi que pour la fonction. Lisez Utiliser Azure Pipelines pour savoir comment ces pipelines sont utilisés pour automatiser le processus CI/CD de chaque application.

Certaines entreprises ne souhaitent peut-être pas gérer un agent de build permanent dans le réseau virtuel. Si c’est le cas, vous pouvez choisir de créer un agent de build dans le pipeline DevOps et le détacher une fois le déploiement terminé. Cela ajoute une autre étape au DevOps, mais réduit la complexité de la gestion de la machine virtuelle. Vous pouvez même envisager d’utiliser des conteneurs en tant qu’agents de build au lieu de machines virtuelles. Il est également possible d’éviter complètement les agents de build en les déployant à partir d’un fichier compressé placé en dehors du réseau virtuel, généralement dans un compte de stockage. Le compte de stockage doit être accessible à partir de l’App Service Environment. Le pipeline doit être en mesure d’accéder au stockage. À la fin du pipeline de mise en production, un fichier compressé peut être déplacé dans le stockage d’objets blob. L’App Service Environment peut ensuite le récupérer et le déployer. Tenez compte des limitations suivantes de cette approche :

• Il existe une déconnexion entre le DevOps et le processus de déploiement réel, ce qui complique la surveillance et le suivi des problèmes de déploiement.
• Dans un environnement verrouillé avec un trafic sécurisé, vous devrez peut-être modifier les règles pour accéder au fichier compressé sur le stockage.
• Vous devrez installer des extensions et des outils spécifiques sur l’App Service Environment pour pouvoir le déployer à partir du fichier compressé.

Pour en savoir plus sur la façon dont les applications peuvent être déployées dans les plans App Service, lisez les articles de l’App Service portant sur les stratégies de déploiement.

Optimisation des coûts

Utiliser la calculatrice de prix Azure pour estimer les coûts. D'autres considérations sont décrites dans la section Coûts de Microsoft Azure Well-Architected Framework. Les réservations Azure vous permettent d’économiser en vous engageant sur des plans d’un ou trois ans pour de nombreuses ressources Azure. Pour en savoir plus, consultez l’article Acheter une réservation.

Voici quelques points à prendre en compte pour certains des services de clés utilisés dans cette architecture.

App Service Environment v3

Il existe plusieurs options de tarification pour App Service. Un App Service Environment est déployé à l’aide de l’App Service Isolé v2. Dans ce plan, il existe plusieurs options pour les tailles de processeur, de I1v2 à I6v2. Cette implémentation de référence utilise trois I1v2 par instance.

Application Gateway

La tarification d’Application Gateway offre diverses options de tarification. Cette implémentation utilise Application Gateway Standard v2 et la référence SKU WAF v2, qui prend en charge la mise à l’échelle automatique et la redondance de zone. Pour plus d’informations sur le modèle tarifaire utilisé pour cette référence SKU, consultez Mise à l’échelle d’Application Gateway v2 et WAF v2.

Cache Azure pour Redis

La section Tarification Azure Cache pour Redis fournit les différentes options de tarification pour ce service. Cette architecture utilise la référence SKU Premium pour la prise en charge du réseau virtuel.

Voici des pages de tarification pour d’autres services utilisés pour verrouiller l’App Service Environment :

• Tarification de Pare-feu Azure

• Tarification de Key Vault

• Tarifs Microsoft Entra

Déployer ce scénario

Pour déployer l’implémentation de référence pour cette architecture, consultez le fichier readme de GitHub et suivez le script pour les déploiements standard.

Contributeurs

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

Auteur principal :

• Dhanashri Kshirsagar | Senior Content PM

Autres contributeurs :

• Deep Bhattacharya | Architecte de solutions cloud
• Suhas Rao | Architecte de solutions cloud

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

Étapes suivantes

• Exécuter votre application dans Azure App Service directement à partir d’un package ZIP
• Schéma YAML d’Azure Pipelines
• Récupérer les adresses de gestion avec l’API
• Azure Key Vault
• Azure Pipelines

Ressources associées

Pour savoir comment étendre cette architecture afin de prendre en charge la haute disponibilité, consultez Déploiement d’applications haute disponibilité à l’aide d’ASE.