A Puppet "fork"-ja, az OpenVox, közzétette első kiadását

Szerszám

A Vox Pupuli projekt bejelentette az OpenVox első kiadását, amely a Puppet automatizálási keretrendszer "soft-fork"-ja. A fork szándékát 2024 decemberében jelentették be.

Az OpenVox 8.11 funkcionálisan megegyezik a Puppet-tel, és helyettesítheti azt. Fontos azonban tudni, hogy bár ugyanazokat a parancsokat beírhatod, ugyanazokat a modulokat és kiegészítőket használhatod, valamint ugyanazokat a beállításokat konfigurálhatod, az OpenVox még nem esett át olyan szintű tesztelésen, mint a Puppet.

[...]

Kérjük, ne használd ezeket a csomagokat kritikus, éles infrastruktúrákon, hacsak nem vagy járatos a hibakeresésben ...

( trey | 2025. 01. 24., p – 13:12 )

Szerkesztve: 2025. 01. 24., p – 13:12

Ansible, Puppet, Chef ...

Ezek is mekkorát mentek annak idején ... egy időben nagy buzzword-ök az IT fórumokon ... itt is ... aztán ... <folytasd!>

trey @ gépház

azten milyen szepen mennek ezek meg mindig infrastruktura automatizalasra on-prem kmornyezetben meg mindig. Persze Cloud-ban inkabb hasznaljak a cloud providerek sajat megoldasait vagy a TerraFrom/OpenTofu/CrossPlane/Whatever megoldasokat, mivel azok kisse mashogy mukodnek (nem agent es nem SSH, hanem API). Aztan ott vannak a nem csak provision tool-ok, hanem azok amik mar inkabb infrastructure management-et csinalnak (provision + monitor + fix).

Es mindezek az eszkozok szepen megvannak egymas mellett, mert mind masra valo. Persze neked aki az IT-ban kalapaccsal szelsz tortat nem fog semmit mondani. Viszont mivel csak a kalapacsot ismered kurvara el vagy telve magaddal, hogy meg a spagettit is meg tudod vele enni 

Mindegy, csak legy eszmeletlen magabiztos es nezz hulyenek mindenki mast :D

Jaja, ülj fel mindig az aktuális hype train-re, attól leszel te az IT Janija! :D Hogy igazán az legyél, javaslom hozzá a cián hajszínt! Ja, azt már nem .... 🤔 az is lefutott már ... 🤭 Akkor itt van neked ez a Puppet soft-fork! Nosza, tűnj ki!

trey @ gépház

Ja, persze, én égetem magam, akinek nincs két egyforma projektje és olyanokat húzok ki a szarból rendszeresen mint amilyen te vagy, akinek az a munkája, hogy 500+ gépen robotol, elvégezve ugyanazt, de már ezt kiváltotta 2 marék shell scripttel, amit - dobpergés - hálózaton keresztül egy másik gépen!!!!! futtat :D

Talán '98 volt, amikor legelőször és utoljára örültem annak, hogy "jééé, SSH-n keresztül lehet parancsokat futtatni". :D :D

trey @ gépház

Te mirol beszelsz mar megint? Terraform 10 eves, en 6 eve hasznalom napi szinten. Az mitol aktualis hype?

Meg a labor infran is azzal huzok fel uj VM-et, mert egyszerubb letrehozni egy fajlt ami behuzza a modult es a 4 parameter atirasa 10x gyorsabb mint kezzel megcsinalni.
Kimegyek egy pohar vizert, mire visszaerek az asztalomhoz kesz.

Kivancsi vagyok Te mivel automatizaltad a napi igenyeket a munkahelyeden. Ha kell egy uj VM megcsinalod kezzel es elkonyvelsz ra x idot a ticketing rendszeretekben vagy hogy kell ezt elkepzelni?

Csak mert itt a fejleszto/tesztelo vagy akar a product manager egy gombnyomasra rak ki maganak egy teljes kornyezetet ami az epp aktualis munkajahoz kell a helyi VMWare kornyezetre vagy AWS-re.
Ezt van, hogy naponta tobbtucatszor megteszik, az automata tesztek meg maguknak rangatjak fel-le.

Amugy ha kezzel raknam ossze nekik akkor darabonkent 2 nap lenne.

Attul, mert a HP szervereken pont nem használnak ilyesmit, még megvan ezeknek a maguk felhasználása. A GitLab telepítését/frissítését pl Chef menedzseli, az OpenShift telepítését Ansible kezeli, stb.

Nem az a baj, hogy kevés dolgot látsz, hanem hogy általánosítasz. Én például alig látok HP szervert magam körül, nyilván mert mindegyik szar, és az igazi üzemeltetők hanyagolják őket.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

Vannak mindig olyanok akik nem tudnak olvasni :)

Azt gondolom, igaz a fenti megállapítás. A lényeg az volt, hogy hype elszállt, aztán maradt utána valami. Juhuuuu! Mintha minden nap ünnepeltem volna, hogy nem deselect-tel hányom a csomagokat már a Debian rendszerekre, hanem van APT!!!!4444

