remote management tool

Linux-haladó

Hi,

Keresek valami tool-t (lehetőleg parancssorosat, de ha nem az, akkor sincs gáz), amivel több 100 szervert lehet távolról piszkálni.
Nem konfig managementre kell, hanem inkább olyasmire, hogy ad-hoc gyűjtsük össze 725 szerverről a /foo/bar.txt 5. sorát.
Vagy tudjuk csekkolni, hogy másik 321 szerveren a /foo2/bar2.csv létezik-e (és pl. egy OK/NOK válasz elég lenne).
Vagy amivel lehet komplex-ebb parancsokat (kisebb scriptek) is kiküldeni a managelt szerverekre.

Ehhez nekem még talán az Ansible áll a legközelebb, de az sem igazán erre való.

Elkezdhetnénk építeni valami saját tool-t, ami idővel már elég kiforrott lesz, de ha van vmi közismert eszköz, akkor nekem az is jó.

Köszi!

---
Szerk: az ssh-s remote parancs futtatás security okokól meg van gátolva (mindegy, miért és hogyan).

  • 4980 megtekintés

( zeller | 2017. 08. 04., p – 08:32 )

Ekkora darabszámot nem, de néhány tucatot cssh-val (illetve arra épülő Perl-ben elkövetett motyóval) kezeltem már. (App::ClusterSSH)

A cssh szerintem nem lesz neki jó, én is az Ansible/Chef vonalon indulnék el. Ez amit leírt a topic indító, tipikusan az ad-hoc management területe. Különben lehet érdemes lenne még ezt átgondolni, mert nem igazán látszik egy körvonalazott feladatkör (csak kb annyi, hogy a management, "furcsa" ötleteinek kellene megfelelni)

Még így a Landscape jut az eszembe.

----
올드보이

Nyilván az lenne a legjobb, ha minden chef-fel lenne managelve és egyszerűen nem lehetnének eltérések, mert a chef client T időnként magára force-olná a jó konfigot.
De ez most nem így van. :)

A feladatkör szerintem tök jól körvonalazott: ne kézzel kelljen sok szerveren ugyanazt a feladatot végrehajtani.

Félre értettél!

A "normál" central config managementet én Cfengine -el, vagy pupettel csinálnám, a "gyüjtsúk le az összes szerverről, hogy hány óra hány percre van beidőzítve a /etc/crontab -ban, a csuda.ssh futtatása és ahol 9:30 és 10:30 közé van időzítva, ott a /var/lib/csuda.dat filet másoljuk át, a csuda serverre", na ezt meg Ansible -el

----
올드보이

Az Ansible nem a legalkalmasabb a config managementre (template -ből generálás illetve az adatmodel + adattartalom típusú config generálás, vagy tevékenység végrehajtás nem épp az erőssége), azt jobb a Puppet, vagy a Cfengine segítségével végezni. Az ad-hoc tevékenységek elvégzése Puppet -el, vagy pláne Cfengine -el sokkal komplikáltabb, mint Ansible -el.

----
올드보이

( tbs v | 2017. 08. 04., p – 09:37 )

adhoc..? parallel-ssh

szerk.: Aha, ssh remote denied... Akkor mindenkepp "okos" toolszet iranyba kell menned... :(

( kallo | 2017. 08. 04., p – 09:24 )

Mi az amire nem jó az ansible?
Mindenféle paralel ssh helyett: ansible -
m shell - a "ls - l /"

( dragi v | 2017. 08. 04., p – 09:36 )

Ha az ssh-s remote nem engedélyezett, akkor se ansible se parallel ssh nem fog működni nem?

( zeller | 2017. 08. 04., p – 10:35 )

A no ssh kellően megnehezíti a dolgokat (a biztonság a használhatatlanságig fokozható...) - pláne úgy, hogy más motyóval meg tetszőleges parancsot le kell, hogy tudj futtatni a gépeken...

Én ilyen volumenben mindenkép kolompolnék egy szűkített (IP-re/hostkulcsra korlátozott) ssh hozzáférés engedélyezéséért, mert bár Zuzu Petals is lehet beszélgetőpartner, de... :-)

( uzsolt v | 2017. 08. 04., p – 10:35 )

Ezek a feladatok mennyire ad-hoc jellegűek? Azaz úgy történik, hogy gondol egyet valaki, és akkor azt le kell kérdezni néhány szerverről, vagy pedig a feladatok előre tudottak.
Másrészt a szerverekhez milyen módon tudsz hozzáférni?

