RHEL 9 offre le tecnologie container più recenti per lo sviluppo e la produzione

Tre anni fa, con il rilascio di Red Hat Enterprise Linux 8 (RHEL 8), abbiamo fornito una nuova serie di strumenti per i container sulla base di un concetto inedito che prendeva il nome di "Flussi applicativi". Grazie a questi nuovi strumenti per i container, gli utenti di RHEL avevano la possibilità di trovare, eseguire, creare e condividere container. Per ulteriori informazioni sul motivo del passaggio di RHEL da Docker a Podman (e sul percorso che ci ha condotto a esso), consulta RHEL 8 enables containers with the tools of software craftsmanship. 

Nell'articolo precedente, What's new in Red Hat Enterprise Linux 8.5 Container Tools?, abbiamo presentato molte delle funzionalità e delle caratteristiche di base necessarie per passare a RHEL 9.

Con il rilascio di RHEL 9, continuiamo a offrire i medesimi strumenti per i container basati su Pod Manager (podman), Buildah, Skopeo, Udica, CRIU e altre utility Linux. RHEL 9 continua a tenere fede alla filosofia incentrata sulla fornitura di quello che riteniamo lo strumento migliore per questa attività, semplificando l'upgrade da RHEL 8 a RHEL 9 per gli utenti dei container. Questo articolo presenta in maniera esaustiva le tecnologie più recenti e i cambiamenti nell'integrazione degli strumenti per i container in RHEL 9.

• RHEL 8.6 e RHEL 9.0: cos'è cambiato?

• Gestione centralizzata dei mapping delle identità

• Supporto di NFS per lo storage in container

• Stack di rete avanzato per Podman 4.0

• Certificato portatile e firma del container

• crun diventa il runtime del container predefinito in RHEL 9.0

• Control Group v2 (cgroup 2) diventa l'impostazione predefinita in RHEL 9 e Podman

RHEL 8.6 e RHEL 9.0: cos'è cambiato?

Innanzitutto, partiamo da alcune informazioni di base su RHEL. RHEL 8.6 e RHEL 9.0 sono quelli che vengono definiti "rilasci sincronizzati". Il loro rilascio è avvenuto più o meno contemporaneamente e questa sincronia si manterrà fino a quando RHEL 8 non raggiungerà la versione 8.10 e passerà alla fase di supporto per la manutenzione, mentre RHEL 9 continuerà a ricevere nuove funzionalità. Gli utenti possono così avvalersi di circa due anni di aggiornamenti delle funzionalità su entrambe le piattaforme e di un periodo di tempo per l'upgrade. Il ciclo di vita di RHEL è stato pensato appositamente per rendere più semplice la procedura di upgrade, anche degli strumenti per i container.

Nel grafico riportato di seguito è possibile notare la sincronizzazione delle seguenti versioni di RHEL 8 e 9:

• RHEL 9 Alpha -> RHEL 8.4

• RHEL 9 Beta -> RHEL 8.5

• RHEL 9.0 GA -> RHEL 8.6

• RHEL 9.1 -> RHEL 8.7

• RHEL 9.2 -> RHEL 8.8

• RHEL 9.3 -> RHEL 8.9

• RHEL 9.4 -> RHEL 8.10 

Questa sincronizzazione tra RHEL 8 e 9 semplifica l'esecuzione degli upgrade e si estende anche alle versioni di Podman, Buildah e Skopeo. Proprio così, le stabili e veloci versioni di Podman, Buildah e Skopeo sono allineate tra loro. Ad esempio, la versione più recente di Podman è la medesima tra RHEL 8 e 9:

Su RHEL 8

cat /etc/redhat-release  Red Hat Enterprise Linux release 8.6 (Ootpa) [root@lance ~]# podman --version podman version 4.0.2

Su RHEL 9

cat /etc/redhat-release  Red Hat Enterprise Linux release 9.0 (Plow) podman --version podman version 4.0.2

La sincronizzazione di software importanti come Podman tra le principali versioni di RHEL semplifica l'esecuzione degli upgrade, ma è comunque necessario essere al corrente di alcuni cambiamenti. In RHEL 8.X abbiamo rilasciato due flussi dell'applicazione: uno che consentiva agli sviluppatori di accedere alle versioni più recenti di Podman, Buildah e Skopeo e un secondo flusso stabile che metteva a disposizione dei team operativi un ciclo di vita di supporto di due anni. 

Flussi applicativi RHEL 8

La metodologia utilizzata in RHEL 8 presentava un paio di criticità. Innanzitutto, non abbiamo riscontrato una grande diffusione del flusso stabile, il che ha confutato l'ipotesi iniziale postulata al lancio di RHEL 8. Avevamo introdotto i flussi veloci e stabili in RHEL 8 nella convinzione che gli utenti volessero accedere a un'API container stabile (Podman), continuando a utilizzare i bit dei sistemi operativi più recenti e avanzati (kernel Linux, systemd ecc.). Questo era sempre stato il desiderio correlato ai sistemi operativi containerizzati.

