Te mire migrálsz/migráltál CentOS Linuxról?

AlmaLinux, CentOS, Fedora, Red Hat, Rocky Linux

Ahogy arról már többször volt hír a HUP-on is, a CentOS Linux megszokott formájában megszűnik és CentOS Stream-ként megy tovább. Te mire migrálod meglévő CentOS node-jaidat, vagy egyáltalán migrálod?

Még nem döntöttem el
7% (45 szavazat)
Nem migrálok sehova, használom amíg lehet, akár update-ek nélkül is
4% (27 szavazat)
CentOS Stream-re
5% (32 szavazat)
Red Hat Enterprise Linux-ra
3% (21 szavazat)
AlmaLinux-ra
6% (34 szavazat)
Oracle Linux-ra
6% (34 szavazat)
Rocky Linux-ra
5% (33 szavazat)
OpenSuse-ra
1% (9 szavazat)
Egyéb RHEL klónra
1% (6 szavazat)
Egyéb nem Red Hat alapú disztóra
7% (43 szavazat)
Nem érint a kérdés, nem használtam/használok CentOS-t
54% (334 szavazat)
Összes szavazat: 618

( niceinformation | 2021. 10. 27., sze – 09:56 )

Egyeb: egy rakas centos 6-unk van, zartlancu rendszeren, vilagtol relative elzarva (egy oceanjaro hajon) szoval nem tudjuk odavinni az uj szervert, friss centos streammel, es egy ovatlan pillanatban atkapcsolni az uj rendszerre. Ezen felul pedig nem en dontok az upgraderol sajnos. Ugyhogy meg elorelathatolag 2-4 evig megy a kokanyolas, ganyolas, takolas, homokvar igazgatasa.

Mivel ezek a saját otthoni felhasználású ("hobbi") szervereim, abból sem több, mint jellemzően 3-5 darab (VPS, időnként felhúzok rövid időre 2-3 pluszt, eleve összesen 2 a fix..) egy adott időpillanatban, ezért a vázolt "fájdalom" engem teljes mértékben elkerül.

Tényleg nem látom, hogy a kommentem hol enged százas/ezres nagyságrendű nagyvállalati szerverállományra asszociálni.

A "mert megérdemled" ugyanúgy él. Az, hogy neked csak néhány "játszadozós" géped van, az nem jelenti azt, hogy másnak ne jutna eszébe ez az irány, aminek később lehetnek igen fájdalmas anyagi mellékhatásai is, ezért írtam, amit írtam.

Van-e RH customer portal, illetve Satellite szintű megoldás a patchmanagementhez/inventory-hoz? Van-e a RHEL for Virtual Datacenters (vagy OEL hasonló) supporthoz hasonló lehetőség? És ezeknek az árai hogyan viszonyulnak a RedHat vagy az Oracle OEL árakhoz?

Komolyan kérdezem, hogy tudsz-e Ubuntu-hoz a RH Satellite funkcionalitását hozó megoldást mondani úgy, hogy nem kér a motyó root jogú ssh accountot a gépekre, mert van, ahol szükség lenne ilyesmire.

Lehet így is, persze, csak amikor csillió gépen kell naprakészen tudni, hogy hova, milyen csomag ment ki, hol, milyen advisory-k vannak, amikre reagálni kell (menjen-e ki a csomag vagy sem...), akkor azért jól jön egy portál, ahol midnenre _is_ lehet szűrni a gépek/vm-ek, telepített/telepítendő csomagok kapcsán.

A konténereket is frissíteni kell, ez az egyik, a másik, hogy vmware-re rakott Linux-ra rakott docker konténerbe rakott java... satöbbi. Mire a kód eljut a CPU-ig, elfelejti, mit is akart csinálni :-D
Szép ez a mindent konténerbe irány, mint anno volt a mindent statikusan egybefordítani, aztán a jóég se tudta, hogy adott alkalmazásba épp miből milyen lukas/ócska komponens van begyógyítva.
Persze, lehet_ne_ mindent is konténerezni, de akkor meg a konténerben lévő tartalmat kell frissen tartani, illetve követni, hogy mihez milyen frissítés/javítás jött ki.

De pont erre való a reproducible build. Hogy ha adott egy git tag, abból mindig bitre ugyanaz a szoftver bináris és konténer image essen ki. És igen, kell frissíteni, de azt, hogy mit milyen verzióra frissít, azt szépen el kell tárolni gitben, és a következő CI build legyártja belőle az image-et, amit lehet kitolni a szerverekre.

Nyilván ide el is kell jutni, és nem triviális ezt megcsinálni, de én inkább ennek a kialakításába invesztálnék pénzt mint az akármilyen vendor lock-in patch management eszközbe.

Igen, ez nagyon jó irány, csak egy meglévő infrastruktúrára ezt rátolni nem biztos, hogy olyan egyszerű, pláne akkor, ha záros határidőn belül kell megoldani a sw/hw inventory/patchmanagement kapcsán felmerült kérdéseket - amikben a "hogyan lesz frissítve és egységes verzión tartva a konténer" is egy a sok kérdés közül.

