Partager via

Créer un ASE à l’aide d’un modèle Azure Resource Manager

  • Article

Vue d’ensemble

Important

Cet article concerne la fonctionnalité App Service Environment v2, qui est utilisée avec les plans App Service isolés. App Service Environment v1 et v2 ont été mis hors service le 31 août 2024. Il existe une nouvelle version d’App Service Environment, plus facile à utiliser et qui s’exécute sur des infrastructures plus puissantes. Pour en savoir plus sur la nouvelle version, commencez par consulter Présentation de l’environnement App Service Environment. Si vous utilisez actuellement App Service Environment v1, suivez les étapes de cet article pour migrer vers la nouvelle version.

À compter du 31 août 2024, le Contrat de niveau de service (SLA) et les crédits de service ne s’appliquent plus aux charges de travail App Service Environment v1 et v2 qui sont toujours en production depuis que ce sont des produits mis hors service. La mise hors service du matériel App Service Environment v1 et v2 a commencé, ce qui risque d’avoir une incidence sur la disponibilité et les performances de vos applications et de vos données.

Vous devez effectuer la migration vers App Service Environment v3 immédiatement, sans quoi vos applications et ressources risquent d’être supprimées. Nous ferons tout notre possible pour migrer automatiquement les charges de travail App Service v1 et v2 restantes à l’aide de la fonctionnalité de migration sur place, mais Microsoft ne garantit nullement ni n’affirme que les applications seront disponibles après la migration automatique. Vous serez peut-être amené à effectuer une configuration manuelle pour finaliser la migration et choisir la référence SKU du plan App Service la mieux adaptée à vos besoins. Si la migration automatique n’est pas possible, vos ressources et les données d’application associées seront supprimées. Nous vous recommandons vivement d’agir dès maintenant pour éviter l’un ou l’autre de ces scénarios extrêmes.

Si vous avez besoin de plus de temps, nous pouvons offrir une seule période de grâce de 30 jours pour vous permettre d’effectuer votre migration. Pour plus d’informations et pour demander cette période de grâce, passez en revue la vue d’ensemble de la période de grâce, puis accédez au portail Azure et au panneau Migration pour chacun de vos environnements App Service.

Pour obtenir les informations les plus à jour sur la mise hors service d’App Service Environment v1/v2, consultez la Mise à jour sur la mise hors service d’App Service Environment v1 et v2.

Les environnements Azure App Service (ASE, App Service Environment) peuvent être créés avec un point de terminaison accessible via Internet ou un point de terminaison sur une adresse interne d’un réseau virtuel Azure. S’il est créé avec un point de terminaison interne, ce point de terminaison est fourni par un composant Azure appelé équilibreur de charge interne (ILB, Internal Load Balancer). Un ASE sur une adresse IP interne est appelé ASE ILB. Un ASE avec un point de terminaison public est appelé ASE externe.

Un ASE peut être créé à l’aide du portail Azure ou d’un modèle Azure Resource Manager. Cet article décrit les étapes et la syntaxe nécessaires pour créer un ASE externe ou un ASE ILB à l’aide de modèles Resource Manager. Pour savoir comment créer un ASEv2 dans le portail Azure, consultez [Créer un ASE externe][MakeExternalASE] ou Créer un ASE ILB.

Lorsque vous créez un environnement ASE dans le portail Azure, vous pouvez créer votre réseau virtuel en même temps ou choisir un réseau virtuel préexistant sur lequel le déployer.

Lorsque vous créez un ASE à partir d’un modèle, vous devez commencer avec :

  • Un réseau virtuel Azure.
  • Un sous-réseau dans ce réseau virtuel. Pour le sous-réseau ASE, nous recommandons une taille de /24 avec 256 adresses pour s’adapter à une croissance et une mise à l’échelle futures. Une fois l’ASE créé, vous ne pouvez plus en modifier la taille.
  • L’abonnement vers lequel vous souhaitez procéder au déploiement.
  • L’emplacement dans lequel vous souhaitez procéder au déploiement.