L'ipotesi si è rivelata erronea. Anzi, gli utenti di RHEL volevano principalmente accedere al flusso stabile di strumenti per i container, insieme al supporto prolungato degli aggiornamenti (EUS) della durata di due anni per RHEL nella sua totalità. È venuto fuori che chi si avvale di RHEL desidera accedere a un intero sistema operativo dotato di un ciclo di vita più lungo. Per questo motivo, abbiamo modificato la modalità di rilascio degli strumenti per i container in RHEL 9. 

EUS e flusso dell'applicazione in sequenza di RHEL 9

In RHEL 9, sono disponibili anche due modalità di utilizzo degli strumenti per i container, una incentrata sulla velocità, l'altra sulla stabilità. Gli sviluppatori e gli utenti che vogliono accedere alle versioni più recenti e avanzate di Podman, Buildah e Skopeo possono utilizzare un Flusso applicativo rilasciato anche ogni 12 settimane (proprio come RHEL 8). Per definizione, questo flusso resta sincronizzato con il flusso veloce su RHEL 8 (fino alla versione 8.10, quando lo sviluppo di RHEL 8 subirà una battuta d'arresto), facilitando l'upgrade o il downgrade tra le versioni principali. 

Gli utenti di RHEL 9 che necessitano di un flusso stabile dotato di supporto per due anni con backport di sicurezza possono ottenerlo con il Supporto prolungato degli aggiornamenti (EUS) RHEL, ma questo prevede una sottoscrizione separata. Per definizione, ogni versione degli strumenti per i container nei rilasci EUS di RHEL 9 viene sincronizzata con il flusso stabile corrispondente in RHEL 8. Come già detto, si semplifica l'upgrade da RHEL 8 a RHEL 9, con il mantenimento di una versione coerente di Podman e la riduzione della possibilità di introdurre regressioni.

È importante tenere presente che la distribuzione di RHEL 8 proseguirà esattamente come previsto, senza conversione alla metodologia utilizzata in RHEL 9. Se sviluppatori, amministratori o architetti hanno pianificato una distribuzione di RHEL 8 sulla base di flussi stabili, sarà possibile continuare ad avvalersene senza ricorrere a EUS.

Va, inoltre, considerato che in RHEL 8.6 il modulo container-tools:2.0 è ormai deprecato e che bisogna passare a una versione più recente (3.0, 4.0, ecc.) per continuare a ricevere le patch di sicurezza. Per ulteriori informazioni, consulta la pagina RHEL Application Streams Life Cycle. 

Gestione centralizzata dei mapping delle identità

La tecnologia Rootless Podman è straordinaria. Migliora la sicurezza dei container attraverso un'esecuzione come utente non root, proprio come avviene per i processi ordinari eseguiti su un sistema. Ciò implica che un carico di lavoro con finalità di attacco dovrebbe abbattere un livello di sicurezza in più, superando prima i controlli dei container e trovando poi un metodo per diventare root. È la soluzione ideale per ampie flotte di laptop/desktop, in ambienti HPC, ma anche per gli sviluppatori su server condivisi.

Tuttavia, la gestione di un numero elevato di utenti non root su ampie flotte di workstation RHEL, nodi HPC o server condivisi è sempre stata piuttosto ardua, perché l'amministratore si trovava a dover gestire manualmente file /etc/subuid e /etc/sugid su ogni nodo.

Ora non è più così. Con RHEL 9, abbiamo introdotto nella Gestione delle identità (IdM) una funzionalità che consente agli amministratori di gestire con facilità gli utenti rootless di Podman in una flotta di utenti e nodi RHEL. Gli utenti possono assegnare subUID/subGID a un singolo utente o a tutti gli utenti di un server di directory. È una soluzione davvero pratica. Per ulteriori informazioni, consulta Chapter 29. Managing subID ranges manually.

Supporto di NFS per lo storage in container

Come accennato in precedenza, Rootless Podman è una funzionalità straordinaria e spesso gli amministratori hanno un gran numero di utenti su molti nodi (workstation, HPC, server di sviluppo condivisi e così via). In queste situazioni, gli utenti vogliono portare con sé i propri dati. Ad esempio, se eseguono un "pull podman" su un nodo, desiderano che quell'immagine sia disponibile su tutti i nodi del cluster. Per riuscirci facilmente con i processi normali basta utilizzare NFS, che però tradizionalmente non funzionava con Podman/container.

