OpsMop je nový projekt autora Ansible, YAML mění za Python 3

Jméno Michael DeHaan vám zřejmě nic samo o sobě neřekne. Když ale dodáme klíčové slovo Ansible, pak už určitě vědět budete. Ano, Michael DeHaan je původní autor Ansible (seriál na Rootu) a zakladatel Ansible, Inc., kterou v roce 2015 odkoupil Red Hat.

Nebyl to ovšem jediný jeho počin v této oblasti: je autorem provisioningového serveru Cobbler a spoluautorem frameworku Func. Zároveň to není určitě počin poslední, protože si letos odskočil vytvořit projekt Vespene.io a nyní představil svého nejmladšího potomka: nástroj OpsMop.

Ansible byl neočekávaný a příliš rychlý úspěch

Ansible vznikl na základě šíleného nápadu vytvořit konfigurační nástroj využívající SSH, vzpomíná DeHaan. Díky podpoře a dobré radě přátel se během měsíce či dvou dostal k použitelnému stavu, kdy Ansible dokázal konfigurovat CentOS a Debian a další distribuce rychle přibývaly.

Projekt se okamžitě v komunitě chytil, začal překotný vývoj, lidé vytvářeli vlastní moduly a Ansible „odstartoval jako raketa“. Úspěch to byl obrovský, ale podle autora až příliš rychlý. Neměl jsem čas ho vyvíjet, jak bych chtěl, říká dnes. Musel se starat o nově založenou firmu, spolupracovat s obrovskou komunitou tvořící moduly a na samotný jazyk Ansible už mu nezbyl čas.

Původní plán počítal s vytvořením jednoduchého jazyka, který bude fungovat jako nákupní seznam nebo chcete-li kuchařský recept. Požadavky ale narůstaly a s nimi i komplexita, která nakonec nutně přetvořila nákupní seznam v plnohodnotný programovací jazyk. Co bylo myšleno jako jednoduchý základ, se stalo něčím úplně jiným.

O tři roky později

Autor v roce 2015 prodal firmu Red Hatu a z projektu Ansible tak vystoupil. Na jedné straně to pro něj znamenalo opuštění zajímavé komunity, ale dalo mu to možnost podívat se na věc s odstupem a z jiné perspektivy. Kdybych podobnou věc začínal dnes, jak bych to udělal? Co bych změnil? Co nejlepšího bych dokázal vytvořit?

Tak vznikl OpsMop, nová generace automatizace, jak autor sám tvrdí. Zatím toho ještě moc není, jsem ve fázi, kde jsem s Ansible byl po dvou až třech týdnech vývoje, přiznává. Původně to byl experiment, ale postupně jsem došel k tomu, že to je config management, který chci používat.

V tuto chvíli jde spíše o koncepci, OpsMop není ještě vhodný pro produkci, ale má jasný směr. Existuje základní funkční jazyk a způsob psaní modulů, obojí už funguje. Ansible je dobrý traktor, dělá dobře těžkou práci. Tohle je ale můj nový sporťák, vysvětluje autor. Zaujme nové publikum i část toho starého.

16 věcí, které jsou jinak

Michael DeHaan představil svůj projekt podrobněji, především jeho hlavní rysy. Sepsal 16 věcí, které jsou proti Ansible jiné a zároveň lepší. Tím také vysvětlil, co můžeme od OpsMop čekat.

1. Opravdové smyčky – jakékoliv konstrukce a externí interakce jsou možné, pokud máte skutečný jazyk.
2. Opravdové proměnné – místo komplikovaného vlastního přístupu k proměnným se opět prosadil klasický přístup známý z programovacích jazyků.
3. Šablony na vyžádání – místo šablonování všeho a odhadování, co je a není proměnná, už OpsMop šablonuje na výslovné požádání.
4. Moduly jsou součástí – už nejsou volány jako externí skripty a volání modulů jsou implementována jako běžné volání funkcí.
5. Přímočaré API – uvnitř je vše uspořádáno kolem slovníků a polí, všechno je přímočařejší, včetně API. Není rozdíl mezi jádrem a modulem, pokud se vám něco nelíbí, můžete si to upravit.
6. Rychlost – Python se už neforkuje při každém volání, takže se dají za sekundu zpracovat stovky požadavků (pokud se zrovna nečeká na balíčkovací systém).
7. Kontrola typů – u všech zdrojů je už při vytváření zkontrolován typ, takže se systém může zaměřit na chybějící soubory nebo argumenty ještě před konfigurací.
8. Vynucení rolí – role jsou na Ansible to nejlepší a OpsMop vynucuje jejich použití. Zároveň už nejsou nadstavbou, ale integrální součástí návrhu.
9. Skutečný graf – OpsMop přistupuje k politikám jako ke stromu zdrojů a handlery jsou linky propojující jednotlivé stromy. Trocha akademické komplexity prý neuškodí.
10. Režim pull a push – použití SSH se ukázalo jako škálovatelné na tisíce systémů, ale vznikla alternativa ansible-pull. OpsMop s tímto režimem počítá automaticky.
11. Hloubka a šířka – je užitečné mít nástroj s tisíci moduly, ale běžný uživatel jich potřebuje padesát. Vývoj se tedy bude soustřeďovat na relativně malou skupinu hlavních modulů.
12. Kompaktnější moduly – jazyk by měl být explicitnější a přehlednější. Místo věcí jako state=present/absent budou existovat příznaky  absent=True.
13. Líně vyhodnocovaná fakta – jednou z největších bolestí velkých playbooků u Ansible byla dlouhá doba vyhodnocování fakt. OpsMop přistupuje k faktům jako k funkcím, které jsou vyhodnoceny až podle potřeby.
14. Silná kompatibilita API – díky rokům praktických zkušeností můžeme vytvořit silný jazyk a zabránit rozbíjení kompatibility mezi verzemi.
15. OpsMop se zaměřuje na kód, ale stejně tak bude možné načítat sady proměnných pomocí seznamů v TOML, YAML nebo JSON. Lze přecházet mezi různými světy.
16. Opravdový běh nanečisto – testovací běhy (dry-run) jsou modelovány přesněji, generují se plány pro jednotlivé akce a vyhodnocuje se úspěšnost jejich provedení.

OpsMop startuje

Jaký tedy OpsMop je? V první řadě naplno využívá jazyka Python 3 a definuje zápis ve stylu Domain Specific Language (DSL). Sám autor uznává, že YAML nebyl dobrou volbou (není sám) a nový projekt na něm už nestaví. Není nutné ani psát šablony v Jinja2, i když je to stále možné.

OpsMop je psán výrazně čistěji s ohledem na kvalitu kódu, čitelnost a spravovatelnost. Velmi důležitým hlediskem vývoje je také výkon celého řešení. Je velmi důležité mít celý model správně, než se vrhneme na hromadu pull requestů. Později se už budou věci špatně měnit.

V tuhle chvíli se tedy ještě ladí základní principy a piluje se kostra základního jazyka a jádra samotného OpsMop. Pak celá tahle nová raketa může vzlétnout. Pokud chcete být u toho, sledujte GitHub, hlídejte novinky na Twitteru, čtěte dokumentaci nebo přispějte do fóra.