Share via

Vytvoření interního nástroje pro vyrovnávání zatížení ASEv1 pomocí šablon Azure Resource Manageru

  • Článek

Důležité

Tento článek se týká služby App Service Environment v1. Služba App Service Environment v1 bude vyřazena 31. srpna 2024. Existuje nová verze služby App Service Environment, která se snadněji používá a běží na výkonnější infrastruktuře. Další informace o nové verzi najdete v úvodu do služby App Service Environment. Pokud aktuálně používáte App Service Environment v1, postupujte podle kroků v tomto článku a proveďte migraci na novou verzi.

Od 29. ledna 2024 už nemůžete vytvářet nové prostředky služby App Service Environment verze 1 pomocí žádné z dostupných metod, včetně šablon ARM/Bicep, webu Azure Portal, Azure CLI nebo rozhraní REST API. Před 31. srpnem 2024 musíte migrovat do služby App Service Environment v3 , abyste zabránili odstranění prostředků a ztrátě dat.

Přehled

Službu App Service Environment je možné vytvořit s interní adresou virtuální sítě místo veřejné VIRTUÁLNÍ IP adresy. Tuto interní adresu poskytuje komponenta Azure, která se nazývá interní nástroj pro vyrovnávání zatížení (ILB). Službu ASE s interním nástrojem pro vyrovnávání zatížení je možné vytvořit pomocí webu Azure Portal. Dá se také vytvořit pomocí automatizace pomocí šablon Azure Resource Manageru. Tento článek vás provede kroky a syntaxí potřebnou k vytvoření služby ASE s interním nástrojem pro vyrovnávání zatížení pomocí šablon Azure Resource Manageru.

