Puppet, Chef vagy Salt?

Linux-haladó

Ti melyik konfigmenedzsment szoftvert, használjátok és miért? Jelenleg Puppeten vagyok, de lehet váltani lenne érdemes.
Linux szerveren mondjuk jól megy, Windows klienseken viszont vannak furcsaságok. Kinek mi a tapasztalata?

Furcsa nekem, hogy ha hibára fut egy modulban, akkor a többit vagy megcsinálja vagy nem (nem a függőségeknél, mert nyilván az úgy jó). Nem tudom ez a többinél is így van? Puppetben lehet valahogy pusholni a configot? Most kb 4 óránként fut (úgy álítottam át), de néha jó lenne azonnal kiküldeni a változtatásokat, vagy parancsokat futtatni a klienseken.

Jelenleg kb 50 Linux szerverrel viaskodik és 25 windows-os klienssel.

Kicsit úgy érzem sok tapasztalat és ötlet kapcsán, hogy illene leírni az én tapasztalataimat is.
* Alapvetően jól működik (server 3.4, kliensek 3.7.3)
* Case sensitive problémába ütköztem ( C:\abcd != C:\ABcd) és sehogy nem tudom rávenni a pulletet, hogy ilyenkor írja felül az adott fájlt mappát, hibával elszáll.
* Ha hiba van akkor bizonytalan hogy melyik modulok futnak le és melyikek nem
* Nem lehet olyat mondani, hogy egy telepítés max 1 órát fusson, ha nem sikerül akkor nyilván valami gond volt.
* A klienseken 4 óránként fut le az ellenőrzés /így konfoltam/
* Nincs mód rá hogy a szerverről kinyomjunk egy frissítést vagy lefuttassunk parancsokat az összes vagy megadott gépeken
* Nem tudom (vagy nem tudom hogy tudhatom meg egyszerűen), hogy hol sikerültek a frissítések vagy hol van valami baj.

Ugyanúgy használom Linux szerverek (Ubuntu, Debian, SUSE, Orcle Linux) menedzselésére, ott a problémák egy része nem lép fel, de a Puppet szerverről kiadott parancsok futtatása (a klienseken) ott is hiányzik. Vagy csak nem találtam rá módot?

a puppet kicket tudtommal evek ota probaljak kiirtani:

# puppet kick
Warning: Puppet kick is deprecated. See http://links.puppetlabs.com/puppet-kick-deprecation
Warning: Failed to load ruby LDAP library. LDAP functionality will not be available
Finished

de mco-val, pssh-val, ansible-lel vagy barmivel tudsz egy 'puppet agent --test'-et nyomni, vagy ha van helyi checkout, akkor `puppet apply /path/to/site.pp`

Ezert en is eleg morcos vagyok, ha mar ott van a nyomorult puppet master, miert nem lehet kiforcoltatni a frissitest? Persze, belepkedhetek akar egyesevel is a gepekre, meg hasznalhatok tizenotfajta kulonbozo toolt, de maga az infra benne van a puppetben, miert akarnek en barmi mast hasznalni erre?
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant: 


()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

Nincs benne, mert mindig a kliens epiti ki a kapcsolatot, a puppetmaster nem kezdemenyez tranzakciot, tehat a puppet agent pull metodussal mukodik.
Az mar mas kerdes, hogy akar lehetne ilyen lehetoseg beepitve.
Mondjuk szerintem nem rossz, ha rendelkezesre all egy Mcollective telepites is a puppet melle, amivel aztan lehet a puppetrunt pocogtetni, meg meg millio mas dolgot csinalni.

Az infra alatt a feltetelekre gondoltam, a puppetmaster tobbe-kevesbe ismeri az osszes node-t, azok elerhetosegeit, le lehet gyujtetni a factokat, meg a jo eg tudja, mennyi infot tud a master, ennyibol mar csak ossze lehetne loni egy vissziranyu kommunikaciot.

Nezegettem ezt az MCollective cuccot, viccesnek tunik, de sajnos elesben meg nem tudtam kiprobalni.
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant: 


()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

( jupiter2005ster v | 2015. 01. 21., sze – 15:20 )

mi eppen Salt-ot vezetünk be. Jelenleg nem tudok nyilatkozni.

puppet-t es chef mar csak a hype miatt sem akartunk :)

a dokumentációja meggyőző és ez volt az első amit olvastunk. ha lesz olyat amit nem tudunk megoldani vele akkor lehet majd migrálunk.

bár kapásból tudok egyet.
nincs modul a kávé főzésre ;)
--
A legértékesebb idő a pillanat amelyben élsz.
https://sites.google.com/site/jupiter2005ster/

( kallo | 2015. 01. 21., sze – 15:21 )

Én még csak a salt-stack-et ismerem jobban, azért döntöttem mellette mert gyorsan üzembe lehet helyezni és pont arra jó amit írtál, hogy gyorsan pusholni tudd a dolgokat, azonnal lefut minden a kiadás pillanatába(ha elérhető a kliens)de azonnal kapsz értesítést arról is, hogy mi történt..
Sajnos nem tökéletes vannak apróbb hibái, de sztem vállalható.

( dap | 2015. 01. 21., sze – 15:28 )

Puppet, de nem ajánlom, én ilyen bugos szoftverrel korábban sose találkoztam. Greenfield projectnél a Chef-et nézném meg először. Sajnos nem csak implementációs, hanem tervezési problémák is vannak.

