Creare un ambiente del servizio app usando un modello di Azure Resource Manager

  • Articolo

Panoramica

Importante

Questo articolo riguarda ambiente del servizio app v2, usato con i piani di servizio app isolato. ambiente del servizio app v2 verrà ritirato il 31 agosto 2024. È disponibile una nuova versione di ambiente del servizio app che è più facile da usare e che viene eseguita su un'infrastruttura più potente. Per altre informazioni sulla nuova versione, iniziare con l'introduzione alla ambiente del servizio app. Se si usa attualmente ambiente del servizio app v2, seguire la procedura descritta in questo articolo per eseguire la migrazione alla nuova versione.

A partire dal 29 gennaio 2024, non è più possibile creare nuove risorse ambiente del servizio app v2 usando uno dei metodi disponibili, inclusi i modelli ARM/Bicep, il portale di Azure, l'interfaccia della riga di comando di Azure o l'API REST. È necessario eseguire la migrazione a ambiente del servizio app v3 prima del 31 agosto 2024 per evitare l'eliminazione delle risorse e la perdita di dati.

app Azure gli ambienti del servizio (A edizione Standard) possono essere creati con un endpoint accessibile da Internet o un endpoint in un indirizzo interno in un'Rete virtuale di Azure. Quando viene creato con un endpoint interno, tale endpoint dispone di un componente Azure denominato servizio di bilanciamento del carico interno (ILB). L'ambiente del servizio app in un indirizzo IP interno è chiamato ambiente del servizio app con bilanciamento del carico interno. L'ambiente del servizio app con un endpoint pubblico è chiamato ambiente del servizio app esterno.

È possibile creare un ambiente del servizio app usando il portale di Azure o un modello di Azure Resource Manager. Questo articolo illustra i passaggi e la sintassi necessari per creare un ambiente del servizio app esterno o con bilanciamento del carico interno con i modelli di Resource Manager. Per informazioni su come creare un oggetto A edizione Standard v2 nel portale di Azure, vedere [Make an External A edizione Standard][MakeExternalA edizione Standard] or Make an ILB A edizione Standard.

Quando si crea un oggetto A edizione Standard nella portale di Azure, è possibile creare la rete virtuale contemporaneamente o scegliere una rete virtuale preesistente in cui eseguire la distribuzione.

Quando si crea un modello, è necessario iniziare con:

  • Una rete virtuale di Azure.
  • Una subnet in tale rete virtuale. Per un ambiente del servizio app è consigliabile una subnet di dimensioni pari a /24 con 256 indirizzi per supportare le esigenze di crescita futura e scalabilità. Dopo che l'ambiente del servizio app è stato creato, non è possibile modificarne le dimensioni.
  • La sottoscrizione in cui si vuole eseguire la distribuzione.
  • La località in cui si vuole eseguire la distribuzione.