Při automatizaci vytváření služby ASE s interním nástrojem pro vyrovnávání zatížení se používají tři kroky:

  1. Nejprve se základní služba ASE vytvoří ve virtuální síti pomocí interní adresy nástroje pro vyrovnávání zatížení místo veřejné virtuální IP adresy. V rámci tohoto kroku se ke službě ASE s interním nástrojem pro vyrovnávání zatížení přiřadí název kořenové domény.
  2. Po vytvoření služby ASE s interním nástrojem pro vyrovnávání zatížení se nahraje certifikát TLS/SSL.
  3. Nahraný certifikát TLS/SSL se službě ASE s interním nástrojem pro vyrovnávání zatížení explicitně přiřadí jako jeho výchozí certifikát TLS/SSL. Tento certifikát TLS/SSL se použije pro přenosy protokolu TLS do aplikací ve službě ASE s interním nástrojem pro vyrovnávání zatížení, když se aplikace řeší pomocí společné kořenové domény přiřazené službě ASE (například https://someapp.mycustomrootcomain.com).

Vytvoření služby ASE základního interního nástroje pro vyrovnávání zatížení

Tady je k dispozici příklad šablony Azure Resource Manageru a přidruženého souboru parametrů.

Většina parametrů v souboru azuredeploy.parameters.json je společná pro vytváření ases interního nástroje pro vyrovnávání zatížení a ase vázaných na veřejnou VIRTUÁLNÍ IP adresu. Následující seznam uvádí parametry zvláštní poznámky nebo jsou jedinečné při vytváření služby ASE s interním nástrojem pro vyrovnávání zatížení:

  • internalLoadBalancingMode: Určuje, jak jsou vystaveny řídicí a datové porty.
    • 3 znamená, že provoz HTTP/HTTPS na portech 80/443 a porty řídicího/datového kanálu, které služba FTP ve službě ASE naslouchá, budou svázané s interní adresou interní sítě s přiděleným interním nástrojem pro vyrovnávání zatížení.
    • 2 znamená, že pouze porty související se službou FTP (řídicí i datové kanály) budou vázané na adresu interního nástroje pro vyrovnávání zatížení, zatímco provoz HTTP/HTTPS zůstane na veřejné VIRTUÁLNÍ IP adrese.
    • 0 znamená, že veškerý provoz je vázán na veřejnou virtuální IP adresu, která službu ASE vytváří jako externí.
  • dnsSuffix: Tento parametr definuje výchozí kořenovou doménu, která se přiřadí službě ASE. Ve veřejné variantě služby Aplikace Azure Service je výchozí kořenová doména pro všechny webové aplikace azurewebsites.net. Vzhledem k tomu, že služba ASE s interním nástrojem pro vyrovnávání zatížení je interní pro virtuální síť zákazníka, nemá smysl používat výchozí kořenovou doménu veřejné služby. Místo toho by služba ASE s interním nástrojem pro vyrovnávání zatížení měla mít výchozí kořenovou doménu, která dává smysl pro použití v rámci interní virtuální sítě společnosti. Hypotetická společnost Contoso může například použít výchozí kořenovou doménu internal.contoso.com pro aplikace, které mají být přeložitelné a přístupné jenom ve virtuální síti společnosti Contoso.
  • ipSslAddressCount: Tento parametr se automaticky ve výchozím nastavení nastaví na hodnotu 0 v souboru azuredeploy.json , protože služba ASE s interním nástrojem pro vyrovnávání zatížení má pouze jednu adresu interního nástroje pro vyrovnávání zatížení. Pro službu ASE s interním nástrojem pro vyrovnávání zatížení neexistují žádné explicitní IP adresy SSL, takže fond IP-SSL adres pro službu ASE s interním nástrojem pro vyrovnávání zatížení musí být nastavený na nulu, jinak dojde k chybě zřizování.

Jakmile se soubor azuredeploy.parameters.json vyplní pro službu ASE s interním nástrojem pro vyrovnávání zatížení, můžete službu ASE s interním nástrojem pro vyrovnávání zatížení vytvořit pomocí následujícího fragmentu kódu PowerShellu. Změňte cesty k souborům tak, aby odpovídaly umístění souborů šablon Azure Resource Manageru na vašem počítači. Nezapomeňte také zadat vlastní hodnoty pro název nasazení Azure Resource Manager a název skupiny prostředků.

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

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

Po odeslání šablony Azure Resource Manageru bude vytvoření služby ASE s interním nástrojem pro vyrovnávání zatížení trvat několik hodin. Po dokončení vytváření se služba ASE s interním nástrojem pro vyrovnávání zatížení zobrazí v uživatelském prostředí portálu v seznamu služby App Service Environment pro předplatné, které aktivovalo nasazení.

Nahrání a konfigurace výchozího certifikátu TLS/SSL

Po vytvoření služby ASE s interním nástrojem pro vyrovnávání zatížení by měl být k ASE přidružený certifikát TLS/SSL jako výchozí certifikát TLS/SSL pro vytvoření připojení TLS/SSL k aplikacím. Pokračujte hypotetickým příkladem společnosti Contoso Corporation, pokud je výchozí přípona DNS ase internal.contoso.com, pak připojení https://some-random-app.internal.contoso.com vyžaduje certifikát TLS/SSL, který je platný pro *.internal.contoso.com.

Existují různé způsoby získání platného certifikátu TLS/SSL, včetně interních certifikačních autorit, zakoupení certifikátu od externího vystavitele a použití certifikátu podepsaného svým držitelem. Bez ohledu na zdroj certifikátu TLS/SSL je potřeba správně nakonfigurovat následující atributy certifikátu:

  • Předmět: Tento atribut musí být nastaven na *.your-root-domain-here.com
  • Alternativní název subjektu: Tento atribut musí obsahovat jak *.your-root-domain-here.com, tak *.scm.your-root-domain-here.com. Důvodem druhé položky je, že připojení TLS k webu SCM/Kudu přidruženému ke každé aplikaci se vytvoří pomocí adresy formuláře your-app-name.scm.your-root-domain-here.com.

S platným certifikátem TLS/SSL jsou potřeba další dva přípravné kroky. Certifikát TLS/SSL je potřeba převést nebo uložit jako soubor .pfx. Nezapomeňte, že soubor .pfx musí obsahovat všechny zprostředkující a kořenové certifikáty a také musí být zabezpečen pomocí hesla.

Výsledný soubor .pfx je pak potřeba převést na řetězec base64, protože certifikát TLS/SSL se nahraje pomocí šablony Azure Resource Manageru. Vzhledem k tomu, že šablony Azure Resource Manageru jsou textové soubory, je potřeba soubor .pfx převést na řetězec base64, aby ho bylo možné zahrnout jako parametr šablony.

Následující fragment kódu PowerShellu ukazuje příklad vygenerování certifikátu podepsaného svým držitelem, export certifikátu jako souboru .pfx, převod souboru .pfx na řetězec kódovaný v base64 a následné uložení zakódovaného řetězce base64 do samostatného souboru. Kód PowerShellu pro kódování base64 byl upraven z blogu skriptů PowerShellu.

$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")

Jakmile se certifikát TLS/SSL úspěšně vygeneruje a převede na řetězec kódovaný v base64, můžete použít ukázkovou šablonu Azure Resource Manageru pro konfiguraci výchozího certifikátu TLS/SSL.

Parametry v souboru azuredeploy.parameters.json jsou uvedené níže:

  • appServiceEnvironmentName: Název nakonfigurované služby ASE s interním nástrojem pro vyrovnávání zatížení.
  • existingAseLocation: Textový řetězec obsahující oblast Azure, ve které byla nasazena služba ASE s interním nástrojem pro vyrovnávání zatížení. Příklad: "USA – středojižní".
  • pfxBlobString: Řetězcová reprezentace souboru .pfx s kódováním based64. Pomocí dříve zobrazeného fragmentu kódu byste zkopírovali řetězec obsažený v souboru exportedcert.pfx.b64 a vložte ho jako hodnotu atributu pfxBlobString .
  • heslo: Heslo použité k zabezpečení souboru .pfx.
  • certificateThumbprint: Kryptografický otisk certifikátu. Pokud tuto hodnotu načtete z PowerShellu (například $certThumbprint z dřívějšího fragmentu kódu), můžete použít hodnotu tak, jak je. Pokud ale zkopírujete hodnotu z dialogového okna certifikátu systému Windows, nezapomeňte nadbytečné mezery odstranit. CertifikátThumbprint by měl vypadat nějak takto: AF3143EB61D43F6727842115BB7F17BBCECAECAE
  • certificateName: Popisný identifikátor řetězce vlastního výběru použitého k identitě certifikátu. Název se používá jako součást jedinečného identifikátoru Azure Resource Manageru pro entitu Microsoft.Web/certificates představující certifikát TLS/SSL. Název musí končit následující příponou: _yourASENameHere_InternalLoadBalancingASE. Tuto příponu používá portál jako indikátor, že se certifikát používá k zabezpečení služby ASE s povoleným interním nástrojem pro vyrovnávání zatížení.

Zkrácený příklad azuredeploy.parameters.json je uvedený níže:

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

Po vyplnění souboru azuredeploy.parameters.json je možné pomocí následujícího fragmentu kódu PowerShellu nakonfigurovat výchozí certifikát TLS/SSL. Změňte cesty k souborům tak, aby odpovídaly umístění souborů šablon Azure Resource Manageru na vašem počítači. Nezapomeňte také zadat vlastní hodnoty pro název nasazení Azure Resource Manager a název skupiny prostředků.

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

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

Po odeslání šablony Azure Resource Manageru bude použití změny přibližně 40 minut na front-end služby ASE trvat. Například s výchozí velikostí SLUŽBY ASE pomocí dvou front-endů bude šablona trvat přibližně 1 hodinu a 20 minut. Zatímco šablona spouští ase, nebude možné škálovat.

Po dokončení šablony budou aplikace ve službě ASE s interním nástrojem pro vyrovnávání zatížení přístupné přes protokol HTTPS a připojení budou zabezpečená pomocí výchozího certifikátu TLS/SSL. Výchozí certifikát TLS/SSL se použije, když se aplikace ve službě ASE s interním nástrojem pro vyrovnávání zatížení řeší pomocí kombinace názvu aplikace a výchozího názvu hostitele. Například https://mycustomapp.internal.contoso.com byste použili výchozí certifikát TLS/SSL pro *.internal.contoso.com.

Stejně jako aplikace spuštěné ve veřejné službě s více tenanty můžou vývojáři také nakonfigurovat vlastní názvy hostitelů pro jednotlivé aplikace a pak nakonfigurovat jedinečné vazby certifikátů TLS/SSL pro jednotlivé aplikace.

Začínáme

Pokud chcete začít pracovat se službou App Service Environment, přečtěte si téma Úvod do služby App Service Environment.

Poznámka:

Pokud chcete začít používat službu Azure App Service před registrací k účtu Azure, přejděte k možnosti Vyzkoušet službu App Service, kde můžete okamžitě vytvořit krátkodobou úvodní webovou aplikaci. Není vyžadována platební karta a nevzniká žádný závazek.