Distributionsplatser för Azure Functions

Distribuera utan distributionsplatser på Flex Consumption

Flex Consumption-planen stöder inte distributionsplatser. För kontrollerade releaser och driftsättningar utan driftstopp, använd rullande uppdateringar som strategi för webbplatsuppdateringar.

Distribuera med hjälp av revisioner på Azure Container Apps

Azure Functions på Azure Container Apps använder inte distributionsplatser. Använd revisioner för att hantera och styra trafiken mellan versioner av din funktionsapp.

I Consumption-, Premium- och Dedikerad-planerna fungerar distributionsplatserna enligt följande:

• Under routningsbytet routas nya funktionstriggeranrop till den bytta platsen utan att behöva en explicit applikationsomstart.
• Platsbyten garanterar inte noll driftstopp. Funktioner som körs för närvarande kan avslutas och tillgängligheten kan försämras i skalade appar under slotbyte. Information om hur du skriver tillståndslösa och defensiva funktioner finns i Förbättra prestanda och tillförlitlighet för Azure Functions. Om driftsättningar utan avbrott är ett krav bör du överväga Flex Consumption-planen med rullande uppdateringar som strategi för platsuppdatering.

Varför använda slots?

Det finns många fördelar med att använda distributionsplatser, bland annat:

• Olika miljöer för olika ändamål: Genom att använda olika distributionplatser kan du särskilja appinstanser innan du växlar till produktion eller en mellanlagringsplats.
• Förvärmning: Distribuera till en slot i stället för direkt till produktion så att appen hinner värmas upp innan den tas i bruk. Dessutom minskar användning av slotar latensen för HTTP-utlösta arbetslaster. Instanser värms upp före distribution, vilket minskar kallstartstiden för nyss distribuerade funktioner.
• Enkla återställningar: Efter ett byte med produktion har platsen som tidigare hade en app satt i staging nu den tidigare produktionsappen. Om de ändringar du bytte in i produktionsplatsen inte är vad du förväntar dig kan du omedelbart återställa bytet för att få tillbaka ditt "senaste kända goda exemplar".
• Minimera omstarter: Om du ändrar appinställningarna i ett produktionsfack krävs en omstart av appen som körs. Du kan i stället ändra inställningarna i en stagingplats och överföra inställningsändringen till produktion med en förvärmd instans. Slotar är det rekommenderade sättet att migrera mellan Functions-körningsversioner samtidigt som högsta möjliga tillgänglighet bibehålls. Mer information finns i Minsta stilleståndstidsuppdatering.

Växla åtgärder

Vid ett byte är den ena platsen källplatsen och den andra målplatsen. Källplatsen innehåller instansen av applikationen som du tillämpar på målplatsen. Följande steg hjälper till att minska stilleståndstiden på målplatsen under ett byte:

1. Tillämpa inställningar: Tillämpa inställningar från målslotten på alla instanser i källslotten. Till exempel tillämpa produktionsinställningarna på testinstansen. De tillämpade inställningarna innehåller följande kategorier:

   • Platsspecifika appinställningar och anslutningssträng (om tillämpligt)
   • Inställningar för kontinuerlig distribution (om aktiverat)
   • Autentiseringsinställningar för App Service (om det är aktiverat)

2. Vänta på omstarter och tillgänglighet: Växlingen väntar på att varje instans i källfacket ska slutföra omstarten och vara tillgänglig för begäranden. Om det inte går att starta om en instans återställer växlingsoperationen alla ändringar i källplatsen och stoppar åtgärden.

3. Uppdatera routing: Om alla instanser på källplatsen värms upp framgångsrikt, slutför de två platserna bytet genom att byta routingregler. Efter det här steget har målplatsen (till exempel produktionsplatsen) appen som tidigare värmdes upp i källfacket.

4. Upprepa åtgärden: Nu när källfacket innehåller appen som tidigare fanns i målfacket, slutför samma åtgärd genom att applicera alla inställningar och starta om instanserna för källfacket.

Tänk på följande punkter:

• När som helst under växlingsåtgärden sker initieringen av de växlade apparna på källfacket. Målfacket förblir online medan källfacket förbereds, oavsett om slotbytet lyckas eller misslyckas.

• För att byta en uppställningsplats med produktionsplatsen, se till att produktionsplatsen alltid är målplatsen. På så sätt påverkar inte växlingsåtgärden din produktionsapp.

• Konfigurera inställningar relaterade till händelsekällor och bindningar som deployment slot-inställningarinnan du startar en swap. Genom att markera dem som "klibbiga" i förväg ser du till att händelser och utdata dirigeras till rätt instans.

• När du skapar en ny mellanlagringsplats kopierar portalen alla befintliga inställningar från produktionsplatsen till den nya platsen, oavsett inställningens stickiness.

Hantera inställningar

Vissa konfigurationsinställningar är specifika för en plats. Följande listor beskriver vilka inställningar som ändras när du byter plats, och vilka inställningar som förblir desamma.

Platsspecifika inställningar:

• Publicera API-slutpunkter
• Egna domännamn
• Icke-offentliga certifikat och TLS/SSL-inställningar
• Skalningsinställningar
• IP-begränsningar
• Alltid på
• Diagnostikinställningar
• Resursdelning för korsande ursprung (CORS)
• Privata slutpunkter

Icke-fackspecifika inställningar:

