Nastavení přípravných prostředí ve službě Azure App Service
Když nasadíte webovou aplikaci, webovou aplikaci v Linuxu, mobilní back-end nebo aplikaci API do služby Azure App Service, můžete místo výchozího produkčního slotu použít samostatný slot nasazení, pokud používáte úroveň plánu Standard, Premium nebo Isolated App Service. Sloty nasazení jsou živé aplikace s vlastními názvy hostitelů. Prvky obsahu a konfigurace aplikace je možné prohodí mezi dvěma sloty nasazení, včetně produkčního slotu.
Nasazení aplikace do neprodu provozního slotu má následující výhody:
- Před prohozením změn s produkčním slotem můžete ověřit změny aplikace v pracovní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 zahodí žádné požadavky. Celý tento pracovní postup můžete automatizovat konfigurací automatického prohození, když není potřeba ověření před prohozením.
- Po prohození má slot s dříve vytvořenou aplikací předchozí produkční aplikaci. Pokud změny prohození do produkčního slotu nejsou podle očekávání, můžete provést stejné prohození okamžitě a získat zpět poslední známý dobrý web.
Každá App Service plán podporuje jiný počet slotů nasazení. Za používání slotů nasazení se neúčtjí žádné další poplatky. Pokud chcete zjistit počet slotů, které vaše úroveň podporuje, podívejte se na App Service limity.
Pokud chcete aplikaci škálovat na jinou úroveň, ujistěte se, že cílová úroveň podporuje počet slotů, které už vaše aplikace 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í.
Přidat slot
Aby bylo možné povolit více slotů nasazení, musí aplikace běžet na úrovni Standard, Premium nebo Isolated.
v Azure Portalvyhledejte a vyberte App Services a vyberte aplikaci.

V levém podokně vyberte Nasazování slotů > Přidat slot.

Poznámka
Pokud aplikace ještě není na úrovni Standard, Premium nebo Isolated, zobrazí se zpráva s oznámením podporovaných úrovní pro povolení staged publikování. V tuto chvíli máte možnost vybrat Upgradovat a před pokračováním přejít na kartu Škálovat vaší aplikace.
V dialogovém okně Přidat slot zadejte název slotu a vyberte, jestli se má naklonovat konfigurace aplikace z jiného slotu nasazení. Pokračujte výběrem možnosti Přidat.

Konfiguraci můžete naklonovat z libovolného existujícího slotu. Nastavení, které lze klonovat, zahrnují nastavení aplikace, připojovací řetězce, verze jazykových rozhraní, webové sokety, verzi PROTOKOLU HTTP a bitost platformy.
Po přidání slotu zavřete dialogové okno výběrem možnosti Zavřít. Nový slot se teď zobrazuje na stránce Nasazování slotů. Ve výchozím nastavení je hodnota Traffic % pro nový slot nastavená na 0 a veškerý zákaznický provoz se směruje do produkčního slotu.
Výběrem nového slotu nasazení otevřete stránku prostředku tohoto slotu.

