Get best of the week

Quoi de neuf dans Red Hat OpenShift 4.2 et 4.3?


La quatrième version d'OpenShift est sortie relativement récemment. La version actuelle 4.3 est disponible à partir de fin janvier et toutes les modifications apportées sont soit quelque chose de complètement nouveau, qui n'était pas dans la troisième version, soit une mise à jour majeure de ce qui est apparu dans la version 4.1. Tout ce que nous allons vous dire maintenant, vous devez connaître, comprendre et considérer ceux qui travaillent avec OpenShift et envisagent de passer à la nouvelle version.

Avec la sortie d'OpenShift 4.2, Red Hat a simplifié Kubernetes. De nouveaux outils et plugins pour créer des conteneurs, des pipelines CI / CD et des déploiements sans serveur sont apparus. Les innovations permettent aux développeurs de se concentrer sur l'écriture de code plutôt que sur les litiges avec Kubernetes.

En fait, quoi de neuf dans les versions d'OpenShift 4.2 et 4.3?

Se diriger vers des nuages ​​hybrides


Lors de la planification d'une nouvelle infrastructure informatique ou du développement d'un paysage informatique existant, les entreprises envisagent de plus en plus l'approche cloud pour fournir des ressources informatiques, pour lesquelles elles mettent en œuvre des solutions de cloud privé, ou utilisent la puissance des fournisseurs de cloud public. Ainsi, les infrastructures informatiques modernes sont de plus en plus construites sur un modèle de cloud «hybride», lorsque des ressources sur site et des ressources de cloud public avec un système de gestion commun sont utilisées. Red Hat OpenShift 4.2 est spécialement conçu pour simplifier la transition vers un modèle de cloud hybride et facilite la connexion des ressources de fournisseurs tels qu'AWS, Azure et Google Cloud Platform au cluster avec des clouds privés sur VMware et OpenStack.

Nouvelle approche d'installation


Dans la version 4, l'approche d'installation d'OpenShift a changé. Red Hat fournit un utilitaire spécial pour déployer un cluster OpenShift - openshift-install. L'utilitaire est le seul fichier binaire écrit en Go. Openshit-installer prépare un fichier yaml avec la configuration requise pour le déploiement.

Dans le cas d'une installation utilisant des ressources cloud, vous devrez spécifier les informations minimales sur le futur cluster: zone DNS, nombre de nœuds de travail, paramètres spécifiques pour le fournisseur cloud, informations de compte pour l'accès au fournisseur cloud. Après avoir préparé le fichier de configuration, le cluster peut être déployé avec une seule commande.

Si l'installation sur vos propres ressources informatiques, par exemple, lors de l'utilisation d'un cloud privé (vSphere et OpenStack sont pris en charge) ou lors de l'installation sur des serveurs bare metal, vous devrez configurer manuellement l'infrastructure - préparer le nombre minimum de machines virtuelles ou de serveurs physiques nécessaires pour créer un cluster de plan de contrôle, configurer services de réseau. Après cette configuration, le cluster OpenShift peut être créé de manière similaire avec une seule commande d'utilitaire openshift-installer.

Mises à jour de l'infrastructure


Intégration avec CoreOS


Une mise à jour clé est l'intégration avec Red Hat CoreOS. Désormais, les nœuds principaux Red Hat OpenShift ne peuvent fonctionner que sur le nouveau système d'exploitation. Il s'agit d'un système d'exploitation gratuit de Red Hat spécialement conçu pour les solutions conteneurisées. Red Hat CoreOS est un Linux léger optimisé pour l'exécution de conteneurs.

Si en 3.11 le système d'exploitation et OpenShift existaient séparément, alors en 4.2 il est inextricablement lié à OpenShift. Il s'agit maintenant d'une seule appliance - une infrastructure immuable.


Pour les clusters qui utilisent RHCOS pour tous les nœuds, la mise à jour d'OpenShift Container Platform est un processus simple et bien automatisé.

Auparavant, pour mettre à jour OpenShift, il était d'abord nécessaire de mettre à jour le système d'exploitation sous-jacent sur lequel le produit s'exécutait (à l'époque c'était Red Hat Enterprise Linux). Ce n'est qu'après cela qu'il a été possible de mettre à jour OpenShift progressivement, nœud par nœud. Il n'a été question d'aucune automatisation du processus.

