OpenShift vs Docker

Docker a remporté la victoire de la vir­tua­li­sa­tion basée sur les con­te­neurs. Le logiciel est une tech­no­lo­gie de base pour la création et l’exécution de con­te­neurs d’ap­pli­ca­tions. Par exemple, Docker est utilisé par des dé­ve­lop­peurs in­di­vi­duels sur leur propre or­di­na­teur portable pour stan­dar­di­ser les flux de travail de dé­ve­lop­pe­ment. OpenShift opère à l’autre extrémité du spectre de la vir­tua­li­sa­tion et couvre les besoins opé­ra­tion­nels d’une or­ga­ni­sa­tion entière. Les en­vi­ron­ne­ments de Cloud publics et privés sont utilisés à la base.

Les deux tech­no­lo­gies ne sont en aucun cas des con­cur­rents directs. En fait, OpenShift était au­pa­ra­vant fondé in­di­rec­te­ment sur Docker et utilise jusqu’à présent le format de conteneur Docker. Nous proposons une vue d’ensemble des points forts et des points faibles ainsi que des scénarios d’uti­li­sa­tion.

Dans les dis­cus­sions en ligne ou les billets de blog, on retrouve toujours cette pro­blé­ma­tique ré­cur­rente : « OpenShift vs Docker : quel est le meilleur outil pour la vir­tua­li­sa­tion des con­te­neurs ? ». Même si la question est souvent posée, il s’agit de tech­no­lo­gies très opposées. Tant OpenShift que Docker ont leur raison d’être et sont gé­né­ra­le­ment utilisés de manière com­plé­men­taire.

Comparer les tech­no­lo­gies OpenShift et Docker revient peu ou prou à se poser la question : « Qu’est-ce qui est mieux, une voiture ou un système de transport public ? ». En principe, les deux s’ac­quit­tent d’une mission similaire : déplacer des personnes et des biens entre des em­pla­ce­ments géo­gra­phiques. Les roues sont également présentes dans les deux tech­no­lo­gies. Les ordres de grandeur qui entrent en jeu ici sont en revanche to­ta­le­ment dif­fé­rents.

Con­trai­re­ment aux con­te­neurs physiques, le pendant virtuel ne constitue pas une tech­no­lo­gie de transport de prime abord. Nous suggérons de recourir à une analogie bio­lo­gique pour une meilleure com­pré­hen­sion. Car les con­te­neurs d’ap­pli­ca­tions et les cellules bio­lo­giques ont beaucoup en commun. Dans les deux cas, il s’agit d’une unité d’in­for­ma­tion devenue « vivante », en­cap­su­lée et fermée sur l’extérieur.

Dans le monde vivant, l’évolution s’est déroulée dans la direction de l’organisme uni­cel­lu­laire vers l’organisme mul­ti­cel­lu­laire. Le dé­ve­lop­pe­ment de con­te­neurs isolés vers des groupes or­ches­trés de con­te­neurs en in­te­rac­tion a suivi la même voie dans le monde virtuel. Les défis associés à la mul­ti­cel­lu­la­rité sont également si­mi­laires à ceux qui se posent lors de l’in­te­rac­tion de plusieurs con­te­neurs.

Les cellules bio­lo­giques et les con­te­neurs d’ap­pli­ca­tions doivent com­mu­ni­quer entre eux. Ils doivent grandir ou mourir en fonction des besoins. Les res­sources glo­ba­le­ment dis­po­nibles doivent être réparties entre chaque unité. Tout cela doit être bien coordonné afin que le système global puisse réagir face à l’évolution des besoins tout en restant stable à long terme. Nous avons dressé l’aperçu suivant pour embrasser toute l’amplitude de la vir­tua­li­sa­tion des con­te­neurs, de Docker à OpenShift :

Nous observons ceci : la question de savoir ce qui est le plus approprié ne peut être résolue qu’en adoptant une pers­pec­tive spé­ci­fique. Iden­ti­fier la « meilleure » des deux approches dépend en fin de compte fortement du point de vue. Il en va de même avec la com­pa­rai­son OpenShift vs Docker.

Docker a po­pu­la­risé la vir­tua­li­sa­tion des con­te­neurs et largement contribué au dé­clas­se­ment des machines vir­tuelles (VM) qui tenaient autrefois le haut du pavé. La gé­né­ra­li­sa­tion des con­te­neurs d’ap­pli­ca­tions a ré­vo­lu­tionné la façon dont les ap­pli­ca­tions sont cons­truites, emballées et exécutées. Car les con­te­neurs cons­ti­tuent une unité lo­gi­cielle nor­ma­li­sée. Ils s’utilisent fa­ci­le­ment partout où un runtime de con­te­neurs approprié est dis­po­nible.