Pracovní slot má stránku pro správu stejně jako všechny ostatní App Service aplikace. Konfiguraci slotu můžete změnit. Abyste si připomeňme, že si slot nasazení prohlížíte, název aplikace se zobrazí jako a typ aplikace <app-name>/<slot-name> je App Service (Slot). Slot můžete také zobrazit jako samostatnou aplikaci ve skupině prostředků se stejnými označeními.
Vyberte adresu URL aplikace na stránce prostředku slotu. Slot nasazení má vlastní název hostitele a je to také živá aplikace. Pokud chcete omezit veřejný přístup ke slotu nasazení, podívejte se na Azure App Service IP adresy.
Nový slot nasazení nemá žádný obsah, i když naklonuje nastavení z jiného slotu. Do tohoto slotu můžete například publikovat pomocí Gitu. Do slotu můžete nasadit z jiné větve úložiště nebo jiného úložiště.
Adresa URL slotu bude ve formátu http://sitename-slotname.azurewebsites.net . Aby délka adresy URL byla v mezích nezbytných limitů DNS, název lokality se zkrátí na 40 znacích, název slotu se zkrátí na 19 znacích a připojí se dalších 4 náhodné znaky, aby výsledný název domény byl jedinečný.
Co se stane během prohození
Kroky operace prohození
Při prohození dvou slotů (obvykle z pracovního slotu do produkčního slotu) provádí App Service následující akce, aby se zajistilo, že v cílovém slotu ne docházet k výpadkům:
Použijte následující nastavení z cílového slotu (například produkčního slotu) pro všechny instance zdrojového slotu:
- Nastavení aplikace pro konkrétní sloty a připojovací řetězce, pokud jsou kyslované.
- Nastavení průběžného nasazování, pokud je povoleno.
- App Service nastavení ověřování, pokud je povoleno.
Kterýkoli z těchto případů aktivuje restartování všech instancí ve zdrojovém slotu. Během prohození s náhledemse 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.
Počkejte, až restartování dokončí každá instance ve zdrojovém slotu. Pokud se restartování jakékoli instance nezdaří, operace prohození vrátí všechny změny zdrojového slotu a zastaví operaci.
Pokud je povolená místní mezipaměť, aktivujte inicializaci místní mezipaměti vytvořením požadavku HTTP na kořen aplikace ("/") na každé instanci zdrojového slotu. Počkejte, až každá instance vrátí jakoukoli odpověď HTTP. Inicializace místní mezipaměti způsobí další restartování každé instance.
Pokud je automatické prohození povolené s vlastním zahajovacímrežimem , aktivujte inicializaci aplikace provedením požadavku HTTP do kořenového adresáře aplikace ("/") v každé instanci zdrojového slotu.
Pokud není zadaný, aktivujte požadavek HTTP do kořenového adresáře aplikace
applicationInitializationzdrojového slotu pro každou instanci.Pokud instance vrátí jakoukoli odpověď HTTP, považuje se za zahřeje.
Pokud jsou všechny instance ve zdrojovém slotu úspěšně zahřejené, prohozením dvou slotů přepnutím pravidel směrování pro tyto dva sloty. Po provedení tohoto kroku má cílový slot (například produkční slot) aplikaci, která je ve zdrojovém slotu předem zahřejená.
Teď, když má zdrojový slot aplikaci před prohozením dříve v cílovém slotu, proveďte stejnou operaci použitím všech nastavení a restartováním instancí.
V jakémkoli okamžiku operace prohození probíhá veškerá inicializace prohození aplikací ve zdrojovém slotu. Cílový slot zůstane online, zatímco se zdrojový slot připravuje a zahřeje, bez ohledu na to, kde je prohození úspěšné nebo neúspěšné. Pokud chcete prohodit pracovní slot s produkčním slotem, ujistěte se, že produkční slot je vždy cílový slot. Operace prohození tak nemá vliv na produkční aplikaci.
Poznámka
Instance v dřívějších produkčních instancích (ty, které se po této operaci prohození prohodí prohodí, se rychle recyklují) v posledním kroku procesu prohození. Pokud máte v aplikaci nějaké dlouhotrační operace, při recyklaci pracovních sil se opouští. To platí také pro aplikace funkcí. Proto by měl být kód aplikace napsaný způsobem, který je tolerantní proti chybám.
Která nastavení se prohodí?
Při klonování konfigurace z jiného slotu nasazení je klonovaná konfigurace upravitelná. Některé prvky konfigurace se po prohození (ne specificky pro slot) řiďte obsahem, zatímco jiné prvky konfigurace zůstanou po prohození (specifické pro slot) ve stejném slotu. Následující seznamy ukazují nastavení, která se při prohození slotů mění.
Nastavení, které jsou prohodily:
- Obecná nastavení, například verze architektury, 32/64 bitů, webové sokety
- Nastavení aplikace (lze nakonfigurovat tak, aby se drží slotu)
- Připojovací řetězce (lze nakonfigurovat tak, aby se drží slotu)
- Mapování obslužných rutin
- Veřejné certifikáty
- Obsah služby WebJobs
- Hybridní připojení *
- Koncové body služby *
- Azure Content Delivery Network *
- Mapování cest
Funkce označené hvězdičkou (*) se plánuje zrušit.
Nastavení, které se prohodí:
- Publikování koncových bodů
- Vlastní názvy domén
- Ne veřejné certifikáty a nastavení TLS/SSL
- Nastavení škálování
- Plánovače webových úloh
- Omezení IP adres
- Always On
- Nastavení diagnostiky
- Sdílení prostředků mezi zdroji (CORS)
- Integrace virtuální sítě
- Spravované identity
- Nastavení končí příponou _EXTENSION_VERSION
Poznámka
Pokud chcete výše uvedená nastavení prohodit, přidejte nastavení aplikace do každého slotu aplikace a nastavte WEBSITE_OVERRIDE_PRESERVE_DEFAULT_STICKY_SLOT_SETTINGS její hodnotu na nebo 0 false . Tato nastavení jsou buď všechna zaměnitelná, nebo vůbec. Nemůžete nastavit, aby se některá nastavení prohodí, a ne ostatní. Spravované identity se nikdy neprohodí a toto nastavení přepisování aplikace na tyto identity nemá vliv.
Některá nastavení aplikace, která platí pro nenačtená nastavení, se také neprohodí. Například vzhledem k tomu, že nastavení diagnostiky se prohodí, související nastavení aplikace, jako jsou a , se také prohodí, i když se nezminí WEBSITE_HTTPLOGGING_RETENTION_DAYS DIAGNOSTICS_AZUREBLOBRETENTIONDAYS jako nastavení slotu.
Pokud chcete nakonfigurovat nastavení aplikace nebo připojovací řetězec pro připojení ke konkrétnímu slotu (bez prohozování), přejděte na stránku Konfigurace pro tento slot. Přidejte nebo upravte nastavení a pak vyberte nastavení slotu nasazení. Zaškrtnutím tohoto políčka App Service, že nastavení není možné 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 děje během prohození.
Důležité
Než prohodíte aplikaci ze slotu nasazení do produkčního prostředí, ujistěte se, že produkční slot je vaším cílovým slotem a že všechna nastavení ve zdrojovém slotu jsou nakonfigurovaná přesně tak, jak je chcete mít v produkčním prostředí.
Prohození slotů nasazení:
Přejděte na stránku slotů nasazení vaší aplikace a vyberte Prohodit.

