Hantera en App Service-miljön

Viktigt!

Den här artikeln handlar om App Service-miljön v2 som används med isolerade App Service-planer. App Service-miljön v2 dras tillbaka 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 v2 följer du stegen i den här artikeln för att migrera till den nya versionen.

Från och med den 29 januari 2024 kan du inte längre skapa nya App Service-miljön v2-resurser med någon av de tillgängliga metoderna, inklusive ARM/Bicep-mallar, Azure Portal, Azure CLI eller REST API. Du måste migrera till App Service-miljön v3 före den 31 augusti 2024 för att förhindra resursborttagning och dataförlust.

En App Service-miljön (ASE) är en distribution av Azure App Service till ett undernät i en kunds Azure Virtual Network-instans. En ASE består av:

  • Klientdelar: Där HTTP eller HTTPS avslutas i en App Service-miljön
  • Arbetare: De resurser som är värdar för dina appar
  • Databas: Innehåller information som definierar miljön
  • Lagring: Används som värd för kundpublicerade appar

Du kan distribuera en ASE med en extern eller intern virtuell IP-adress (VIP) för appåtkomst. En distribution med en extern VIP kallas ofta för en extern ASE. En distribution med en intern VIP kallas en ILB ASE eftersom den använder en intern lastbalanserare (ILB). Mer information om ILB ASE finns i Skapa och använda en ILB ASE.

Skapa en app i en ASE

Om du vill skapa en app i en ASE använder du samma process som när du normalt skapar en app, men med några små skillnader. När du skapar en ny App Service-plan:

  • I stället för att välja en geografisk plats där appen ska distribueras väljer du en ASE som plats.
  • Alla App Service-planer som skapats i en ASE kan bara vara på en isolerad prisnivå.

Om du inte har en ASE kan du skapa en genom att följa anvisningarna i Skapa en App Service-miljön.

Så här skapar du en app i en ASE:

  1. Välj Skapa en resurs>webb - och mobilapp.>

  2. Ange ett namn för appen. Om du redan har valt en App Service-plan i en ASE återspeglar domännamnet för appen domännamnet för ASE:

    App name selection

  3. Välj en prenumeration.

  4. Ange ett namn för en ny resursgrupp eller välj Använd befintlig och välj ett i listrutan.

  5. Välj ditt operativsystem.

  6. Välj en befintlig App Service-plan i din ASE eller skapa en ny genom att följa dessa steg:

    a. På menyn till vänster i Azure-portalen väljer du Skapa en resurswebbapp>.

    b. Välj prenumerationen.

    c. Välj eller skapa resursgruppen.

    d. Ange namnet på webbappen.

    e. Välj Kod eller DockerContainer.

    f. Välj en körningsstack.

    g. Välj Linux eller Windows.

    h. Välj din ASE i listrutan Region .

    i. Välj eller skapa en ny App Service-plan. Om du skapar en ny App Service-plan väljer du lämplig isolerad SKU-storlek.

    Isolated pricing tiers

    Kommentar

    Linux-appar och Windows-appar kan inte ingå i samma App Service-plan, men de kan finnas i samma App Service-miljön.

  7. Välj Granska + skapa, kontrollera att informationen är korrekt och välj sedan Skapa.

Så här fungerar skalning

Varje App Service-app körs i en App Service-plan. App Service-miljön innehåller App Service-planer och App Service-planer innehåller appar. När du skalar en app skalar du även App Service-planen och alla appar i samma plan.

När du skalar en App Service-plan läggs den infrastruktur som behövs till automatiskt. Det finns en tidsfördröjning för att skala åtgärder medan infrastrukturen läggs till. Om du utför flera skalningsåtgärder i följd utförs den första begäran om infrastrukturskalning och de andra placeras i kö. När den första skalningsåtgärden är klar fungerar alla andra infrastrukturbegäranden tillsammans. Och när infrastrukturen läggs till tilldelas App Service-planerna efter behov. Att skapa en ny App Service-plan är i sig en skalningsåtgärd eftersom den begär ytterligare maskinvara. En skalningsåtgärd tar vanligtvis 30–60 minuter att slutföra.

I App Service för flera klientorganisationer är skalning omedelbart eftersom en pool med resurser är lättillgänglig för att stödja den. I en ASE finns det ingen sådan buffert och resurser allokeras baserat på behov.

I en ASE kan du skala en App Service-plan upp till 100 instanser. En ASE kan ha upp till 201 totala instanser för alla App Service-planer i ase-programmet.

IP-adresser