Mondjuk lehet hogy az a gond, hogy erősen szimpatizálok a Rails-szel, a DRY nagyon erősen él bennem. Ha nem zavar a redundancia akkor a problémák jó részét megkerülöd, mert legtöbb gond a rosszul kigondolt öröklés miatt van, de ugye nem kötelező örökölni.

~41k sornyi megírt .pp alapján alakult ki ez a véleményem.

( elod v | 2015. 01. 21., sze – 15:26 )

Puppet kezdő vagyok Windows-on.

Ami nálam felmerült:
- néha a jogosultságok kliens oldalon a fejük tetejére állnak, pontosan nem jöttem rá mitől van, azután is megtörtént hogy explicit beállítottam mi legyen
- néha beragad a processz és újraindításkor nem törlődik a lock file
- push-ot nem használom, félóránta fut, alapvetően jól megy
- push-ot tud, csak az mcollective kell hozzá mintha
- scheduled task-ok kezelése még nem az igazi

( Kayapo | 2015. 01. 21., sze – 21:01 )

- A saltstack nagyon friss, túl új, kevés (viszonylag) a use case.
- A puppet nagyon flexibilis sokat tud, nagyon könnyű rávenni bármire, ha magadévá teszed a szemléletét.
- A chef nem ekkora hálózatra van optimalizálva. Annak a pozitívumai lenginkáb a néhány száztól néhány ezer node -ból álló rendszereken mutatkozik meg.
- A cfengine2/3 szinte bármekkora hálózatban bevezethető ez az első (tudomásom szerint) ilyen célú alkalmazás. A tanulhatósága, viszont hagy némi kívánni valót maga után. A syntaxisa és a configurálás elve (főképp a 3 esetében) meglehetősen bakafántos

Mindent össze vetve nekem jelenleg a puppet előtte a cfengine2/3 a kedvencem.

Kávé főzéshez ezt a kiegészítőt javaslom: http://www.mrcoffee.com/coffeemakers/BVMC-PSTX91WE.html

----
올드보이
http://molnaristvan.eu/

( zsolt.k | 2015. 01. 21., sze – 21:35 )

Én próbáltam mindhármat, a SaltStack vált be legjobban:
- villámgyorsan üzembe helyezhető
- minimális tanulási fázis, átlátható config fájlok
- kevés erőforrást eszik

( Mico v | 2015. 01. 22., cs – 00:38 )

puppet - ahogy fentebb is írták, bugos. de egy idő után megszokod és nem tűnik fel.

a salt nagyon megtetszett, de az is néha ugyanolyan bugos. a filozófia zsír. kár, hogy kicsit is komolyabb konfignál, gépszámnál már olyan dolgokat kellett feltalálni, hogy utoljára akkor fájt annyira a fejem, amikor egy éjszakát rászántam a brainfuck-ra. ha egy kicsit még fejlődik, akkor ez javulni fog. a sebesség nem tudom, mitől javulna, mert nem is valami gyors. egyszer rászántam egy kis időt játszani, bekonfolja az RSA II-t, feltelepíti a bubuntut, berakja nagiosba, haproxy-ba, mókol az LSI kártyával, amennyit néztem, hogy csinálja, az alatt 100 szerver is elkészült volna, de megnyugtat a tudat, hogy ez mostanában így cool.

a cfengine-ről annyit tudok, hogy úgy döntöttünk, hogy elfelejtjük. :)

( bigpojnt v | 2015. 01. 22., cs – 06:04 )

Ha van idod sokat foglalkozni vele, cserebe sok gepes kornyezetben gyorsan futo konfigmenedzsmentet akarsz akkor cfengine.

Ha gyorsan akarsz latvanyos eredmenyt elerni akkor puppet.

Ha penzt is szeretnel raszanni, akkor chef.

Attol fugg, mi a cel. Szerintem az ingyenes feature-k is vannak olyan jok, hogy megerje hasznalni. Nehol sokkal okosabb, mint a Puppet, raadasul managelni is egyszerubb.
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant: 


()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

( onyx v | 2015. 01. 22., cs – 09:36 )

Nalunk Puppet, csak ajanlani tudom. Mondjuk erdemes elszakadni a tipikus package-file-service triotol es egy kis logikat tenni a manifestjeidbe. Ha ez megy, akkor szerintem nagyon jo.

( pirate | 2015. 01. 22., cs – 10:46 )

Esetleg ansible?

---
"Már nem csak tehetségekből, de a hülyékből is kifogytunk..."

( Herakleitos | 2015. 01. 22., cs – 13:26 )

ANSIBLE
Egyszerű.
SSH-n megy.
Nem kell neki a kezelt eszközön előre telepített szoftver.
Gyors.
Verziózható (git, mercurial, stb) a CM állomány.

"Csak a változás állandó." - Herakleitos

( egmont | 2015. 01. 22., cs – 14:34 )