Grazie a questa nuova funzionalità, Podman è ora in grado di archiviare dati su qualsiasi server NFS che supporti gli attributi estesi (xattrs). Gli utenti non root/rootless possono eseguire l'estrazione dell'immagine una sola volta e utilizzarla ovunque sia disponibile la propria directory home. Si tratta di una funzione estremamente pratica con workstation, nodi HPC o anche server di sviluppo condivisi che si avvalgono di CI/CD. Per ulteriori informazioni, leggi l'articolo upstream: New features for running containers on NFS with rootless Podman 

Stack di rete avanzato per Podman 4.0

Nella versione di RHEL 9 con Podman 4.X, gli utenti dispongono di un nuovo stack di rete, che comprende nuove funzionalità, come un migliore supporto di IPv6, un miglioramento del supporto per i container in più reti e prestazioni migliorate. 

Il seguente articolo ne presenta una panoramica esaustiva: Podman 4.0's new network stack: What you need to know.

Certificato portatile e firma del container

Con il rilascio di RHEL 8.4, abbiamo introdotto UBI Micro, una delle immagini del container più piccole e veloci del settore (Introduction to Red Hat's UBI Micro).

Con il rilascio di RHEL 9, ci siamo avvalsi di questa tecnologia per creare una minuscola immagine del container OpenSSL (12,5 MB), che può essere utilizzata per semplici scenari di utilizzo crittografici, come la creazione di richieste di certificati SSL, la verifica dei certificati SSL o anche la firma di file.

Gli sviluppatori dispongono così di un metodo standardizzato per attuare scenari di utilizzo crittografici affidabili, in produzione o su desktop/laptop. Come per tutte le Red Hat Universal Base Image, insieme ai tuoi sviluppatori, puoi utilizzare e distribuire questo nuovo certificato portatile e firmare il container ovunque necessario.

Per ulteriori informazioni, consulta l'elenco presente nel Red Hat Ecosystem Catalog

• ubi9/openssl 

• ubi8/openssl

crun diventa il runtime dei container predefinito in RHEL 9.0

Nel 2020, i collaboratori di Red Hat hanno introdotto crun, un runtime dei container veloce, con ridotto consumo di memoria e conforme alla OCI. In RHEL 9, abbiamo scelto crun come runtime predefinito dei container. Sia crun che runc saranno supportati per l'intero ciclo di vita di RHEL 9.

Il passaggio a crun come sistema predefinito semplifica molte attività di configurazione di base degli amministratori, migliora le prestazioni e l'utilizzo della memoria e apre la strada a tutti i tipi di scenari di utilizzo più interessanti. Per ulteriori informazioni, consulta: An introduction to crun, a fast and low-memory footprint container runtime

Control Group v2 (cgroup 2) diventa la scelta predefinita in RHEL 9 e Podman

Il progetto cgroup 2 si definisce così: "un componente del kernel Linux che offre un meccanismo per isolare, misurare e controllare la distribuzione delle risorse per una serie di processi su un server". In questo modo, amministratori e software per l'infrastruttura, come motori per container e runtime, possono avvalersi di un efficiente meccanismo di limitazione delle risorse utilizzate da un determinato processo, funzione particolarmente utile con i container. 

Sebbene inizialmente cgroup 2 fosse supportato in RHEL 8, l'utente era costretto ad attivarlo e a eseguire un riavvio. Con RHEL 9, cgroup 2 è il meccanismo predefinito pronto all'uso che offre un controllo più dettagliato sui container rootless (First Look: Rootless Containers and cgroup v2 on Fedora 31). Per un'interessante presentazione di cgroup 2, consulta: World domination with cgroups in RHEL 8: Welcome cgroups v2!

Conclusione

RHEL 9.0 con Podman 4.0.2 presenta molte nuove e incredibili funzionalità per i container, ma molte di esse sono disponibili anche in RHEL 8.6. Che tu preferisca adottare la soluzione più recente e avanzata oppure sfruttare al meglio un'installazione preesistente, la progettazione e l'architettura del flusso applicativo degli strumenti per container soddisfaranno ogni tua esigenza.

Con RHEL 9, continuiamo a consentire un accesso rapido alle versioni più recenti e avanzate di Podman, Buildah e Skopeo, ma ora offriamo anche l'accesso a un flusso stabile tramite EUS. Abbiamo cercato di semplificare ulteriormente l'utilizzo di RHEL 9 per i nostri clienti e ci auguriamo che le novità siano di tuo gradimento. Ci piacerebbe conoscere la tua opinione.

Invia il tuo feedback al nuovo Product Manager per gli strumenti per i container, Mark Russell (https://www.linkedin.com/in/marrusl/), al Product Manager per i server RHEL, Scott McCarty (@fatherlinux), al Technical Marketing Manager, Eric Hendricks (@itguyeric) oppure scrivi al nostro account Twitter ufficiale Red Hat Enterprise Linux, @rhel.