Dela via

Skapa och använda en intern lastbalanserare App Service-miljön

  • Artikel

Viktigt!

Den här artikeln handlar om App Service-miljön v2, som används med isolerade App Service-planer. App Service-miljön v1 och v2 dras tillbaka från och med den 31 augusti 2024. Det finns en ny version av App Service-miljön som är enklare att använda och köra på kraftfullare infrastruktur. Om du vill veta mer om den nya versionen börjar du med Introduktion till App Service-miljön. Om du för närvarande använder App Service-miljön v1 följer du stegen i den här artikeln för att migrera till den nya versionen.

Från och med den 31 augusti 2024 gäller serviceavtal (SLA) och tjänstkrediter inte längre för App Service-miljön v1- och v2-arbetsbelastningar som fortsätter att vara i produktion eftersom de är tillbakadragna produkter. Avvecklingen av maskinvaran App Service-miljön v1 och v2 har påbörjats, vilket kan påverka tillgängligheten och prestandan för dina appar och data.

Du måste slutföra migreringen till App Service-miljön v3 omedelbart eller så kan dina appar och resurser tas bort. Vi försöker automatiskt migrera eventuella återstående App Service-miljön v1 och v2 på bästa sätt med hjälp av migreringsfunktionen på plats, men Microsoft gör inga anspråk eller garantier om programtillgänglighet efter automatisk migrering. Du kan behöva utföra manuell konfiguration för att slutföra migreringen och optimera ditt SKU-val för App Service-plan för att uppfylla dina behov. Om automatisk migrering inte är möjlig tas dina resurser och associerade appdata bort. Vi uppmanar dig starkt att agera nu för att undvika något av dessa extrema scenarier.

Om du behöver ytterligare tid kan vi erbjuda en respitperiod på 30 dagar för att slutföra migreringen. Mer information och för att begära den här respitperioden finns i översikten över respitperioden och gå sedan till Azure Portal och gå till migreringsbladet för var och en av dina App Service-miljön.

Den senaste informationen om App Service-miljön v1/v2-tillbakadragning finns i App Service-miljön v1- och v2-pensionsuppdateringen.

Azure App Service-miljön är en distribution av Azure App Service till ett undernät i ett virtuellt Azure-nätverk (VNet). Det går att distribuera en App Service-miljö (ASE) på två sätt:

  • Med en VIP på en extern IP-adress som ofta kallas för en extern ASE.
  • Med en VIP på en intern IP-adress, som ofta kallas ILB ASE eftersom den interna slutpunkten är en intern lastbalanserare (ILB).

Den här artikeln visar hur du kan skapa en intern belastningsutjämnare i apptjänstmiljö. En översikt över ASE finns i Introduktion till App Service-miljöer. Information om hur du skapar en extern ASE finns i [Skapa en extern ASE][MakeExternalASE].

Översikt

Du kan distribuera en ASE med en internet-tillgänglig slutpunkt eller med en IP-adress i ditt VNet. Om du ska konfigurera IP-adressen till en VNet-adress måste ASE vara distribuerad med en ILB. När du distribuerar din ASE med en ILB måste du ange namnet på din ASE. Namnet på din ASE används i domänsuffixet för apparna i DIN ASE. Domänsuffixet för din ILB ASE är <ASE name.appserviceenvironment.net>. Appar som skapas i en ILB ASE läggs inte i den offentliga DNS-tjänsten.

Tidigare versioner av ILB ASE krävde att du angav ett domänsuffix och ett standardcertifikat för HTTPS-anslutningar. Domänsuffixet samlas inte längre in när ILB ASE skapas och ett standardcertifikat samlas inte längre in. När du skapar en ILB ASE nu tillhandahålls standardcertifikatet av Microsoft och är betrott av webbläsaren. Du kan fortfarande ange anpassade domännamn för appar i din ASE och ange certifikat för dessa anpassade domännamn.

