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 contenute sono qualcosa di completamente nuovo che non era presente nella terza versione, oppure un aggiornamento importante di quanto apparso nella versione 4.1. Tutto quello che ti diremo ora deve essere conosciuto, compreso e preso in considerazione da chi lavora con OpenShift e ha intenzione di passare ad una nuova versione.
Con il rilascio di OpenShift 4.2, Red Hat ha reso più semplice il lavoro con Kubernetes. Sono comparsi nuovi strumenti e plugin per la creazione di contenitori, pipeline CI/CD e distribuzioni serverless. Le innovazioni offrono agli sviluppatori l'opportunità di concentrarsi sulla scrittura del codice e non sulla gestione di Kubernetes.
In realtà, cosa c'è di nuovo nelle versioni di OpenShift 4.2 e 4.3?
Verso i cloud ibridi
Quando si pianifica una nuova infrastruttura IT o quando si sviluppa un panorama IT esistente, le aziende prendono sempre più in considerazione un approccio cloud per la fornitura di risorse IT, per la quale implementano soluzioni cloud private o sfruttano la potenza dei fornitori di cloud pubblici. Pertanto, le moderne infrastrutture IT vengono sempre più costruite secondo un modello di cloud “ibrido”, in cui vengono utilizzate sia risorse on-premise che risorse di cloud pubblico con un sistema di gestione comune. Red Hat OpenShift 4.2 è appositamente progettato per semplificare la transizione verso un modello di cloud ibrido e semplifica la connessione delle risorse di provider come AWS, Azure e Google Cloud Platform al cluster, oltre all'utilizzo di cloud privati su VMware e OpenStack.
Nuovo approccio all'installazione
Nella versione 4, l'approccio all'installazione di OpenShift è cambiato. Red Hat fornisce un'utilità speciale per la distribuzione di un cluster OpenShift: openshift-install. L'utilità è un singolo file binario scritto in Go. Openshit-installer prepara un file yaml con la configurazione richiesta per la distribuzione.
In caso di installazione utilizzando risorse cloud, sarà necessario specificare informazioni minime sul futuro cluster: zona DNS, numero di nodi di lavoro, impostazioni specifiche per il provider cloud, informazioni sull'account per l'accesso al provider cloud. Dopo aver preparato il file di configurazione, il cluster può essere distribuito con un comando.
In caso di installazione sulle proprie risorse informatiche, ad esempio, quando si utilizza un cloud privato (sono supportati vSphere e OpenStack) o quando si installa su server bare metal, sarà necessario configurare manualmente l'infrastruttura - preparare il numero minimo di macchine virtuali o server fisici necessari per creare un cluster Control Plane e configurare i servizi di rete. Dopo questa configurazione, è possibile creare in modo simile un cluster OpenShift con un comando dell'utilità openshift-installer.
Aggiornamenti dell'infrastruttura
Integrazione CoreOS
L'aggiornamento chiave è l'integrazione con Red Hat CoreOS. I nodi master Red Hat OpenShift ora possono funzionare solo sul nuovo sistema operativo. Si tratta di un sistema operativo gratuito di Red Hat progettato specificamente per soluzioni container. Red Hat CoreOS è un Linux leggero ottimizzato per l'esecuzione di contenitori.
Se nella versione 3.11 il sistema operativo e OpenShift esistevano separatamente, nella versione 4.2 è inestricabilmente collegato con OpenShift. Ora si tratta di un unico dispositivo: un'infrastruttura immutabile.
Per i cluster che utilizzano RHCOS per tutti i nodi, l'aggiornamento di OpenShift Container Platform è un processo semplice e altamente automatizzato.
In precedenza, per aggiornare OpenShift, era necessario prima aggiornare il sistema operativo sottostante su cui era in esecuzione il prodotto (all'epoca, Red Hat Enterprise Linux). Solo allora OpenShift potrà essere aggiornato gradualmente, nodo per nodo. Non si è parlato di automazione del processo.
Ora, poiché la OpenShift Container Platform controlla completamente i sistemi e i servizi su ciascun nodo, compreso il sistema operativo, questo compito viene risolto premendo un pulsante dall'interfaccia web. Successivamente, all'interno del cluster OpenShift viene avviato un operatore speciale che controlla l'intero processo di aggiornamento.
Nuovo CSI
In secondo luogo, il nuovo CSI è un controller di interfaccia di archiviazione che consente di connettere vari sistemi di archiviazione esterni al cluster OpenShift. Sono supportati numerosi fornitori di driver di archiviazione per OpenShift in base a driver di archiviazione scritti dagli stessi produttori di sistemi di archiviazione. Un elenco completo dei driver CSI supportati è disponibile in questo documento: . In questo elenco puoi trovare tutti i principali modelli di disk array dei principali produttori (Dell/EMC, IBM, NetApp, Hitachi, HPE, PureStorage), soluzioni SDS (Ceph) e cloud storage (AWS, Azure, Google). OpenShift 4.2 supporta i driver CSI della specifica CSI versione 1.1.
Rete di servizi RedHat OpenShift
Basato sui progetti Istio, Kiali e Jaeger, Red Hat OpenShift Service Mesh, oltre ai consueti compiti di instradamento delle richieste tra servizi, ne consente il tracciamento e la visualizzazione. Ciò aiuta gli sviluppatori a comunicare, monitorare e gestire facilmente un'applicazione distribuita all'interno di Red Hat OpenShift.
Visualizzazione di un'applicazione avente un'architettura a microservizi utilizzando Kiali
Per semplificare il più possibile l'installazione, la manutenzione e la gestione del ciclo di vita di Service Mesh, Red Hat OpenShift fornisce agli amministratori un operatore speciale, Service Mesh Operator. Si tratta di un operatore Kubernetes che consente di distribuire pacchetti Istio, Kiali e Jaeger riconfigurati su un cluster, massimizzando il carico amministrativo della gestione delle applicazioni.
CRI-O invece di Docker
Il runtime del contenitore predefinito Docker è stato sostituito da CRI-O. Era possibile utilizzare CRI-O già nella versione 3.11, ma nella 4.2 è diventato quello principale. Non buono o cattivo, ma qualcosa da tenere a mente quando si utilizza il prodotto.
Operatori e distribuzione delle applicazioni
Gli operatori sono una nuova entità per RedHat OpenShift, apparsa nella quarta versione. È un metodo per creare pacchetti, distribuire e gestire un'applicazione Kubernetes. Può essere pensato come un plugin per applicazioni distribuite in contenitori, guidato dall'API Kubernetes e dagli strumenti kubectl.
Gli operatori Kubernetes aiutano ad automatizzare qualsiasi attività relativa all'amministrazione e alla gestione del ciclo di vita dell'applicazione distribuita nel tuo cluster. Ad esempio, l'operatore può automatizzare aggiornamenti, backup e ridimensionamento dell'applicazione, modificare la configurazione, ecc. L'elenco completo degli operatori è reperibile all'indirizzo .
OperatorHub è accessibile direttamente dall'interfaccia web della console di gestione. È una directory dell'applicazione per OpenShift gestita da Red Hat. Quelli. tutti gli operatori approvati da Red Hat saranno coperti dal supporto del fornitore.
Portale OperatorHub nella console di gestione OpenShift
Immagine di base universale
Si tratta di un set standardizzato di immagini del sistema operativo RHEL che può essere utilizzato per creare applicazioni containerizzate. Esistono set minimi, standard e completi. Occupano pochissimo spazio e supportano tutti i pacchetti installati e i linguaggi di programmazione necessari.
Strumenti CI/CD
In RedHat OpenShif 4.2, è diventato possibile scegliere tra Jenkins e OpenShift Pipelines basate su Tekton Pipelines.
OpenShift Pipelines è basato su Tekton, che è meglio supportato da Pipeline con l'avvicinarsi di Code e GitOps. Nelle pipeline OpenShift, ogni passaggio viene eseguito nel proprio contenitore, quindi le risorse vengono utilizzate solo durante l'esecuzione del passaggio. Ciò offre agli sviluppatori il controllo completo sulle pipeline di distribuzione dei moduli, sui plug-in e sul controllo degli accessi senza un server CI/CD centrale da gestire.
OpenShift Pipelines è attualmente in anteprima per sviluppatori ed è disponibile come operatore su un cluster OpenShift 4. Naturalmente, gli utenti OpenShift possono ancora utilizzare Jenkins su RedHat OpenShift 4.
Aggiornamenti sulla gestione degli sviluppatori
Nella versione 4.2 OpenShift, l'interfaccia web è stata completamente aggiornata sia per gli sviluppatori che per gli amministratori.
Nelle versioni precedenti di OpenShift, tutti lavoravano su tre console: directory del servizio, console di amministrazione e console di lavoro. Ora il cluster è diviso solo in due parti: console amministratore e console sviluppatore.
La Console per gli sviluppatori ha ricevuto miglioramenti significativi all'interfaccia utente. Ora visualizza in modo più conveniente le topologie delle applicazioni e dei relativi assembly. Ciò rende più semplice per gli sviluppatori creare, distribuire e visualizzare applicazioni containerizzate e risorse in cluster. Permette loro di concentrarsi su ciò che è importante per loro.
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 la comunicazione in stile git push, questa CLI aiuta gli sviluppatori che non conoscono 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 proprio 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
È stata rilasciata l'estensione Red Hat OpenShift Deployment per Microsoft Azure DevOps. Gli utenti di questo set di strumenti DevOps possono ora distribuire le proprie applicazioni su Azure Red Hat OpenShift o su qualsiasi altro cluster OpenShift direttamente da Microsoft Azure DevOps.
Passaggio dalla terza versione alla quarta
Dato che stiamo parlando di una nuova versione e non di un aggiornamento, non puoi semplicemente mettere la quarta versione sopra la terza. L'aggiornamento dalla versione XNUMX alla versione XNUMX non sarà supportato..
Ma c'è una buona notizia: Red Hat fornisce strumenti per la migrazione dei progetti dalla versione 3.7 alla versione 4.2. È possibile migrare i carichi di lavoro delle applicazioni utilizzando lo strumento Cluster Application Migration (CAM). CAM consente di controllare la migrazione e ridurre al minimo i tempi di inattività delle applicazioni.
turno aperto 4.3
Le principali innovazioni descritte in questo articolo sono apparse nella versione 4.2. Le modifiche apportate di recente alla versione 4.3 non sono così grandi, ma ci sono ancora alcune novità. L’elenco delle modifiche è piuttosto ampio, ecco le più significative a nostro avviso:
Aggiorna la versione di Kubernetes alla 1.16.
La versione è stata aggiornata due volte contemporaneamente; in OpenShift 4.2 era la 1.14.
Crittografia dei dati in etcd
A partire dalla versione 4.3 è diventato possibile crittografare i dati nel database etcd. Una volta abilitata la crittografia, sarà possibile crittografare le seguenti risorse API OpenShift e API Kubernetes: segreti, ConfigMap, percorsi, token di accesso e autorizzazione OAuth.
Casco
Aggiunto il supporto per Helm versione 3, un popolare gestore di pacchetti per Kubernetes. Per ora il supporto ha lo status TECHNOLOGY PREVIEW. Il supporto del timone verrà esteso al supporto completo nelle versioni future di OpenShift. L'utilità helm cli viene fornita con OpenShift e può essere scaricata dalla console Web di gestione del cluster.
Aggiornamento della dashboard del progetto
Nella nuova versione, Project Dashboard fornisce informazioni aggiuntive nella pagina del progetto: stato del progetto, utilizzo delle risorse e quote del progetto.
Visualizzazione delle vulnerabilità per quay nella console Web
È stata aggiunta una funzionalità alla console di gestione per visualizzare le vulnerabilità note per le immagini nei repository Quay. È supportata la visualizzazione delle vulnerabilità per i repository locali ed esterni.
Creazione semplificata di operatorhub offline
Nel caso di implementazione di un cluster OpenShift in una rete isolata, dalla quale l'accesso a Internet è limitato o assente, la creazione di un "mirror" per il registro di OperatorHub è semplificata. Ora questo può essere fatto solo con tre squadre.
Autori:
Victor Puchkov, Yuri Semenyukov
Fonte: habr.com