Partager via

Comment créer un environnement ASEv1 ILB à l’aide des modèles Azure Resource Manager

  • Article

Important

Cet article traite de l’environnement App Service Environment v1. App Service Environment v1 et v2 sont 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, car 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 accédez 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.

Vue d’ensemble

Les environnements App Service peuvent être créés avec une adresse interne de réseau virtuel au lieu d’une adresse IP virtuelle publique. Cette adresse interne est fournie par un composant Azure appelé « équilibreur de charge interne » (ILB). Vous pouvez créer un ILB ASE à l’aide du portail Azure. Il peut également être créé de manière automatisée par le biais des modèles Azure Resource Manager. Cet article décrit les étapes et la syntaxe nécessaires à la création d’un ILB ASE à l’aide des modèles Azure Resource Manager.

La création automatisée d’un ILB ASE comporte trois étapes :

  1. Tout d’abord, l’ASE de base est créé dans un réseau virtuel à l’aide d’une adresse d’équilibreur de charge interne au lieu d’une adresse IP virtuelle publique. Dans le cadre de cette étape, un nom de domaine racine est affecté à l’ILB ASE.
  2. Une fois l’ILB ASE créé, un certificat TLS/SSL est chargé.
  3. Le certificat TLS/SSL chargé est explicitement affecté à l’ILB ASE en tant que certificat TLS/SSL « par défaut ». Ce certificat TLS/SSL est utilisé pour le trafic TLS à destination des applications de l’environnement ASE ILB quand celles-ci ont pour adresse le domaine racine commun attribué à l’environnement ASE (par exemple, https://someapp.mycustomrootcomain.com).

Création de l’ILB ASE de base

Un exemple de modèle Azure Resource Manager et son fichier de paramètres associé sont disponibles ici.

La plupart des paramètres du fichier azuredeploy.parameters.json sont communs à la création d’environnements ASE ILB et d’environnements ASE liés à une adresse IP virtuelle publique. La liste ci-dessous répertorie les paramètres spécifiques, ou qui sont uniques, lors de la création d’un ILB ASE :

  • internalLoadBalancingMode : détermine la façon dont les ports de contrôle et de données sont exposés.
    • La valeur 3 signifie que le trafic HTTP/HTTPS sur les ports 80/443 ainsi que les ports des canaux de contrôle ou de données écoutés par le service FTP dans l’environnement ASE seront liés à une adresse interne du réseau virtuel allouée par l’ILB.
    • La valeur 2signifie que seuls les ports liés au service FTP (canaux de contrôle et de données) seront liés à une adresse d’ILB, tandis que le trafic HTTP/HTTPS restera sur l’adresse IP virtuelle publique.
    • La valeur 0 signifie que tout le trafic est lié à l’adresse IP virtuelle publique, ce qui rend l’environnement ASE externe.
  • dnsSuffix: ce paramètre définit le domaine racine par défaut qui sera 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. Cependant, étant donné qu’un ILB ASE 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é fictive 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.
  • 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 aucune adresse IP SSL explicite pour un environnement ASE ILB. Par conséquent, le pool d’adresses IP SSL pour un environnement ASE ILB doit être défini sur zéro, sinon une erreur d’approvisionnement se produit.

Une fois le fichier azuredeploy.parameters.json renseigné pour un ILB ASE, ce dernier peut ensuite être créé à l’aide de l’extrait de code PowerShell suivant. Changez les chemins de fichiers pour qu’ils correspondent aux emplacements où se trouvent les fichiers de modèle Azure Resource Manager sur votre machine. Pensez également à indiquer vos propres valeurs pour le nom de déploiement d’Azure Resource Manager et le nom 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

Une fois le modèle Azure Resource Manager envoyé, la création de l’environnement ASE ILB prendra quelques heures. Une fois la création terminée, l’ASE ILB s’affichera dans le portail dans la liste des environnements App Service pour l’abonnement qui a déclenché le déploiement.

Chargement et configuration du certificat TLS/SSL « par défaut »

Une fois l’ILB ASE créé, un certificat TLS/SSL doit être associé à l’ASE en tant que certificat TLS/SSL « par défaut » utilisé pour établir des connexions TLS/SSL avec les applications. Poursuivons avec l’exemple de la société fictive Contoso Corporation. 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.

Il existe différentes façons d’obtenir un certificat TLS/SSL valide, notamment les autorités de certification internes, l’achat d’un certificat auprès d’un émetteur externe ou l’utilisation d’un certificat auto-signé. 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*. La deuxième entrée est nécessaire, car les connexions TLS au site SCM/Kudu associé à chaque application sont établies à l’aide d’une adresse au format votre-nom-application.scm.votre-domaine-racine-ici.com.

Une fois le certificat TLS/SSL valide à disposition, deux étapes préparatoires supplémentaires sont nécessaires. Le certificat TLS/SSL doit être converti/enregistré sous forme de fichier .pfx. N’oubliez pas que le fichier .pfx doit inclure tous les certificats intermédiaires et racine et être sécurisé avec un mot de passe.

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

L’extrait de code PowerShell ci-dessous montre un exemple de génération d’un certificat auto-signé, d’exportation du certificat en fichier .pfx, de conversion du fichier .pfx au format Base64 de la chaîne codée, puis d’enregistrement de la chaîne codée en Base64 dans un fichier distinct. Le code PowerShell pour l’encodage en Base64 est une adaptation issue du blog des 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 encodée en base64, vous pouvez utiliser l’exemple de modèle Azure Resource Manager pour configurer le certificat TLS/SSL par défaut.

Les paramètres du 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. À l’aide de l’extrait de code ci-dessus, copiez la chaîne contenue dans « exportedcert.pfx.b64 » et collez-la 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, $certThumbprint dans l’extrait de code précédent), vous pouvez utiliser la valeur telle quelle. Toutefois, si vous copiez la valeur à partir de la boîte de dialogue de certificat Windows, n’oubliez pas de retirer les espaces superflus. La valeur 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 Azure Resource Manager unique pour l’entité Microsoft.Web/certificates représentant le certificat TLS/SSL. Le nom doit finir par le suffixe suivant : _yourASENameHere_InternalLoadBalancingASE. Ce suffixe permet au portail d’indiquer que le certificat est utilisé pour sécuriser un ASE avec équilibrage de charge interne.

