Ecco la strategia di upgrade per gli utenti CentOS 7 raccontata nell’ultimo Red Hat Summit

Come tutti ormai sanno, annunciando la “chiusura” di CentOS ormai a dicembre del 2020, Red Hat aveva indicato delle tempistiche chiare in merito a quando le varie versioni avrebbero cessato di ricevere gli aggiornamenti critici.

CentOS 8 avrebbe visto concludere la sua avventura il 31 dicembre 2021, mentre CentOS 7, la più utilizzata al momento dell’annuncio e quindi quella ad impattare più utenti e datacenter, il 30 giugno del 2024.

Le alternative offerte da Red Hat, per usare un eufemismo, sono state da subito poche: passare a CentOS Stream (che però è una release rolling, inadatta agli ambienti di produzione), oppure passare a Red Hat Enterprise Linux, magari utilizzando qualcuna delle opzioni che consentivano di averne di gratuite rispettando determinati requisiti.

In realtà, come sappiamo, il mercato le alternative se le è create da se, tanto che da subito abbiamo iniziato a seguire i progetti AlmaLinux e Rocky Linux e ne stiamo parlando da parecchio.

Sorprenderà qualcuno quindi leggere dell’annuncio fatto all’ultimo Red Hat Summit 2023 nel quale Gunnar Hellekson, vice president e general manager del prodotto RHEL, ha raccontato di come in Red Hat si siano resi conto che…

It’s actually very difficult to migrate. Read the documentation. It’ll say, in order to move from CentOS to something else, you have to shut the machine down and destroy it and create a new server with your new operating system.

È veramente difficile migrare. Leggete la documentazione. Dirà che per muoversi da CentOS a qualcos’altro bisogna spegnere la macchina, distruggerla e ricreare un nuovo server con il nuovo sistema operativo.

Ora, fermo restando come questa affermazione sia forse vera solo per CentOS 7 (in quanto esistono strumenti come ELevate che consentono migrazioni painless) ed in particolare per gli ambienti cloud, Red Hat conferma di aver pensato a tutto: grazie infatti a Red Hat Enterprise Linux for Third-Party Linux Migration sarà possibile usufruire di una serie di tool per convertire CentOS 7 in RHEL 7 e da lì passare a RHEL 8 o RHEL 9 la cui migrazione verso, a detta di Hellekson, è molto semplice (utilizzando il tool Leapp).

Il tutto consentirà agli utenti di avere ancora altri due anni di supporto, poiché la EOL (End Of Life) di RHEL 7 è appunto più avanzata rispetto a CentOS 7. Inoltre con le varie possibilità offerte dalle subscription gratuite il passaggio potrebbe anche essere gratuito.

Tutto semplice? Tutto pronto? Come racconta TheNewStack, i grandi provider supportano questa mossa, ma ovviamente saranno poi gli utenti a dire quanto successo potrà avere.

Ditelo anche voi: sareste più propensi al passaggio CentOS 7 -> RHEL 7 -> RHEL 8 (o 9) oppure CentOS 7 -> AlmaLinux/Rocky Linux? Due migrazioni in due anni che, almeno sulla carta, dovrebbero filare lisce oppure una migrazione singola con però la necessità di includere degli stop?

Ed a questa domanda se ne aggiunge un’altra, sicuramente più critica: quanti datacenter CentOS 7 ci saranno ancora il 30 luglio 2024?

Da sempre appassionato del mondo open-source e di Linux nel 2009 ho fondato il portale Mia Mamma Usa Linux! per condividere articoli, notizie ed in generale tutto quello che riguarda il mondo del pinguino, con particolare attenzione alle tematiche di interoperabilità, HA e cloud.
E, sì, mia mamma usa Linux dal 2009.