Con­trai­re­ment aux machines vir­tuelles au­pa­ra­vant om­ni­pré­sentes, mais assez im­po­santes, les con­te­neurs sont légers. Des dizaines, voire des milliers de con­te­neurs peuvent être exploités sur un hôte. Cet avantage inhérent à la vir­tua­li­sa­tion des con­te­neurs a conduit à la diffusion d’ar­chi­tec­tures de mi­cro­ser­vices dis­tri­buées. Au lieu de cons­truire une ap­pli­ca­tion mo­no­li­thique, on divise la palette de fonctions en com­po­sants in­di­vi­duels. Chaque composant est emballé comme un service dans son propre conteneur. Les con­te­neurs sont démarrés et les services com­mu­ni­quent entre eux via le réseau.

L’approche des mi­cro­ser­vices est par­ti­cu­liè­re­ment pratique pour le dé­ve­lop­pe­ment de logiciels, car elle permet de recourir aux tech­no­lo­gies les plus adaptées à chaque service. Au lieu d’être em­pri­son­nés dans des langages et des pa­ra­digmes de pro­gram­ma­tion in­di­vi­duels, ils peuvent varier d’un service à l’autre. Comme de nouvelles tech­no­lo­gies se pré­sen­tent de plus en plus, il est ainsi plus aisé de réim­plé­men­ter des services in­di­vi­duels.

La capacité à cloner plusieurs con­te­neurs si­mi­laires à partir d’une image de conteneur se traduit par l’évo­lu­ti­vité de l’ensemble du système. Des con­te­neurs sup­plé­men­taires sont démarrés quand la demande augmente, le service concerné est mis à l’échelle sur le plan ho­ri­zon­tal. Ceci nécessite toutefois un système qui surveille les con­te­neurs en cours de fonc­tion­ne­ment et arrête ou démarre de nouveaux con­te­neurs selon les besoins. Les demandes entrantes doivent également être dis­tri­buées vers chaque conteneur.

La com­plexité du système augmente con­si­dé­ra­ble­ment en parallèle à son évo­lu­ti­vité. Ceci concerne au moins tous les aspects suivants :

• Réception des demandes par ré­par­ti­teur de charge
• Répartir les tâches entre chaque conteneur
• Sur­veil­lance de l’état des instances de conteneur
• Quitter et démarrer de nouvelles instances
• Mise en place d’un réseau entre les con­te­neurs
• Main­te­nance des con­te­neurs ou des images par des mises à jour, etc.

Tout cela, considéré en un bloc, entraîne une surcharge d’ad­mi­nis­tra­tion massive. Et ce n’est pas tout. À cela s’ajoute la gestion du système ad­mi­nis­tra­tif lui-même. Ce niveau de contrôle, qui assure tous les points ré­per­to­riés ci-dessus, doit également être géré, surveillé et mis à jour. Il va sans dire que les uti­li­sa­teurs ne doivent jamais ressentir des pertes de per­for­mances pendant ce temps. La sécurité du système global doit être en outre garantie de bout en bout.

Enfin, nous sou­hai­tons également profiter de la pos­si­bi­lité d’or­ches­trer les clusters de con­te­neurs au-delà des fron­tières de l’in­fras­truc­ture. Au plus tard à ce stade, la com­plexité du système s’est accrue à tel point qu’il devient difficile à gérer par des personnes. Des outils spéciaux sont donc né­ces­saires pour aider les or­ga­ni­sa­tions à maîtriser cette com­plexité. Les al­ter­na­tives com­pa­rables à OpenShift sont nées de ce champ de tension.

Comme nous l’avons mentionné plus haut, les tech­no­lo­gies OpenShift et Docker sont très éloignées l’une de l’autre. La com­pa­rai­son est plus ra­tion­nelle quand on intègre le logiciel « Ku­ber­netes », également connu sous l’ap­pel­la­tion K8s, à l’analyse. Le pas franchi de Docker à K8s est com­pa­rable à l’évolution des or­ga­nismes uni­cel­lu­laires vers les or­ga­nismes mul­ti­cel­lu­laires. Dans la même veine, le pas franchi de K8s à OpenShift est com­pa­rable à l’évolution des or­ga­nismes in­di­vi­duels vers un groupe d’êtres vivants. Examinons à nouveau les tech­no­lo­gies utilisées sous cet aspect :

