Proč potřebujete kontejnery?

Již jsme mluvili o výhodách a nevýhodách nejpopulárnější technologie DevOps roku 2019 – platformy pro správu kontejnerů Kubernetes pro systémy Big Data. Dnes si povíme, proč jsou kontejnery vůbec potřeba, jak se liší od virtuálních strojů, jaké jsou jejich výhody a nevýhody a proč je potřeba jejich orchestrace.

Obsah

1. Co je kontejnerizace aplikací a jak funguje
2. Jaký je rozdíl mezi kontejnerem a virtuálním strojem?
3. Výhody a nevýhody kontejnerů v Big Data
4. Proč je nutná orchestrace: jak pracovat s více kontejnery v systémech Big Data

Co je kontejnerizace aplikací a jak funguje

Kontejnerizace (virtualizace na úrovni operačního systému, kontejnerová nebo zónová virtualizace) je metoda virtualizace, při které jádro operačního systému spravuje více izolovaných instancí uživatelského prostoru namísto pouze jedné. Z uživatelského hlediska jsou tyto instance (kontejnery nebo zóny) zcela totožné s jednotlivými operačními systémy. Jádro poskytuje úplnou izolaci kontejnerů, takže aplikace z různých kontejnerů se nemohou navzájem ovlivňovat [1].

Nefunkční kontejner je soubor (množina souborů) na disku. Při spouštění nádoby kontejnerový motor (Docker, CRI-O, Railcar, RKT, LXC) rozbalí obraz kontejneru s potřebnými soubory a metadaty a přenese je do jádra operačního systému (OS).

Kontejnerový motor – jedná se o software, který přijímá požadavky uživatelů vč. Parametry příkazového řádku, které stahují obrazy kontejnerů a spouštějí je. Spuštění kontejneru je podobné spuštění systémového procesu a vyžaduje volání API do jádra operačního systému. Toto volání API obvykle zahájí další izolaci a připojí kopii souborů, které jsou v bitové kopii kontejneru. Zároveň komunikuje s jádrem OS za účelem spouštění kontejnerizovaných procesů. doba běhu kontejneru je nízkoúrovňová komponenta, která se obvykle používá jako součást kontejnerového motoru, ale může být také použita ručně k testování kontejnerů. Runtime kontejneru přijímá z kontejnerového enginu bod připojení kontejneru (při testování to může být pouze adresář) a metadata kontejneru (při testování to může být ručně vytvořený soubor config.json).

Po spuštění se kontejner stane systémovým procesem. Postup při spouštění kontejnerů, stejně jako formát obrázků kontejnerů uložených na disku, jsou definovány a regulovány normami. Dnes je nejoblíbenější Standard Open Container Initiative (OCI)., která specifikuje formát obrázků kontejnerů, definuje formát disku pro jejich uložení a také metadata (hardwarová architektura, operační systém) [2].

Jaký je rozdíl mezi kontejnerem a virtuálním strojem?

Na rozdíl od hardwarové virtualizace, kdy je emulováno hardwarové prostředí a lze spustit více hostujících OS, je instance OS pouze se stejným jádrem jako původní (hostitelský) operační systém spuštěna v kontejneru. Tímto způsobem všechny kontejnery uzlů sdílejí společné jádro. Zároveň odpadá další režie zdrojů pro emulaci virtuálního hardwaru a spuštění plnohodnotné instance OS, což je typické pro virtualizaci hardwaru. Existují implementace pro vytváření téměř kompletních instancí OS (Solaris Containers, Virtuozzo kontejnery, OpenVZ), stejně jako možnosti izolace jednotlivých služeb s minimálním operačním prostředím (jail, Docker) [1], které se nejčastěji používají v systémech Big Data, s přihlédnutím k rostoucí oblibě architektury mikroslužeb.

Kontejnery vám tedy umožňují umístit mnohem více aplikací na jeden fyzický server než jakýkoli virtuální stroj, který zabírá mnohem více systémových prostředků (RAM a procesorových cyklů). Na rozdíl od virtuálního stroje, kde je emulován OS a potřebný virtuální hardware, kontejner ukrývá pouze aplikaci a nezbytné minimum systémových knihoven. Díky tomu můžete na jednom serveru provozovat 2-3x více aplikací. Kontejnerizace také umožňuje vytvořit přenosné a holistické prostředí pro vývoj, testování a následné nasazení, což odpovídá přístupu DevOps [3].