Maintenant, puisque la plate-forme OpenShift Container contrôle entièrement les systèmes et services sur chaque nœud, y compris le système d'exploitation, cette tâche est résolue en appuyant sur un bouton de l'interface Web. Après cela, un opérateur spécial est lancé à l'intérieur du cluster OpenShift, qui contrôle l'ensemble du processus de mise à jour.

Nouveau CSI


Le second est le nouveau CSI, le contrôleur d'interface de stockage, qui vous permet de connecter divers systèmes de stockage externes au cluster OpenShift. Un grand nombre de fournisseurs de pilotes de stockage pour OpenShift sont pris en charge en fonction des pilotes de stockage écrits par les fournisseurs de stockage eux-mêmes. Une liste complète des pilotes CSI pris en charge se trouve dans ce document: https://kubernetes-csi.imtqy.com/docs/drivers.html . Dans cette liste, vous pouvez trouver tous les principaux modèles de baies de disques des principaux fabricants (Dell / EMC, IBM, NetApp, Hitachi, HPE, PureStorage), les solutions SDS (Ceph) et le stockage cloud (AWS, Azure, Google). OpenShift 4.2 prend en charge l'utilisation des pilotes CSI de la spécification CSI version 1.1.

RedHat OpenShift Service Mesh


Basé sur les projets Istio, Kiali et Jaeger - Red Hat OpenShift Service Mesh, en plus des tâches habituelles de routage des requêtes entre services, il vous permet de les suivre et de les visualiser. Cela aide les développeurs à simplifier l'interaction, la surveillance et la gestion des applications déployées dans Red Hat OpenShift.


Visualisation d'une application avec une architecture de microservices à l'aide de Kiali

Pour simplifier l'installation, le service et la gestion du cycle de vie de Service Mesh, Red Hat OpenShift fournit aux administrateurs un opérateur spécial - Service Mesh Operator. Il s'agit de l'opérateur Kubernetes, qui vous permet de déployer les packages Istio, Kiali et Jaeger reconfigurés sur le cluster, minimisant ainsi la charge administrative de la gestion des applications.

CRI-O au lieu de Docker


Le Docker d'exécution par défaut du conteneur Docker a été remplacé par CRI-O. CRI-O pouvait déjà être utilisé dans la version 3.11, mais en 4.2, il est devenu le principal. Pas bon et pas mal, mais mérite d'être gardé à l'esprit lors de l'utilisation du produit.

Opérateurs et déployer des applications


Opérateurs - une nouvelle entité pour RedHat OpenShift, qui est apparue dans la quatrième version. Il s'agit d'une méthode pour empaqueter, déployer et gérer l'application Kubernetes. Il peut être imaginé comme un plugin pour les applications déployées dans des conteneurs gérés à l'aide de l'API Kubernetes et des outils kubectl.

Les opérateurs Kubernetes aident à automatiser toutes les tâches liées à l'administration et à la gestion du cycle de vie d'une application que vous déployez dans votre cluster. Par exemple, un opérateur peut automatiser les mises à jour, sauvegarder et faire évoluer une application, modifier la configuration, etc. Une liste complète des opérateurs est disponible sur https://operatorhub.io/ .

OperatorHub est disponible directement à partir de l'interface Web de la console de gestion. Il s'agit d'un catalogue d'applications pour OpenShift géré par Red Hat. Ceux. tous les opérateurs approuvés par Red Hat seront couverts par le support du fournisseur.


Portail OperatorHub dans OpenShift Management Console

Image de base universelle


Il s'agit d'un ensemble standardisé d'images RHEL OS que vous pouvez utiliser pour créer vos applications dans des conteneurs. Il existe des ensembles minimes, standard et complets. Ils prennent très peu de place, prennent en charge tous les packages et langages de programmation installés nécessaires.

Outils CI / CD


RedHat OpenShif 4.2 a la possibilité de choisir entre Jenkins et OpenShift Pipelines basé sur Tekton Pipelines.

OpenShift Pipelines est basé sur Tekton, qui est mieux pris en charge par le Pipeline à l'approche du Code et de GitOps. Dans les pipelines OpenShift, chaque étape est exécutée dans son propre conteneur, les ressources sont donc utilisées uniquement pendant l'exécution de l'étape. Cela donne aux développeurs un contrôle complet sur les pipelines de livraison de modules, les plug-ins et le contrôle d'accès sans serveur central CI / CD pour la gestion.

OpenShift Pipelines est actuellement en phase de prévisualisation pour les développeurs et est disponible en tant qu'opérateur sur le cluster OpenShift 4. Bien sûr, les utilisateurs d'OpenShift peuvent toujours utiliser Jenkins dans RedHat OpenShift 4.

