Come creare un servizio di bilanciamento del carico interno A edizione Standard v1 usando i modelli di Azure Resource Manager

Panoramica

È possibile creare ambienti del servizio app con un indirizzo interno di rete virtuale anziché un indirizzo VIP pubblico. L'indirizzo interno viene messo a disposizione da un componente di Azure denominato servizio di bilanciamento del carico interno (ILB). È possibile creare un ambiente del servizio app con servizio di bilanciamento del carico interno usando il portale di Azure. L'ambiente può anche essere creato con l'automazione, usando i modelli di Azure Resource Manager. Questo articolo illustra i passaggi e la sintassi necessari per creare un ambiente del servizio app con servizio di bilanciamento del carico interno con i modelli di Azure Resource Manager.

L'automazione della creazione di un ambiente del servizio app con servizio di bilanciamento del carico interno prevede tre passaggi:

1. Viene prima creato l'ambiente del servizio app di base in una rete virtuale usando un indirizzo di servizio di bilanciamento del carico interno anziché un indirizzo VIP pubblico. Nell'ambito di questo passaggio viene assegnato un nome di dominio radice all'ambiente del servizio app con servizio di bilanciamento del carico interno.
2. Dopo aver creato il servizio di bilanciamento del carico interno a edizione Standard, viene caricato un certificato TLS/SSL.
3. Il certificato TLS/SSL caricato viene assegnato in modo esplicito al servizio di bilanciamento del carico interno A edizione Standard come certificato TLS/SSL "predefinito". Questo certificato TLS/SSL verrà usato per il traffico TLS verso le app nel servizio di bilanciamento del carico interno edizione Standard quando le app vengono indirizzate usando il dominio radice comune assegnato all'A edizione Standard (ad esempio https://someapp.mycustomrootcomain.com)

Creazione dell'ambiente del servizio app con servizio di bilanciamento del carico interno

Un esempio di modello di Azure Resource Manager e il relativo file di parametri associato sono disponibili qui.

La maggior parte dei parametri nel file azuredeploy.parameters.json è comune per la creazione di edizione Standard ilB A e A edizione Standard associati a un indirizzo VIP pubblico. L'elenco seguente indica parametri importanti o specifici per la creazione di un ambiente del servizio app con servizio di bilanciamento del carico interno:

• internalLoadBalancingMode: determina come vengono esposte le porte di controllo e dati.
  • 3 indica sia il traffico HTTP/HTTPS sulle porte 80/443 che le porte del canale di controllo/dati ascoltate dal servizio FTP nel servizio A edizione Standard, verranno associate a un indirizzo interno della rete virtuale allocata dal bilanciamento del carico interno.
  • 2 indica che solo le porte correlate al servizio FTP (sia i canali di controllo che di dati) verranno associate a un indirizzo ILB, mentre il traffico HTTP/HTTPS rimarrà sull'indirizzo VIP pubblico.
  • 0 indica che tutto il traffico è associato all'indirizzo VIP pubblico rendendo A edizione Standard esterno.
• dnsSuffix: questo parametro indica il dominio radice predefinito che verrà 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é tuttavia 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, un'ipotetica Contoso Corporation potrebbe usare un dominio radice predefinito di internal.contoso.com per le app destinate a essere risolvibili e accessibili solo all'interno della rete virtuale di Contoso.
• ipSslAddressCount: questo parametro viene automaticamente impostato sul valore predefinito di 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 sono presenti indirizzi IP-SSL espliciti per un ilB A edizione Standard e quindi il pool di indirizzi IP-SSL per un ilB A edizione Standard deve essere impostato su zero; in caso contrario, si verificherà un errore di provisioning.

Dopo che il file azuredeploy.parameters.json è stato compilato per un ilB A edizione Standard, è possibile creare il codice ILB A edizione Standard usando il frammento di codice di PowerShell seguente. Modificare i percorsi dei file in modo che corrispondano alla posizione in cui si trovano i file modello di Azure Resource Manager nel computer. Indicare anche i valori per il nome della distribuzione di Azure 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