Szerintem ha ezek a kérdések tisztázottak, akkor esélyesebb valami jó megoldást találni.

( gelei v | 2017. 08. 04., p – 10:51 )

Hogy kezelitek most a szervereket? Oké, hogy nincs ssh, de jó lenne tudni, miből kell dolgozni. :)

( bazso | 2017. 08. 04., p – 11:02 )

Ha az ssh tiltott, akkor jó eséllyel bármilyen kívülről jövő, root joggal parancsokat futtató bármivel szemben is ez lesz a bibi.

A másik út, hogy a szerver maga megy el megkérdezni időnként hogy van-e dolga (pl. chef), de ssh nélkül ez is sajtreszelős kicsit.

Győzd meg a security csapatot hogy mire és hogyan akarsz ssh-t (tuti van általuk is elfogadható konfig), sok fejfájástól megszabadulnál.

Aztán vannak nyakatekert megoldások, mint pl a backup agent pre-script felhasználása, de az perverz, antipattern, és a biztonsága is kérdéses

( mogorva v | 2017. 08. 04., p – 12:18 )

Hi,

Köszi mindenkinek a válaszokat.

Az ssh félreérthető volt: van ssh, de tiltva van a távoli parancs futtatás: "ssh hostname parancs"
De sima ssh login van.

Rundeck: ismerem, jobb kellene (vagy legalábbis amit én ismerek, az elég béna).

Most Ansible-t használok, de az szerintem konfig és service management tool. Lehet, hogy ez nem gond, de hülyén néz ki, hogy egy command outputját regisztrálom változóba majd debug-gal kiírom. Azt gondoltam, van ennél szebb megoldás is.

De úgy látom, nincs jobb eszköz (még a Rundeck a legjobb tipp), különben már vki bedobta volna.

Ha sima ssh loginod van, és nem riaszt a Perl, akkor szerintem az App::Clusterssh modulra lehet építeni olyan eszközt, ami párhuzamosan indít n darab ssh session-t, beloginol, és a megadott stringet "betolja" az élő, "interaktív login"-ként felépített ssh session-be, amit meg a túloldal visszaír, azt meg lokálisan megjeleníti/gépenként lerakja egy fájlba/satöbbi.

Szerintem annyira nem gáz ez, ha a debug kimenete nem tetszik, nem egy wasistdas írni egy olyat modult, ami úgy írja ki, ahogy te akarod. Mondjuk nem is értem, ha 200 gépen meg akarod nézni, hogy ott a foo.txt, akkor milyen formátum lenne jó?
gép-ok
gép-nemok
debug ugyanezt csinálja.

De ha meg az a végcél, hogy ott legyen a foo.txt, akkor a copy modullal nem egyszerűbb megoldani, hogy tegye is oda? Max. force:no, ha nem akarod, hogy felülírja, ami már van.

( KissT | 2017. 08. 05., szo – 10:09 )

mcollective?

amúgy nekem ez eléggé monitoring-nak hangzik, gondolom van valami monitoring software már helyben nyilván nem futatsz százas nagyságrendben szervereket monitoring nélkül szóval azt is érdemes megnézni hogy még ha kicsavart kézzel is de tudod-e a meglévő monitoringot erre is használni, ugyanakkor azt is alap lenne hogy van configuration management ilyen szerver számnál szóval ki tudja...

* Nincs "if-else", a "count=0" hasznalata mint "ha letezik csinald" - egy vicc.
* Nincs rendes loop, a "menj vegig az indexen" egy vicc.
* A remote state vagy mukodik vagy nem. Ha menet kozben leall valamikor, akkor keresztet is vethetsz az egeszre.
* Nem kezel tobb state-t. Csak egyetlen egyet, ha local-ban akarsz nyomulni. Persze lehet azt csinalni, hogy logikai egysegenkent letrehozol egy konyvtarat es egy variable-ekkel, meg symnlinkekkel szepen osszefesulsz mindent. Igy ha belepsz egy konyvtarba oda csinalja a state-t. Na de mi van ha abbol is ketfajta kell. Ja az mar nem megy, mert felulcseszi. Varj akkor ott a remote state...ooo...lasd fent.
* Modulokat ne hasznalj, mert a modulokban hasznalt variable-eket nem ismeri fel destroy eseten, azaz hibara fut. Ezt kb a 0.7.2 ota csinalja, ma meg mar ugy a a 0.10.0-nal tartunk.