App Service kan allokera en dedikerad IP-adress till en app. Den här funktionen är tillgänglig när du har konfigurerat en IP-baserad TLS/SSL-bindning, enligt beskrivningen i Binda ett befintligt anpassat TLS/SSL-certifikat till Azure App Service. I en ILB ASE kan du inte lägga till fler IP-adresser som ska användas för DEN IP-baserade TLS/SSL-bindningen.

Med en extern ASE kan du konfigurera en IP-baserad TLS/SSL-bindning för din app på samma sätt som i App Service för flera klientorganisationer. Det finns alltid en extra adress i ASE, upp till 30 IP-adresser. Varje gång du använder en läggs en annan till så att en adress alltid är lättillgänglig. En tidsfördröjning krävs för att allokera en annan IP-adress. Den fördröjningen förhindrar att IP-adresser läggs till i snabb följd.

Skalning i klientdelen

När du skalar ut dina App Service-planer läggs arbetare automatiskt till för att stödja dem. Varje ASE skapas med två klientdelar. Klientdelarna skalas automatiskt ut med en hastighet av en klientdel för varje uppsättning med 15 App Service-planinstanser. Om du till exempel har tre App Service-planer med fem instanser vardera skulle du ha totalt 15 instanser och tre klientdelar. Om du skalar till totalt 30 instanser har du fyra klientdelar. Det här mönstret fortsätter när du skalar ut.

Antalet klientdelar som allokeras som standard är bra för en måttlig belastning. Du kan sänka förhållandet till så lite som en klientdel för var femte instans. Du kan också ändra storleken på klientdelarna. Som standard är de enkla kärnor. I Azure-portalen kan du ändra deras storlek till två eller fyra kärnor i stället.

Det finns en avgift för att ändra förhållandet eller klientdelsstorlekarna. Mer information finns i Priser för Azure App Service. Om du vill förbättra inläsningskapaciteten för din ASE får du mer förbättring genom att först skala till tvåkärns klientdelar innan du justerar skalningsförhållandet. Om du ändrar kärnstorleken för klientdelen kommer du att uppgradera din ASE och bör göras utanför normal kontorstid.

Klientdelsresurser är HTTP/HTTPS-slutpunkten för ASE. Med standardkonfigurationen för klientdelen är minnesanvändningen per klientdel konsekvent cirka 60 procent. Den främsta orsaken till att skala dina klientdelar är CPU-användning, som främst drivs av HTTPS-trafik.

App-åtkomst

I en extern ASE är domänsuffixet som används för att skapa appar .<asename.p.azurewebsites.net>. Om din ASE heter external-ase och du är värd för en app med namnet contoso i den ASE:t, når du den på följande URL:er:

  • contoso.external-ase.p.azurewebsites.net
  • contoso.scm.external-ase.p.azurewebsites.net

Information om hur du skapar en extern ASE finns i Skapa en App Service-miljön.

I en ILB ASE är domänsuffixet som används för att skapa appen .<asename.appserviceenvironment.net>. Om din ASE heter ilb-ase och du är värd för en app med namnet contoso i den ASE:n når du den på följande URL:er:

  • contoso.ilb-ase.appserviceenvironment.net
  • contoso.scm.ilb-ase.appserviceenvironment.net

Information om hur du skapar en ILB ASE finns i Skapa och använda en ILB ASE.

SCM-URL:en används för att komma åt Kudu-konsolen eller för att publicera din app med hjälp av Webbdistribution. Kudu-konsolen ger dig ett webbgränssnitt för felsökning, uppladdning av filer, redigering av filer och mycket mer.

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. Om din ILB ASE V2 skapades efter maj 2019 behöver du inte hantera ILB-standardcertifikatet eftersom det hanteras av Microsoft.

Publicera

I en ASE, precis som med apptjänsten för flera klientorganisationer, kan du publicera med följande metoder:

  • Webbdistribution
  • FTP
  • Kontinuerlig integrering (CI)
  • Dra och släpp i Kudu-konsolen
  • En IDE, till exempel Visual Studio, Eclipse eller IntelliJ IDEA

Med en extern ASE fungerar alla dessa publiceringsalternativ på samma sätt. Mer information finns i Distribution i Azure App Service.

Med en ILB ASE är publiceringsslutpunkterna endast tillgängliga via ILB. ILB finns på en privat IP-adress i ASE-undernätet i det virtuella nätverket. Om du inte har nätverksåtkomst till ILB kan du inte publicera några appar på den ASE:n. Som anges i Skapa och använda en ILB ASE måste du konfigurera DNS för apparna i systemet. Det kravet omfattar SCM-slutpunkten. Om slutpunkterna inte har definierats korrekt kan du inte publicera. Dina IDE:er måste också ha nätverksåtkomst till ILB för att publicera direkt till den.

