La quarta versione di OpenShift è stata rilasciata relativamente recentemente. L'attuale versione 4.3 è disponibile dalla fine di gennaio e tutte le modifiche in essa sono o completamente nuove, mai viste nella terza versione, oppure aggiornamenti sostanziali di ciò che era presente nella versione 4.1. Tutto ciò che ora ci accingiamo a raccontare è importante da sapere, comprendere e tenere in considerazione per chi lavora con OpenShift e prevede di passare alla nuova versione.
Con il rilascio della versione OpenShift 4.2, Red Hat ha semplificato il lavoro con Kubernetes. Sono stati introdotti nuovi strumenti e plugin per la creazione di container, pipeline CI/CD e distribuzioni serverless. Queste novità consentono agli sviluppatori di concentrarsi sulla scrittura del codice, piuttosto che su complicazioni relative a Kubernetes.
In sostanza, quali sono le novità nelle versioni OpenShift 4.2 e 4.3?
Verso il cloud ibrido
Nella pianificazione di una nuova infrastruttura IT o nello sviluppo del panorama IT esistente, le aziende considerano sempre più spesso un approccio cloud per fornire risorse IT, realizzando soluzioni cloud private o utilizzando le capacità dei fornitori di cloud pubblici. In questo modo, le moderne infrastrutture IT sono sempre più costruite secondo un modello di cloud "ibrido", che utilizza risorse sia on-premises che pubbliche con un sistema di gestione condiviso. Red Hat OpenShift 4.2 è stato progettato per semplificare la transizione verso un modello di cloud ibrido e consente di connettere facilmente al cluster risorse di fornitori come AWS, Azure e Google Cloud Platform, insieme all'uso di cloud privati su VMware e OpenStack.
Un nuovo approccio all'installazione
Nella quarta versione è cambiato l'approccio all'installazione di OpenShift. Red Hat fornisce uno strumento speciale per distribuire cluster OpenShift: openshift-install. Questo strumento è un unico file binario, scritto in Go. L'installer di OpenShift prepara un file yaml con la configurazione necessaria per la distribuzione.
Nel caso di un'installazione che utilizza risorse cloud, sarà necessario fornire informazioni minime sul futuro cluster: zona DNS, numero di nodi worker, impostazioni specifiche per il fornitore di cloud, dati di accesso per il fornitore di cloud. Dopo la preparazione del file di configurazione, il cluster può essere distribuito con un singolo comando.
In caso di installazione su risorse di calcolo proprie, ad esempio, utilizzando un cloud privato (vSphere e OpenStack sono supportati) o installando su server bare metal, sarà necessaria una configurazione manuale dell'infrastruttura: preparare il numero minimo di macchine virtuali o server fisici necessari per creare un cluster Control Plane, configurare i servizi di rete. Dopo tale configurazione, il cluster OpenShift può essere creato allo stesso modo con un solo comando dello strumento openshift-installer.
Aggiornamenti nell'infrastruttura
Integrazione con CoreOS
L'aggiornamento principale è l'integrazione con Red Hat CoreOS. Ora i nodi master di Red Hat OpenShift possono funzionare solo su un nuovo sistema operativo. Questo è un sistema operativo gratuito di Red Hat, progettato specificamente per soluzioni container. Red Hat CoreOS è una distribuzione Linux leggera, ottimizzata per eseguire container.
Se nella versione 3.11 il sistema operativo e OpenShift esistevano separatamente, nella versione 4.2 sono strettamente collegati a OpenShift. Ora è un appliance unico — infrastruttura immutabile.
Per i cluster che utilizzano RHCOS per tutti i nodi, l'aggiornamento della OpenShift Container Platform è un processo semplice e ben automatizzato.
In passato, per aggiornare OpenShift, era necessario prima aggiornare il sistema operativo di base su cui era in esecuzione il prodotto (all'epoca era Red Hat Enterprise Linux). Solo dopo si potevano aggiornare OpenShift progressivamente, nodo per nodo. Non si parlava affatto di automazione del processo.
Ora, poiché la OpenShift Container Platform controlla completamente i sistemi e i servizi su ogni nodo, incluso il sistema operativo, questo compito si svolge premendo un pulsante dall'interfaccia web. Da lì viene attivato un operatore speciale all'interno del cluster OpenShift, che gestisce l'intero processo di aggiornamento.
Nuovo CSI
In secondo luogo, il nuovo CSI — controllore dell'interfaccia di storage, che consente di collegare diversi sistemi di storage esterni al cluster OpenShift. È supportato un ampio numero di fornitori di driver di storage per OpenShift basati sui driver di storage realizzati dai produttori di sistemi di storage. L'elenco completo dei driver CSI supportati può essere trovato in questo documento: . In questo elenco puoi trovare tutti i principali modelli di array di dischi dei principali produttori (Dell/EMC, IBM, NetApp, Hitachi, HPE, PureStorage), soluzioni SDS (Ceph) e archiviazione cloud (AWS, Azure, Google). OpenShift 4.2 supporta l'uso dei driver CSI secondo la specifica CSI versione 1.1.
RedHat OpenShift Service Mesh
Basato sui progetti Istio, Kiali e Jaeger - Red Hat OpenShift Service Mesh, oltre alla normale funzione di instradamento delle richieste tra i servizi, consente anche il loro tracciamento e visualizzazione. Questo aiuta gli sviluppatori a semplificare l'interazione, il monitoraggio e la gestione dell'applicazione distribuita all'interno di Red Hat OpenShift.
Visualizzazione di un'applicazione con architettura a microservizi utilizzando Kiali
Per semplificare al massimo i processi di installazione, servizio e gestione del ciclo di vita del Service Mesh, Red Hat OpenShift fornisce agli amministratori un operatore speciale: il Service Mesh Operator. Questo è un operatore Kubernetes che consente di distribuire nel cluster pacchetti riconfigurati di Istio, Kiali e Jaeger, alleggerendo al massimo il carico amministrativo nella gestione delle applicazioni.
CRI-O invece di Docker
Il runtime dei contenitori predefinito Docker è stato sostituito da CRI-O. È stato possibile utilizzare CRI-O già nella versione 3.11, ma nella 4.2 è diventato il principale. Non è né buono né cattivo, ma è da tenere presente quando si utilizza il prodotto.
Operatori e distribuzione delle applicazioni
Gli operatori sono una nuova entità per RedHat OpenShift, apparsa nella quarta versione. Questo metodo di imballaggio, distribuzione e gestione delle applicazioni Kubernetes può essere visto come un plugin per le applicazioni distribuite nei contenitori, gestito tramite l'API Kubernetes e gli strumenti kubectl.
Gli operatori Kubernetes aiutano a automatizzare qualsiasi attività legata all'amministrazione e alla gestione del ciclo di vita dell'applicazione che distribuisci nel tuo cluster. Ad esempio, un operatore può automatizzare aggiornamenti, backup e scaling dell'applicazione, modificare la configurazione, ecc. Un elenco completo degli operatori è disponibile su .
OperatorHub è accessibile direttamente dall'interfaccia web della console di gestione. Rappresenta un catalogo di applicazioni per OpenShift, supportato da Red Hat. Tutti gli operatori approvati da Red Hat saranno coperti da supporto vendor.
Portale OperatorHub nella console di gestione OpenShift
Immagine di base universale
Questo è un set standardizzato di immagini del sistema operativo RHEL che puoi utilizzare per creare le tue applicazioni nei contenitori. Ci sono set minimi, standard e completi. Occupano davvero poco spazio, supportano tutti i pacchetti e i linguaggi di programmazione necessari.
Strumenti CI/CD
In RedHat OpenShift 4.2 è stata introdotta la possibilità di scegliere tra Jenkins e OpenShift Pipelines basati su Tekton Pipelines.
OpenShift Pipelines si basa su Tekton, che supporta meglio gli approcci Pipeline as Code e GitOps. Nei pipeline di OpenShift, ogni passaggio viene eseguito in un contenitore dedicato, quindi le risorse vengono utilizzate solo durante l'esecuzione del passaggio. Questo offre agli sviluppatori un controllo totale sui pipeline di consegna dei moduli, sui plugin e sul controllo degli accessi senza un server centrale CI/CD da gestire.
OpenShift Pipelines è attualmente in fase di anteprima per gli sviluppatori ed è disponibile come operatore nel cluster OpenShift 4. Gli utenti di OpenShift possono ovviamente continuare a utilizzare Jenkins in RedHat OpenShift 4.
Aggiornamenti nella gestione per gli sviluppatori
In 4.2 OpenShift ha completamente aggiornato l'interfaccia web sia per gli sviluppatori che per gli amministratori.
Nelle versioni precedenti di OpenShift, si lavorava in tre console: catalogo servizi, console amministratore e console lavoro. Ora il cluster è suddiviso in sole due parti: console amministratore e console sviluppatore.
La console sviluppatore ha ricevuto miglioramenti significativi nell'interfaccia utente. Ora visualizza meglio topologie delle applicazioni e le loro build. Questo rende più facile per gli sviluppatori creare, distribuire e visualizzare applicazioni containerizzate e risorse del cluster. Permette di concentrarsi su ciò che è importante per loro.
Portale sviluppatore nella console di gestione OpenShift
Odo
Odo è uno strumento della riga di comando orientato agli sviluppatori che semplifica lo sviluppo di applicazioni in OpenShift. Utilizzando un'interazione in stile git push, questa CLI aiuta gli sviluppatori che non conoscono Kubernetes a creare applicazioni in OpenShift.
Integrazione con gli ambienti di sviluppo
Ora gli sviluppatori possono creare, debug e distribuire le loro applicazioni in OpenShift senza lasciare il loro ambiente di sviluppo preferito, come Microsoft Visual Studio, JetBrains (compreso IntelliJ), Eclipse Desktop, ecc.
Estensione Red Hat OpenShift Deployment per Microsoft Azure DevOps
È disponibile l'estensione Red Hat OpenShift Deployment per Microsoft Azure DevOps. Gli utenti di questo insieme di strumenti DevOps possono ora distribuire le proprie applicazioni in Azure Red Hat OpenShift o in qualsiasi altro cluster OpenShift direttamente da Microsoft Azure DevOps.
Transizione dalla terza alla quarta versione
Poiché si tratta di un nuovo rilascio e non di un aggiornamento, non è così semplice prendere e installare la quarta versione sopra la terza. L'aggiornamento dalla terza alla quarta versione non sarà supportato.
Ma c'è una buona notizia: Red Hat offre strumenti per migrare i progetti da 3.7 a 4.2. Puoi trasferire i carichi di lavoro delle applicazioni utilizzando lo strumento Cluster Application Migration (CAM). CAM consente di controllare la migrazione e ridurre al minimo il tempo di inattività dell'applicazione.
OpenShift 4.3
Le principali novità descritte in questo articolo sono apparse nella versione 4.2. Nella recentissima 4.3, le modifiche non sono così significative, ma ci sono comunque alcune novità. L'elenco delle modifiche è piuttosto ampio; riportiamo le più significative a nostro avviso:
Aggiornamento della versione di Kubernetes a 1.16.
La versione è stata aggiornata di ben due livelli, mentre in OpenShift 4.2 era 1.14.
Crittografia dei dati in etcd
A partire dalla versione 4.3, è possibile crittografare i dati nel database etcd. Dopo l'attivazione della crittografia, sarà possibile crittografare le seguenti risorse dell'OpenShift API e Kubernetes API: Secrets, ConfigMaps, Routes, token di accesso e autorizzazione OAuth.
Helm
Aggiunta la supporto per Helm versione 3 - un popolare gestore di pacchetti per Kubernetes. Attualmente, il supporto ha lo stato di TECHNOLOGY PREVIEW. Nelle versioni future di OpenShift, il supporto per Helm sarà esteso fino a diventare completo. L'utilità helm cli è fornita insieme a OpenShift e può essere scaricata dalla console web di gestione del cluster.
Aggiornamento del Project Dashboard
Nella nuova versione, il Project Dashboard fornisce informazioni aggiuntive sulla pagina del progetto: stato del progetto, utilizzo delle risorse e domande per il progetto.
Visualizzazione delle vulnerabilità per quay nella console web
Nella console di gestione è stata aggiunta la funzione di visualizzazione delle vulnerabilità note per le immagini nei repository Quay. Sono supportate le vulnerabilità per i repository locali ed esterni.
Semplificata la creazione di operatori offline
Per il caso di distribuzione di un cluster OpenShift in una rete isolata, l'accesso a cui è limitato o assente, è semplificata la creazione di uno "specchio" per il registro di OperatorHub. Ora si potrà fare questo con sole tre comandi.
Autori:
Viktor Puchkov, Yuriy Semyenukov
Fonte: habr.com
