Nastavení přípravných prostředí ve službě Azure App Service

Když nasadíte webovou aplikaci, webovou aplikaci v Linuxu, mobilním back-endu nebo aplikaci API do služby Aplikace Azure Service, můžete místo výchozího produkčního slotu použít samostatný slot nasazení, když běžíte na úrovni plánu Služby App Service úrovně Standard, Premium nebo Isolated App Service. Sloty nasazení jsou živé aplikace s vlastními názvy hostitelů. Mezi dvěma sloty nasazení, včetně produkčního slotu, je možné prohodit obsah aplikace a prvky konfigurace.

Nasazení aplikace do neprodukčního slotu má následující výhody:

• Před prohozením s produkčním slotem můžete ověřit změny aplikace v přípravném slotu nasazení.
• Nasazení aplikace do slotu a její následné prohození do produkčního prostředí zajistí, že jsou všechny instance slotu před přeřazením do produkčního prostředí plně připravené. Tím se eliminují výpadky při nasazování aplikace. Přesměrování provozu je bezproblémové a kvůli operacím prohození se nezahodí žádné požadavky. Celý pracovní postup můžete automatizovat tak, že nakonfigurujete automatické prohození v případě, že ověření předběžného prohození není potřeba.
• Po prohození teď slot s dříve fázovanou aplikací má předchozí produkční aplikaci. Pokud změny prohozené do produkčního slotu nejsou tak, jak očekáváte, můžete provést stejnou prohození okamžitě, abyste získali svůj "poslední známý dobrý web".

Každá úroveň plánu služby App Service podporuje jiný počet slotů nasazení. Za používání slotů nasazení se neúčtují žádné další poplatky. Pokud chcete zjistit počet slotů, které úroveň vaší aplikace podporuje, podívejte se na limity služby App Service.

Pokud chcete aplikaci škálovat na jinou úroveň, ujistěte se, že cílová úroveň podporuje počet slotů, které aplikace už používá. Pokud má vaše aplikace například více než pět slotů, nemůžete ji škálovat na úroveň Standard , protože úroveň Standard podporuje pouze pět slotů nasazení.

Toto video ukazuje, jak nastavit přípravná prostředí ve službě Aplikace Azure Service.

Kroky ve videu jsou popsané také v následujících částech.

Požadavky

Informace o oprávněních, která potřebujete k provedení požadované operace slotu, najdete v tématu Operace poskytovatele prostředků (například vyhledejte slot).

Přidat slot

Aby bylo možné povolit více slotů nasazení, musí být aplikace spuštěná na úrovni Standard, Premium nebo Isolated .

az webapp deployment slot create --name <app-name> --resource-group <group-name> --slot <slot-name>

New-AzWebAppSlot -ResourceGroupName <group-name> -Name <app-name> -Slot <slot-name> -AppServicePlan <plan-name>

Nový slot nasazení nemá žádný obsah, i když nastavení naklonujete z jiného slotu. Můžete například publikovat do tohoto slotu pomocí Gitu. Do slotu můžete nasadit z jiné větve úložiště nebo jiného úložiště. Získání profilu publikování ze služby Aplikace Azure Service může poskytnout požadované informace pro nasazení do slotu. Profil lze importovat pomocí sady Visual Studio, aby se do slotu nasadil obsah.

Adresa URL slotu má formát http://sitename-slotname.azurewebsites.net. Pokud chcete zachovat délku adresy URL v rámci nezbytných limitů DNS, název webu se zkrátí na 40 znaků a sloučený název webu a název slotu musí být menší než 59 znaků.

Co se stane během prohození

Kroky operace prohození

Když prohodíte dva sloty (obvykle z přípravného slotu jako zdroje do produkčního slotu jako cíle), služba App Service provede následující kroky, aby se zajistilo, že cílový slot neproběhl prostoje:

1. U všech instancí zdrojového slotu použijte následující nastavení z cílového slotu (například produkčního slotu):

   • Pokud je to možné, nastavení aplikace specifické pro sloty a připojovací řetězec.
   • Pokud je povolené nastavení průběžného nasazování .
   • Nastavení ověřování služby App Service, pokud je povoleno.

   Pokud se u zdrojového slotu použije některá nastavení, tato změna aktivuje restartování všech instancí ve zdrojovém slotu. Během prohození s náhledem to označuje konec první fáze. Operace prohození je pozastavená a můžete ověřit, že zdrojový slot funguje správně s nastavením cílového slotu.

