Rudder-ről vélemény?

Eldöntöttem, vége a salt-nak... Rengeteg vele a probléma egy ideje (korábban írtam, kérdeztem már erről). Pár napja, hete már most az is történik, hogy a 3-4GB ram-os gépek lefőnek... Mitől? A salt-tól, mert megeszi az összes RAM-ot. Leállítom, 7-800MB az össz memóriahasználat, szóval 2,3GB-ot megeszik. Az újév első projektje lesz azt hiszem kipicsázni.

A rudder így első ránézésre jónak tűnik alternatívaként. Sőt, jobbnak is mint a salt, mert van hozzá egy rendes UI. Gyakorlati tapasztalat valakinek?

Tudtok mást ajánlani?

Ami esetleg jó lenne, hogy ha a meglévő salt state-eket valahogy lehetne importálni, konvertálni...

Hozzászólások

Technikai szempontok az én szemszögemből:

- Java... annak minden előnyével és hátrányával.

- Csak 1 szerver lehet... Értem hogy nincs adatvesztés ha lefő, mert majd ha visszatér, akkor a node-ok betolják az adatokat. De ha épp akkor kéne valamit csinálni, amikor le van rohadva, akkor nem pár óra múlva kell, mire esetleg valahogy elindul.

- Doksi szerint: secure, secure, de azért public netre ne tedd, vagy csak VPN-en... :) Szóval ezzel le is van hárítva a felelősség ha bármi történik.

- Jó a web és jó hogy van, de hiányzik a cli interfész, illetve pl. egy-egy command futtatásának lehetősége csak úgy, és az output megkapása.

"Sose a gép a hülye."

A legfőbb hogy nincs agent, SSH-zgat a hostokra, amik szanaszét vannak, tűzfal, NAT mögött, és nem akarok ezzel szórakozni.

A windows-os támogatás nem tudom milyen. Egyáltalán azt se tudom, hogy a windowsra hogy SSH-zik.

A másik hogy csak úgy egy commandot nem lehet vele lefuttatni és az eredményt megkapni (ez mondjuk a rudder-rel is ugyanígy probléma; de javíts ki ha nem így van).

Az sem tiszta, hogy a free (community edition)-be pontosan mi van benne, vagy mik a limitek.

"Sose a gép a hülye."

Nem akarnálak rábeszélni, csak infó, hogy

Winről fingom sincs. 

Vagy valami "kerülő" megoldás jöhet még szóba, mint pl:

- VPN minden a kliensről az ansible server felé, és akkor a VPN-es IP-jén el lehet érni... Csak itt ugye problémás, hogy melyik kliens éppen milyen IP-n érhető el. Ha dinamikus, akkor hogy fogja frissíteni? Ha statikus, akkor kézzel kell managelni, hogy melyik kliens milyen IP-t kapjon.

- SSH a kliensről az ansible felé, és remote port forward, amivel betolja az ssh vagy épp winrm portját pl. az ansible loopbackjére... De a probléma itt is ugyanaz: hova? Ha fixen valahova, akkor managelni kell, ha dinamikusan, akkor hogy fog frissülni? Meg random fog portokat próbálni?

"Sose a gép a hülye."

Nekem összességében ezekkel az a nagy bajom, hogy ha megdöglik az extrás csatornád, akkor lehet szívni.

- VPN minden a kliensről az ansible server felé, és akkor a VPN-es IP-jén el lehet érni... Csak itt ugye problémás, hogy melyik kliens éppen milyen IP-n érhető el. Ha dinamikus, akkor hogy fogja frissíteni? Ha statikus, akkor kézzel kell managelni, hogy melyik kliens milyen IP-t kapjon.

