V praktickém průvodci pro Docker jsme v pátém díle mluvili o nativním nástroji, který zajišťuje velmi pohodlný provisioning infrastruktury. Víte, že HPE OneView, brána do komponovatelné infrastruktury, nabízí otevřený driver pro Docker Machine?

Infrastruktura vs. Docker kontejnery

Kontejnery jsou vrstva abstrakce, která může běžet například na Raspberry Pi (mini-počítač za 25 dolarů) i na HPE Proliant nebo HPE Synergy compute nodu. Můžete je spouštět v hypervisoru VMware, KVM i Hyper-V. Provozovat se dají ve veřejném cloudu Amazonu, Azuru i Rackspace. Otázkou tedy je, kdy je jaký podklad pro kontejnery vhodný.

Docker nebo ještě lépe kompletní PaaS (jako je Cloud Foundry například v distribuci HPE Stackato) může být vaší garancí přenositelnosti aplikací mezi různými prostředími, protože identickým způsobem poběží v Amazonu, Azuru, v OpenStack ve vašem datovém centru i na VirtualBoxu notebooku vývojáře. V takovém případě bude využití IaaS ideální forma podkladu.

Možná provozujete klasické IT a přemýšlíte o vytvoření moderního prostředí pro agilní část IT, ale tak, aby to bylo rychlé a pokud možno se v klasickém IT nic moc nezměnilo (nemyslím, že je to ideální přístup, ale budiž). Pak bude nejlepší Docker provozovat v klasické VM a tímto způsobem zajistit potřebné (certifikované a úřady orazítkované) oddělení, segmentaci provozu a soulad s aktuálními procesy.

Další velmi lákavá možnost je nainstalovat Docker přímo na fyzické stroje. Tímto způsobem získáváte fantastickou efektivitu využití zdrojů (žádné identické kopie kernelu v paměti, žádné simulace hardwaru, …). Na jednom běžně dostupném fyzickém serveru dnes můžete mít tisíce kontejnerů (nepřeháním). Oddělení kontejnerů není tak dokonalé jako u VM, kterým s tím pomáhají přímo instrukce v hardware (mimochodem i to se může změnit – pracuje se na implementaci kontejnerů s Intel VT sadou) a tak to možná není vhodný scénář pro současný běh produkční bankovní aplikace s internetovým portálem, testovacím prostředím a bezpečnostním honeypotem na stejném nodu. Nicméně proč to nevyužít pro nějakou třídu aplikace, byznys jednotku a pro tyto kategorie mít separátní nody/clustery? Právě pro takové scénáře je OneView driver pro Docker Machine ideální.

Docker Machine

Docker přichází s vlastním nástrojem pro provisioning hostitelů, o kterém jsme psali v našem seriálu. Připomeňme, že jde o jednoduchou aplikaci, která s využitím ovladače zajistí Docker hostitele. Nejprve připraví samotný Linux server, následně se k němu připojí, nainstaluje Docker, nakopíruje potřebné klíče a certifikáty, zapíše si je (a umožňuje pak přes docker-machine příkazy skákat do jednotlivých nodů) a dokonce zvládne i nainstalovat Swarm cluster apod. Z našeho pohledu teď bude zajímavá právě práce driveru, který zařizuje vznik serveru a samotného Linux hostitele. Jedním z driverů je například VirtualBox (otevřená virtualizace často používaná na noteboocích), který vytvoří VM, jejíž šablonu si před tím automaticky stáhne. Jiným je třeba OpenStack driver, kterému řeknete kde je váš OpenStack, jaký základní Linux image chcete použít, do jaké sítě má koukat a jak velký má server být, a docker-machine zprostředkuje vytvoření příslušné VM. Podobným způsobem to funguje s drivery pro veřejný cloud jako je Amazon či Azure.

To všechno jsou ale scénáře s VM. Dalo by se nějak jednoduše pracovat přímo s fyzickými servery, což přináší řadu výhod v efektivitě využití zdrojů, například umístit na blade žiletku tisíce kontejnerů? O tom je open source driver pro HPE OneView.

OneView driver pro Docker Machine