Nagy dolog, de milyen jól lehetett vele jaszkarizni.

trey @ gépház

Szerintem egy picit sarkitasz. 
Ezek a toolok annak jok akinek mondjuk van 50 gepe es nem akarja egyesevel atallitani az NTP szervert v nem akarja egyesevel az nscd-t nslcd-re cserelni. 
Abban a reszben egyetertek viszont h mindig van valami technologia amit felraknak a hype vonatra. Ansible eseten pl mikor 1 gepen is azzal csinal valamit az ember, mert az “meno”, na az pont ez a kategoria. 
A megfogalmazassal es a sarkitassal az a bajom h egy kalap ala veszel mindenkit. Azt is akinek ez a tool napi szinten orakat sporol, meg azt is aki erre matyizott h mennyire fasza a mi elavult szemleletunkhoz kepest h vannak parancsok es azzal megoldhato kb minden kis mennyisegu (<10) gep eseten. 

Szandekosan egy trivialis peldat akartam hozni. Van a rendszergazda, aki szepen vegigsshzza az 50 gepet, editalgatja a konfigot, stb. Megoldotta? Meg. Mondjuk 2 ora alatt, plusz 2 gepen elrontotta. 
Van a fosodratu mernokur (by hajbi), aki ir ra egy 2 soros playbookot, ami lefut 5 perc alatt, kozben megissza a kavejat. 
Akkor ki volt a hatekonyabb? (Csak koltoi a kerdes :))

en azt mondom hogy az ilyen cuccok nem (csak) attol faszak hogy automatan felszorja a php-t meg akarmelyik csomagot, hanem ha at kell allitani 16 web gepen a upload_max_filesize erteket, akkor nemlesz hibazas hogy egyik 128M, masik meg 18M (mert veletlenul kimarad egy 2-es) lesz, hanem mindegyik egyforma.

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Bámulatos, hogy hol tart már a tudomány, bazmeg! :D

Mintha annak örülnék, hogy szerda ebédidőben, amikor a plebs elmegy halózni a kantinba, kitolja az SCCM a legfrissebb x szoftvercsomagot, meg lefut egy valag script group policy-ból és a végén mind egyforma lesz, ugyanazon vállalat 5 távol eső városában levő site-on, az utolsó irodában is :D :D :D mert sikerült beállítanom 🤷‍♂️

Isten hozott 2000-ben!

trey @ gépház

En is javitalak, bocsi: ezzel nagyon nagy tevedesben vagy. 
Ez megint a sarkitas. Valszeg nem hasznalsz ilyen toolokat, de ebbol nem kovetkezik h szarok, ahogy az sem h ebben a melysegben ertesz hozza. 
Tisztellek es sokmindenben egyet is ertek veled sokszor, de sztem rossz az az irany h ami ismeretlen az szar meg tulhajpolt. Ezen kivul olyat irsz teljes magabiztossaggal, amit itt kapasbol meg tudunk cafolni sokan. Egy szakmai portalon sztem nem jo az amikor egy szamunkra ismeretlen toolrol megingathatatlan velemenyt formalunk, mert magadat hiteltelenited vele. 

Nem, _van 50 gépem_, nem azt írtam h. ugyanolyan.

Lehet az 3 különböző Linux disztró is. Netovább Windows. És nagyon nagy különbség van aközött a meghatározás között h. "le kell szedni róla", vagy "meg kell győződni róla h. nincs ott" (előfordulhat h. nem kell csinálni semmit).

Hogy példaként hozzam az Openstack-Ansible-t: megküldöd az inventorydat a playbook-al, ami felhúz 10 compute-ot, 2 network node-ot, 3 managert mondjuk. Akkor a te terminológiád szerint ez 15 ugyanolyan gép? Mert sztem nem.

Tehát van 50 egyforma Linux géped, amin ugyanazt kell csinálni. Ez egyforma.

Láttál te már igazán heterogén környezetet? Ahol Windows 2003-tól 2025-ig, ESXi-től FreeBSD-ig, SUSE Linux-tól CentOS-en át Ubuntu-ig mindent is kell supportálni? Nincs két egyforma gép, nincs két egyforma feladat, nincs két egyforma béállitandó? Nincs két egyforma hiba?

Megint kiindultatok abból, hogy ti vagytok a PHP Hosting Pistike Bt., ahol át kell lökni 100 egyforma  gépen a php.ini-ben valamit.

🤷

Meg létezik olyan, hogy valakinek van 100 ügyfele, 100 különböző rendszerrel, problémával.

trey @ gépház

Szerintem félreérted a tool mibenlétét és megint átmész személyeskedésbe. Köszi, de nem vagyok PHP Hosting Pistike Bt tulajdonosa/alkalmazottja/közelében.

Az első mondatod kapásból téves. De ebben a beszélgetésben, ahol az egy érv h. PHP Pistike.... felesleges továbbmenni.

