OpenShift : qu’est-ce que c’est ?

OpenShift constitue une pla­te­forme d’ap­pli­ca­tion basée sur Ku­ber­netes. Ce logiciel est utilisé pour cons­truire des en­vi­ron­ne­ments d’ap­pli­ca­tion et de dé­ve­lop­pe­ment dé­cen­tra­li­sés et capables de mettre à l’échelle. En se basant sur OpenShift, des solutions pro­prié­taires de Platform as a Service (PaaS), Software as a Service (SaaS) et Con­tai­ners as a Service (CaaS) peuvent être im­plé­men­tées.

Ce logiciel permet une gestion complète du cycle de vie de l’ap­pli­ca­tion, y compris le dé­ve­lop­pe­ment, le dé­ploie­ment, le pilotage et la main­te­nance. Plus de 2 000 en­tre­prises à travers le monde s’appuient sur OpenShift pour héberger leurs ap­pli­ca­tions dans des en­vi­ron­ne­ments Cloud hybrides. Nous allons vous expliquer comment OpenShift fonc­tionne et ce qui rend ce logiciel si spécial.

OpenShift ne se résume pas à un produit unique. L’en­tre­prise Red Hat a plutôt fait le choix d’éditer plusieurs versions sous forme de logiciels open source sous la licence Apache. La version « in­con­tour­nable » est la « Red Hat OpenShift Container Platform » (OCP). Cette dernière est installée sous la forme d’un cluster Ku­ber­netes sur l’in­fras­truc­ture Cloud hybride d’une en­tre­prise. Un cluster OpenShift unique peut donc couvrir de multiples en­vi­ron­ne­ments de Cloud publics et privés.

À part la OpenShift Container Platform (OCP), il existe la version com­mu­nau­taire « OKD », qui portait autrefois le nom de « OpenShift Origin ». OKD constitue une dis­tri­bu­tion Ku­ber­netes per­son­na­li­sée qui s’appuie sur Ku­ber­netes pour la gestion des clusters et sur des con­te­neurs com­pa­tibles avec Open Container Ini­tia­tive (OCI). Elle comprend également des capacités de gestion du cycle de vie des ap­pli­ca­tions et des outils DevOps. Il est in­té­res­sant de noter qu’OKD constitue la fondation « en amont » du dé­ve­lop­pe­ment des autres versions d’OpenShift, de même que le projet open source Chromium se situe à la base du dé­ve­lop­pe­ment du na­vi­ga­teur Chrome.

Outre OCP et OKD, qui cons­ti­tuent des solutions « à domicile », les­quelles sont hébergées dans leur propre in­fras­truc­ture, il existe également un large éventail de solutions « gérées ». Ces dernières sont exécutées sur divers Cloud publics issus de four­nis­seurs im­por­tants, de même que sur l’in­fras­truc­ture Cloud de Red Hat. Nous nous con­cen­trons prin­ci­pa­le­ment sur la version OCP 4.8, laquelle constitue la version en vigueur au moment de la parution de cet article. Jetons un œil rapide aux dif­fé­rentes versions d’OpenShift :

OpenShift cor­res­pond à une suite de pla­te­formes d’ap­pli­ca­tions basée sur Ku­ber­netes. Ce logiciel comprend une poignée de com­po­sants de base, ainsi qu’un large éventail de fonc­tion­na­li­tés ad­di­tion­nelles. Il est possible d’héberger OpenShift dans des en­vi­ron­ne­ments très divers, parmi lesquels les machines « bare metal », les Clouds publics et privés, et les Edge Devices.

OpenShift se fonde sur une stack technique, qui constitue une pile de tech­no­lo­gies in­ter­con­nec­tées. Au niveau le plus bas, une dis­tri­bu­tion Linux spé­ci­fique est utilisée en tant que système d’ex­ploi­ta­tion. Le « Red Hat En­ter­prise Linux CoreOS » (RHCOS) auquel on a recours ici est installé sur du matériel physique ou vir­tua­lisé.