Per automatizzare la creazione di A edizione Standard, seguire le linee guida nelle sezioni seguenti. Se si sta creando un ilB A edizione Standard v2 con dnsSuffix personalizzato (ad esempio, internal.contoso.com), è necessario eseguire altre operazioni.

  1. Dopo aver creato il servizio di bilanciamento del carico interno A edizione Standard con dnsSuffix personalizzato, deve essere caricato un certificato TLS/SSL corrispondente al dominio ilB A edizione Standard.

  2. Il certificato TLS/SSL caricato viene assegnato al servizio di bilanciamento del carico interno a edizione Standard come certificato TLS/SSL "predefinito". Questo certificato viene usato per il traffico TLS/SSL verso le app nel servizio di bilanciamento del carico interno edizione Standard quando usano il dominio radice comune assegnato a A edizione Standard (ad esempio, https://someapp.internal.contoso.com).

Creare l'ambiente del servizio app

Un modello di Resource Manager che crea un file A edizione Standard e i relativi parametri associati è disponibile in GitHub per A edizione Standard v2.

Per creare un edizione Standard A edizione Standard, usare questo esempio di modello di Resource Manager A edizione Standard v2. La maggior parte dei parametri del file azuredeploy.parameters.json è comune alla creazione degli ambienti del servizio app con bilanciamento del carico interno e degli ambienti del servizio app esterni. Nell'elenco seguente vengono chiamati parametri di nota speciale o univoci quando si crea un servizio di bilanciamento del carico interno a edizione Standard con una subnet esistente.

Parametri

  • aseName: questo parametro definisce un nome A edizione Standard univoco.
  • location: questo parametro definisce la posizione del ambiente del servizio app.
  • existingVirtualNetworkName: questo parametro definisce il nome della rete virtuale esistente e della subnet in cui risiederà A edizione Standard.
  • existingVirtualNetworkResourceGroup: il parametro definisce il nome del gruppo di risorse della rete virtuale esistente e della subnet in cui risiederà A edizione Standard.
  • subnetName: questo parametro definisce il nome della subnet della rete virtuale esistente e della subnet in cui risiederà A edizione Standard.
  • internalLoadBalancingMode: impostare nella maggior parte dei casi su 3, a indicare che sia il traffico HTTP/HTTPS sulle porte 80/443 che le porte dei canali di controllo/dati ascoltate dal servizio FTP nell'ambiente del servizio app saranno associati a un indirizzo interno della rete virtuale allocato dall'ILB. Se questa proprietà viene impostata su 2, solo le porte correlate al servizio FTP (canali di controllo e dati) vengono associate a un indirizzo del servizio di bilanciamento del carico interno. Se questa proprietà è impostata su 0, il traffico HTTP/HTTPS rimane sull'indirizzo VIP pubblico.
  • dnsSuffix: questo parametro indica il dominio radice predefinito che viene assegnato all'ambiente del servizio app. Nella variante pubblica del servizio app di Azure, il dominio radice predefinito per tutte le app Web è azurewebsites.net. Poiché un ambiente del servizio app con servizio di bilanciamento del carico interno è interno alla rete virtuale di un cliente, non ha senso usare il dominio radice predefinito del servizio pubblico. Un ambiente del servizio app con servizio di bilanciamento del carico interno deve invece avere un dominio radice predefinito appropriato per la rete virtuale interna dell'azienda. Ad esempio, Contoso Corporation potrebbe usare un dominio radice predefinito di internal.contoso.com per le app che devono essere risolvibili e accessibili solo all'interno della rete virtuale di Contoso. Per specificare un dominio radice personalizzato, è necessario usare la versione 2018-11-01 api o le versioni precedenti.
  • ipSslAddressCount: questo parametro viene automaticamente impostato sul valore predefinito 0 nel file azuredeploy.json perché gli ambienti del servizio app con servizio di bilanciamento del carico interno hanno un solo indirizzo del servizio di bilanciamento del carico interno. Non esistono indirizzi IP SSL per un ambiente del servizio app con bilanciamento del carico interno. Il pool di indirizzi IP SSL per un ambiente del servizio app con bilanciamento del carico interno deve quindi essere impostato su zero. In caso contrario, si verifica un errore di provisioning.

Dopo la compilazione di azuredeploy.parameters.json, creare l'ambiente del servizio app usando il frammento di codice di PowerShell. Modificare i percorsi dei file per fare in modo che corrispondano alle posizioni dei file dei modelli di Resource Manager nel computer. Indicare i valori per il nome della distribuzione di Resource Manager e il nome del gruppo di risorse:

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

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

La creazione dell'oggetto A edizione Standard richiede circa due ore. L'ambiente del servizio app viene quindi visualizzato nel portale nell'elenco di ambienti del servizio app per la sottoscrizione che ha attivato la distribuzione.

Caricare e configurare il certificato TLS/SSL "predefinito"

Un certificato TLS/SSL deve essere associato a A edizione Standard come certificato TLS/SSL "predefinito" usato per stabilire connessioni TLS alle app. Se il suffisso DNS predefinito di A edizione Standard è internal.contoso.com, una connessione a https://some-random-app.internal.contoso.com richiede un certificato TLS/SSL valido per *.internal.contoso.com.

Ottenere un certificato TLS/SSL valido usando le autorità di certificazione interne, l'acquisto di un certificato da un'autorità di certificazione esterna o l'uso di un certificato autofirmato. Indipendentemente dall'origine del certificato TLS/SSL, è necessario configurare correttamente gli attributi del certificato seguenti:

  • Soggetto: questo attributo deve essere impostato su *.your-root-domain-here.com.
  • Nome alternativo soggetto: questo attributo deve includere sia *.your-root-domain-here.com che *.scm.your-root-domain-here.com. Le connessioni TLS al sito SCM/Kudu associato a ogni app usano un indirizzo del modulo your-app-name.scm.your-root-domain-here.com.

Con un certificato TLS/SSL valido, sono necessari altri due passaggi preliminari. Convertire/salvare il certificato TLS/SSL come file pfx. Tenere presente che il file con estensione pfx deve includere tutti i certificati intermedi e quelli radice. Proteggerlo con una password.

Il file pfx deve essere convertito in una stringa base64 perché il certificato TLS/SSL viene caricato usando un modello di Resource Manager. Poiché i modelli di Resource Manager sono file di testo, il file PFX deve essere convertito in una stringa Base 64. In questo modo può essere incluso come parametro del modello.

Usare il frammento di codice di PowerShell seguente per:

  • Generare un certificato autofirmato.
  • Esportare il certificato come file PFX.
  • Convertire il file PXF in una stringa con codifica Base 64.
  • Salvare la stringa con codifica Base 64 in un file separato.

Questo codice PowerShell per la codifica Base 64 è stato adattato dal blog di script di 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")

Dopo la generazione e la conversione del certificato TLS/SSL in una stringa con codifica Base64, usare il modello di Resource Manager di esempio Configurare il certificato SSL predefinito in GitHub.

I parametri del file azuredeploy.parameters.json sono elencati qui:

  • appServiceEnvironmentName: nome dell'ambiente del servizio app con servizio di bilanciamento del carico interno in fase di configurazione.
  • existingAseLocation: stringa di testo contenente l'area di Azure in cui è stato distribuito l'ambiente del servizio app con servizio di bilanciamento del carico interno. Ad esempio "Stati Uniti centro-meridionali".
  • pfxBlobString: rappresentazione del file con estensione pfx sotto forma di stringa con codifica Base 64. Usare il frammento di codice visualizzato prima e copiare la stringa contenuta in "exportedcert.pfx.b64". Incollarla come valore dell'attributo pfxBlobString.
  • password: password usata per la protezione del file con estensione pfx.
  • certificateThumbprint: identificazione personale del certificato. Se si recupera questo valore da PowerShell (ad esempio, $certificate.Thumbprint dal frammento di codice precedente), è possibile usare il valore così come è. Se si copia il valore dalla finestra di dialogo del certificato di Windows, rimuovere gli spazi estranei. Il valore di certificateThumbprint sarà simile a AF3143EB61D43F6727842115BB7F17BBCECAECAE.
  • certificateName: identificatore di stringa descrittivo scelto dall'utente per identificare il certificato. Il nome viene usato come parte dell'identificatore univoco di Resource Manager per l'entità Microsoft.Web/certificates che rappresenta il certificato TLS/SSL. Il nome deve terminare con il suffisso seguente: _yourA edizione Standard NameHere_InternalLoadBalancingA edizione Standard. Il portale di Azure usa questo suffisso per indicare che il certificato è usato per la protezione di un ambiente del servizio app abilitato al bilanciamento del carico interno.

Un esempio abbreviato di azuredeploy.parameters.json è illustrato qui:

{
  "$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"
    }
  }
}

