Vyšel CentOS 8, přináší průběžně aktualizovaný CentOS Stream

Přiznám se, že nevím, jaký je přesně smysl rolling verze CentOSu. K důležitým požadavkům na serverovou distribuci je být dlouhodobě stabilní, kontejnery nebo cloud na tom nic nemění. Možná to může být užitečné pro vývojáře cloudových aplikací, nebo jak se dneska módně říká, DevOps?

Otázka je, jestli je toto právě místo pro RHEL resp. CentOS. Jejich jedinou devízou je právě to, že do Linuxu vnesli stabilitu enterprisové úrovně.

Na druhou stranu je pravda, že to se dodržuje hlavně u RHEL - když už tam člověk platí velké peníze za podporu, nepřipraví se o ni jen kvůli touze po novější verzi jednoho balíku.

Na třetí stranu, tu samou ukázněnost rozhodně nemají uživatelé CentOSU. Tam je poměrně běžné, že admin distribuci hned po instalaci cinkne repem z Fedory nebo i jiného zdroje, čímž efektivně pohřbí jakékoliv výhody zrovna této distribuce. Je to mimochodem hezký příllad z praxe, jak velký rozdíl v chování způsobí školení admina, podpora výrobce vs. komunitní přístup.

Podle mě to povede k odtržení CentOSU od RHEL, ještě méně adminů bude ochotno používat OS tak, jak je výrbcem daný a de facto podporovaný. CentOS získá aspoň nepřesné statistiky, kolik %% uživatelů ho používá tak, jak byl myšlen, a kolik si ho cinkne. Když si uživatelé přidali repa z Fedory, CentOS věděl prd. (Tj. hledal bych za tím politiku firmu).

To je právě ta logika, která mi trochu uniká. Kdybych byl vývojář nějaké korporátní aplikace, tak bych asi chtěl mít vývojovou platformu, která se co nejvíc podobá té, na které to pojede naostro - tj. RHEL, který se neaktualizuje každé dva dny. To je ideální využití pro CentOS, ale když ho používám v rolling režimu, tak je to celé v P****.

Rolling release v podani CentOS si nepredstavuj jako Gentoo :) Proste to bude stream ktery se obcas updatne. Napriklad kdyz vyjde nove Gnome. Ale bude to jednou za cas a musi to asi projit Fedorou. Nebude tam ABI kompatibilita.

Da se to prirovnat k EPELu kde by se sice nemely baliky povysovat ale v realu k tomu dochazelo porad. Udrzet komunitu na uzde u distra s 10letou podporou je nemozne. Osobne to vnimam jako super napad.
Napriklad jako OS pro pracovni stanici.

Jinak pracuju na projektu ktery je pro RHEL ale vyvoj jede na Fedore. Tam tu stabilitu a ABI nepotrebuju. Jakmile se ale dela nova vere vse se pohcopitelne na RHELu a CentOSu testuje. Ani tak nezalezi na vyvojarovne OS jako na tom jak se vse testuje.

zapomínáš na to, že dnešní korporáty (aspoň v českém prostředí) docela migrují z RHEL na třeba OracleLinuxu, už ani CentOS v produkci není ničím novým. Tendence agilního přístup (a agilních týmů) vede k odstraňování zkušených adminů, kteří jsou nahrazeny vývojáři, kteří hledají pouze funkční řešení a nikoliv bezpečnú, udržovatelné, dokumentovatelné, spravovatelné atd.

RHEL je tímhle nejspíš vysoce ovlivněný a CentOS jde v jejich šlépějích. V době kontejnerů najít dneska zkušenějšího admina na linux v korporátech je poměrně nesnadné hledání.

Domnívám se (ale možná se pletu), že Oracle Linux je v podstatě rebuild RHEL neboli něco jako CentOS. S těmi adminy je to spíš tak, že dnešní korporáti je už nepotřebují. Je zajímá software, ne RHEL jako takový, a na to software si na AWS, Azuru apod. naklikají, kolik kontejnerů nebo virtuálních strojů potřebují, ty jsou předem vendorem nastavené tak, aby fungovaly, a víc se o to nemusí starat. Jenže i tak je potřeba, aby tyto kontejnery atd. byly dlouhodobě stabilní, takže obden tam cpát novou verzi libssl nebo nějaký bleeding edge Go runtime přímo z gitu je opravdu koledování si o průser.

Ve všech firmách s 5+ vývojáři, kde jsem za poslední roky pracoval, byl vždycky někdo, kdo se věnoval primárně infrastruktuře. Ta infrastruktura se proti kódu moc nemění. Nasadí se Kubernetes, do něj se deployují kontejnery vybuilděné v nějakém CI a na tom to končí. Není to tak, že by s každou novou verzí bylo potřeba přepracovat infrastrukturu. Neřekl bych, že se odstraňují zkušení admini, ale věřím, že ti co moc bojují proti kontejnerům a obecně změnám na serverech i v procesech, se nakonec odstraní sami.

