Dela via

Konfigurera mellanlagringsmiljöer i Azure App Service

  • Artikel

Kommentar

Från och med den 1 juni 2024 kan nyligen skapade App Service-appar generera ett unikt standardvärdnamn som använder namngivningskonventionen <app-name>-<random-hash>.<region>.azurewebsites.net. Befintliga appnamn förblir oförändrade. Till exempel:

myapp-ds27dh7271aah175.westus-01.azurewebsites.net

Mer information finns i Unikt standardvärdnamn för App Service-resurs.

När du distribuerar webbappen, webbappen i Linux, mobil serverdelen eller API-appen till Azure App Service kan du använda ett separat distributionsfack i stället för standardproduktionsplatsen. Den här metoden är tillgänglig om du kör på plannivån Standard, Premium eller Isolerad App Service. Distributionsfack är liveappar med egna värdnamn. Det går att byta ut appinnehåll och konfigurationselement mellan två distributionsfack, inklusive produktionsplatsen.

Att distribuera ditt program till en icke-produktionsplats har följande fördelar:

  • Du kan verifiera appändringar i ett distributionsfack för mellanlagring innan du byter den med produktionsplatsen.
  • När du distribuerar en app till ett fack först och byter den till produktion ser du till att alla instanser av facket värms upp innan du byter den till produktion. Den här metoden eliminerar stilleståndstid när du distribuerar din app. Trafikomdirigeringen är sömlös. 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 mellanlagrad app nu den tidigare produktionsappen. Om ändringarna som växlas 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 webbplats .

Varje App Service-plannivå stöder olika antal distributionsplatser. Det kostar inget extra för användning av distributionsplatser. Information om hur många platser som appens nivå stöder finns i Begränsningar för App Service.

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 standardnivån . Standardnivån stöder endast fem distributionsfack.

Den här videon visar hur du konfigurerar mellanlagringsmiljöer i Azure App Service.

Stegen i videon beskrivs också i följande avsnitt.

Förutsättningar

  • Information om vilka behörigheter du behöver för att utföra den fackåtgärd du vill använda finns i Resursprovideråtgärder. Sök efter fack, till exempel.

Lägga till en plats

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 navigerar du till appens hanteringssida.

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

    Kommentar

    Om appen inte redan finns på nivån Standard, Premium eller Isolerad väljer du Uppgradera. Gå till fliken Skala i appen 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.

    Skärmbild som visar hur du konfigurerar ett nytt distributionsfack med namnet

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

    Kommentar

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

  4. När du har angett inställningarna 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 det nya facket, där all kundtrafik dirigeras till produktionsplatsen.

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

    Skärmbild som visar hur du öppnar distributionsfackets hanteringssida i portalen.

    Mellanlagringsplatsen har en hanteringssida precis som andra App Service-appar. Du kan ändra platsens konfiguration. För att påminna dig om att du visar distributionsfacket visas appnamnet som appnamn>/<facknamn>.< Apptypen är App Service (Slot). 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 liveapp. Information om hur du begränsar offentlig åtkomst till distributionsfacket finns i IP-begränsningar för Azure App Service.

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 publiceringsprofil från Azure App Service kan tillhandahålla nödvändig information för distribution till facket. Visual Studio kan importera profilen för att distribuera innehåll till facket.

Fackets URL har formatet http://sitename-slotname.azurewebsites.net. Om du vill hålla URL-längden inom nödvändiga DNS-gränser trunkeras webbplatsnamnet med 40 tecken. Det kombinerade webbplatsnamnet och platsnamnet måste vara färre än 59 tecken.

Vad händer under ett byte

Växlingsåtgärdssteg

När du växlar två platser gör App Service följande för att säkerställa att målfacket inte upplever driftstopp:

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

    När någon av inställningarna tillämpas på källplatsen utlöser ändringen alla instanser i källfacket för omstart. Under växling med förhandsversion markerar den här åtgärden slutet på den första fasen. Växlingsåtgärden har pausats. Du kan kontrollera att källfacket fungerar korrekt med målfackets inställningar.

  2. Vänta tills alla instanser i källfacket har slutfört omstarten. Om det inte går att starta om någon instans återställer växlingsåtgärden alla ändringar i 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ällfacket. 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 den anpassade programinitiering på varje instans av källfacket.

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

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

  5. Om alla instanser på källfacket värms 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ällfacket.

  6. Nu när källfacket 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ällfacket. Målfacket förblir online medan källfacket förbereds och värms upp, oavsett om 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.

Kommentar

Dina tidigare produktionsinstanser växlas till mellanlagring efter den här växlingsåtgärden. Dessa instanser återvinns i det sista steget i växlingsprocessen. Om du har några tidskrävande åtgärder i ditt program överges de 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 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). 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 växlas:

  • Språkstack och version, 32/64-bitars
  • 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)
  • Monterade lagringskonton (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 har markerats med en asterisk (*) planeras att vara oanvända.

Inställningar som inte byts ut:

  • Allmänna inställningar som inte nämns i Inställningar som 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 och relaterade inställningar
  • Inställningar som slutar med suffixet _EXTENSION_VERSION
  • Inställningar som skapats av Service Connector

Kommentar

Om du vill göra inställningarna utbytbara lägger du till appinställningen WEBSITE_OVERRIDE_PRESERVE_DEFAULT_STICKY_SLOT_SETTINGS på 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. Den här åsidosättningsappinställningen påverkar dem inte.

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

Om du vill konfigurera en appinställning eller anslutningssträng att hålla sig till ett visst fack, som inte växlas, går du till sidan Miljövariabel för inställningar>för det facket. Lägg till eller redigera en inställning och välj sedan inställningen Distributionsfack. Om du väljer det här alternativet ser du till att inställningen inte kan växlas.

Skärmbild som visar hur du konfigurerar en appinställning som en platsinställning i Azure Portal.

Växla två fack

Du kan växla distributionsfack på appens distributionsfacksida och sidan Översikt. Mer information om fackbytet finns i Vad händer under växlingen.

Viktigt!

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

Så här byter du distributionsfack:

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

    Skärmbild som visar hur du initierar en växlingsåtgärd i portalen.

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

  2. Välj önskade käll- och målfack . Målet är vanligtvis produktionsplatsen. Välj också 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.

    En skärmbild som visar hur du konfigurerar och slutför en växling i portalen.

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

  3. När du är klar väljer du Stäng för att stänga dialogrutan.

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

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

Innan du byter 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örhandsversion 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 återställer App Service konfigurationselementen till källfacket.

Kommentar

Växla 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.

    Dialogrutan visar hur konfigurationen i källfacket ändras i fas 1 och hur käll- och målfacket ä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 meddelar dialogrutan dig. 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ärd och väljer Slutför växling.

    Skärmbild som visar hur du konfigurerar en växling med förhandsversion i portalen.

    Om du vill avbryta ett väntande byte väljer du Avbryt växling i stället och väljer sedan Avbryt växling längst ned.

  4. När du är klar väljer du Stäng för att stänga dialogrutan.

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

Återställa ett byte

Om det uppstår fel i målfacket (till exempel produktionsplatsen) efter ett fackbyte återställer du platserna till deras lägen före växlingen genom att byta samma två platser omedelbart.

Konfigurera automatisk växling

Kommentar

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 kallstart och noll stilleståndstid för appens kunder. När automatisk växling är aktiverad från en plats till produktion, varje gång du push-överför kodändringarna till det facket, byter App Service automatiskt appen till produktion när den har värmts upp i källfacket.

Kommentar

Innan du konfigurerar automatisk växling för produktionsplatsen bör du överväga att testa automatisk växling på ett målfack som inte är produktionsobjekt.

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

  1. Gå till appens resurssida. Välj Distributionsdistributionsplatser<>>önskat källfack.>

  2. I den vänstra rutan väljer du Inställningar>Konfiguration>Allmänna inställningar.

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

    Skärmbild som visar hur du konfigurerar automatisk växling till produktionsplatsen i portalen.

  4. Kör en kod push-överföring till källfacket. Automatisk växling sker efter en kort tid. 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 tills den här anpassade uppvärmningen har slutförts innan den byts ut mot målfacket. 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 applicationInitialization för distributionsfack och hur du åtgärdar dem.

Du kan också anpassa uppvärmningsbeteendet med följande appinställningar:

  • WEBSITE_SWAP_WARMUP_PING_PATH: Sökvägen till att pinga via 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 inkluderar /statuscheck eller rotsökvägen, /.

Kommentar

Konfigurationselementet <applicationInitialization> är en del av varje appstart, medan 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 produktionstrafik automatiskt

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.

Så här dirigerar du produktionstrafik automatiskt:

  1. Gå till resurssidan för webbappen 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) för att representera mängden total trafik som du vill dirigera. Välj Spara.

    Skärmbild som visar hur du dirigerar en procentandel av begärandetrafiken till ett distributionsfack i portalen.

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

Dirigera produktionstrafik manuellt

Utöver automatisk trafikroutning kan App Service dirigera begäranden till ett visst fack. Det här alternativet ä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 din betaapp 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. De dirigeras inte automatiskt till facket eftersom routningsprocenten är inställd på 0. Den här konfigurationen ä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 (Slot) 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.

Skärmbild som visar hur du tar bort ett distributionsfack i portalen.

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 byta fack med hjälp av Resource Manager-mallar anger du två egenskaper för resurserna Microsoft.Web/sites/slots och Microsoft.Web/sites :

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

Exempel på Resource Manager-mall

Följande Resource Manager-mall växlar två platser genom att uppdatera buildVersionstaging platsen och ange targetBuildVersion på produktionsplatsen. Du måste ha ett fack som heter 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. Du kan köra den upprepade gånger och skapa samma tillstånd för platserna. Utan någon ändring av mallen utlöser efterföljande körningar av samma mall inte något fackbyte eftersom platserna redan är i önskat tillstånd.

Felsöka växlingar

Om något fel uppstår under ett fackbyte visas felet i D:\home\LogFiles\eventlog.xml. Den loggas också i den programspecifika felloggen.

Här följer några vanliga växlingsfel:

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

  • Initieringen 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 en platsuppdateringsåtgärd kan följande fel inträffa Platsen kan inte ändras eftersom dess konfigurationsinställningar har förberetts för växling. Det här felet kan inträffa om växling med förhandsversion (växling med flera faser) fas 1 slutförs, men fas 2 ännu inte har utförts. Det kan också inträffa om ett byte misslyckades. Det finns två sätt att lösa det här problemet:

    • Avbryt växlingsåtgärden som återställer platsen till det gamla tillståndet
    • Slutför växlingsåtgärden som uppdaterar platsen till önskat nytt tillstånd

    Information om hur du avbryter eller slutför växlingsåtgärden finns i växla med förhandsversion (växling med flera faser).

  • 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 begäranden om uppvärmning når appkoden. Du kan lösa det här 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 URL-omskrivningsreglerna 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 uppleva oväntade omstarter. Omstarterna sker eftersom konfigurationen för värdnamnsbindningen inte synkroniseras efter ett byte. Den här situationen i sig orsakar inte omstarter. Vissa underliggande lagringshändelser, till exempel redundansväxlingar för lagringsvolymer, kan dock identifiera dessa avvikelser och tvinga alla arbetsprocesser att startas om. Om du vill minimera dessa typer av omstarter anger du appinställningen WEBSITE_ADD_SITENAME_BINDINGS_IN_APPHOST_CONFIG=1 på alla platser. Den här appinställningen fungerar dock inte med WCF-appar (Windows Communication Foundation).

Gå vidare

Blockera åtkomst till icke-produktionsfack