Dialogové okno Prohodit zobrazuje nastavení ve vybraném zdrojovém a cílovém slotu, která se změní.
Vyberte požadované sloty Source (Zdroj) a Target (Cíl). Cíl je obvykle produkční slot. Vyberte také karty Source Changes (Změny zdroje) a Target Changes (Cílové změny) a ověřte, že se změny konfigurace očekávají. Až budete hotovi, můžete sloty okamžitě prohodit výběrem možnosti Prohodit.

Pokud chcete vidět, jak by se váš cílový slot spouštěl s novým nastavením předtím, než k prohození skutečně dojde, nevyberte Prohodit , ale postupujte podle pokynů v tématu Prohození s náhledem.
Až budete hotovi, zavřete dialogové okno výběrem možnosti Zavřít.
Pokud máte nějaké problémy, podívejte se na článek Řešení potíží s prohozeními.
Prohodit ve verzi Preview (vícenásobné swapy)
Před přepnutím do produkčního prostředí jako cílového slotu ověřte, že aplikace běží s vyměněným nastavením. Zdrojové sloty se také zahřeje před dokončením swapu, což je žádoucí pro klíčové aplikace.
Když provedete prohození s náhledem, App Service provede stejnou operaci přepnutí , ale po prvním kroku se pozastaví. Před dokončením prohození pak můžete ověřit výsledek na přípravném slotu.
Pokud zrušíte prohození, App Service znovu aplikuje prvky konfigurace na zdrojovou pozici.
Pro prohození s náhledem:
Postupujte podle kroků v části prohození slotů nasazení , ale vyberte provést prohození s náhledem.

