Distributionsplatser och växling

Distributionsplatser är aktiva, separata miljöer för en App Service-webbapp, där varje miljö har ett eget värdnamn (till exempel myapp-staging.azurewebsites.net). Platserna delar samma App Service-plan och resurser som produktionsplatsen, men körs oberoende av varandra. De möjliggör blue-green-distributioner — ni validerar en ny version på en staging-plats och byter sedan plats så att den hamnar i produktion utan driftstopp. Platser är tillgängliga från Standard-nivån och uppåt.

Lägg till en ny distributionsplats i webbappen med hjälp av Azure-portalen eller CLI. Varje plats får en egen URL, programinställningar och anslutningssträngar. Ni kan skapa upp till 5 platser på Standard och upp till 20 platser på Premium-nivån. Vanliga platsnamn är staging, canary, hotfix och integration, vilket återspeglar olika steg i releasepipelinen.

Före ett byte är det viktigt att förvärma staging-platsen så att den nya versionen är fullständigt initierad. En kall App Service-instans hanterar de första begärandena långsamt medan körningsmiljön initieras, vilket är oacceptabelt i produktion. Aktivera Auto Swap eller skicka manuellt HTTP-begäranden för uppvärmning till staging-platsen. App Service stöder även en applicationInitialization-konfiguration där ni kan definiera uppvärmningssökvägar som måste returnera 200 innan platsen anses vara redo.

Ett byte utbyter staging- och produktionsplatserna atomiskt. Under ett byte dirigerar App Service först trafiken till staging-instanserna som kör den nya koden, väntar på att de ska initieras och dirigerar sedan om all produktionstrafik till de nya instanserna. De gamla produktionsinstanserna blir då den nya staging-platsen. Detta gör återställning enkel — byt bara igen för att återgå till den tidigare versionen.

Programinställningar kan markeras som platsbundna (specifika för en plats) eller icke-platsbundna (kan följa med vid byte). Icke-platsbundna inställningar följer med distributionsplatsen när ni byter — staging-databasens anslutningssträng följer alltså koden in i produktion. Platsbundna inställningar stannar kvar på platsen oavsett byten — produktionen behåller alltid sin anslutningssträng till produktionsdatabasen. Markera inställningar som platsbundna med kryssrutan ”deployment slot setting” eller via CLI.

App Service stöder trafikdelning — att dirigera en procentandel av produktionstrafiken till en icke-produktionsplats utan att genomföra ett fullständigt byte. Detta möjliggör canary-releaser, där ni gradvis flyttar trafiken från 5 % till 10 % och sedan till 50 % när ni får större förtroende för den nya versionen, samtidigt som ni övervakar felfrekvensen vid varje steg. Användare som hamnar på canary-platsen får en platsbunden cookie som håller dem kvar på samma version så att sessionen förblir konsekvent.

Auto Swap byter automatiskt in en staging-plats i produktion när ny kod distribueras till den. Det passar bra för CI/CD-pipelines där ni vill att varje lyckad distribution ska tas i drift omedelbart. Auto Swap väntar på att staging-platsens HTTP-begäranden ska returnera 200 innan bytet slutförs. Aktivera funktionen per plats i portalen eller via CLI — men använd den med försiktighet, eftersom det saknas ett manuellt godkännandesteg mellan distribution och produktion.

Följ dessa metodtips för distributionsplatser: validera alltid i staging innan ni byter till produktion, använd platsbundna inställningar för att hålla produktionsdatabasens anslutningar åtskilda från staging, kör smoketester mot staging-platsens URL efter distributionen, konfigurera sökvägar för hälsokontroll så att App Service inte slutför bytet om den nya versionen inte är frisk och tagga era distributioner så att ni kan spåra vilken commit som körs på varje plats.

I en typisk CI/CD-pipeline kompilerar och testar byggsteget koden, skickar distributionssteget artefakten till staging-platsen, kör ett integreringsteststeg automatiserade tester mot staging-URL:en och byter bytessteget staging till produktion — eventuellt med ett manuellt godkännande som villkor. Detta mönster stöds inbyggt i både Azure Pipelines och GitHub Actions med App Service-distributionsåtgärden.

Under och efter ett byte av plats bör ni övervaka viktiga mått i Azure Monitor för att bekräfta att den nya versionen fungerar korrekt. Håll utkik efter ökningar av HTTP 5xx-fel, genomsnittlig svarstid och CPU-/minnesanvändning. Konfigurera måttaviseringar som utlöses om felfrekvensen överskrider ett tröskelvärde — då får ni en signal om att snabbt byta tillbaka. Smart identifiering i Application Insights kan automatiskt meddela er om avvikelser efter en distribution.

Distributionsplatser är att föredra framför att underhålla helt separata App Service-appar för staging och produktion, eftersom platserna delar samma plan (ingen extra kostnad), erbjuder byte med ett klick och återställning, stöder trafikdelning och hanteras under samma App Service-resurs. Använd separata appar endast när staging kräver fundamentalt andra plan-SKU:er, isoleringskrav eller helt separat fakturering.

I den här lektionen lärde ni er att distributionsplatser tillhandahåller isolerade miljöer som möjliggör blue-green-distributioner, att platsbundna inställningar håller miljöspecifik konfiguration (till exempel databas-URL:er) bunden till platsen i stället för till koden och att trafikdelning möjliggör canary-releaser genom att dirigera en procentandel av produktionstrafiken till en ny version. Nästa steg är att utforska automatisk skalning och anpassade domäner.