Nakoukněme pod pokliču patchování u platformních služeb (PaaS) v Azure
Platformní služby jsou skvělé. Dostáváte SLA na službu a patching OS a prostředí či služby necháváte na Microsoft. Nemusíte to řešit. Vrtá vám ale hlavou, jak to Azure dělá? Posbírejme informace z veřejně dostupných blogů a podívejme se tomu pod kapotu.
Platformní služba, OS a runtime/služba je starost Microsoftu
Připomeňme zásadní výhodu PaaS. Celá služba je samozřejmě bezpečná a aktualizovaná jak z pohledu OS tak z hlediska runtime či prostředí (například PHP stack v App Service nebo SQL služba u Azure SQL DB apod.). Dodržuje dané SLA a patching není výmluva – ten se do toho samozřejmě počítá. Například na SQL DB máte SLA 99,99% na službu, tedy na funkční přístup do vaší databáze a do toho se musí vejít havárie serverů, racků, datových center a samozřejmě i věci jako je patching. Zajímá vás jak to Azure dělá?
První příklad – Azure App Service (webové aplikace)
Podívejme se nejprve na službu App Service. Jde o platformní řešení pro vaše webové aplikace. Funguje tak, že existují nějaké řídící zdroje (pushování kódu, monitoring, load-balancing, TLS šifrování a tak podobně) a pro vlastní aplikace se používá tzv. Service Plan. Jde v zásadě o jedno a více VM, které jsou přiděleny jen vám, ale které jsou plně spravované Microsoftem. Uvnitř těchto VM pak vznikají izolované prostory pro vaše webové aplikace (řekněme například jakési IIS kontejnery). Patching se týká dvou věcí – operačního systému pod tím, typicky Windows, a patching aplikační prostředí, například PHP stacku. Oboje pro vás platforma řeší automaticky (nutno zmínit, že u aplikačního prostředí se takto aplikují typicky minor patche, které nemají vliv na stávající kód – generační obměna runtime na novou major verzi je obvykle řešena tak, že se objeví jako nový runtime, na který můžete zmigrovat dle svého uvážení postupně, jak otestujete aplikaci – některé nejstarší pak mohou z platformy odejít, ale o tom jste s dostatečným předstihem informováni).
Fajn, jak se to tedy dělá? Obvykle to probíhá v pravidelném cyklu jednoho měsíce, který koreluje s uvolňováním záplat Windows, nicméně v případě kritických chyb se tyto implementují dle potřeby i mimo cyklus. Prvním krokem je, že testovací tým si všechno důkladně otestuje. Co se děje dál?
Druhým krokem je deployment do tzv. canary regionů. To je něco, co v portálu nevidíte, a většina zákazníků o těchto regionech netuší. Jedná se o testovací regiony, takovou laboratoř pro testování změn v Azure, než se pustí do produkčních regionů. Někteří velcí zákazníci mohou o přístup do canary regionu požádat. Dělají to ti největší uživatelé a běží tam svoje testy (případně získají přístup k prototypům budoucích funkcí Azure – ty jsou obvykle nejprve v canary pro private preview pro velmi omezené publikum, následně v private preview v normálním regionu pro širší, ale stále omezené publikum, potom v public preview dostupném pro všechny, ale bez SLA, a pak jde funkce do General Availability). Patche se tedy nasadí v canary regionu a neustále se sbírají metriky jak z obrovského množství testovacích aplikací, tak i z testovacích prostředí „interních zákazníků“ (XBOX, Office365 apod.) a externích zákazníků (zmíněné velké firmy, které získají do canary přístup). Teprve pokud je tady vše v pořádku, postupuje se dál.