Oooo. Es meg ezer mas szar. Egyszeruen nem gondoltak at a dolgot amikor terveztek. Illetve ezt tenyleg nem szabadott volna kiadni a 2.3.4-es verzio elott. Az meg meg legalabb ket es fel ev. :D

Es most akkor meghasonlok, mert bizony a terraform-ot. De szopas az egesz. :D

Viszont a kerdezo nem a clouderroforrasok managmentere akarja hasznalni az eszkozt, hanem hogy configuracviokat ellenorizzen egyes gepeken. Erre viszont a terraform tenyleg alkalmatlan. Ugyan osszeloheto a puppettel (de azzal meg minek).

Szet kell ezt kicsit vagni:
* Letrehozas: amikro elso alkalommal letrehozunk egy eroforrast
* Configuralas: amikor a letrehozott eroforrast melyebben konfiguraljuk (az apachot is beallitjuk rajta)
* Torles: teljesen toroljuk minden elemevel egyutt
* Modositas: csak egy EBS volume meretet valtoztatunk, vagy bedugjuk egy uj halozatba

A fentieket kellene tudnia a TerraFrom-nak.
- Ezzel szemben tudja a Letrehozast, de sajna a state-k kezelese nulla, amire erosen epit, igy tulajdonkeppen hasznalhatatlan is :D
- A configuralast nem tudja csak usertemplate-k hasznalataval (a puppet meghivasat felejtsuk mar el), ami egy vicc ugye egy salt vagy chef vagy ansible-hez kepest
- A Torleskor meg imadkozz, hogy minden menjen (a mount-olt ebs volumokkal az ec2 destroy nem fog sajna meg dependency kezeles eseten sem, pl.)
- Modositaskor a legszornyubb, hogy egyes valtoztatasok eseten torli az eroforrast es ujra krealja. Ami szamos esetben megengedhetetlen

Amugy amig nem kellet TerraForm-olni:
- Ansible+add_host modul a Letrehosasra es a letrehozaskori konfiguraciora
- Ansible+dynamic inventory az elso es a kesobbi ujrakonfiguralasokra
- Ansible+dynamic invantroy a torlesre

Viszont hatranya az Ansible-nek, hogy nem mindenre van modulja. Elonye viszont, hogy kb. egy fel ap alatt meg lehet irni egy uj AWS modult, ha annyira hianyzik. :D
Ugyanezt probald meg a GO-ban irt TerraForm-ba belehegeszteni valahogy. :D

Ha az ugyfel azt mondja ugorj, en megkerdezem milyen magasra :D
Komolyra forditva a szot, ha az o infrastruckturajukban mindenutt X termeket hasznalnak es az igeny az, hogy a beszallito is azt hasznalja es tolja fol a tobbi kod melle ami X-hez tartozik, akkor azt kell csinalni. Persze en mnimalizaltam a TerraForm hasznalatat es a apply/destroy-on kivul mindent az Ansible csinal. Sot a destroy nagy reszet is. :D (kacsint, kacsint)

hogy mi a velemenyem arrol, hogy szerinted vilag legnagyobb adatmennyisegevel dolgozo cegeinek, a bigdata zaszloshajoinak en mondom meg, hogy fogjak be a pofajukat, mert az lesz amit en akarok es kuss, hogy ne a fika egye az ovodast, ahol is ok a fika... :D

De azt hiszem a hozzaszolasod utan nem erdemes barmit is hozza(d) fuznom :D

vagy felreertettelek es en vagyok a fika...de akkor meg ..varj csak, ugyanez a vege...no comment

He? Holtamadtam Rad? Egy kis kronologia:
- Leritam, hogy TerraFormot "kellett" hasznalni az egyik projekten
- Megkerdezted kellet-e
- Megirtem miert kellett es hogy hoygan is mukodik ez parszazezer fot foglalkoztato nagy cegek eseteben
- Leirtad, hogy akkor a fika eszi az ovodast (ebben egy kis gunyt ereztem, hogy ugy ugralok ahogy az ugyfel futyul, ami igaz is, mivel az o igenyeit kell kielegitenem, hogy megkapja a ceg a penzet, ahol dolgozom)
- Leritam, hogy no comment (lasd, hogy miert)
- Megjegyezted, hogy az ultimate ervedre nem is lehetne semmit mondani
- Leirtam, a "no comment" mogotti tartalmat
- Hiszti, hiszti, hiszti, hogy miert bantalak :D