V dialogovém okně se dozvíte, jak se změní konfigurace ve zdrojovém slotu ve fázi 1 a jak se změní zdrojový a cílový slot ve fázi 2.
Až budete připraveni zahájit prohození, vyberte možnost Spustit prohození.
Po dokončení fáze 1 se zobrazí upozornění v dialogovém okně. Zobrazte náhled swapu ve zdrojovém slotu tak, že na
https://<app_name>-<source-slot-name>.azurewebsites.net.Až budete připraveni dokončit vyřazení, vyberte Dokončit prohození v akci prohození a vyberte Dokončit prohození.
Chcete-li zrušit probíhající zahození, vyberte možnost Zrušit zaměnit místo.
Až skončíte, zavřete dialogové okno tak, že vyberete Zavřít.
Pokud máte nějaké problémy, přečtěte si téma řešení potíží se zahozením.
Informace o automatizaci vícenásobného swapu najdete v tématu automatizace pomocí PowerShellu.
Vrácení swapu zpět
Pokud dojde k nějakým chybám v cílové patici (například k produkčnímu slotu) po prohození slotu, obnovte tyto sloty do jejich předem odkládacích stavů tak, že tyto dva sloty hned odměňujete.
Konfigurace automatického prohození
Poznámka
Automatické prohození není podporováno ve webových aplikacích v systému Linux a Web App for Containers.
automatické prohození zjednodušuje Azure DevOps scénáře, kdy chcete aplikaci nasadit průběžně s nulovým startem a s nulovými výpadky pro zákazníky aplikace. Když je automatický swap povolený z slotu do produkčního prostředí, pokaždé, když se do této patice nahraje změny kódu, App Service automaticky zahodí aplikaci do produkčního prostředí po zahřívání ve zdrojové pozici.
Poznámka
Před konfigurací automatického prohození pro produkční slot zvažte možnost testování automatického prohození na neprodukčním cílovém slotu.
Konfigurace automatického prohození:
Přejít na stránku prostředků vaší aplikace. Vyberte Konfigurace slotů pro nasazení > <desired source slot> > > Obecné nastavení.
Pro Automatické prohození vyberte zapnuto. Pak vyberte požadovanou cílovou patici pro slot nasazení automatického prohození a na panelu příkazů vyberte Uložit .

Spusťte do zdrojové patice nabízení kódu. Automatické prohození proběhne po krátké době a aktualizace se projeví na adrese URL cílové patice.
Pokud máte nějaké problémy, přečtěte si téma řešení potíží se zahozením.
Zadat vlastní zahřívání
Některé aplikace mohou před zahozením vyžadovat vlastní akce. applicationInitializationPrvek konfigurace v web.config umožňuje určit vlastní inicializační akce. Operace prohození počká na dokončení tohoto vlastního zahřívání a teprve potom bude prohozena s cílovou paticí. Tady je ukázka fragmentu 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í applicationInitialization prvku najdete v části Nejčastější selhání přepnutí slotu nasazení a jejichřešení.
Můžete také přizpůsobit chování zahřívání pomocí jednoho nebo obou následujících nastavení aplikace:
WEBSITE_SWAP_WARMUP_PING_PATH: Cesta k nástroji test paketů přes protokol HTTP pro zahřívání webu. Toto nastavení aplikace přidejte 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řívání. Přidejte toto nastavení aplikace s čárkami odděleným seznamem kódů HTTP. Příklad je200,202. Pokud vrácený stavový kód není v seznamu, operace zahřívání a swap se zastaví. Ve výchozím nastavení jsou všechny kódy odpovědí platné.WEBSITE_WARMUP_PATH: Relativní cesta k webu, která by měla být otestována pomocí testu při každém restartování lokality (nikoli jenom během zahození slotu). Příklady hodnot jsou/statuschecknebo kořenová cesta/.
Poznámka
<applicationInitialization>Prvek konfigurace je součástí spuštění každé aplikace, zatímco dvě nastavení aplikace pro zahřívání se vztahují jenom na zahození slotu.
Pokud máte nějaké problémy, přečtěte si téma řešení potíží se zahozením.
Monitorování swapu
Pokud se operace prohození trvá příliš dlouho, můžete získat informace o operaci swapu v protokolu aktivit.
Na stránce prostředků vaší aplikace na portálu v levém podokně vyberte Protokol aktivit.
Operace swap se v dotazu protokolu zobrazí jako Swap Web App Slots . Můžete ho rozbalit a vybrat jednu z dílčích operací nebo chyb a zobrazit podrobnosti.
Směrování provozu
Ve výchozím nastavení se všechny požadavky klientů na produkční adresu URL () aplikace směrují http://<app_name>.azurewebsites.net do produkčního slotu. Část provozu můžete směrovat do jiné patice. Tato funkce je užitečná v případě, že potřebujete zpětnou vazbu od uživatele k nové aktualizaci, ale nejste připraveni ho uvolnit do produkčního prostředí.
Směrovat provozní provoz automaticky
Postup automatického směrování provozních přenosů:
Přejít na stránku prostředků vaší aplikace a vyberte sloty nasazení.
Ve sloupci provoz% slotu, na který chcete směrovat, zadejte procento (mezi 0 a 100), které bude představovat objem celkového provozu, který chcete směrovat. Vyberte Uložit.