A patchmanagement és a vendor lock-in nem jár kéz-a-kézben, ha és amennyiben adott OS-re vesz az ember (cég) supportot, akkor az már tekinthető vendor lock-in állapotnak, tehát attól, hogy az OS szállítója adja a management/inventory eszközt, azzal nem lesz szűkebb a zsák, amiben táncolni kell :-)

A szopás lényege állandó marad: ha nincs automatizált teszted kb. mindenre is (és hw-közeli dolgokra ugye ez egy elég nehéz dió), akkor vagy vakrepülés jelleggel tolod ki a patcheket automatán, aztán ha beszívtad, csak amolyan microsoftos módra, akkor jön a rollback/reinstall meg a kézi gépészkedés; ha meg van, akkor egészen könnyű a konténeres világ is. És aki ezt a legacy világot tolja, annak általában nincsenek automatizált tesztjei kb. mindenre is.

Ezért van buguntuban autoupdate service, ugye...? Meg is frissítette az openjdk-t rendesen, aztán a wildfly úgy maga alá rosált tőle, hogy öröm volt nézni...
Egyébként meg teszten frissítünk először, majd a tesztelt verziójú(!) csomagok mennek az UAT/prod környezetbe - legalábbis jobb esetben :-P

"Meg is frissítette az openjdk-t rendesen, aztán a wildfly úgy maga alá rosált tőle, hogy öröm volt nézni..."

Az ilyen csomagokat freezelni kell (apt-mark hold), valszeg egy-egy rendszeren csak nehany ilyen jellegu csomagod van amiket ugyis kezzel akarsz frisstieni, a tobbi par szazra meg maradhat az auto update.

Az, hogy alapértelmezetten bekapcsolva jön, az az alapvető probléma egy szervernek szánt OS esetén - szerencsére  tanulva az esetből ez a "nagyszerű" fícsör is, meg az apport is (ami egy-egy nagyobb processz elhasalása esetén a maradék CPU-t és RAM-ot simán fel tudja zabálni) megy nálam a lecsóba, mert mindkét "hasznos" dolog képes agyonvágni a szolgáltatást, amiért az adott kiszolgáló létre lett hozva.

Nem a holdba rakott csomag a megoldás, hanem a nem tervezett"/nem tervezhető frissítés kikapcsolása, és az éles környezetben csak tervezetten módosítani a sw-környezet elemein.

Buguntura 250 dodo/VM/év a support, amiben a fenti motyó benne foglaltatik, DC-re "unlimited" VM-es support árat nem láttam - a másik oldalon a RHEL for Virtual Datacenters van, ami természetesen RHEL-t fed le - de annyit, amennyit az adott virtualizációs platform 2 socketes hardveren elbír, nem pedig darabonként fizetve a VM-ek után.

de nem tok mind1 melyikre mennyi a support? mert a centos juzerek jellemzoen nem vettek eddig sem supportot, igy nem az volt fo a szempont naluk a valtaskor sem.

mas szoval akinek a support fontos az eddig sem centos-t hasznalt, hanem rhel-t es az tudtommal nem szunt meg, tehat oket ez az egesz nem is erinti.

Onnan indult a szál, hogy azt mondtam, hogy a csillió Ubuntu használata lehet problémás, ha olyan audit elvárások vannak, ami naprakész sw/hw inventory, frissítések naplózott elvégzése, és hasonlókat igényel - erre van a Canonical-nak _is_ és a RH-nak is (meg az Oracle-nek is) fizetős megoldása - csak épp az nem mindegy, hogy mennyi az annyi.

Egyébként n+1 helyen láttam/látom azt, hogy dev/tst környezet CentOS, prod (meg esetleg uat) az meg RHEL. Ilyen helyen lehet, hogy érdemes átgondolni vagy a developer subscrition-t (a tényleg dev gépekre), vagy pedig nagy levegőt venni, és a prod (+uat) gépek egyedi supportját leváltani RHEL for Virtual Datacenters licensz(ek)re - ha jellemzően VM-ekben futnak a RHEL-ek. Tehát lehet olyan scenario, ahol CentOS-ról RHEL-re történik a váltás, _és_ az egyedi licenszelésről "kilós"-ra.
Ez akkor játszik igazán, ha VmWare van, mert ha csakmost van gondolkodás virtualizáción, akkor lehet, hogy "kilósan" az OracleVM/OEL jön ki kedvezőbben.

Minek lenne RH customer akármi egy nem RH-s disztróban? Nyilván, ha neked RH-s megoldások kellenek, akkor RH-s vagy azon alapuló disztrók kellenek neked. Kicsit olyasmi, mikor a userek várják el, hogy Linuxra legyenek ugyanazok a windowsos szoftverek. Attól, hogy neked szükséged van ilyesmire, az nem azt jelenti, hogy másnak is. Bőven megvolt a Linux meg a szerverek világa az RH előtt is, meg anélkül is megvan. Pont ez a lényege a Linuxnak, hogy kismillió disztró van, akár sajátot is faraghatsz, nincs az, hogy egy kereskedelmi terméket kell hozzá mindenképp megvenni, vagy vendor-lock-in hatása alatt lenni.