Hidd el en is nyugodtan alszom :D

A terraform nekem elso sorban azert tetszett, mert kello melyesegu az integralas az AWS-sel, illetve a konfig kelloen egyszeruen olvashato. Kuzdottem egy sort a Cloudformationnel, de az kicsit nopliz esete volt. (Debugolhatatlan, gyakran 30 perc + volt egy egyszeru provisioning, etc.)

Puppettel is kuzdottem egy sort, de szamos erv szolt az atfogo hasznalat ellen amikor legutobb neztem: 1. memoriahasznalat a celgepen 2. master nelkul nagyon korlatozott a funkciohalmaz 3. a default mukodese szerint minden uj gepnek kell ertelmes reverse DNS, kulonben nem kaphat manifestet. Ha egy IP es hostnev ujra kiosztasra kerul (pl. autoscaling groupban), akkor a master elhajt a retekbe. 4. Az AWS konfiguralashoz kell egy gep amirol kezdemenyezed.

Ansible megnezesi listan van, de valahogy nem sikerult meg megbaratkozni vele.

--
Pásztor János
Sole Proprietor @ Opsbears | Refactor Zone

A Cloudfiomration egy vicc (volt, de kezd jo lenni, ugyanakkor en is kerulom :D).

En az ansible-t pont azert szeretem, mert szep "Infrastructure as a Code"-ot lehet belole csinalni, es nem kell ruby-val bohockodni. YML es kesz. Es eleg jo a ninja template (mit jo, iszonyat fasza). Illetve a python-hoz jobban ertek, mint a ruby-hoz. :D

Egyszeruen szamomra ninca ami ellene szolna.
Persze a gyors fejlesztesi utem miatt mindig erdemes elolvasni a changelog-ot, illetve az altalad hasznalt modulok doksijat, hogy eppen mit valtoztattak mire a kulcsszavaknal. :D

Amugy a fo bajom az a TerraForm-mal, hogy amit most csinalok vele, azt siman megtehetnem Ansible-el is es tisztabb, szarazabb erzes lenne. :D

Na, futottam egy kort az Ansible-el... nem vagyok 100%-osan boldog tole, bar ez lehet hogy csak a megfelelo dokumentacio hianya. Pl. itt van egy adott gep amit letrehoztam, az egyszeruseg kedveert a DigitalOcean API-val. Utana hogy veszem ra az Ansiblet hogy jelentkezzen be a gepre es ott csinaljon dolgokat? Kezzel beirom a host listaba? Vagy van ra valamilyen megoldas hogy ugyanazon futas kozben felnyalja es felconfolja?

--
Pásztor János
Sole Proprietor @ Opsbears | Refactor Zone

Erre valo az add_host.

Amikor letrehozod a gepet(eket) csinalj egy "register: digital_machines". Utana barhol tudod az ebben visszaadott json/yaml/yml akarmit amit a digitalocean visszaad kezelni. A kovetkezo step igy az lesz mondjuk, hogy add_host amiben a with_items a digital_machines kimenetenek hasznalataval egy tomb elemei lesznek pl. "digital_machines.instances" (amennyiben ad olyat vissza). Ezek utan ha minden instance elemnek van ipv4_address-e, akkor azt mondod az add_host-nak, hogy {{ item.ipv4_address }}. De le van dokumentalva az add_host modulnal peldakkal.

A masik lehetoseg, hogy egy dynamic invantory scpritet hasznalsz, de ez azt jelenti, hogy egyszer futtatod a playbook-ot, hogy letrahozza a gepeket, a masikban pedig a konfigot. A dynamic inventory meg majd visszaadja az osszes dolgot ami neked kell.

Ez lehet elsore bonyolultnak hangzik, de hidd el nagyon nem az.
Sot en ugy szoktam, hogy a regisztralt kimenetbol inkabb gyartok egy listat set_fact modul hasznalataval (mondjuk hosts_ips) es utana akkor mar inkabb ezt hasznalom es nem valami hosszu json parsingot.

