3rd party configuration management software vs. saját megoldások

UNIX, UNIX-szerű

3rd party configuration management software (Salt, Puppet, Chef és társaik).
41% (83 szavazat)
Saját fejlesztésű megoldások (pl. shell script, powershell script, alkalmazás).
20% (40 szavazat)
Csak a végeredmény érdekel, nem tudom eldönteni, megvan a véleményem de mást kell használnom, egyéb és leírom stb.
39% (78 szavazat)
Összes szavazat: 201

( chx | 2016. 10. 13., cs – 11:27 )

Tényleg érdekelne hogy ki mit használ, és miért. 3rd party-nál ugyanúgy ki kell alakítani a környezetet, plusz fixelni a bugokat. Én a sajátot preferálom, a cég nem és hát vannak hátrányai a 3rd party-nak (innen a szavazás). Egyszerűen nem látom hogy egy shell scriptingben jártas, a saját környezetét jól ismerő sysadmin staff minek használna 3rd party cuccokat, amikor házon belül is meg lehet oldani mindent.

Köszönöm ha megosztod a véleményed.

____________________
echo crash > /dev/kmem

Azért mert ha kirúgnak téged akkor az új embernek ne a te bugos kódjaidat kelljen túrnia.
Legalábbis fejlesztőknél ezért preferálják a kész middlewareket. Minden középvezető rémálma amikor a programozó odajön hozzá és azt mondja, hogy ő majd lekódolja vason.

--
GPLv3-as hozzászólás.

el kell donteni: ti most egy olyan ceg vagytok, aki config management software-t akar gyartani, karbantartani es fejlesztgetni? Vagy olyan ceg vagytok akik probalnak rendszert uzemeltetni? Mibol van a beveteletek, es mire mennyit akartok kolteni?

Valamint: tegyuk fel nem elerheto a szoftver iroja. Felvesztek egy kollegat, akinek meg kell oldania valamit a custom solutionnal. Jon egy cryptic hibauzenet, mit csinalsz? Nem lehet rakeresni a google-ban 1 mp alatt, hogy mi a helyzet, ki kell debuggolni azt a scriptet, amit egy nem szoftverfejleszto ember irt.

Alig hinném, hogy egy ilyen kérdésre általános válasz adható.
Nagyban függ a válasz attól, hogy hány darab, hány féle, milyen jellegű eszközt menedzselünk milyen felhasználásra.
Például simán el tudom képzelni, hogy adott esetben az optimális válasz akár ez is lehet:
-30 db eszköz: egyedi
-3000 db eszköz: gyártói
-300000 db eszköz: egyedi

Üdv,
Marci

Valószínűleg itt van a kutya elásva. Erősen homogén Linux alkalmazásfarm, nx100-as nagyságrendben, saját repo-k, saját LDAP user mgmt stb. Annyira egyforma minden hogy beütött a kérdés, minek ide 3rd party. Ha heterogénebb a környezet, lehet hogy fel sem merül bennem ez a kérdés.

Köszönöm mindenki véleményét és szavazatát.

____________________
echo crash > /dev/kmem

amikor egy eszkozt valasztasz, gyakorlatilag a problemahalmazodat valasztod ki. van amiben a Puppet jobb mint a Chef, de az Ansible ugyanabban rosszabb mint a Salt es biztos, hogy a sajatod jobb lesz valamiben es sokkal rosszabb masban, mint a tobbiek. ha letezne egy tokeletes megoldas, mar mindenki azt hasznalna. szerintem nem terul meg sajatba energiat fektetni, csak ha nem foglalkozol massal.
egy ceg szempontjabol gyakorlati haszon es hatalmas megtakaritas, ha azt kerdezheti az interjun, hogy lattal-e mar Puppet modult es nem kell fel evi beredet kidobni az ablakon, mert nem ismered a helyi uberkusztom eszkoz minden nyugjet.

