A patra versiune a OpenShift a fost lansată relativ recent. Versiunea actuală 4.3 este disponibilă de la sfârșitul lunii ianuarie și toate modificările din ea sunt fie ceva complet nou care nu era în versiunea a treia, fie o actualizare majoră a ceea ce a apărut în versiunea 4.1. Tot ceea ce vă vom spune acum trebuie să fie cunoscut, înțeles și luat în considerare de cei care lucrează cu OpenShift și intenționează să treacă la o nouă versiune.
Odată cu lansarea OpenShift 4.2, Red Hat a simplificat lucrul cu Kubernetes. Au apărut noi instrumente și pluginuri pentru crearea de containere, conducte CI/CD și implementări fără server. Inovațiile oferă dezvoltatorilor posibilitatea de a se concentra pe scrierea codului, și nu pe tratarea cu Kubernetes.
De fapt, ce este nou în versiunile OpenShift 4.2 și 4.3?
Trecerea către nori hibrizi
Atunci când planifică o nouă infrastructură IT sau când dezvoltă un peisaj IT existent, companiile iau în considerare din ce în ce mai mult o abordare cloud pentru furnizarea de resurse IT, pentru care implementează soluții private cloud sau folosesc puterea furnizorilor de cloud public. Astfel, infrastructurile IT moderne sunt construite din ce în ce mai mult după un model de cloud „hibrid”, atunci când sunt folosite atât resursele on-premise, cât și resursele cloud public cu un sistem de management comun. Red Hat OpenShift 4.2 este special conceput pentru a simplifica tranziția la un model de cloud hibrid și facilitează conectarea resurselor de la furnizori precum AWS, Azure și Google Cloud Platform la cluster, împreună cu utilizarea cloud-urilor private pe VMware și OpenStack.
Noua abordare a instalarii
În versiunea 4, abordarea instalării OpenShift s-a schimbat. Red Hat oferă un utilitar special pentru implementarea unui cluster OpenShift - openshift-install. Utilitarul este un singur fișier binar scris în Go. Openshit-installer pregătește un fișier yaml cu configurația necesară pentru implementare.
În cazul instalării folosind resurse cloud, va trebui să specificați informații minime despre viitorul cluster: zona DNS, numărul de noduri de lucru, setări specifice pentru furnizorul de cloud, informații despre cont pentru accesarea furnizorului de cloud. După pregătirea fișierului de configurare, clusterul poate fi implementat cu o singură comandă.
În cazul instalării pe propriile resurse de calcul, de exemplu, când utilizați un cloud privat (vSphere și OpenStack sunt acceptate) sau când instalați pe servere bare metal, va trebui să configurați manual infrastructura - pregătiți numărul minim de mașini virtuale sau servere fizice necesare pentru a crea un cluster Plan de control, pentru a configura serviciile de rețea. După această configurare, un cluster OpenShift poate fi creat în mod similar cu o comandă a utilitarului openshift-installer.
Actualizări de infrastructură
Integrarea CoreOS
Actualizarea cheie este integrarea cu Red Hat CoreOS. Nodurile principale Red Hat OpenShift pot funcționa acum numai pe noul sistem de operare. Acesta este un sistem de operare gratuit de la Red Hat, care este conceput special pentru soluții de containere. Red Hat CoreOS este un Linux ușor optimizat pentru rularea containerelor.
Dacă în 3.11 sistemul de operare și OpenShift existau separat, atunci în 4.2 este indisolubil legat de OpenShift. Acum, acesta este un singur aparat - infrastructură imuabilă.
Pentru clusterele care folosesc RHCOS pentru toate nodurile, actualizarea OpenShift Container Platform este un proces simplu și extrem de automatizat.
Anterior, pentru a actualiza OpenShift, mai întâi trebuia să actualizați sistemul de operare de bază pe care rula produsul (la momentul respectiv, Red Hat Enterprise Linux). Abia atunci OpenShift ar putea fi actualizat treptat, nod cu nod. Nu s-a vorbit despre vreo automatizare a procesului.
Acum, deoarece OpenShift Container Platform controlează pe deplin sistemele și serviciile de pe fiecare nod, inclusiv sistemul de operare, această sarcină este rezolvată prin apăsarea unui buton din interfața web. După aceasta, în interiorul clusterului OpenShift este lansat un operator special, care controlează întregul proces de actualizare.
CSI nou
În al doilea rând, noul CSI este un controler de interfață de stocare care vă permite să conectați diferite sisteme de stocare externe la clusterul OpenShift. Un număr mare de furnizori de drivere de stocare pentru OpenShift sunt acceptați pe baza driverelor de stocare care sunt scrise de producătorii de sisteme de stocare înșiși. O listă completă a driverelor CSI acceptate poate fi găsită în acest document: . În această listă puteți găsi toate modelele principale de matrice de discuri de la producători de top (Dell/EMC, IBM, NetApp, Hitachi, HPE, PureStorage), soluții SDS (Ceph) și stocare în cloud (AWS, Azure, Google). OpenShift 4.2 acceptă driverele CSI ale specificației CSI versiunea 1.1.
RedHat OpenShift Service Mesh
Pe baza proiectelor Istio, Kiali și Jaeger, Red Hat OpenShift Service Mesh, pe lângă sarcinile obișnuite de direcționare a cererilor între servicii, permite urmărirea și vizualizarea acestora. Acest lucru îi ajută pe dezvoltatori să comunice, să monitorizeze și să gestioneze cu ușurință o aplicație implementată în Red Hat OpenShift.
Vizualizarea unei aplicații având o arhitectură de microservicii folosind Kiali
Pentru a simplifica cât mai mult posibil instalarea, întreținerea și gestionarea ciclului de viață al Service Mesh, Red Hat OpenShift oferă administratorilor un operator special, Service Mesh Operator. Acesta este un operator Kubernetes care vă permite să implementați pachete Istio, Kiali și Jaeger reconfigurate într-un cluster, maximizând sarcina administrativă a gestionării aplicațiilor.
CRI-O în loc de Docker
Timpul de rulare implicit al containerului Docker a fost înlocuit cu CRI-O. Era posibil să se folosească CRI-O deja în versiunea 3.11, dar în 4.2 a devenit cea principală. Nu bine sau rău, dar ceva de reținut atunci când utilizați produsul.
Operatori și implementarea aplicațiilor
Operatorii sunt o nouă entitate pentru RedHat OpenShift, care a apărut în a patra versiune. Este o metodă de ambalare, implementare și gestionare a unei aplicații Kubernetes. Poate fi considerat ca un plugin pentru aplicațiile implementate în containere, conduse de API-ul Kubernetes și instrumentele kubectl.
Operatorii Kubernetes ajută la automatizarea oricăror sarcini legate de administrarea și managementul ciclului de viață al aplicației pe care o implementați în cluster. De exemplu, operatorul poate automatiza actualizările, backup-urile și scalarea aplicației, poate modifica configurația etc. O listă completă a operatorilor poate fi găsită la .
OperatorHub este accesibil direct din interfața web a consolei de management. Este un director de aplicații pentru OpenShift întreținut de Red Hat. Acestea. toți operatorii aprobați Red Hat vor fi acoperiți de asistența furnizorilor.
Portalul OperatorHub în consola de management OpenShift
Imagine de bază universală
Este un set standardizat de imagini RHEL OS care poate fi folosit pentru a construi aplicațiile dvs. containerizate. Există seturi minime, standard și complete. Ele ocupă foarte puțin spațiu și acceptă toate pachetele instalate și limbajele de programare necesare.
Instrumente CI/CD
În RedHat OpenShif 4.2, a devenit posibil să alegeți între Jenkins și OpenShift Pipelines bazate pe Tekton Pipelines.
OpenShift Pipelines se bazează pe Tekton, care este mai bine susținut de Pipeline pe măsură ce Code și GitOps se apropie. În conductele OpenShift, fiecare pas rulează în propriul său container, astfel încât resursele sunt utilizate doar în timp ce pasul se execută. Acest lucru oferă dezvoltatorilor control complet asupra conductelor de livrare a modulelor, pluginurilor și controlului accesului fără un server central CI/CD de gestionat.
OpenShift Pipelines este în prezent în Developer Preview și este disponibil ca operator pe un cluster OpenShift 4. Desigur, utilizatorii OpenShift pot utiliza în continuare Jenkins pe RedHat OpenShift 4.
Actualizări de management pentru dezvoltatori
În 4.2 OpenShift, interfața web a fost complet actualizată atât pentru dezvoltatori, cât și pentru administratori.
În versiunile anterioare de OpenShift, toată lumea lucra în trei console: directorul de servicii, consola de administrator și consola de lucru. Acum cluster-ul este împărțit în doar două părți - consola de administrator și consola pentru dezvoltatori.
Consola pentru dezvoltatori a primit îmbunătățiri semnificative ale interfeței cu utilizatorul. Acum afișează mai convenabil topologiile aplicațiilor și ansamblurile acestora. Astfel, dezvoltatorilor le este mai ușor să creeze, să implementeze și să vizualizeze aplicații containerizate și resursele grupate. Le permite să se concentreze asupra a ceea ce este important pentru ei.
Portal pentru dezvoltatori în consola de management OpenShift
aud
Odo este un utilitar de linie de comandă orientat către dezvoltatori care simplifică dezvoltarea aplicațiilor în OpenShift. Folosind comunicarea în stilul git push, acest CLI îi ajută pe dezvoltatorii nou în Kubernetes să construiască aplicații în OpenShift.
Integrarea cu mediile de dezvoltare
Dezvoltatorii își pot construi, depana și implementa acum aplicațiile în OpenShift fără a părăsi mediul lor preferat de dezvoltare a codului, cum ar fi Microsoft Visual Studio, JetBrains (inclusiv IntelliJ), Eclipse Desktop etc.
Extensie Red Hat OpenShift Deployment pentru Microsoft Azure DevOps
Extensia Red Hat OpenShift Deployment pentru Microsoft Azure DevOps a fost lansată. Utilizatorii acestui set de instrumente DevOps își pot implementa acum aplicațiile în Azure Red Hat OpenShift sau în orice alt cluster OpenShift direct din Microsoft Azure DevOps.
Trecerea de la a treia versiune la a patra
Deoarece vorbim despre o nouă versiune și nu despre o actualizare, nu puteți pune pur și simplu a patra versiune peste cea de-a treia. Actualizarea de la versiunea 3 la versiunea 4 nu va fi acceptată..
Dar există o veste bună: Red Hat oferă instrumente pentru migrarea proiectelor de la 3.7 la 4.2. Puteți migra încărcăturile de lucru ale aplicațiilor utilizând instrumentul Cluster Application Migration (CAM). CAM vă permite să controlați migrarea și să minimizați timpul de nefuncționare al aplicației.
OpenShift 4.3
Principalele inovații descrise în acest articol au apărut în versiunea 4.2. Modificările 4.3 lansate recent nu sunt la fel de mari, dar există încă câteva lucruri noi. Lista modificărilor este destul de extinsă, iată cele mai semnificative în opinia noastră:
Actualizați versiunea Kubernetes la 1.16.
Versiunea a fost actualizată în doi pași simultan în OpenShift 4.2, a fost 1.14.
Criptarea datelor în etcd
Începând cu versiunea 4.3, a devenit posibilă criptarea datelor în baza de date etcd. Odată ce criptarea este activată, va fi posibilă criptarea următoarelor resurse OpenShift API și Kubernetes API: Secrete, ConfigMaps, Rute, jetoane de acces și autorizare OAuth.
Cârmă
S-a adăugat suport pentru Helm versiunea 3, un manager de pachete popular pentru Kubernetes. Deocamdată, suportul are statutul TECHNOLOGY PREVIEW. Suportul Helm va fi extins la suport complet în versiunile viitoare de OpenShift. Utilitarul helm cli vine cu OpenShift și poate fi descărcat de pe consola web de gestionare a clusterelor.
Actualizarea tabloului de bord al proiectului
În noua versiune, Project Dashboard oferă informații suplimentare pe pagina proiectului: starea proiectului, utilizarea resurselor și cotele proiectului.
Afișarea vulnerabilităților pentru chei în consola Web
A fost adăugată o funcție la consola de management pentru a afișa vulnerabilitățile cunoscute pentru imaginile din depozitele Quay. Este acceptată afișarea vulnerabilităților pentru depozitele locale și externe.
Crearea simplificată a operatorhubului offline
În cazul implementării unui cluster OpenShift într-o rețea izolată, din care accesul la Internet este limitat sau absent, crearea unei „oglinzi” pentru registrul OperatorHub este simplificată. Acum acest lucru se poate face cu doar trei echipe.
Autori:
Victor Puchkov, Yuri Semenyukov
Sursa: www.habr.com