Ja meg valami. Mi is ugy hasznaljuk az Ansible-t hogy a terraform megcsinalja minimalisan a gepeket -> ansible dynamic inventory-val meg konfigolja oket.

Sajnos a konfigra teljesen alkalmatlan a TerraForm, en legalabbis nem akarok olyan shellscriptet irni, ami megnezi, hogy volt e mar konfigolva valami, ha a TerraForm ujra fut. Erre valok a puppet, chef, ansible. Mondjuk ha puppet-et hasznaltok, akkor jo lesz a TerraForm, mert azzal tud beszelni (meghivja az agent-et a hoston).

De amit most en latok, hogy a vilag az Ansible fele mozdult el a puppet/chef oldalrol. 10 ugyfelbol 9 azt keri. Szoval erdemes belenezni.

Én simán az inventory-t query-zem ütemezve különböző szempontok alapján (distro, pillar, szerver típus, stb.) és ezekből csinálok host file-okat.

A dokumentáltsága egyébként szerintem elég vacak, viszont a netről (pl. github) sok hasznos infót össze lehet szedni.

Mondjuk a YAML-tól való undor leküzdéséhez van egy szerintem nagyon jó szintaxis egyszerűsítés az Ansible-ben (remélem marad is):
pl.:

copy:
src: source/path
dest: dest/path
owner: myuser
group: mygroup
mode: 0640

(nem tudom, code-on belül a tabulálás miért nem működik, a copy allattiak eggyel beljebb vannak)

helyett:

copy: src=source/path dest=dest/path owner=myuser group=mygroup mode=0644

Nekem ez utóbbi jobban tetszik a tömörségével.

Egyrészt azt hiszem nem hallottad a lényeget a merge emlegetésével, másrészt ez miért jobb, mint a teljesen szabványos yaml: 


copy: {src: source/path, dest: dest/path, owner: myuser, group: mygroup, mode: 0640}

Már azon túl, hogy valaki nem olvasott doksit, vagy nagyon not inverted here szindrómája volt, és muszáj volt beletenni neki valami nem kompatibiliset csakazértis?

"Ez sem (annyira) rossz, nekem a másik tetszik, na."

Érteni értem, de biztos, hogy két kapcsos zárójel és pár vessző megspórolása miatt nem áldoznám be azt, hogy random yaml parserrel lehessen dolgozni az adattal. Aki ezt bevezette, azt kéne tarkóncsapni.

(Főleg, hogy pl ha szegény könyvtárat mondjuk program filesnak hívják, akkor a csodaszintaktika a fasz se tudja mit csinál. Illetve nyilván idézőjelezni kell. Amit meg yamlben csak azért, mert whitespace van, nem kell.)

"Amúgy a mergenél meg nem értem, mire gondolsz, ha branchekre a verziókezelőben, akkor sem olyan hű de nagy a probléma."

Bár nem én voltam, de két gond is van vele, ha egynél több dolog változik. Nyilván nem kibírhatatlanok, de:
1) Ez nyilván ízlés kérdése, de én jobban látom mi történt ebből: 


 copy:
-  src: source/path
+  src: source/otherpath
   dest: dest/path
-  owner: myuser
+  owner: otheruser
   group: mygroup

mint ebből: 


-copy: {src: source/path, dest: dest/path, owner: myuser, group: mygroup, mode: 0640}
+copy: {src: source/otherpath, dest: dest/path, owner: otheruser, group: mygroup, mode: 0640}

2) Ha a fenti példában a két változás különböző helyről jön (pl mert valaki korábban már átírta a pathot, te meg most a usert), akkor a második merge conflict lesz, amit kézzel kell kezelni.

Idézőjelezni kell, persze, az nyilvánvaló.

Na ez az, amire azt mondom, hogy ennyit azért még át lehet tekinteni egy diff-ben. Meg azért ez nem egy programnyelv, vagy egy program, ha 2 paramétert egymástól függetlenül 2 ember akarna mergelni, akkor ott már túlságosan fel vannak osztva a feladatok :)

"Idézőjelezni kell, persze, az nyilvánvaló."

nem, nem nyilvánvaló :) a 


copy:
  src: Program files
  dest: dest/path
  ...

ugyanúgy, ahogy a: 


copy: {src: Program files, dest: dest/path, ... }

is valid yaml. Úgy, idézőjel nélkül. Szóval a csodaszintakszis erősen szembe megy annak, ami egyébként a yamlben van, ezzel is segítve az átjárhatóságot :)