Tudnék mesélni az ellenkezőjéről.
Nem mondom, hogy mindenhova az az ideális, ha fejleszt magának a cég custom megoldást.
De bizonyos cégméret fölött, már az is lehet, hogy megtérül a befektetés.
Hallottam már cégtől eltávozott kollégáktól, hogy hiányoltak itt jól megszokott belső eszközöket.
(Meg persze egy két olyan belső eszközünkről is hallottam véleményt, amit meg ugyanaz a kolléga nem hiányolt. De ez persze ugye, belső projektek kiforrottságán, életútján is múlik, hogy mennyire kedvelt.)

Szóval, van az a cégméret... (kb. enterprise fölött ? ;) ) ahol megéri befektetni belső custom megoldások fejlesztésébe, és ez nem rossz döntés.

Persze az is lehet, hogy elhamarkodottan itélek, még 4 hónapja sincs, hogy itt vagyok! ;)

Na igen, de van, hogyazt a tool-t ami mindennel jobb, de tenyleg tobb mint 10 evig csiszoltak. Addig meg hasznaltak a sztenderd megoldasokat. :D
En is lattam mar a szelesen elterjedt megoldasoknal jobb belso megoldaskent fejlesztett eszkozoket. Jobbak voltak, de tenyleg. Csak kellett 8-12 ev mire eljuotttak ide.
Szoval ha van ilyen megoldas az jo, de van, hogy meg nem eleg jo es ilyenkor bozony jol jonnek az altalanos eszkozok, akiket mindenki ismer.
Masreszt nehez eladni, hogy en negy evig dolgoztam a PQDT23 rendszerrel. Mig azt, hogy egy evig puppet/ansible/akarmi-vel foglalkoztam kicsit jobban hangzik a munkaero piacon. :D

-1024
Akkor a software-fejlesztési profilú cégek gépparkjai futtassanak saját készítésu" OS-eket? :) Az autódat sem készen vennéd, ha gépészmérnök lennél esetleg? Szerintem amivel dolgozol, azt támogassa más, mert Te erre nem érsz rá - etto"l még Te is _kísérletezhetsz_ ilyesmivel, csak azon leheto"leg ne múljon semmi. De hogy válaszoljak is: Chef-et használok. Otthon is. És persze bo"vítettem rajta sk. is, mert szükségét láttam és leheto"vé teszik. :)
------------------------
{0} ok boto
boto ?

Azert mert egy-egy ilyen toolnal valoszinuleg a fejlesztok mar sokkal tobb mindenre gondoltak mint ami neked eszedbe jut es a felhasznaloi bazis miatt jobban is dukumentalt lesz.

Ahogy mar tobben irtak egyszerubb a szemelycsere (ami nem ordogtol valo gondolkodas, nem csak arra kell gondolni, hogy igy konyebben kirughato vagy, de magadtol is felmondhatsz, lebetegedhetsz stb). Marpedig ha uj kellega jon (akar melled akar helyetted) akkor nem mindegy, hogy azt kell neki mondani, hogy itt van ez a rendszer amit X-cuccal managelunk (amit vagy mar eleve ismer mert ugy lett felveve, vagy jol dukumentalt a weben, kismillio forum hozzaszolassal) vagy itt van ez a rendszer amit ezzel a hazi cuccal managelunk eloszor ebbe asd bele magad. A hely viszonyokat felterkepezni, abban othonosan mozogni akkor is sok ido ha minden jol dokumentalt es nincsenek hazi cuccok benne. Ezta bettanulast nagyon megneheziti ha ugy kell nekiallni a munkanak hogy egy hazi fejlesztesu (valoszinuleg gyengen dokumentalt) szoftvert kell elsajatitani eloszor.

Szerintem altalanossagban 3rd party-kat kell hasznalni, es inkabb ezeken belul fejleszteni (ugye hiaba van meg a tool, nyilvan meg csillio scriptet hozza kell tenni), esetleg boviteni ha kell (lugin, patch bekuldes), illetve azon dolgozni, hogy a kulonbozo 3rd party cuccok jol mukodjenek egymassal (utobbi esetben nem conf. managementrol beszelek).

Hatalmas +1.

