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.
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ší.
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.
V tomto seriálu se zaměřím na Kubernetes, dnes nejpopulárnější orchestrátor především v Linux světě. Z mého pohledu jedinou dobrou alternativou je Service Fabric z dílny Microsoftu (Linux verze je open source!), na kterém je z většiny postaven Azure. Service Fabric není jen orchestrátor, ale nabízí víc i jako platforma pro mikroslužby včetně programovacího modelu a je dost populární u .NET vývojářů (přestože Linux verze je také dostupná a drží světový rekord v rychlosti spuštění 1 milionu kontejnerů na 2000 nodech clusteru do 3 minut).
Kubernetes je orchestrátor a ovládá nejčastěji Docker hostitele (přestože jeho modulární architektura umožňuje i další varianty). V toto chvíli primárně Linux, ale Microsoft velmi intenzivně pracuje na podpoře Windows. V preview už si to můžete vyzkoušet (podívejte na ACS-engine), ale chybí některé síťové konstrukty - nicméně Windows Server 1709 už umožnil dokonce kombinovat Windows a Linux kontejnery v jednom stroji a právě přicházející 1803 a následně Windows Server 2019 přidává velké množství věcí právě pro Kubernetes.
Jako orchestrátor dokáže Kubernetes řešit scheduling na nody v clusteru, držet kontejnery při životě, propojit je a balancovat na ně provoz, řešit externí přístupy, definovat služby a zajišťovat jejich discovery, řídit perzistentní storage a tak podobně.
Jak na Kubernetes v Azure? Pro většinu z vás doporučuji AKS - plně spravovanou službu v Azure. Master nody jsou ve správě Microsoftu a dokonce za ně ani neplatíte, jsou zdarma. Platíte pouze za agent nody, kde běží vaše kontejnery. Kubernetes je složitý a je ideální přenechat starost o takovou platformu někomu, kdo ji dobře zná … a kdo ji vymyslel. Ze tří zakladatelů Kubernetes původně z Google jsou dnes dva ve firmě Heptio a Brendan Burns je v Microsoft a řídí jeho kontejnerovou strategii. AKS je pro mě jasná volba.
Pokud se v Kubernetes chcete "vrtat", například mít přístup k funkcím a variantám, které ještě nejsou natolik stabilní, aby je Microsoft dal do AKS služby s SLA (například podpora Windows hostitelů), nebo mít možnost ovlivnit celou instalaci včetně plného přístupu do master nodů, zvolte ACS-engine. Jde o open source nástroj pro generování ARM šablon, které následně použijete pro automatizované nasazení Kubernetes v Azure (mimochodem stejný engine na pozadí používá AKS když pro vás připravuje prostředí). AKS je plně spravované, ACS-engine je způsob, jak jednoduše rozjet prostředí, které si pak spravujete sami.
Možná potřebujete Kubernetes včetně developerské nadstavby a pak se určitě můžete poohlédnout po Open Shift od Red Hatu, nebo chcete distribuci stejnou, jakou můžete mít u sebe, například Tectonic od CoreOS (dnes patří Red Hatu) či použít Canonical distribuci nebo Mirantis. Pokud chcete alternativní PaaS, je tu Pivotal Cloud Foundry (pod kapotou nemá Kubernetes ale jiný kontejnerový systém) s perfektní podporou v Azure a v marketplace najdete i Mesosphere DC/OS či Docker Swarm (dva alternativní orchestrátory).
V naprosté většině situací budete provozovat Kubernetes nad (v horším případě) virtualizací, typičtěji nad plnou IaaS, třeba v Azure. Integrace těchto dvou světů je velmi důležitá. Tak například v cloud-native aplikacích chcete škálovat zdroje dle potřeby. To Kubernetes umí, přiklonuje vám kontejnery, ale to nemusí stačit - budete asi potřebovat i přeškálovat zdroje v IaaS, tedy přidat další nody (= zdroje s CPU a RAM). Navíc většinou vede nasazení Kubernetes na potřebu vícero clusterů. Izolace s kontejnery je v tuto chvíli postavena na OS (cgroups, namespaces apod.) a to nemusí odpovídat vašim bezpečnostním požadavkům. V praxi tak možná budete mít jeden cluster na vývoj a testování, jiný cluster na produkci aplikací podléhajících PCI-DSS a třetí cluster na běžné produkční aplikace. Schopnost vytvářet cluster na kliknutí a začlenit do správné sítě je dost zásadní.
Ale to není všechno. Kubernetes potřebujete integrovat síťově. Je k ničemu mít uvnitř perfektně řešené propojení a balancing, když se k tomu nikdo nedostane z venku. Kubernetes umožňuje se automaticky obracet na IaaS a vytvářet pravidla na externím balanceru. Podobné je to se storage. Pokud ve vašich kontejnerech potřebujete perzistenci dat, má Kubernetes storage drivery a umí si sáhnout do IaaS, vytvořit Volume a ten namapovat na kontejner.
A co když cloudová platforma nabízí služby, které chcete ve svém kontejnerovém světě využít co nejjednodušším způsobem přímo prostředky Kubernetes? Proč se babrat s databází, ztrácet s tím drahocený čas, brzdit projekt a dosahovat nižších SLA, když mám v Azure kompletní DB as a Service s SLA na dostupnost i výkon, globální distribuovatelností, zabezpečením i zálohováním a DR na kliknutí pro MS SQL, MySQL, PostgreSQL, Mongo DB, Cassandra nebo Gremlin? Proč se trápit s řešením redundantního message bus když je tu Azure Service Bus? Preferuji použití Kubernetes pro aplikační, převážně stateless, logiku a využití Azure služeb pro to ostatní. Další integrací Kubernetes a cloudu je podpora servisního katalogu, tedy schopnost přímo Kubernetes prostředky vytvářet zdroje v cloudu, například databáze, a přístupové údaje rovnou nativně poskytovat aplikačnímu kontejneru.
Pokud jedete svět mimo tradiční MS vývoj, třeba Java, Node, PHP, Ruby nebo Python, pro Kubernetes najdete velmi masivní podporu. Předně je tu celý open source ekosystém kolem a nad Kubernetes, zejména v těchto projektech, kde hraje Microsoft hlavní úlohu: Helm šablony, Draft pro vývojáře, Brigade a Kashti pro automatizaci, ACS/AKS plugin do Jenkins a nadstavby a moduly do Visual Studio Code. Kromě toho je řada dalších open source řešení, které vám pomohou s konkrétní implementací vývoje a CI/CD jako jsou pluginy do balíčkovacích nástrojů (například do Maven), ovládání kontejnerů i Kubernetes z Ansible či Chef a podpora pro různé CI/CD nástroje jako je Jenkins, Spinnaker, CircleCI, plugin do TeamCity nebo Travis CI a samozřejmě také PaaS laděná nadstavba typu Open Shift.
Přicházíte z krásně integrovaného ekosystému .NET? Visual Studio dnes umí pomáhat s montováním kontejnerů (zabalí vaší aplikaci automatizovaně a stačí si o to jen říct) a kromě možnosti použít Windows kontejnery pro tradiční .NET (podpora Kubernetes přijde s Windows Server 2019) je tu také .NET Core - open source .NET nové generace, který velmi spokojeně běží v Linux kontejneru v Kubernetes včetně podpory celého řetězce ve Visual Studio a Visual Studio Team Services pro CI/CD.
Přemýšlíte o kontejnerech? Začínáte s Kubernetes? Použijte Azure a AKS, plně spravovanou variantu jako služba. Vyzkoušet si něco malého u sebe s Minikube proč ne, ale vybudovat skutečně plnohodnotný cluster integrovaný do IaaS vrstvy je docela pracné a s pouhou virtualizací vám zůstane spousta věcí na ruční práci.
Příště se podíváme na základny Kubernetes a zprovozníme v AKS. Pak už se budeme moci vrhnout do detailů jednotlivých částí. Vraťte se zpět pro další porci.