"Na ez az, amire azt mondom, hogy ennyit azért még át lehet tekinteni egy diff-ben"
Mint mondtam izlés kérdése, az elsőt azonnal megértem, a másodikhoz legalább 2 másodpercig hunyorognom kell. (Arról a mókáról már nem is beszélve, hogy simán nem veszem észre, hogy mondjuk egynél tobb dolog változott :) )

"Meg azért ez nem egy programnyelv, vagy egy program, ha 2 paramétert egymástól függetlenül 2 ember akarna mergelni, akkor ott már túlságosan fel vannak osztva a feladatok :)"
Nem kell ehhez 2 ember, elég ha te nem pulloltál, mielőtt szerkesztettél. Vagy csak párhuzamosan nagy tételben raknak épp rendet, az bizony előfordul. Az ilyen tooloknak épp az az egyik erőssége, hogy a szofver fejlesztésben bevált toolokat használjuk, hogy adott esetben nagyívű refaktorokat is meg lehessen csinálni könnyen. És ezért nagyon csúnya, hogy egy minor syntax sugar miatt borítja a kompatibilitást akármivel. Innen nem tudok rajta gyors végigszaladni egy scripttel, és rendbetenni, lendületből átbaszni jsonba és bepostolni valami csatolt rendszerbe, stb stb. Ezért nagyon kártékony ez, az, hogy mellesleg még sytax sugarnak is szar, az tényleg mellesleg :)

Azért egy C kódnál cifrább dolgok is vannak, mégis megoldja az ember.

Szerintem emberközelibb az "alternatív" írásmód. Engem az jobban érdekel, hogy én el tudjam olvasni, mint a gép. Ezért utálom pl. az XML konfig formátumot is. De egyébként lehet, hogy egyszer meg fogják szüntetni, a dokumentációból már kivették.

"Azért egy C kódnál cifrább dolgok is vannak, mégis megoldja az ember."

Meg hát. De ugye itt most sytax sugarról beszélgetünk :)

"Szerintem emberközelibb az "alternatív" írásmód."
Mondom, ízlések és pofonok. Szerintem a vesszővel elválasztott lista pont ennyire emberközeli :) A rendesen kiírt lista diffje meg határozottan sokkal emberközelibb :)

Engem az jobban érdekel, hogy én el tudjam olvasni, mint a gép".

Lelked rajta. Majd gondolj erre, mikor valami nagyobb turkálás kapcsán egy fél délutánt elbaszol arra, hogy a sed és undorító regexek segítségével old meg, amit jqval, command line yamllel, vagy egy pár soros random scripttel (mert yaml parser mindenhez van, és többnyire faék egyszerű) bruttó 10 percben megoldhattál volna.

"Ezért utálom pl. az XML konfig formátumot is."

Az XMLt ugyan arra tervezték (a legenda szerint, aztán a fasz se tudja), hogy géppel is, meg embernek is lehessen olvasni. Ez sikerült is, csak mindkettőnek rettenetesen fájdalmas. Szóval szerintem nem érdemes idekeverni, a yaml egy alapvetően jól olvasható formátum.

>> Amúgy a mergenél meg nem értem, mire gondolsz, ha branchekre a verziókezelőben, akkor sem olyan hű de nagy a probléma.
> Bár nem én voltam, de két gond is van vele, ha egynél több dolog változik.

+1
bár én csak a másodikra gondoltam, de az első is szokott pain in the ass lenni...
--
blogom

- nem illeszkedik a unix "filozófiába"
- abba a software generációba tartozónak érzem, aminek a fejlesztői lusták/óckodnak megtanulni régi jól bevált fogásokat
- és ezért újra meg újra feltalálják a kereket,
- sorozatosan olyan koncept hibákat követnek el, amiken a kitaposott úton járva hamarabb túljutottak volna, gyorsabban kinőtt volna a software a gyerekbetegségeiből

~~~~~~~~
deb http://deb.uucp.hu/ wheezy yazzy repack

félre ne értsd, értem én, nekem is van egy csomószor olyan érzésem az újvonalas tooloknál, hogy ezt most miért kellett így, meg ehhez minek kellett feltalálni a spanyolviaszt, és konkrétan nem tudom megmondani, hogy miért fáj. Csak azért igyekszem tudatosan más kategóriába sorolni a "nem tetszik, ahogy működik", és a "rosszul működik" dolgokat, és ennek megfelelően kezelni.

