JSON? Taková ta hrůza, kterou různí bloudi používají pro konfiguraci některých věcí, kde ale nejde ani napsat pitomý komentář? A XML, tedy něco, co je přáíliš komplexní pro uživatele i stroje? No pěkně děkuju.
YAML není geniální. Nedá se ani -- stejně jako cokoliv jiného -- použít pro cokoliv, ale pořád je to snesitelnější než mnoho z toho, co se běžně pro jednoduché konfigurace používá.
No když jsem před lety na Ansible kouknul, tak jsem to rychle zavrhl, protože YAML a ne skriptovací jazyk přímo. YAML se hodí k popisu nějakých dat, ale až ve druhé linii (k zápisu dat ho ve finále používám, ale načte si ho až kód z fabfilu). Šáhl jsem po Fabricu a byla to dobrá volba. Dělalo se mi s tím od začátku mnohem lépe. Nepíšu si fabfily obecně pro více OS, ale soustředil jsem se pouze na Debian. To je asi výhoda a nevýhoda zároveň.
Jsem zvědav co tohle OpsMop bude ve srovnání s Fabricem.
Porovnávat Fabric a Ansible je srovnávat jabka s banánama. Je to ovoce, ale hodí se na jiné věci.
Fabric míří úplně jinam - říkáte, jak se má něco udělat. Taková civilizovaná náhrada Makefile nebo shellu.
Oproti tomu v Ansible (a jiných config-management nástrojích) popisujete deklarativně cílový stav - je to taková dokumentace toho, jak to má vypadat ve finále a existuje k tomu nástroj, jak ji spustit.
Asi jo. Já to vzal, že potřebuju něco mezi. Provádět něco hromadně na serverech, ale taky jim dávat jednotnou fazonu. Ve Fabricu jsem si napsal kód, který umí mimo jiné aplikovat "politiky", která jsem ve finále popsal v YAML :-). Přes fabric mohu dělat různé hromadné akce na serverech a aplikovat nějaké jednotné šablony na servery. Přišlo mi nějak jednodušší si to doimplementovat do Fabricu, než se učit moduly pro Ansible...
Ehm. Tak teďka mícháte jabka a banány vy. Ansible je pseudo-deklarativní, lze s ním deklarativně psát za předpokladu idempotentních modulů a určité pozornosti, ale to není jeho silná stránka. Je to ale především orchestestrační framework pro automatizaci konfigurací. Pomocí Ansible definujete že se má udělat A a pak B. To jde v deklarativních systémech hodně špatně (pomocí závislostí).
Čistě deklarativní je třeba Puppet, hodně uživatelů kombinuje sílu obou nástrojů - pomocí Ansible orchestrují Puppet který je naopak naprosto nevhodný k orchestraci (utopíte se v moži závislostí).
Já se nebudu pouštět do nějakého flamu, pravda je někde uprostřed, já jen chtěl dát poznámku že u té deklarativy bych byl velmi opatrný.
No tak za deklarativni v Ansible se dá považovat tak možná dobře navrženy model konfigurace. Jak dojde na tašky a role, už jde v reálu o konkrétní sekvenci které se musí stát, různé na sebe navazuji. Sice tu máme idempotenci, ale ta platí tak pro jednotlivé moduly. Já jsem naopak rád za jistou průhlednost toho, že když implementuje roli, jednotlivé kroky běží v nějakém pořadí. Paralelizace v rámci jednoho serveru je spíše specialitou.
A jak tu někdo píše, není vůbec špatně stavět se k tomu tak, že když to začne být komplikované, je třeba udělat krok zpět a zamyslet se zdá to nejde jednodušeji.
YAML mi dokonale vyhovuje, jednak je mnohem čitelnější než xml a json, druhak se snadno píše - nemusím řešit chybějící závorky, odsazení je vidět na první pohled. Na ansiblu oceňuju deklarativní zápis - neříkám co se má udělat, ale jak má server vypadat a většinou není má starost, jak toho ansible dosáhne :-). Absence nebo krkolomný zápis složitějších algoritmů... mi také vyhovuje, protože než přijdu na to, jak zapsat složitý algoritmus, zpravidla vymyslím mnohem jednodušší řešení problému. Jediné co mi vadí je prakticky nemožnost předpisy ladit - režim --check je prakticky k ničemu a ověřit že jsem drobným refaktoringem rolí definici serveru nerozbil je dost zdlouhavé - naklikat ve vmware nový server, pustit na něj ansible, ověřit že je vše jak má... velmi zdlouhavé a někdy nemožné.
Ja som dany problem vyriesil svojpomocne.
Spravil som si kniznicu s vlastnym DSL jazykom postavenym na C#, po ktoreho spusteni vypadne sablona pre Ansible. Mal som to napisane za den k plnej spokojnosti. Viem pouzivat cykly, podmienky a vsteky vyhody skutocneho jazyka a pritom zostavam deklarativny.
Ono YAML je podla mna hrozny format, ale proti formatom inych automation tollsov pre linuxove systemy ma tu vyhodu, ze je aspon ako tak standardny (Salt, Checf a Pupet pouzivajuv vlastne formaty).
Uvidime co vznikne o par rokov ked Michael DeHaan opusti OpsMop.
Obdobný nápad s vlastním DSL toolkem pro Ansible měli i jiní, není nutné hned si dělat vlastní kolo :-) Pokud se někomu líbí Ruby like DSL...
https://github.com/wied03/ansible-ruby
https://github.com/flajann2/ansible-powerplay
Praveze mne sa nepacilo Ruby, chcel som intelisense a vlastne in-build hepre pre opakovane ulohy. A hovorim, to koleso som mal hotove za den. A tym, ze som si to robil pre vlastne potreby som sa vyhol cyklom, premennym a inkludom vo vyslednom Yamly. Prosto moje potreby to splnilo.
Podle popsaneho cile to vypada zajimave. Nektere veci Ansible/YAML resi dost divoce, treba trochu komplexnejsi cykly. Dost rozhodne se na to v praci mrkneme. Zni to opravdu slibne
Pochopitelně píšu jen hypoteticky - nevím jaké problémy řeší pomocí složitých smyček. Já na ně narážel v různých situacích a řešení byla také různá - někdy pomáhá jiné rozvržení rolí, rozdělení role na několik, použití include role nebo yml souboru s tasky, použití handleru místo podmíněného tasku, nebo naopak podmíněný task místo handleru a v neposlední řadě i napsání vlastního modulu - čímž se to přesouvá do roviny OpsMod v tom, že problém popisuju v pythonu... ale protože omezím modul jen na ten jeden konkrétní problém (zapouzdření, jedna zodpovědnost), tak to neberu jako zesložitění celého jinak víceméně lineárního řešení.
Hele nevim, mas pravdu v tom, ze jakmile to zacne byt komplikovanejsi, tak se vyplati se zastavit a promyslet to. Ale mam jeden priklad, kdy mi to tak proste vyslo, ze bylo jednodussi prohnat to externi template, ktera zbuildi json, kterej si pak nactu. Celkovy vysledek je dobre citelny, jednoduchy na spravu. Mozna by prepsani celeho playbooku/role ve finale vyslo lepe, ale casove by to bylo dvounasobne a nejsem si jisty, ze by to nejak vyznamne prospelo.
Podle posledních informací je projekt discontinued: https://github.com/opsmop/opsmop
Co jsem si četl, tak autor nenalezl dostatek lidí, kteří by s ním na projektu spolupracovali a sám to táhnout nechce, protože drive mu dává právě komunikace s ostatními.