Konfigurera mellanlagringsmiljöer i Azure App Service

När du distribuerar din webbapp, webbapp i Linux, mobil serverdel eller API-app för att Azure App Service kan du använda ett separat distributionsfack i stället för standardproduktionsplatsen när du kör på nivån Standard, Premium eller Isolerad App Service plan. Distributionsfack är liveappar med egna värdnamn. Appinnehåll och konfigurationselement kan växlas mellan två distributionsplatser, inklusive produktionsplatsen.

Distributionen av ditt program till en icke-produktionsplats har följande fördelar:

  • Du kan verifiera appändringar i ett distributionsfack för mellanlagring innan du växlar det med produktionsplatsen.
  • Om du distribuerar en app till ett fack först och växlar den till produktion ser du till att alla instanser av facket värms upp innan de växlas till produktion. Detta eliminerar stilleståndstiden när du distribuerar appen. Trafikomdirigeringen är sömlös och inga begäranden tas bort på grund av växlingsåtgärder. Du kan automatisera hela arbetsflödet genom att konfigurera automatisk växling när validering före växling inte behövs.
  • Efter ett byte har facket med tidigare mellanlagrade appar nu den tidigare produktionsappen. Om ändringarna som växlas till produktionsplatsen inte är som förväntat kan du utföra samma byte omedelbart för att få tillbaka din "senast kända bra webbplats".

Varje App Service plannivå stöder olika antal distributionsplatser. Det tillkommer ingen extra kostnad för att använda distributionsplatser. Information om hur många platser som appens nivå stöder finns i App Service gränser.

Om du vill skala din app till en annan nivå kontrollerar du att målnivån stöder det antal platser som appen redan använder. Om din app till exempel har fler än fem platser kan du inte skala ned den till Standard-nivån eftersom Standard-nivån endast stöder fem distributionsplatser.

Lägga till ett fack

Appen måste köras på nivån Standard, Premium eller Isolerad för att du ska kunna aktivera flera distributionsplatser.

  1. i Azure Portal söker du efter och väljer App Services och väljer din app.

    Sök efter App Services

  2. I den vänstra rutan väljer du Distributionsfack>Lägg till plats.

    Lägg till en ny distributionsplats

    Anteckning

    Om appen inte redan finns på nivån Standard, Premium eller Isolerad får du ett meddelande som anger vilka nivåer som stöds för att aktivera stegvis publicering. Nu kan du välja Uppgradera och gå till fliken Skala i appen innan du fortsätter.

  3. I dialogrutan Lägg till ett fack ger du platsen ett namn och väljer om du vill klona en appkonfiguration från ett annat distributionsfack. Välj Lägg till för att fortsätta.

    Konfigurationskälla

    Du kan klona en konfiguration från ett befintligt fack. Inställningar som kan klonas är appinställningar, anslutningssträngar, språkramverksversioner, webbsocketer, HTTP-version och plattformsbitness.

Anteckning

För närvarande klonas inte en privat slutpunkt över platser.

  1. När facket har lagts till väljer du Stäng för att stänga dialogrutan. Det nya facket visas nu på sidan Distributionsfack . Som standard är Trafik % inställt på 0 för det nya facket, där all kundtrafik dirigeras till produktionsplatsen.

  2. Välj det nya distributionsfacket för att öppna platsens resurssida.

    Namn på distributionsfack

    Mellanlagringsplatsen har en hanteringssida precis som andra App Service app. Du kan ändra platskonfigurationen. För att påminna dig om att du visar distributionsfacket visas appnamnet som <appnamn>/<platsnamn> och apptypen är App Service (Slot). Du kan också se platsen som en separat app i resursgruppen med samma beteckningar.

  3. Välj appens URL på platsens resurssida. Distributionsfacket har ett eget värdnamn och är också en liveapp. Information om hur du begränsar offentlig åtkomst till distributionsplatsen finns i Azure App Service IP-begränsningar.

