La quatrième version d'OpenShift est sortie récemment. La version actuelle, 4.3, est disponible depuis fin janvier et toutes les modifications qu'elle apporte sont soit totalement nouvelles, ce qui n'était pas présent dans la version 3, soit de grandes mises à jour de ce qui est apparu dans la version 4.1. Tout ce que nous allons décrire ici est essentiel à connaître, à comprendre et à considérer pour ceux qui travaillent avec OpenShift et prévoient de passer à la nouvelle version.
Avec le lancement de la version OpenShift 4.2, Red Hat a simplifié l'utilisation de Kubernetes. De nouveaux outils et plugins ont été introduits pour la création de conteneurs, les pipelines CI/CD et les déploiements serverless. Ces innovations permettent aux développeurs de se concentrer sur l'écriture de code plutôt que sur la gestion de Kubernetes.
Quelles sont donc les nouveautés dans les versions OpenShift 4.2 et 4.3 ?
Tendance vers les clouds hybrides
Lors de la planification d'une nouvelle infrastructure informatique ou lors de l'évolution du paysage informatique existant, les entreprises envisagent de plus en plus l'approche cloud pour fournir des ressources informatiques, en mettant en œuvre des solutions de cloud privé ou en utilisant les capacités des fournisseurs de cloud public. Ainsi, les infrastructures informatiques modernes sont de plus en plus construites selon un modèle de cloud hybride, utilisant à la fois des ressources on-premises et des ressources publiques, avec un système de gestion commun. Red Hat OpenShift 4.2 a été spécifiquement conçu pour faciliter la transition vers le modèle de cloud hybride et permet de connecter facilement au cluster des ressources de fournisseurs tels qu'AWS, Azure et Google Cloud Platform, par rapport à l'utilisation de clouds privés sur VMware et OpenStack.
Une nouvelle approche de l'installation
Dans la quatrième version, l'approche d'installation d'OpenShift a changé. Red Hat fournit un utilitaire spécial pour déployer un cluster OpenShift – openshift-install. Cet utilitaire est un seul fichier binaire, écrit en Go. L'openshift-installer prépare un fichier yaml avec la configuration requise pour le déploiement.
Lors de l'installation à l'aide de ressources cloud, il sera nécessaire d'indiquer les informations minimales sur l'avenir du cluster : zone DNS, nombre de nœuds worker, paramètres spécifiques au fournisseur de cloud et données de compte pour accéder au fournisseur de cloud. Après avoir préparé le fichier de configuration, le cluster peut être déployé en une seule commande.
En cas d'installation sur des ressources informatiques propres, par exemple lors de l'utilisation d'un cloud privé (vSphere et OpenStack pris en charge) ou sur des serveurs bare metal, une configuration manuelle de l'infrastructure sera nécessaire – préparer le nombre minimal de machines virtuelles ou de serveurs physiques nécessaires à la création d'un cluster Control Plane, configurer les services réseau. Après cette configuration, le cluster OpenShift pourra être créé de manière similaire par une seule commande de l'outil openshift-installer.
Mises à jour de l'infrastructure
Intégration avec CoreOS
La mise à jour clé est l'intégration avec Red Hat CoreOS. Désormais, les nœuds master de Red Hat OpenShift peuvent fonctionner uniquement sous un nouveau système d'exploitation. C'est un système d'exploitation gratuit de Red Hat, spécifiquement conçu pour les solutions conteneurisées. Red Hat CoreOS est un Linux allégé, optimisé pour exécuter des conteneurs.
Alors qu'en 3.11 le système d'exploitation et OpenShift existaient séparément, en 4.2 ils sont désormais indissociables d'OpenShift. C'est maintenant un appareil unique – infrastructure immuable.
Pour les clusters qui utilisent RHCOS pour tous les nœuds, la mise à jour de la plateforme OpenShift Container est un processus simple et bien automatisé.
Auparavant, pour mettre à jour OpenShift, il fallait d'abord mettre à jour le système d'exploitation de base sur lequel le produit était exécuté (à l'époque, il s'agissait de Red Hat Enterprise Linux). Ce n'est qu'après cela que l'on pouvait mettre à jour OpenShift progressivement, nœud par nœud. Il n'y avait aucune automatisation dans le processus.
Maintenant, puisque la plateforme OpenShift Container contrôle entièrement les systèmes et services sur chaque nœud, y compris l'OS, cette tâche se fait d'un simple clic depuis l'interface Web. Ensuite, un opérateur spécial est lancé à l'intérieur du cluster OpenShift, gérant tout le processus de mise à jour.
Nouveau CSI
Deuxièmement – un nouveau CSI – contrôleur de l'interface de stockage qui permet de connecter différents systèmes de stockage externes au cluster OpenShift. Un grand nombre de fournisseurs de pilotes de stockage pour OpenShift, basés sur les pilotes de stockage fournis par les fabricants, sont pris en charge. La liste complète des pilotes CSI pris en charge peut être trouvée dans ce document : . Dans cette liste, vous pouvez trouver tous les principaux modèles de systèmes de stockage des principaux fabricants (Dell/EMC, IBM, NetApp, Hitachi, HPE, PureStorage), des solutions SDS (Ceph) et des stockages en nuage (AWS, Azure, Google). OpenShift 4.2 prend en charge le fonctionnement avec 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 les services, permet de réaliser leur traçabilité et leur visualisation. Cela aide les développeurs à simplifier l'interaction, la surveillance et la gestion de l'application déployée dans Red Hat OpenShift.
Visualisation d'une application ayant une architecture microservices avec Kiali
Pour simplifier au maximum les processus d'installation, de service et de gestion du cycle de vie du Service Mesh, Red Hat OpenShift fournit aux administrateurs un opérateur spécial – le Service Mesh Operator. C'est un opérateur Kubernetes qui permet de déployer sur le cluster des packages reconfigurés de Istio, Kiali et Jaeger, allégeant ainsi la charge administrative de la 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 4.2, il est devenu principal. Ce n'est ni bon ni mauvais, mais il convient de le 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, qui est apparue dans la quatrième version. C'est une méthode d’emballage, de déploiement et de gestion des applications Kubernetes. On peut le considérer comme un plugin géré par l'API Kubernetes et des outils kubectl pour les applications déployées dans des conteneurs.
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 dans votre cluster. Par exemple, un opérateur peut automatiser les mises à jour, les sauvegardes et le redimensionnement de l'application, modifier la configuration, etc. La liste complète des opérateurs peut être consultée sur .
OperatorHub est accessible directement depuis l'interface web de la console de gestion. C'est un catalogue d'applications pour OpenShift, soutenu par Red Hat. Cela signifie que tous les opérateurs approuvés par Red Hat bénéficieront d'un support vendor.
Le portail OperatorHub dans la console de gestion OpenShift
Image de base universelle
C'est un ensemble standardisé d'images du système d'exploitation RHEL, que vous pouvez utiliser pour créer vos applications dans des conteneurs. Il existe des ensembles minimal, standard et complet. Ils occupent très peu d'espace, prennent en charge tous les packages nécessaires et les langages de programmation.
Outils CI/CD
Dans RedHat OpenShift 4.2, il est possible de choisir entre Jenkins et OpenShift Pipelines basé sur Tekton Pipelines.
OpenShift Pipelines est basé sur Tekton, qui soutient mieux les approches Pipeline as Code et GitOps. Dans les pipelines OpenShift, chaque étape s'exécute dans son propre conteneur, ce qui fait que les ressources ne sont utilisées que pendant l'exécution de l'étape. Cela donne aux développeurs un contrôle total sur les pipelines de livraison de modules, les plugins et le contrôle d'accès sans serveur CI/CD central pour la gestion.
OpenShift Pipelines est actuellement en phase Preview pour les développeurs et est disponible en tant qu'opérateur sur le cluster OpenShift 4. Bien entendu, les utilisateurs d'OpenShift peuvent continuer à utiliser Jenkins dans RedHat OpenShift 4.
Mises à jour de gestion pour les développeurs
Dans la version 4.2, OpenShift a complètement remanié l'interface web tant pour les développeurs que pour les administrateurs.
Dans les versions précédentes d'OpenShift, tout se passait dans trois consoles : le catalogue de services, la console administrateur et la console de travail. Maintenant, le cluster est divisé en seulement deux parties : la console administrateur et la console développeur.
La console développeur a reçu d'importantes améliorations de l'interface utilisateur. Elle affiche maintenant plus clairement les topologies des applications et leurs builds. Cela facilite aux développeurs la création, le déploiement et la visualisation des applications conteneurisées et des ressources du cluster. Cela leur permet de se concentrer sur ce qui est important pour eux.
Portail développeur dans la console de gestion OpenShift
Odo
Odo est un outil de ligne de commande conçu pour les développeurs, simplifiant le développement d'applications dans OpenShift. En utilisant une interaction de type git push, cette CLI aide les développeurs qui ne sont pas familiers avec 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 préféré, comme Microsoft Visual Studio, JetBrains (y compris IntelliJ), Eclipse Desktop, etc.
Extension de déploiement Red Hat OpenShift pour Microsoft Azure DevOps
Une extension Red Hat OpenShift Deployment pour Microsoft Azure DevOps est désormais disponible. Les utilisateurs de cet ensemble d'outils DevOps peuvent déployer leurs applications sur Azure Red Hat OpenShift ou tout autre cluster OpenShift directement depuis Microsoft Azure DevOps.
Passage de la version trois à la version quatre
Comme il s'agit d'une nouvelle version et non d'une mise à jour, il n'est pas si simple d'installer la quatrième version par-dessus la troisième. La mise à jour de la version trois vers la version quatre ne sera pas prise en charge..
Mais il y a une bonne nouvelle : Red Hat fournit des outils pour migrer des projets de la version 3.7 vers 4.2. Vous pouvez transférer les charges de travail des applications à l'aide de l'outil Cluster Application Migration (CAM). CAM offre un contrôle sur la migration et permet de minimiser le temps d'arrêt des applications.
OpenShift 4.3
Les principales nouveautés décrites dans cet article sont apparues dans la version 4.2. Dans la nouvelle version 4.3, les changements ne sont pas aussi significatifs, mais il y a tout de même quelques nouveautés. La liste des changements est suffisamment vaste, voici les plus importants selon nous :
Mise à jour de la version Kubernetes vers 1.16.
La version a été mise à niveau de deux étapes, OpenShift 4.2 était à 1.14.
Chiffrement des données dans etcd
À partir de la version 4.3, la possibilité de chiffrer les données dans la base etcd a été ajoutée. 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 d'autorisation OAuth.
Helm
Ajout de la prise en charge de la version Helm 3 – un gestionnaire de paquets populaire pour Kubernetes. Pour l'instant, la prise en charge a le statut de TECHNOLOGY PREVIEW. Dans les futures versions d'OpenShift, le support de Helm sera étendu à un niveau complet. L'outil helm cli est inclus avec OpenShift et peut être téléchargé depuis la console Web de gestion du cluster.
Mise à jour du Project Dashboard
Dans la nouvelle version, le Project Dashboard fournit des informations supplémentaires sur la page du projet : statut du projet, utilisation des ressources et quotas pour le projet.
Affichage des vulnérabilités pour Quay dans la console Web
La console de gestion a ajouté une fonctionnalité d'affichage des vulnérabilités connues pour les images dans les dépôts Quay. Il est possible d'afficher les vulnérabilités pour les dépôts locaux et externes.
La création d'operatorhub hors ligne a été simplifiée.
Pour le déploiement d'un cluster OpenShift dans un réseau isolé, dont l'accès à Internet est limité ou inexistant, la création d'un « miroir » pour le registre OperatorHub a été simplifiée. Cela pourra désormais être réalisé en seulement trois commandes.
Auteurs :
Victor Pouchkov, Youri Sémenyoukov
Source : habr.com