2. Počkejte na dokončení restartování každé instance ve zdrojovém slotu. Pokud se některé instanci nepodaří restartovat, operace prohození vrátí všechny změny zdrojového slotu a zastaví operaci.

3. Pokud je povolená místní mezipaměť , aktivujte inicializaci místní mezipaměti tak, že v každé instanci zdrojového slotu provedete požadavek HTTP na kořen aplikace ("/"). Počkejte, až každá instance vrátí jakoukoli odpověď HTTP. Inicializace místní mezipaměti způsobí další restartování každé instance.

4. Pokud je povolené automatické prohození pomocí vlastního zahřátí, aktivujte vlastní inicializace aplikace pro každou instanci zdrojového slotu.

   Pokud applicationInitialization není zadaný, aktivujte požadavek HTTP na kořen aplikace zdrojového slotu v každé instanci.

   Pokud instance vrátí jakoukoli odpověď HTTP, považuje se za zahřeje.

5. Pokud se všechny instance ve zdrojovém slotu úspěšně zahřejí, prohodíte oba sloty přepnutím pravidel směrování pro oba sloty. Po tomto kroku má cílový slot (například produkční slot) aplikaci, která se dříve zahřeje ve zdrojovém slotu.

6. Teď, když má zdrojový slot dříve v cílovém slotu předhození, proveďte stejnou operaci použitím všech nastavení a restartováním instancí.

V libovolném okamžiku operace prohození probíhá veškerá inicializace prohozených aplikací ve zdrojovém slotu. Cílový slot zůstane online, zatímco zdrojový slot se připravuje a zahřeje bez ohledu na to, jestli se prohození úspěšně nebo nezdaří. Pokud chcete prohodit přípravný slot s produkčním slotem, ujistěte se, že produkční slot je vždy cílovým slotem. Operace prohození tak nemá vliv na vaši produkční aplikaci.

Která nastavení se prohodí?

Při klonování konfigurace z jiného slotu nasazení se klonovaná konfigurace dá upravit. Některé prvky konfigurace sledují obsah napříč prohozením (nikoli konkrétním slotem), zatímco jiné konfigurační prvky zůstanou ve stejném slotu po prohození (konkrétní slot). Následující seznamy ukazují nastavení, která se mění při prohození slotů.

Nastavení, která se prohodí:

• Zásobník jazyků a verze, 32/64bitová verze
• Nastavení aplikace (je možné nakonfigurovat tak, aby se držela slotu)
• Připojovací řetězce (lze nakonfigurovat tak, aby se držely slotu)
• Připojené účty úložiště (je možné nakonfigurovat tak, aby se držely slotu)
• Mapování obslužných rutin
• Veřejné certifikáty
• Obsah webových úloh
• Hybridní připojení *
• Koncové body služby *
• Azure Content Delivery Network *
• Mapování cest

Funkce označené hvězdičkou (*) se plánují zrušit.

Nastavení, která se neprohodí:

• Obecná nastavení, která nejsou uvedená v nastaveních, která se prohodí
• Koncové body publikování
• Vlastní názvy domén
• Neveřejné certifikáty a nastavení PROTOKOLU TLS/SSL
• Nastavení škálování
• Plánovače webových úloh
• Omezení IP adres
• Stálé připojení
• Nastavení diagnostiky
• Sdílení prostředků mezi zdroji (CORS)
• Integrace virtuální sítě
• Spravované identity a související nastavení
• Nastavení, která končí příponou _EXTENSION_VERSION
• Nastavení vytvořená konektorem služby

Pokud chcete nakonfigurovat nastavení aplikace nebo připojovací řetězec zůstat u konkrétního slotu (neprohozeno), přejděte na stránku Konfigurace daného slotu. Přidejte nebo upravte nastavení a pak vyberte nastavení slotu nasazení. Když toto políčko zaškrtnete, služba App Service oznámí, že nastavení nejde prohodit.

Prohození dvou slotů

Sloty nasazení můžete prohodit na stránce Nasazovací sloty vaší aplikace a na stránce Přehled. Technické podrobnosti o prohození slotů najdete v tématu Co se stane během prohození.

az webapp deployment slot swap --resource-group <group-name> --name <app-name> --slot <source-slot-name> --target-slot production

Switch-AzWebAppSlot -SourceSlotName "<source-slot-name>" -DestinationSlotName "production" -ResourceGroupName "<group-name>" -Name "<app-name>"

