La quarta versione di OpenShift è stata rilasciata relativamente di recente. L'attuale versione 4.3 è disponibile dalla fine di gennaio e tutte le modifiche in essa sono o qualcosa di completamente nuovo, assente nella terza versione, oppure un grande aggiornamento di quanto introdotto nella versione 4.1. Tutto ciò che stiamo per condividere è fondamentale da sapere, comprendere e tenere in considerazione per chi lavora con OpenShift e pianifica di passare alla nuova versione.
Con il rilascio della versione OpenShift 4.2, Red Hat ha semplificato l'interazione con Kubernetes. Sono stati introdotti nuovi strumenti e plugin per la creazione di contenitori, pipeline CI/CD e distribuzioni serverless. Le novità consentono agli sviluppatori di concentrarsi sulla scrittura del codice, invece di districarsi con Kubernetes.
Quali sono le novità nelle versioni OpenShift 4.2 e 4.3?
Movimento verso il cloud ibrido
Quando si pianifica una nuova infrastruttura IT o si sviluppa il panorama IT esistente, sempre più aziende considerano l'approccio cloud per fornire risorse IT, implementando soluzioni cloud private o utilizzando la potenza dei fornitori di cloud pubblici. In questo modo, le moderne infrastrutture IT vengono sempre più costruite secondo un modello cloud ibrido, in cui si utilizzano sia risorse on-premises che pubbliche insieme a un sistema di gestione comune. Red Hat OpenShift 4.2 è stato progettato per semplificare la transizione verso un modello di cloud ibrido e consente di collegare facilmente al cluster le risorse di fornitori come AWS, Azure e Google Cloud Platform, insieme all'uso di cloud privati su VMware e OpenStack.
Nuovo approccio all'installazione
Nella quarta versione è cambiato l'approccio all'installazione di OpenShift. Red Hat fornisce un'utilità specifica per il dispiegamento del cluster OpenShift: openshift-install. Questa utilità è un unico file binario scritto in Go. L'installer di OpenShift prepara un file yaml con la configurazione necessaria per il dispiegamento.
In caso di installazione utilizzando risorse cloud, sarà necessario fornire informazioni minime sul futuro cluster: zona DNS, numero di nodi worker, impostazioni specifiche per il fornitore di cloud e dati dell'account per accedere al fornitore cloud. Una volta preparato il file di configurazione, il cluster può essere distribuito con un solo comando.
Nel caso di installazione su risorse computazionali proprie, ad esempio utilizzando un cloud privato (supportati vSphere e OpenStack) 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 il cluster Control Plane e configurare i servizi di rete. Dopo tale configurazione, il cluster OpenShift potrà essere creato con un solo comando dell'utility openshift-installer.
Aggiornamenti nell'infrastruttura
Integrazione con CoreOS
L'aggiornamento chiave è l'integrazione con Red Hat CoreOS. Ora i nodi master di Red Hat OpenShift possono funzionare solo su un nuovo OS. È un sistema operativo gratuito di Red Hat, progettato specificamente per soluzioni container. Red Hat CoreOS è una versione leggera di Linux, ottimizzata per l'esecuzione di container.
Se nella versione 3.11 il sistema operativo e OpenShift esistevano separatamente, nella versione 4.2 sono indissolubilmente legati 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 il prodotto era in esecuzione (all'epoca era Red Hat Enterprise Linux). Solo dopo si poteva aggiornare OpenShift gradualmente, nodo dopo nodo. Non c'era alcuna automazione nel processo.
Ora, poiché la OpenShift Container Platform controlla completamente i sistemi e i servizi su ogni nodo, incluso il sistema operativo, questo compito viene svolto premendo un pulsante nell'interfaccia web. Dopodiché, viene avviato un operatore speciale all'interno del cluster OpenShift, che gestisce l'intero processo di aggiornamento.
Nuovo CSI
Il secondo è un nuovo CSI — un controllore dell'interfaccia di archiviazione che consente di collegare vari sistemi di storage esterni al cluster OpenShift. Supporta un'ampia gamma di provider di driver di storage per OpenShift basati su driver di storage forniti dai produttori di sistemi di archiviazione. Un elenco completo dei driver CSI supportati può essere trovato in questo documento: . In questo elenco sono presenti tutti i principali modelli di array di dischi dei produttori leader (Dell/EMC, IBM, NetApp, Hitachi, HPE, PureStorage), soluzioni SDS (Ceph) e archiviazione cloud (AWS, Azure, Google). OpenShift 4.2 supporta i driver CSI conformi alla specifica CSI versione 1.1.
RedHat OpenShift Service Mesh
Basato sui progetti Istio, Kiali e Jaeger — Red Hat OpenShift Service Mesh, oltre alle normali operazioni di instradamento delle richieste tra i servizi, consente di eseguire 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 di Service Mesh, Red Hat OpenShift fornisce agli amministratori un operatore speciale: il Service Mesh Operator. Si tratta di un operatore Kubernetes che consente di distribuire nel cluster pacchetti riconfigurati di Istio, Kiali e Jaeger, riducendo al minimo il carico amministrativo nella gestione delle applicazioni.
CRI-O invece di Docker
Il runtime dei contenitori predefinito Docker è stato sostituito da CRI-O. CRI-O era già disponibile nella versione 3.11, ma nella 4.2 è diventato il principale. Non è né buono né cattivo, ma è opportuno tenerlo presente nell'utilizzo del prodotto.
Operatori e distribuzione delle applicazioni
Gli operatori sono una nuova entità per Red Hat OpenShift, introdotta nella quarta versione. Si tratta di un metodo di imballaggio, distribuzione e gestione delle applicazioni Kubernetes. Può essere considerato come un plugin gestito tramite l'API Kubernetes e gli strumenti kubectl per le applicazioni distribuite in contenitori.
Gli operatori Kubernetes aiutano ad automatizzare qualsiasi attività legata all'amministrazione e alla gestione del ciclo di vita dell'applicazione che si dispiega nel proprio cluster. Ad esempio, un operatore può automatizzare aggiornamenti, backup e scalabilità dell'applicazione, modificare la configurazione e così via. 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. Ciò significa che tutti gli operatori approvati da Red Hat saranno coperti da supporto da parte del venditore.
Il portale OperatorHub nella console di gestione OpenShift
Immagine base universale
Si tratta di un insieme standardizzato di immagini del sistema operativo RHEL che possono essere utilizzate per creare le proprie applicazioni nei container. Sono disponibili set minimi, standard e completi. Occupano poco spazio e supportano tutti i pacchetti e linguaggi di programmazione necessari.
Strumenti CI/CD
In RedHat OpenShift 4.2 è stata introdotta la possibilità di scegliere tra Jenkins e OpenShift Pipelines basato 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 proprio container, quindi le risorse vengono utilizzate solo durante l'esecuzione del passaggio. Ciò consente agli sviluppatori un controllo completo sui pipeline di consegna dei moduli, plug-in e controllo degli accessi senza un server CI/CD centrale per la gestione.
OpenShift Pipelines è attualmente in fase di anteprima per gli sviluppatori ed è disponibile come operatore nel cluster OpenShift 4. Naturalmente, gli utenti di OpenShift possono continuare a utilizzare Jenkins in RedHat OpenShift 4.
Aggiornamenti nella gestione per gli sviluppatori
In OpenShift 4.2, l'interfaccia web è stata completamente aggiornata sia per gli sviluppatori che per gli amministratori.
Nelle versioni precedenti di OpenShift, tutti lavoravano in tre console: catalogo servizi, console amministratore e console work. Ora il cluster è diviso solo in due parti: console amministratore e console sviluppatore.
La console dello sviluppatore ha ricevuto significativi miglioramenti all'interfaccia utente. Ora visualizza meglio le topologie delle applicazioni e le loro build. Questo facilita agli sviluppatori la creazione, distribuzione e visualizzazione di applicazioni containerizzate e risorse di cluster, consentendo loro di concentrarsi su ciò che è importante.
Portale per sviluppatori nella console di gestione OpenShift
Odo
Odo è un'utilità da riga di comando orientata agli sviluppatori che semplifica lo sviluppo di applicazioni in OpenShift. Utilizzando un'interazione in stile git push, questo CLI aiuta gli sviluppatori che non sono familiari con Kubernetes a creare applicazioni in OpenShift.
Integrazione con ambienti di sviluppo
Gli sviluppatori possono ora creare, eseguire il debug e distribuire le proprie applicazioni in OpenShift senza lasciare il loro ambiente di sviluppo del codice preferito, come Microsoft Visual Studio, JetBrains (incluso IntelliJ), Eclipse Desktop, ecc.
Estensione Red Hat OpenShift Deployment per Microsoft Azure DevOps
È disponibile l'estensione Red Hat OpenShift Deployment per Microsoft Azure DevOps. Ora gli utenti di questo set di strumenti DevOps possono distribuire le proprie applicazioni in Azure Red Hat OpenShift o in qualsiasi altro cluster OpenShift direttamente da Microsoft Azure DevOps.
Passaggio dalla terza versione alla quarta
Poiché si tratta di un nuovo rilascio e non di un semplice aggiornamento, non è possibile semplicemente installare la quarta versione sopra la terza. L'aggiornamento dalla terza alla quarta versione non sarà supportato.
Ma c'è anche una buona notizia: Red Hat offre strumenti per migrare progetti da 3.7 a 4.2. È possibile 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 emerse nella versione 4.2. Nella recentemente rilasciata 4.3, le modifiche non sono così significative, ma ci sono comunque alcune novità. L'elenco delle modifiche è piuttosto ampio, riportiamo le più significative secondo la nostra opinione:
Aggiornamento della versione Kubernetes a 1.16.
La versione è stata aggiornata di due livelli, 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 aver abilitato la crittografia, sarà possibile crittografare le seguenti risorse OpenShift API e Kubernetes API: Secrets, ConfigMaps, Routes, token di accesso e autorizzazione OAuth.
Helm
È stata aggiunta la supporto per Helm 3, un popolare gestore di pacchetti per Kubernetes. Attualmente, il supporto ha lo stato di TECHNOLOGY PREVIEW. Nelle future versioni di OpenShift, il supporto per Helm sarà esteso a una piena implementazione. Lo strumento helm cli è fornito insieme a OpenShift e può essere scaricato dalla Console Web di gestione del cluster.
Aggiornamento del Project Dashboard
Nella nuova versione, il Project Dashboard fornisce informazioni aggiuntive nella pagina del progetto: stato del progetto, utilizzo delle risorse e quote per il progetto.
Visualizzazione delle vulnerabilità per quay nella Console Web
È stata aggiunta alla console di gestione la funzione di visualizzazione delle vulnerabilità note per le immagini nei repository Quay. È supportata la visualizzazione delle vulnerabilità sia per i repository locali che per quelli esterni.
Semplificata la creazione di operatorhub offline
Per i casi di distribuzione di un cluster OpenShift in una rete isolata, in cui l'accesso a Internet è limitato o assente, è stata semplificata la creazione di un "mirror" per il registro OperatorHub. Ora è possibile farlo con sole tre comandi.
Autori:
Victor Puchkov, Yuri Semenyukov
Fonte: habr.com