Pour automatiser la création de votre environnement ASE, suivez les instructions fournies dans les sections suivantes. Si vous créez un environnement ASE ILB v2 avec une valeur dnsSuffix personnalisée (par exemple, internal.contoso.com), il reste quelques étapes à accomplir.

  1. Une fois l’environnement créé, un certificat TLS/SSL correspondant à votre domaine ASE à équilibreur de charge interne doit être chargé.

  2. Le certificat TLS/SSL chargé est explicitement attribué à l’ASE ILB en tant que certificat TLS/SSL « par défaut ». Ce certificat est utilisé pour le trafic TLS/SSL vers les applications de l’ASE ILB quand celles-ci utilisent le domaine racine commun assigné à l’ASE (par exemple, https://someapp.internal.contoso.com).

Créer l’ASE

Un modèle Resource Manager qui crée un environnement ASE et le fichier de paramètres associé est disponible sur GitHub pour ASE v2.

Si vous souhaitez créer un environnement ASE, utilisez cet exemple de modèle Resource Manager ASE v2. La plupart des paramètres définis dans le fichier azuredeploy.parameters.json sont communs à la création des ASE ILB et des ASE externes. Dans la liste suivante figurent les paramètres notables ou uniques, en lien avec la création d’un environnement ASE ILB avec un sous-réseau existant.

Paramètres

  • aseName : ce paramètre définit un nom d’environnement ASE unique.
  • location : ce paramètre définit l’emplacement de l’environnement ASE.
  • existingVirtualNetworkName : ce paramètre définit le nom de réseau virtuel du réseau virtuel et du sous-réseau existants dans lesquels l’environnement ASE résidera.
  • existingVirtualNetworkResourceGroup : ce paramètre définit le nom de groupe de ressources du réseau virtuel et du sous-réseau existants dans lesquels l’environnement ASE résidera.
  • subnetName : ce paramètre définit le nom de sous-réseau du réseau virtuel et du sous-réseau existants dans lesquels l’environnement ASE résidera.
  • internalLoadBalancingMode : dans la plupart des cas, définissez ce paramètre sur 3, ce qui signifie que le trafic HTTP/HTTPS sur les ports 80/443 ainsi que les ports de canaux de contrôle/données écoutés par le service FTP sur l’ASE seront liés à une adresse interne du réseau virtuel allouée à l’ILB. Si ce paramètre est défini sur 2, seuls les ports associés au service FTP (canaux de contrôle et de données) sont liés à une adresse d’ILB. Si cette propriété a la valeur 0, le trafic HTTP/HTTPS reste sur l’adresse IP virtuelle publique.
  • dnsSuffix : ce paramètre définit le domaine racine par défaut affecté à l’ASE. Dans la version publique d’Azure App Service, le domaine racine par défaut pour toutes les applications web est azurewebsites.net. Étant donné qu’un ASE ILB est interne au réseau virtuel d’un client, il n’est pas pertinent d’utiliser le domaine racine par défaut du service public. Au lieu de cela, un ILB ASE doit avoir un domaine racine par défaut approprié pour une utilisation au sein du réseau virtuel interne d’une société. Par exemple, une société nommée Contoso Corporation peut utiliser le domaine racine par défaut internal.contoso.com pour les applications destinées à être résolues et accessibles uniquement au sein du réseau virtuel de Contoso. Pour indiquer un domaine racine personnalisé, vous devez utiliser la version 2018-11-01 de l’API ou des versions antérieures.
  • ipSslAddressCount : ce paramètre est automatiquement défini par défaut sur la valeur 0 dans le fichier azuredeploy.json, car les ASE ILB disposent d’une seule adresse d’ILB. Il n’existe pas d’adresse IP SSL explicite pour un ASE ILB. Par conséquent, le pool d’adresses IP SSL pour un ASE ILB doit être défini sur zéro. Autrement, une erreur d’approvisionnement se produit.

Une fois le fichier azuredeploy.parameters.json complété, créez l’ASE à l’aide de l’extrait de code PowerShell. Modifiez les chemins d’accès des fichiers de façon à ce qu’ils correspondent aux emplacements des fichiers du modèle Resource Manager sur votre ordinateur. Songez à indiquer vos propres valeurs pour les noms de déploiement Resource Manager et de groupe de ressources :

$templatePath="PATH\azuredeploy.json"
$parameterPath="PATH\azuredeploy.parameters.json"

New-AzResourceGroupDeployment -Name "CHANGEME" -ResourceGroupName "YOUR-RG-NAME-HERE" -TemplateFile $templatePath -TemplateParameterFile $parameterPath

La création de l’environnement ASE prend environ deux heures. Ensuite, l’ASE apparaît sur le portail dans la liste des ASE pour l’abonnement qui a déclenché le déploiement.

Charger et configurer le certificat TLS/SSL « par défaut »

Un certificat TLS/SSL doit être associé à l’ASE en tant que certificat TLS/SSL « par défaut » utilisé pour établir les connexions TLS aux applications. Si le suffixe DNS par défaut d’ASE est internal.contoso.com, une connexion à https://some-random-app.internal.contoso.com nécessite un certificat TLS/SSL valide pour *.internal.contoso.com.

Vous pouvez vous procurer un certificat TLS/SSL valide auprès d’autorités de certification internes, en achetant un certificat à un émetteur externe ou en utilisant un certificat autosigné. Quelle que soit la source du certificat TLS/SSL, les attributs de certificat suivants doivent être configurés correctement :

  • Objet : cet attribut doit être défini sur * .votre-domaine-racine-ici.com.
  • Autre nom de l’objet : cet attribut doit inclure à la fois *.votre-domaine-racine-ici.com et *.scm.votre-domaine-racine-ici.com*. Les connexions TLS au site GCL/Kudu associé à chaque application utilisent une adresse au format nom-de-votre-application.scm.votre-domaine-racine-ici.com.

Une fois un certificat TLS/SSL valide à disposition, deux étapes préparatoires supplémentaires sont nécessaires. Convertissez/enregistrez le certificat TLS/SSL en tant que fichier .pfx. N’oubliez pas que le fichier .pfx doit inclure tous les certificats racines et intermédiaires. Sécurisez-le avec un mot de passe.

Le fichier .pfx doit être converti en chaîne base64, car le certificat TLS/SSL est chargé à l’aide d’un modèle Resource Manager. Étant donné que les modèles Resource Manager sont des fichiers texte, le fichier .pfx doit être converti en chaîne base64. Ainsi, il peut être inclus en tant que paramètre du modèle.

Utilisez l’extrait de code PowerShell ci-dessous pour effectuer les opérations suivantes :

  • générer un certificat auto-signé ;
  • exporter le certificat dans un fichier .pfx ;
  • convertir le fichier .pfx en une chaîne codée en base64 ;
  • enregistrer la chaîne codée en base64 dans un fichier distinct.

Le code PowerShell pour l’encodage en base64 à été adapté à partir du Blog relatif aux scripts PowerShell :

$certificate = New-SelfSignedCertificate -certstorelocation cert:\localmachine\my -dnsname "*.internal.contoso.com","*.scm.internal.contoso.com"

$certThumbprint = "cert:\localMachine\my\" + $certificate.Thumbprint
$password = ConvertTo-SecureString -String "CHANGETHISPASSWORD" -Force -AsPlainText

$fileName = "exportedcert.pfx"
Export-PfxCertificate -cert $certThumbprint -FilePath $fileName -Password $password     

$fileContentBytes = get-content -encoding byte $fileName
$fileContentEncoded = [System.Convert]::ToBase64String($fileContentBytes)
$fileContentEncoded | set-content ($fileName + ".b64")

Une fois le certificat TLS/SSL généré et converti en chaîne codée en base64, utilisez l’exemple de modèle Resource Manager Configurer le certificat SSL par défaut disponible sur GitHub.

Les paramètres figurant dans le fichier azuredeploy.parameters.json sont répertoriés ci-dessous :

  • appServiceEnvironmentName : nom de l'ILB ASE configuré.
  • existingAseLocation : chaîne de texte contenant la région Azure où l'ILB ASE a été déployé. Par exemple : « USA Centre Sud ».
  • pfxBlobString : représentation sous forme de chaîne codée en Base64 du fichier .pfx. Utilisez l’extrait de code présenté précédemment, et copiez la chaîne contenue dans « exportedcert.pfx.b64 ». Collez celle-ci en tant que valeur de l’attribut pfxBlobString.
  • mot de passe : mot de passe utilisé pour sécuriser le fichier .pfx.
  • certificateThumbprint : empreinte numérique du certificat. Si vous récupérez cette valeur à partir de Powershell (par exemple, $certificate.Thumbprint dans l’extrait de code précédent), vous pouvez utiliser la valeur telle quelle. Si vous copiez la valeur à partir de la boîte de dialogue du certificat Windows, n’oubliez pas de retirer les espaces superflus. La valeur de certificateThumbprint doit se présenter sous la forme suivante : AF3143EB61D43F6727842115BB7F17BBCECAECAE.
  • certificateName : identificateur de chaîne convivial de votre choix permettant d'identifier le certificat. Ce nom fait partie de l’identificateur Resource Manager unique pour l’entité Microsoft.Web/certificates qui représente le certificat TLS/SSL. Le nom doit finir par le suffixe suivant : _yourASENameHere_InternalLoadBalancingASE. Le portail Azure utilise ce suffixe en tant qu’indicateur signalant que le certificat est utilisé pour sécuriser ASE avec ILB.

Un exemple abrégé du fichier azuredeploy.parameters.json est présenté ici :

{
  "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentParameters.json",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "appServiceEnvironmentName": {
      "value": "yourASENameHere"
    },
    "existingAseLocation": {
      "value": "East US 2"
    },
    "pfxBlobString": {
      "value": "MIIKcAIBAz...snip...snip...pkCAgfQ"
    },
    "password": {
      "value": "PASSWORDGOESHERE"
    },
    "certificateThumbprint": {
      "value": "AF3143EB61D43F6727842115BB7F17BBCECAECAE"
    },
    "certificateName": {
      "value": "DefaultCertificateFor_yourASENameHere_InternalLoadBalancingASE"
    }
  }
}