Pokud máte nějaké problémy, přečtěte si téma Řešení potíží s prohozením.

Prohození s verzí Preview (vícefázové prohození)

Před přepnutím do produkčního prostředí jako cílového slotu ověřte, že aplikace běží s prohozenými nastaveními. Zdrojový slot se také zahřeje před dokončením prohození, což je žádoucí pro klíčové aplikace.

Když provedete prohození s verzí Preview, služba App Service provede stejnou operaci prohození, ale pozastaví se po prvním kroku. Před dokončením prohození pak můžete ověřit výsledek přípravného slotu.

Pokud prohození zrušíte, app Service znovu spustí konfigurační prvky do zdrojového slotu.

az webapp deployment slot swap --resource-group <group-name> --name <app-name> --slot <source-slot-name> --target-slot production --action preview

az webapp deployment slot swap --resource-group <group-name> --name <app-name> --slot <source-slot-name> --target-slot production --action swap

az webapp deployment slot swap --resource-group <group-name> --name <app-name> --slot <source-slot-name> --target-slot production --action reset

Switch-AzWebAppSlot -SourceSlotName "<source-slot-name>" -DestinationSlotName "production" -ResourceGroupName "<group-name>" -Name "<app-name>" -SwapWithPreviewAction ApplySlotConfig

Switch-AzWebAppSlot -SourceSlotName "<source-slot-name>" -DestinationSlotName "production" -ResourceGroupName "<group-name>" -Name "<app-name>" -SwapWithPreviewAction CompleteSlotSwap

Switch-AzWebAppSlot -SourceSlotName "<source-slot-name>" -DestinationSlotName "production" -ResourceGroupName "<group-name>" -Name "<app-name>" -SwapWithPreviewAction ResetSlotSwap

Pokud máte nějaké problémy, přečtěte si téma Řešení potíží s prohozením.

Vrácení výměny zpět

Pokud v cílovém slotu (například v produkčním slotu) po prohození slotu dojde k nějakým chybám, obnovte sloty do jejich předhození tím, že okamžitě prohodíte stejné dva sloty.

Konfigurace automatického prohození

Automatické prohození zjednodušuje scénáře Azure DevOps, ve kterých chcete aplikaci nasadit nepřetržitě s nulovým studeným spuštěním a nulovým výpadkem pro zákazníky aplikace. Když je automatické prohození povolené z slotu do produkčního prostředí, app Service automaticky přehodí aplikaci do produkčního prostředí, jakmile se zahřeje ve zdrojovém slotu.

az webapp deployment slot auto-swap --name <app-name> --resource-group <group-name> --slot <source-slot-name>

az webapp deployment slot auto-swap --name <app-name> --resource-group <group-name> --slot <source-slot-name> --disable

Set-AzWebAppSlot -ResourceGroupName "<group-name>" -Name "<app-name>" -Slot "<source-slot-name>" -AutoSwapSlotName "production"

Pokud máte nějaké problémy, přečtěte si téma Řešení potíží s prohozením.

Zadání vlastního zahřátí

Některé aplikace můžou před prohozením vyžadovat vlastní akce pro přípravu. Element applicationInitialization konfigurace v souboru web.config umožňuje zadat vlastní inicializační akce. Operace prohození čeká na dokončení tohoto vlastního zahřátí před prohozením s cílovým slotem. Tady je ukázkový fragment web.config.

<system.webServer>
    <applicationInitialization>
        <add initializationPage="/" hostName="[app hostname]" />
        <add initializationPage="/Home/About" hostName="[app hostname]" />
    </applicationInitialization>
</system.webServer>

Další informace o přizpůsobení elementu applicationInitialization najdete v tématu Nejběžnější chyby prohození slotů nasazení a jejich řešení.

Chování zahřátí můžete také přizpůsobit jedním nebo oběma následujícími nastaveními aplikace:

• WEBSITE_SWAP_WARMUP_PING_PATH: Cesta k příkazu ping přes HTTP zahřeje váš web. Toto nastavení aplikace přidáte zadáním vlastní cesty, která začíná lomítkem jako hodnotou. Příklad: /statuscheck. Výchozí hodnota je /.
• WEBSITE_SWAP_WARMUP_PING_STATUSES: Platné kódy odpovědí HTTP pro operaci zahřátí. Přidejte toto nastavení aplikace se seznamem kódů HTTP oddělených čárkami. Příkladem je 200,202 . Pokud vrácený stavový kód není v seznamu, zastaví se operace zahřátí a prohození. Ve výchozím nastavení jsou všechny kódy odpovědí platné.
• WEBSITE_WARMUP_PATH: Relativní cesta na webu, která by měla být ping při každém restartování lokality (nejen během prohození slotů). Příklady hodnot zahrnují /statuscheck kořenovou cestu nebo kořenovou cestu /.

