Vlákno názorů k článku
Canonical nabízí placenou 12letou podporu pro Ubuntu 14.04 LTS a novější od bez_přezdívky - Dříve byl normální styl vývoje aplikace takový, že...

Dříve byl normální styl vývoje aplikace takový, že byla stabilní, udržovaná, ale ne příliš vyvíjená větev (ve smyslu zpětné kompatibility), pak byla druhá větev vývojová, ta zase negarantovala tu zpětnou kompatibilitu. A jednou za čas se prostě tato vývojová větev prohlásila za stabilní, přešla do udržovacího režimu a vznikla nová vývojová větev.

Pak se začalo přecházet na styl rolling updates - prostě průběžně aktualizujte. Životní cyklus aktuálních větví se začal zkracovat a narostly tím nároky na administrátory - spravuji, například, Nextcloud - to je co týden nová verze a major verze jsou podporovány jen 12 měsíců. Podobně je na tom Gitlab, OpenShift, webové prohlížeče... Člověk pak nedělá nic jiného, než že plánuje odstávky kvůli údržbě.

Že tento stav začal vadit správcům a žádají delší cyklus podpory je vlastně logické. Ve firmě, kde tyto věci berou vážně, to znamená měsíce plánování a příprav, a pak sse jednoduše může stát, že když dojde na upgrade, tak už se instaluje stará verze místo ještě starší a ta nová je zase v nedohlednu.

Ono to totiž znamená otestovat novou verzi, vyzkoušet upgrade a kompatibilitu v testovacím prostředí, celé to provést ještě jednou v dev (nad ostrou aplikací v testovacím režimu) a až pak se dá plánovat upgrade produkce. A to už jsou klidně 4 měsíce v... A ten Nextcloud nebo OpenShift už vydává další verzi...

Takže je logické, že správci žádají delší podporu, protože současný styl vývoje na ně klade ohromné nároky.

26. 3. 2024, 11:09 editováno autorem komentáře

U Nextcloudu si můžete zaplatit Nextcloud Enterprise a dostanete podstatně delší podporu. Ona totiž ta dlouhodobá podpora není zadarmo. Dřív se tolik neřešila bezpečnost, takže se udělal release, maximálně se tam občas fixnul nějaký nepříjemný bug, ale jinak se to nechalo ležet víceméně ladem. Dnes je údržba čehokoliv podstatně náročnější a když to chce člověk zadarmo, musí se smířit s tím, že to má jinou cenu - časté upgrady.

Nechci zabředávat do konkrétních aplikací, jen uvádím příklad... A vysvětluji proč to zákazníci vyžadují a že jsou ochotni za to zaplatit je jen lepší...

Pokud vím, tak podobné věci nyní řeší i RedHat...

Co takhle použít Docker kontejnery?

A v čem ti to pomůže? Stejně musíš migrovat data, ověřit, že vše funguje, upgradovat monitoring, vše ověřit, zajistit odstávku služby atd. atd.

To částečně řeší problémy... Ale jen částečně. Měl jsem několikrát situaci, kdy se během minor aktualizace aplikace (v kontejneru) změnila verze použité knihovny pro přístup k externí komponentě - třeba Redis, databáze a podobně (není důležité která). A nově použitá verze obsahovala chybu, která se projevila jen za jistých specifických okolností, které nastaly.

Důvod pro přechod na novou verzi dané knihovny nebyl, prostě si to jen vývojáři nepohlídali. NE-kontejnerová varianta bez problémů fungovala i se starší verzí dané knihovny. Chyba se projevila po migraci dat na novou verzi, přičemž downgrade není možný. Kdybych ten upgrade důkladně neotestoval, co bych dělal? Dat tam bylo požehnaně a obnova ze zálohy (kterou jsem měl) by trvala desítky hodin kvůli zajištění konzistence dat.

To mi vůbec nedává smysl. Když se dala použít jedna verze knihovny mimo docker, dala se vyměnit v dockeru.

Aplikace byla distribuována jako balík nebo jako docker image. Mimochodem, extrémně zprasený. Ale furt to byla snadnější cesta, než udržovat instalaci z balíku.

Build vlastního docker image s funkční knihovnou byl pak hrozný voser. Na to jsem se vykašlal, protože by mne museli platit výrazně lépe. Navíc, ztrácíš do jisté míry kompatibilitu s upstreamem. Prostě jsem počkal, až vydají image, který bude obsahovat opravenou verzi knihovny.

u jednoho projektu právě kvůli openshift máme dva týmy souběžně každý přípravuje upgrade na jinou verzi.

Zásadní jsou hlavně jakkékoliv změny, protože to znamená spoustu zásahů do dokumentací, spousty migrací, spousty koordinace s týmy, které to používají.

Také mi to začíná vadit a s láskou vzpomínám na openBSD, škoda, že dnes už v produkci vídám jen pár mohykánů.

S cloudem to je ještě větší problém, oznámení pár měsíců dopředu, že se něco mění a stará verze už nebude. Teď zrovna v týdnu MS PowerBI, skvělé, migrace není podporována, takže se musí napsat proces vlastní.

"S cloudem to je ještě větší problém"

A ve finale zjistis, ze nejpouzivanejsi funkcnost v nove verzi chybi, neni ani nijak jednoduse nahraditelna, a i ty mene pouzivave veci jsou schovane ve 25 urovni dynamicky se menicich obrazkovych nesmyslu. V ramci proaktivniho vyvoje (pripadne dalsi podobny zmrdspeak) se ti pak nove (zcela zpetne nekompatabilni) verze budou rolovat ... treba kazdeho 1/2 roku.