S’appuyant sur le système d’ex­ploi­ta­tion RHCOS, Ku­ber­netes est utilisé en tant que conteneur et or­ches­tra­teur de cluster. Ku­ber­netes gère le dé­ploie­ment, l’ex­ten­si­bi­lité et la gestion des ap­pli­ca­tions con­te­neu­ri­sées. On a recours à des opé­ra­teurs Ku­ber­netes pour cons­ti­tuer la couche su­pé­rieure de la stack technique. Ces dernières sont des ap­pli­ca­tions « Ku­ber­netes natives » pré­dé­ve­lop­pées et facile à installer. Outre les opé­ra­teurs, un registre de con­te­neurs est utilisé lors de la con­fi­gu­ra­tion et de l’exécution d’un cluster OpenShift.

OpenShift s’appuie sur une dis­tri­bu­tion Ku­ber­netes spé­ci­fique, laquelle utilise CRI-O en lieu et place de Docker ou de con­tai­nerd à titre d’exécution de conteneur. Rompre avec Docker comme tech­no­lo­gie sous-jacente présente des avantages en termes de sécurité et de com­pa­ti­bi­lité avec d’autres formats de con­te­neurs.

Un opérateur Ku­ber­netes est res­pon­sable de la santé d’une ap­pli­ca­tion entière. Les opé­ra­teurs couvrent l’ensemble du cycle de vie d’une ap­pli­ca­tion Ku­ber­netes, de l’ins­tal­la­tion à la main­te­nance en passant par le pilotage. Pour reprendre les mots de la notice OpenShift :

Il existe un vaste éventail d’opé­ra­teurs sur la pla­te­forme Ope­ra­to­rHub. À titre d’exemple, une grande diversité de systèmes de bases de données peuvent être intégrés sans heurt dans le cluster OpenShift quasiment sans aucun effort. Par ailleurs, on a recours à des opé­ra­teurs d’in­fras­truc­ture pour gérer le cluster.

Il s’avère que les opé­ra­teurs sont es­sen­tiels au fonc­tion­ne­ment d’OpenShift. Un opérateur Ku­ber­netes constitue une spé­cia­li­sa­tion du con­trô­leur Ku­ber­netes au niveau de l’ap­pli­ca­tion. Un con­trô­leur Ku­ber­netes supervise en per­ma­nence l’état d’une ressource et ajuste divers pa­ra­mètres comme né­ces­saire pour maintenir un état défini.

Un registre de conteneur contient des images de con­te­neurs qui sont créées en continu au fil du dé­ve­lop­pe­ment d’un logiciel. Les images sont ver­sion­nées, soumises à des vé­ri­fi­ca­tions de sécurité, et stockées dans le registre. Il est in­té­res­sant de noter qu’au sein d’OpenShift, le registre lui-même est im­plé­menté en tant qu’opérateur.

« Quay » constitue un registre développé par Red Hat avec une attention par­ti­cu­lière portée à la sécurité. Les images requises lors de l’ins­tal­la­tion du cluster OpenShift sont obtenues à partir de Quay. Ce faisant, Quay peut gérer d’autres artefacts de dé­ve­lop­pe­ment en plus des images con­te­neurs. Pour reprendre à nouveau les mots de la notice Red Hat :

Suivant le modèle de produits de dif­fé­rents niveaux défini par OpenShift OCP et OKD, de multiples versions de Quay ont été dé­ve­lop­pées :

OpenShift est développé tout en haut de Ku­ber­netes en tant que cluster de con­te­neurs. Au niveau du cluster, OpenShift comprend deux sous-niveaux :

1. Control Plane (« Plan ré­gu­la­teur »)

Le control plane est composé de ce qu’on appelle des « control plane machines ». Ces dernières sont également connues sous le nom de « Master Machines » et gèrent le cluster de l’OpenShift Container Plateform.

1. Worker Machines

Les worker machines, aussi connues sous le nom de « compute machines » (« machines de calcul »), mènent à bien le travail effectif du cluster OpenShift. Les Master machines assignent des tâches aux worker machines et su­per­vi­sent leur exécution.

Une working machine exécute les services suivants et fait donc partie du cluster OpenShift :

• CRI-O, en tant qu’en­vi­ron­ne­ment d’exécution de conteneur,
• Kubelet, en tant que service qui accepte et procède les requêtes de lancer et d’in­ter­rompre des charges de travail,
• Un serveur proxy, qui prend en charge la com­mu­ni­ca­tion entre les work machines.

