Konfigurera mellanlagringsmiljöer i Azure App Service

Artikel
02/12/2023
16 minuter för att läsa

När du distribuerar webbappen, webbappen i Linux, den mobila serverdelen eller API-appen 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. Distributionsfack är live-appar med egna värdnamn. Appinnehåll och konfigurationselement kan växlas mellan två distributionsplatser, inklusive produktionsplatsen.

Distribution 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 en tidigare mellanlagrad app 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 fungerande webbplats".

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

Om du vill skala appen 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 standardnivå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.

i Azure Portal söker du efter och väljer App Services och väljer din app.
I den vänstra rutan väljer du Distributionsfack>Lägg till fack.

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 aktivering av mellanlagrad publicering. Nu har du möjlighet att välja Uppgradera och gå till fliken Skala för din app innan du fortsätter.
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.

Du kan klona en konfiguration från valfri befintlig plats. Inställningar som kan klonas omfattar appinställningar, anslutningssträngar, språkramverksversioner, webbsocketar, HTTP-version och plattformsbithet.

Anteckning

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

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.
Välj det nya distributionsfacket för att öppna platsens resurssida.

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>/<facknamn> och apptypen är App Service (fack). Du kan också se facket som en separat app i resursgruppen med samma beteckningar.
Välj app-URL:en på platsens resurssida. Distributionsfacket har ett eget värdnamn och är också en live-app. Information om hur du begränsar offentlig åtkomst till distributionsfacket 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 facket 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 distribution till platsen. Profilen kan importeras av Visual Studio för att distribuera innehåll till facket.

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 webbplatsnamnet 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 ett byte?

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 får avbrottstid:

Tillämpa följande inställningar från målplatsen (till exempel produktionsplatsen) på alla instanser av källplatsen:
- Platsspecifika appinställningar och anslutningssträngar, om tillämpligt.
- Inställningar för kontinuerlig distribution , om de är aktiverade.
- App Service autentiseringsinställningar om det är aktiverat.
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 har pausats och du kan kontrollera att källplatsen fungerar korrekt med målfackets inställningar.
Vänta tills alla instanser i källplatsen har slutfört omstarten. Om någon instans inte kan startas om återställer växlingsåtgärden alla ändringar till källplatsen och stoppar åtgärden.
Om lokal cache är aktiverad utlöser du lokal cacheinitiering genom att göra en HTTP-begäran till programroten ("/") på varje instans av källplatsen. Vänta tills varje instans returnerar ett HTTP-svar. Initiering av lokal cache orsakar ytterligare en omstart på varje instans.
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 ett HTTP-svar anses den vara uppvärmd.
Om alla instanser på källplatsen har värmts upp växlar du de två facken 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.
Nu när källplatsen har förväxlingsappen tidigare i målfacket 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 växla en 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) återanvänds snabbt i det sista steget i växlingsprocessen. Om du har långvariga åtgärder i ditt program kommer de att överges när arbetarna återanvänds. Detta gäller även för funktionsappar. Därför bör programkoden skrivas på ett feltolerant sätt.

Vilka inställningar byts ut?

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 (fackspecifikt). I följande listor visas de inställningar som ändras när du byter fack.

Inställningar som byts ut:

Allmänna inställningar, till exempel ramverksversion, 32/64-bitars webbsocket
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:

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

Dialogrutan Växla visar inställningar i de valda käll- och målplatserna som kommer att ändras.
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.

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.
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:

Följ stegen i Växla distributionsfack men välj Utför växling 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.
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.
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.
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 ett fackbyte å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:

Gå till appens resurssida. Välj Distributionsplatser><önskad källplats>>Konfiguration>Allmänna inställningar.
För Automatisk växling aktiverad väljer du På. Välj sedan önskad målplats för Distributionsfack för automatisk växling och välj Spara i kommandofältet.
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:

Gå till appens resurssida och välj Distributionsplatser.
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.

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 ange trafiken i facket till 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äxling av 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=1 på alla 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

Konfigurera mellanlagringsmiljöer i Azure App Service

Lägga till ett fack

Vad händer under ett byte?

Växlingsåtgärdssteg

Vilka inställningar byts ut?

Växla två fack

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

Återställa en växling

Konfigurera automatisk växling

Ange anpassad uppvärmning

Övervaka ett byte

Dirigera trafik

Dirigera produktionstrafik automatiskt

Dirigera produktionstrafik manuellt

Ta bort ett fack

Automatisera med PowerShell

Skapa en webbapp

Skapa ett fack

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

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

Växla distributionsfack

Övervaka växlingshändelser i aktivitetsloggen

Ta bort ett fack

Automatisera med Resource Manager mallar

Exempel på Resource Manager mall

Automatisera med CLI

Felsöka växlingar

Nästa steg

Ytterligare resurser

Ytterligare resurser