• Allmänna inställningar, såsom ramverksversion, 32/64-bitars och webbsockets
• Appinställningar (kan konfigureras för att hålla sig till en plats)
• Anslutningssträngar (kan konfigureras för att hålla sig till ett fack)
• Hanterarmappningar
• Offentliga certifikat
• Hybridanslutningar *
• Integrering av virtuellt nätverk *
• Tjänstslutpunkter *
• Azure Content Delivery Network *

Funktioner som har markerats med en asterisk (*) byts inte ut avsiktligt.

Skapa en distributionsinställning

Du kan markera inställningar som en distributionsinställning, vilket gör den klibbig. En fast inställning växlar inte med appinstansen.

Om du skapar en distributionsinställning i en plats, se till att du skapar samma inställning med ett unikt värde i vilken annan plats som helst som ingår i en swap. På så sätt är inställningsnamnen konsekventa mellan platser, även om värdet för en inställning inte ändras. Den här namnkonsekvensen säkerställer att koden inte försöker komma åt en inställning som har definierats i ett fack men inte en annan.

Använd följande steg för att skapa en distributionsinställning:

1. Gå till Deployment slots i funktionsappen och välj sedan platsnamnet.

   

2. Välj Konfiguration och välj sedan det inställningsnamn som du vill hålla fast vid det aktuella facket.

   

3. Välj Deploymentsplatsinställning och välj sedan OK.

   

4. Efter att inställningssektionen stängts, välj Spara för att behålla ändringarna.

   

Distribuera en app till en slot

Platserna är tomma när du skapar en plats. Du kan använda någon av de distributionstekniker som stöds för att distribuera din applikation till en plats.

Hur distributionsplatser skalar

Alla fack skalas till samma antal arbetare som produktionsplatsen.

• För Förbrukningsplaner skalar facket när funktionsappen skalar.
• För App Service-planer skalar appen till ett fast antal arbetare. Platser körs på samma antal arbetare som appplanen.

Visa fack

Du kan se information om befintliga platser genom att använda antingen Azure CLI eller Azure-portalen.

az functionapp deployment slot list --name "<APP_NAME>" --resource-group "<RESOURCE_GROUP>"

Lägga till en plats

Du kan lägga till en plats genom att använda antingen Azure CLI eller Azure-portalen.

az functionapp deployment slot create --name "<APP_NAME>" --resource-group "<RESOURCE_GROUP>" --slot staging

Du kan också skapa en plats genom att använda Azure Resource Manager (ARM)-mallar eller Bicep-filer. Ett exempel på hur du skapar en funktionsapp i en förbrukningsplan med ett distributionsfack finns i den här Azure Resource Manager-snabbstarten.

Åtkomst till platsresurser

Du får åtkomst till resurser (HTTP-utlösare och administratörsslutpunkter) på ett mellanlagringsfack på samma sätt som produktionsplatsen. Men i stället för funktionsappens värdnamn använder du det platsspecifika värdnamnet i begärande-URL:en, tillsammans med eventuella fackspecifika nycklar. Eftersom staging-slots är liveappar måste du skydda dina funktioner i en staging-slot precis som i en produktionsslot.

Växla platser

Du kan byta plats in och ut ur produktion genom att använda antingen Azure CLI eller Azure-portalen.

az functionapp deployment slot swap --name "<APP_NAME>" --resource-group "<RESOURCE_GROUP>" --slot staging --target-slot production

Ångra ett byte

Om ett byte leder till ett fel eller du vill ångra ett byte kan du återställa till det ursprungliga tillståndet. Om du vill återgå till det förinstallerade tillståndet gör du ett nytt byte för att återställa växlingen.

Ta bort ett fack

Du kan ta bort en plats genom att använda antingen Azure CLI eller Azure-portalen.

az functionapp deployment slot delete --name "<APP_NAME>" --resource-group "<RESOURCE_GROUP>" --slot staging

Ändra App Service-plan

Med en funktionsapp som körs under en App Service-plan kan du ändra den underliggande App Service-planen för en plats.

Använd följande steg för att ändra ett facks App Service-plan:

1. Gå till Deployment slots i funktionsappen och välj sedan platsnamnet.

   

2. Under App Service-plan väljer du Ändra App Service-plan.

3. Välj den plan som du vill uppgradera till eller skapa en ny plan.

   

4. Välj OK.

Att tänka på

Azure Functions-utplaceringsplatser har följande överväganden:

• Hur många platser som är tillgängliga för en app beror på planen. Konsumtionsplanen stöder totalt två platser: produktionsplatsen och en uppställningsplats. Fler utrymmen är tillgängliga för appar som körs under andra planer. Mer information finns i Tjänstbegränsningar.
• Om du byter en plats återställs nycklar för appar som har en AzureWebJobsSecretStorageType appinställning inställd till files.
• När du aktiverar platser ställer portalen in din funktionsapp till skrivskyddat läge.
• Platsbyten kan misslyckas när din funktionsapp använder ett säkert lagringskonto som standardlagringskonto (inställt i AzureWebJobsStorage). Mer information finns i referensen WEBSITE_OVERRIDE_STICKY_DIAGNOSTICS_SETTINGS .
• Använd funktionsappnamn som är kortare än 32 tecken. Namn längre än 32 tecken kan orsaka värd-ID-kollisioner.