Výhody a nevýhody kontejnerů v Big Data

Z pohledu využití kontejnerizace aplikací v Big Data jsou nejvýznamnější tyto výhody této technologie: [4]:

• standardizace – díky základně otevřených standardů mohou kontejnery běžet na všech hlavních distribucích Linuxu, Microsoftu a dalších populárních OS;
• nezávislost na kontejneru ze zdrojů nebo architektury hostitele, na kterém běží, usnadňuje přenositelnost obrazu kontejneru z jednoho prostředí do druhého a poskytuje nepřetržitý sled procesů DevOps od vývoje a testování až po nasazení (CI/CD potrubí);
• izolace – aplikace v kontejneru běží v izolovaném prostředí a nevyužívá paměť, procesor ani disk hostitelského OS, což zaručuje izolaci procesů uvnitř kontejneru a poskytuje určitou úroveň zabezpečení. Více o bezpečnosti v kontejnerových technologiích, zejména o zranitelnostech Kubernetes, jsme psali v samostatných materiálech.
• znovupoužitelnost – všechny komponenty potřebné ke spuštění aplikace jsou zabaleny do jednoho obrazu, který lze spustit vícekrát;
• rychlost nasazení – vytvoření a spuštění kontejneru vyžaduje mnohem méně času než vytvoření instance virtuálního stroje nebo nastavení plnohodnotného pracovního prostředí;
• zvýšení produktivity práce – pokud je každá mikroslužba komplexního systému zabalena do samostatného kontejneru, za který zodpovídá jeden vývojář, pak lze pracovní úkoly paralelizovat bez vzájemných závislostí a konfliktů;
• zjednodušení sledování – Verze obrazů kontejnerů vám umožňuje sledovat aktualizace a vyhnout se problémům se synchronizací.

Se všemi výše uvedenými výhodami se však virtualizace kontejnerů vyznačuje následující nevýhody:

• „zabalení“ do kontejneru mnohem více zdrojů, než aplikace vyžaduje, což vede k rozšíření obrazu a velká velikost kontejner [5];
• problém bezpečnosti informací – a to i přesto, že mnoho systémů pro práci s kontejnery (Kubenetes, Docker atd.) obsahuje ochranu proti hackingu a ztrátě dat, například izolaci jmenného prostoru, flexibilní mechanismy pro síťové politiky a autorizaci uživatelů podle rolí podle klíče, stejně jako dalších nástrojů, o kterých si povíme podrobněji v dalším článku, není používání kontejnerů vždy bezpečné. Například některé důležité subsystémy jádra operačního systému Linux fungují mimo kontejner (periferie, SELinux, Cgroups a celý souborový systém uvnitř systémové oblasti /sys). Díky tomu je možné hacknout operační systém, pokud má klient (uživatel nebo aplikace) kontejneru práva root [5]. Přečtěte si o tom více v našem dalším článku.
• problém zajištění kvality s rostoucím počtem kontejnerů, včetně rozložení pracovní zátěže – k řešení tohoto problému se používají kontejnerové orchestrační systémy, o kterých si povíme později.

Proč je nutná orchestrace: jak pracovat s mnoha kontejnery v Big Datové systémy

Pro následující akce je nutná organizace kontejnerů v systémech Big Data [2]:

• nasazení více kontejnerů současně v různých prostředích (na počítači vývojáře, na testovacích a produkčních serverech, v prostředí obnovy po havárii, v cloudovém clusteru atd.), což odpovídá konceptu DevOps neustálého vývoje, testování a dodávání softwaru;
• dynamická distribuce kontejnerů napříč uzly clusteru (vyvažování zátěže);
• neustálé sledování stavu kontejnerové aplikace a automatické obnovení jejich selhání (restart).

Moderní trh bezplatného a proprietárního softwaru nabízí mnoho systémů pro orchestraci kontejnerů. Kubernetes, Apache Mesos a Red Hat OpenShift jsou považovány za nejoblíbenější a vhodné pro spolehlivé a vysoce zatížené systémy Big Data. Pro nepříliš velké projekty se hodí Docker Swarm, Nomad, Fleet, Aurora. Pozoruhodná jsou také cloudová řešení Amazon EC2 Container Service a Microsoft Azure Container Service [6].