Pokud máte nějaké problémy, přečtěte si téma Řešení potíží s prohozením.

Monitorování prohození

Pokud dokončení operace prohození trvá dlouho, můžete získat informace o operaci prohození v protokolu aktivit.

az monitor activity-log list --resource-group <group-name> --query "[?contains(operationName.value,'Microsoft.Web/sites/slots/slotsswap/action')]"

Get-AzLog -ResourceGroup <group-name> -StartTime 2023-07-07 | where{$_.OperationName -eq 'Swap Web App Slots'}

Automatické směrování produkčního provozu

Ve výchozím nastavení se všechny požadavky klientů na produkční adresu URL (http://<app_name>.azurewebsites.net) aplikace směrují do produkčního slotu. Část provozu můžete směrovat do jiného slotu. Tato funkce je užitečná, pokud potřebujete zpětnou vazbu uživatelů pro novou aktualizaci, ale nejste připraveni ji uvolnit do produkčního prostředí.

az webapp traffic-routing set --resource-group <group-name> --name <app-name> --distribution <slot-name>=15

Add-AzWebAppTrafficRouting -ResourceGroupName "<group-name>" -WebAppName "<app-name>" -RoutingRule @{ActionHostName='<app-name>-<slot-name>.azurewebsites.net';ReroutePercentage='15';Name='<slot-name>'}

Jakmile se klient automaticky přesměruje do konkrétního slotu, je na tento slot připnut po dobu jedné hodiny nebo do doby, než se soubory cookie odstraní. V klientském prohlížeči můžete zjistit, ke kterému slotu je relace připnutá, a to tak, že se podíváte na x-ms-routing-name soubor cookie v hlavičce HTTP. Požadavek, který je směrován do "přípravného" slotu, má soubor cookie x-ms-routing-name=staging. Požadavek, který je směrován do produkčního slotu, má soubor cookie x-ms-routing-name=self.

Ruční směrování produkčního provozu

Kromě automatického směrování provozu může App Service směrovat požadavky do konkrétního slotu. To je užitečné, když chcete, aby se vaši uživatelé mohli přihlásit nebo odhlásit z beta aplikace. Pokud chcete směrovat produkční provoz ručně, použijte x-ms-routing-name parametr dotazu.

Pokud chcete uživatelům umožnit, aby se odhlásili z beta aplikace, můžete například vložit tento odkaz na webovou stránku:

<a href="<webappname>.azurewebsites.net/?x-ms-routing-name=self">Go back to production app</a>

Řetězec x-ms-routing-name=self určuje produkční slot. Jakmile klientský prohlížeč přejde na odkaz, přesměruje se do produkčního slotu. Každý další požadavek má x-ms-routing-name=self soubor cookie, který připne relaci do produkčního slotu.

Pokud chcete uživatelům umožnit, aby se přihlásili k vaší beta aplikaci, nastavte stejný parametr dotazu na název neprodukčního slotu. Tady je příklad:

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

Ve výchozím nastavení mají nové sloty pravidlo 0%směrování zobrazené šedě. Když explicitně nastavíte tuto hodnotu na 0% (zobrazenou v černém textu), uživatelé budou mít přístup k přípravnému slotu ručně pomocí parametru x-ms-routing-name dotazu. Nebudou ale směrovány do slotu automaticky, protože procento směrování je nastavené na 0. Jedná se o pokročilý scénář, ve kterém můžete přípravný slot skrýt před veřejností a zároveň umožnit interním týmům testovat změny v slotu.

Odstranění slotu

az webapp deployment slot delete --name <app-name> --resource-group <group-name> --slot <slot-name>

Remove-AzWebAppSlot -ResourceGroupName "<group-name>" -Name "<app-name>" -Slot "<slot-name>"

Automatizace pomocí šablon Resource Manageru

Šablony Azure Resource Manageru jsou deklarativní soubory JSON používané k automatizaci nasazení a konfigurace prostředků Azure. Pokud chcete prohodit sloty pomocí šablon Resource Manageru, nastavte dvě vlastnosti prostředků Microsoft.Web/sites/slots a Microsoft.Web/sites :

• buildVersion: Jedná se o řetězcovou vlastnost, která představuje aktuální verzi aplikace nasazené v slotu. Například: "v1", "1.0.0.1" nebo "2019-09-20T11:53:25.2887393-07:00".
• targetBuildVersion: Toto je řetězcová vlastnost, která určuje, co buildVersion má slot mít. targetBuildVersion Pokud se aktuální hodnota nerovná buildVersion, aktivuje operaci prohození vyhledáním slotu se zadaným buildVersion.

Příklad šablony Resource Manageru

Následující šablona Resource Manageru prohodí dva sloty aktualizací buildVersion slotu staging a nastavením v targetBuildVersion produkčním slotu. Předpokládá se, že jste vytvořili slot s názvem 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')]"
            }
        }        
    ]
}

