A cuarta versión de OpenShift publicouse hai relativamente pouco tempo. A actual versión 4.3 está dispoñible desde finais de xaneiro e todos os cambios nel son algo completamente novo que non estaba na terceira versión, ou unha actualización importante do que apareceu na versión 4.1. Todo o que che contaremos agora debe ser coñecido, entendido e tido en conta por aqueles que traballan con OpenShift e teñen pensado cambiar a unha nova versión.
Co lanzamento de OpenShift 4.2, Red Hat facilitou o traballo con Kubernetes. Apareceron novas ferramentas e complementos para crear contedores, canalizacións CI/CD e despregamentos sen servidor. As innovacións dan aos desenvolvedores a oportunidade de centrarse en escribir código, e non en tratar con Kubernetes.
En realidade, que hai de novo nas versións de OpenShift 4.2 e 4.3?
Avanzando cara ás nubes híbridas
Ao planificar unha nova infraestrutura de TI ou ao desenvolver unha paisaxe de TI existente, as empresas están considerando cada vez máis un enfoque na nube para a provisión de recursos de TI, para o que implementan solucións de nube privada ou usan o poder dos provedores de nube pública. Así, as modernas infraestruturas informáticas están a construírse cada vez máis segundo un modelo de nube "híbrido", cando se utilizan tanto recursos locais como recursos de nube pública cun sistema de xestión común. Red Hat OpenShift 4.2 está especialmente deseñado para simplificar a transición a un modelo de nube híbrida e facilita a conexión de recursos de provedores como AWS, Azure e Google Cloud Platform ao clúster, xunto co uso de nubes privadas en VMware e OpenStack.
Novo enfoque para a instalación
Na versión 4, o enfoque para instalar OpenShift cambiou. Red Hat ofrece unha utilidade especial para implementar un clúster OpenShift: openshift-install. A utilidade é un único ficheiro binario escrito en Go. Openshit-installer prepara un ficheiro yaml coa configuración necesaria para a implantación.
En caso de instalación mediante recursos na nube, terá que especificar información mínima sobre o futuro clúster: zona DNS, número de nodos de traballo, configuración específica para o provedor de nube, información da conta para acceder ao provedor de nube. Despois de preparar o ficheiro de configuración, o clúster pódese despregar cun só comando.
En caso de instalación nos seus propios recursos informáticos, por exemplo, cando se utiliza unha nube privada (vSphere e OpenStack son compatibles) ou cando se instala en servidores simples, terá que configurar manualmente a infraestrutura: preparar o número mínimo de máquinas virtuais ou servidores físicos necesarios para crear un clúster de Control Plane, configurar servizos de rede. Despois desta configuración, pódese crear un clúster OpenShift de forma similar cun comando da utilidade openshift-installer.
Actualizacións de infraestruturas
Integración CoreOS
A actualización clave é a integración con Red Hat CoreOS. Os nodos mestres de Red Hat OpenShift agora poden funcionar só no novo sistema operativo. Este é un sistema operativo gratuíto de Red Hat que está deseñado especificamente para solucións de contedores. Red Hat CoreOS é un Linux lixeiro optimizado para executar contedores.
Se en 3.11 o sistema operativo e OpenShift existían por separado, entón en 4.2 está inextricablemente ligado con OpenShift. Agora este é un único aparello: unha infraestrutura inmutable.
Para os clústeres que usan RHCOS para todos os nodos, actualizar OpenShift Container Platform é un proceso sinxelo e altamente automatizado.
Anteriormente, para actualizar OpenShift, primeiro tiñas que actualizar o sistema operativo subxacente no que se executaba o produto (naquel momento, Red Hat Enterprise Linux). Só entón OpenShift podería actualizarse gradualmente, nodo por nodo. Non se falou de ningunha automatización do proceso.
Agora, dado que OpenShift Container Platform controla totalmente os sistemas e servizos de cada nodo, incluído o SO, esta tarefa resólvese premendo un botón desde a interface web. Despois diso, lánzase un operador especial dentro do clúster OpenShift, que controla todo o proceso de actualización.
Novo CSI
En segundo lugar, o novo CSI é un controlador de interface de almacenamento que permite conectar varios sistemas de almacenamento externos ao clúster OpenShift. Un gran número de provedores de controladores de almacenamento para OpenShift son compatibles en función de controladores de almacenamento escritos polos propios fabricantes do sistema de almacenamento. Neste documento pódese atopar unha lista completa de controladores CSI compatibles: . Nesta lista podes atopar todos os modelos principais de matrices de discos dos principais fabricantes (Dell/EMC, IBM, NetApp, Hitachi, HPE, PureStorage), solucións SDS (Ceph) e almacenamento na nube (AWS, Azure, Google). OpenShift 4.2 admite controladores CSI da especificación CSI versión 1.1.
RedHat OpenShift Service Mesh
Baseado nos proxectos Istio, Kiali e Jaeger, Red Hat OpenShift Service Mesh, ademais das tarefas habituais de enrutamento de solicitudes entre servizos, permite o seu rastrexo e visualización. Isto axuda aos desenvolvedores a comunicarse, supervisar e xestionar facilmente unha aplicación implantada dentro de Red Hat OpenShift.
Visualización dunha aplicación cunha arquitectura de microservizos mediante Kiali
Para simplificar o máximo posible a instalación, o mantemento e a xestión do ciclo de vida de Service Mesh, Red Hat OpenShift ofrece aos administradores un operador especial, o Service Mesh Operator. Este é un operador de Kubernetes que che permite despregar paquetes Istio, Kiali e Jaeger reconfigurados nun clúster, maximizando a carga administrativa da xestión das aplicacións.
CRI-O en lugar de Docker
O tempo de execución do contedor predeterminado Docker foi substituído por CRI-O. Xa era posible usar CRI-O na versión 3.11, pero na 4.2 converteuse na principal. Non é bo nin malo, pero é algo a ter en conta ao usar o produto.
Operadores e implantación de aplicacións
Os operadores son unha nova entidade para RedHat OpenShift, que apareceu na cuarta versión. É un método de empaquetado, implantación e xestión dunha aplicación Kubernetes. Pódese considerar como un complemento para aplicacións despregadas en contedores, impulsado pola API de Kubernetes e as ferramentas kubectl.
Os operadores de Kubernetes axudan a automatizar todas as tarefas relacionadas coa administración e a xestión do ciclo de vida da aplicación que implementas no teu clúster. Por exemplo, o operador pode automatizar actualizacións, copias de seguridade e escalado da aplicación, cambiar a configuración, etc. Pódese atopar unha lista completa de operadores en .
Pódese acceder a OperatorHub directamente desde a interface web da consola de xestión. É un directorio de aplicacións para OpenShift mantido por Red Hat. Eses. todos os operadores aprobados por Red Hat estarán cubertos polo soporte de provedores.
Portal OperatorHub na consola de xestión de OpenShift
Imaxe base universal
É un conxunto estandarizado de imaxes do sistema operativo RHEL que se poden usar para crear as súas aplicacións en contedores. Hai conxuntos mínimos, estándar e completos. Ocupan moi pouco espazo e admiten todos os paquetes instalados e linguaxes de programación necesarios.
Ferramentas CI/CD
En RedHat OpenShif 4.2, fíxose posible escoller entre Jenkins e OpenShift Pipelines baseados en Tekton Pipelines.
OpenShift Pipelines baséase en Tekton, que é mellor apoiado por Pipeline a medida que se achega Code e GitOps. Nos pipelines de OpenShift, cada paso execútase no seu propio contedor, polo que os recursos só se usan mentres se executa o paso. Isto ofrece aos desenvolvedores un control total sobre as canalizacións de entrega de módulos, os complementos e o control de acceso sen un servidor central CI/CD para xestionar.
OpenShift Pipelines está actualmente en Developer Preview e está dispoñible como operador nun clúster OpenShift 4. Por suposto, os usuarios de OpenShift aínda poden usar Jenkins en RedHat OpenShift 4.
Actualizacións de xestión de programadores
En 4.2 OpenShift, a interface web actualizouse por completo tanto para desenvolvedores como para administradores.
Nas versións anteriores de OpenShift, todos traballaban en tres consolas: directorio de servizos, consola de administrador e consola de traballo. Agora o clúster divídese só en dúas partes: consola de administrador e consola de programador.
A consola para programadores recibiu melloras significativas na interface de usuario. Agora mostra de xeito máis cómodo as topoloxías das aplicacións e os seus conxuntos. Isto facilita aos desenvolvedores a creación, a implantación e a visualización de aplicacións en contedores e recursos agrupados. Permítelles centrarse no que é importante para eles.
Portal para programadores na consola de xestión de OpenShift
Oído
Odo é unha utilidade de liña de comandos orientada aos desenvolvedores que simplifica o desenvolvemento de aplicacións en OpenShift. Usando a comunicación de estilo git push, esta CLI axuda aos desenvolvedores novos en Kubernetes a crear aplicacións en OpenShift.
Integración con contornos de desenvolvemento
Os desenvolvedores agora poden construír, depurar e implantar as súas aplicacións en OpenShift sen saír do seu contorno de desenvolvemento de código favorito, como Microsoft Visual Studio, JetBrains (incluíndo IntelliJ), Eclipse Desktop, etc.
Extensión de implementación de Red Hat OpenShift para Microsoft Azure DevOps
Lanzouse a extensión Red Hat OpenShift Deployment para Microsoft Azure DevOps. Os usuarios deste conxunto de ferramentas DevOps agora poden implantar as súas aplicacións en Azure Red Hat OpenShift ou en calquera outro clúster de OpenShift directamente desde Microsoft Azure DevOps.
Transición da terceira versión á cuarta
Xa que estamos a falar dunha nova versión, e non dunha actualización, non podes poñer a cuarta versión encima da terceira. Non se admitirá a actualización da versión 3 á versión 4..
Pero hai boas noticias: Red Hat ofrece ferramentas para migrar proxectos da 3.7 á 4.2. Pode migrar as cargas de traballo das aplicacións mediante a ferramenta de migración de aplicacións en clúster (CAM). CAM permítelle controlar a migración e minimizar o tempo de inactividade das aplicacións.
OpenShift 4.3
As principais novidades descritas neste artigo apareceron na versión 4.2. Os cambios 4.3 publicados recentemente non son tan grandes, pero aínda hai algunhas cousas novas. A lista de cambios é bastante extensa, aquí están os máis significativos na nosa opinión:
Actualiza a versión de Kubernetes á 1.16.
A versión actualizouse en dous pasos á vez en OpenShift 4.2 era 1.14.
Cifrado de datos en etcd
A partir da versión 4.3, fíxose posible cifrar os datos na base de datos etcd. Unha vez habilitado o cifrado, será posible cifrar os seguintes recursos da API de OpenShift e da API de Kubernetes: segredos, ConfigMaps, rutas, tokens de acceso e autorización OAuth.
Leme
Engadiuse soporte para a versión 3 de Helm, un popular xestor de paquetes para Kubernetes. Polo momento, o soporte ten o estado TECHNOLOGY PREVIEW. A compatibilidade de Helm ampliarase ata o soporte total nas futuras versións de OpenShift. A utilidade helm cli vén con OpenShift e pódese descargar desde a consola web de xestión de clústeres.
Actualización do panel do proxecto
Na nova versión, Project Dashboard ofrece información adicional na páxina do proxecto: estado do proxecto, utilización de recursos e cotas do proxecto.
Mostrando vulnerabilidades para Quay na consola web
Engadiuse unha función á consola de xestión para mostrar vulnerabilidades coñecidas para imaxes nos repositorios de Quay. Admítese a visualización de vulnerabilidades para repositorios locais e externos.
Creación simplificada de operadorhub offline
No caso de implantar un clúster OpenShift nunha rede illada, desde a cal o acceso a Internet é limitado ou ausente, simplifícase a creación dun "espelo" para o rexistro de OperatorHub. Agora pódese facer con só tres equipos.
Os autores:
Víctor Puchkov, Yuri Semenyukov
Fonte: www.habr.com