Némi utánaolvasás után a Salt-ot választottuk. A többit nem tanulmányoztam (vö. http://xkcd.com/1445/).

Az jött le nekem a cikkek alapján, hogy a maga módján mindegyik szopás. (Ha valamelyik nem lenne az, azt használná mindenki.) A kérdés leginkább az, hogy a te esetedre melyik hátrányok a leginkább lenyelhetők, illetve megéri-e váltani.

A hibákat jobban észreveszi az ember, hülyeség lenne most leírnom hogy "megkértem valamire, és jé megcsinálta". Szóval szubjektív lista az engem idegesítő hibáiról:

- A hagyományos Unix filozófia, miszerint akkor dumálunk ha baj van, tökéletes pofonbaszása. Rengeteget rizsázik a sikerről is; többezer sor output-ot kell visszatekerned hogy kiderítsd, volt-e hiba. Sőt! Ha valamelyik klienst nem tudta elérni, arról semmit nem jelez! (Lehet hogy átkonfigurálható, de bakker, hadd ne kelljen ezzel foglalkoznom!)

- Sokszor nem talál rá egy kliensre. Ha sokáig nem csinálsz semmit, és megkéred valamire, van hogy csak a kliensek egy része hallgat, aztán újra megkéred, meg harmadszor is, akkor már mindenki.

- Közel azonos verzió kell kliens és szerver oldalon. Például az Ubuntu Trusty által szállított szerver és az Utopic által szállított kliens nem kompatibilis.

- TAB completion a kliensekhez fordul az elérhető kiegészítésekért, és baromi hosszú a timeout ha bármelyik nem elérhető, vagyis gyakorlatilag használhatatlan.

- Számomra totál káosz az egyszeri parancsok és a konfig fájlba írható dolgok közti összefüggés; hasonló, de nem teljesen ugyanaz az elérhető dolgok listája.

- A konfig fájl struktúrája szörnyű, például rendszeres hogy egy lista elemei egyelemű map-ek diszjunkt kulccsal - miért nem egyetlen többelemű map? Ezen felül is szerintem erőltetett, bonyolult - bár pont ennek az ellenkezőjét mondják sokan. A függőségeket, például konfig fájl változása vagy gitből frissítés esetén szerver újraindítása, elég nehéz megérteni és nehézkes megcsinálni.

- Az elérhető funkciókban sok hiányosságot találtam, olyan dolgokat nem tud amik számomra alapok lettek volna. Például patch-et alkalmazni csak akkor tud, ha megadom a kiindulási fájl md5-jét. De ha pontosan ismerem a kiindulási fájlt, akkor akár a teljes új verziót is letárolhatnám, szóval ennek semmi értelmét nem látom; annak lenne értelme hogy kissé eltérő fájlokra is megpróbálja alkalmazni.

- Amíg olyat akarsz csinálni, amire ők is gondoltak, addig elég nagy segítség. Ha bármi speciálisabbra van szükséged, akkor szenvedni fogsz, és visszasírod a kézi ssh-val szkriptezést :)

- Szűkszavú, nehezen érthető dokumentáció.

Puppet:
- erőforrásigényes, sokszor elkezdi enni a memóriát
- (számomra) undorító config fájlok, 1 hétig szenvedtem velük, Salt-nál 1 nap után készségszinten használtam
- van sok modul, de nekem eddig egyiket sem sikerült használni, mert: nem volt kompatibilis az OS-el, nem volt kompatibilis annak a szolgáltatásnak a legfrissebb verziójával amit kezelnie kellett volna, bele kellett volna nyúlni a modulba, mert pont olyan konfigurációs lehetőség nem volt, mint ami kellett volna. Elkapott az ideg, amikor már 6 órája próbálgattam egy adott dolog elvégzésére való modulokat.
- az agent-ek beállítása a Salt-hoz képest kínszenvedés, a salt minionok generálnak maguknak kulcsot, és bejelentkeznek a masterhez, Puppetnél (mikor használtam) ezt kézzel kellett megtenni
- a Puppet dokumentációja elég szűkszavú, sok dologra nem tér ki

Hozzáteszem a Salt-nak is megvannak az egmont által leírt hiányosságai, de alapvetően egy gyorsan tanulható, gyorsan üzembehelyezhető, szerethető eszköz.

Nah nem mintha vedeni akarnam a puppetet de azert jo lenne tisztazni par dolgot.

- Ez 2.x sorozatban igaz volt 3.5.x folott mar nem.

- Inkabb rubyhoz hasonlo konfigja valaki szereti valaki nem de az 1 het eleg tulzo.
- Nagyon egzotikus OS-t hasznalhatsz puppetlabs altal kiadot modulok Ubuntu/Centos/Redhat kompt. altalaban. Ja ,hogy programozni kellet volna egy kicsit? Azert ez nem a kategoria ,hogy googleozol es talalsz mindenre magadnak modulet.
- Puppet agentek is maguknak a kezdetek oda maguknak kulcsot az elso indulasnal.
- bullshit.

Itt alapvetoen szerintem nem a puppetel volt a gond hanem veled. Mert ezek nem a puppet hibai voltak hanem ,hogy nem erteted meg a mukodest hanem azt vartad ,hogy letoltesz valami es egybol mukodni fog.

--
"ssh in a for loop is not a solution" – Luke Kanies, Puppet developer

Na álljon meg a menet, tisztázzunk akkor tényleg pár dolgot:

1. az általam leírt dolgok a szubjektív véleményemet, tapasztalatomat tükrözik. A kérdező többek között erre volt kíváncsi.
Mellesleg nem mondtam, hogy bármelyik tökéletes, vagy jobb a másiknál. Alapvetően nem vagyok csőlátású, azt vallom, hogy a feladathoz/célhoz/projekthez kell eszközt választani. Van ahol a SaltStack, van ahol a Puppet, van ahol a cfengine, van ahol teljesen más a jó megoldás.

2. "Inkabb rubyhoz hasonlo konfigja valaki szereti valaki nem de az 1 het eleg tulzo."
Nem tudom, programozok Ruby-ban, de nekem a Puppet config fájljai a Salt-éhoz képest átláthatatlanok. Az 1 hét 1 hét volt, lehet másnak fele annyi, az is lehet, hogy másnak a Salt-é nem fog tetszeni. Ismétlem, csak, hogy megértsd: szubjektív vélemény, tapasztalat.