Amikor a mostani munkahelyemre kerultem egy DevOps csoport 3. tagjakent, ismerkedtem meg az Ansible rejtelmeivel. Probaido alatt mindket senior kollega felmondott, mit ne mondjak, nem ismertem ki a teljes rendszert 2 honap alatt, de sikerult az utanam felvettekkel egyutt atvenni, mivel a config management egy ismert, jol dokumentalt eszkozzel volt megoldva. Bele sem merek gondolni, mi lett volna, ha valami hazi ganyolast kellett volna senior staff nelkul egyben tartanom...

--
"It all keeps adding up / I think I'm cracking up / Am I just paranoid? / I'm just stoned"
/Green Day - Basket Case/

( mrceeka v | 2016. 10. 13., cs – 19:17 )

Scriptelés szerintem mindenféle gyártói megoldáshoz kell.

Üdv,
Marci

( golgota | 2016. 10. 14., p – 08:40 )

En az Infrastructure as a Code-ra szavazok, az meg nem scripteles. Bar igen, van hogy belefut az ember bug-okba, vagy hogy a szoftver nem rendelkezik egy adott funkcioval. De altalaban mindegyiket lehet workaround-olni. Napokig meg sosem fejtettem vissza kodot, mivel csak nyiltforrasuakat hasznalunk es max egy ora alatt megtalalja az ember, hogy mi a baj. Utana vagy kijavitjuk es commit-oljuk, vagy a fejlesztoket kerjuk meg. Eddig ez meg tokeletesen mukodott mindenhol (kiveve TerraForm, ahol masfel eves bugok vannak meg visszaeso regressziok es szarnak bele :D)

En a sajat laptopomon is Ansible-t hasznalok, hogy beallitsam a rendszert egy ujratelepiets utan. A HOME-m marad, ott van venne a playbook, az ansible install utan mar mehet is a play es visszakapom a rendszeremet.
De ez arra is jo, ha mondjuk sajat specialis beallitasaim vannak. Mondjuk a HOME-om alatt van a docker es a libvirt base. Egy systemd update meg mindig kinyirja a beallitasokat, mert nem hasznlaja a DOCKEROPTS-ot. Persze minden egyes alkalommal foghatnam es megszerkeszthetnem, vagy irhatnek egy sed-es scriptet, de minek, ha az Ansible megcsinalja, ha en egyszer(!!!) megcsinaltam.

( htmm v | 2016. 10. 14., p – 10:29 )

* 3rd party configuration management software

Egeszen konkretan Ansible. Eddig ugy nez ki, minel tobbet hasznaljuk annal jobban szeretjuk. (Ha ez szamit: nehany szaz szerver van managelve vele.)

--
http://blog.htmm.hu/

( uid_194 | 2016. 10. 14., p – 10:39 )

Volt, hogy sajat fejlesztesu config managementet hasznaltam. Soha tobbet. Fos mind, ami a piacon van, de legalabb guglizhato fos, amit tobbnyire nem nekem kell lapatolni.

--
|8]

( mogorva v | 2016. 10. 14., p – 16:32 )

Előző helyen, amikor még lelkes voltam és fiatal, írtam sajátot. Egész jó volt, az új és utód kollégák még tovább is tudták fejleszteni.
Itt, az új helyen viszont semmi ingert nem éreztem arra, hogy írjak sajátot, ezért kerestem 3rdparty-t és találtam ansible-t.

A szavazat ment a 3rdparty-ra.

( hory v | 2016. 10. 14., p – 21:25 )

Ansible nagyon nepszeru, de amikor egy sima cp/mv 5 sor (es meg 5, ha hibat/stdout-ot akarsz kezelni), es minden aprosaghoz doksit kell turni, mert minden command kicsit masmilyen, akkor en is inkabb egy sima shell scriptet javasoltam, otodannyi LoC-vel.

Ansible spec nem gyozott meg, persze lehet ertelme, de csak akkor, ha egy-egy task komolyabb, mint mv, uncompress, ...

A script-gyujtemennyel tenyleg hatalmas baj, hogy uj dolgozo/tobbi rendszergazdanak kulon kell tanulnia.

( KissT | 2016. 10. 15., szo – 10:21 )

Nem is értem hogy ez miért kérdés, lehet azért mert az elmúlt 5-6 évben egyetlen bugba sem futottam bele, nekem eszembe se jutna hogy ne configuration management tools-al essek neki egy hálózatnak.
Még a laptopom is puppetel futt...