Ezt a szopásfaktort se értem. Ha valakinek kielégíti az igényeit az Ubuntu Server, az miért lenne szopás? Nem hinném, hogy fizetőssé tennék vagy ilyesmi. Félre ne érts, az Ubuntu nekem sem szimpatikus, de amiket felhozol ellene, azok teljesen fals érvek.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Értő olvasás kéne... Azt kérdeztem, hogy van-e olyan, Canoniocal-tól, vagy más, nem Alaszkai halászgyerek one-man-show projektje szintet megütő vendortól származó megoldás, ami adja azokat a szolgáltatásokat, amit a RedHat-os portál.

Tehát naprakész lista a szerverekről, a telepített csomagokról, az adott szervert érintő errata-król/javításokról, az előfizetésem állapotáról és hasonlókról... Igen az Ubuntuhoz van, azonos support level esetén olyan $250/vm/év.

Kézzel meg scripthalmazokkal lehet bohóckodni, meg akár jól is üzemelteni szervereket, de amikor a fenti információkra naprakészen van szükséged, és mondjuk van ~200VM-ed meg további ~15-20 fizikai géped, akkor erősen vértpisálós meló összevakarni ezt (pláne ha a vm-ek n+1 vcenterben meg standalone esxi-n találhatóak...)

 

Ha nagyvallalati kornyezetben hasznalsz valamit, esetleg beepited a sajat termekedbe, es profi supportra van szukseged, az mindenkepp draga lesz. Az ilyen esetekben fontosabb, hogy az adott vendor mennyire stabil, megbizhato, atlathato, hogyan sujtja export kontroll stb.

Otthonra es kis barkacs megoldasok eseten pedig hitvita a dolog, amibe nem erdemes belefolyni...

( haramia | 2021. 10. 28., cs – 00:20 )

Én arra volnék kíváncsi, hogy aki AlmaLinux-ra migrált, az miért amellett döntött a Rocky-val szemben. Én eredetileg Oracle-re álltam át egy gépemmel, amin már CentOS 8 volt és nem volt fix, hogy mikor lesz alternatíva, de 8.4 óta boldog Rocky felhasználó vagyok.

Még nem csináltam meg a migrációt, de a tervek szerint Alma lesz. Sokat vacilláltam és a következők miatt döntöttem mellette:

- Sokkal hamarabb jelent meg mint a Rocky. Ezt a jó szokását remélem megtartja és nem kell sokat várni a frissítésekre.

- Van mögötte egy nagyobb(acska) cég ami korábban is ezzel foglalkozott, azaz nem egy one man show amiből ha elfogy a kezdeti lelkesedés/lendület akkor nagyon csúnyán le tud ülni.

- A Rocky-t - ha jól tudom - az csinálja aki a CentOS-t is elkezdte - vagy valami hasonló. Szóval tapasztalata van, de el is adta/kilépett amikor már nagyra nőtt. Még mielőtt valaki belekötne, ezzel nincs semmi baj, a zsíros kenyér sincs ingyen, de nem szerettem volna ismét ugyanazt a táncot eljárni a jövőben mint most.

- Oracle Linuxot nem akartam. Az Oracle-ben sosem bíztam, de ha nem lett volna Alma és Rocky akkor persze OEL lett volna a szerencsés kiválasztott.

Ha meg esetleg rossz lóra tettem akkor remélhetőleg a jövőben egyszerűen lehet majd váltani a disztribúciók között, hiszen - elvileg - mindegyik binárisan kompatibilis az adott RHEL-el.

Ami nagy köcsögség volt az IBM-től/RedHat-tól hogy ha nem tudták volna fenntartani magát a CentOS-t - amit kétlek, de az ő pénzük, az ő döntésük hogy mire költik - akkor miért nem csináltak egy új CentOS Foundation-t? Tolnak alá némi vasat ami nekik fillérekből megvan, kapnak vele némi jó PR-t és leírják az adóból mint jótékonykodást. A jövőben meg önkéntesek csinálják azt amiért eddig egy csomó pénzt fizettek az alkalmazottaknak. Ha meg idővel bedől akkor meg nem őket fogja mindenki csesztetni.

( csabka v | 2021. 10. 28., cs – 08:12 )

Szerkesztve: 2021. 10. 28., cs – 08:13

SaltStack pl kiválóan alkalmas tömeges Ubuntu patch menedzsmentre... Ha nem akar az ember Ansible +AWX - el ssh n keresztül menedzselni... 

Mind a kettő ingyen is van...ráadásul az auditor ok szeretik (saját tapasztalat) őket ha vannak főleg ha git forrásból nevesített használókkal követhetőn, hálózatilag persze biztonságosan. 

Persze ezek működtek RHEL/OL/CentOS ra is :) 

Amúgy Satelite mögött is ilyen van (puppet).