3. "Nagyon egzotikus OS-t hasznalhatsz puppetlabs altal kiadot modulok Ubuntu/Centos/Redhat kompt. altalaban."
Így van, csak a PuppetLabs nem gyárt a világ minden szoftveréhez modult. Sajnos vannak egzotikusabb dolgok is, amiket kénytelenek vagyunk használni, és nincs hozzá official modul.

4. "Ja ,hogy programozni kellet volna egy kicsit? Azert ez nem a kategoria ,hogy googleozol es talalsz mindenre magadnak modulet."
Ne haragudj, de nem hiszem, hogy ismerjük egymást, így nem tudom mire vélni ezt a megjegyzésed. Két cég vezető fejlesztőjeként programozok eleget (nem rendszergazda vagyok), mellesleg a vége az lett, hogy minden modult megírtunk magunknak.

5. "Puppet agentek is maguknak a kezdetek oda maguknak kulcsot az elso indulasnal."
Anno én mikor elkezdtem belemélyedni, az official guide úgy kezdte az adott részt, hogy "generáljunk kulcsot". Persze lehet rosszul emlékszem, ez benne van a pakliban.

6. "bullshit"
Szerintem ez itt egy szakmai fórum. Ha nem vagy képes kulturáltan vitatkozni egy témáról, akkor ne szólj hozzá. Ha igen, akkor támaszd alá érvekkel, és ha jogos, akkor meggyőzöl, vagy beszélgethetünk róla tovább.

"Itt alapvetoen szerintem nem a puppetel volt a gond hanem veled. Mert ezek nem a puppet hibai voltak hanem ,hogy nem erteted meg a mukodest hanem azt vartad ,hogy letoltesz valami es egybol mukodni fog."

Szerintem nem ismerjük egymást, így nem tudom milyen alapon írod ezt. Nem vártam semmi ilyesmit, egyrészt mint fentebb is részleteztem, a végén megírtuk mi magunk a szükséges modulokat tokkal, vonóval, másrészt pedig már ne haragudj, de ha fent volt a Puppet Forge-on a modul, akkor gondoltuk előbb megnézzük, mielőtt elkezdünk munkaórákat beleölni a saját modulok megírásába. Tudod vannak emberek akik ilyen munkahely nevű izében dolgoznak (majd próbáld ki egyszer, adnak pénzt a munkádért meg minden), és sajnos bizonyos külső tényezők behatárolják az erőforrásokat (menedzsment, ügyfél, stb).

ui.: bocs ha elragadtattam magam, de nem igazán bírom felfogni, hogy egyes emberek egy szakmai fórumon elkezdenek okoskodni/személyeskedni, nem képesek elfogadni, hogy nem csak az ő nézőpontjuk létezik, és képtelenek kulturált szakmai vitát folytatni. Ilyenkor én is felveszem az ő stílusukat.

Én nem igazán hiszek a 3rd party, előregyártott puppet modulokban. A saját modulok rövidebbek, egységes elvek mentén működnek, így egyszerűbb belenyúlni és karbantartani. Először persze sok kész modult kezdünk el használni, aztán ezek elkezdtek kikopni, mert gyakran több idő ment el rájuk mint megírni a nulláról. Ezt számomra összességében pozitívum: ennyire könnyű modult írni.

Én nem találkoztam a többi felsorolt hátránnyal se. Üzemeltetési szempontból jó a puppet, stabilan, megbízhatóan fut a gépeken, könnyű telepíteni és monitorozni.

Szerintem a puppet jó eszköz, az öröklést és a nyelv egyes elemeit leszámítva. A probléma állatorvosi lova a #5517. Nem ez az egyetlen probléma vele, de legszebb példája annak, hogy mennyire nem volt (jól) kitalálva amikor megalkották és ettől azóta sem szabadultak. És ez nem csak az én véleményem;

Status: Accepted
Priority: High
Added by Peter Meier about 4 years ago

( és nem, a Hiera nem váltja ki az öröklést. :)

Csak amihez en is hozza tudok vau.

5) Ez szerencsere eleg sokat valtozott: https://docs.puppetlabs.com/guides/install_puppet/post_install.html a node-k automatikusan generalnak maguknak kulcsot es beposztolnak egy CSR-t, neked a master oldalan csak egy darab paranccsal approve-olni kell, ami mellesleg general egy publik kulcsot a node-nak, majd a puppet agent ujboli futtatasaval automatan telepul is a cert.

6) Szerintem is nagyon regen nezted mar a puppet doksijat. A docs.puppetlabs.com -nal keves reszletesebb dokumentaciot olvastam, igazabol sok szoftverhez ennek a tizede sincs. Lehet, hogy regen keves doksi volt hozza, de ez ma mar egyaltalan nem igaz.
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant: 


()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

> Szerintem ez itt egy szakmai fórum. Ha nem vagy képes kulturáltan vitatkozni egy témáról, akkor ne szólj hozzá.

Szakmai forum es kulturaltam forumozott, total relevans volt a hozzaszolasa.
Mielott felhuzod az orrod egy szakmai forumon, gondold vegig, h lehet, megis veled van a prolema, pl. ez:

"Két cég vezető fejlesztőjeként programozok eleget (nem rendszergazda vagyok)"