( Sea-you | 2016. 10. 15., szo – 14:02 )

Immutable infra, minden mas kontenerben fut. Az imagehez meg Packer + Ansible.

( o_O v | 2016. 10. 18., k – 13:20 )

Nincs ra szuksegunk jelenleg, inframanagment: terraform, AWS + CoreOS + Kubernetes + Docker.
--
"ssh in a for loop is not a solution" – Luke Kanies, Puppet developer

Az a TerraForm ami olyan bugos, mint egy hangyaboly? Az amelyikben a tobb mint egy eves hibakat nem javitjak, mert hogy inkabb a featurok utan mennek? Mi is hasznaljuk, de fokozatosan terunk vissza Ansible-re, mert az stabilan mukodik. Ahanyszor mi belefutottunk, hogy az apply megy, de aztan nem tudja destroy-olni.
Szogezzuk le, hogy nem tud tobbet, mint egy CloudFormation viszont sokkal ganyabb az egesz. Azt ne is emlitsuk, hogy nincs benne decision (if vagy when, mint az Ansible-be), nem tud provisionolni, csak meghivni esetleg provision eszkozoket, na de abban sncs koszonet, a local-exec es remote-exec meg egy vicc kategoria. Ahhoz hogy 100%-ban menjen a detsroy vagy egy egesz szezetesrendnek kell imatkoznia, vagy egy vonaglo szuzlanyt kell kakas verevel locsolni. Es meg ilyenkor is kell egy asztrologus, hogy vajon hogyan allnak a csillagok.
Meg csak szovtvernek sem neveznem, nemhogy enterprise solution-nek, amivel reklamozzak magukat. :D

Persze jatszani jo. Mi ezen mutatjuk meg az uj embereknek, hogy hogyan nem kell provision eszkozt irni. Az elrettento pelda.

Persze lehet hogy egyszer majd sok ev mulva kiforrja magat. :D (de akkor ne enterprise solution-ozzenek nekem)

Mivel egyetlen szoftver sem tokeletes, igy a Terraform sem, de mint mindent ezt is lehet szarul hasznalni. Ha nem irod meg jol a kodot (ami egyebkent nem nehez at all) akkor lehet, hogy nem tudod majd destroyolni. Az elejen en is futottam bele hasonlokba, de mar nincs ilyen, mert kijavitottam a kodot. Kivancsi lennek a peldatokra, mert sztem ott valami masrol van szo (pl arrol, h az AWS API inkonzisztens par esetben).

A CFhez kepest vannak viszont vitathatatlan elonyei, csak, hogy parat emlitsek:

- nem JSON, olvashato, konnyen ertheto kod
- Egy kodbol tudom managelni a CloudFlare DNSt, StatusCake-et es az AWS resourceaimat, stb.
- Interpolation, data sources
- Modulok (bar ezeket ha nem muszaj nem hasznalom)
- Azok a feature-ok amik szamottevo erdeklodesre tartanak szamot sokszor hamarabb tudja mint a CF (peldaul jelenleg CFbol nem tudsz 2.3as ElasticSearchot csinalni, TFbol meg igen)
- Pontosan latom mi fog valtozni es hogyan.

Ehhez kepest futottam olyanba CFfel amikor az Amazon support azt mondta miutan failed statuszban ragadt a stackem, h csinaljam ujra. Meg jo hogy nem production stack volt, de nem keves felesleges plusz munka