Un exemple abrégé de fichier azuredeploy.parameters.json est présenté ci-dessous :

{
    "$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 complété, le certificat TLS/SSL par défaut peut être configuré à l’aide de l’extrait de code PowerShell suivant. Changez les chemins de fichiers pour qu’ils correspondent aux emplacements où se trouvent les fichiers de modèle Azure Resource Manager sur votre machine. Pensez également à indiquer vos propres valeurs pour le nom de déploiement d’Azure Resource Manager et le nom 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

Une fois le modèle Azure Resource Manager envoyé, l’application de la modification prendra environ 40 minutes par environnement ASE frontal. Par exemple, avec un environnement ASE de taille standard utilisant deux serveurs frontaux, l’application du modèle prendra environ 1 heure et 20 minutes. Lorsque le modèle est en cours d’exécution, l’ASE ne peut pas être mis à l’échelle.

Une fois le modèle terminé, les applications de l’ILB ASE sont accessibles via le protocole HTTPS et les connexions sont sécurisées à l’aide du certificat TLS/SSL par défaut. Le certificat TLS/SSL par défaut est utilisé quand l’adresse des applications de l’ILB ASE se compose du nom de l’application 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, à l’instar des applications qui s’exécutent sur le service multilocataire public, les développeurs peuvent aussi configurer des noms d’hôte personnalisés pour des applications individuelles, puis configurer des liaisons de certificat SNI TLS/SSL uniques pour ces applications individuelles.

Prise en main

Pour prendre en main les environnements App Service, consultez Présentation de l'environnement App Service

Notes

Si vous voulez vous familiariser avec Azure App Service avant d’ouvrir un compte Azure, accédez à la page Essayer App Service, où vous pourrez créer immédiatement une application web temporaire dans App Service. Aucune carte de crédit n’est requise ; vous ne prenez aucun engagement.