Det nya distributionsfacket har inget innehåll, även om du klonar inställningarna från ett annat fack. Du kan till exempel publicera till det här facket med Git. Du kan distribuera till platsen från en annan lagringsplatsgren eller en annan lagringsplats. Hämta publiceringsprofilen från Azure App Service kan tillhandahålla nödvändig information för att distribuera till platsen. Profilen kan importeras av Visual Studio för att distribuera innehåll till platsen.

Platsens URL kommer att ha formatet http://sitename-slotname.azurewebsites.net. För att hålla URL-längden inom nödvändiga DNS-gränser trunkeras platsnamnet med 40 tecken, platsnamnet trunkeras med 19 tecken och ytterligare 4 slumpmässiga tecken läggs till för att säkerställa att det resulterande domännamnet är unikt.

Vad händer under en växling

Växlingsåtgärdssteg

När du växlar två platser (vanligtvis från en mellanlagringsplats till produktionsplatsen) gör App Service följande för att säkerställa att målplatsen inte upplever driftstopp:

  1. Använd följande inställningar från målplatsen (till exempel produktionsplatsen) på alla instanser av källplatsen:

    Något av dessa fall utlöser alla instanser i källfacket för att starta om. Under växling med förhandsversion markerar detta slutet på den första fasen. Växlingsåtgärden pausas och du kan kontrollera att källplatsen fungerar korrekt med målplatsens inställningar.

  2. Vänta tills varje instans i källplatsen har slutfört omstarten. Om någon instans inte kan startas om återställer växlingsåtgärden alla ändringar i källplatsen och stoppar åtgärden.

  3. Om lokal cache är aktiverad utlöser du initiering av lokal cache genom att göra en HTTP-begäran till programroten ("/") på varje instans av källplatsen. Vänta tills varje instans returnerar något HTTP-svar. Initiering av lokal cache orsakar ytterligare en omstart på varje instans.

  4. Om automatisk växling är aktiverat med anpassad uppvärmning utlöser du Programinitiering genom att göra en HTTP-begäran till programroten ("/") på varje instans av källplatsen.

    Om applicationInitialization inte anges utlöser du en HTTP-begäran till programroten för källplatsen på varje instans.

    Om en instans returnerar något HTTP-svar anses den vara uppvärmd.

  5. Om alla instanser på källplatsen har värmts upp växlar du de två platserna genom att växla routningsreglerna för de två platserna. Efter det här steget har målplatsen (till exempel produktionsplatsen) appen som tidigare har värmts upp i källplatsen.

  6. Nu när källplatsen har förväxlingsappen tidigare i målplatsen utför du samma åtgärd genom att tillämpa alla inställningar och starta om instanserna.

När som helst under växlingsåtgärden sker allt arbete med att initiera de växlade apparna på källplatsen. Målplatsen förblir online medan källplatsen förbereds och värms upp, oavsett var växlingen lyckas eller misslyckas. Om du vill byta mellanlagringsplats med produktionsplatsen kontrollerar du att produktionsplatsen alltid är målplatsen. På så sätt påverkar inte växlingsåtgärden din produktionsapp.

Anteckning

Instanserna i dina tidigare produktionsinstanser (de som kommer att växlas till mellanlagring efter den här växlingsåtgärden) kommer att återvinnas snabbt i det sista steget i växlingsprocessen. Om du har några långvariga åtgärder i ditt program kommer de att överges när arbetarna återvinner. Detta gäller även för funktionsappar. Därför bör programkoden skrivas på ett feltolerant sätt.

Vilka inställningar växlas?

När du klonar konfigurationen från ett annat distributionsfack kan den klonade konfigurationen redigeras. Vissa konfigurationselement följer innehållet i ett byte (inte fackspecifikt), medan andra konfigurationselement finns kvar på samma plats efter ett byte (platsspecifikt). I följande listor visas de inställningar som ändras när du byter fack.