Nem a te hibad, h nem rendszergazda vagy, de talan nem is a puppet-e:)

t
ui.: Egy nagyreszt elegedetlen puppet felhasznalo vagyok.

"Szakmai forum es kulturaltam forumozott, total relevans volt a hozzaszolasa."

Rendben, akkor idézek:

- "bullshit."
Ez nekem nem egy szakmai, érvekkel alátámasztott állítás.

- "Itt alapvetoen szerintem nem a puppetel volt a gond hanem veled. Mert ezek nem a puppet hibai voltak hanem ,hogy nem erteted meg a mukodest hanem azt vartad ,hogy letoltesz valami es egybol mukodni fog."
Ez eléggé személyeskedésnek tűnik. Nem hiszem, hogy kulturált viselkedés bárkiről ismeretlenül, és a helyzet ismerete nélkül egy publikus fórumon ilyesmit írni. És ez se tűnik se túl szakmainak, sem érvekkel alátámasztottnak.

- "Ja ,hogy programozni kellet volna egy kicsit? Azert ez nem a kategoria ,hogy googleozol es talalsz mindenre magadnak modulet."
Ez is eléggé személyeskedésnek tűnik, lásd előző az előző pontot.

"Mielott felhuzod az orrod egy szakmai forumon, gondold vegig, h lehet, megis veled van a prolema"
Nem húztam fel az orrom, de én a kérdező kérdésére feleltem, és nem álltam neki másokat ócsárolni.

"Nem a te hibad, h nem rendszergazda vagy, de talan nem is a puppet-e:)"
Az észrevételeim egy részét amiket leírtam a Puppet-el kapcsolatban, mások is megerősítették ebben a thread-ben. Tény, hogy amit leírtam, nem túl up-to-date, régebben foglalkoztam vele, azóta egy-két dolog változott.
Az, hogy vezető fejlesztő pozícióban dolgozok két cégnél, nem jelenti azt, hogy a tudásom lekorlátozódik erre, nem írtam le, de tudok például főzni, barkácsolni, és menedzseltem Puppet-el anno pár gépet, és jelenleg SaltStack-el egy 46 főt számláló gépparkot (Heartbeat, Pacemaker, Varnish, nginx, PHP-FPM, node.js, Java, Gearman, MariaDB Galera Cluster, memcached, Redis, ElasticSearch, Hadoop, Exim, Icinga, Logstash), de olyan cégek rendszereihez is közöm van, amit jó eséllyel az itt fórumozók ettek, vagy ittak már. Amúgy nem hibáztattam a Puppet-et, mint korábban is írtam, a saját szubjektív véleményeimet, tapasztalataimat írtam le, a kérdező erre volt kíváncsi. És mint írtam, a többinek is vannak hibái.

>>> - a Puppet dokumentációja elég szűkszavú, sok dologra nem tér ki
>> - "bullshit."
> Ez nekem nem egy szakmai, érvekkel alátámasztott állítás.

Vazold fel kerlek, h amit te irtal, az miert relevansabb:)

> Amúgy nem hibáztattam a Puppet-et

Nekem pedig ez jott le.

Kaptal egy eleg nyers, de korrekt es szerintem relevans valaszt az irasodra. Nincs ezzel semmi baj, nem kell tulcizellalni a dolgokat. Tovabba szerintem a hataron belul is maradt es amit irt, szemelyeskedes sem volt.
Ahogy szoktak mondani, just my 2 cents:)

t

( hrgy84 | 2015. 01. 23., p – 15:19 )

OFF: Je, azt hittem eltuntel...

ON: a puppet es a chef kozott vagyok feluton. Rettenetesen imadom a puppetet, bar a ruby nyelvu alaprogramozast csak nemregiben kezdtem el elsajatitani, a manifestekben azert meg igy is rengeteg mindent el lehet intezni. A chef ket dolog miatt tetszik igazabol: sokkal jobban van megcsinalva a kozponti node management, illetoleg a ruby szintaxis kozelebb all a szivemhez. De azert meg a puppet fele huzok.
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant: 


()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

A felsorolt pontok közül nekem több is oprendszerfüggetlennek tűnik;

> Ha hiba van akkor bizonytalan hogy melyik modulok futnak le és melyikek nem
Itt igazából arra gondolsz, hogy tranzakció alapú apply kéne, hogy a rendszer mindig egy működőképes állapotban maradjon? Szép lenne, de ezt szerintem egyik SCM se tudja jelenleg automatikusan. Ha nem erre gondolsz, akkor nem értem a problémát.

> Nem lehet olyat mondani, hogy egy telepítés max 1 órát fusson, ha nem sikerül akkor nyilván valami gond volt.
Linuxon cron-ból futtasd, ne agent-ként: 

timeout 1h puppet agent --no-daemonize --onetime

Így egy csomó RAM-ot is megspórolsz. A Windows-t nem ismerem, de gondolom ott is van ezen az elven megoldás.

> Nincs mód rá hogy a szerverről kinyomjunk egy frissítést vagy lefuttassunk parancsokat az összes vagy megadott gépeken
Erre más eszközök vannak, pl a distributed shell-ek. Azzal lehet triggerelni az instant frissítést is. Én nem vagyok meggyőződve arról, hogy ez az SCM dolga, annak a hiányossága lenne.
Kicsit olyan, mint számonkérni a http szerveren, hogy miért nem frissíti a brózeremben a lapot ha változott a tartalom a szerveren. Pull vs push ugye.