An Ansible fasza, szeretem en is, es hasznaltam AWShez is, de a TF jobb ebben, legutobb amikor probalgattam, jo par dolgot nem ismert. Meg annyit megemlitenek, hogy pl a fent szereplo ElasticSearchhoz nincs hivatalos modul, csak egy user altal irt (hirtelen ezt talaltam https://github.com/fiunchinho/ansible-aws-elasticsearch-module), amihez nincsen semmifele test-case hozzaadva, u h nehezen biznam ra barmilyen production rendszeremet.

A count ami a modul eseten destroy-kor nem ertekelodik ki (7.0 sorozat regression): https://github.com/hashicorp/terraform/issues/8146, https://github.com/hashicorp/terraform/pull/9021, https://github.com/hashicorp/terraform/issues/8098, https://github.com/hashicorp/terraform/issues/8448

Igy peldaul megcseszheti az ember azt, ha IF-elni szeretne mondjuk module_enabled-del (0|1), hogy ne kelljen valamit ketszer leirni. :D

Nagyon meg van oldva. :D

a POC ra:
http://pastebin.com/VbdRX51A

Bar mondjuk ahogy irtad az en kodom szar, meg azoknak akik bejelentettek. Bar furcsa, hogy akkor miert is foglalkozik vele (illetve nem) a Hashicorp. :D

Lehet nagyon szar a kodom, de ha ismert bug-ba futok bele akkor ne a kodomat hibaztassuk ugye. Khmm...
Mereszen ki volt jelentve, hogy csak akkor utkozhetek barmi bajba, ha a kodom szar. :D
Ez az elkepzeles annira meresz es feltetelezi, hogy a TerraFrom bugfree, amitol olyan messze van, mint a fenti pelda is mutatja, mint en attol, hogy 4 eves kislanynak nezzenek. :D

A vegen meg odaveted, hogy megis csak en vagyok a hulye, mert modulokat hasznalok. Szep. Ahhoz kepest, hogy "az ilyenek miatt igyekszem nem hasznalni modulokat" a fenti problema nem volt ismert elotted, hiszen megmagyaraztad, hogy az en kodom a szar.

Egy csipetnyi szakmai alazat nem artana, mielott leszoljuk a masik munkajat. Vagy utanajaras mielott nagyokat mondunk. De hagyjuk is.

Nem irtam, h bugmentes, vannak bugok. Annyit irtam, h a legtobb esetben maga a kod okozza a problemakat. Nem akartam leszolni a munkadat, ha igy erezted elnezest kerek.

Isemerem a modulokkal kapcsolatos problemakat, ezert igyekszem nem hasznalni oket.

Peace!

ps: kicsit hianyolom ezt a vonalat a HUProl, jo lenne ezekrol beszelgetni magyarul is vegre.

Miert lenne barmi duplan, vagy inkabb ugy kerdezem miert lenne a prod meg a staging vagy akar a dev kod mas ?
Minel kozelebbi a dev stack az eles rendszerhez annal kisebb a hibalehetoseg, nalam ez pl ~0.

Ugyanakkor a gyakori dolgok ami kisebb mint egy stack, azokat cpp templatekent generalom, pl tags, parameters, vagy amitol rusnya a kod pl lunchconfig init script etc. ezek mennek egy include mappaba aztan a kodban meg #include standard_tags etc etc

Ha TerraForm bugos akkor CF is ugyan is a CF-t lehetetlen debugolni kb. ha elkurtal valamit akkor add egy kb. random hibauzenetet amibol vagy megfejted mi a baj vagy nem. Plusz a terraformot ugyan mint a kodjainkat tudjuk tesztelni ( https://github.com/newcontext/kitchen-terraform ) Infrastructure as Code elvek szerint. Plusz CI-ba futtatjuk remote backenddel tobben is tudjak mar hasznalni es ne taroljuk a state fileokat git-be.

Nem hasznalunk se local-exec es remote-exec minek?!

Van autoscaling group ahhoz hozza van rendelve egy megfelelo user-data aztan cso a gep elindul minden magarahuz amire szuksege van es mar ott is van a clusterbe.

Mi modulositva hasznaljuk a TF-t normalisan scoupolunk ami lehet az templatebe van es le kezeljuk a dependency dolgokat ahol kell igy ilyen destroy problema nincsen amit emlitettel.

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

En nem mondtam ,hogy nincs hiba :D nyugi en is eleg sokba belefutok csak amivel Te talalkoztal nekem nem jott elo ennyi. De AWS security groupnal nem birja lekezelni az egymasra hivatkozast azt meg mindig nem birtka kijavitani pedig tok jo lenne.
--
"ssh in a for loop is not a solution" – Luke Kanies, Puppet developer