Inställningar som växlas:

  • Allmänna inställningar, till exempel ramverksversion, 32/64-bitars, webbsocketar
  • Appinställningar (kan konfigureras för att hålla sig till ett fack)
  • Anslutningssträngar (kan konfigureras för att hålla sig till ett fack)
  • Hanterarmappningar
  • Offentliga certifikat
  • Webbjobbsinnehåll
  • Hybridanslutningar *
  • Tjänstslutpunkter *
  • Azure Content Delivery Network *
  • Sökvägsmappningar

Funktioner som markerats med en asterisk (*) planeras att vara oanvända.

Inställningar som inte växlas:

  • Publicera slutpunkter
  • Egna domännamn
  • Icke-offentliga certifikat och TLS/SSL-inställningar
  • Skalningsinställningar
  • WebJobs-schemaläggare
  • IP-begränsningar
  • Alltid på
  • Diagnostikinställningar
  • Resursdelning för korsande ursprung (CORS)
  • Virtual Network-integration
  • Hanterade identiteter
  • Inställningar som slutar med suffixet _EXTENSION_VERSION

Anteckning

Om du vill göra ovan nämnda inställningar utbytbara lägger du till appinställningen WEBSITE_OVERRIDE_PRESERVE_DEFAULT_STICKY_SLOT_SETTINGS i varje plats i appen och anger dess värde till 0 eller false. De här inställningarna kan antingen växlas eller inte alls. Du kan inte bara göra vissa inställningar utbytbara och inte de andra. Hanterade identiteter växlas aldrig och påverkas inte av den här åsidosättningsappinställningen.

Vissa appinställningar som gäller för oanvända inställningar växlas inte heller. Eftersom diagnostikinställningar till exempel inte växlas, så växlas relaterade appinställningar som WEBSITE_HTTPLOGGING_RETENTION_DAYS och DIAGNOSTICS_AZUREBLOBRETENTIONDAYS inte heller, även om de inte visas som platsinställningar.

Om du vill konfigurera en appinställning eller anslutningssträng för att hålla sig till ett visst fack (inte växlat) går du till sidan Konfiguration för det facket. Lägg till eller redigera en inställning och välj sedan inställningen för distributionsfack. Om du markerar den här kryssrutan visas App Service att inställningen inte kan växlas.

Platsinställning

Växla två fack

Du kan växla distributionsfack på sidan Distributionsfack för appen och på sidan Översikt . Teknisk information om fackbytet finns i Vad händer under växlingen.

Viktigt

Innan du växlar en app från ett distributionsfack till produktion kontrollerar du att produktionen är målplatsen och att alla inställningar i källplatsen är konfigurerade exakt som du vill ha dem i produktion.

Så här växlar du distributionsfack:

  1. Gå till sidan Distributionsfack för appen och välj Växla.

    Växla knapp

    Dialogrutan Växla visar inställningar i de valda käll- och målplatserna som kommer att ändras.

  2. Välj önskade käll- och målfack . Målet är vanligtvis produktionsplatsen. Välj även flikarna Källändringar och Måländringar och kontrollera att konfigurationsändringarna förväntas. När du är klar kan du växla facken direkt genom att välja Växla.

    Slutföra växlingen

    Om du vill se hur målplatsen skulle köras med de nya inställningarna innan växlingen faktiskt sker väljer du inte Växla, utan följer anvisningarna i Växla med förhandsversion.

  3. När du är klar stänger du dialogrutan genom att välja Stäng.

Om du har problem kan du läsa Felsöka växlingar.

Växla med förhandsversion (växling i flera faser)

Innan du växlar till produktion som målplats kontrollerar du att appen körs med de växlade inställningarna. Källfacket värms också upp innan bytet slutförs, vilket är önskvärt för verksamhetskritiska program.

När du utför en växling med förhandsversionen utför App Service samma växlingsåtgärd men pausar efter det första steget. Du kan sedan kontrollera resultatet på mellanlagringsplatsen innan du slutför växlingen.

Om du avbryter växlingen App Service återställer konfigurationselementen till källplatsen.

Anteckning

Växling med förhandsversion kan inte användas när någon av platserna har platsautentisering aktiverat.