Mises à jour de gestion pour les développeurs


Dans 4.2, OpenShift a complètement mis à jour l'interface Web pour les développeurs et les administrateurs.

Dans les versions précédentes d'OpenShift, tout le monde travaillait sur trois consoles: un catalogue de services, une console d'administration et une console de travail. Maintenant, le cluster est divisé en seulement deux parties: la console administrateur et la console développeur.

La console du développeur a reçu d'importantes améliorations de l'interface utilisateur. Il est désormais plus pratique d'afficher les topologies d'applications et leurs assemblages. Les développeurs peuvent ainsi créer, déployer et visualiser plus facilement des applications conteneurisées et des ressources de cluster. Vous permet de vous concentrer sur ce qui est important pour eux.


Portail des développeurs dans la console de gestion OpenShift

Odo


Odo est un utilitaire de ligne de commande orienté développeur qui simplifie le développement d'applications dans OpenShift. En utilisant l'interaction de style git push, cette CLI aide les développeurs novices à créer des applications Kubernetes dans OpenShift.

Intégration avec les environnements de développement


Les développeurs peuvent désormais créer, déboguer et déployer leurs applications dans OpenShift sans quitter leur environnement de développement de code préféré, comme Microsoft Visual Studio, JetBrains (y compris IntelliJ), Eclipse Desktop, etc.

Extension Red Hat OpenShift Deployment pour Microsoft Azure DevOps


L'extension Red Hat OpenShift Deployment pour Microsoft Azure DevOps est apparue. Désormais, les utilisateurs de cette boîte à outils DevOps peuvent déployer leurs applications sur Azure Red Hat OpenShift ou tout autre cluster OpenShift directement à partir de Microsoft Azure DevOps.

Transition de la troisième version à la quatrième


Puisque nous parlons d'une nouvelle version, pas d'une mise à jour, il n'est pas si facile de prendre et de mettre la quatrième version au-dessus de la troisième. La mise à jour de la troisième à la quatrième version ne sera pas prise en charge .

Mais il y a une bonne nouvelle: Red Hat fournit des outils pour déplacer des projets de 3.7 à 4.2. Vous pouvez transférer des charges de travail d'application avec l'outil de migration d'application de cluster (CAM). CAM vous permet de contrôler la migration et de minimiser les temps d'arrêt des applications.

Openshift 4.3


Les principales innovations décrites dans cet article sont apparues dans la version 4.2. Dans la version 4.3 récemment publiée, les changements ne sont pas si importants, mais il y a encore quelque chose de nouveau. La liste des changements est assez longue, nous donnons les plus significatifs à notre avis:

Mettez à jour la version de Kubernetes à 1.16.


La version a été immédiatement mise à niveau en deux étapes, dans OpenShift 4.2, elle était de 1,14.

Chiffrement des données dans etcd


À partir de la version 4.3, il est devenu possible de crypter les données dans la base de données etcd. Une fois le cryptage activé, il sera possible de crypter les ressources OpenShift API et Kubernetes API suivantes: Secrets, ConfigMaps, Routes, jetons d'accès et autorisation OAuth.

Barre


Ajout de la prise en charge de Helm 3rd version - un gestionnaire de packages populaire pour Kubernetes. Jusqu'à présent, le support a le statut de PREVIEW TECHNOLOGIQUE. Dans les futures versions d'OpenShift, la prise en charge de Helm sera étendue à 100%. L'utilitaire helm cli est fourni avec OpenShift et peut être téléchargé à partir de la console Web de gestion de cluster.

Mise à jour du tableau de bord du projet


Dans la nouvelle version de Project Dashboard fournit des informations supplémentaires sur la page du projet: état du projet, utilisation des ressources et quotas pour le projet.

Afficher les vulnérabilités de quai dans la console Web


Ajout de la fonction d'affichage des vulnérabilités connues des images dans les référentiels Quay à la console de gestion. Le mappage des vulnérabilités pour les référentiels locaux et externes est pris en charge.

Création simplifiée de hub opérateur hors ligne


Dans le cas du déploiement d'un cluster OpenShift sur un réseau isolé, dont l'accès Internet est limité ou absent, la création d'un «miroir» pour le registre OperatorHub est simplifiée. Maintenant, cela peut être fait avec seulement trois équipes.

Auteur: Yuri Semenyukov

More articles:


All Articles