Csak annyit mondanék példának h. van egy graylog role-om, amit group és hostvarssal konfigurálok, járt már Windows-on, Ubuntun, FreeBSD-n, mindegyik más ügyfél gépe volt és mindegyik gép tök más környezetbe tolja a logjait tök különböző beállításokkal. Mégis ugyanaz az Ansible playbook rakta fel a sidecart és állította be. Ha neked ebből az a következtetés jön össze h. van 3 ugyanolyan gépem, akkor szerintem átmentél valamiért write onlyba. Hogy miért az már a te dolgod, én nem szeretnék azzal vitatkozni h. feltételezel és személyeskedsz a topcitól teljesen elkanyarodva. Nekem ez most elég nagy csalódás volt a szakmaiságodban.

Jaja, sejtettem, hogy ez a kör következik. Semmit sem értettem félre, a példáitokra - ti hoztátok - reagáltam.

Csak annyit mondanék példának h. van egy graylog role-om, amit group és hostvarssal konfigurálok, járt már Windows-on, Ubuntun, FreeBSD-n, mindegyik más ügyfél gépe volt és mindegyik gép tök más környezetbe tolja a logjait tök különböző beállításokkal. Mégis ugyanaz az Ansible playbook rakta fel a sidecart és állította be. Ha neked ebből az a következtetés jön össze h. van 3 ugyanolyan gépem

Hazudsz, te arról beszéltél, hogy átírod 50 gépen az időszervert, a másik meg 500 gépről felteszel/leszedsz egy csomagot. Erre most hozol egy random loglapátolást A-ból B-be. Nem én ugrálok, hanem te.

A nagymenőzést te kezdted, már azzal léptél be.

trey @ gépház

Ezek mind-mind példák. Szándékosan nem komplexek, nem azzal szoktunk demozni sem h. feltelepítünk egy 1000-node-os OpenStack clustert.

Persze, van az SCCM, meg van mindenféle cucc régóta. Nem arról van szó h. el akarom neked adni az Ansible-t, csak szerettem volna szakmailag megcáfolni egy helytelen állítást. Ettől mindenki úgy dolgozik és azzal amivel akar, csak én nem fogok odaírni egy lightosan lesajnáló/valóságtorzító kommentet az SCCM cikk alá, mert nem ismerem olyan mélyen h. megalapozott véleményem legyen.

Nagymenőzés? Mert az a véleményem arról a kollégáról aki az Ansible-t konfiguráció management eszközként akarja használni h. nem tud olvasni? Továbbra is ez a véleményem, de ezt a README is alátámasztja. Ha ez nagymenőzés, akkor elnézést kívánok. Az Ansible pont nem erre készült. A Puppet pl igen, erre _is_ jó (2007-et írtunk, mikor pont emiatt kezdtük el használni Linuxos környezetben, akkor utáltam meg a Ruby-t).

Ne haragudj, de azért lehazugozol, mert hozok még egy komplexebb példát h. alátámasszam h. igenis működik az h. 3 tök különböző környezetre igaz ugyanaz a playbook v. role? Írjam én is h. hazudsz, mert kvára tud valamit a tool, amiről állítod h. nem? 

Nagymenőzés? Mert az a véleményem arról a kollégáról aki az Ansible-t konfiguráció management eszközként akarja használni h. nem tud olvasni? Továbbra is ez a véleményem, de ezt a README is alátámasztja.

"Ansible is a radically simple IT automation system. It handles configuration management, "

Oké, de ez egy szakmai portál. Kérlek mutass már rá az Ansible docs-ban h. hol van olyan h. ő egy konfigurációmanagement eszköz? Mindenhol odáig sikerül eljutni h. akkor lefuttatotd a playbookot és megcsinálja a konfigot. Ez nem konfig management, ez provisioning.

A konfig management az, amikor a Puppet agent gondoskodik róla h. az smb.conf-od tuti az legyen ami definiálva van a Puppet szerveren, teszi mindezt automatán. Tehát, ha elolvassa valaki a tool leírását alaposan, akkor rájön h. ez a mondat egy nagy marketing bullshit gyakorlatilag. Én meg úgy véltem h. aki bevezet valamit, az el is olvassa h. mit tud. De igazad van, ha csak ezt olvassa el a nyakkendős manager, akkor az, config management. 

Szerintem egy nyakkendős menedzsert kajak telibenemérdekli, hogy ti mivel bűvészkedtek. Hogy éppen 500 helyre fog az indiai beSSH-zni, vagy építhetsz magától zenélő rendszert, de közben a te béredből kijön 2000 indiai bérbohóc? Egyetlen egy valami fogja meghatározni:

Melyik Lesz Az Olcsóbb

A többi a kutyát nem érdekli.

trey @ gépház

Ebből meg full az jön le h. te ilyeneknek dolgozol. Van pár külföldi cég akinek bedolgozok, első mondat a megbeszélésen: Melyik Lesz A Hatékony