Az ansible egy inventorynak nevezett listából dolgozik, abban vannak benne a nodeok (meg a groupok, meg az ilyen olyan metadata, ha kell). Ez fapad esetben egy kézzel szerkesztett yaml/ini, de nyilván vannak mindenféle már megírt inventory pluginek, amik létező adatbázisokból szedik elő ezeket az adatokat. Sőt, lehet is ilyet írni. Ha kézi munkázni kell, akkor én vagy írnék egy olyat, ami valahogy kiszedegeti a vpn konfig környékéből, vagy -- ami talán valamivel egyszerűbb, scale függő, hogy neked mi lesz a jó -- kézzel verném az inventoryba az új nodeokat, hostnévvel, és úgy csinálnék vpnt, hogy tartsa karban a dns bejegyzéseket. 

Persze, mindig lehet valamivel szívni. De ha 1-1 döglik meg időnként akármiért, azt lehet kézzel fixálni.

Ami inkább a baj, az örök probléma, hogy mi az a VPN, ami egyszerű, elérhető linuxon és windowson is és problémamentesen megy? Semmi....

- PPTP... Insecure, tudom. De mivel egy SSH megy benne, így talán nem érdekes. Viszont ha egy GW mögött több gép van, akkor a GRE miatt lehet probléma. (Bár, windowsra pl. a winrm titkosított? Mert ha nem, akkor annak semmiképp nem kéne pucéron mennie. Egyébként az SSH host key ellenőrzés hogy megy?)

- OpenVPN - windowson szopás a tun/tap driver - egyébként jó és működik (másra használjuk hasonló célból)

És ezzel kb. vége is a listának...

"Sose a gép a hülye."

Persze, mindig lehet valamivel szívni. De ha 1-1 döglik meg időnként akármiért, azt lehet kézzel fixálni.

Ha átlátod, és kezelhető méretű, akkor nyilván hajrá.

VPN ügyben passzpiros, wineket nem tutujgattam nagy tételben soha életemben. Amit láttam belőle, ott az OpenVPNnel nem volt baj sose. Vagy kell nézni vmi fizetőset esetleg.

Azert nincs vege annak a listanak :)

 

Legegyszerubb sztm a Tailscale. (Wireguard alappal) Kb next/next/finish a telepites, van mindenre (is), nem akadaly neki akarmilyen zart NAT sem (van HTTP relay server) Nem beszelve arrol , hogy sztm messze tul mutat egy "point to pint" VPN en, lenyegeben inkabb ZeroTier szeru "virtualis router"

* ansible-pull es akkor meg a gitOps is meg van oldva

* Windows-on winRM-en keresztul megy

* Nem igaz: 

$ ansible all -i "localhost," -c local -m shell -a 'echo hello world'       
localhost | CHANGED | rc=0 >>
hello world

De hasznalhatsz siman inventory file-t is es kesz, azaz az ansible-es geprol egyetlen host "ellen" is futtathatsz parancsot, barmit, akarmit. Mi is igy szoktunk riportokat gyartani

* Minden free, a gui a tower nem, de van community UI, ami ugyanaz (irtak elottem)

Ha mar ujat akarsz tanulni en javaslom hogy a defacto standard ansible legyen, de persze donthetsz mashogy is. Van benne vault, meg minden istennyila ami egy enterprise-ba csak kell es megis tok ingyenes es a community elegge fasza. itt is. :D

Mondjuk ha mindenaron agent-tel akarod csinalni akkor ugye az ansible kiesik, amikor adhoc command-ot akarsz futtatni. 

Bar ugye ha keves gepet managelsz, akkor kinyitni mindegyiken az ssh portot nem nagy dolog, illetve a winrm-et. ha meg nagyon sokat, akkor atz meg ugyis valami automatizmus huzza fel (pixie+kickstart, cobler, anyamkinyja) igy azt is konnyen meg lehet csinalni, csak ujra kell deployolni a gepet.

Szoval a kerdesre a valaszt Te tudod, hogy megeri e az ansible-el foglalkozni (szerintem mindenkeppen) vagy veszel valamit penzert vagy hasznalod a nem olyan kenyelmes puppet, chef vonalat.

Nem fogok semmit újradeployolni csak ezért, ez 1000%. :)