7 risposte a “Ecco la strategia di upgrade per gli utenti CentOS 7 raccontata nell’ultimo Red Hat Summit”

  1. Avatar Massimiliano
    Massimiliano

    CentOS Stream (che però è una release rolling, inadatta agli ambienti di produzione)

    Non sono il top della lingua inglese, ma stream e rolling non mi sembrano sinonimi. CentOS Stream non è una rolling, in quanto i concetti di versione/upgrade/backport esistono.
    Trovo però più interessante il tema dell’inadeguatezza. I casi che conosco direttamente, passati alla versione stream, non hanno riscontrato problemi nei sistemi di produzione. Sarebbe interessante conoscere l’esperienza, e soprattutto il motivo, di chi invece ha avuto problemi con questa versione.

  2. Avatar Massimiliano
    Massimiliano

    Chiamarla “rolling” è forse una semplificazione, ma è anche la realtà dei fatti: non esistono cicli di release, i pacchetti vengono aggiornati senza un ritmo predefinito e senza che ve ne sia un raggruppamento che ne definisca appunto una versione.

    Non capisco cosa intendi per release/versione allora: esistono la 8, 9 etc.

    Questo aspetto ne evidenzia il limite di gestione in ambiti produttivi: non avendo previsioni o aggiornamenti è complicato, se non impossibile, definire delle finestre di gestione degli aggiornamenti dei sistemi stessi né dei livelli generali di compatibilità.

    La compatibilità binaria è garantita a parità di versione con RHEL. Lo affermano loro, non io. Anche perché se infrangessero la compatibilità si romperebbe anche RHEL, che ne è una diretta derivata, di conseguenza anche i cloni.

    Poi per carità, ognuno fa quello che vuole, ma del passaggio a Stream su entità di classe enterprise (quindi entità non da 10 server, ma da1000) non mi risulta ne esistano casi di successo raccontati.

    A me invece risultano, sia per conoscenza personale che casi di adozione interessanti [1]. Non mi risulta invece il contrario, cioè il fallimento, non vuol dire che non sia capitato. La poca storia è forse anche conseguenza del fatto che molti (me compreso) lavorano ormai sempre più sul cloud e meno sul ferro. I grossi clienti che conosco che gestiscono il loro data center erano già su versioni enterprise, quindi la faccenda non li tocca.
    A proposito di cloud, anche AWS sembra gradire, almeno in parte [2].

    Chiaramente sono pronto ad essere smentito.

    Non è questione di essere smentiti, né di far polemica. Semplicemente di ragionare sui fatti. Se qualcuno ha avuto esperienze positive/negative, sarebbe utile conoscerle per farsi un’idea nel valutare pro e contro.

    [1] https://www.slideshare.net/DavideCavalca1/centos-stream-at-facebook
    [2] https://docs.aws.amazon.com/linux/al2023/ug/relationship-to-fedora.html

  3. Avatar Raoul Scarazzini

    Chiamarla “rolling” è forse una semplificazione, ma è anche la realtà dei fatti: non esistono cicli di release, i pacchetti vengono aggiornati senza un ritmo predefinito e senza che ve ne sia un raggruppamento che ne definisca appunto una versione.
    Questo aspetto ne evidenzia il limite di gestione in ambiti produttivi: non avendo previsioni o aggiornamenti è complicato, se non impossibile, definire delle finestre di gestione degli aggiornamenti dei sistemi stessi né dei livelli generali di compatibilità.
    Poi per carità, ognuno fa quello che vuole, ma del passaggio a Stream su entità di classe enterprise (quindi entità non da 10 server, ma da 1000) non mi risulta ne esistano casi di successo raccontati.
    Chiaramente sono pronto ad essere smentito.

  4. Avatar Raoul Scarazzini

    Figurati, nessunissima polemica.
    Red Hat definisce CentOS Stream “the upstream (development) branch of Red Hat Enterprise Linux.” (vedi https://blog.centos.org/2020/12/future-is-centos-stream/ ) e lo fa non a caso, perché Stream è l’anticamera (da testare) di quanto viene incluso nelle release di RHEL.
    A me, per definizione, sembra la cosa più lontana dalla stabilità necessaria in ambienti di produzione. Poi se Facebook ha un team di release che si occupa esclusivamente di gestire gli aggiornamenti (di fatto convertendo da Stream a release la distribuzione) è chiaro che risparmia così. AWS non gradisce per nulla, semplicemente ha una distro sua che gestisce per conto proprio.
    Quindi no, Stream, che non sarà una rolling ma è una development, non è adatta per nulla alla maggioranza degli ambiti di classe enterprise. Anche perché altrimenti tutto il clamore che abbiamo sempre raccontato in merito alla “chiusura” di CentOS, alla creazione di AlmaLinux e Rocky Linux non avrebbe alcuna ragione di esistere…

  5. Avatar Massimiliano
    Massimiliano

    AWS non gradisce per nulla, semplicemente ha una distro sua che gestisce per conto proprio.

    Certo, tutta sua. Poi trovi i bug, identici al bit, di “altri”: ma queste sono illazioni, tutte mie. 😉
    In ogni caso, sono soggetti che sicuramente adottano soluzioni in sistemi altamente stressati e critici, val la pena seguire come si muovono. Non rappresentano di certo l’IT medio.

    Quindi no, Stream, che non sarà una rolling ma è una development, non è adatta per nulla alla maggioranza degli ambiti di classe enterprise.

    Sul concetto di development, come per quello di rolling, andrebbero spese due parole. Per me lo sviluppo è composto da feature in evoluzione, ci sono richieste e cambiamenti a stretto giro. Per questo tipo di sistemi stabili, i cambiamenti sono prevalentemente (se non tutti) riguardanti fix e patch di stabilità, performance e sicurezza. Tutte cose che dovrebbero essere gradite a chi amministra un sistema di base. Inoltre i gestori di pacchetti consentono una selezione mirata delle modifiche da apportare, riducendo ulteriormente i rischi.

    Anche perché altrimenti tutto il clamore che abbiamo sempre raccontato in merito alla “chiusura” di CentOS, alla creazione di AlmaLinux e Rocky Linux non avrebbe alcuna ragione di esistere…

    E magari il polverone è stato un po’ esagerato. Nei miei sondaggi personali, tra chi usava CentOS, qualcuno è passato a CentOS Stream, qualcuno a Ubuntu, e (in un caso) qualcuno ha cominciato a usare anche OpenSUSE per certi scopi. Nessuno ha avuto problemi.
    Mi è parso che, in generale, tutti si siano rivolti ai “nomi noti”, non ho riscontrato successo nei cloni.

  6. Avatar Raoul Scarazzini

    Sarei molto curioso di conoscere la storia di qualche azienda che ha migrato un parco composto da centinaia di macchine CentOS a Ubuntu o OpenSUSE. In particolare di come sono stati gestiti gli inevitabili fermo macchina, le divergenze di librerie o il cambio di package manager.
    Penso sarebbe un eccellente caso di studio.

  7. Avatar Massimiliano
    Massimiliano

    Centinaia penso sia da datacenter di una certa dimensione. Nei casi più “umani” (al più qualche decina) il grosso del lavoro è stato aggiustare i sorgenti IaC (Infrastructure as Code, Ansible va per la maggiore) e pianificare con attenzione gli interventi per area funzionale/layer applicativo. Il “passaggio” a Ubuntu è stato perché era già utilizzata in alcuni ambiti e quindi era una gestione nota. Per quel che ricordo, OpenSUSE è stata usata per la gestione dei cluster K8S (a quanto pare da dei vantaggi).
    Tra virtualizzazione e container, il SO di base tende a essere il minore dei problemi (almeno nell’ambito dell’erogazione di servizi): preoccupano di più il DB (in generale i dati), l’application server ed il linguaggio di programmazione.

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *