Konfigurera mellanlagringsmiljöer i Azure App Service
Kommentar
Från och med den 1 juni 2024 har alla nyligen skapade App Service-appar möjlighet att generera ett unikt standardvärdnamn med hjälp av namngivningskonventionen <app-name>-<random-hash>.<region>.azurewebsites.net. Befintliga appnamn förblir oförändrade.
Exempel: myapp-ds27dh7271aah175.westus-01.azurewebsites.net
Mer information finns i Unikt standardvärdnamn för App Service-resurs.
När du distribuerar din webbapp, webbapp på Linux, mobil serverdel eller API-app till Azure App Service kan du använda ett separat distributionsfack i stället för standardproduktionsplatsen när 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 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 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 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 eftersom Standard-nivån endast stöder fem distributionsplatser.
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 platså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.
I den vänstra rutan väljer du Distributionsplatser>Lägg till fack.
Kommentar
Om appen inte redan finns på nivån Standard, Premium eller Isolerad väljer du Uppgradera och går till fliken Skala i appen innan du fortsätter.
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.
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.
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 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-appar. Du kan ändra platsens konfiguration. För att påminna dig om att du visar distributionsfacket visas appnamnet som appnamn>/<facknamn> och apptypen är App Service (Slot).< Du kan också se facket som en separat app i resursgruppen med samma beteckningar.
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. Profilen kan importeras av Visual Studio 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 platsnamnet med 40 tecken och det kombinerade platsnamnet 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 (vanligtvis från en mellanlagringsplats som källa till produktionsplatsen som mål) gör App Service följande för att säkerställa att målplatsen inte upplever driftstopp:
Tillämpa följande inställningar från målplatsen (till exempel produktionsplatsen) på alla instanser av källfacket:
- Platsspecifika appinställningar och anslutningssträng, om tillämpligt.
- Inställningar för kontinuerlig distribution , om det är aktiverat.
- App Service-autentiseringsinställningar , om de är aktiverade.
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 detta slutet på den första fasen. Växlingsåtgärden har pausats och du kan kontrollera att källfacket fungerar korrekt med målplatsens inställningar.
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.
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.
Om automatisk växling är aktiverat med anpassad uppvärmning utlöser du den anpassade programinitiering på varje instans av källfacket.
Om
applicationInitializationinte 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.
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.
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
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 några tidskrävande å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 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 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 ovan nämnda inställningar 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 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ä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 (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 ser du till att inställningen inte kan växlas.
Växla två fack
Du kan växla distributionsfack på appens distributionsfacksida och sidan Översikt. Teknisk information om fackbytet finns i Vad händer under bytet.
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:
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 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.
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.
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 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:
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.
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 Slutför växling i växlingsåtgärd och väljer Slutför växling.
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.
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.
Å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:
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 till källfacket. 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 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 en eller båda av 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 är200,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/statuscheckeller rotsökvägen,/.
Kommentar
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 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:
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) för att representera mängden total trafik som du vill dirigera. Välj Spara.
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å 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. Detta är användbart när du vill att dina användare ska kunna välja att använda 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. Men de dirigeras inte automatiskt till facket 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 (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.
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: 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 vadbuildVersionfacket ska ha.targetBuildVersionOm inte är lika med den aktuellabuildVersionutlöser den växlingsåtgärden genom att hitta platsen med angivenbuildVersion.
Exempel på Resource Manager-mall
Följande Resource Manager-mall växlar två platser genom att uppdatera buildVersion staging platsen och ange targetBuildVersion på produktionsplatsen. Det förutsätter att du har skapat 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. 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 ett fel uppstår under ett fackbyte loggas det 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 "Det går inte att ändra facket eftersom dess konfigurationsinställningar har förberetts för växling". Detta kan inträffa om antingen växling med förhandsversion (växling med flera faser) fas 1 har slutförts men fas 2 ännu inte har utförts eller om en växling har misslyckats. 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
Se växling med förhandsversion (växling i flera faser) för att lära dig hur du avbryter eller slutför växlingsåtgärden.
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. Detta beror på att konfigurationen för värdnamnsbindning efter ett byte inte är synkroniserad, vilket i sig inte orsakar omstarter. Vissa underliggande lagringshändelser (till exempel redundansväxlingar i 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=1på alla platser. Den här appinställningen fungerar dock inte med WCF-appar (Windows Communication Foundation).