Problem se zkusenymi se netyka jen adminu. Dokud korporat bota netlaci, tak se nic neresi, protoze to zbytecne zatezuje rozpocet. Zazil jsem opakovane jak pri sebelepsim smoulovani kontejnerovane aplikace v produkci a pod velkou zatezi "nejak nestihaly", a nasledne jak progresivni-nezkuseni razem jihli anebo to rovnou svadeli na pomale disky nebo javu nebo postgres/oracle nebo cassandru nebo cokoliv co pod tim meli. Vyresit to musel az nejaky neprogresivni koren, ktery kaslal na moderni PR nesmysly, ale zato rozumel full-stack problematice. To je ovsem spravne!

Psani kodu a jeho zakladni deployment je jen obycejne hazeni lopatou, a na to skutecne staci jen povrchni znalosti algoritmu, par nejakych API a zuzeny pohled na vyuzivane technologie. Proc nenechat par nadsencu generovat jakys-takys kod v domneni, ze delaji strasne moderni veci? Neskutecne to setri naklady a vetsina takovych aplikaci stejne nikdy nedojde az ke svym limitum, aby to musel nekdo dodatecne "resit". Takze proto je hledani kohokoliv zkusenejsiho v korporatech (a nejenom tam) nesnadne, ale je to jen logicky dusledek toho jak moderni IT funguje.

Mam k produkcnym centosom pridany EPEL lebo ack, htop a monit.
Nemyslim si ze moj produkcny centos je preto menej konzervativne stabilny.

Normální produkční Centos určitě není méně stabilní. Tady šlo o to jejich nové rolling vydání: rolling CentOS mi připadá jako oxymoron.

rolling CentOS má sloužit jako developer preview budoucího RHELu. Budete vědět, co se chystá do nového RHELu/CentOSu. Protože pokud dneska chcete vyvíjet pro nový RHEL. Dejme tomu pro RHEL 9, tak dneska je vaší jedinou možností stavět nad Fedorou, která je pro korporátní vývoj hodně rychlá. Druhá možnost je čekat na vydání RHEL 9 a pak ještě na vydání CentOS 9 a pak začít vyvíjet. Tou dobou už vás někdo převálcuje. Stream CentOS vám umožní vyvíjet a buildit vaši aplikaci pro budoucí RHEL/CentOS tak, že pro vás nová verze nebude tak velké překvapení a můžete být s vaší aplikací nachystaní už v den jeho vydání.

Třeba zrovna u PHPka je toto problém, protože PHP aplikace se vyvíjejí celkem rychlým tempem a verze PHP, která je v CentOSu rychle zastarává. Bez http://rpms.remirepo.net/ bych na tom byl celkem blbě.

I Apache co je v CentOSu 7 je dneska celkem zastaralý, protože nepodporuje deska modení http2, ale s tím se dá ještě vyžít.

O tom mluvím výše. Podle mě je na takový use case RHEL a potažmo i CentOS od počátku nevhodná distribuce. Jediná výhoda obou je právě konzervativní přístup doplněný o enterprise podporu od RedHatu, který ručí za to, že ty staré verze podporuje svým jménem i po skončení podpory vendora.

RHEL 7 tohle řešil pomocí SCL (https://www.softwarecollections.org/en/scls/?search=php). RHEL 8 tohle řeší pomocí modulů (yum module list) a umožňuje si vybrat jakou verzi jazyka nebo databáze chcete.

Tak ještě čekám na naplnění epel repozitáře a může se jít testovat. :)

Asi to je skor otazka na centos team, ale ako je to s upgrade centos 7.6 na centos 8?
Navody som videl len pre RHEL a v podminkach bol pristup do plateneho repozitara a instalacia leapp balicka.

https://www.itzgeek.com/how-tos/linux/centos-how-tos/how-to-upgrade-from-rhel-7-to-rhel-8.html

To určitě funguje na RHEL. Jestli je to součástí CentOSu nevím.

leapp je asi v rhel-7-server-extras-rpms repo, lebo yum info leapp na centos-7.7 pise Error: No matching Packages to list

rhel-7-server-extras-rpms contains leapp for upgrade CentOS 7 to 8. Will CentOS extras provide leapp?

There are no plans for the CentOS core team to support or package leapp but if there is sufficient support from the community to provide copies amended for CentOS then they could be released as part of a SIG. However, given the current lack of support for the preupgrade tool to migrate from CentOS 6 to 7 and the total lack of response to all calls for volunteers to package that, I would not be optimistic about it happening.

https://bugs.centos.org/view.php?id=16116

No ja teda zustanu u CentOS bez privlastku :) Ten system jsem si porizoval kvuli tomu, ze ma extra dlouhou podporu a proste funguje.

Na server taky zůstanu u standartního CentOSu, ale na malinu až tam bude podpora uvažuju, že požiju tu stream verzi