Po uložení nastavení se zadané procento klientů náhodně směruje do neprodukčního slotu.
Po automatickém směrování klienta na konkrétní slot je tento slot "připnuté" do této patice po celou dobu trvání této klientské relace. V klientském prohlížeči uvidíte, ke kterému slotu je vaše relace připnuté, a Prohlédněte si x-ms-routing-name soubor cookie v hlavičkách protokolu 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 .
Poznámka
pomocí az webapp traffic-routing set příkazu v rozhraní příkazového řádku Azure můžete také nastavit procenta směrování z nástrojů CI/CD, jako jsou GitHub akce, DevOps kanály nebo jiné systémy automatizace.
Ruční směrování provozní provozu
Kromě automatického směrování provozu můžou 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 vyjádřit nebo odhlásit z vaší beta aplikace. Chcete-li směrovat provozní provoz ručně, použijte x-ms-routing-name parametr dotazu.
Pokud chcete uživatelům umožnit, aby si z aplikace nahlásili svůj souhlas, můžete tento odkaz umístit na svou 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. Po přístupu klientského prohlížeče k odkazu se přesměruje na produkční slot. Každý další požadavek obsahuje x-ms-routing-name=self soubor cookie, který zakládá relaci do produkčního slotu.
Pokud chcete uživatelům umožnit, aby se do aplikace beta přihlášeni, 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 směrování 0% , zobrazené v šedé. Když explicitně nastavíte tuto hodnotu na 0% (zobrazený černý text), můžou uživatelé přistupovat k pracovnímu slotu ručně pomocí x-ms-routing-name parametru dotazu. Nebudou ale směrovány do slotu automaticky, protože procento směrování je nastaveno na 0. Toto je pokročilý scénář, ve kterém můžete "svůj pracovní slot" Skrýt z veřejného a zároveň umožnit interním týmům testování změn na slotu.
Odstranění slotu
Vyhledejte a vyberte svou aplikaci. Vyberte možnost sloty nasazení > <slot to delete> > – Přehled. Typ aplikace se zobrazuje jako App Service (slot) , abyste se přihlásili, že prohlížíte slot pro nasazení. Na panelu příkazů vyberte Odstranit .