Abban meg tudlak erősíteni h. a kis magyar mocsárban más a mentalitás, de ez nem is csoda, mikor le vagyunk maradva többnyire úgy 50-60 évvel fejben mondjuk egy USA-hoz képest.

Nem kis magyar mocsár, barátom, hanem német, brit világcégek pont azok, amik Indiába szervezik ki ezeket a kulimunkákat, mert az az olcsóbb. Neveket csak azért nem említek, mert nem akarom őket kellemetlen helyzetbe hozni.

trey @ gépház

Azert szivesen megneznem h azok a cegek, amik nem dinoszauruszok vajon mennyi Architect munkat szerveztek ki indiaba az utobbi evekben. 
Meg az is h az indiainak kesz playbookot adnak-e v root jogot. 
Inkabb az elobbi, de tenyleg felesleges ezt huzni. Van igeny arra amit te csinalsz, meg van igeny az agyonhajpolt Ansible-re is. 
Igy van ez rendjen. 

Nézd, közölted, hogy a README is alátámasztja, hogy ez nem egy konfig management eszköz. Aztán ez a github repóban levő első mondata az, hogy ez egy config management eszköz. Az szerintem eléggé a doksija. De legyen akkor, ansible doksi, introduction to ansible:

Ansible provides open-source automation that reduces complexity and runs everywhere. Using Ansible lets you automate virtually any task. Here are some common use cases for Ansible:

  • Eliminate repetition and simplify workflows

  • Manage and maintain system configuration

  • Continuously deploy complex software

  • Perform zero-downtime rolling updates

Kiemelés tőlem. Ettől persze lehet még az ansible egy szar konfig management platform, szerintem se az az erőssége, bár szerintem nem azért, amit mondasz, az szerintem másodlagos kérdés, hogy hogy van garantálva, meg agent meg fene tudja, a config managementnek nem feladata védekezni a szándékos szabotázs ellen, ansible segítségével is lehet olyat építeni, amikor ettől az van kint, amire vársz, mert úgy van kialakitíva az infra. Bár tény, hogy ehhez is kicsit vékony a tooling, de leginkább azért nem, mert valójában rohadtul nem idempotens, akármennyire is hazudozta évekig ugyanaz a doksi, ami konfig managementnek hívja, hogy idempotens, mert ha az if-et when-nek hívjuk, akkor csoda történik, vagy nem tudom :D

Szóval sajnos a doksija konkrétan azt állítja, hogy ő config management.

Rendben, igazad van. Ha azt a száraz tényt nézzük h. ez oda van írva.

Lehet a terminológia szar, akkor pontosítom a "menőzős" mondatom: Ha a kolléga utánaolvasott volna a README-ben, meg az example-k között, akkor tudná h. erre a feladatra _önmagában_ az Ansible nem alkalmas. Kivéve ha azt konfigmanagementnek nevezzük h. egy Jinja2 alapján kirakom a konfigot, amikor entert nyomok a playbookra. De azért itt jön az amit te írtál ilyen szépen: kissé vékony a tooling :) Plusz ezt nagyon nem hívnám konfiguráció managementnek. 

Egyébként mi az, amitől a puppet annyival sokkal config managementebb? Mármint ok, van egy agent, az ansible köré meg nyilván kicsit sarkítva, de kell egy tisztességes inventory, meg egy cronjob kb. Amire azért tudok úgy nézni, hogy ez a kedvenc one thing, but one thing well mantra szerint tök rendben van. Cserébe az awx van ingyen is, a puppet webes interface meg nincs, meg hát van ansible-pull is. Egyébként meg mindkettőben le kell írni valahogy, hogy mi lesz ott, valami execution odamegy, aztán megcsinálja, csak az egyikben undorító yamlbe ágyazott jinja templatet kell írni, a másikban ha szerencséd van, akkor csak ilyen kamujson manifestet, ha kevésbé, akkor undorító rubyt, az egyikben inventory filet kell baszogatni, a másikban meg hierát. Tény kérdés, hogy az ansible egy kicsit legósabb érzést hoz magával, de arról meg azért tudjuk, hogy az attól függően jó vagy rossz, hogy épp mi a feladat, meg hogy az alapvetés egy rakás szar-e vagy sem (szerintem jó sok évvel ezelőtt ép buga kolléga a szomszéd threadból volt az, aki szépen lassan az ~összes vackot megírta saját modulba, amire szükségünk volt, mert ami volt "gyárilag", hát az ... szóval, na), én továbbra se látom, hogy mi az a rengeteg plusz, ami miatt önmagában kevés lesz.

Aztán lehet, hogy tévedek, és van valami nagyon extra ma már benne, mert jó rég láttam puppetet közelről, de most gyorsan belepillantva úgy tűnik, hogy nagyságrendileg ugyan az van benne, mint tök tudja, 15 éve volt. A saját miért jobb mint ansible doksijukból is az érződik kb, amit én is mondtam, hogy ez deklaratív, az ansible meg nem, meg ennek a származtatott előnyei :)

