saltstack, gyorsan kellett valami :) De a puppet-ről is jókat hallottam. A chef ha jól tudom akkor nagyobb gépparkhoz ajánlott.
-------------------- http://grant-it.com/
Igen, használom, Windows desktop-okhoz.
Windows alatt továbbra sem tökéletes az agent, de úgy nagy általánosságban jól megy.
Mást nem használtam mert tavaly hasonlítgattam őket, és ez tűnt a megfelelő tool-nak. Ma futnék egy kört még PowerShell DSC-vel is ha Windows környezetről lenne szó.
Én használok. Rosszat nem tudok mondani, eddig bevált. Fejlesztőkkel szokott gond lenni, akik a modulokat írják :) Nyilván van egyfajta belépési küszöb, amit meg kell ugrani hozzá, ez szokott gondot okozni. Van más alternatíva, pl Chef, Ansible, SaltStack, etc.
felszínesen használtam Puppetet és Chef-t is egyik sem rossz a maga nevében, de végül a SaltStack mellett döntöttem... nem bántam meg nagyon kézre áll.
A cél egyébként egy nagyjából tiszta CentOS 7 környezetben nagy tömegben kettő féle (Cassandra és Wildfly) node kezelése, egy ideje próbálgatom a Puppet-et, kezdem átlátni.
Ami tetszik, az tényleg a deklaratív leírás, hogy mit várok el, mint eredményt, de...
...sokszor procedurálisan kell megadnom, vagy nekiállnom a huszonkettedik modul fejlesztésének, mert a másik huszonkettő tud mindenféle dolgot, csak azt egyet nem, ami épp nekem kell.
...ha valami nem működik, akkor ténylegesen vért kell hugyozni, mire kiderül, hogy mi az oka, mert vagy túl általánosak a hibaüzenetek, vagy túl technikaiak és ha valaki nem ért a Ruby-hoz, akkor bizony megszívta.
...a dokumentációja kicsit meredek néha, mintha kihagynának dolgokat, amiket természetesnek vesznek, pedig nem az...
Tobb eves, tobb 100 node-os tapasztalat. Nincs kezi modositas a host-on, kizarolag puppet-en keresztul modositunk configot. Osszehasonlitani csak a cfengine-nel tudnam mivel azt hasznaltuk elotte.
Hatranya:
Nagyon flexibilis es sokfelekeppen lehet megcsinalni a dolgokat benne. Ha nem kovetsz valami pattern-t es sok gepes kornyezetben hasznalod (sok service-es igazabol) par honap module-iras utan jossz ra, hogy mit hogyan kellett volna szepen csinalni -> kezdodhet a refaktoring.
Szemely szerint a roles and profiles pattern-t ajanlom hiera-val. Ha koveted, akkor kb vegtelen hatalmas gepparkot lehet vele tiszta, atlathato szep koddal managelni.
Talalsz a neten sok irast rola, ezzel kezdheted: http://garylarizza.com/blog/2014/02/17/puppet-workflow-part-2/
Megeri megtanulni, mert talan a legtobbet hasznalt configuracio management tool nagy, enterprise kornyezetben (bar en a 10 server-es kornyezetben is ezt hasznaltam).
Erdemes megnezni pl. a Foreman-t is hozza, azzal egesz korrekt kis rendszer rakhato ossze.
Amit erdemes nagyon megnezni, hogy milyen modult telepitesz, mit tud. Sokszor van ugy (bar ez nem Puppet sajatossag), hogy nincs igazan olyan kozossegi modul, ami megfelelo lenne, es inkabb le kell fejleszteni egyet. En pl. igy jartam a monittal, van Puppet-hez is, Chef-hez is, de mind vagy rettenetesen buta, vagy csak a csomagot telepiti es csok. A vegen nekem kellett osszerakni egy modult. Ugyanez igaz pl. az adatbazisos modulokra is, vagy tokeletesen passzol, ami van, vagy mindenkepp uj modult kell irni.
Amire nagyon kell figyelni, az az agentek update time-ja. Fel ora tokeletes, ha valaminek ennel gyorsabban kell megtortennie, belepsz, es magad futtatod meg az agent-et, vagy ha van Foreman es a node-okra fel van szorva a Foreman SmartProxy, magad is meg tudod triggerelni a webes feluletrol. Lehet persze szukebb idot is hagyni, de a PuppetMaster alapbol nem teljesitmenyre van optimalizalva, akkor mar mokolni kell vele, hogy ne a beepitett Rubys webszerver tolja, hanem valami Rack-es tortenet, plusz nginx ele... eleg sok melo. Valamikor tervezek egy ilyen jellegu tutorialt irni, de... az nem mostanaban lesz.
Ha kell konkret implementacioban segitseg, nyugodtan irj itt, vagy keress meg privat - ahogy jobban tetszik. Akar uj modult is tudok irni, ha hianyzik a szukseges Ruby/Puppet fejlesztoi tudas.
-- Blog | @hron84 Üzemeltető macik
a master lassusagara a megoldas a Puppet Server, vagy a gepeken helyi checkout a konfig repobol es MCollective-vel vagy Salt-tal egy apply. en az utobbit hasznaltam, mert konnyebb volt telepiteni par nagysagrenddel. ha tobb szaz geped van, amugy is jol jon egy ilyen.
a roles+profiles pattern eleg jol mukodik, en most epp igy irok at Puppet 4-re egy Puppet 2.7-es kodbazist. nekem a Foreman amugy se jott be, de az R+P elonye, hogy pontosan egy sor a node definicioja, arra meg elegge agyu.
en meg hasznalom a hiera-eyaml-gpg-t, hogy a nyilvanosan tarolt repoba be lehessen rakni titkos dolgokat. rohej, hogy ezt senki nem oldotta meg normalisan, talan csak a Chef, de szerencsere most egyszerre 3 kezdemenyezes is van: Keywhiz, sneaker es a harmadik, ami most nem jut eszembe:/
Hat, nalunk biztos, hogy tobb olyan gep is lenne, amin nem csak egy role van (pl. backend szervereken tipikus, hogy van Redis es/vagy Memcached, plusz egy kis ez, plusz egy kis az), viszont nekem a Foreman azert jon be, mert egereszve tudom osszerakni a node konfigjat, gyak. be se kell lepni a Puppet szerverre.
Jol hangzik ez a Puppet Server, majd utana nezek, en a legtobb esetben alacsapom egy Thin-nek/Unicorn-nak a Puppet mastert, es utana Nginx-szel loadbalancelek.
-- Blog | @hron84 Üzemeltető macik
nalunk biztos, hogy tobb olyan gep is lenne, amin nem csak egy role van
akkor olvasd el a roles + profiles pattern bemutatojat: http://garylarizza.com/blog/2014/02/17/puppet-workflow-part-2/
minden gepen pontosan egy role van, ha tobb lenne, az egy ujabb role.
Igen, csakhogy egy letezo infrastruktura importalasanal nem igazan lehet alkalmazni az ilyen nagy fenyes patterneket, legfokeppen azert nem, mert ha az altalad mondott szabalyt betartom, akkor gyakorlatilag gepenkent lehetne kulon role-t gyartani, akkor meg mar akar node-nkent is konfiguralhatnam a puppetet, es feleslegesek lennenek a role-k.
En azt gondolom, hogy a Chef role megkozelitese kozelebb all ahhoz, amivel egy meglevo rendszert le lehet fedni, ahol a role gyakorlatilag a kulonbozo de egybetartozo konfiguraciok halmaza, mittudomen, egy MySQL kiszolgalo, es a gepen fennlevo dolgokat role-kba szervezem, tehat ha egy gep mondjuk MySQL es LDAP kiszolgalo is, akkor kerul ra ket role, egy MySQL es egy LDAP role. Mivel nincs kozottuk atfedes, igy nem kerulhet konfliktusba a ketto.
De persze, ez mero hitvita, szoval nem akarlak meggyozni az igazamrol, csak elmondtam, en hogyan gondolkodom.
-- Blog | @hron84 Üzemeltető macik
a Chef role-jai itt inkabb a profile-oknak felelnek meg, es a role modulra is fokent a Hiera adatok behuzasa koruli szopkoraszas miatt van szukseg.
de persze egyik pattern sem csodafegyver es konnyen elkepzelheto olyan kornyezet, ahol pont ezt nem praktikus megvalositani.
En eleve nem szeretem ezeket a dolgokat tulbonyolitani, es ritkan intezek mindent Puppetbol. A legtobbszor nekem csak az a celom, hogy a gep feleljen meg bizonyos ceges standardoknak, peldaul legyen rajta alapbol belove az NRPE/Munin/Monit szentharomsag, legyenek fenn bizonyos generikus csomagok az adminisztraciohoz (screen, ncftp, mc, vim, ilyesmi), es ha adott a szerver kicsit generikusabb szerepkore, akkor a szerepkorhoz tartozo csomagok is legyenek fenn. Magat az adott szerepkort altalaban nem, vagy csak bizonyos reszeit konfiguralom Puppetbol. Peldaul a foszer altal is emlitett WP site-t pl. mappa/fajl szinten biztos, hogy definialnam, de a MySQL adatok peldaul eleg trukkosek tudnak lenni, foleg, ha nem is azon a gepen van a MySQL szerver. De egyebkent is averzioim vannak ezzel kapcsolatban, bar ez talan abbol ered, hogy nem tudtam ezt az ujfajta Puppetet tesztelni.
-- Blog | @hron84 Üzemeltető macik
CFengine utan most tesztelunk az atallasra(4. honapban jar). Valahogy nem erzem, hogy kezre allna, de majd ezt is megszokom.
Saltstack-ot en sokkal emberkozelibbnek erzem, kb 2hetes tesztelessel a hatam mogott.
(Dolgoztam cfengine-nel, puppet-tel és ansible-lel elég sokat - a chef és a saltstack kimaradt.)
Egy érdekes aspektusa a dolognak, hogy a Puppet elsősorban deklaratívnak szánt konfig menedzsment rendszer. Ez elméletben a nyerő megoldás. Mark Burgess-nek a cfengine kapcsán vannak erről kiváló fejtegetései, szépen és tudományosan bizonyítja, hogy sokkal jobb így intézni a dolgokat, mint egyszerűen megmondani a gépeknek, hogy mit csináljanak. Ezzel én messzemenően egyet is értek. Elméletben.
De van egy "kis" gond: az elérhető rendszergazdák többsége számára a deklaratív konfig menedzsment gondolata idegen, nem tudnak vele azonosulni, nem tudnak ilyen környezetben hatékonyan dolgozni és a tapasztalatom alapján sokszor hosszabb távon is csak szenvedés marad nekik a dolog. Ha abban a szerencsés helyzetben vagy, hogy egy halom olyan rendszergazda vesz körül, aki vágja a témát, akkor a puppet tök jó dolog. Ha az átlagos helyzetben vagy, akkor próbálkozz inkább az ansible-lel, könnyebben megérthető lesz és jobban segíteni fogja a hatékonyságot.
"Egy érdekes aspektusa a dolognak, hogy a Puppet elsősorban deklaratívnak szánt konfig menedzsment rendszer."
Vannak benne kihívások... :)
Egy ideje már használom, de eddig csak alap dolgokra, vagyis többnyire olyan beállításokra, mint a szükséges csomagok, swap beállítása, időzóna, postfix relay, satöbbi, tehát leginkább annyi volt a célom, hogy ha létrehozok egy új VPS-t, akkor az ilyen apróságokat ne kelljen kézzel szögelnem, de alkalmazás specifikus dolgokat nem bíztam rá.
Most költöztetem a Cassandra node-okat két DC között, mert a Vultr frankfurti központjában kissé túl vannak terhelve a gépek és tényleg jóval lassabb, mint az amszterdami DC, de kb. két napja keresem a fogást a Cassandra és a Puppet kapcsolatán, mert ugyan van három modul, de egyik se volt jó. Modult írni pedig most nagyon nincs kedvem, mert jelenleg a Puppet futtatáson túl egy node költöztetése (Cassandra telepítés, konfigurálás, adatintegritás ellenőrzés) kb. 15-20 perc munka, a modul megírása pedig ránézésre egy hetembe simán belekerülhet... nem arányos.
A Puppet Forge is kicsit ambivalens, mert ránézésre nagyon változatos a kínálat és nem érzem magam biztonságban, hogy ha leakasztok a szögről egy modult, akkor nem fogok-e ez miatt hetekkel-hónapokkal később szívni... :)
"De van egy "kis" gond: az elérhető rendszergazdák többsége számára a deklaratív konfig menedzsment gondolata idegen"
Ez jelenleg one-man-show, szóval nem érdekel, hogy milyenek az átlag rendszergazdák. Saját magamról szeretnék terhelést levenni, hogy ne foglalkozzak automatizálható dolgokkal, a közvetlen értékteremtésre szeretnék rámenni. :)
mert ugyan van három modul, de egyik se volt jó. Modult írni pedig most nagyon nincs kedvem, mert jelenleg a Puppet futtatáson túl egy node költöztetése (Cassandra telepítés, konfigurálás, adatintegritás ellenőrzés) kb. 15-20 perc munka, a modul megírása pedig ránézésre egy hetembe simán belekerülhet... nem arányos.
Pont ezért felejtős az egész. Nagyon szép design, tök jó célok, csak hát iszonyat overhead. Az egyszerű admin minek programozgasson egy (többnyire) szaros konfig fájl beállításához. Ami puppetben pl. 1 hét, az ansible-vel 1 nap (se). És nem lesz rosszabb, vagy áttekinthetetlenebb az eredmény (sőt). Ráadásul modult írni is egyszerű hozzá.
Megnézem majd, ha eljutok odáig, de most az a helyzet, hogy viszonylag sok munkám van a Puppet konfigokban és kevés időm, hogy egy újabbat tanuljak meg és arra sincs időm, hogy modult írjak a hiányzó funkciókra.
Azt hiszem az oprendszer szintjéig egyelőre marad a Puppet, arra teljesen jól bevált, a Cassandra node és a Wildfly slave telepítést megoldom kézzel, aztán majd újra átgondolom később, hogy mivel dolgozzak. :)
En ket iteracioban irok Puppet modul, eloszor osszecsapok siman csak valamit a Puppet nyelven ugy, hogy a legtobb resource altalaban egy Exec/File resource-ban vegzodik, aztan mikor lecsillapodtak a kedelyek, akkor atirom normalisra - ha van ra igeny. Egy Exec-ekbol allo konfigot par perc osszehozni, mondjuk negyed-fel ora kidebugolni, es mar meg is van, mert gyakorlatilag azokat a parancsokat tolod bele, amiket amugy is elsutnel SSH-n at. Messze van a szeptol, az idealistol meg hajjaj, de mukodik.
-- Blog | @hron84 Üzemeltető macik
No, de alapvetően az eddigi SSH-n futtatott script gyűjteményt akartam lecserélni valami olyanra, ami elterjedt és nem érzékeny annyira a konkrét operációs rendszerre. Ez részben működik a Puppet-tel, részben nem... egyelőre működik, aztán majd lecserélem, ha lesz időm vagy előnyt ad a csere.
Pont ezert jo elso korben Exec-ekkel megirni, mert a meglevo scriptgyujtemenyek konkret parancsai igy atultethetoek, raadasul ezt a felet a legkonnyebb megerteni, mert csak a fuggosegeket kell jol osszeloni, es szevasz. Aztan, ha mar megvolt a migracio, es minden mukodik faszan Puppettel, el lehet melyedni a Ruby kod rejtelmeiben, libeket, factokat irkalni, es szofisztiakltra megoldani a rendszert.
-- Blog | @hron84 Üzemeltető macik
Minden akarat kérdése... a Puppet-be nem fogok több időt tenni, ha jelentős mértékben hozzá kellene nyúlnom, akkor más eszközt választok, mert egyre kevésbé érzem alkalmasnak a feladatra, ahogy már írtam volt:
...sokszor procedurálisan kell megadnom, vagy nekiállnom a huszonkettedik modul fejlesztésének, mert a másik huszonegy tud mindenféle dolgot, csak azt egyet nem, ami épp nekem kell.
...ha valami nem működik, akkor ténylegesen vért kell hugyozni, mire kiderül, hogy mi az oka, mert vagy túl általánosak a hibaüzenetek, vagy túl technikaiak és ha valaki nem ért a Ruby-hoz, akkor bizony megszívta.
...a dokumentációja kicsit meredek néha, mintha kihagynának dolgokat, amiket természetesnek vesznek, pedig nem az...
Azert a rendszergazda, ha automatizalhat, es sok gepes kornyezetben kell, akkor hulye lenne nem beletanulni.
Sajat modult irni meg nem nagy muveszet; bar en csak Puppettel dolgoztam.
En mindenkinek javasolnek elotte, valamifele standerd-eket lefektetni es ugy nekiallni. Pl. particiok meretei, webstack, apt, sudo, iptables, es meg sorolhatnam, mert kesobb rosszabb lesz ujrairni.
"Azert a rendszergazda, ha automatizalhat, es sok gepes kornyezetben kell, akkor hulye lenne nem beletanulni."
Azért én már láttam karón varjút... :)
...amikor át kellett írni a /etc/resolv.conf fájlban az egyik névszerver IP címét, és a kétszázvalahány RHEL gépen a rendszergarázda egyenként belépett, a többségét tekintve kézzel jól megszerkesztette, némelyiket elszabta, aztán ellenőrzés nélkül kilépett én meg csodálkoztam, hogy miért nem látja a build szerver az svn szervert...
Igen, de én nem azt írtam, hogy nem automatizál a rendszergazda, hanem azt, hogy a deklaratív konfig menedzsment a többség számára nehezebben felfogható, mint az imperatív.
azert tegyuk azt is melle, hogy az a tisztan deklarativ konfiguracio a gyakorlatban neha ugy csap vissza, mint a kilincsbe akadt hozentroger. szep, hogy ennyire ragaszkodtak hozza, de azt is latni kell, hogy tobbek kozott az implementacio (nehol igen sulyos) korlatai miatt volt szukseg az imperativ elemeket behozni. es hat az elvek olyanok, mint a fing, pedig valaszthattak volna azt is, hogy ujrairjak az oroklodest, hogy mukodjon, vagy a Hierat integraljak jobban, vagy nem ulnek ket evet az RI Pienaar altal javasolt module_data megoldason (ami most nem is mukodik), hogy lehessen vegre normalis modulokat irni.
Hozzászólások
En hasznalok.
De mar JUMon is mondtam :)
--
"ssh in a for loop is not a solution" – Luke Kanies, Puppet developer
Ja... :)
--
http://wiki.javaforum.hu/display/~auth.gabor/Home
saltstack, gyorsan kellett valami :) De a puppet-ről is jókat hallottam. A chef ha jól tudom akkor nagyobb gépparkhoz ajánlott.
--------------------
http://grant-it.com/
Igen, használom, Windows desktop-okhoz.
Windows alatt továbbra sem tökéletes az agent, de úgy nagy általánosságban jól megy.
Mást nem használtam mert tavaly hasonlítgattam őket, és ez tűnt a megfelelő tool-nak. Ma futnék egy kört még PowerShell DSC-vel is ha Windows környezetről lenne szó.
Fő gyengesége a nyelv: deklaratívnak szánták, de nem lett az, hanem egy beteg öszvér kerekedett belőle.
Ezt használjuk, mert mélyen bele kellett menni mire kiderültek a gyengeségei. Bármi másnak jobban örülnék. :) Chef?
Én használok. Rosszat nem tudok mondani, eddig bevált. Fejlesztőkkel szokott gond lenni, akik a modulokat írják :) Nyilván van egyfajta belépési küszöb, amit meg kell ugrani hozzá, ez szokott gondot okozni. Van más alternatíva, pl Chef, Ansible, SaltStack, etc.
Salt ;-)
felszínesen használtam Puppetet és Chef-t is egyik sem rossz a maga nevében, de végül a SaltStack mellett döntöttem... nem bántam meg nagyon kézre áll.
+1
--
A legértékesebb idő a pillanat amelyben élsz.
https://sites.google.com/site/jupiter2005ster/
Ha még nem kezdted el, szerintem ne is tedd :)
Saltstack, ansible sokkal egyszerűbbek.
A cél egyébként egy nagyjából tiszta CentOS 7 környezetben nagy tömegben kettő féle (Cassandra és Wildfly) node kezelése, egy ideje próbálgatom a Puppet-et, kezdem átlátni.
Ami tetszik, az tényleg a deklaratív leírás, hogy mit várok el, mint eredményt, de...
...sokszor procedurálisan kell megadnom, vagy nekiállnom a huszonkettedik modul fejlesztésének, mert a másik huszonkettő tud mindenféle dolgot, csak azt egyet nem, ami épp nekem kell.
...ha valami nem működik, akkor ténylegesen vért kell hugyozni, mire kiderül, hogy mi az oka, mert vagy túl általánosak a hibaüzenetek, vagy túl technikaiak és ha valaki nem ért a Ruby-hoz, akkor bizony megszívta.
...a dokumentációja kicsit meredek néha, mintha kihagynának dolgokat, amiket természetesnek vesznek, pedig nem az...
--
http://wiki.javaforum.hu/display/~auth.gabor/Home
SaltStack!
Tobb eves, tobb 100 node-os tapasztalat. Nincs kezi modositas a host-on, kizarolag puppet-en keresztul modositunk configot. Osszehasonlitani csak a cfengine-nel tudnam mivel azt hasznaltuk elotte.
Hatranya:
Nagyon flexibilis es sokfelekeppen lehet megcsinalni a dolgokat benne. Ha nem kovetsz valami pattern-t es sok gepes kornyezetben hasznalod (sok service-es igazabol) par honap module-iras utan jossz ra, hogy mit hogyan kellett volna szepen csinalni -> kezdodhet a refaktoring.
Szemely szerint a roles and profiles pattern-t ajanlom hiera-val. Ha koveted, akkor kb vegtelen hatalmas gepparkot lehet vele tiszta, atlathato szep koddal managelni.
Talalsz a neten sok irast rola, ezzel kezdheted: http://garylarizza.com/blog/2014/02/17/puppet-workflow-part-2/
Megeri megtanulni, mert talan a legtobbet hasznalt configuracio management tool nagy, enterprise kornyezetben (bar en a 10 server-es kornyezetben is ezt hasznaltam).
+1
Erdemes megnezni pl. a Foreman-t is hozza, azzal egesz korrekt kis rendszer rakhato ossze.
Amit erdemes nagyon megnezni, hogy milyen modult telepitesz, mit tud. Sokszor van ugy (bar ez nem Puppet sajatossag), hogy nincs igazan olyan kozossegi modul, ami megfelelo lenne, es inkabb le kell fejleszteni egyet. En pl. igy jartam a monittal, van Puppet-hez is, Chef-hez is, de mind vagy rettenetesen buta, vagy csak a csomagot telepiti es csok. A vegen nekem kellett osszerakni egy modult. Ugyanez igaz pl. az adatbazisos modulokra is, vagy tokeletesen passzol, ami van, vagy mindenkepp uj modult kell irni.
Amire nagyon kell figyelni, az az agentek update time-ja. Fel ora tokeletes, ha valaminek ennel gyorsabban kell megtortennie, belepsz, es magad futtatod meg az agent-et, vagy ha van Foreman es a node-okra fel van szorva a Foreman SmartProxy, magad is meg tudod triggerelni a webes feluletrol. Lehet persze szukebb idot is hagyni, de a PuppetMaster alapbol nem teljesitmenyre van optimalizalva, akkor mar mokolni kell vele, hogy ne a beepitett Rubys webszerver tolja, hanem valami Rack-es tortenet, plusz nginx ele... eleg sok melo. Valamikor tervezek egy ilyen jellegu tutorialt irni, de... az nem mostanaban lesz.
Ha kell konkret implementacioban segitseg, nyugodtan irj itt, vagy keress meg privat - ahogy jobban tetszik. Akar uj modult is tudok irni, ha hianyzik a szukseges Ruby/Puppet fejlesztoi tudas.
--
Blog | @hron84
Üzemeltető macik
a master lassusagara a megoldas a Puppet Server, vagy a gepeken helyi checkout a konfig repobol es MCollective-vel vagy Salt-tal egy apply. en az utobbit hasznaltam, mert konnyebb volt telepiteni par nagysagrenddel. ha tobb szaz geped van, amugy is jol jon egy ilyen.
a roles+profiles pattern eleg jol mukodik, en most epp igy irok at Puppet 4-re egy Puppet 2.7-es kodbazist. nekem a Foreman amugy se jott be, de az R+P elonye, hogy pontosan egy sor a node definicioja, arra meg elegge agyu.
en meg hasznalom a hiera-eyaml-gpg-t, hogy a nyilvanosan tarolt repoba be lehessen rakni titkos dolgokat. rohej, hogy ezt senki nem oldotta meg normalisan, talan csak a Chef, de szerencsere most egyszerre 3 kezdemenyezes is van: Keywhiz, sneaker es a harmadik, ami most nem jut eszembe:/
Hat, nalunk biztos, hogy tobb olyan gep is lenne, amin nem csak egy role van (pl. backend szervereken tipikus, hogy van Redis es/vagy Memcached, plusz egy kis ez, plusz egy kis az), viszont nekem a Foreman azert jon be, mert egereszve tudom osszerakni a node konfigjat, gyak. be se kell lepni a Puppet szerverre.
Jol hangzik ez a Puppet Server, majd utana nezek, en a legtobb esetben alacsapom egy Thin-nek/Unicorn-nak a Puppet mastert, es utana Nginx-szel loadbalancelek.
--
Blog | @hron84
Üzemeltető macik
"gyak. be se kell lepni a Puppet szerverre. "
svn a baratod ;)
Ezt nem értem, az SVN hogyan tud nekem segíteni ebben? Illetve miért csak az SVN tud ebben nekem segíteni?
--
Blog | @hron84
Üzemeltető macik
nalunk biztos, hogy tobb olyan gep is lenne, amin nem csak egy role van
akkor olvasd el a roles + profiles pattern bemutatojat: http://garylarizza.com/blog/2014/02/17/puppet-workflow-part-2/
minden gepen pontosan egy role van, ha tobb lenne, az egy ujabb role.
Igen, csakhogy egy letezo infrastruktura importalasanal nem igazan lehet alkalmazni az ilyen nagy fenyes patterneket, legfokeppen azert nem, mert ha az altalad mondott szabalyt betartom, akkor gyakorlatilag gepenkent lehetne kulon role-t gyartani, akkor meg mar akar node-nkent is konfiguralhatnam a puppetet, es feleslegesek lennenek a role-k.
En azt gondolom, hogy a Chef role megkozelitese kozelebb all ahhoz, amivel egy meglevo rendszert le lehet fedni, ahol a role gyakorlatilag a kulonbozo de egybetartozo konfiguraciok halmaza, mittudomen, egy MySQL kiszolgalo, es a gepen fennlevo dolgokat role-kba szervezem, tehat ha egy gep mondjuk MySQL es LDAP kiszolgalo is, akkor kerul ra ket role, egy MySQL es egy LDAP role. Mivel nincs kozottuk atfedes, igy nem kerulhet konfliktusba a ketto.
De persze, ez mero hitvita, szoval nem akarlak meggyozni az igazamrol, csak elmondtam, en hogyan gondolkodom.
--
Blog | @hron84
Üzemeltető macik
a Chef role-jai itt inkabb a profile-oknak felelnek meg, es a role modulra is fokent a Hiera adatok behuzasa koruli szopkoraszas miatt van szukseg.
de persze egyik pattern sem csodafegyver es konnyen elkepzelheto olyan kornyezet, ahol pont ezt nem praktikus megvalositani.
En eleve nem szeretem ezeket a dolgokat tulbonyolitani, es ritkan intezek mindent Puppetbol. A legtobbszor nekem csak az a celom, hogy a gep feleljen meg bizonyos ceges standardoknak, peldaul legyen rajta alapbol belove az NRPE/Munin/Monit szentharomsag, legyenek fenn bizonyos generikus csomagok az adminisztraciohoz (screen, ncftp, mc, vim, ilyesmi), es ha adott a szerver kicsit generikusabb szerepkore, akkor a szerepkorhoz tartozo csomagok is legyenek fenn. Magat az adott szerepkort altalaban nem, vagy csak bizonyos reszeit konfiguralom Puppetbol. Peldaul a foszer altal is emlitett WP site-t pl. mappa/fajl szinten biztos, hogy definialnam, de a MySQL adatok peldaul eleg trukkosek tudnak lenni, foleg, ha nem is azon a gepen van a MySQL szerver. De egyebkent is averzioim vannak ezzel kapcsolatban, bar ez talan abbol ered, hogy nem tudtam ezt az ujfajta Puppetet tesztelni.
--
Blog | @hron84
Üzemeltető macik
CFengine utan most tesztelunk az atallasra(4. honapban jar). Valahogy nem erzem, hogy kezre allna, de majd ezt is megszokom.
Saltstack-ot en sokkal emberkozelibbnek erzem, kb 2hetes tesztelessel a hatam mogott.
(Dolgoztam cfengine-nel, puppet-tel és ansible-lel elég sokat - a chef és a saltstack kimaradt.)
Egy érdekes aspektusa a dolognak, hogy a Puppet elsősorban deklaratívnak szánt konfig menedzsment rendszer. Ez elméletben a nyerő megoldás. Mark Burgess-nek a cfengine kapcsán vannak erről kiváló fejtegetései, szépen és tudományosan bizonyítja, hogy sokkal jobb így intézni a dolgokat, mint egyszerűen megmondani a gépeknek, hogy mit csináljanak. Ezzel én messzemenően egyet is értek. Elméletben.
De van egy "kis" gond: az elérhető rendszergazdák többsége számára a deklaratív konfig menedzsment gondolata idegen, nem tudnak vele azonosulni, nem tudnak ilyen környezetben hatékonyan dolgozni és a tapasztalatom alapján sokszor hosszabb távon is csak szenvedés marad nekik a dolog. Ha abban a szerencsés helyzetben vagy, hogy egy halom olyan rendszergazda vesz körül, aki vágja a témát, akkor a puppet tök jó dolog. Ha az átlagos helyzetben vagy, akkor próbálkozz inkább az ansible-lel, könnyebben megérthető lesz és jobban segíteni fogja a hatékonyságot.
"Egy érdekes aspektusa a dolognak, hogy a Puppet elsősorban deklaratívnak szánt konfig menedzsment rendszer."
Vannak benne kihívások... :)
Egy ideje már használom, de eddig csak alap dolgokra, vagyis többnyire olyan beállításokra, mint a szükséges csomagok, swap beállítása, időzóna, postfix relay, satöbbi, tehát leginkább annyi volt a célom, hogy ha létrehozok egy új VPS-t, akkor az ilyen apróságokat ne kelljen kézzel szögelnem, de alkalmazás specifikus dolgokat nem bíztam rá.
Most költöztetem a Cassandra node-okat két DC között, mert a Vultr frankfurti központjában kissé túl vannak terhelve a gépek és tényleg jóval lassabb, mint az amszterdami DC, de kb. két napja keresem a fogást a Cassandra és a Puppet kapcsolatán, mert ugyan van három modul, de egyik se volt jó. Modult írni pedig most nagyon nincs kedvem, mert jelenleg a Puppet futtatáson túl egy node költöztetése (Cassandra telepítés, konfigurálás, adatintegritás ellenőrzés) kb. 15-20 perc munka, a modul megírása pedig ránézésre egy hetembe simán belekerülhet... nem arányos.
A Puppet Forge is kicsit ambivalens, mert ránézésre nagyon változatos a kínálat és nem érzem magam biztonságban, hogy ha leakasztok a szögről egy modult, akkor nem fogok-e ez miatt hetekkel-hónapokkal később szívni... :)
"De van egy "kis" gond: az elérhető rendszergazdák többsége számára a deklaratív konfig menedzsment gondolata idegen"
Ez jelenleg one-man-show, szóval nem érdekel, hogy milyenek az átlag rendszergazdák. Saját magamról szeretnék terhelést levenni, hogy ne foglalkozzak automatizálható dolgokkal, a közvetlen értékteremtésre szeretnék rámenni. :)
Erről van szó nagyjából: http://prezi.javaforum.hu/gacivs-devop/
mert ugyan van három modul, de egyik se volt jó. Modult írni pedig most nagyon nincs kedvem, mert jelenleg a Puppet futtatáson túl egy node költöztetése (Cassandra telepítés, konfigurálás, adatintegritás ellenőrzés) kb. 15-20 perc munka, a modul megírása pedig ránézésre egy hetembe simán belekerülhet... nem arányos.
Pont ezért felejtős az egész. Nagyon szép design, tök jó célok, csak hát iszonyat overhead. Az egyszerű admin minek programozgasson egy (többnyire) szaros konfig fájl beállításához. Ami puppetben pl. 1 hét, az ansible-vel 1 nap (se). És nem lesz rosszabb, vagy áttekinthetetlenebb az eredmény (sőt). Ráadásul modult írni is egyszerű hozzá.
Megnézem majd, ha eljutok odáig, de most az a helyzet, hogy viszonylag sok munkám van a Puppet konfigokban és kevés időm, hogy egy újabbat tanuljak meg és arra sincs időm, hogy modult írjak a hiányzó funkciókra.
Azt hiszem az oprendszer szintjéig egyelőre marad a Puppet, arra teljesen jól bevált, a Cassandra node és a Wildfly slave telepítést megoldom kézzel, aztán majd újra átgondolom később, hogy mivel dolgozzak. :)
--
http://wiki.javaforum.hu/display/~auth.gabor/Home
En ket iteracioban irok Puppet modul, eloszor osszecsapok siman csak valamit a Puppet nyelven ugy, hogy a legtobb resource altalaban egy Exec/File resource-ban vegzodik, aztan mikor lecsillapodtak a kedelyek, akkor atirom normalisra - ha van ra igeny. Egy Exec-ekbol allo konfigot par perc osszehozni, mondjuk negyed-fel ora kidebugolni, es mar meg is van, mert gyakorlatilag azokat a parancsokat tolod bele, amiket amugy is elsutnel SSH-n at. Messze van a szeptol, az idealistol meg hajjaj, de mukodik.
--
Blog | @hron84
Üzemeltető macik
No, de alapvetően az eddigi SSH-n futtatott script gyűjteményt akartam lecserélni valami olyanra, ami elterjedt és nem érzékeny annyira a konkrét operációs rendszerre. Ez részben működik a Puppet-tel, részben nem... egyelőre működik, aztán majd lecserélem, ha lesz időm vagy előnyt ad a csere.
--
http://wiki.javaforum.hu/display/~auth.gabor/Home
Pont ezert jo elso korben Exec-ekkel megirni, mert a meglevo scriptgyujtemenyek konkret parancsai igy atultethetoek, raadasul ezt a felet a legkonnyebb megerteni, mert csak a fuggosegeket kell jol osszeloni, es szevasz. Aztan, ha mar megvolt a migracio, es minden mukodik faszan Puppettel, el lehet melyedni a Ruby kod rejtelmeiben, libeket, factokat irkalni, es szofisztiakltra megoldani a rendszert.
--
Blog | @hron84
Üzemeltető macik
Nem akarok elmélyedni a Ruby rejtelmeiben...
--
http://wiki.javaforum.hu/display/~auth.gabor/Home
Ez nem akarat kerdese. Fogsz.
--
Blog | @hron84
Üzemeltető macik
Minden akarat kérdése... a Puppet-be nem fogok több időt tenni, ha jelentős mértékben hozzá kellene nyúlnom, akkor más eszközt választok, mert egyre kevésbé érzem alkalmasnak a feladatra, ahogy már írtam volt:
...sokszor procedurálisan kell megadnom, vagy nekiállnom a huszonkettedik modul fejlesztésének, mert a másik huszonegy tud mindenféle dolgot, csak azt egyet nem, ami épp nekem kell.
...ha valami nem működik, akkor ténylegesen vért kell hugyozni, mire kiderül, hogy mi az oka, mert vagy túl általánosak a hibaüzenetek, vagy túl technikaiak és ha valaki nem ért a Ruby-hoz, akkor bizony megszívta.
...a dokumentációja kicsit meredek néha, mintha kihagynának dolgokat, amiket természetesnek vesznek, pedig nem az...
--
http://wiki.javaforum.hu/display/~auth.gabor/Home
Pont ezert jo elso korben Exec-ekkel megirni, [...] es szevasz
LOL...
--
"Tudom én hogy nem biztonságos, de le van szarva az egész [...] A WoW jelszavam maradjon titokban csak az a lényeg!" (BlinTux)
Azert a rendszergazda, ha automatizalhat, es sok gepes kornyezetben kell, akkor hulye lenne nem beletanulni.
Sajat modult irni meg nem nagy muveszet; bar en csak Puppettel dolgoztam.
En mindenkinek javasolnek elotte, valamifele standerd-eket lefektetni es ugy nekiallni. Pl. particiok meretei, webstack, apt, sudo, iptables, es meg sorolhatnam, mert kesobb rosszabb lesz ujrairni.
"Azert a rendszergazda, ha automatizalhat, es sok gepes kornyezetben kell, akkor hulye lenne nem beletanulni."
Azért én már láttam karón varjút... :)
...amikor át kellett írni a /etc/resolv.conf fájlban az egyik névszerver IP címét, és a kétszázvalahány RHEL gépen a rendszergarázda egyenként belépett, a többségét tekintve kézzel jól megszerkesztette, némelyiket elszabta, aztán ellenőrzés nélkül kilépett én meg csodálkoztam, hogy miért nem látja a build szerver az svn szervert...
--
http://wiki.javaforum.hu/display/~auth.gabor/Home
khm, no comment. :)
Igen, de én nem azt írtam, hogy nem automatizál a rendszergazda, hanem azt, hogy a deklaratív konfig menedzsment a többség számára nehezebben felfogható, mint az imperatív.
igaz.
azert tegyuk azt is melle, hogy az a tisztan deklarativ konfiguracio a gyakorlatban neha ugy csap vissza, mint a kilincsbe akadt hozentroger. szep, hogy ennyire ragaszkodtak hozza, de azt is latni kell, hogy tobbek kozott az implementacio (nehol igen sulyos) korlatai miatt volt szukseg az imperativ elemeket behozni. es hat az elvek olyanok, mint a fing, pedig valaszthattak volna azt is, hogy ujrairjak az oroklodest, hogy mukodjon, vagy a Hierat integraljak jobban, vagy nem ulnek ket evet az RI Pienaar altal javasolt module_data megoldason (ami most nem is mukodik), hogy lehessen vegre normalis modulokat irni.
+1 az ansible-re
--
"Tudom én hogy nem biztonságos, de le van szarva az egész [...] A WoW jelszavam maradjon titokban csak az a lényeg!" (BlinTux)
+1
+1 ansible.