Une fois le fichier azuredeploy.parameters.json rempli, configurez le certificat TLS/SSL par défaut à l’aide de l’extrait de code PowerShell. Modifiez les chemins d’accès aux fichiers pour qu’ils correspondent aux emplacements où se trouvent les fichiers du modèle Azure Resource Manager sur votre ordinateur. Songez à indiquer vos propres valeurs pour les noms de déploiement Resource Manager et de groupe de ressources :

$templatePath="PATH\azuredeploy.json"
$parameterPath="PATH\azuredeploy.parameters.json"

New-AzResourceGroupDeployment -Name "CHANGEME" -ResourceGroupName "YOUR-RG-NAME-HERE" -TemplateFile $templatePath -TemplateParameterFile $parameterPath

L’application de la modification prend environ 40 minutes par serveur frontal ASE. Par exemple, pour un environnement ASE de taille standard utilisant deux serveurs front-end, l’application du modèle prend environ 1 heure et 20 minutes. Lorsque le modèle est en cours d’exécution, l’ASE ne peut pas mettre à l’échelle.

Une fois l’exécution du modèle terminé, les applications sur l’ILB ASE est accessible via le protocole HTTPS. Les connexions sont sécurisées à l’aide du certificat TLS/SSL par défaut. Le certificat TLS/SSL par défaut est utilisé lorsque des applications sur l’ASE ILB sont adressée à l’aide d’une combinaison de leur nom et du nom d’hôte par défaut. Par exemple, https://mycustomapp.internal.contoso.com utilise le certificat TLS/SSL par défaut pour *.internal.contoso.com.

Cependant, comme pour les applications qui s’exécutent sur le service mutualisé public, les développeurs peuvent configurer des noms d’hôtes personnalisés pour des applications individuelles. Ils peuvent également configurer des liaisons de certificat TLS/SSL SNI uniques pour des applications individuelles.