En fait, OpenShift repose sur K8s, qui était à son tour basé au départ sur Docker. La sé­pa­ra­tion de Docker et de K8s est récente. Examinons ci-dessous les deux ex­tré­mi­tés du spectre, OpenShift vs Docker, en détail.

Docker est une tech­no­lo­gie open source qui permet d’emballer des ap­pli­ca­tions dans des con­te­neurs ou d’exécuter des con­te­neurs d’ap­pli­ca­tions. Docker permet de créer des con­te­neurs d’ap­pli­ca­tions portables qui s’exécutent dans un en­vi­ron­ne­ment de Cloud ou sur un matériel in­for­ma­tique local. Le logiciel est fourni par la société homonyme Docker Inc. Outre la version open source gratuite, l’en­tre­prise propose plusieurs produits payants.

Docker réunit trois outils en un seul à l’heure actuelle :

1. Docker Engine, qui fournit les fonc­tion­na­li­tés prin­ci­pales de la vir­tua­li­sa­tion des con­te­neurs.
2. Docker Compose, une fonc­tion­na­lité qui permet d’or­ches­trer plusieurs con­te­neurs fédérés en groupe.
3. Docker Swarm, un mode qui permet l’or­ches­tra­tion de clusters de con­te­neurs sur plusieurs hôtes.

Docker Engine est à son tour constitué de trois com­po­sants prin­ci­paux :

1. Docker Daemon, qui fonc­tionne comme un dockerd sur l’hôte.
2. L’API Docker est fournie par Docker Daemon. Le daemon Docker est interrogé et contrôlé par l’API.
3. L’interface en ligne de commande (CLI) est utilisée comme commande docker pour com­mu­ni­quer avec l’API Docker.

Docker Engine est natif de Linux. En outre, Docker Desktop s’ac­com­pagne d’un package facile à installer sous Mac et Windows. Docker Desktop simplifie la con­fi­gu­ra­tion et comprend une interface uti­li­sa­teur graphique. D’autres tech­no­lo­gies issues de Docker, comme Docker Compose, sont également incluses.

Docker s’est imposé comme la norme de vir­tua­li­sa­tion des con­te­neurs au cours de la dernière décennie. Il n’est donc pas étonnant que le logiciel fonc­tionne sur les systèmes d’ex­ploi­ta­tion les plus divers. Docker est re­la­ti­ve­ment facile à installer, et la prise en main de la fonc­tion­na­lité de base est elle-même très aisée. L’énorme gamme d’images de con­te­neurs pré­fa­bri­quées s’avère avant tout pratique. Ces dernières con­tien­nent des en­vi­ron­ne­ments logiciels pour le dé­ve­lop­pe­ment et la pro­duc­tion et peuvent être obtenues des registres de con­te­neurs publics. Comparé à OpenShift, Docker est une tech­no­lo­gie beaucoup moins complexe.

Les prin­ci­paux in­con­vé­nients de Docker résultent de la crois­sance dé­sor­ga­ni­sée du logiciel au fil des ans. Ce qui a débuté au stade de la vir­tua­li­sa­tion des con­te­neurs est devenu aujourd’hui une pla­te­forme mo­no­li­thique qui en fait trop à la fois. Avec Docker Swarm et Docker Compose, l’uti­li­sa­tion de Docker dépasse largement les objectifs initiaux. Par rapport aux approches modernes, Docker est re­la­ti­ve­ment faible en termes de sécurité et de per­for­mance.

Docker jouit d’un solide po­si­tion­ne­ment surtout en tant qu’outil de dé­ve­lop­pe­ment de logiciels. Les en­vi­ron­ne­ments de dé­ve­lop­pe­ment locaux sont en­cap­su­lés avec les outils et flux de travail utilisés dans des con­te­neurs. Les dé­ve­lop­peurs peuvent se partager les images ainsi générées qui cons­ti­tuent le socle d’un dé­ve­lop­pe­ment normalisé et re­pro­duc­tible.

Docker sert également de base aux tech­no­lo­gies qui en découlent. Les outils de dé­ve­lop­pe­ment tels que DDEV et Lando font appel à Docker pour sim­pli­fier le dé­ve­lop­pe­ment local. Des outils puissants d’or­ches­tra­tion de con­te­neurs sont dis­po­nibles avec des pla­te­formes comme Portainer et Mirantis (an­cien­ne­ment Docker En­ter­prise).