Automatizace pomocí PowerShellu
Poznámka
Tento článek používá modul Azure Az PowerShell, což je doporučený modul PowerShellu pro interakci s Azure. Pokud chcete začít s modulem Az PowerShell, projděte si téma věnované instalaci Azure PowerShellu. Informace o tom, jak migrovat na modul Az PowerShell, najdete v tématu Migrace Azure PowerShellu z AzureRM na Az.
Azure PowerShell je modul, který poskytuje rutiny pro správu Azure prostřednictvím Windows PowerShell, včetně podpory pro správu slotů nasazení v Azure App Service.
informace o instalaci a konfiguraci Azure PowerShell a o ověřování Azure PowerShell pomocí předplatného Azure najdete v tématu jak nainstalovat a nakonfigurovat Microsoft Azure PowerShell.
Vytvoření webové aplikace
New-AzWebApp -ResourceGroupName [resource group name] -Name [app name] -Location [location] -AppServicePlan [app service plan name]
Vytvoření slotu
New-AzWebAppSlot -ResourceGroupName [resource group name] -Name [app name] -Slot [deployment slot name] -AppServicePlan [app service plan name]
Zahájení prohození s náhledem (vícefázové prohození) a použití konfigurace cílového slotu ve zdrojovém slotu
$ParametersObject = @{targetSlot = "[slot name – e.g. "production"]"}
Invoke-AzResourceAction -ResourceGroupName [resource group name] -ResourceType Microsoft.Web/sites/slots -ResourceName [app name]/[slot name] -Action applySlotConfig -Parameters $ParametersObject -ApiVersion 2015-07-01
Zrušení čekajícího prohození (prohození s recenzí) a obnovení konfigurace zdrojového slotu
Invoke-AzResourceAction -ResourceGroupName [resource group name] -ResourceType Microsoft.Web/sites/slots -ResourceName [app name]/[slot name] -Action resetSlotConfig -ApiVersion 2015-07-01
Prohození slotů nasazení
$ParametersObject = @{targetSlot = "[slot name – e.g. "production"]"}
Invoke-AzResourceAction -ResourceGroupName [resource group name] -ResourceType Microsoft.Web/sites/slots -ResourceName [app name]/[slot name] -Action slotsswap -Parameters $ParametersObject -ApiVersion 2015-07-01
Monitorování událostí prohození v protokolu aktivit
Get-AzLog -ResourceGroup [resource group name] -StartTime 2018-03-07 -Caller SlotSwapJobProcessor
Odstranění slotu
Remove-AzResource -ResourceGroupName [resource group name] -ResourceType Microsoft.Web/sites/slots –Name [app name]/[slot name] -ApiVersion 2015-07-01
Automatizace s Resource Manager šablonami
Azure Resource Manager šablony jsou deklarativní soubory JSON, které slouží k automatizaci nasazení a konfigurace prostředků Azure. Pokud chcete prohodit sloty pomocí Resource Manager, nastavíte dvě vlastnosti prostředků Microsoft.Web/sites/slots a Microsoft.Web/sites:
buildVersion: Toto je řetězcová 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, cobuildVersionmá slot mít. Pokud se targetBuildVersion nerovná aktuální verzi , aktivuje se operace prohození vyhledáním slotu sebuildVersionzadaným parametrembuildVersion.
Příklad Resource Manager šablony
Následující Resource Manager aktualizuje pracovní slot a nastaví pro buildVersion targetBuildVersion produkční slot . Tím se tyto dva sloty prohodí. Šablona předpokládá, že už máte vytvořenou webovou aplikaci se slotem 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 Resource Manager je idempotentní, což znamená, že se může provádět opakovaně a vytvářet stejný stav slotů. Po prvním spuštění se targetBuildVersion bude shodovat s aktuálním buildVersion , takže se prohození nespustila.
Automatizace pomocí rozhraní příkazového řádku
Příkazy Azure CLI pro sloty nasazení najdete v tématu az webapp deployment slot.
Řešení potíží s prohozeními
Pokud během prohození slotůdojde k nějaké chybě, zaprotokoluje se D:\home\LogFiles\eventlog.xml. Zaprotokoluje se také do protokolu chyb specifických pro aplikaci.
Tady jsou některé běžné chyby prohození:
Do kořenového adresáře aplikace se načasoval požadavek HTTP. Operace prohození počká 90 sekund pro každý požadavek HTTP a až 5krát zkusí operaci opakování. Pokud dojde k časového limitu 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 najdete v tématu Přehled místní mezipaměti.
Během vlastního zahřejese požadavky HTTP prochádí interně (bez nutnosti procházet externí adresou URL). Selžou s určitými pravidly přepisu adres URL v Web.config. Například pravidla pro přesměrování názvů domén nebo vynucování PROTOKOLU HTTPS mohou bránit zahřejování požadavků, aby se dostaly do kódu aplikace. Pokud chcete tento problém obvyř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řejení mohou pravidla přepsání adresy URL stále blokovat požadavky HTTP. Pokud chcete tento problém obvyř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 u aplikace docházet k neočekávaným restartováním. Je to proto, že po prohození se konfigurace vazby názvu hostitele nesynchronní, což samo o sobě nezpůsobí restartování. Některé události základního úložiště (například převzetí služeb při selhání svazku úložiště) však mohou tyto nesrovnalosti zjistit a vynutit restartování všech pracovních procesů. Pokud chcete tyto typy restartování minimalizovat, nastavte nastavení
WEBSITE_ADD_SITENAME_BINDINGS_IN_APPHOST_CONFIG=1aplikace na všech slotech. Toto nastavení aplikace ale nefunguje s aplikacemi WCF (Windows Communication Foundation).