Cea de-a patra versiune OpenShift a fost lansată relativ recent. Versiunea actuală, 4.3, este disponibilă din sfârșitul lunii ianuarie și toate modificările din aceasta sunt fie ceva complet nou, ce nu exista în versiunea a treia, fie o actualizare majoră a ceea ce a apărut în versiunea 4.1. Tot ceea ce vom discuta acum trebuie să fie cunoscut, înțeles și luat în considerare de cei care lucrează cu OpenShift și intenționează să facă tranziția la noua versiune.
Odată cu lansarea versiunii OpenShift 4.2, Red Hat a simplificat lucrul cu Kubernetes. Au apărut noi instrumente și plugin-uri pentru crearea de containere, pipeline-uri CI/CD și desfășurări fără server. Noutățile oferă dezvoltatorilor posibilitatea de a se concentra pe scrierea codului, în loc de a se ocupa de problemele legate de Kubernetes.
Ce este nou în versiunile OpenShift 4.2 și 4.3?
Tendința spre clouduri hibride
În planificarea unei noi infrastructuri IT sau în dezvoltarea peisajului IT existent, companiile examinează din ce în ce mai des abordarea cloud pentru furnizarea resurselor IT, implementând soluții cloud private sau utilizând capacitățile furnizorilor de cloud public. Astfel, infrastructurile IT moderne sunt din ce în ce mai des construite pe un model de cloud „hibrid”, unde sunt utilizate atât resurse on-premises, cât și resurse de cloud public cu un sistem de gestionare comun. Red Hat OpenShift 4.2 a fost conceput special pentru a simplifica tranziția la modelul de cloud hibrid și permite conectarea facilă a resurselor de la furnizori precum AWS, Azure și Google Cloud Platform, alături de utilizarea cloud-urilor private pe VMware și OpenStack.
O nouă abordare a instalării
În versiunea a 4-a, abordarea față de instalarea OpenShift s-a schimbat. Red Hat oferă un utilitar special pentru desfășurarea cluster-ului OpenShift – openshift-install. Acest utilitar reprezintă un singur fișier binar, scris în Go. Openshift-installer pregătește un fișier yaml cu configurația necesară pentru desfășurare.
În cazul instalării utilizând resurse cloud, va fi necesar să specificați informații minime despre viitorul cluster: zona DNS, numărul de noduri worker, setări specifice pentru furnizorul de cloud, date de cont pentru accesul la furnizorul de cloud. După pregătirea fișierului de configurație, clusterul poate fi desfășurat cu o singură comandă.
În cazul instalării pe resursele computaționale proprii, cum ar fi utilizarea unui cloud privat (care suportă vSphere și OpenStack) sau instalarea pe servere bare metal, va fi necesară configurarea manuală a infrastructurii – pregătirea unui număr minim de mașini virtuale sau servere fizice necesare pentru a crea un cluster Control Plane și configurarea serviciilor de rețea. După această configurare, clusterul OpenShift poate fi creat similar cu o singură comandă a utilitarului openshift-installer.
Actualizări în infrastructură
Integrarea cu CoreOS
Actualizarea cheie – este integrarea cu Red Hat CoreOS. Acum, nodurile master Red Hat OpenShift pot funcționa doar pe un nou sistem de operare. Aceasta este un sistem de operare gratuit de la Red Hat, special conceput pentru soluții containerizate. Red Hat CoreOS este un Linux ușor, optimizat pentru rularea containerelor.
Dacă în 3.11 sistemul de operare și OpenShift existau separat, în 4.2 ele sunt intrinsec legate de OpenShift. Acum este un appliance unic – infrastructură immutable.
Pentru clusterele care utilizează RHCOS pentru toate nodurile, actualizarea OpenShift Container Platform este un proces simplu și bine automatizat.
Anterior, pentru a actualiza OpenShift, era necesar mai întâi să se actualizeze sistemul de operare de bază pe care produsul era rulat (la acel moment era Red Hat Enterprise Linux). Abia după aceea se putea actualiza OpenShift treptat, nod cu nod. Nu exista nicio automatizare a procesului.
Acum, deoarece OpenShift Container Platform controlează complet sistemele și serviciile de pe fiecare nod, inclusiv OS-ul, această sarcină se rezolvă printr-o simplă apăsare de buton din interfața web. După aceasta, se pornește un operator special în cadrul clusterului OpenShift, care gestionează întregul proces de actualizare.
Noul CSI
Al doilea — noul CSI — controlerul interfeței de storage, care permite conectarea diverselor storaje externe la clusterul OpenShift. Este suportat un număr mare de furnizori de drivere de storage pentru OpenShift, bazate pe driverele de storage pe care le furnizează producătorii de stocare. Lista completă a driverelor CSI suportate poate fi găsită în acest document: . În această listă puteți găsi toate modelele de array-uri de stocare ale principalelor producători (Dell/EMC, IBM, NetApp, Hitachi, HPE, PureStorage), soluții SDS (Ceph) și stocări cloud (AWS, Azure, Google). OpenShift 4.2 suportă lucrul cu drivere CSI conform specificației CSI versiunea 1.1.
RedHat OpenShift Service Mesh
Bazat pe proiectele Istio, Kiali și Jaeger — Red Hat OpenShift Service Mesh, pe lângă sarcinile obișnuite de rutare a cererilor între servicii, permite urmărirea și vizualizarea acestora. Acest lucru ajută dezvoltatorii să simplifice interacțiunile, monitorizarea și gestionarea aplicației desfășurate în cadrul Red Hat OpenShift.
Vizualizarea unei aplicații cu arhitectură microservicii folosind Kiali
Pentru a simplifica procesele de instalare, serviciu și management al ciclului de viață al Service Mesh, Red Hat OpenShift oferă administratorilor un operator special - Service Mesh Operator. Acest operator Kubernetes permite desfășurarea pachetelor Istio, Kiali și Jaeger, configurate, pe cluster, reducând la minimum sarcina administrativă a gestionării aplicațiilor.
CRI-O în loc de Docker
Runtime-ul containerului implicit Docker a fost înlocuit cu CRI-O. CRI-O putea fi utilizat deja în versiunea 3.11, dar în 4.2 a devenit principalul. Nu este bine și nici rău, dar merită să aveți în vedere acest aspect când folosiți produsul.
Operatori și desfășurarea aplicațiilor
Operatorii sunt o nouă entitate pentru RedHat OpenShift, care a apărut în a patra versiune. Acesta este un metod de împachetare, desfășurare și gestionare a aplicației Kubernetes. Poate fi văzut ca un plugin gestionat prin API Kubernetes și instrumente kubectl pentru aplicațiile desfășurate în containere.
Operatorii Kubernetes ajută la automatizarea oricăror sarcini legate de administrarea și gestionarea ciclului de viață al aplicației pe care o desfășurați în clusterul dumneavoastră. De exemplu, un operator poate automatiza actualizările, backup-ul și scalarea aplicației, modificarea configurației etc. Lista completă a operatorilor poate fi consultată la .
OperatorHub este disponibil direct din interfața web a consolei de administrare. Acesta este un catalog de aplicații pentru OpenShift, susținut de Red Hat. Astfel, toți operatorii aprobați de Red Hat vor beneficia de suport din partea furnizorului.
Portalul OperatorHub în consola de administrare OpenShift
Imagine de bază universală
Acesta este un set standardizat de imagini ale sistemului de operare RHEL, care poate fi utilizat pentru a crea aplicațiile dumneavoastră în containere. Există seturi minime, standard și complete. Ocupă foarte puțin spațiu, susțin toate pachetele și limbajele de programare necesare.
Instrumente CI/CD
În RedHat OpenShift 4.2, a fost adăugată opțiunea de a alege între Jenkins și OpenShift Pipelines bazat pe Tekton Pipelines.
OpenShift Pipelines se bazează pe Tekton, care susține mai bine abordările Pipeline as Code și GitOps. În pipelini OpenShift, fiecare pas se execută într-un container propriu, astfel încât resursele sunt utilizate doar în timpul execuției pasului. Aceasta oferă dezvoltatorilor control complet asupra pipelinelor de livrare a modulelor, pluginurilor și controlului accesului fără un server CI/CD centralizat pentru gestionare.
OpenShift Pipelines este în prezent în faza de Preview pentru dezvoltatori și este disponibil ca operator pe clusterul OpenShift 4. Desigur, utilizatorii OpenShift pot continua să folosească Jenkins în RedHat OpenShift 4.
Actualizări în management pentru dezvoltatori
În 4.2, OpenShift a actualizat complet interfața web atât pentru dezvoltatori, cât și pentru administratori.
În versiunile anterioare ale OpenShift, toată lumea lucra în trei console: catalogul de servicii, consola administratorului și consola de lucru. Acum, clusterul este împărțit doar în două părți — consola administratorului și consola dezvoltatorului.
Consola dezvoltatorului a primit îmbunătățiri semnificative ale interfeței utilizatorului. Acum, topologiile aplicațiilor și construcțiile lor sunt afișate mai confortabil. Acest lucru facilitează dezvoltatorilor crearea, desfășurarea și vizualizarea aplicațiilor containerizate și a resurselor clusterului. Le permite să se concentreze asupra a ceea ce este important pentru ei.
Portalul dezvoltatorului în consola de administrare OpenShift
Odo
Odo este un instrument de linie de comandă orientat spre dezvoltatori, care simplifică dezvoltarea aplicațiilor în OpenShift. Utilizând interacțiunea în stil git push, acest CLI ajută dezvoltatorii care nu sunt familiarizați cu Kubernetes să creeze aplicații în OpenShift.
Integrarea cu medii de dezvoltare
Dezvoltatorii pot acum să creeze, să depaneze și să desfășoare aplicațiile lor î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.
Extensia Red Hat OpenShift Deployment pentru Microsoft Azure DevOps
A apărut extensia Red Hat OpenShift Deployment pentru Microsoft Azure DevOps. Acum utilizatorii acestui set de instrumente DevOps pot desfășura aplicațiile lor în Azure Red Hat OpenShift sau în orice alt cluster OpenShift direct din Microsoft Azure DevOps.
Trecerea de la versiunea a treia la a patra
Deoarece este vorba despre o nouă versiune și nu despre o actualizare, nu se poate pur și simplu instala versiunea a patra peste versiunea a treia. Actualizarea de la versiunea a treia la a patra nu va fi suportată.
Dar există și vești bune: Red Hat oferă instrumente pentru migrarea proiectelor din 3.7 în 4.2. Puteți migra sarcinile de lucru ale aplicațiilor folosind instrumentul Cluster Application Migration (CAM). CAM permite controlul migrației și minimizează timpul de nefuncționare al aplicației.
OpenShift 4.3
Principalele noutăți descrise în acest articol au apărut în versiunea 4.2. În noul 4.3, modificările nu sunt atât de semnificative, dar există totuși câteva noutăți. Lista modificărilor este destul de cuprinzătoare, vom menționa cele mai relevante din perspectiva noastră:
Actualizarea versiunii Kubernetes la 1.16.
Versiunea a fost actualizată cu două salturi, în OpenShift 4.2 era 1.14.
Criptarea datelor în etcd
Începând cu versiunea 4.3, a apărut posibilitatea de a cripta datele în baza etcd. După activarea criptării, va fi posibilă criptarea următoarelor resurse OpenShift API și Kubernetes API: Secrets, ConfigMaps, Routes, tokenuri de acces și autorizare OAuth.
Helm
Suport adăugat pentru Helm versiunea 3 – un manager de pachete popular pentru Kubernetes. Până acum suportul are statutul de TECHNOLOGY PREVIEW. În viitoarele versiuni OpenShift, suportul pentru Helm va fi extins la o capacitate totală. Utilitarul helm cli este inclus împreună cu OpenShift și poate fi descărcat din consola web de management a cluster-ului.
Actualizarea Project Dashboard
În noua versiune, Project Dashboard oferă informații suplimentare pe pagina proiectului: starea proiectului, utilizarea resurselor și cotele pentru proiect.
Afișarea vulnerabilităților pentru quay în consola web
În consola de management a fost adăugată funcția de afișare a vulnerabilităților cunoscute pentru imaginile din repositoarele Quay. Se susține afișarea vulnerabilităților pentru repositoarele locale și externe.
Simplificarea creării operatorului offline
Pentru cazul desfășurării unui cluster OpenShift într-o rețea izolată, al cărei acces la internet este limitat sau absent, a fost simplificată crearea unui „oglinzi” pentru registrul OperatorHub. Acum se poate face acest lucru cu doar trei comenzi.
Autori:
Victor Puchkov, Yuri Semeniuk
Sursa: habr.com