Så här växlar du med förhandsversion:

  1. Följ stegen i Växla distributionsfack men välj Utför växling med förhandsversion.

    Växla med förhandsversion

    Dialogrutan visar hur konfigurationen i källfacket ändras i fas 1 och hur käll- och målplatsen ändras i fas 2.

  2. När du är redo att starta växlingen väljer du Starta växling.

    När fas 1 är klar meddelas du i dialogrutan. Förhandsgranska växlingen i källfacket genom att gå till https://<app_name>-<source-slot-name>.azurewebsites.net.

  3. När du är redo att slutföra den väntande växlingen väljer du Åtgärden Slutför växling i växling och väljer Slutför växling.

    Om du vill avbryta en väntande växling väljer du Avbryt växling i stället.

  4. När du är klar stänger du dialogrutan genom att välja Stäng.

Om du har problem kan du läsa Felsöka växlingar.

Information om hur du automatiserar en växling med flera faser finns i Automatisera med PowerShell.

Återställa en växling

Om det uppstår fel i målfacket (till exempel produktionsplatsen) efter en fackväxling återställer du platserna till deras förväxlingstillstånd genom att byta samma två platser omedelbart.

Konfigurera automatisk växling

Anteckning

Automatisk växling stöds inte i webbappar i Linux och Web App for Containers.

Automatisk växling effektiviserar Azure DevOps-scenarier där du vill distribuera din app kontinuerligt med noll kalla starter och noll stilleståndstid för appens kunder. När automatisk växling är aktiverat från en plats till produktion, varje gång du push-överför kodändringarna till det facket, App Service automatiskt växlar appen till produktion när den har värmts upp i källfacket.

Anteckning

Innan du konfigurerar automatisk växling för produktionsplatsen bör du överväga att testa automatisk växling på en målplats som inte är produktionsbaserad.

Så här konfigurerar du automatisk växling:

  1. Gå till appens resurssida. Välj Distributionsplatser><önskad källplats>>Konfiguration>Allmänna inställningar.

  2. För Automatisk växling aktiverad väljer du . Välj sedan önskad målplats för Distributionsfack för automatisk växling och välj Spara i kommandofältet.

    Val för att konfigurera automatisk växling

  3. Kör en kod push-överföring till källplatsen. Automatisk växling sker efter en kort tid och uppdateringen återspeglas på målplatsens URL.

Om du har problem kan du läsa Felsöka växlingar.

Ange anpassad uppvärmning

Vissa appar kan kräva anpassade uppvärmningsåtgärder före växlingen. Med applicationInitialization konfigurationselementet i web.config kan du ange anpassade initieringsåtgärder. Växlingsåtgärden väntar på att den här anpassade uppvärmningen ska slutföras innan den växlas med målplatsen. Här är ett exempel på ett web.config fragment.

<system.webServer>
    <applicationInitialization>
        <add initializationPage="/" hostName="[app hostname]" />
        <add initializationPage="/Home/About" hostName="[app hostname]" />
    </applicationInitialization>
</system.webServer>

Mer information om hur du anpassar elementet finns i De vanligaste växlingsfelen för distributionsfack och hur du åtgärdar dem.applicationInitialization

Du kan också anpassa uppvärmningsbeteendet med en eller båda av följande appinställningar:

  • WEBSITE_SWAP_WARMUP_PING_PATH: Sökvägen för att pinga över HTTP för att värma upp din webbplats. Lägg till den här appinställningen genom att ange en anpassad sökväg som börjar med ett snedstreck som värde. Ett exempel är /statuscheck. Standardvärdet är /.
  • WEBSITE_SWAP_WARMUP_PING_STATUSES: Giltiga HTTP-svarskoder för uppvärmningsåtgärden. Lägg till den här appinställningen med en kommaavgränsad lista med HTTP-koder. Ett exempel är 200,202 . Om den returnerade statuskoden inte finns i listan stoppas uppvärmnings- och växlingsåtgärderna. Som standard är alla svarskoder giltiga.
  • WEBSITE_WARMUP_PATH: En relativ sökväg på platsen som ska pingas när platsen startas om (inte bara under fackbyten). Exempelvärden är /statuscheck eller rotsökvägen. /