Med en ILB ASE kan du göra saker som:

  • Värdhantera intranätprogram på ett säkert sätt i molnet, som du kommer åt via en plats-till-plats eller ExpressRoute.
  • Skydda appar med en WAF-enhet
  • Vara värd för appar i molnet som inte listas i offentliga DNS-servrar.
  • Skapa internet-isolerade appar för serverdelar, som dina appar för klientdelar säkert kan integrera med.

Inaktiverad funktion

Det finns några saker som du inte kan göra när du använder en ILB ASE:

  • Använd IP-baserad TLS/SSL-bindning.
  • Tilldela IP-adresser till specifika appar.
  • Köp och använd ett certifikat med en app via Azure-portalen. Du kan hämta certifikat direkt från en certifikatutfärdare och använda dem med dina appar. Du kan inte hämta dem via Azure-portalen.

Skapa en intern belastningsutjämnare i apptjänstmiljö

Information om hur du skapar en ILB ASE finns i Skapa en ASE med hjälp av en Azure Resource Manager-mall.

Kommentar

Det App Service-miljön namnet får inte innehålla fler än 36 tecken.

Skapa en app i en ILB ASE

Du skapar en app i en ILB ASE på samma sätt som du skapar en app i en ASE vanligtvis.

  1. I Azure Portal väljer du Skapa en resurswebbapp>>.

  2. Ange appens namn.

  3. Välj prenumerationen.

  4. Välj eller skapa en Resursgrupp.

  5. Välj publicering, körningsstack och operativsystem.

  6. Välj en plats där platsen är en befintlig ILB ASE.

  7. Välj eller skapa en App Service plan.

  8. Välj Granska och Skapa och välj sedan Skapa när du är redo.

Webbjobb, Functions och ILB ASE

Både Functions och webbjobb går att använda på en ILB ASE, men för att portalen ska fungera med dem måste du ha nätverksåtkomst till SCM-webbplatsen. Det innebär att din webbläsare antingen måste vara på en värd som är i eller anslutet till det virtuella nätverket. Om din ILB ASE har ett domännamn som inte slutar med appserviceenvironment.net måste du se till att webbläsaren litar på HTTPS-certifikatet som din SCM-webbplats använder.

DNS-konfiguration

När du använder en extern ASE registreras appar som görs i din ASE med Azure DNS. Det finns inga ytterligare steg i en extern ASE för att dina appar ska vara offentligt tillgängliga. Med en ILB ASE måste du hantera din egen DNS. Du kan göra detta på din egen DNS-server eller med privata Azure DNS-zoner.

Så här konfigurerar du DNS på din egen DNS-server med din ILB ASE:

  1. skapa en zon för <ASE name.appserviceenvironment.net>
  2. skapa en A-post i den zonen som pekar * på IP-adressen för ILB
  3. skapa en A-post i den zonen som pekar på ILB IP-adressen
  4. skapa en zon i <ASE name.appserviceenvironment.net> med namnet scm
  5. skapa en A-post i scm-zonen som pekar * på IP-adressen för ILB

Så här konfigurerar du DNS i privata Azure DNS-zoner:

  1. skapa en privat Azure DNS-zon med namnet <ASE name.appserviceenvironment.net>
  2. skapa en A-post i den zonen som pekar * på IP-adressen för ILB
  3. skapa en A-post i den zonen som pekar på ILB IP-adressen
  4. skapa en A-post i den zonen som pekar *.scm till ILB IP-adressen

DNS-inställningarna för ase-standarddomänsuffixet begränsar inte dina appar till att endast vara tillgängliga med dessa namn. Du kan ange ett anpassat domännamn utan validering av dina appar i en ILB ASE. Om du sedan vill skapa en zon med namnet contoso.net kan du göra det och peka den på IP-adressen för ILB. Det anpassade domännamnet fungerar för appbegäranden men inte för scm-webbplatsen. Scm-webbplatsen är endast tillgänglig på <appname.scm>.<asename.appserviceenvironment.net>.