Igen, a linuxok pxe + kickstart-tal települnek. Nincs semmi varázslat, a ks-ek kézzel vannak készítve, megcsinálja egy full alap minimal installt, jelenleg a salt-miniont felrakja. Aztán a következő 1-2 lépcső a salt state, ami bekonfigurálja a rendszert általánosan, utána esetlegesen jöhet még pár specifikus state (pl. httpd fullsetup), utána meg a kézi munka, ami már mindig egyedi.

"Sose a gép a hülye."

Egyébként ami régen még egész használható volt az a puppet/theforeman, és a puppet agentes/pullos arch alapból. Nem tudom, milyenek mostanra.

A theforeman ha jól látom a deployt csinálja inkább. Ez a rész kevésbé érdekes.

Azt hiszem, a guin azért még volt ez az, de már baromi régen láttam. Ettől még a puppet jó lehet. 

Illetve így elnézve a satellite/spacewalk is erre épült. :D

Most hogy mondod. Mondjuk durva, hogy múltidőben, én még arra emlékszem, hogy majd a következő már erre fog :D

konkretan a satellite upstreamje jelenleg a  puppet/theforeman :) regen spacewalk volt de az mogul kiment az RH, ugy tom mar meg is szunt. Azt forkolta amugy a SUSE, abbol lett az uyuni, ami meg a Suse Manager upstreamje jelenleg :) O amugy Salt-ra epul, de mar tud Ansible-t is asszem par release ota. Mondjuk nem tudom... En salt ozok SUSE manager miatt, de nem tapasztaltam meg vele semmi ilyen nagy eroforras problemat....

Atfogalmazom, miert egy olyan technologiat valasztottal, ami tok uj, miert nem a meglevok kozul?

A puppet miertre onmagaban csak szubjektivan tudnek valaszolni. Inkabb ird le, mi az, ami nem OK a rudder eseten egeszen es ha tudom, megmondom, hogy van a puppet eseten. Lattam mar, h irtal vmi listat, csak ha jol ertem, az menet kozben modosult mar.

Mert 4-5 éve mikor ez szembejött, akkor elkezdtem vele foglalkozni, tesztelni, lett egy master, behúztam alá 4-5 gépet tesztelni, és tök jó volt, jól működött minden. (Spacewalkról váltottunk, örültem hogy megszabadultam a bloatware, instabil, átláthatatlan, memóriazabáló servicektől). Úgyhogy kb. ebből a tesztből lett éles, lett másik master, felkerült a minion az összes gépre (a spacewalk utolsó rugásaként felrakattam vele a salt-miniont, aztán mikor bejött minden gép, akkor a salt-tal leszedettem a spacewalk-client-tet, a spacewalk szerver meg ment a levesbe). Egy fél nap alatt átálltunk. :) És kb. tavaly őszig minden tök jól is működött.

Ami a rudderből hiányzik:

- azonnali command futtatás és az command outputja (és ehhez kapcsolódóan a cli interfész)

- windows agent

Néha gondoltam rá, hogy jó lenne a salt-hoz egy web, amikor csak valami quick check vagy overview kell, de igazából megvoltam nélküle, és ezután is meglennék.

"Sose a gép a hülye."

> Mert 4-5 éve mikor ez szembejött, akkor elkezdtem vele foglalkozni, tesztelni, lett egy master, behúztam alá 4-5 gépet tesztelni, és tök jó volt, jól működött minden. (Spacewalkról váltottunk, örültem hogy megszabadultam a bloatware, instabil, átláthatatlan, memóriazabáló servicektől). Úgyhogy kb. ebből a tesztből lett éles, lett másik master, felkerült a minion az összes gépre (a spacewalk utolsó rugásaként felrakattam vele a salt-miniont, aztán mikor bejött minden gép, akkor a salt-tal leszedettem a spacewalk-client-tet, a spacewalk szerver meg ment a levesbe). Egy fél nap alatt átálltunk. :) És kb. tavaly őszig minden tök jól is működött.