La spé­cia­li­sa­tion sup­plé­men­taires des working machines résulte de l’état des con­te­neurs en cours d’exécution et du software qu’ils con­tien­nent.

Jetons un œil plus précis à la structure du control plane présentée ci-dessous. Nous éta­blis­sons une dis­tinc­tion entre les com­po­sants de l’im­plé­men­ta­tion Ku­ber­netes et les com­po­sants spé­ci­fiques à OpenShift :

Les com­po­sants du control plane spé­ci­fiques à OpenShift sont im­plé­men­tés en tant qu’opé­ra­teurs :

La pla­te­forme de con­te­neurs OpenShift est d’abord utilisée pour cons­truire des en­vi­ron­ne­ments d’ap­pli­ca­tion et de dé­ve­lop­pe­ment. Ceci rend possible l’im­plé­men­ta­tion de solutions PaaS, SaaS et CaaS propres à l’en­tre­prise. Compte tenu de la puissance et de la com­plexité de ce logiciel, OpenShift est d’abord utilisé pour des projets au long cours dirigés par d’im­por­tantes or­ga­ni­sa­tions.

Parmi les uti­li­sa­teurs d’OpenShift, on retrouve des gou­ver­ne­ments et des instituts de recherche à l’échelle nationale, de même que des en­tre­prises présentes à l’in­ter­na­tio­nal telles que des banques et des com­pag­nies d’assurance. Les groupes d’uti­li­sa­teurs sus­men­tion­nés bé­né­fi­cient tous de dé­ploie­ments de Cloud hybrides. Le dé­ploie­ment par-delà les limites du Cloud privé et public permet à des parties de l’in­fras­truc­ture d’être hébergées en res­pec­tant les di­rec­tives de con­for­mité locales.

Parmi les autres aspects im­por­tants qui cons­ti­tuent des atouts pour OpenShift, on peut noter son haut niveau de sécurité. Prévenir les cyber in­tru­sions et les fuites de données re­pré­sente un enjeu capital pour les en­tre­prises in­ter­na­tio­nales de grande taille. Les brèches de sécurité peuvent nuire du­ra­ble­ment à l’image de l’en­tre­prise et entraîner des dommages fi­nan­ciers non né­gli­geables.

Les fonc­tion­na­li­tés que comprend OpenShift per­met­tent d’accélérer l’éla­bo­ra­tion des ap­pli­ca­tions. Ceci permet de réduire les périodes de dé­ve­lop­pe­ment sur le terrain ; les équipes in­for­ma­tiques en interne peuvent con­for­ta­ble­ment gérer leurs res­sources par elles-mêmes et pousser plus avant le dé­ve­lop­pe­ment sans in­ter­rup­tion.

Si une en­tre­prise a recours à l’une des offres OpenShift gérées, cela la dispense du besoin d’ad­mi­nis­trer ses serveurs et systèmes d’ex­ploi­ta­tion. Au lieu de se préoc­cu­per des mises à jour et des sau­ve­gardes, l’en­tre­prise peut se con­cen­trer sur l’essentiel : innover et créer de la valeur pour le con­som­ma­teur.

Il est évident qu’OpenShift n’a pas été conçu pour les petites en­tre­prises et les dé­ve­lop­peurs in­di­vi­duels. Pour répondre aux besoins de ces derniers, il est pré­fé­rable d’opter pour l’une des al­ter­na­tives à OpenShift ou des al­ter­na­tives à Ku­ber­netes.

Parmi les prin­ci­paux avantages d’un OpenShift, par rapport à un « simple » Ku­ber­netes, il convient de souligner ses pa­ra­mètres d’uti­li­sa­tion clé-en-main. Ces derniers dépassent de loin la gestion de clusters de Ku­ber­netes. Entre autres, OpenShift offre des fonc­tion­na­li­tés pour :

• L’ap­pli­ca­tion réseau à dé­fi­ni­tion lo­gi­cielle (SDN)
• Le routage
• L’au­then­ti­fi­ca­tion
• La su­per­vi­sion et la gestion des logs

