La quarta versió d'OpenShift es va publicar fa relativament poc. La versió actual 4.3 està disponible des de finals de gener i tots els canvis que s'hi introdueixen són una cosa completament nova que no es trobava a la tercera versió, o bé una actualització important del que va aparèixer a la versió 4.1. Tot el que us explicarem ara ha de ser conegut, entès i tingut en compte per aquells que treballen amb OpenShift i tenen previst canviar a una nova versió.
Amb el llançament d'OpenShift 4.2, Red Hat ha facilitat el treball amb Kubernetes. Han aparegut noves eines i connectors per crear contenidors, canalitzacions CI/CD i desplegaments sense servidor. Les innovacions donen als desenvolupadors l'oportunitat de centrar-se a escriure codi i no a tractar amb Kubernetes.
De fet, què hi ha de nou en les versions d'OpenShift 4.2 i 4.3?
Avançar cap als núvols híbrids
Quan planifiquen una nova infraestructura informàtica o quan desenvolupen un panorama informàtic existent, les empreses consideren cada cop més un enfocament al núvol per proporcionar recursos informàtics, per als quals implementen solucions de núvol privat o utilitzen el poder dels proveïdors de núvol públic. Així, les infraestructures informàtiques modernes es construeixen cada cop més segons un model de núvol "híbrid", quan s'utilitzen tant recursos locals com recursos del núvol públic amb un sistema de gestió comú. Red Hat OpenShift 4.2 està especialment dissenyat per simplificar la transició a un model de núvol híbrid i facilita la connexió de recursos de proveïdors com AWS, Azure i Google Cloud Platform al clúster, juntament amb l'ús de núvols privats a VMware i OpenStack.
Nou enfocament de la instal·lació
A la versió 4, l'enfocament per instal·lar OpenShift ha canviat. Red Hat proporciona una utilitat especial per desplegar un clúster OpenShift: openshift-install. La utilitat és un únic fitxer binari escrit a Go. L'Openshit-installer prepara un fitxer yaml amb la configuració necessària per al desplegament.
En cas d'instal·lació amb recursos del núvol, haureu d'especificar informació mínima sobre el futur clúster: zona DNS, nombre de nodes de treball, paràmetres específics per al proveïdor de núvol, informació del compte per accedir al proveïdor de núvol. Després de preparar el fitxer de configuració, el clúster es pot desplegar amb una ordre.
En cas d'instal·lació en els vostres propis recursos informàtics, per exemple, quan utilitzeu un núvol privat (s'admeten vSphere i OpenStack) o quan s'instal·leu en servidors bare metal, haureu de configurar manualment la infraestructura: preparar el nombre mínim de màquines virtuals o servidors físics necessaris per crear un clúster de pla de control, configurar serveis de xarxa. Després d'aquesta configuració, un clúster OpenShift es pot crear de manera similar amb una ordre de la utilitat d'instal·lador d'openshift.
Actualitzacions d'infraestructures
Integració de CoreOS
L'actualització clau és la integració amb Red Hat CoreOS. Els nodes mestres de Red Hat OpenShift ara poden funcionar només al nou sistema operatiu. Aquest és un sistema operatiu gratuït de Red Hat dissenyat específicament per a solucions de contenidors. Red Hat CoreOS és un Linux lleuger optimitzat per executar contenidors.
Si a la 3.11 el sistema operatiu i l'OpenShift existien per separat, a la 4.2 està indissociablement vinculat amb OpenShift. Ara es tracta d'un únic aparell: una infraestructura immutable.
Per als clústers que utilitzen RHCOS per a tots els nodes, l'actualització de OpenShift Container Platform és un procés senzill i altament automatitzat.
Anteriorment, per actualitzar OpenShift, primer calia actualitzar el sistema operatiu subjacent en què s'executava el producte (aleshores, Red Hat Enterprise Linux). Només llavors OpenShift es podria actualitzar gradualment, node per node. No es va parlar de cap automatització del procés.
Ara, com que la plataforma de contenidors OpenShift controla completament els sistemes i serveis de cada node, inclòs el sistema operatiu, aquesta tasca es resol prement un botó des de la interfície web. Després d'això, s'inicia un operador especial dins del clúster OpenShift, que controla tot el procés d'actualització.
Nou CSI
En segon lloc, el nou CSI és un controlador d'interfície d'emmagatzematge que us permet connectar diversos sistemes d'emmagatzematge externs al clúster OpenShift. Un gran nombre de proveïdors de controladors d'emmagatzematge per a OpenShift són compatibles basats en controladors d'emmagatzematge escrits pels mateixos fabricants de sistemes d'emmagatzematge. En aquest document es pot trobar una llista completa de controladors CSI compatibles: . En aquesta llista podeu trobar tots els models principals de matrius de discs dels principals fabricants (Dell/EMC, IBM, NetApp, Hitachi, HPE, PureStorage), solucions SDS (Ceph) i emmagatzematge al núvol (AWS, Azure, Google). L'OpenShift 4.2 admet els controladors CSI de l'especificació CSI versió 1.1.
RedHat OpenShift Service Mesh
Basat en els projectes Istio, Kiali i Jaeger, Red Hat OpenShift Service Mesh, a més de les tasques habituals d'encaminament de sol·licituds entre serveis, permet el seu rastreig i visualització. Això ajuda els desenvolupadors a comunicar-se, supervisar i gestionar fàcilment una aplicació desplegada dins de Red Hat OpenShift.
Visualització d'una aplicació amb una arquitectura de microservei mitjançant Kiali
Per simplificar al màxim la instal·lació, el manteniment i la gestió del cicle de vida de Service Mesh, Red Hat OpenShift ofereix als administradors un operador especial, l'Operador de Service Mesh. Es tracta d'un operador de Kubernetes que us permet desplegar paquets Istio, Kiali i Jaeger reconfigurats en un clúster, maximitzant la càrrega administrativa de la gestió d'aplicacions.
CRI-O en lloc de Docker
El temps d'execució del contenidor predeterminat Docker s'ha substituït per CRI-O. Ja era possible utilitzar CRI-O a la versió 3.11, però a la 4.2 es va convertir en la principal. No és bo ni dolent, però cal tenir en compte a l'hora d'utilitzar el producte.
Operadors i desplegament d'aplicacions
Els operadors són una nova entitat per a RedHat OpenShift, que va aparèixer a la quarta versió. És un mètode per empaquetar, desplegar i gestionar una aplicació Kubernetes. Es pot pensar com un complement per a aplicacions desplegades en contenidors, impulsat per l'API de Kubernetes i les eines kubectl.
Els operadors de Kubernetes ajuden a automatitzar qualsevol tasca relacionada amb l'administració i la gestió del cicle de vida de l'aplicació que desplegueu al vostre clúster. Per exemple, l'operador pot automatitzar actualitzacions, còpies de seguretat i escalat de l'aplicació, canviar la configuració, etc. Podeu trobar una llista completa d'operadors a .
OperatorHub és accessible directament des de la interfície web de la consola de gestió. És un directori d'aplicacions per a OpenShift mantingut per Red Hat. Aquells. tots els operadors aprovats per Red Hat estaran coberts per l'assistència de proveïdors.
Portal OperatorHub a la consola de gestió d'OpenShift
Imatge base universal
És un conjunt estandarditzat d'imatges RHEL OS que es poden utilitzar per crear les vostres aplicacions en contenidors. Hi ha conjunts mínims, estàndard i complets. Ocupen molt poc espai i admeten tots els paquets instal·lats i llenguatges de programació necessaris.
Eines CI/CD
A RedHat OpenShif 4.2, va ser possible triar entre Jenkins i OpenShift Pipelines basats en Tekton Pipelines.
OpenShift Pipelines es basa en Tekton, que és més compatible amb Pipeline a mesura que s'acosta Code i GitOps. A les pipelines d'OpenShift, cada pas s'executa al seu propi contenidor, de manera que els recursos només s'utilitzen mentre s'executa el pas. Això ofereix als desenvolupadors un control complet sobre les canalitzacions de lliurament de mòduls, els connectors i el control d'accés sense un servidor central CI/CD per gestionar.
L'OpenShift Pipelines es troba actualment a la vista prèvia per a desenvolupadors i està disponible com a operador en un clúster OpenShift 4. Per descomptat, els usuaris d'OpenShift encara poden utilitzar Jenkins a RedHat OpenShift 4.
Actualitzacions de gestió de desenvolupadors
A l'OpenShift 4.2, la interfície web s'ha actualitzat completament tant per als desenvolupadors com per als administradors.
En versions anteriors d'OpenShift, tothom treballava en tres consoles: directori de servei, consola d'administrador i consola de treball. Ara el clúster només es divideix en dues parts: la consola de l'administrador i la consola del desenvolupador.
La consola del desenvolupador ha rebut millores importants en la interfície d'usuari. Ara mostra de manera més còmoda les topologies de les aplicacions i els seus conjunts. Això facilita als desenvolupadors crear, desplegar i visualitzar aplicacions en contenidors i recursos agrupats. Els permet centrar-se en allò que és important per a ells.
Portal de desenvolupadors a la consola de gestió d'OpenShift
escolto
Odo és una utilitat de línia d'ordres orientada als desenvolupadors que simplifica el desenvolupament d'aplicacions a OpenShift. Utilitzant la comunicació d'estil git push, aquesta CLI ajuda els desenvolupadors nous a Kubernetes a crear aplicacions a OpenShift.
Integració amb entorns de desenvolupament
Els desenvolupadors ara poden crear, depurar i desplegar les seves aplicacions a OpenShift sense sortir del seu entorn de desenvolupament de codi preferit, com ara Microsoft Visual Studio, JetBrains (incloent IntelliJ), Eclipse Desktop, etc.
Extensió de desplegament de Red Hat OpenShift per a Microsoft Azure DevOps
S'ha llançat l'extensió Red Hat OpenShift Deployment per a Microsoft Azure DevOps. Els usuaris d'aquest conjunt d'eines DevOps ara poden desplegar les seves aplicacions a Azure Red Hat OpenShift o a qualsevol altre clúster d'OpenShift directament des de Microsoft Azure DevOps.
Transició de la tercera versió a la quarta
Com que estem parlant d'una versió nova, i no d'una actualització, no podeu posar la quarta versió a sobre de la tercera. No s'admetrà l'actualització de la versió XNUMX a la versió XNUMX..
Però hi ha bones notícies: Red Hat ofereix eines per migrar projectes de la 3.7 a la 4.2. Podeu migrar les càrregues de treball d'aplicacions mitjançant l'eina de migració d'aplicacions de clúster (CAM). CAM us permet controlar la migració i minimitzar el temps d'inactivitat de l'aplicació.
OpenShift 4.3
Les principals innovacions descrites en aquest article van aparèixer a la versió 4.2. Els canvis 4.3 publicats recentment no són tan grans, però encara hi ha algunes coses noves. La llista de canvis és força extensa, aquí teniu els més significatius segons la nostra opinió:
Actualitzeu la versió de Kubernetes a la 1.16.
La versió es va actualitzar en dos passos alhora; a OpenShift 4.2 era 1.14.
Xifratge de dades en etcd
A partir de la versió 4.3, es va fer possible xifrar dades a la base de dades etcd. Un cop habilitat el xifratge, serà possible xifrar els següents recursos de l'API d'OpenShift i de l'API de Kubernetes: Secrets, ConfigMaps, Rutes, testimonis d'accés i autorització OAuth.
Timó
S'ha afegit suport per a la versió 3 de Helm, un gestor de paquets popular per a Kubernetes. De moment, el suport té l'estat VISTA PREVIA DE TECNOLOGIA. El suport d'Helm s'ampliarà fins al suport total en futures versions d'OpenShift. La utilitat Helm cli ve amb OpenShift i es pot descarregar des de la consola web de gestió de clúster.
Actualització del tauler de control del projecte
A la nova versió, Project Dashboard proporciona informació addicional a la pàgina del projecte: estat del projecte, ús de recursos i quotes del projecte.
Mostrant vulnerabilitats de Quay a la consola web
S'ha afegit una funció a la consola de gestió per mostrar les vulnerabilitats conegudes per a les imatges dels dipòsits de Quay. S'admet la visualització de vulnerabilitats per a repositoris locals i externs.
Creació simplificada d'operadorhub fora de línia
En el cas de desplegar un clúster OpenShift en una xarxa aïllada, des de la qual l'accés a Internet és limitat o absent, es simplifica la creació d'un "mirall" per al registre OperatorHub. Ara això es pot fer amb només tres equips.
Autors:
Víctor Puchkov, Yuri Semenyukov
Font: www.habr.com