Mindkettonket helyre kell tegyem. 
Olyanon utkozunk ami nincs. 
Arra valaszoltam h “config enforcement”, nem arra h config management. 
Igy nezve a Puppet igen (hiszen az agent elvegzi ezt), Ansibel meg by design nem. Hiszen ahogy irtad is, neked kell takolni a kornyezetet. 
 

Igy mar valid az eredeti commentem sztem. 

Arra valaszoltam h “config enforcement”, nem arra h config management. 

Ah, volt egy olyan szál is, de itt konkrétan a config management hangzott el :)

Igy nezve a Puppet igen (hiszen az agent elvegzi ezt), Ansibel meg by design nem. Hiszen ahogy irtad is, neked kell takolni a kornyezetet. 

Igen (bár valójában egy ansible-pull meg egy (check) futás nem lesz olyan nagyon messze attól, amit a puppet agent csinál magától, orbitális tákolásnak azért nem mondanám)

"Szóval sajnos a doksija konkrétan azt állítja, hogy ő config management"

 

W: And this isn't my nose, it's a false one.
(V lifts up carrot)
V: Well?
P1: Well we did do the nose
V: The nose?
P1: ...And the hat, but she is a witch!

 

https://www.youtube.com/watch?v=rf71YotfykQ

:)

Szóval... mint olyan, aki használja mindkettőt, és ansible-t is konfig managementre... höhö... it's a false one.

Ami 50/500/50000 teljesen különböző gép is lehet. Lefutnak a feladatok, az AWX szépen annyi podot generál a Kubernetes clusterben a playbookok futtatására, amennyi kell neki, aztán visszaadja az eőrforrásokat.  Ez lehet egy új Kubernetes cluster kihúzása, egy új loadbalancer VIP,  tűzfal szabályok létrehozása, módosítása, egy új gép gép létrehozása/helyreállítása, mass change-ek végrehajtása vagy épp visszavonása és még use case-ek százai. 

Dolgozik a git, a kubernetes, a gitlab, és egyéb toolok, alig kell ember az opsra. Szerintem ezeket hamarosan az AI hajtja, az operáció kábelezésből fog állni, minden másra ott az AI hajtotta CICD.  

Honnan jön ez, hogy egyformának kell lennie?

Jóval több mint 100k node-ot érünk el Ansible-lal. Valóban van köztük rengeteg egyforma is, de irreleváns. Olyannyira, hogy nem is csak hagyományos értelemben vett szervereket tudsz vele kezelni, hanem szinte bármit. Fusson rajta tetszőleges OS, legyen bármilyen architektúra, lehet akár storage, cloud service vagy network device. Szóval pont az egyik legnagyobb előnye az SSH-val szemben, hogy nem kell "egyformának" lennie a targeteknek. Csatlakozhatsz többféle protokollon, különböző hitelesítéssel, használhatsz többféle privilege escalation-t. Szerintem pont akkor érdemes SSH-n maradni, ha egyforma szervereid vannak.

Ansible-hez más mindset kell, ami elsőre szokatlan SSH után:
- Ansible deklaratív, SSH imperatív. Az SSH-n azt mondod, hogy milyen parancsot szeretnél futtatni, az Ansible-lal pedig, hogy milyen állapotot szeretnél elérni - ez általában közelebb áll az üzlet/ügyfél igényhez.
- Ansible idempotens (próbál lenni) - lefuttathatod többször ugyanazt, nem lesznek duplikált szolgáltatásaid vagy hibásan generált konfigjaid, stb. (ez kellően nagyszámú célrendszernél nagyon nagy könnyítés).
- Homogén konfiguráció: szinte mindent YAML vagy Jinja-ban írsz le, amik nem csak hogy egységesek, de emberi szem számára könnyen olvashatóak és átláthatóak. (Legalábbis számomra sokkal szebb, mint a JSON, XML, egyedi szöveg alapú konfigok).
- Központi management - Ansible már standalone is kifinomultabb eszköz nagyszámú heterogén target kezelésére, mint az SSH.
Automatizált működés - AWX/Tower/AAP-val kiegészítve drasztikusan csökkenthető a monoton, repetitív, alacsony hozzáadott értékű emberi munka.

Honnan jön ez, hogy egyformának kell lennie?

A példáitokra reagáltam:

Ezek a toolok annak jok akinek mondjuk van 50 gepe es nem akarja egyesevel atallitani az NTP szervert v nem akarja egyesevel az nscd-t nslcd-re cserelni. 

[...]

en azt mondom hogy az ilyen cuccok nem (csak) attol faszak hogy automatan felszorja a php-t meg akarmelyik csomagot, hanem ha at kell allitani 16 web gepen a upload_max_filesize erteket, akkor nemlesz hibazas hogy egyik 128M, masik meg 18M (mert veletlenul kimarad egy 2-es) lesz, hanem mindegyik egyforma.