Pour gérer la pla­te­forme, OpenShift inclut une interface Web puissante en plus des outils de ligne de commande obli­ga­toires. Les flux de dé­ve­lop­pe­ment et de DevOps s’en trouvent accélérés, au moyen des « Red Hat OpenShift Pipelines ». On a recours à la structure Tekton pour l’« In­té­gra­tion continue » / « Dé­ve­lop­pe­ment Continu » (CI/CD). Outre les ap­pli­ca­tions con­te­neu­ri­sées, des approches modernes « sans serveurs », basées sur « Ku­ber­netes Sans Serveur » (Knative), peuvent être utilisées.

Un autre point auquel OpenShift est attentif est le fait de fournir des ar­chi­tec­tures de mi­cro­ser­vices dis­tri­buées. Également connu sous le nom de « Red Hat Service Mesh », ce modèle d’ap­pli­ca­tion est basé sur le projet open source « Istio ». Pour faire face à la com­plexité inhérente aux ar­chi­tec­tures de mi­cro­ser­vices, OpenShift donne accès à un certain nombre d’autres outils : « Pro­me­theus » est utilisé pour gérer la su­per­vi­sion et les no­ti­fi­ca­tions, tandis que « Jaeger » permet d’assurer le suivi des tran­sac­tions. Enfin, on aura recours à « Kiali » pour vi­sua­li­ser le service mesh.

L’un des prin­ci­paux avantages associés à l’uti­li­sa­tion d’OpenShift est le fait de pouvoir exécuter ce logiciel dans un en­vi­ron­ne­ment Cloud hybride. Ici, un cluster OpenShift unique couvre les limites de multiples Cloud publics et privés. Les clusters OpenShift qui ont recours à Red Hat En­ter­prise Linux CoreOS (RHCOS) comme leur seul système d’ex­ploi­ta­tion bé­né­fi­cient des processus au­to­ma­ti­sés lorsqu’ils se mettent à jour et à niveau.

La tech­no­lo­gie Red Hat et les outils de gestion intégrés, ainsi que les processus dé­ve­lop­pés au sein de la pla­te­forme con­dui­sent à une ex­pé­rience uti­li­sa­teur plus élevée. Le modèle de dé­ve­lop­pe­ment open source ainsi que les fonc­tion­na­li­tés DevOps intégrées per­met­tent des processus de dé­ve­lop­pe­ments accélérés. Le recours plus fréquent aux opé­ra­teurs en tant que format d’ap­pli­ca­tion universel contribue à la stan­dar­di­sa­tion et simplifie les cus­to­mi­sa­tions qui étaient complexes jusqu’alors.

Le recours à CRI-O en tant qu’exécution de conteneur en lieu et place de Docker conduit à une sécurité accrue de la pla­te­forme. L’interface Web er­go­no­mique est con­si­dé­rée comme plus puissante et plus claire que le tableau de bord Ku­ber­netes com­pa­rable. OpenShift excelle également sur le plan de la ligne de commande, du fait notamment de la commande oc, laquelle rend la pla­te­forme plus facile à utiliser.

Bien sûr, les pa­ra­mètres spé­ci­fiques sus­men­tion­nés d’OpenShift en­traî­nent également des in­con­vé­nients. D’une part, les uti­li­sa­teurs che­vron­nés de Ku­ber­netes déplorent l’absence des puissants charts Helm, lesquels décrivent la con­fi­gu­ra­tion de l’in­fras­truc­ture. De plus, il n’est pas possible d’utiliser tous les con­te­neurs Docker Hub sous OpenShift, compte tenu des pa­ra­mètres de sécurité dra­co­niens. Le fait de se con­cen­trer sur la dis­tri­bu­tion Linux propre à Red Hat, Red Hat En­ter­prise Linux CoreOS (RHCOS), présente également un effet res­tric­tif. À cet égard, Ku­ber­netes se révèle plus flexible.

OpenShift peut être exécuté sur plus ou moins n’importe quel niveau d’in­fras­truc­ture in­for­ma­tique, des machines « bare metal » située dans vos datas centers privés, aux machines vir­tuelles au sein des en­vi­ron­ne­ments Cloud privés ou publics, en passant par les dis­po­si­tifs de pé­ri­phé­rie de médiation. Nous éta­blis­sons une dis­tinc­tion entre les solutions « gérées », dans les­quelles la gestion de la pla­te­forme OpenShift est assurée par le vendeur, et les ins­tal­la­tions « auto-gérées » ad­mi­nis­trée par le client lui-même :