> Nem tudom (vagy nem tudom hogy tudhatom meg egyszerűen), hogy hol sikerültek a frissítések vagy hol van valami baj
https://docs.puppetlabs.com/guides/reporting.html

"Nincs mód rá hogy a szerverről kinyomjunk egy frissítést vagy lefuttassunk parancsokat az összes vagy megadott gépeken"
De erre van lehetoseg mcollectivenek hivjak linuxon megy windowson nem hasznalom. Csak alapbol a puppet nemtudja regen volt kick de az mar nem hasznalatos.

Amugy manageles szempontjabol erdemes lenne megismerkedned foremannal.

--
"ssh in a for loop is not a solution" – Luke Kanies, Puppet developer

Most egyelore hanyagolom a PuppetDB-t, ez a foreman viccesnek tunik, legalabbis elso latasra. Egy turhetoen kinezot talaltam itt, kiprobalni en se probaltam meg ki, de a leiras alapjan egesz jo.
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant: 


()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

Ahogy nezem, ez valami foreman-fork, legalabb a feluletet atbrandelhettek volna, de whatever. Mindenesetre en most zoldmezos beruhazast inditottam, szoval szinte barmi jo lehetne, de a foreman azert tetszik nagyon, mert GUI-bol tudom odakattintani a classokat, szinte nem is kell konfigolni rajta tul sok mindent. Ha kell majd valami "mezitlabas", akkor csinalok ra kulon modult, oszt' csokolom.
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant: 


()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

( mogorva v | 2016. 09. 27., k – 09:46 )

Sziasztok,

Így a topic nyitása után másfél évvel rákérdeznék, hogy mit ajánlanátok kombinált windows és linux konfig managementre?
Nincs szükség űrtechnikára, legyen inkább megbízható/átlátható és könnyen (akár pár nap alatt) bevezethető.

Köszi!

( sz332 v | 2016. 09. 27., k – 11:44 )

Sziasztok, akkor én is kérdeznék :)

Van egy rakás különböző szoftver komponensük, változatos nyelvben írva (java, cpp, python, php, stb.) Amire szükség lenne, hogy a fejlesztők (linux, win7/10, etc.)
egy parancs leütésével kapjanak egy virtuális gépet, ami futtat egy általuk megadott svn branchbeli kódot + konfigurációt. Hogy egy ilyen virtuális környezet 1 óra
alatt áll elő, az önmagában nem gond, a fejlesztés úgy szokott kinézni, hogy fogjuk a cpp szervert, összerakjuk, az elfut magában, és mi kódoljuk hozzá a klienseket.

Az első ötletem az volt, hogy mindent külön docker container-be rakok, de aztán belefutottam abba, hogy bizonyos komponensek általunk buildelendő kernel modulokat
használnak. Úgyhogy most van egy vagrant file-om, ami kb. így néz ki:


#Core files

config.vm.provision "shell", path: "core/increase_swap.sh"
config.vm.provision "shell", path: "core/packages.sh"
config.vm.provision "shell", path: "core/postgresql.sh"
config.vm.provision "shell", path: "core/java.sh"
config.vm.provision "shell", path: "core/maven.sh"
config.vm.provision "shell", path: "core/tomcat.sh"

#Server files

config.vm.provision "shell", path: "server/packages.sh"
config.vm.provision "shell", path: "server/wanpipe.sh"
config.vm.provision "shell", path: "server/ace.sh"
...
config.vm.provision "file", source: "server/production.cfg", destination: "/home/vagrant/production.cfg"
config.vm.provision "shell", path: "server/build.sh"

...

Ez így falura jó lesz, viszont nem tudom, nem-e lehetne ezt valahogy szebben megoldani, erre várnék ötleteket, tanácsokat. A használat kb. az, hogy minden fejlesztő kicheckolja az SVN-ből
a test könyvtárat, majd egy konzolt nyitva végrehajt egy vagrant up-ot, utána pedig elmegy ebédelni. Ebéd után ott lesz neki a szépen futó rendszer. :)

En ezt ugy oldom meg, hogy ansible-ben van egy playbookom (3 role: create route53_dns, create_security_zone, create_instances)
Ez felporget par szervert AWS-ben (a szerverek szama, feladata, stb. a playbook parameterektol fugg, es taggelem oket ennek megfeleloen project= env= serverrole= )
A kovetkezo playbook var amig a szerverek talpra allnak (kb 3-5 perc), aztan lefuttat egy common (apt-update, user-mgmt install xyz packages)
Idokozben a hatterben amig a fentiek mennek Jenkins mar epiti a csomagokat es ha keszen vannak felkuldi a binarisokat S3 bucketbe
Az installalo playbook lerantja a binarisokat, kicsomagolja oket a megfelelo szerverre, alkalmazza a J2 templateket (valtozok ansible-ben) a konfiguraciora es elinditja a szervert.
Az utolso playbook beallitja a front-end proxy Virt-hostjat az eppen felallt kornyezetre es reloadolja a proxy-t.

A fentiekket egy Jenkins Jobba fuzve - ha a fejlesztok keszitenek egy uj branchet a masterbol es a jenkins pipeline triggerelve van akkor 15 perc mulva a kornyezet elerheto a https://BRANCH-NAME.endomainem.com -on, teljes integracioval vagy stubokkal attol fugg hogy parameterezik a Jenkins Job-ot.

Na, akkor rögtön egy kérdés. A jenkins az hol fut, különálló szerveren? Ha pl. linux kernellel kell modult összeforgatni, akkor azt hogy oldanád meg? Mert ha jól értem, akkor a szerverek itt tényleg csak kb. containerek, tehát van bennük max egy tomcat, azt annyi, és a jenkinsről töltik lefele a binárisaikat.

