Kubernetes prakticky: proč kontejnery, proč orchestrátor, proč Azure
Kontejnerové obrazy jsou skvělou jednotkou nasazení, ideálním novým způsobem zapouzdření a nasazování aplikací. Kontejner je také perfektní výpočetní jednotkou, infrastrukturní komponentou s výbornou přenositelností mezi cloudy, datovými centry i IoT zařízeními. To všechno je fajn pokud si hrajete s jedním „serverem“ nebo Raspberry. Pokud ale máte cluster serverů, potřebujete balancovat provoz, umisťovat kontejnery, dělat service discovery třeba s DNS, držet vysokou dostupnost, řešit síťové konektivity, certifikáty pro externí komunikaci, provádět upgrady vašich služeb a tak podobně, neobejdete se bez orchestrátoru. Myslím, že Kubernetes je perfektní volba. Dnes se podívejme na základní výhody kontejnerů, Kubernetes a proč to všechno mít v Azure.
Kontejnerový obraz jako jednotka nasazení
Co všechno potřebuje váš kód k úspěšnému běhu? Knihovny, utility, framework, web server, systémové nástroje? A tenhle koktejl právě v těch správných verzích kdy to všechno funguje a tak, aby byl namíchaný přesně stejně při vývoji, testu, stagingu i produkci. To se dá řešit například package managerem OS (MSI, dpkg, rpm), prostředky programovacích prostředí (OSGi, pip, gem, Chocolate, NuGet), balíčky (jar, webdeploy), konfiguračním nástrojem (Ansible, Chef, Puppet) a tak podobně. To všechno má ale jeden společný problém – je to jednak dost složité, ale hlavně peklo všech dependencies se řeší v okamžiku deploymentu. Nasazujete aplikaci z dpkg a v ten moment se balíček snaží vypořádat se všemi verzemi vs. co už v systému je.
Někdy je instalace všech komponent tak komplikovaná, že ji běžný člověk prostě nedá. Proto řada dodavatelů složitého software jej začala distribuovat ve formě virtuální appliance, tedy v předinstalované VM, kde to všechno je už rozchozené. Velmi běžné to je u bezpečnostních systémů (NGFW, IPS) a také u „složitého“ software typu Micro Focus nebo CA. Jenže příprava takové appliance je zdlouhavá, hůře automatizovatelná a výsledné soubory jsou obrovské.
Kontejnerový obraz je podobný virtuální appliance, tedy je to hotová aplikace se vším co potřebuje ke svému běhu, je immutable, nemění se – pro novou verzi se vytvoří nová appliance, která původní nahrazuje. Na rozdíl od VM je ale tento proces výborně automatizovatelný, vrstvený souborový systém je velmi efektivní z hlediska přenosu obrazů a i se všemi vrstvami je obraz řádově menší, než klasická VM. Dependencies se tedy řeší v době vytváření obrazu a nikoli při deploymentu (jak je tomu třeba u MSI nebo dpkg). Kontejnerový obraz stačí prostě spustit.
Chcete příklad z dílny Microsoftu? Azure Machine Learning vám vyplivne kontejnerový obraz, Azure Functions Runtime se distribuuje v kontejnerech, Azure Stream Analytics pro IoT Edge je kontejner. Existují oficiální Docker obrazy pro Dynamics NAV (pro testování), SQL Server v Linuxu (plně podporováno), SQL Server Express ve Windows (plně podporováno) a další.
Kontejner jako výpočetní jednotka
Kontejnery jsou současně výpočetní jednotkou a krásně tak spojují problematiku vývoje a nasazení aplikace s přidělováním a řízením výpočetních zdrojů. Díky sdílení kernelu je kontejner velmi efektivní, sjednocený formát nabízí (konečně) velmi dobrou přenositelnost (vzpomeňte si na selhání OVF formátu pro VM … otevřený a blabla, ale prakticky OVF pro VMware nefunguje v KVM a Hyper-V bez úprav), například proto, že nebootuje. Startuje během milisekund, je malý na přenos i spotřebu zdrojů. Pustíte ho v cloudu, na vašem serveru, notebooku i větším IoT zařízení typu Raspberry.
Příklad z Microsoft dílny? Prakticky celý Azure využívá pro své vnitřní účely buď přímo kontejnery nebo jim podobné izolace procesů v Service Fabric a třeba takový Cloud Shell je ve skutečnosti kontejner spuštěný přes Kubernetes na pozadí. Kontejnery jsou ale právě také mechanismus jak distribuovat logiku do IoT Edge zařízení, například proudovou analýzu s Stream Analytics, učení či výsledné modely v Azure Machine Learning nebo serverless framework Azure Functions Runtime.