Dopo l'invio del modello di Azure Resource Manager, la creazione del servizio di bilanciamento del carico interno A edizione Standard richiederà alcune ore. Al termine della creazione, l'ambiente del servizio app con servizio di bilanciamento del carico interno verrà visualizzato nel portale nell'elenco di ambienti del servizio app per la sottoscrizione che ha attivato la distribuzione.

Caricamento e configurazione del certificato TLS/SSL "predefinito"

Dopo aver creato il servizio di bilanciamento del carico interno A edizione Standard, un certificato TLS/SSL deve essere associato a A edizione Standard come certificato TLS/SSL "predefinito" usato per stabilire connessioni TLS/SSL alle app. Continuando con l'esempio ipotetico Contoso Corporation, 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.

Esistono diversi modi per ottenere un certificato TLS/SSL valido, incluse le ca interne, l'acquisto di un certificato da un'autorità di certificazione esterna e l'uso di un certificato autofirmato. Indipendentemente dall'origine del certificato TLS/SSL, è necessario configurare correttamente gli attributi del certificato seguenti:

• Subject: 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. Il motivo della seconda voce è che le connessioni TLS al sito SCM/Kudu associate a ogni app verranno effettuate usando un indirizzo del modulo your-app-name.scm.your-root-domain-here.com.

Con un certificato TLS/SSL valido, sono necessari due passaggi preliminari aggiuntivi. Il certificato TLS/SSL deve essere convertito/salvato come file pfx. Il file con estensione pfx deve includere tutti i certificati intermedi e radice ed essere protetto con una password.

Il file pfx risultante deve quindi essere convertito in una stringa base64 perché il certificato TLS/SSL verrà caricato usando un modello di Azure Resource Manager. Poiché i modelli di Azure Resource Manager sono file di testo, il file con estensione pfx deve essere convertito in una stringa con codifica Base64 per essere incluso come parametro del modello.

Il frammento di codice di PowerShell riportato di seguito illustra un esempio di generazione di un certificato autofirmato, l'esportazione del certificato come file pfx, la conversione del file pfx in una stringa con codifica base64 e il salvataggio della stringa con codifica base64 in un file separato. Il codice di PowerShell per la codifica Base64 è stato adattato dal blog degli 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 aver generato e convertito correttamente il certificato TLS/SSL in una stringa con codifica Base64, è possibile usare il modello di Azure Resource Manager di esempio per la configurazione del certificato TLS/SSL predefinito.

I parametri del file azuredeploy.parameters.json sono elencati di seguito:

• 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 Base64. Usando il frammento di codice indicato in precedenza, la stringa contenuta in "exportedcert.pfx.b64" dovrà essere copiata e incollata 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 $certThumbprint dal frammento di codice precedente, è possibile usare il valore così come è. Se tuttavia 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 Azure 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. Questo suffisso viene usato dal portale 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 di seguito:

{
    "$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 , è possibile configurare il certificato TLS/SSL predefinito usando il frammento di codice di PowerShell seguente. Modificare i percorsi dei file in modo che corrispondano alla posizione in cui si trovano i file modello di Azure Resource Manager nel computer. Indicare anche i valori per il nome della distribuzione di Azure 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

Dopo l'invio del modello di Azure Resource Manager, l'applicazione della modifica richiederà circa 40 minuti per A edizione Standard front-end. Ad esempio, con una dimensione predefinita A edizione Standard usando due front-end, il modello richiederà circa 1 ora e 20 minuti per il completamento. Durante l'esecuzione del modello, l'ambiente del servizio app non potrà essere ridimensionato.

Al termine del modello, è possibile accedere alle app nel servizio di bilanciamento del carico interno a edizione Standard tramite HTTPS e le connessioni verranno protette usando il certificato TLS/SSL predefinito. Il certificato TLS/SSL predefinito verrà 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 userebbe il certificato TLS/SSL predefinito per *.internal.contoso.com.

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

Introduzione

Per iniziare a usare gli ambienti del servizio app, vedere Introduzione all'ambiente del servizio app