Az AWS kuon VPC-k vannak:
Services: itt van jenkins, logstash, selenuim, jmeter - mittomenmegmi... (services na :) )
Playground: ide mindeki kedvere cimbalhatja fel a hostokat es a stackeket... (webstack, app, db stb...)
Developmet:
Performance: itt futtatja a jenkins a loadtesteket
preprod
prod

Ezekben a VPC-ben mind mind tobb kulonbozo "fuggeloeges" (FE,app,db,stb) kornyeztet kepzelj el sec-groupokkal elvalasztva. (PL prodban van egy Live-instaces taggolt stak kulon ELB-ben meg egy standby... Lehet mas is csak nincs ertelme...

A jenkins maga a master nem egy erogep, de van neki ugyanott a servicesben jopar slave-je akik epitenek latastol mikulasig es keszitik a csomagokat az ansible/jenkins kombonak...

A te esetedbe nem igazan tudom mit mondjak - nalunk java appok vannak amiket epitunk, mondjuk ha linux kernelt akarsz forgatni legyen egy olyan jenkins slave-ed ami kulon van tagelve es a kuloleges dolgokat azon epitsd... Teszteleni lehet tobb fele AMI (geptipus) template-ed amire a create_instance ansible playbook hivatkozik es eppen azt rantja be amelyik neked tetszik es abbol a template-bol epit neked 1-2-4-8 magos X gigas gepet... (tesztelni sztem eleg a micro is)... Mondjuk ameddig a konkret kovetelmenyeket nem tudom nem igazan tudok mit mondani - en csak leirtam en hogyan oldottam meg ezt (most ez volt a feladat)...

KB 2 - 3 het...

Nem olyan bonyolult mint elsore hangzik... A kulcs a jo tervezes :)

Csomag es binaris epites: Jenkins - eredmeny tarolva S3...

Playbook hogy epitsen egy VPC-t (sec groupok, route53, elb)
Playbook hogy felrants egy instancet (parameterzheto) {{ env }} {{ serverrole }} { egyebparameter }}
Playbook hogy installja a cuccot az S3-bol (parametterezheto - {{ Bin_version }}, {{ conf_version }}, {{ appname }}

ansible-ben ez nem tul bonyolult - az AWS-re tok jo moduljai vannak...

Mondjuk a fentiek nem teljesen fedik a valosagot... Maga a playbookok megirasa valoban 2-3 het volt, de a teljes kialakitas, monitoring, infrastruktura tervezes, configuracio templatezes, standardizalas, teszteles egy rakat trial-and-error, integralas, 3rd party kapcsolatok kialakitasa, stb. korulbelul 6 honapnyi munka 2 embernek. Ha megvan a terv, megvan egy jo build process, a fentiek akkor maga a megvalositas kb 2-3 het volt...

+1 Puppetrol valtottunk sokkal egyszerubb, gyorsabb es attekinthetobb. Jenkins jobokbol hivogatom a playbookokat a klikkelos fejlesztoknek, minden git repobol jon, a templatezes j2 (jinja2 ) hasznal... Gyors, egyszeru, kulon modulja az AWS dinamikus inventory, route53, sec-group stb... Teszi a dolgat

( mogorva v | 2016. 09. 29., cs – 15:05 )

Teljesen szakmai alapon (melyik weblap design-ja tetszik jobban) úgy döntöttem, Ansible-lel indulunk.

Megnéztem pár videót, elolvastam ezt-azt, de egyelőre nem világos, hogy milyen user nevében kellene ügyködnie a remote gépen.
Kényelem szempontjából nyilván a root (Administrator) lenne a legjobb, de nem tartom túl jó ötletnek.
Van erre valami best practice?

Become (Privilege Escalation)

Security szempontbol erosen javasolt, hogy a root userrel ne tudj besshzni egy szerverre, ezert celszeru nevesitett user(eke)t es/vagy management user(eke)t letrehozni es ezeknek a userek szamara biztositani a megfelelo szintu adminisztratori szintu jogokat sudoval.

Az Ansible kezdetben csak Linux/Unix rendszerek menedzselesere volt alkalmas es azt is csak SSH-n keresztul, ezert ott a su es a sudo tokeletesen eleg volt, de 1.7-tol mar megjelent a Windows rendszerek tamogatasanak csiraja, amit WinRM-en keresztul valositanak meg, illetve itt mar nem mukodik a su, sudoval valo jogosultsag megszerzesenek a lehetoseg.

Ennek a problemanak a megoldasara jott letre a become, amelyben a korabbi su es sudo mar csak egy jogosultsagi modszer.

Az Ansiblet en dedikalt management gep(ek)en futtatom, management userrel, amely SSH-n keresztul, kulccsal kapcsolodik a menedzselni kivant gephez, szinten egy management userrel, amelynek az adott sudoers fajlban engedelyezem, hogy sudo jelszo nelkul tudjon a root user neveben tevekenykedni.

Termeszetesen - paranoia szinttol fuggoen - lehet szabalyozni, hogy a menedzsement user az egyes feladatokat milyen linux vagy sudo userrel/csoporttal tudja ellatni.

úgy, hogy ha le tudod kapcsolni a root-tal való direkt logint, akkor az ismert usernévvel próbálkozó biztosabban nem jut be, mintha lenne elméleti esélye, hogy mondjuk megtörik a kulcsot, vagy a root jelszavát. (ráadásul viszonylag egyszerűen lehet mondjuk fail2banolni)

Nem nagy ügy ez egyébként inkább csak junk control.

Igen, mindent.

echo "mgmtusr ALL=(ALL) NOPASSWD: ALL" > /etc/sudoers.d/mgmtusr

Ahogy irtam, termeszetesen lehet tovabb fokozni a jogosultsagok szabalyozasat,
illetve lehet sudo passwordot is megadni, ha szeretned.

Noveli a biztonsag erzetet:
- Ha az SSH hozzaferesek szamat lecsokkented (csak limitalt gepekrol lehet hozzafereni az adott szerverhez).
- Ha csak megadott accountokkal lehet csatlakozni.
- Ha az engedelyezett accountok csak SSH kulccsal tudnak kapcsolodni.
- Ha a hozzaferesek kozpontilag loggolva vannak.

Kitol vagy mitol szeretned jobban megvedeni magad?

> tovabb fokozni

Errol beszelek, hogy bar ez a bevett modszer, valojaban senki nem fokozott itt meg semmit.

> - Ha csak megadott accountokkal lehet csatlakozni.

Ez konkretan mi? Amugy nemcsak megadott accountokkal lehet?;)