Zonen med namnet .<asename.appserviceenvironment.net> är globalt unikt. Före maj 2019 kunde kunderna ange domänsuffixet för ILB ASE. Om du vill använda .contoso.com för domänsuffixet kunde du göra det och det skulle inkludera scm-webbplatsen. Det fanns utmaningar med den modellen, inklusive; hantera standard-TLS/SSL-certifikatet, brist på enkel inloggning med scm-platsen och kravet på att använda ett jokerteckencertifikat. Standarduppgraderingsprocessen för ILB ASE-certifikatet var också störande och orsakade omstarter av programmet. För att lösa dessa problem ändrades ILB ASE-beteendet för att använda ett domänsuffix baserat på namnet på ASE och med ett Microsoft-ägt suffix. Ändringen av ILB ASE-beteendet påverkar bara ILB ASE som gjorts efter maj 2019. Befintliga ILB ASE:er måste fortfarande hantera standardcertifikatet för ASE och deras DNS-konfiguration.

Publicera med en ILB ASE

För varje app som skapas finns det två slutpunkter. I en ILB ASE har <du appnamn.><ILB ASE-domän> och <appnamn.scm>.<ILB ASE-domän>.

SCM-webbplatsens namn tar dig till Kudu-konsolen som heter Avancerad portal inom Azure-portalen. Med Kudu-konsolen kan du visa miljövariabler, utforska disken, använda en konsol och mycket mer. Mer information finns i Kudu console for Azure App Service (Kudu-konsol för Azure App Service).

Internetbaserade CI-system, t.ex GitHub och Azure DevOps, fungerar fortfarande med en ILB ASE om Build Agent är tillgänglig via Internet och på samma nätverk som ILB ASE. För Azure DevOps gäller att om Build Agent har skapats på samma virtuella nätverk som ILB ASE (olika undernät går bra) kan den hämta koden från Azure DevOps-git och distribuera till ILB ASE. Om du inte vill skapa en egen Build Agent måste du använda ett CI-system som använder en pull-modell, till exempel Dropbox.

Publiceringsslutpunkterna för appar i en ILB ASE använder domänen som ILB ASE skapades med. Den här domänen visas i appens publiceringsprofil och i appens portalblad (Översikt>Essentials och även Egenskaper). Om du har en ILB ASE med domänsuffixet <ASE name.appserviceenvironment.net> och en app med namnet mytest använder du mytest.<ASE name.appserviceenvironment.net> för FTP och mytest.scm.contoso.net för MSDeploy-distribution.

Konfigurera en ILB ASE med en WAF-enhet

Du kan kombinera en waf-enhet (brandvägg för webbprogram) med din ILB ASE för att endast exponera de appar som du vill ha till Internet och hålla resten endast tillgängligt från det virtuella nätverket. På så sätt kan du bland annat skapa säkra program med flera nivåer.

Om du vill veta mer om hur du konfigurerar din interna belastningsutjämnare i apptjänstmiljö med en WAF-enhet går du till Configure a web application firewall with your App Service environment (Konfigurera en brandvägg för webbaserade program med din App Service-miljö). Den här artikeln visar hur du använder en virtuell Barracuda-installation med din apptjänstmiljö. Ett annat alternativ är att använda Azure Application Gateway. Application Gateway använder OWASP-kärnregler för att göra programmen säkra. Mer information om Application Gateway finns i Introduction to the Azure web application firewall (Introduktion till Azures brandvägg för webbaserade program).

ILB ASE:er som gjordes före maj 2019

ILB ASEs som gjordes före maj 2019 krävde att du angav domänsuffixet när ASE skapades. De krävde också att du skulle ladda upp ett standardcertifikat som baserades på det domänsuffixet. Med en äldre ILB ASE kan du inte heller utföra enkel inloggning till Kudu-konsolen med appar i ILB ASE. När du konfigurerar DNS för en äldre ILB ASE måste du ange jokertecknet A-posten i en zon som matchar ditt domänsuffix. Om du skapar eller ändrar ILB ASE med anpassat domänsuffix måste du använda Azure Resource Manager-mallar och en API-version före 2019. Den senaste api-versionen för support är 2018-11-01.

Kom igång