Fórumok
https://hup.hu/comment/3158796#comment-3158796
Mivel az eredeti topic trey-es lett, nyitottam egy másikat. Ki mikor, milyen stratégiát választ, melyiket használja és miért?
trey: Értelmes ember implicit evidensnek venné a helyedben, hogy nem szívesen látott vendég itt, neked leírom külön: kérlek, még erre a bejegyzésre se válaszolj.
Mások: Örömteli lenne, ha szakmai vonalon maradna a beszélgetés (ha van egyáltalán mit elmondani).
Hozzászólások
Engem az érdekelne, ha lenne 50000 (érted, ha lenne) gépem, amin át kéne írni a php max file limitet, akkor melyiket kéne választanom! Köszi! Csak komoly válaszokat kérnék, pls.!
trey @ gépház
tanzut!!!!! mert az mar 2000-ben is ment :DDD
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
Semelyiket, mert a kontenerizalt alkalamasodban jol beallitottad. Ugye beallitottad mikor buildelted? 😁
A terraform nem teljesen erre való, szóval az és az opentofu kiesett. De bármelyik, kifejezetten konfiguráció menedzsmentre való eszközt (Puppet, Chef, Ansible...)
Blog | @hron84
via @snq-
uyuni
Fedora 41, Thinkpad x280
hogymi?;)
A Terraformot aktívan használom, főleg Kuberenetes teszt környezetek felhúzására mind felhőben, mind lokál Proxmox clusteren. Nézegettem az OpenTofu-t, egyelőre nincs igényem az áttérésre.
ezt kifejtenéd picit? gondolom a terraform proxmoxon az csak a vm létrehozásig játszik (esetleg cloud-init-tel csomagfelhúzás). utána mi jön?
Gábriel Ákos
mi vegyesen hasznaljuk. van amiben ez a jo, van amiben az. de nagyreszt az infra letrehozas terraformmal, utana puppet+ansible (itt mar az "gyoz" hogy melyikhez van nagyobb kozos tudas)
ennyit a kalapacsrol \o/
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
Nagyvonalakban a következő történik Terraformon keresztül:
Az egészet egy GitHub action füzér vezérli. Kiválasztom melyik service, melyik branch-ét akarom tesztelni, milyen konfiggal és kb 10 perc múlva ott a friss, ropogós environment a tesztelni kívánt módosításokkal. Ha már megy a cluster, de valamelyik komponens frissül, akkor értelemszerűen nem kell az egészet bontani, csak az adott komponens frissül.
Ha már nem kell a környezet, akkor destroy, és kézcsók.
Update: az egészet egy játszós projekthez raktam össze érdeklődésből, mielőtt leszeditek rólam a keresztvizet. Sok mindent lehetne jobban csinálni, de egyedül raktam össze, csak én használom, tökéletesen megfelel. Ha kinövi magát a projekt, lesz hozzáértő, aki megcsinálja rendesen. :D
A feladat határozza meg az eszközt, vagyis a használt automatizációs megoldást. Ehhez jönnek a különböző igények (Muszáj enterprise support legyen hozzá stb.)
Ha megvan a kép akkor derül ki, hogy melyik automatizációs megoldás lesz a megfelelő.
Ha most csak a címben szereplő opciókat nézem, hogy ne legyen elbonyolítva a megoldás azzal, hogy újabb automatizációs megoldásokat hoznék be a képbe.
Jellemzően kisebb cégeknél, ahol nem jelentkezik igény különböző minősítésekre, ill. jogi oldalról nincs megfelelés és belátható időn belül nem is merül fel egyik se, ott szabad a választás.
A nagyobb cégeknél, ahol meg kell felelni különböző elvárásoknak, minősítéseknek, ill. jogi és egyéb szempontból, ott csak az Enterprise vonal jön képbe. Itt így marad a Puppet, Terraform vonal. Hiába tudja ugyanazt kb, mint az Open Source vonal.
A kérdés arra vonatkozik, h melyiket valasztod.
Infrastruktúra kezelés: Terraform, cloud oldalon inkább Crossplane.
Konfiguráció management:
Fizikai gépek és virtuális gépek esetén: Ansible
Kubernetes cluster esetén: Docker, Helm, Kustomize, FluxCD. Ez a toolkit, amivel kikerül az image és a config.
ok, szóval nrwm a Tofut.
Puppet on-premise esetén, Terraform cloud esetén. A fork esetén meg majd meglássuk, egyelőre egy helyen mentünk át OpenTF irányba, mert kellett olyan feature, ami TF esetén nem volt, a Puppet fork még kurva új ahhoz, hogy bármit is lehessen mondani róla.
https://iotguru.cloud
Konfigurációmenedzsment: ansible
Infrastruktúramenedzsment: pulumi
Gábriel Ákos
Miért pulumi?
Gondolom az egyik JS fejleszto kapta meg a Platform Engineer sapkat :-)
Persze. Az egyetlen.
Gábriel Ákos
Terraform licenszváltozás kapcsán kellett valami más, ezt már nézegettem régebben is, megfelelt a(z itthoni) dolgaimnak.
Semmi extra komplikált nincsen, proxmoxra kell feldobálni dolgokat.
Gábriel Ákos
Puppetet régen használtam, de már inkább Ansible és AWX kombó, leginkább provisioningre, persze néhol config check/enforce is játszik, de arra vannak jobb toolok, meg persze más szemlélet, inkább cloud workloadokban gondolkodunk, ahol a konfiguráció nem azt jelenti h. akkor a /etc-ben meghegesztek egy fájlt, szóval ha úgy tetszik akkor a konfigurációmenedzsmentre Git(Lab|Tea|Hub).
Ez a mindent szétforkolunk dolog viszont egyre kevésbé tetszik. Lehet öregszem v. nemtom, de jobban hiszek a konzisztens, régóta működő, supportálható dolgokban, mint a legújabb hájpolt izékben, még ha többet is tudnak. Tisztában vagyok vele h. opensource sajátosság h. évente készül n db új disztró meg új "ansible" meg új kisf.szom, de jobb lenne ha nem töredezne ennyire fel a történet. Kicsit enterpriseabb környezetbe nem eladható h. x,y,z összeálltak és de fasza izét csináltak, akkor használjuk is, mert ha elhangzik a kérdés h. és ki fogja hosszútávon támogatni, akkor arra nehéz megnyugtató választ adni.
hat nekem az ansible kurva lassu. hiaba van ssh controlmaster, mire vegiger egy egyszeru playbookon az is percek. puppet agent meg 4-5 sec alatt csekkollja hogy minden oke. (nyilvan ha matatni kell akkor azert dolgozik)
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
Elvileg a pipelining segítene ezen. Már ha azért lassú, mert folyton be-ki lépked.
... csak hát ezzel nem műkdik a sudo, és ugye egy gépre még az automatizációs megoldás se kéne belépkedjen root-tal.
Blog | @hron84
via @snq-
Igen, nálam sincs bekapcsolva :)
Jo hat almat ne hasonlits a kortevel. Egy push tipusu management tool sose lesz olyan gyors mint egy aminek minden gepen van 0/24-ben futo agentje.
Mindkettonek megvan a maga elonye es hatranya.
Ez tény, de ez adottság ugye a működési modellje miatt.
Ha most azonnal kéne választani, a Ruby-s őrület miatt sztem inkább SaltStack-et választanék. Mármint ha az agent-es megoldás kellene és gyorsítani akarnék.
Na most foleg azt valasztom amire az ugyfelnek igenye van. Legtobbszor van naluk mar valami es ragaszkodnak hozza. Van hogy cserelni akarjak.
Bare metal: a jo oreg pixie es kickstart es neha ansible-pull
Felho: legtobbszor Terraform, OpenTofu, ha multi subscription akkor TerraGruntm, de van hogy CloudFormation vagy AzureRM. Elofordult mar hogy az ugyfel boto-s python stacket adott. Amit visoznt szeretek, ha engedik hogy az ArgoCD CrossPlane-es Claim-eken keresztul managelje a cloud resouce-okat. Tisztabb, szarazabb erzes (masfeledik lepes amikor az ugyfel a crossplane-en keresztul terraform templateket hivogat, de ezt kevesbe szeretem)
K8S: Foleg Helm, ritkan Kustomize, de az is ArgoCD-n keresztul ApplicationSet-ekkel
Konfigmanagement: Attol fugg hogy push vagy pull modelhez ragaszkodik az ugyfel. Ha mehet a push a kozpontbol akkor ansible, ha egy agent pull-ol, akkor Puppet (de mar tenyleg elenyeszo szamu helyen hasznaljuk csak), Chef-be nem kostoltam bele soha, de vannak kollegak akik olyan projekteken vannak ahol az kell
Gabrielakos irta a pulumi-t, azt is mindig meg akartam nezni de sose volt ra idom :D
Na de Terrafrom vagy OpenTofu. A legtobb partnerunknel maradt a TerraaForm bar egyre tobben migralnak Tofu-ra. A fo ok azok a 4-8 eves "azert sem csinaljuk meg" ticketek amik alap kellene legyenek, a Tofu-ban meg javtiva vagy implementalva lettek. A fejlodese is gyorsabb. Most kerult bele ugye a dinamikus provider ami a Terraformban nem lesz es kesz (vagy majd most de), ami miatt mi a legtobb helyen TerraGrunt-ot hasznaltunk eddig. Meg van egy par vegtelenul idegesito bug a TerraFormban (2-3 eves bugok, amikor meg mindig csak a discussion megy), amit a Tofu-sok kurvagyorsan fixaltak.
És most neked áll a cerka magadra, hogy ennyi divatszót sikerült elsütni egy hozzászólásban?
Nem kell a rizsa, hogy én nem értem a felét sem, mert a cipődön száradó kutyaszar is többet tud nálam.
Egy golgota stílusú hozzászólást láthattunk imént.
U.I.: tubikám
nem all a cerka, egyszeruen ennyi mindennel kellett foglalkoznom mert az ugyfelek ezt szerettek volna. En meg abbol elek, hogy leszallitom az ugyfelnek ami kell es nem abbol hogy felszopom hajbit :D
Amugy hogy kicsit okulj is ezek nem divatszavak, hanem termekek. De mondjuk aki beczukott szemmel pippant le masokat, az nem lat ugye :D
Fentebb egy semmire se jo, semmihez sem erto, de masok lepippantasaval megelegedo (es boldogsagban furdo) kiscsiko hozzaszolasat olvashattuk. Kicsi kleine, kleine, kleine, erttem en hogy szeretsz szugyig beolajozott testtel a faszerdoben boldogan sikkangatva szaladgalni, de miert kell ezt mindenki elott? :D
<narrátor mély hangon: tompos fórumtárs által áhított, mélyszakmai szálat olvashat a nagyérdemű, a szálban komolyabb szakmai komment ugyan nincs, de a szemlélődő Teleshop-os TV spot jelleggel értesülhet a 2020-as évek buzzword-jeinek listájáról>
trey @ gépház
Erzesem szerint sulyos gondjaid lehetnek. Pszichiaterhez kene menni, nem a neten kotekedni.
Nekem semmiféle problémám nincs. Prezentáltam hogy golgota milyen módon fórumozik más témákban. Ha ő csinálja máshol az rendben van. Ha én csinálom az ő hozzászólására az nincs rendben. 🤡
-
Sulyos mentalis problemaid vannak, kezeltesd oket.
Semmi divatszo nem volt a hozzaszolasaban, egy normalis vallalati kornyezetben pontosan ezeket hasznaljak igy 2025-ben.
Ezek szerint viszont te valami rendesen lemaradt helyen melozol, gondolom innen van a fusztracio, mert te is erzed hogy lassan piackeptelenne valik a jelenlegi tudasod, es ilyen netes frocsogessel probalod "kezelni" magadban.
En meg a felho reszhez annyit tennek hozza hogy Atlantis, git-tel osszekotve nagyszeruen megvalosithato vele a gitops terraform platform, nalunk nagyon bevalt multi-cloud kornyezetben (AWS+OCI+GCP)
Nekem semmiféle problémám nincs. Prezentáltam hogy golgota milyen módon fórumozik más témákban. Ha ő csinálja máshol az rendben van. Ha én csinálom az ő hozzászólására az nincs rendben. 🤡
Lovesem sincs mirol beszelsz, halistennek nem vagyok itt nagy forumos.
Az eredeti hozzaszolas teljesen szakmai, semmi kivetnivalot nem latok benne, minden amit leirt helytallo, modern es hasznos, nagyjabol manapsag ez egy industry-standard toolset, sot elengedhetetlen olyan helyeken ahol az engineering csapat merete meghaladja az 50 fot, fokepp cloudos kornyezetben.
Azt nem tudtam hogy itt ilyen szemelyes ellentetek vannak. :)
Engem mondjuk az érdekelne, hogy mi a tapasztalat a forkokkal (Puppet vs OpenVox illetve Terraform vs OpenTofu)? Van amiben az újabb jobb? (Azt most vegyük ki a képletből, hogy melyiket miért forkolták - pl mert a korábbi projekt fizetős lett)
Blog | @hron84
via @snq-
OpenTofu fasza, az már bizonyított, a Puppet fork-ból a lófasz se tudja még, hogy mi lesz.
https://iotguru.cloud
De aztan megv ette az IBM es ujra free lett. De amint fentebb is irtam, a Hashicorp egy csomo mindent visszafogott a fejleszteszben olyan technologiai dolgokat, amik nem business related dolgok voltak. Valoszinuleg hogy nyomja a Terraform cloud-ot (HCP), ahol meg csomo minden ment ami a talpas Terraform plan/apply-al nem vagy nehezkes volt. Igy mentek a business feature-ok es maradtak 3-5 eves issue-k meg egy csomora ramondtak, hogy leszarjuk nem csinaljuk meg, majd jon egy ujabb verzio ahol mashogy lesz majd (nem javitva lesz, csak mashogy). A Tofu meg inkabb technikai fejlesztesek es feature-ok menten van goindozva, mivel uzleti erdek nem nagyon van egyelore.
Aztan tegyuk hozza, hogy kijott az 1.10-es Terraform, hogy torjon mindent, de mindent. Semmi nem ment. Eltortek a complex variable-k, azaz minden map, object, list. Csak a sima talpas string, number es boolean nem. Ilyen hibat nem lehet csinalni, senki nem tesztelte egy kibaszott var file-ra? Ne mar. A Tofu-nal meg ilyet nem tapasztaltunk. Miota hasznaljuk nem volt breaking change, illetve mi legalabbis nem futottunk bele.
Most jott ki a tofuban a dynamic (for_each based) provider opcio es a target eseteben az exclude (ami 10+ eves keres a Terraformtol :D)