Kdyz vemes zivotni cyklus OS, tak nejmene 2 roky po uvedeni verze je nepouzitelny, plny tristnich bugu, nema smysl ho ani testovat. Teprve pak se v korporatu zacne testovat kompatabilita aplikaci a infrastruktury = nejmene + dalsi 2 roky. A teprve kdyz to vsechno klapne, tak mozna po 5 letech muzes mit +- nasazeno do provozu.

Samozrejme muzes se na to vyprdnout a risknout to ... a dopadnes jak zaslouzis.

A ve výsledku zjistíte, že máte v core aplikaci customizace, které dodavatel té aplikace v nové versi neumí, protože přešel na jinou komponentu, neboť ta stará má po end-of-life a není pro ni náhrada. Takže než někdo kvůli customizacím uvede ještě novější versi, s jinou komponentou, máte ve firmě díky after EOL komponentě i after EOL versi aplikace na after EOL OS a udržujete to na after EOL železe.

Jup, a zjisti se to tyden pred nasazenim te nove verze ... ;D

Našim zákazníkům v tomto v určitých případech pomohly kontejnery, u našich desktopových konkrétně flatpaky. Třeba odvětví animačních studií je hodně rigidní. Tam dodavateli trvá roky vydat software pro novou verzi OS a pak ještě studia zásadně nemění software během produkce filmu, což může být klidně až dva roky. A pak už začínají mít problém zase s podporou hardwaru, protože nové ovladače se do RHELu backportují jen v prvních 5 letech, pak už se jen opravují chyby.

Flatpak jim umožní tu jednu aplikaci, která pořád závisí na RHEL 7, hodit do kontejneru s tímto systémem a oni zatím můžou upgradovat všechno ostatní. V tom kontejneru se to líp spravuje po EOL i z pohled bezpečnosti. Aplikaci se nemusí dát přístup k síti, pokud ho nepotřebuje, omezí se jí přístup do hosta atd...

> customizace, které dodavatel té aplikace v nové versi neumí, protože přešel na jinou komponentu,

A nebo prostě tam původní vývojáři už nepracují, taky běžné. Noví se v tom starém kódu nevyznají.

Trošku ironicky, tá "after EOL" verzia aplikácie an "after EOL" OS (my máme ešte stále cez desiatku RHEL 5.11 a aspoň dvakrát toľko RHEL 6.10 na už asi obstarožnom fyzickom železe) často funguje úplne spoľahlivo (t.j. chýbajúca podpora vlastne nevadí), a s novou sú len samé problémy (staré známe chyby boli nahradené novými, ešte neznámymi). S migráciou je toľko práce, že to nikto nechce schváliť (a dať rozpočet), ale zase z inej časti korporátu frfľú, že sú stále v prevádzke nepodporované verzie, ale tým to skončí.

jedu poměrně dost na upstreamu různých OS a určitě bych to nenazval tristním stavem.

U klientů vidím ale jiný problém a důvod proč to tak dlouho trvá a tak dlouho se čeká. Je tam spousta ruční práce, spousta přezvatých tutoriálů a navodů. Ten kdo systém připravuje zpravidla s tím moc pracovat neumí, je to někdo jiný než ten kdo to dělal před rokem a když nefunguje příkaz z dokumentace, je v koncích, nerozumí tomu, aby našel jiné řešení obratem. Všechno testování je ruční až poloruční, automatizace když už je, tak jen formou dávkových příkazů. V takovémhle prostředí dělat nějaký výraznější upgrade je prostě těžké a trvá to dlouho.

Do toho ještě vstupuje běžný enteprise SW, který se vyznačuje haldou špatně napsaných bash a java scriptů na různé obsluhy, konfigurace a přípravy prostředí, na starty a vypnutí služeb. Zpravidla to má spousty hardcodovaných cest a hodnot, které je potřeba dodržet.

;D ... mam mimo dalsich krasek pod palcem SW, ktery ma konfiguraci zadratovanou pri instalaci, takze ji potom uz nijak normalne nezmenis. K tomu samozrejme dalsi bonus, ze se "aktivuje". Jenze ta verze kterou zakaznik pouziva se uz aktivovat neda. A ted si predstav, ze tohle potrebujes prenyst na jiny OS.

Jako udelal sem to, po tom co sem stravil par mesicu hackovanim ty veci. Ve finale sem to defakto cracknul. Zakaznik chtel, zakaznik mel, ale levny to nebylo. Vyhoda je, ze ted uz se to da vpodstate naprasaka kamkoli zkopirovat ... a neprotestuje to.

Jiste, mohli by nasadit novejsi verzi, jenze ta neumi prave to, co pouzivaji, zato umi spoustu veci, ktere nanic nepotrebuji.

BTW: Kdyz sme u toho, vnstat (najdes bezne v distrech) ... to ve verzi 1x byla trivialni primitivni vec ... spoustena cronem, ktera ti bywoko rekla kolik dat ti tak nejak tece pres iface. Jednoho krasneho dne prisla aktualizace na 2x ... a ja se divil, proc to dop... nefunguje. A ona z toho frikulinska setrvale bezici servisa, delajici vsechno mozne i nemozne, kterou vubec nanic nepotrebuju.

Podotykam ze si samozrjeme to kolo umim napsat sam, ale rikal sem si proc to delat, kdyz to uz nekdo udelal ze ... takze sem bloknul aktualizace a nahodil zpet v1. A toto se deje porad a neustale s vetsinou SW.

Prave du nahodit starou verzi adobe readeru, protoze ta aktuelni me uz se... neustalymi popupy na tema kup si tohle, nebo tamto, tuhle mas uzasny naprosto nesmyslny frikulinsky funkce ...