Názory k článku
Vyšel CentOS 8, přináší průběžně aktualizovaný CentOS Stream
-
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. -
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.
-
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.
Nezažil jsem zákazníka, který by chtěl mít v produkci kontejnery za takovou cenu, za jakou by byly spravované z hlediska bezpečnosti srovnatelně. Ony kontejnery značně zrychlují vývoj, deployment, ... - to všechno ano. Odspravovat je je ještě o něco náročnější, než čistou instalaci.
Setkávám se pak s tím, že vývojáři proklamují, jak jsou kontejnery super (eh, mají na ně své dva, tři, pět testovacích přístupů) a jak není potřeba admin, protože vše je hotové jako image. Budiž, do vývoje super věc. V produkci pak najednou nastanou problémy s výkonem, nemožností určitých konfiguračních změn (anebo za cenu neupdatovatelnosti), ...
Je možné, že se to v budoucnu vyřeší, ale to je ještě hodně daleko. Navíc kontejnery v pojetí Linuxu je totální, technicky nekoncepční z nouze ctnost.
-
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.
-
Miroslav SuchýStříbrný podporovatelrolling 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í.
-
Podle oznameni v mailing listu chapu Stream jako nahled na budouci podverze (tedy 8.1, 8.2, ...). "Devitku" by mela "prezentovat" Fedora :)
"It is a cleared-path to contributing into future minor releases of RHEL while interacting with Red Hat and other open source developers. This pairs nicely with the existing contribution path in Fedora for future major releases of RHEL."
-
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.
-
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.
-
Miroslav SuchýStříbrný podporovatel
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.
-
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.
ČLÁNKY DO MAILU