Ki a fasznak kell 50-100-1000 gépen ezeket csinálnia? Egy szűk rétegnek, az IT egy részének.

Hja, értem, hogy van sok hókusz-pókusz, kb. úgy, ahogy máshol. Dolgok megtörténnek csodálatos módon távoli gépeken. De, miért kell(ene) ettől hasra esni?

trey @ gépház

Egész infrastruktúrát (különböző célú és oprendszerű szerverek, virtual appliance-ek, hálózati eszközök alkotják) provisionölünk nulláról és üzemeltetünk Puppet segítségével, de ismételgestd csak az "50 egyforma gép" és "5000 gépen átállítani a foobart" mantrát. :D

Van több puppetes és ansible-s scenario is, nem minden publikus belőle, de nagy vonalakban:

- van céges spéci Debian/Ubuntu alapú Linux disztribúció, a belső support csapat Puppet Enterprise segítségével maintaineli ezeket távolról
- van olyan connectivity termékünk, ami customerekhez kerül ki, a vonal végén van egy vagy több szerver (akár egy blade-nyi is), azon vSphere és arra kerül fel a virtuális routerektől elkezdve különböző funkciójú linux/BSD/egyéb egzotikus VM-ek, ezek automatikus deploymentje, upgrade-je/patch managementje zajlik ilyen módon
- van olyan telkó termékünk, ami kubernetesre települ, a deployment automation és az upgrade van ilyen módon megtámogatva, itt nem történik semmi automágia, a kész ansible playbookokat a deployment engineer használja
- van olyan posture management termékünk is, ami beépítve tartalmaz ansible-t és azzal scriptelhető, ott a customer használhat standard ansible-collections modulokat a legozáshoz, nem kell újra feltalálni a spanyolviaszt

A fenti technikák egy részét sok helyütt új termékekben kiváltotta a konténerizáció, de ott is kell valahogy az alatta lévő infrastruktúrát telepíteni/előkészíteni.

Barátom, a mi világunkban már akkor léteztek ilyenek és szállítottuk is őket, amikor te még egy HDD-nyi shell scripttel bohóckodtál.

Nem a toolon röhögtem, félrértés ne essék, hanem azon a jelenségen, hogy amikor ezek megjelentek nálatok, úgy örültetek, mint majom a farkának, ment a tánci, hogy ez lesz a jövő, mindenki mindent dobjon el és ki ... Mindeközben csak 15 évvel voltatok lemaradva ... tőlünk.

Futkoztok itt mint pók a falon, hogy van nyitható ajtó, meg forgatható kormány.

trey @ gépház

te olyan vagvy mint az alkoholista mari neni a mellekgomorszentjakabi kocsmaban, aki meg eleteben nem ment tavolabvb az utcaja vegeben levo AFESZ kocsmanal, de meggyozodese, hogy jobban ismeri a vilagot mindenkinel jobban es ennek sokszor hangot is ad jo nagy bohocot csinalva magabol :D

koszonjuk :D

Jaja, már 2000-es évek elején olyan eszközökkel dolgoztam, aminek te 15 évvel később örültél, mint majom a farkának.

VMware témakörben pedig rád férne egy fejtágító, mert még mindig azon a szinten vagy, aki azt hiszi, hogy a VMware egy fizetős VirtualBox :D

hint: Tanzu, Aria stb.

Keress valakit a nagy cégednél, aki látott már ilyet és meséltesd el, hogy mik ezek 🤭

trey @ gépház

Jaja, már 2000-es évek elején olyan eszközökkel dolgoztam, aminek te 15 évvel később örültél, mint majom a farkának.

A 2000-es évek elején szerintem pont ugyanolyan eszközökkel dolgozunk mindannyian... azóta fordult egy csomót az IT világ és alapvetően te maradtál le, csak valamiért azt hiszed, hogy mindenki más maradt a 2000-es évek elején, selection bias, más ligában focizunk, nagyobb költségvetésű projekteken, mint amekkora a cég több éves bevétele, ahol dolgozol... :D

https://iotguru.cloud

A szórakozás kölcsönös 🍺

Annak örülök, mint írtam, valószínűleg fel se tűnik a tudás hiánya okán, hogy amúgy égeted magad a faszságokkal. :D

Azért kíváncsi lennék, hogy ezt a sok bullshitet hogyan sikerül ügyfélnek eladni :D

Úgy, hogy nem a múltban élnek, hanem a jelenben és nem eladni kell nekik ezt, hanem megkeresnek, hogy lenne ilyen meló, mondjuk, mint említettem, kidobni a picsába Tanzu-t és csömböllékeit. Neked meg maradnak azok az ügyfelek, akik a múltban élnek és jó nekik az is, nincs igényük másra, mert egyrészt nem ismerik, másrészt a beszállítóik se ismerik, így boldog tudatlanságban léteznek. Win-win.

https://iotguru.cloud

Ja, nem tűnik fel, hogy éppen aktuális hype-pal házalsz mint a Teleshop. Nem, nem. Bizony, nem.