Tato šablona Resource Manageru je idempotentní, což znamená, že je možné ji opakovaně spustit a vytvořit stejný stav slotů. Bez jakékoli změny šablony následné spuštění stejné šablony neaktivují prohození slotů, protože sloty jsou již v požadovaném stavu.

Řešení potíží s prohozeními

Pokud během prohození slotu dojde k nějaké chybě, zaprotokoluje se D:\home\LogFiles\eventlog.xml. Protokoluje se také v protokolu chyb specifických pro aplikaci.

Tady je několik běžných chyb prohození:

• Vypršel časový limit požadavku HTTP na kořen aplikace. Operace prohození čeká na každý požadavek HTTP 90 sekund a opakuje se až pětkrát. Pokud vyprší časový limit všech opakování, operace prohození se zastaví.

• Inicializace místní mezipaměti může selhat, když obsah aplikace překročí kvótu místního disku zadanou pro místní mezipaměť. Další informace naleznete v tématu Přehled místní mezipaměti.

• Během operace aktualizace lokality může dojít k následující chybě " Slot nelze změnit, protože jeho nastavení konfigurace bylo připravené pro prohození". K tomu může dojít v případě, že byla dokončena buď prohození s verzí Preview (vícefázové prohození ), ale fáze 2 ještě nebyla provedena, nebo se prohození nezdařilo. Tento problém můžete vyřešit dvěma způsoby:

  1. Zrušení operace prohození, která obnoví lokalitu zpět do starého stavu
  2. Dokončete operaci prohození, která aktualizuje lokalitu na požadovaný nový stav.

  Informace o zrušení nebo dokončení operace prohození najdete v tématu Prohození s verzí Preview (vícefázové prohození ).

• Během vlastního zahřátí se požadavky HTTP provádějí interně (bez průchodu externí adresou URL). Můžou selhat s určitými pravidly přepsání adresy URL v souboru Web.config. Pravidla pro přesměrování názvů domén nebo vynucení HTTPS můžou například bránit v zahřátí požadavků v dosažení kódu aplikace. Chcete-li tento problém vyřešit, upravte pravidla přepsání přidáním následujících dvou podmínek:

  <conditions>
    <add input="{WARMUP_REQUEST}" pattern="1" negate="true" />
    <add input="{REMOTE_ADDR}" pattern="^100?\." negate="true" />
    ...
  </conditions>
  

• Bez vlastního zahřátí můžou pravidla přepsání adresy URL stále blokovat požadavky HTTP. Chcete-li tento problém vyřešit, upravte pravidla přepsání přidáním následující podmínky:

  <conditions>
    <add input="{REMOTE_ADDR}" pattern="^100?\." negate="true" />
    ...
  </conditions>
  

• Po prohození slotů může dojít k neočekávanému restartování aplikace. Důvodem je to, že po prohození se konfigurace vazby názvu hostitele nesynchronizuje, což samo o sobě nezpůsobí restartování. Některé základní události úložiště (například převzetí služeb při selhání svazku úložiště) však můžou tyto nesrovnalosti detekovat a vynutit restartování všech pracovních procesů. Pokud chcete tyto typy restartování minimalizovat, nastavte WEBSITE_ADD_SITENAME_BINDINGS_IN_APPHOST_CONFIG=1 nastavení aplikace na všech slotech. Toto nastavení aplikace ale nefunguje s aplikacemi WCF (Windows Communication Foundation).

Další kroky

Blokování přístupu k neprodukčním slotům