Konfigurera mellanlagringsmiljöer i Azure App Service

När du distribuerar webbappen, webbappen på Linux, den mobila backend-appen eller API-appen till Azure App Servicekan 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 live-appar med egna värdnamn. Appinnehåll och konfigurationselement kan växlas mellan två distributionsfack, inklusive produktionsplatsen.

Att distribuera ditt program till en plats som inte är en 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 i förväg inte behövs.
  • Efter en växling har facket med tidigare mellanfasad app nu den tidigare produktionsappen. Om ändringarna som växlades till produktionsplatsen inte är som förväntat kan du utföra samma växling omedelbart för att få tillbaka din "senast kända bra plats".

Varje App Service plan 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 som din appnivå 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 din app redan använder. Om din app till exempel har fler än fem platser kan du inte skala ned den till standardnivån eftersom standardnivån endast stöder fem distributionsfack.

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

  1. i Azure Portalsö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 fack.

    Lägg till en ny distributionsplats

    Anteckning

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

  3. I dialogrutan Lägg till ett fack ger du facket 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 bland annat appinställningar, anslutningssträngar, språkramverksversioner, webbsocketar, HTTP-version och plattformsbithet.

  4. 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 Traffic % inställt på 0 för den nya platsen, där all kundtrafik dirigeras till produktionsplatsen.

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

    Distributionsfackrubrik

    Mellanlagringsplatsen har en hanteringssida precis som andra App Service app. Du kan ändra platsens konfiguration. För att påminna dig om att du visar distributionsfacket visas appnamnet som , och apptypen är <app-name>/<slot-name> App Service (fack). Du kan också se facket som en separat app i resursgruppen med samma beteckningar.

  6. Välj appens URL 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 en annan plats. 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.

Platsens URL har 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

Steg för växlingsåtgärd

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 drabbas av driftstopp:

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

    Alla dessa fall utlöser att alla instanser på källplatsen startas om. Under växling med förhandsversionmarkerar detta slutet på den första fasen. Växlingsåtgärden har pausats och du kan verifiera att källfacket fungerar korrekt med målplatsens inställningar.

  2. Vänta tills varje instans i källfacket har startats om. Om någon instans inte startar om återställer växlingsåtgärden alla ändringar till källfacket 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 ett HTTP-svar. Initiering av lokal cache gör att varje instans startas om på nytt.

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

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

    Om en instans returnerar ett HTTP-svar anses den vara varm.

  5. Om alla instanser på källplatsen har värmets upp kan du växla de två platserna genom att byta routningsregler 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ällfacket.

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

Vid vilken tidpunkt som helst av växlingsåtgärden utförs allt arbete med att initiera de växlade apparna på källplatsen. Målplatsen förblir online medan källfacket 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 tas bort när arbetarna återanvänder. 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 över en växling (inte fackspecifik), medan andra konfigurationselement finns kvar på samma plats efter en växling (fackspecifik). I följande listor visas de inställningar som ändras när du växlar platser.

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 en plats)
  • Hanterarmappningar
  • Offentliga certifikat
  • WebJobs-innehåll
  • Hybridanslutningar *
  • Tjänstslutpunkter *
  • Azure Content Delivery Network *
  • Sökvägsmappningar

Funktioner som markerats med en asterisk (*) planeras att tas bort.

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 slutar med suffixet _EXTENSION_VERSION

Anteckning

Om du vill att tidigare nämnda inställningar ska kunna växlas lägger du till appinställningen i varje fack i appen WEBSITE_OVERRIDE_PRESERVE_DEFAULT_STICKY_SLOT_SETTINGS och anger värdet till eller 0 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 byts aldrig ut och påverkas inte av den här åsidosättningsappinställningen.

Vissa appinställningar som gäller för ej använda inställningar växlas inte heller. Eftersom diagnostikinställningar till exempel inte växlas växlar relaterade appinställningar som och inte heller, även om de inte WEBSITE_HTTPLOGGING_RETENTION_DAYS DIAGNOSTICS_AZUREBLOBRETENTIONDAYS visas som fackinställningar.

Om du vill konfigurera en appinställning eller anslutningssträng så att den håller 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 distributionsfackinställning. Om du markerar den här kryssrutan App Service anger att inställningen inte kan växlas.

Fackinställning

Växla två fack

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

Viktigt

Innan du växlar en app från ett distributionsfack till produktion kontrollerar du att produktion är målplatsen och att alla inställningar på 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 din app och välj Växla.

    Växlingsknapp

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

  2. Välj önskade käll- och målplatser. Målet är vanligtvis produktionsplatsen. Välj också flikarna Källändringar och Måländringar och kontrollera att konfigurationsändringarna är förväntade. 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ålfacket skulle köras med de nya inställningarna innan växlingen faktiskt sker väljer du inte Växla , utan följer instruktionerna 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 gå till 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 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 konfigurationselementen på nytt till källfacket.

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 Slutför växling i växlingsåtgärden 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 gå till Felsöka växlingar.

Information om hur du automatiserar ett byte i flera faser finns i Automatisera med PowerShell.

Återställa en växling

Om det uppstår fel på målplatsen (till exempel produktionsplatsen) efter ett byte återställer du facken till deras förväxlings tillstånd genom att växla 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 kallstarter och noll driftstopp för appens kunder. När automatisk växling har aktiverats från en plats till produktion växlar App Service automatiskt appen till produktion varje gång du pushar kodändringarna till det facket.