HPE OneView je nástroj pro ovládání infrastruktury programovatelným způsobem, tedy Infrastructure as Code. Nejen to. Nabízí práci s hardwarem podobnou tomu, co známe z virtuálních světů, kde můžeme pružně přiřazovat compute, storage a networking zdroje. Je tak zástupcem Composable Infrastructure. Driver pro Docker Machine je volně k dispozici na Github:

https://github.com/HewlettPackard/docker-machine-oneview/

Jak pracuje s aktuální generací hardware a OneView verzí 1.20 a 2.00? První co potřebujeme v docker-machine je získat server. V případě VM je to relativně jednoduché, řeknete její velikost (typ), síťové připojení a to je vlastně všechno. OneView driver umožňuje ve fyzickém světě pracovat stejně jednoduše. Ve OneView si můžete vytvořit profily či chcete-li šablony fyzických serverů obsahující nastavení jejich vlastností (včetně způsobu jejich napojení do sítě, připojení SAN a dalších voleb). V Docker Machine tedy použijete jméno příslušné šablony přepínačem –oneview-server-template, OneView samo najde příslušný volný server, nastaví a propojí ho dle potřeby. Druhým krokem je mít k dispozici základní Linux OS pro následnou instalaci Docker. V případě VM je to opět snadné, použijete hotovou šablonu, z které základní OS naběhne. U fyzického světa je to složitější, ale díky Insight Control server provisioning (ICsp), což je nástroj krásně provázaný s OneView, se i takový úkol stává hračkou. V ICsp musíte mít připravený OS build plán (tedy řekněme “načtený” cílový Linux OS, ICsp následně zajistí jeho plně automatizovanou instalaci na cílovou serverovou žiletku). V rámci příkazu docker-machine tak uvádíte právě příslušný build plán (–oneview-os-plan). Máte HPE Blade servery, OneView a ICsp? Pak máte Infrastructure as Code – váš Docker může přímo sahat do fyzických zdrojů bez (mnohdy) zbytečné ztráty výkonu a jednoduchosti přes hypervisor, který je někdy navíc.

Composable Infrastructure

Možná jste slyšeli o projektu HPE Synergy, který naplňuje myšlenky Composable Infrastructure. V čem bude v tomto scénáři jiný? Z pohledu Docker Machine prakticky v ničem a to je přesně to správné! OneView vám dává Infrastructure as Code a v tomto případě hotový driver. Jak je to skutečně implementováno je záležitost OneView a driveru, vás to trápit nemusí. Vy používáte příkazy docker-machine a neřešíte, jak je uděláno. Implementace v případě HPE Synergy ale pravděpodobně bude trochu jiná. Tak například ona šablona serveru bude podstatě zajímavější a bude mít víc možností – třeba schopnost volit počet a typ lokálních disků apod. Synergy podporuje stateless servery. Místo skutečné instalace základního OS přes nástroj ICsp budete v budoucnu moci využít Streameru, tedy jakéhosi zásobníku imagů, z kteréhp server přímo nabootoje (místo lokálních disků nebo nějaké LUN ze SAN s nainstalovaným OS). Server je tak zcela bezestavový, což našemu scénáři docela vyhovuje (když žiletka umře, tak s tím počítáme – kontejnery různými mechanismy spouštíme v clusterech a po opravě žiletky z ní jednoduše vytvoříme nového hostitele). Scénář pak je: docker-machine řekne “Chci další node určitého typu a konektivity pro můj Docker cluster”. Synergy posbírá jednotlivé zdroje a z komponent sestaví fyzický server, ten nechá bezestavově naběhnout do hostitelského OS a zajistí vhodnou konektivitu, docker-machine nainstaluje Docker a následně Docker Swarm, tedy clusterovací systém.

Stačí si tedy říct a během chvilky máte větší kapacitu pro vaše kontejnerové aplikace. A co v noci? Co třeba použít docker-machine k odebrání nodu z clusteru a přes Chef modul pro OneView udělat z této žiletky node v Hadoop clusteru tak, aby se přes noc mohla chroupat nějaká velká data s tím, že mu přihodíme ještě pár lokálních SSD disků, ať si může lépe ukládat dočasné výpočty? Ráno pak můžete žiletku zase vrátit do Docker clusteru. Takhle se pracuje s Composable Infrastructure!