Přístup ke konkrétní App Service instanci a ARR Affinity
Tento článek byl napsán v roce 2017. Vývojářské technologie se neustále inovují a článek již nemusí popisovat aktuální stav technologie, ideální řešení a můj současný pohled na dané téma.
Kudu je užitečný online nástroj, který umožňuje sledovat nastavení webové aplikace, prostředí, procesů a zasahovat do určité míry i do úložiště dat. Jak se ale pomocí Kudu podívat na nastavení konkrétní instance, když je webová aplikace nasazená v App Service s více instancemi? Pokud z nějakého důvodu chcete, aby byl Váš požadavek (zobrazení webu, Kudu, aj.) zpracován konkrétní instancí, ukážu jak na to v tomto článku.
Úložiště dat v App Service
Důvodů, proč se připojit ke konkrétní instanci může být několik. Mnoho vývojářů, kteří používali v minulosti Cloud Services žijí v mylné představě, že obsah App Service (resp. jedné web app) je duplicitní na každé instanci a změnu je tudíž nutné na každé instanci provést samostatně. Není to vůbec potřeba. Každá webová aplikace v App Service má úložiště rozděleno do několika kategorií:
Lokální úložiště (per instance)
Skutečné lokální úložiště se nachází ve složce local. Obsah tohoto adresáře je dostupný jen jedné instanci a tudíž jeho zkoumání může být spojeno i s potřebou vybrat si v Kudu konkrétní instanci pro správu. Tento adresář zpravidla obsahuje dočasné soubory nebo různá nastavení a lze z něj pouze číst.
Sdílené úložiště (per web app)
Složka home obsahuje především výstupy z logování (LogFiles) a samostatný adresář s webovou aplikací a vším, co s ní souvisí (site), resp. site/wwwroot. Obsah této složky je sdílený pro Web App - pro všechny instance. Interně se obsah složky home nachází v Azure Storage. Konfigurační nastavení (např.: web.config a další) je dále přepisováno tím, co si vývojář nastaví přímo v Azure portálu. Za určitých okolností může stroj cachovat obsah (nebo jeho část) z home do local. Tento scénář popisovat dále nebudu. Obsah složky home lze upravovat, soubory je možné měnit a tyto změny se projevují okamžitě na všech instancích.
Systémová data
Posledním případem jsou systémové složky, které se vážou přímo k dané instanci (Program Files, Windows) a obsah těchto složek a souborů je pouze pro čtení.
ARR Afinity
Pokud máte i po přečtení odstavců výše potřebu přistoupit na konkrétní instanci, je nutné ověřit v nastavení Web App, zda je aktivní ARR Afinity. By default je tato volba aktivní a většinou ji nebudete chtít vypínat. Aktivní ARR Afinity se projevují vytvářením specifické affinity cookie u klienta, kterou používá IIS rozšíření Application Request Routing.
Je to užitečné, neboť díky tomuto mechanismu je zajištěno, že uživatel přistupující k webové aplikaci bude obsluhován stále stejným strojem. U aplikací, kde se neřeší stav (například statické HTML stránky) je vhodnější ARR Afinity vůbec nepoužívat. Správce, který vstupuje do Kudu má již tuto affinity cookie přidělenou (nebo ji dostane) a spravuje tak stále stejnou instanci. O existenci cookie se lze přesvědčit třeba v Chrome:
Identifikátor instance (přesněji jeho část) můžeme nalézt i přímo v Kudu v sekci Environment a bloku System info:
Azure Resource Explorer
Pokud tedy víme na jaké jsme instanci, stačí už jen zjistit, jaké další existují a poté změnit affinity cookie v prohlížeči pomocí vhodného doplňku. Poslouží k tomu nástroj Azure Resource Explorer na adrese resources.azure.com. Pomocí tohoto nástroje si zvolím aktuální subscription a najdu Web App včetně všech instancí:
Jak je vidět z obrázku, identifikátory se shodují. Kdyby Web App běžela na více instancích, viděl bych v Resource Exploreru všechny tyto identifikátory a následně bych mohl kterýmkoliv aktualizovat affinity cookie. Pro úpravu cookies v Chrome lze použít například doplněk EditThisCookie