Anteckning

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

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

  1. Gå till appens resurssida. Välj Distributionsfack > <desired source slot> > Konfiguration > Allmänna inställningar.

  2. För Automatiskt växling aktiverat väljer du . Välj sedan önskat målfack för Automatisk växling av distributionsfack och välj Spara i kommandofältet.

    Val för att konfigurera automatisk växling

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

Om du har problem kan du gå till Felsöka växlingar.

Ange anpassad uppvärmning

Vissa appar kan kräva anpassade uppvärmningsåtgärder före bytet. 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 du växlar med målplatsen. Här är ett exempel på 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 applicationInitialization elementet finns i De vanligaste distributionsfackväxlingsfelen och hur du åtgärdar dem.

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 via HTTP för att värma upp webbplatsen. 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ärder. 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 fackväxlingar). Exempelvärden inkluderar /statuscheck eller rotsökvägen, / .

Anteckning

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

Om du har problem kan du gå till Felsöka växlingar.

Övervaka en växling

Om växlingsåtgärden tar lång tid att slutföra kan du hämta 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 en av delå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 en annan plats. 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 i produktion.

Dirigera produktionstrafik automatiskt

Så här dirigerar du produktionstrafik automatiskt:

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

  2. I kolumnen Trafik % för den plats 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 icke-produktionsplatsen.

När en klient automatiskt dirigeras till en specifik plats "fästs" den på det facket under klientsessionens livslängd. I klientwebbläsaren kan du se vilket fack sessionen är fäst på genom att titta på x-ms-routing-name cookien 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 kommandot i Azure CLI för att ange dirigeringsprocent från az webapp traffic-routing set 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 en specifik plats. Detta är användbart när du vill att användarna ska kunna välja att använda eller välja bort din betaapp. Om du vill dirigera produktionstrafik manuellt använder du x-ms-routing-name frågeparametern .

Om du till exempel vill att användarna ska kunna välja bort din betaapp kan du lägga till 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 x-ms-routing-name=self cookien som fäster sessionen på produktionsplatsen.

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

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

Som standard får nya platser routningsregeln 0% , som visas i grått. När du uttryckligen anger det här värdet till (visas i svart text) kan användarna komma åt 0% mellanlagringsplatsen manuellt med hjälp av x-ms-routing-name frågeparametern. Men de dirigeras inte till platsen automatiskt eftersom dirigeringsprocenten ä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 > <slot to delete> > Översikt. Apptypen visas som en App Service (fack) för att påminna dig om att du visar ett distributionsfack. Välj Ta bort i kommandofältet.

Ta bort ett distributionsfack

Automatisera med PowerShell

Anteckning

I den här artikeln används Azure Az PowerShell-modulen, som är den rekommenderade PowerShell-modulen för att interagera med Azure. För att komma igång med Az PowerShell kan du läsa artikeln om att installera Azure PowerShell. 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 innehåller cmdlets för att hantera Azure via Windows PowerShell, inklusive stöd för att hantera 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örhandsgranskning (växling i flera faser) och tillämpa målplatskonfigurationen på källfacket

$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 (byt med granskning) och återställ konfigurationen för 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

Automatisera med Resource Manager mallar

Azure Resource Manager är deklarativa JSON-filer som används för att automatisera distributionen och konfigurationen av Azure-resurser. Om du vill växla fack med 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 distribuerats i facket. 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 buildVersion vad facket ska ha. Om targetBuildVersion inte är lika med den aktuella utlöser detta växlingsåtgärden genom att hitta buildVersion platsen som har angiven buildVersion .

Exempel Resource Manager mall

Följande Resource Manager uppdaterar för buildVersion mellanlagringsplatsen och anger targetBuildVersion på produktionsplatsen. Detta kommer att växla mellan de två facken. Mallen förutsätter att du redan har en webbapp som skapats 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 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 targetBuildVersion körningen matchar den aktuella buildVersion , så en växling utlöses inte.

Automatisera med CLI

Azure CLI-kommandon för distributionsfack finns i az webapp deployment slot.

Felsöka växlingar

Om något fel inträffar under ett byteloggas det in i 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 har en tidsendd. 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 har upphört att fungera stoppas växlingsåtgärden.

  • Initiering av lokal cache kan misslyckas när appinnehållet överskrider den lokala diskkvot som angetts för den lokala cachen. Mer information finns i Översikt över lokal cache.

  • Under anpassad uppvärmning görs HTTP-begärandeninternt (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. Du kan komma runt det här problemet genom att ändra reglerna för omskrivning 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 URL-omskrivningsregler fortfarande blockera HTTP-begäranden. Du kan komma runt det här problemet genom att ändra reglerna för omskrivning genom att lägga till följande villkor:

    <conditions>
      <add input="{REMOTE_ADDR}" pattern="^100?\." negate="true" />
      ...
    </conditions>
    
  • Efter fackväxlingar kan det uppstå oväntade omstarter i appen. Det beror på att efter en växling blir konfigurationen för värdnamnsbindningen inte synkroniserad, vilket i sig inte orsakar omstarter. Vissa underliggande lagringshändelser (till exempel redundans för lagringsvolym) kan dock identifiera dessa avvikelser och tvinga alla arbetsprocesser att starta om. Om du vill minimera dessa typer av omstarter anger du WEBSITE_ADD_SITENAME_BINDINGS_IN_APPHOST_CONFIG=1 appinställningenalla platser. Den här appinställningen fungerar dock inte med Windows WCF-appar (Communication Foundation).

Nästa steg

Blockera åtkomst till platser som inte är produktionsplatser