> Kitol vagy mitol szeretned jobban megvedeni magad?

Egyelore ott tartunk, hogy a fentivel a direkt root loginhoz kepest elobbre van-e a user.
Ugy alapbol szerintem nem, fuggetlenul attol, hogy ez a bevalt eljaras.

> tovabb fokozni
Minden attol fugg, hogy mire szeretned hasznalni az Ansiblet.

Mivel az Ansible konfiguracio menedzsment es ad-hoc feladatok vegrehajtasat vegzo tool,
ezert az eredeti alapkerdesedet, hogy mit, milyen userrel kell vegrehajtani nem az Ansible fogja megoldani.

Az Ansible abban fog Teged tamogatni, hogy az altalad elore megalmodott es implementalt sudo jogosultsagokat
kepes leszel hasznalni az Ansible playbookjaidban.

Amennyiben a sudo jogosultsagok/szabalyok letrehozasat is Ansible segitsegevel szeretned elvegezni, akkor
meg kell nezni, hogy mi az a minimalis jogosultsag keszlet, illetve beallitas, ami ahhoz kell, hogy ezt
vegre tud hajtani.

Egy szerver szuletesenek/telepitesenek pillanata alkalmas arra, hogy megteremtsuk a lehetoseget annak, hogy
kozponti menedzsment (kozponti yum tarolobol telepiteni, kozponti logszerverbe logoljon, kozponti monitorozasba keruljon)
ala lehessen vonni.

> - Ha csak megadott accountokkal lehet csatlakozni.
Bocs, itt nem jol fejeztem ki magam, illetve ez az elotte levo ponthoz kapcsolodott szorosan.
Ha peldaul SFTP-t szolgaltatsz, akkor kell adnod hozzaferest az SSHhoz, de nem szukseges teljes erteku SHELL-t adnod (/sbin/nologin vagy valami korlatozott SHELL ha pl.: sftp es scp-t szolgaltatsz).

Ezek alapjan az adminisztrator/menedzsment accountokat IP alapjan, vagy csoport tagsag alapjan is kulon tudod kezelni az sshd konfigjaban.

> Egyelore ott tartunk, hogy a fentivel a direkt root loginhoz kepest elobbre van-e a user.
Mindenkeppen, mert alapvetoen nem szukseges hogy rootkent kozlekedjen ki-be a rendszerben.
A root szintu jogokat akkor vesszuk elo, amikor szukseges.
Az adott feladat elvegzesehez szukseges minimalis jogosultsag donti el, hogy milyen feladatot milyen userrel,
vagy annak a usernek a jogosultsagi szintjevel megegyezo jogkorrel vegezzuk el. Illetve van olyan, hogy nem
eleg maga a jogosultsag szintje, szukseg van meg kornyezeti beallitasok egyezosegere is.

Egyszerusitem es atfogalmazom a problmeat. Az, hogy root user nem lephet be a szerverre, elsosorban nem a biztonsag noveleseert van, hanem az auditalhatosag noveleseert. Maskepp fogalmazva, lehet, hogy az adminoknak amugy full-access no-password joguk van a sudoban, de a belepesuk teljesen perszonalizaltan van logolva, emiatt ha valahol karosodas eri a rendszert, visszakovethetove valik, hogy a megadott idointervallumban ki es mikor lepett be a rendszerbe, emiatt a felelos megtalalasa biztosabban megtortenik. (Nyilvan ennek ki nem mondott feltetele az, hogy az audit logok replikalva legyenek egy fuggetlen tarolorendszerben is)

Ennek egy mellekhatasa, benefitje, hogy amugy az internetrol erkezo tamadasokat is nagyban csokkenti az a teny, hogy a root account AMUGY nem hozzaferheto egyszeru loginnel, mert mar egy sokkal korabbi ponton elszall az egesz a francba.

Egyetlen esetben tartom indokoltnak a root hozzaferes (kizarolag kulcs alapu) engedelyezeset: ha rsync alapu push menteseket vegzunk (rsnapshot, rdiff-backup, duplicity, you name it), de itt megfontolas targyava kell tenni, hogy ez esetben ez egy alternativ porton futo, erre dedikalt SSH szerverre tortenjen.
--
Blog | @hron84
Üzemeltető macik