Hype? A Puppet most nyáron lesz 20 éves, 15 éve használom. Az Ansible csak 13 éves, azt 10 éve használom. A Terraform, na az lehet, hogy hype, az még csak 10 éves tool és csak 10 éve használom. Hajj, ember, te tényleg nem tudod, mi a lófaszról beszélsz, annyira nem értesz a területhez. :D

És égetem magam, hogy nekem megfelelnek az iparban bizonyított dolgok és nem ugrálok fel hetente az éppen aktuális VarázsIT 2020™ bullshitre.

Trey-trey! Héló! Valaki szóljon trey-nek! Hajbazer feltörte az account-ot. :D

https://iotguru.cloud

Inkább fizessék ki ezt a kurva sok pénzt neked, aki

  • jaj, a kölköm
  • taknyos az orrom
  • nincs kedvem
  • haggyámá' megy a sorozat a Home Office-ban
  • haggyámá' szabadságon vagyok
  • stb.

értem. Majd te megírod az obskurus szarodat, hogy megtörténjen a csoda 200 gépen, egyformán. Összetákolod OpenFuFu-ból.

trey @ gépház

Alapvetően egyetértek veled abban h. a HO több problémát jelent mint hasznot, de ez egy nagyon durva általánosítás. Csak a közvetlen környezetemben több ember szokott HO-ban lenni és a produktivitásuk semmilyen módon sem esik ezalatt, sőt, néha még jobb is mint ha bent ülnek a csavargyárban.

Asszem Dániáról volt valami cikk valahol (ebbe beleköthetsz, mert pontosan nem fogom belinkelni), ami arról szólt h. a dánoknál nincs ez a kommunista hozzáállás, nem baj ha taknyos vagy, vagy beteg a gyerek, mehetsz, senki se kér számon, a munkádat értékelik, nem azt h. azzal mennyi időt töltesz el és hol. Persze, egy új üzletet bekábelezni, összerakni a hálózatot, stb. azt nem lehet HO-ból (15 évig csináltam ilyeneket, szóval láttam közelről), de amit lehet esetleg ott pont a rugalmasság tud előny lenni, ha tud azzal élni a kolléga. Az h. általánosítunk h. mindenki aki HO ban van egy tórger lusta fasz, az szerintem erős túlzás.

Ettől tök függetlenül én is behívom minimum 2, de inkább 3 napra a srácokat az irodába, mert szocializáció, kávé mellett ötletelés, stb. még mindig hatékonyabb mint teamsen ülni ingben-alsógatyában.

Szuper, akkor vizsgáljuk meg abból a szempontból, hogy egy rendszer ipari standard építőkövekből épül fel, amihez a megbízó kb. bárhol talál hozzáértőt, ha a leszállítójával baj van vs. összetákolt, obskurus izé, aminek a titkait őrzi a szállítója, mert attól függ a megbízása, hogy ő az értője.

Na, mi meg ezeket szoktuk kifele lapátolni. Nem egy helyen futottunk bele ilyen szarokba, beleérve Magyarországi egyetemeket stb. (ahol elvileg házon belül is érteni kellene hozzá, nem, hisz ők tanítják ezeket), ahol olyan dzsumbuj kuplerájokat szoktunk találni, hogy besírsz.

trey @ gépház

Hozok egy ellenpéldát: a jelenlegi munkahelyemen pontosan ezt hitték h. itt minden milyen rendben van. Aztán kiderült h. van egy /devops mappa az egyik gépen, amiben csöcsül 50db bash script, amit 100-an írtak az utóbbi 10 évben.

Na pl. ezeket cseréltük le Ansible-re. Kérdem én, ha valami RedHat által támogatott, tehát enterprise valami, akkor az átmegy az ipari standard felkiáltásodon v. jobb ha nem vezetjük be és jön az ilyen shadow it h. "megpatkolom valami scripttel". Melyik a jobb?

Az h. toolingot úgy kell választani h. az támogatott legyen az nem kérdés productionben. De ez a topic nem az OpenTofu és barátairól szól, hanem Ansible, Puppet, stb. Ezzel indítottad az eszmecserét.

Attól h. valami shiny new izé és a 23. forkja valaminek és tud valami csodát, attól én istenbizony nem fogom bevezetni. De írták már alább h. egy Terraform az 15 éve létező cucc, van hozzá enterprise support is. Nem jóska bash/python/perl scriptjeiről beszélünk, hanem nagy cégek enterprise termékeiről.

Hozok egy ellenpéldát: a jelenlegi munkahelyemen pontosan ezt hitték h. itt minden milyen rendben van. Aztán kiderült h. van egy /devops mappa az egyik gépen, amiben csöcsül 50db bash script, amit 100-an írtak az utóbbi 10 évben.

Na, pont az ilyenekről ráz a hideg. Régészkedjen, akinek Imre az anyja.

trey @ gépház