Utan ytterligare ändringar fungerar inte internetbaserade CI-system som GitHub och Azure DevOps med en ILB ASE eftersom publiceringsslutpunkten inte är tillgänglig via Internet. Du kan aktivera publicering till en ILB ASE från Azure DevOps genom att installera en lokal versionsagent i det virtuella nätverket som innehåller ILB ASE. Du kan också 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. Du kan se den i appens publiceringsprofil och i appens portalfönster (i Översikt>essentials och även i Egenskaper).

Lagring

En ASE har 1 TB lagringsutrymme för alla appar i ASE. En App Service-plan i SKU för isolerad prissättning har en gräns på 250 GB. I en ASE läggs 250 GB lagringsutrymme till per App Service-plan upp till gränsen på 1 TB. Du kan ha fler App Service-planer än bara fyra, men det finns inget mer lagringsutrymme utöver gränsen på 1 TB.

Övervakning

Som kund bör du övervaka App Service-planerna och de enskilda appar som körs och vidta lämpliga åtgärder. För App Service-miljön v2 bör du också vara uppmärksam på måtten kring plattformsinfrastrukturen. Dessa mått ger dig insikter om hur plattformsinfrastrukturen och klientdelsservrarna (multiRole) fungerar, och du kan vidta åtgärder om de används kraftigt och du inte får maximalt dataflöde.

Via Azure-portalen och CLI kan du konfigurera skalningsförhållandet för dina klientdelsservrar mellan 5 och 15 (standard 15) App Service-planinstanser per klientdelsserver. En App Service-miljön har alltid minst två klientdelsservrar. Du kan också öka storleken på klientdelsservrarna.

Måttomfånget som används för att övervaka plattformsinfrastrukturen kallas Microsoft.Web/hostingEnvironments/multiRolePools.

Du ser ett omfång som heter Microsoft.Web/hostingEnvironments/workerPools. Måtten här gäller endast för App Service-miljön v1.

Loggning

Du kan integrera din ASE med Azure Monitor för att skicka loggar om ASE till Azure Storage, Azure Event Hubs eller Log Analytics. Dessa objekt loggas idag:

Situation Meddelande
ASE är inte felfri Den angivna ASE:n är inte felfri på grund av en ogiltig konfiguration av virtuellt nätverk. ASE pausas om tillståndet för feltillståndet fortsätter. Se till att riktlinjerna som definieras här följs: Nätverksöverväganden för en App Service-miljön.
ASE-undernätet har nästan slut på utrymme Den angivna ASE:n finns i ett undernät som nästan har slut på utrymme. Det finns {0} återstående adresser. När dessa adresser är uttömda kommer ASE inte att kunna skalas.
ASE närmar sig total instansgräns Den angivna ASE närmar sig den totala instansgränsen för ASE. Den innehåller {0} för närvarande App Service Plan-instanser av maximalt 201 instanser.
ASE kan inte nå ett beroende Den angivna ASE:en kan inte nå {0}. Se till att riktlinjerna som definieras här följs: Nätverksöverväganden för en App Service-miljön.
ASE är pausat Angiven ASE är pausad. ASE-avstängningen kan bero på ett kontounderskott eller en ogiltig konfiguration av virtuellt nätverk. Lös rotorsaken och återuppta ASE för att fortsätta att betjäna trafiken.
ASE-uppgraderingen har startat En plattformsuppgradering till angiven ASE har påbörjats. Förvänta dig fördröjningar i skalningsåtgärder.
ASE-uppgraderingen har slutförts En plattformsuppgradering till angiven ASE har slutförts.
Skalningsåtgärder har startats En App Service-plan ({0}) har börjat skalas. Önskat tillstånd: {1} Jag{2} arbetar.
Skalningsåtgärder har slutförts En App Service-plan ({0}) har slutfört skalningen. Aktuellt tillstånd: {1} Jag{2} arbetar.
Skalningsåtgärder har misslyckats Det gick inte att skala en App Service-plan ({0}). Aktuellt tillstånd: {1} Jag{2} arbetar.

Så här aktiverar du loggning på din ASE:

  1. Gå till Diagnostikinställningar i portalen.
  2. Välj Lägg till diagnostikinställning.
  3. Ange ett namn för loggintegrering.
  4. Välj och konfigurera de loggmål som du vill använda.
  5. Välj AppServiceEnvironmentPlatformLogs.

ASE diagnostic log settings

Om du integrerar med Log Analytics kan du se loggarna genom att välja Loggar från ASE-portalen och skapa en fråga mot AppServiceEnvironmentPlatformLogs. Loggar genereras endast när din ASE har en händelse som utlöser den. Om din ASE inte har en sådan händelse kommer det inte att finnas några loggar. Om du snabbt vill se ett exempel på loggar på Log Analytics-arbetsytan utför du en skalningsåtgärd med något av App Service-abonnemangen i DIN ASE. Du kan sedan köra en fråga mot AppServiceEnvironmentPlatformLogs för att se loggarna.

