Written by Jak vypadají vaše image (nebo chcete-li šablony) ve vaší klasické virtualizaci? Jedna z nejčastějších otázek v diskusích kolem OpenStack s KVM jako hypervisorem je, jak mám konvertovat svoje VMware obrazy. Odpovědi na to sice existují, ale upřímně řečeno obávám se, že špatně je samotná otázka. Nasazení IaaS jako je OpenStack a potenciální snížení závislosti na jediném hypervisoru (docela dobré a typické nasazení je v produkci KVM a vSphere a v dev/test KVM a VirtualBox s Vagrantem) je dobrou příležitostí přemýšlet o vaší strategii kolem tvorby a používání diskových obrazů. Nicméně tyto úvahy nejsou nijak specifické pro IaaS. Všechno v tomto článku se vás týká i pokud zatím stále jen virtualizujete.
Přístupy k tvorbě a užívání image
Myslím, že existují v zásadě tři přístupy.
Image vznikají tak, že něco ve VM ručně kutáme a výsledek uložíme jako nový obraz
- Výhoda: Nemusíme se nic učit, takhle se to dělalo i v prehistorii
- Nevýhoda: Každý image je unikát, vše trvá dlouho, vzniká velké množství chyb, opakovatelnost je velmi problematická, dokumentace prakticky neexistuje nebo je špatně, závislost (více či méně) na hypervisor platformě (a s tím spojená špatná přenositelnost a problém nekonzistencí mezi vývojem, QA a produkcí)
Máme základní diskový obraz a konfigurační nástroje, které ho dostanou do stavu požadovaného aplikací
- Výhoda: Vše je automatizované a dopadne vždy stejně, výborná a živá dokumentace, nezávislost na hypervisor platformě a přenositelnost
- Nevýhoda: Příprava služby (aplikace) trvá dlouho, troubleshooting vyžaduje znalosti
Používáme immutable servery, tedy image je read only a pro každou verzi aplikace vždy vzniká nový fixní obraz
- Výhoda: Rychlý start, vysoká bezpečnost (lze třeba i vypnout SSH přístup apod.), pro provoz jednoduché nasazení, při použití vhodných nástrojů lze jedním postupem vygenerovat funkčně identické obrazy pro různé hypervisory a platformy (přenositelnost)
- Nevýhoda: Nutnost změnit development strategii a naučit se používat nové nástroje předávání údajů aplikacím místo tradičních konfiguračních souborů
První potup znáte jistě velmi dobře, pojďme se tedy soustředit na druhé dva.
“Dotahování” VM aneb immutable image
Základem této strategie je úvaha, že je riskantní nacházet se v nějakém mezistavu. Možná to znáte z některých svých činností – někdy je rychlejší a jednodušší začít od začátku, než se pokoušet napravit něco, co se vám nebo někomu jinému zrovna nepovedlo. Někdy to třeba rychlejší a jednodušší není, ale je tu jedna jistota. Pokud vyjdete ze stejných startovních podmínek a budete opakovat identický postup, dojdete ke stejnému výsledku. Aby byla zajištěna přesnost v postupu, bude ho dělat robot (ve formě vhodného nástroje). Pokud tedy potřebujete obraz s nainstalovanými komponentami jako je web server, aplikační server, knihovny a tak podobně, začnete ze základního obrazu s operačním systémem a pak si stáhnete všechny potřebné aktualizace a komponenty dle předpisu. Mohl by to vlastně být nějaký skript, ale to je strašně špatně udržitelné a museli byste pokaždé vymýšlet všechno znova. Sáhněte tedy raději po vhodném nástroji, který to udělá přehledně, předvídatelně, spoustu věcí vyřeší za vás, existují k němu rozsáhlé knihovny hotových modulů a příkladů a ideálně dokonce podporuje metodu desired state (tedy definujete cílový stav a na pořadí operací nezáleží).
Co použít? Nejstarší CFEngine bych dnes už doporučoval nechat odpočívat, ale můžete vyzkoušet jednoho ze dvou soupeřících dospěláků – Puppet a Chef. První je napsaný v Ruby, zaměřuje se na desired state princip (tedy deklarativní přístup), na serverech používá agenta a je velmi oblíbený. Ten druhý je také v Ruby (a část v Erlang), má řadu zajímavých vychytávek, je spíše řešen imperativně (více se podobá programování) a kromě konfigurace serverů exceluje i v dalších zajímavostech (testování softwaru nebo compliance check). Možná vás ale zaujmou i mladí, kteří na to jdou bez agentů a pro většinu lidí jsou jednodušší na seznámení. Tím jsou Ansible a SaltStack, oba napsaní v Python, oba hojně využívající nádherně čitelné předpisy (YAML a Jinja šablony). Já osobně pro začátek doporučuji Ansible, ale pak není špatné zkusit třeba Chef, který je velmi rozšířený (ale všechno je otázkou osobního vkusu a potřeb – v této čtyřce neuděláte chybu). Více o Ansible a Chef najdete v mém českém lab guide pro Helion OpenStack 2.0 (v sekci ke stažení bude už brzy, dám vědět). Pokud hledáte něco, co si poradí se vším včetně třeba UNIX systémů a má velmi bohatou knihovnu, nabízí GUI, compliance a je zavedené a prověřené v enterprise, zkuste komerční HPE Server Automation.
Co tedy potřebujete? Používáte pouze základní image – Okna 2012 R2, Ubuntu 14.04, CentOS 7 a to je třeba všechno. Pak máte ale připravené role (recepty, scénáře, …) pro jednotlivé typy serverů. Potřebujete novou verzi knihovny, jiné sestavení vaší aplikace nebo změnu nastavení? Rozhodně ji neprovedete ručně, ale zadáte ji do předpisu vámi vybraného nástroje. Většina z nich vám umožní stejnou sestavu spustit na vašem už běžícím serveru (na to existuje krásné slovo – nástroj je idempotentní), protože co už tam je se pouze ověří, že je v požadovaném stavu, a co tam chybí nebo nesedí se opraví. Stejně tak ale můžete vzít původní image a vybudovat všechno znovu (pokud jde o rychlý security patch, může být fajn to udělat na existujícím VM, ale ve většině případů bych volil cestu vybudovat si vše znova – ostatně takto stávající VM vůbec nemusíte vypínat a omezovat její dostupnost pro uživatele, až bude druhá nahoře funkční, můžete uživatele překlopit nějakým mechanismem – pro jednoduchost zatím řekněme DNS, ale na cloudsvet si povíme podstatně lepší metody).
Zapouzdřené aplikace aneb immutable server
Dotahování image je sice výborné z pohledu opakovatelnosti, dokumentace, přenositelnosti a plné automatizace, ale může trvat dlouho. Pokaždé musíte stáhnout hromady balíčků (někdy je dobrý nápad mít lokální cache), upravit a nakopírovat spousty souborů, instalovat služby. Všechno sice dělá precizní automat, ale zkrátit čas se mu nemusí podařit. Pokud by v předpisu byla chyba, je nutné ji zachytit, a protožo takový deployment už má blízko k Operations týmu, musí v něm být potřebné znalosti. Ze všech těchto důvodů se dá jít ještě dál a připravovat zlaté obrazy, tedy golden image a immutable server.
Myšlenka spočívá v tom, že vyjdete z předchozího scénáře, protože ten vám dává všechny příjemné vlastnosti desired state způsobu práce. Jeho výsledky ovšem přetavíte v hotový obraz – a samozřejmě automatizovaně. Můj nejoblíbenější nástroj je v tomto ohledu jednoznačně Packer (už brzy si ho vyzkoušíte v cloudsvět Helion OpenStack 2.0 labu). Packer je jednoúčelový nástroj – stejných výsledků dosáhnete i v rámci univerzálnější orchestrace typu HPE Operation Orchestration či jeho open source varianty CloudSlang. Začínáte tím, že Packeru předhodíte výchozí obraz s OS. V předchozím kroku byly nástroje nezávislé na hypervisoru, tady to tak není – nicméně můžete jedním krokem a způsobem vyrobit obrazy pro různé platformy. Do předpisu tedy dáme třeba Debian obraz ve vSphere, OpenStack s KVM a Amazon AMI – tyto obvykle nemusíme vytvářet, existují už hotové. Packer pak každý tento image spustí v příslušném prostředí a provede “dotažení” – shell skript, Ansible, Chef a mnohé další podle vaší chutě. Následně z výsledku udělá nový image a ten připraví ke spuštění. Tak například v OpenStack to funguje tak, že Packer si sám na pozadí vytvoří instanci výchozího image, zajistí spuštění dotahovačů, pak instanci vypne, udělá z ní nový image, který je v OpenStack k dispozici pro spuštění. Totéž platí pro Amazon nebo vSphere a kromě toho Packer umí i čisté QEMU/KVM nebo VirtualBox včetně přípravy Vagrant boxů. A mimochodem dnes už podporuje i Docker kontejner, takže se stává docela dobrou migrační cestou pro ty, co kromě VM zkouší i kontejnery.
Výsledkem je, že provoz získává image s instancí aplikace, kterou stačí spustit v požadovaném počtu. Je dokonce možné v zapouzdření jít tak daleko, že necháte Packer na konci procesu zlikvidovat management přístup do VM, tedy zakázat SSH či RDP. Řešení je velmi spolehlivé, jednoduché pro provozáky a vše se spouští velmi rychle a dají se tak použít vychytávky jako je autoscaling cloud native aplikací. Je tu ale jedna změna – v předchozím případě nám konfigurační nástroj mohl zajistit i aplikační konfiguraci (tedy sdělit VM s aplikací kde má DB a jak se do ní nalogovat). V tomto scénáři něco takového není vhodné – naše zlaté obrazy by neměly mít pevně danou konfiguraci v sobě. Nastavení a objevování nodů by tedy mělo být ideálně mimo vlastní obraz. Na to existují nástroje jako je Etcd, Consul, Zookeper nebo doozerd – ale o těch jindy. Immutable servery jsou perfektní, ale už po vás vyžadují trochu víc znalostí a přemýšlení – ale odměna je sladká.
Jak se svět mění s kontejnery
O kontejnerech na cloudsvět píšeme často a dnešní článek o nich není. Ale když se zamyslíme – používáme nástroje, které vezmou základní obraz a přidají do něj balíčky a aplikace – to zní jako Dockerfile. Když máme hotovo můžeme z toho vytvořit nový zlatý obraz – jako Docker commit. Snažíme se dát konfigurace pokud možno mimo image. Naznačuji, že immutable servers koncept má ke kontejnerům velmi blízko a ve finále funguje jak s VM, tak s kontejnerem. Pokud tuto cestu začnete tak pro sebe děláte velmi dobře a tento způsob přemýšlení se vám hodí pro svět VM i kontejnerů.