Pont erre megoldás az Ansible és társai. H. ezek rendszerbe tudjanak kerülni. Ne a setup-base-system.sh v. rosszabb esetben az alapbeallitasok.cmd legyen a megoldás, hanem egy szépen, deklaratívan leírt valami, ami elvégzi az adott infrához tartozó alapbeállításokat mondjuk az adott gép szerepköre szerint.

A lenti ilyen-olyan forkja az akárminek és az milyen fasza topiccal nem értek egyet, mert előfordulhat h. a shiny new agonyhájpolt szar 1 év múlva nem lesz. De ha kicsit megnézed, akkor RedHat Automation Platform van, aminek van életciklusa, támogatása, minden szarja ami szükséges egy akár nagyvállalati környezetben.

És ezért válaszoltam azt h. elmúlt a nagy hype (mert most az AI hype van, meg cloud hype még tart), de ha megnézed akkor az Ansible köszöni jól van, aki arra használja amire ki lett találva az tök elégedett, a RedHat meg szép profitot csinál belőle. Tehát röviden összefoglalva a nagy hájp után a helyére került.

Tekintve h en ezt ugy ertelmezem (szarkazmus, hangulatkeltes stb) h sehol sincsenek ezek, nem. 
ez volt a felvetes:

“Ezek is mekkorát mentek annak idején ... egy időben nagy buzzword-ök az IT fórumokon ... itt is ... aztán ... <folytasd!>”

Folytattam h koszonik szepen, tok jol uzemelnek ott ahol szukseg van rajuk. 
Ezt probalod mar napok ota cafolni. 

Szuper, akkor vizsgáljuk meg abból a szempontból, hogy egy rendszer ipari standard építőkövekből épül fel, amihez a megbízó kb. bárhol talál hozzáértőt, ha a leszállítójával baj van vs. összetákolt, obskurus izé, aminek a titkait őrzi a szállítója, mert attól függ a megbízása, hogy ő az értője.

Jajj, hagyjuk már, nyilván nem ismeri senkise az ansiblet meg a puppetet. Ne csináljunk már úgy, mintha ezek ne lennének ipari standardok.

Ezek az "összetákolt, obskurus szarok" 10-15-20 éves iparági sztenderdek, felfordítasz egy követ és lesz ott egy csomó IT-s, akiknek a nagy része kurva jól ért ezekhez. Neked csak annyi a bajod, hogy a cégeteknél senki nem ért hozzá, ezért se ti, se az ügyfeleitek nem használják és mivel tudják a piacon, hogy nem értetek hozzá, meg se keresnek titeket ezekkel - lásd selection bias.

Még mindig az a helyzet, hogy téged minősít, hogy ezekről kb. nulla tudásod van és generálisan nem érted az egészet. Hogy kb. big picture értsd, hogy milyen arányokról van szó: https://imgur.com/a/THCIHMi

https://iotguru.cloud

A grafikon azt jelenti, hogy amit te ismersz, az csak egy kerekítési hiba ezen a területen... ettől persze írhatod, hogy obskúrus szar az összes iparági sztenderd CMDB/CMT, de azzal csak magad égeted, hogy mennyire be van szűkülve az IT tudásod... 🤣

🍿

https://iotguru.cloud

most akkor felallt a faszod magadra, hogy a 2000es evekben valami szarszunyok wiindowsos fossal iranyitgattal valamit egy fiszem-faszom magyar kis szarnal? :D

Vmware-bol meg nem kell fejtagito, sot olyanokbol sem amirol te meg csak nem is hallottal (ansible shell scripteket tol le???, rohej vagy), de hatarozott velemenyed van MARINENI, igyal megegyet az ITs afeszkocsmadban es hangoskodj nyugodtan :D

Ó, tesó, nekem IT témára 20+ éve nem áll már fel, az utolsó, amikor IT-s témára felállt 25 évvel ezelőtt történt a 3Dfx-nél. Nekem az IT nem hobbi és az életem, kb. könnyű pénzkereseti forrás. Szóval mellélőttél, nekem ezzel az IT pride-dal, amit levágtok max. a napomat színesítitek. :D

trey @ gépház

Hat ja, Mondjuk nehany dologoban a Tofu mar most elorebb van, mint a Terraform nehany 3-6 eve "nem fogjuk ugyse megcsinalni" issue-ja :D

Gondolom itt is volt valami, hogy valakinek a toke telelett azzal, hogy miert nem csinalnak meg valamit, aztan azt mondta forkolom es majd talan lesz valami. Kivancsian varom mi lesz belole (bar Puppet-et regota nem hasznalunk sehol)

Ne erolkodj, mivel nem ertened. Hogy megvilagitsam egy hasonlattal, te az a kiskutya v agy, aki ugyan nem tud pitizni, nem tud ulni ha mondjak, nagyjabol nem kepes semmire, de ha vakkant egyet, akkor a sajat hangjatol azonnal bepisil a gyonyorusegtol. :D

Amugy elnezest kerek a cegedtol, nem azert nezem le mert magyar kis szirszar ceg, hanem miattad :D