Az bekezdes elejen mintha a Rudder-rol beszelnel, de a vegen meg a Salt-rol? Nem vilagos.

Mindenesetre ha a Rudder annyi idos, az nagyon meglep, mert eddig amugy nem hallottam rola. Mindenesetre majd megnezem.

> Ami a rudderből hiányzik:

> - azonnali command futtatás és az command outputja (és ehhez kapcsolódóan a cli interfész)

A puppet eseten asszem van vmi bolt nevu tool, ami talan ezt szolgalna, de igazabol passzolom.

Arra jottem ra, hogy a puppet config mgmt-re jo, deployment-re es remote command futtatasra viszont a legtobb esetben szivas. Az utobbi esetben (ami neked hianyzik), valoszinuleg mindig.

Csupan csak azert, mert masra valo, mas az elv. Amennyire latom, igazabol az ansible-vel (vagy barmi mas megoldassal) szoktak kombinalni.

 

Osszessegeben minden hasonlo automation toolnak van vmi gyenge pontja. Vagy configot tud jol manage-elni es szarul tud deploy-olni v. forditva (vagy vmi hasonlo).

 

> - windows agent

Elvileg van, sosem hasznaltam, bar tobb panaszt sem lattam ra, mint a linux-os agentre.

 

 

Hacsak ennyi, akkor valoszinuleg te elegedett Rudder user lehetsz, akkor meg kar lenne valtani.

 

Szivesen olvasnek amugy egy elmenybeszamolot par peldaval, esetleg egy osszehasonlitassal (pl. nennyi az overhead, mi a sebessege, milyen hatranyai vannak stb.)

Csak a puppet-hez tudok hozzaszolni, mert azt hasznaltam nagyon sokat, mind a 3 platformon (win, linux, osx).

Amire jo: config management olyan kornyezetben, ahol a gepek (viszonylag) allandoak. 

Megy, teszi a dolgat, azonban windows-on kicsit lassu, ellenben meg tudsz vele mindent csinaltatni. Mac-en is megy de ott a MacOS sajatossagaibol adodoan vannak vele szivasok, hasonloan a windows-hoz - de ez nem a puppet hibaja. 

Mivel mutual tls auth-ot hasznal es a kliens megy vissza a szerverhez, ezert nem kell vpn-el szivni, ha nem akarsz. (Elvileg, a cert alairas tud lenni serulekeny, de azt meg lehet offline is csinalni.)

 

Amire nem jo: provisioning-re.

 

Puppet bolt valo ad-hoc parancsok futtatasara, de en sem hasznaltam. 

És ad-hoc command futtatásra?

OSX nincs.

Windows kevés... Ha lassú, de amúgy megy és megcsinál mindent... OK, lenyelem. A salt is kb. 2-3x lassabb volt windowson mint linuxon. Már javítottak rajta sokat, de még mindig lassabb.

"Sose a gép a hülye."

Az a kerdes, hogy mire hasznaljatok a salt-ot. provisioning, configuration, vagy mindketto?

Eleg sok tool van, van ami mindkettot tudja, van ami csak az egyiket. Anno keresgeltunk, es baromi nehez volt levadaszni, melyik mit tud pontosan.

Provisioning:

pulumi, terraform, stb

configuration:

chef, puppet, cfengine, stb.

kombo:

ansible, salt, stb.
 

Sajnos kiprobalas nelkul szerintem nehez megmondani, mi fog bejonni/mukodni. (pl terraform melle is van consul, stb, amik kibovitik a funkcionalitast).

Igen én is ezt látom, hogy a saját oldalukról alig derül ki valami, hogy pontosan hogy működik, mire épül, mit tud, vagy mik a limitek. Gyakran még egy screenshot se volt. Egy idő után már ezeket meg se néztem, hanem youtube-on néztem róluk pár tutorialt, mert abból mérföldekkel több kiderül rövidebb idő alatt.

Config managementre, meg mindenfele ad-hoc jellegű dolgok futtatására, adatgyűjtésre.

"Sose a gép a hülye."