La quatrième version d'OpenShift est sortie relativement récemment. La version actuelle 4.3 est disponible depuis fin janvier et tous les changements qu'elle contient 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 doit être connu, compris et pris en compte par ceux qui travaillent avec OpenShift et envisagent de passer à une nouvelle version.
Avec la sortie d'OpenShift 4.2, Red Hat a facilité l'utilisation de Kubernetes. De nouveaux outils et plugins sont apparus pour créer des conteneurs, des pipelines CI/CD et des déploiements sans serveur. Les innovations donnent aux développeurs la possibilité de se concentrer sur l'écriture de code et non sur Kubernetes.
Au fait, quoi de neuf dans les versions d'OpenShift 4.2 et 4.3 ?
Vers des cloud 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 une 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 selon 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, ainsi que l'utilisation de cloud privés sur VMware et OpenStack.
Nouvelle approche de l'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 un seul fichier binaire écrit en Go. Openshit-installer prépare un fichier yaml avec la configuration requise pour le déploiement.
En cas d'installation utilisant des ressources cloud, vous devrez spécifier des informations minimales sur le futur cluster : zone DNS, nombre de nœuds de travail, paramètres spécifiques au fournisseur de cloud, informations de compte pour accéder au fournisseur de cloud. Après avoir préparé le fichier de configuration, le cluster peut être déployé avec une seule commande.
En cas d'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 d'une installation sur des serveurs bare metal, vous devrez configurer manuellement l'infrastructure - préparer le nombre minimum de machines virtuelles ou serveurs physiques requis pour créer un cluster de plan de contrôle, configurer les services réseau. Après cette configuration, un cluster OpenShift peut être créé de la même manière avec une seule commande de l'utilitaire openshift-installer.
Mises à jour des infrastructures
Intégration CoreOS
La mise à jour clé est l'intégration avec Red Hat CoreOS. Les nœuds maîtres Red Hat OpenShift peuvent désormais fonctionner seulement 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 de conteneurs. Red Hat CoreOS est un Linux léger optimisé pour l'exécution de conteneurs.
Si dans la version 3.11 le système d'exploitation et OpenShift existaient séparément, alors dans la version 4.2 il est inextricablement lié à OpenShift. Il s’agit désormais d’une seule appliance : une infrastructure immuable.
Pour les clusters qui utilisent RHCOS pour tous les nœuds, la mise à niveau d'OpenShift Container Platform est un processus simple et hautement automatisé.
Auparavant, pour mettre à jour OpenShift, vous deviez d'abord mettre à jour le système d'exploitation sous-jacent sur lequel le produit était exécuté (à l'époque, Red Hat Enterprise Linux). Ce n’est qu’alors qu’OpenShift pourra être mis à jour progressivement, nœud par nœud. Il n'a pas été question d'automatisation du processus.
Désormais, étant donné que OpenShift Container Platform 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
Deuxièmement, le nouveau CSI est un 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 sur la base de pilotes de stockage écrits par les fabricants de systèmes de stockage eux-mêmes. Une liste complète des pilotes CSI pris en charge peut être trouvée dans ce document : . Dans cette liste, vous trouverez tous les principaux modèles de baies de disques des principaux fabricants (Dell/EMC, IBM, NetApp, Hitachi, HPE, PureStorage), de solutions SDS (Ceph) et de stockage cloud (AWS, Azure, Google). OpenShift 4.2 prend en charge les pilotes CSI de la spécification CSI version 1.1.
Maillage de services RedHat OpenShift
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, permet leur traçage et leur visualisation. Cela aide les développeurs à communiquer, surveiller et gérer facilement une application déployée dans Red Hat OpenShift.
Visualisation d'une application ayant une architecture microservice à l'aide de Kiali
Pour simplifier autant que possible l'installation, la maintenance et la gestion du cycle de vie de Service Mesh, Red Hat OpenShift fournit aux administrateurs un opérateur spécial, le Service Mesh Operator. Il s'agit d'un opérateur Kubernetes qui vous permet de déployer des packages Istio, Kiali et Jaeger reconfigurés sur un cluster, maximisant ainsi la charge administrative de gestion des applications.
CRI-O au lieu de Docker
Le runtime de conteneur par défaut Docker a été remplacé par CRI-O. Il était déjà possible d'utiliser CRI-O dans la version 3.11, mais dans la version 4.2, il est devenu le principal. Ni bon ni mauvais, mais quelque chose à garder à l'esprit lors de l'utilisation du produit.
Opérateurs et déploiement d'applications
Les opérateurs sont une nouvelle entité pour RedHat OpenShift, apparue dans la quatrième version. Il s'agit d'une méthode de packaging, de déploiement et de gestion d'une application Kubernetes. Il peut être considéré comme un plugin pour les applications déployées dans des conteneurs, piloté par l'API Kubernetes et les outils kubectl.
Les opérateurs Kubernetes aident à automatiser toutes les tâches liées à l'administration et à la gestion du cycle de vie de l'application que vous déployez sur votre cluster. Par exemple, l'opérateur peut automatiser les mises à jour, les sauvegardes et la mise à l'échelle de l'application, modifier la configuration, etc. Une liste complète des opérateurs peut être trouvée sur .
OperatorHub est accessible directement depuis l’interface web de la console de gestion. Il s'agit d'un répertoire 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 la console de gestion OpenShift
Image de base universelle
Il s'agit d'un ensemble standardisé d'images du système d'exploitation RHEL qui peuvent être utilisées pour créer vos applications conteneurisées. Il existe des ensembles minimaux, standards et complets. Ils prennent très peu de place et prennent en charge tous les packages installés et langages de programmation nécessaires.
Outils CI/CD
Dans RedHat OpenShif 4.2, il est devenu possible de choisir entre Jenkins et OpenShift Pipelines basés sur Tekton Pipelines.
OpenShift Pipelines est basé sur Tekton, qui est mieux pris en charge par Pipeline à mesure que Code et GitOps s'approchent. Dans les pipelines OpenShift, chaque étape s'exécute dans son propre conteneur, de sorte que les ressources ne sont utilisées que pendant l'exécution de l'étape. Cela donne aux développeurs un contrôle complet sur les pipelines de livraison de modules, les plugins et le contrôle d'accès sans avoir à gérer un serveur CI/CD central.
OpenShift Pipelines est actuellement en version Developer Preview et disponible en tant qu'opérateur sur un cluster OpenShift 4. Bien entendu, les utilisateurs d'OpenShift peuvent toujours utiliser Jenkins sur RedHat OpenShift 4.
Mises à jour de la gestion des développeurs
Dans OpenShift 4.2, l'interface Web a été entièrement mise à jour pour les développeurs et les administrateurs.
Dans les versions précédentes d'OpenShift, tout le monde travaillait sur trois consoles : répertoire de services, console administrateur et console de travail. Désormais, le cluster est divisé en deux parties seulement : la console d'administrateur et la console de développeur.
La console développeur a reçu des améliorations significatives de l'interface utilisateur. Désormais, il affiche plus facilement les topologies des applications et leurs assemblys. Cela permet aux développeurs de créer, déployer et visualiser plus facilement des applications conteneurisées et des ressources en cluster. Leur permet de se 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. Grâce à la communication de style git push, cette CLI aide les développeurs qui découvrent Kubernetes à créer des applications 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é, tel que Microsoft Visual Studio, JetBrains (y compris IntelliJ), Eclipse Desktop, etc.
Extension de déploiement Red Hat OpenShift pour Microsoft Azure DevOps
L'extension Red Hat OpenShift Deployment pour Microsoft Azure DevOps a été publiée. Les utilisateurs de cet ensemble d'outils DevOps peuvent désormais déployer leurs applications sur Azure Red Hat OpenShift ou tout autre cluster OpenShift directement depuis Microsoft Azure DevOps.
Transition de la troisième version à la quatrième
Puisque nous parlons d’une nouvelle version, et non d’une mise à jour, vous ne pouvez pas simplement mettre la quatrième version au-dessus de la troisième. La mise à jour de la version XNUMX vers la version XNUMX ne sera pas prise en charge..
Mais il y a une bonne nouvelle : Red Hat fournit des outils pour migrer les projets de la version 3.7 vers la version 4.2. Vous pouvez migrer les charges de travail d'application à l'aide de l'outil Cluster Application Migration (CAM). CAM vous permet de contrôler la migration et de minimiser les temps d'arrêt des applications.
quart ouvert 4.3
Les principales innovations décrites dans cet article sont apparues dans la version 4.2. Les changements récemment publiés dans la version 4.3 ne sont pas aussi importants, mais il y a encore quelques nouveautés. La liste des changements est assez longue, voici les plus significatifs à notre avis :
Mettez à jour la version de Kubernetes vers 1.16.
La version a été mise à niveau en deux étapes à la fois : dans OpenShift 4.2, elle était 1.14.
Cryptage des données dans etcd
À partir de la version 4.3, il est devenu possible de chiffrer les données dans la base de données etcd. Une fois le chiffrement activé, il sera possible de chiffrer les ressources suivantes de l'API OpenShift et de l'API Kubernetes : secrets, ConfigMaps, routes, jetons d'accès et autorisation OAuth.
Casque
Ajout de la prise en charge de Helm version 3, un gestionnaire de packages populaire pour Kubernetes. Pour l’instant, le support a le statut TECHNOLOGY PREVIEW. La prise en charge de Helm sera étendue à une prise en charge complète dans les futures versions d'OpenShift. L'utilitaire helm cli est fourni avec OpenShift et peut être téléchargé à partir de la console Web de gestion du cluster.
Mise à jour du tableau de bord du projet
Dans la nouvelle version, Project Dashboard fournit des informations supplémentaires sur la page du projet : statut du projet, utilisation des ressources et quotas du projet.
Affichage des vulnérabilités de quay dans la console Web
Une fonctionnalité a été ajoutée à la console de gestion pour afficher les vulnérabilités connues pour les images dans les référentiels Quay. L'affichage des vulnérabilités pour les référentiels locaux et externes est pris en charge.
Création simplifiée d'un hub d'opérateur hors ligne
Dans le cas du déploiement d'un cluster OpenShift dans un réseau isolé, à partir duquel l'accès à Internet est limité ou absent, la création d'un « miroir » pour le registre OperatorHub est simplifiée. Désormais, cela peut être fait avec seulement trois équipes.
Auteurs:
Victor Puchkov, Youri Semenyukov
Source: habr.com