Az egy dolog, hogy nem tetszik ahogy mukodik, de azt rosszul is csinalja sajnos. :(

A kerdes, hogy az hogy nincs benen IF es LOOP csak nekem nem tetszik, vagy ez nem jo mukdoes. A fejlesztok szerint ez egy tokeletes mukodes. A forum-jaik +1-ei alapjan hibas dontes. :D

Es ebbol van ugy tizezerszazmillionyolvanegy a TerraForm-ban. :D
Olyan "jajj miert ment el pocsekba ez az egesz, pedig de jo lett volna" erzese van az embernek.
De azert hasznalom :D

nálam a "nem tetszik" és a "rosszul működik" az egy subsztancia ... de ez már filozófiai magasságokba emelné a témát :D

közel mindenre, aminek a működése valakinek nem tetszik, rá lehet fogni hogy "dehát ez így működik jól", "le van dokumentálva", "más logika alapján ez normális", "nem bug hanem fícsör", stb. – minden ilyen esetben valójában csak az van hogy a felhasználó és a fejlesztő (-n keresztül a program) logikája nem illeszkedik egymásra.

ezek alapján talán azt mondhatom, "nem tetszik hogy ez szándékosan így működik jól"

:D

~~~~~~~~
deb http://deb.uucp.hu/ wheezy yazzy repack

Nem, nem egészen. Vannak dolgok, amik kifejezetten szarul csinálják, amit kéne nekik (pl bugosak, meg esnek kelnek, vagy egyszerűen csak rosszul oldják meg a problémát, mert szarul van szervezve mondjuk a UI). És vannak dolgok, amik a saját konfortzónámon / megszokásaimon kívül esnek, illetve az adott problémára, amit próbálok megoldani nem jók. Na, ezeket a toolokat ígyekszem agyban nem leírni teljesen, hanem végiggondolni hogy adott esetben másnak, vagy másik problémára nem lesz-e jó.

És igen, ez filozófiai magasság :) Viszont tök jól le lehetett szűrni belőle, hogy a terraformot érdemes lehet azért megnézni (kritikusan, bár az alap),mert bár per se neked nem tetszik, nem azt mondtad róla, hogy egy bugos szar, hanem azt, hogy nem tetszik :)

khmm...amugy erosen egy bugos szar am, masfel eve hozza nem nyult bajokkal. Viszont az uj feature-ok mindig jonnek. :D
Erdemes elolvasgatni a github-os bugokat. Neha agymenes az egesz. :D

Ettol fuggetlenul hatarozottan allitom, hogy nem csak erdemes, hanem kell is, hogy utana nezz ha magasabb szintu infrastruktura automatizalas erdekel. (amit amgy regebben megoldottunk sima pixie-bol egy kickstartal vagy preseed-del :D)

Annal feljebb mar inkabb puppet, chef, salt, ansible-t erdemes hasznalni.

bocsánat, nem akartam úgy csinálni, mintha figyelmen kívül hagynám, hogy te ezt mondod, felírtam jól :) csak nem akartam teljesen összezavarni a beszélgetéseket...

igazából tényleg az van, hogy sajnos ezek az újvonalas CI/CD/devopsnak cimkézett toolok még mindegyik, hát hogy fogalmazzak diplomatikusan, látszik, hogy új cuccok, gyerekbetegségekkel, hiányzó alap featureökkel. Azok is, amik igazából mert nem új cuccok (hello jenkins, igen, rólad beszélek). És ja, régen ment ez pixieből :) De az igazság az, hogy azért hoznak új, és fasza dolgokat.

Bár már többször felmerült bennem, hogy szarok az összesre, és írok magamnak buildbotban sajátot, de mindig rájövök, hogy azt is azzal kéne kezdeni, hogy egy csomó nemlétező konnektort megírhatok a buildbothoz :D

( gthomas | 2017. 08. 08., k – 14:08 )

consul (by HashiCorp) minden gépre, és akkor lehet exec-el ad-hoc bármit futtatni rajtuk, pl. lekérdezésre is.

( d3n3s | 2017. 08. 10., cs – 10:33 )

Fabric (Python), illetve ahogy fölöttem is említették: Ansible (Tower vagy Semaphore), Chef.