Skapa en avisering

Om du vill skapa en avisering mot dina loggar följer du anvisningarna i Skapa, visa och hantera loggaviseringar med Hjälp av Azure Monitor. I korthet:

  • Öppna sidan Aviseringar i ASE-portalen
  • Välj Ny aviseringsregel
  • Välj din resurs som log analytics-arbetsyta
  • Ange villkoret med en anpassad loggsökning för att använda en fråga som "AppServiceEnvironmentPlatformLogs | där ResultDescription innehåller "har börjat skala" eller vad du vill. Ange tröskelvärdet efter behov.
  • Lägg till eller skapa en åtgärdsgrupp efter behov. Åtgärdsgruppen är den där du definierar svaret på aviseringen, till exempel att skicka ett e-postmeddelande eller ett SMS
  • Ge aviseringen ett namn och spara den.

Uppgraderingsinställning

Om du har flera ASE:er kanske du vill att vissa ASE:er ska uppgraderas före andra. Det här beteendet kan aktiveras via ASE-portalen. Under Konfiguration har du möjlighet att ange uppgraderingsinställningar. De tre möjliga värdena är:

  • Ingen: Azure uppgraderar din ASE i någon viss batch. Det här är standardvärdet.
  • Tidigt: Din ASE uppgraderas under den första halvan av App Service-uppgraderingarna.
  • Sent: Din ASE uppgraderas under andra halvan av App Service-uppgraderingarna.

Välj önskat värde och välj Spara. Standardvärdet för alla ASE är Ingen.

ASE configuration portal

Funktionen upgradePreferences är mest meningsfull när du har flera ASE:er eftersom dina "tidiga" ASE:er uppgraderas före dina "sena" ASE:er. När du har flera ASE:er bör du ange att dina utvecklings- och test-ASE:er ska vara "tidiga" och att dina produktions-ASE:er ska vara "Late".

Prissättning

Prissättnings-SKU:n som kallas Isolerad är endast avsedd för ases. Alla App Service-planer som finns i ASE finns i den isolerade pris-SKU:n. Isolerade priser för App Service-planer kan variera beroende på region.

Utöver priset för dina App Service-planer finns det ett fast pris för själva ASE. Det fasta priset ändras inte med storleken på din ASE. Den betalar för ASE-infrastrukturen med en standardskalningshastighet på ytterligare en klientdel för varje 15 App Service-planinstanser.

Om standardskalningshastigheten för en klientdel för varje 15 App Service-planinstanser inte är tillräckligt snabb kan du justera förhållandet där klientdelar läggs till eller storleken på klientdelarna. När du justerar förhållandet eller storleken betalar du för de frontend-kärnor som inte skulle läggas till som standard.

Om du till exempel justerar skalningsförhållandet till 10 läggs en klientdel till för var 10:e instans i dina App Service-planer. Den fasta avgiften täcker en skalningsgrad på en klientdel för var 15:e instans. Med ett skalningsförhållande på 10 betalar du en avgift för den tredje klientdelen som läggs till för de 10 App Service-planinstanserna. Du behöver inte betala för det när du når 15 instanser eftersom det lades till automatiskt.

Om du justerar storleken på klientdelarna till två kärnor men inte justerar förhållandet betalar du för de extra kärnorna. En ASE skapas med två klientdelar, så även under tröskelvärdet för automatisk skalning skulle du betala för två extra kärnor om du ökade storleken till klientdelar med två kärnor.

Mer information finns i Priser för Azure App Service.

Ta bort en ASE

Så här tar du bort en ASE:

  1. Välj Ta bort överst i fönstret App Service-miljön.

  2. Ange namnet på din ASE för att bekräfta att du vill ta bort den. När du tar bort en ASE tar du också bort allt innehåll i den.

    ASE deletion

  3. Välj OK.

ASE CLI

Det finns kommandoradsfunktioner att administrera till en ASE. Azure CLI-kommandona anges nedan.

C:\>az appservice ase --help

Group
    az appservice ase : Manage App Service Environments v2.
        This command group is in preview. It may be changed/removed in a future release.
Commands:
    create         : Create app service environment.
    delete         : Delete app service environment.
    list           : List app service environments.
    list-addresses : List VIPs associated with an app service environment.
    list-plans     : List app service plans associated with an app service environment.
    show           : Show details of an app service environment.
    update         : Update app service environment.

For more specific examples, use: az find "az appservice ase"