Comme mentionné pré­cé­dem­ment, OpenShift opère tout en haut du spectre des con­te­neurs. OpenShift est utilisé pour mettre en place des en­vi­ron­ne­ments d’ap­pli­ca­tions et de dé­ve­lop­pe­ment dis­tri­bués et évolutifs selon le modèle Platform-as-a-Service (PaaS). Le logiciel met à dis­po­si­tion un en­vi­ron­ne­ment d’exécution complet dans lequel les con­te­neurs sont déployés, exécutés, gérés et or­ches­trés. Les outils intégrés sim­pli­fient les flux de travail modernes de dé­ve­lop­pe­ment et de dé­ploie­ment.

Une dis­tri­bu­tion Ku­ber­netes (K8s) dédiée est utilisée pour cons­ti­tuer le socle d’OpenShift. Cette solution peut être déployée au-delà des fron­tières du Cloud et de l’in­fras­truc­ture, pour favoriser une ex­pé­rience uti­li­sa­teur cohérente. La fonc­tion­na­lité centrale de K8s est complétée par des fonc­tion­na­li­tés de sécurité et de sur­veil­lance et repose sur une gestion cen­tra­li­sée des po­li­tiques. Ceci apporte la garantie d’un haut niveau de qualité sur l’ensemble de l’or­ga­ni­sa­tion à travers son éco­sys­tème logiciel.

En premier lieu, OpenShift bride la com­plexité opé­ra­tion­nelle associée à l’ad­mi­nis­tra­tion de clusters K8s autogérés. Ainsi, plusieurs clusters K8s peuvent être gérés de manière cen­tra­li­sée au-delà des fron­tières des in­fras­truc­tures de Cloud publiques et privées. Con­for­mé­ment à l’approche PAAS, les dé­ve­lop­peurs internes à l’en­tre­prise peuvent demander des res­sources de manière autonome pour leurs projets via une interface Web. Des outils et des flux de travail intégrés pour les notions de Con­ti­nuous In­te­gra­tion et de Con­ti­nuous Delivery (CI/CD) com­plè­tent la palette de fonctions et réduisent con­si­dé­ra­ble­ment les délais de livraison.

Sous le capot, OpenShift repose sur une dis­tri­bu­tion K8s dédiée à l’or­ches­tra­tion des con­te­neurs et des clusters. À l’origine, K8s utilisait Docker en tant que runtime de con­te­neurs. Cette dé­pen­dance a été aban­don­née au profit de « Container Runtime Interface » de l’Open Container Ini­tia­tive (CRI-O). Ceci se traduit par des avantages en termes de sécurité et de per­for­mances.

D’une manière générale, OpenShift séduit par les dis­po­si­tifs de sécurité intégrés. Un registre de con­te­neurs spé­cia­le­ment sécurisé est proposé avec « Quay ». L’au­to­ri­sa­tion et l’au­then­ti­fi­ca­tion de bout en bout limitent l’accès des uti­li­sa­teurs aux dif­fé­rents secteurs du système. La pos­si­bi­lité d’héberger des clusters in­di­vi­duels dans dif­fé­rentes régions géo­gra­phiques permet de garantir une meilleure con­for­mité en termes de pro­tec­tion et de sou­ve­rai­neté des données.

OpenShift fonc­tionne uni­que­ment sur des systèmes d’ex­ploi­ta­tion spé­ci­fiques de Red Hat, tels que « Red Hat En­ter­prise Linux CoreOS » (RHCOS) et « Red Hat En­ter­prise Linux » (RHEL). L’ins­tal­la­tion est con­si­dé­rée comme ex­trê­me­ment fas­ti­dieuse. Une ins­tal­la­tion pour des projets d’envergure peut ainsi s’étaler sur plusieurs semaines. En raison des dis­po­si­tifs de sécurité plus sévères, il n’est pas possible d’utiliser toutes les images de con­te­neurs des registres publics.

Il est possible de mettre en œuvre des pla­te­formes en tant que service (PaaS), des logiciels en tant que service (SaaS) et des con­te­neurs en tant que service (CaaS) internes à l’en­tre­prise sur la base d’OpenShift. On s’adresse ici clai­re­ment aux grandes or­ga­ni­sa­tions. Pour les dé­ve­lop­peurs in­di­vi­duels, OpenShift est dé­fi­ni­ti­ve­ment trop grand et trop difficile à manipuler.

Même si la com­pa­rai­son directe OpenShift vs Docker peut sembler relever d’un exercice d’équi­li­briste, certaines ca­rac­té­ris­tiques des deux tech­no­lo­gies peuvent être mises en con­fron­ta­tion. Par souci d’in­té­gra­lité, nous reprenons à nouveau Ku­ber­netes (K8s) dans la com­pa­rai­son :