Dopo aver compilato il file azuredeploy.parameters.json , configurare il certificato TLS/SSL predefinito usando il frammento di codice di PowerShell. Modificare i percorsi dei file per fare in modo che corrispondano al percorso dei file dei modelli di Resource Manager nel computer. Indicare i valori per il nome della distribuzione di Resource Manager e il nome del gruppo di risorse:

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

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

L'applicazione della modifica richiede circa 40 minuti per ogni front-end dell'ambiente del servizio app. Ad esempio, per un A di dimensioni predefinite edizione Standard che usa due front-end, il modello richiede circa 1 ora e 20 minuti per il completamento. Durante l'esecuzione del modello, l'ambiente del servizio app non può essere ridimensionato.

Quando il modello è completato, le app nell'ambiente del servizio app con bilanciamento del carico interno sono accessibili tramite HTTPS. Le connessioni vengono protette usando il certificato TLS/SSL predefinito. Il certificato TLS/SSL predefinito viene usato quando le app nel servizio di bilanciamento del carico interno A edizione Standard vengono indirizzate usando una combinazione del nome dell'applicazione più il nome host predefinito. Ad esempio, https://mycustomapp.internal.contoso.com usa il certificato TLS/SSL predefinito per *.internal.contoso.com.

Tuttavia, come per le app eseguite nel servizio multi-tenant pubblico, gli sviluppatori possono configurare nomi host personalizzati per le singole app. Possono anche configurare associazioni di certificati TLS/SSL SNI univoche per le singole app.