Dotaz: Eventy napric radou serveru

[Ray]

Hoj, hledal jsem a nejak jsem nenasel nic dostatecne jednoducheho a pouzitelneho. A nez si to psat, tak bych rad zkusil, jesli uz nekdo neco takoveho neresil, jakoze urcite resil :)

Potreboval bych provazat radu serveru 'eventama'. Tj. napriklad na jednom serveru nastane commit SSH a nejakej jinej si ma udelat 'svn update'. Aktualne to resim klasicky - tj. ssh, klice a spousteni skriptu/prikazu. Nicmene z casoprostoroveho pohledu je v tom bordel, protoze ty nahdlery jsou rozdistribuovany na X stroju a za rok clovek vi prd, co je na co navazany.

Rad bych ale mel nejakeho "daemona", ktery by tohle nejak rozumne obalil. Moje predstava je, ze mi nejakej program vyvola event (typicky skript) coz je neco, co ma nejaky nazev/parametry. Nicmene, ten event se vyvola na k tomu urcenem 'mastrovy' ktery tento event preposle vsem ostatnim - a to bud ve formne eventu, nebo jiz rovnou 'prikaz' co se ma provest (lokalne). Tj. skript udela 'ssh kamsi s parametrama'. Tim to pro nej konci.

Tj. moje predstava handleru je, ze mam nejaky soubor, kde mam definovano co kterej pocitac ma pri kterem eventu (resp. parametru) provest (a zde mit moznost nacist parametr eventu). Pokud se dany event nepovede (poslat, chybny navratovy kod, ...) tak buzer email.

Takhle nejak jednoduse, zadna dalsi slozitost. Veci co zavani heradbeat/puppet (tedy HA) nechci, zbytecne komplikovane. Navic je taky pouzivam a rad bych to odelil od sebe.

Neznate neco, co by tyhle pozadavky nejako jednoduse splnilo ? Rozhodne to musi bezet jen v ramci SSH, nerad bych nejake dalsi sluzby a otevrene porty.

Diky za hinty

R.

---

---

Odpovědi

[DarkKnight]

Kdyby nebyla nutna podminka SSH, tak to splnuje Salt Reactor, obavam se ze na SSH si budes muset napsat nejaky vlastni script

[Ray]

Vypada to zajimave. Posledni dobu zacinam byt docela zklamanej z "orchestration", kdy se veci navzajem kupi tak, ze fungujou pomalu uz jen nahodou :) X zavisi na Y to na Z. Jenze pokud se konfiguruje X primo, tak ma Y problem. Ve skutenocsti se to musi prez Z, ale to neporuruje tohle a tohle... Brrr :) Nejkrasnejsi priklad je openstack (ac treba openvswitch a dalsi vyuzite casti jsou samostatne naprosto skvele ! ovs rulez :) Proto bych rad to SSH ve smyslu jednoduchosti.

Tady ale vypada, ze salt je 'core' a funguje i 'sam', takze urco stoji za to projit si jak funguje.

Diky

R.

[Josef Kufner]

To, co jsi popsal, se da udělat docela snadno pomocí SSH a pár skriptů a šikovné adresářové struktury.

Na master serveru budeš mít jeden adresář pro každý event. V každém takovém adresáři budou skripty, které se mají spustit, když event přijde. Příchod eventu bude spočívat ve spuštění skriptu, který jako první parametr veme event (t.j. název adresáře) a spustí postupně všechny skripty v daném adresáři. Ostatní parametry nezměněné předá skriptům.

Vyvolání eventu pak bude vypadat takto: ssh master ~/event-bus/invoke-event $nazev_eventu $parametr.

~/event-bus/invoke-event bude něco jako: for f in ~/event-bus/on-$event.d/* ; do [ -x "$f" ] && $f $@ ; done

A pak už zbývá jen roznést všude SSH klíče a máš hotovo. Případně přihodit ssh wrapper, který daný příkaz spustí všude (puppet?).

Jednotlivé reakce na eventy pak jsou jen prosté skripty v určeném adresáři, takže je vše přehledné a hlavně na jednom místě.

Logování a e-maily pri chybách si pořešíš v tom invoke-event skriptu (je to pár řádek kódu).

Pokud chceš asynchronní eventy, tak z invoke-event volej at. Pak navíc můžeš k eventu přidat i čas, kdy se má spustit.

[Ray]

Diky :) Tak nejak mi to taktez prislo nejjednodussi s tim, ze bych to bylo na FS co by se mountoval (RO). Ale ty prace to nakonec odladit. Proto jsem si rikal, ze urco nejsem jedinej, kdo neco takhle jednoduchyho chce resit jednoduse....

R.

[Josef Kufner]

Tu adresářovou strukturu se skripty na obsluhu eventů jsem zamýšlel pouze na masteru. Klienti o ničem vědět nebudou – master se na ně v reakci na event připojí po SSH a udělá, co je potřeba.

[bla.bla]

ansible je presne to co potrebujes :) ansible tower je free do 10 strojov a tam to mas pekne centralne spravovane.

[Ray]

Taky jsem po tom pokukoval, ale patri to uz do kategorie 'resi to vsechno' a po nedavnych zkusenostech co mam s 'orchestration' (openstack a podobny) bych se tomu docela rad vyhnul. Nejak se ta komplexita zavilosti a funkcnosti docela zvrhla. Fakt je ale, ze ANS jsem na vlasni kuzi jeste nemel tu cest/smulu* poznat :) jako to redhatu funguje, ta komerce ? Mam nulovou zkusenost.

R.

* nehodici skrnout

[bla.bla]

riesi to presne to co si nakonfigurujes v playbookoch :) Hlavna vyhoda je to ze si vystaci s portom 22, ssh klucmi a zakladnym pythonom nainstalovanym na klientoch. Maju celkom bohatu zakladnu library(budu podporovane vsetky zakladne git,svn atd. a operacie nad nimi), maju dostupne ansible galaxy(repozitar verejnych playbookov), moznosti su takmer neobmedzene. Licencia je potrebna len na Tower, podrobnosti si pozri na stranke, maju tam transparentny pricing model.

[Ruža Becelin]

Primlouvam se za ansible - primocare, minimalni learning curve.

Chci se zeptat, co za spatnou zkusenost mas s OpenStack? Ja pouzivam OS od release Juno a nemam s tim zadne problemy.

Na Red Hatu funguje komerce tak, ze si to clovek natrenuje na CentOS a upstream verzich a ve firme se pak poridi supportovana verze.

[GeorgeWH]

mozno serf