Anteckning

Konfigurationselementet <applicationInitialization> är en del av varje appstart, medan de två appinställningarna för uppvärmningsbeteende endast gäller för fackbyten.

Om du har problem kan du läsa Felsöka växlingar.

Övervaka ett byte

Om växlingsåtgärden tar lång tid att slutföra kan du få information om växlingsåtgärden i aktivitetsloggen.

Välj Aktivitetslogg i den vänstra rutan på appens resurssida i portalen.

En växlingsåtgärd visas i loggfrågan som Swap Web App Slots. Du kan expandera den och välja något av underåtgärderna eller felen för att se informationen.

Dirigera trafik

Som standard dirigeras alla klientbegäranden till appens produktions-URL (http://<app_name>.azurewebsites.net) till produktionsplatsen. Du kan dirigera en del av trafiken till ett annat fack. Den här funktionen är användbar om du behöver användarfeedback för en ny uppdatering, men du inte är redo att släppa den till produktion.

Dirigera produktionstrafik automatiskt

Så här dirigerar du produktionstrafik automatiskt:

  1. Gå till appens resurssida och välj Distributionsplatser.

  2. I kolumnen Trafik % för det fack som du vill dirigera till anger du en procentandel (mellan 0 och 100) som representerar den totala trafik som du vill dirigera. Välj Spara.

    Ange en trafikprocent

När inställningen har sparats dirigeras den angivna procentandelen klienter slumpmässigt till den icke-produktionsplatsen.

När en klient automatiskt dirigeras till en specifik plats "fästs" den på den platsen i en timme eller tills cookies tas bort. I klientwebbläsaren kan du se vilket fack sessionen fästs på genom att titta på cookien x-ms-routing-name i HTTP-huvudena. En begäran som dirigeras till "mellanlagringsplatsen" har cookien x-ms-routing-name=staging. En begäran som dirigeras till produktionsplatsen har cookien x-ms-routing-name=self.

Anteckning

Du kan också använda az webapp traffic-routing set kommandot i Azure CLI för att ange routningsprocenten från CI/CD-verktyg som GitHub Actions, DevOps-pipelines eller andra automatiseringssystem.

Dirigera produktionstrafik manuellt

Förutom automatisk trafikroutning kan App Service dirigera begäranden till ett visst fack. Det här är användbart när du vill att användarna ska kunna välja eller välja bort betaappen. Om du vill dirigera produktionstrafik manuellt använder du frågeparametern x-ms-routing-name .

Om du till exempel vill låta användarna välja bort betaappen kan du placera den här länken på din webbsida:

<a href="<webappname>.azurewebsites.net/?x-ms-routing-name=self">Go back to production app</a>

Strängen x-ms-routing-name=self anger produktionsplatsen. När klientwebbläsaren har åtkomst till länken omdirigeras den till produktionsplatsen. Varje efterföljande begäran har cookien x-ms-routing-name=self som fäster sessionen på produktionsplatsen.

Om du vill låta användarna välja betaappen anger du samma frågeparameter till namnet på den icke-produktionsplatsen. Här är ett exempel:

<webappname>.azurewebsites.net/?x-ms-routing-name=staging

Som standard får nya platser en routningsregel på 0%, som visas i grått. När du uttryckligen anger det här värdet till 0% (visas i svart text) kan användarna komma åt mellanlagringsplatsen manuellt med hjälp x-ms-routing-name av frågeparametern. Men de dirigeras inte automatiskt till platsen eftersom routningsprocenten är inställd på 0. Det här är ett avancerat scenario där du kan "dölja" mellanlagringsplatsen från allmänheten samtidigt som interna team kan testa ändringar på platsen.

Ta bort ett fack

Sök efter och välj din app. Välj Distributionsfack><för att ta bort>>Översikt. Apptypen visas som App Service (fack) för att påminna dig om att du visar ett distributionsfack. Innan du tar bort ett fack måste du stoppa facket och ställa in trafiken i facket på noll. Välj Ta bort i kommandofältet.

Ta bort ett distributionsfack

Automatisera med PowerShell

Anteckning

Vi rekommenderar att du använder Azure Az PowerShell-modulen för att interagera med Azure. Se Installera Azure PowerShell för att komma igång. Information om hur du migrerar till Az PowerShell-modulen finns i artikeln om att migrera Azure PowerShell från AzureRM till Az.

Azure PowerShell är en modul som tillhandahåller cmdletar för att hantera Azure via Windows PowerShell, inklusive stöd för hantering av distributionsfack i Azure App Service.

Information om hur du installerar och konfigurerar Azure PowerShell och om hur du autentiserar Azure PowerShell med din Azure-prenumeration finns i Installera och konfigurera Microsoft Azure PowerShell.


Skapa en webbapp

New-AzWebApp -ResourceGroupName [resource group name] -Name [app name] -Location [location] -AppServicePlan [app service plan name]

Skapa ett fack

New-AzWebAppSlot -ResourceGroupName [resource group name] -Name [app name] -Slot [deployment slot name] -AppServicePlan [app service plan name]

Initiera en växling med en förhandsversion (växling i flera faser) och tillämpa målplatskonfigurationen på källplatsen

$ParametersObject = @{targetSlot  = "[slot name – e.g. "production"]"}
Invoke-AzResourceAction -ResourceGroupName [resource group name] -ResourceType Microsoft.Web/sites/slots -ResourceName [app name]/[slot name] -Action applySlotConfig -Parameters $ParametersObject -ApiVersion 2015-07-01

Avbryt en väntande växling (växla med granskning) och återställ konfigurationen av källfacket

Invoke-AzResourceAction -ResourceGroupName [resource group name] -ResourceType Microsoft.Web/sites/slots -ResourceName [app name]/[slot name] -Action resetSlotConfig -ApiVersion 2015-07-01

Växla distributionsfack

$ParametersObject = @{targetSlot  = "[slot name – e.g. "production"]"}
Invoke-AzResourceAction -ResourceGroupName [resource group name] -ResourceType Microsoft.Web/sites/slots -ResourceName [app name]/[slot name] -Action slotsswap -Parameters $ParametersObject -ApiVersion 2015-07-01

Övervaka växlingshändelser i aktivitetsloggen

Get-AzLog -ResourceGroup [resource group name] -StartTime 2018-03-07 -Caller SlotSwapJobProcessor  

Ta bort ett fack

Remove-AzResource -ResourceGroupName [resource group name] -ResourceType Microsoft.Web/sites/slots –Name [app name]/[slot name] -ApiVersion 2015-07-01

För att utföra en platsväxling från produktionsplatsen behöver identiteten (minst) behörighet för att utföra Microsoft.Web/sites/slotsswap/Action åtgärden. Mer information finns i Resursprovideråtgärder

Automatisera med Resource Manager mallar

Azure Resource Manager-mallar är deklarativa JSON-filer som används för att automatisera distributionen och konfigurationen av Azure-resurser. Om du vill växla fack med hjälp av Resource Manager mallar anger du två egenskaper för resurserna Microsoft.Web/sites/slots och Microsoft.Web/sites:

  • buildVersion: Det här är en strängegenskap som representerar den aktuella versionen av appen som distribueras i facket. Till exempel: "v1", "1.0.0.1" eller "2019-09-20T11:53:25.2887393-07:00".
  • targetBuildVersion: Det här är en strängegenskap som anger vad buildVersion platsen ska ha. Om targetBuildVersion inte är lika med den aktuella buildVersionutlöser detta växlingsåtgärden genom att hitta platsen som har den angivna buildVersion.

Exempel på Resource Manager mall

Följande Resource Manager mall uppdaterar buildVersion mellanlagringsplatsen och anger targetBuildVersion på produktionsplatsen. Detta växlar de två platserna. Mallen förutsätter att du redan har skapat en webbapp med ett fack med namnet "staging".

{
    "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
    "contentVersion": "1.0.0.0",
    "parameters": {
        "my_site_name": {
            "defaultValue": "SwapAPIDemo",
            "type": "String"
        },
        "sites_buildVersion": {
            "defaultValue": "v1",
            "type": "String"
        }
    },
    "resources": [
        {
            "type": "Microsoft.Web/sites/slots",
            "apiVersion": "2018-02-01",
            "name": "[concat(parameters('my_site_name'), '/staging')]",
            "location": "East US",
            "kind": "app",
            "properties": {
                "buildVersion": "[parameters('sites_buildVersion')]"
            }
        },
        {
            "type": "Microsoft.Web/sites",
            "apiVersion": "2018-02-01",
            "name": "[parameters('my_site_name')]",
            "location": "East US",
            "kind": "app",
            "dependsOn": [
                "[resourceId('Microsoft.Web/sites/slots', parameters('my_site_name'), 'staging')]"
            ],
            "properties": {
                "targetBuildVersion": "[parameters('sites_buildVersion')]"
            }
        }        
    ]
}

Den här Resource Manager mallen är idempotent, vilket innebär att den kan köras upprepade gånger och generera samma tillstånd för platserna. Efter den första körningen targetBuildVersion matchar den aktuella buildVersion, så en växling utlöses inte.

Automatisera med CLI

Azure CLI-kommandon för distributionsplatser finns i az webapp deployment slot (Az webapp deployment slot).

Felsöka växlingar

Om ett fel inträffar under ett fackbyte loggas det in D:\home\LogFiles\eventlog.xml. Den loggas också i den programspecifika felloggen.

Här är några vanliga växlingsfel:

  • En HTTP-begäran till programroten är tidstimerad. Växlingsåtgärden väntar i 90 sekunder för varje HTTP-begäran och försöker igen upp till 5 gånger. Om alla återförsök överskrids stoppas växlingsåtgärden.

  • Den lokala cacheinitieringen kan misslyckas när appinnehållet överskrider den lokala diskkvot som angetts för det lokala cacheminnet. Mer information finns i Översikt över lokalt cacheminne.

  • Under den anpassade uppvärmningen görs HTTP-begäranden internt (utan att gå igenom den externa URL:en). De kan misslyckas med vissa URL-omskrivningsregler i Web.config. Regler för att omdirigera domännamn eller framtvinga HTTPS kan till exempel förhindra att uppvärmningsbegäranden når appkoden. Lös problemet genom att ändra omskrivningsreglerna genom att lägga till följande två villkor:

    <conditions>
      <add input="{WARMUP_REQUEST}" pattern="1" negate="true" />
      <add input="{REMOTE_ADDR}" pattern="^100?\." negate="true" />
      ...
    </conditions>
    
  • Utan en anpassad uppvärmning kan reglerna för URL-omskrivning fortfarande blockera HTTP-begäranden. Lös problemet genom att ändra omskrivningsreglerna genom att lägga till följande villkor:

    <conditions>
      <add input="{REMOTE_ADDR}" pattern="^100?\." negate="true" />
      ...
    </conditions>
    
  • Efter fackbyten kan appen få oväntade omstarter. Detta beror på att värdnamnsbindningskonfigurationen efter ett byte inte synkroniseras, vilket i sig inte orsakar omstarter. Vissa underliggande lagringshändelser (till exempel redundansväxlingar för lagringsvolymer) kan dock identifiera dessa avvikelser och tvinga alla arbetsprocesser att starta om. Om du vill minimera dessa typer av omstarter anger du appinställningenWEBSITE_ADD_SITENAME_BINDINGS_IN_APPHOST_CONFIG=1alla platser. Den här appinställningen fungerar dock inte med WCF-appar (Windows Communication Foundation).

Nästa steg

Blockera åtkomst till platser som inte är produktionsplatser