OpenShift vs Docker

Docker a remporté la victoire de la virtualisation basée sur les conteneurs. Le logiciel est une technologie de base pour la création et l’exécution de conteneurs d’applications. Par exemple, Docker est utilisé par des développeurs individuels sur leur propre ordinateur portable pour standardiser les flux de travail de développement. OpenShift opère à l’autre extrémité du spectre de la virtualisation et couvre les besoins opérationnels d’une organisation entière. Les environnements de Cloud publics et privés sont utilisés à la base.

Les deux technologies ne sont en aucun cas des concurrents directs. En fait, OpenShift était auparavant fondé indirectement 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’utilisation.

Dans les discussions en ligne ou les billets de blog, on retrouve toujours cette problématique récurrente : « OpenShift vs Docker : quel est le meilleur outil pour la virtualisation des conteneurs ? ». Même si la question est souvent posée, il s’agit de technologies très opposées. Tant OpenShift que Docker ont leur raison d’être et sont généralement utilisés de manière complémentaire.

Comparer les technologies 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’acquittent d’une mission similaire : déplacer des personnes et des biens entre des emplacements géographiques. Les roues sont également présentes dans les deux technologies. Les ordres de grandeur qui entrent en jeu ici sont en revanche totalement différents.

Contrairement aux conteneurs physiques, le pendant virtuel ne constitue pas une technologie de transport de prime abord. Nous suggérons de recourir à une analogie biologique pour une meilleure compréhension. Car les conteneurs d’applications et les cellules biologiques ont beaucoup en commun. Dans les deux cas, il s’agit d’une unité d’information devenue « vivante », encapsulé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 unicellulaire vers l’organisme multicellulaire. Le développement de conteneurs isolés vers des groupes orchestrés de conteneurs en interaction a suivi la même voie dans le monde virtuel. Les défis associés à la multicellularité sont également similaires à ceux qui se posent lors de l’interaction de plusieurs conteneurs.

Les cellules biologiques et les conteneurs d’applications doivent communiquer entre eux. Ils doivent grandir ou mourir en fonction des besoins. Les ressources globalement disponibles 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 virtualisation des conteneurs, 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 perspective spécifique. Identifier la « meilleure » des deux approches dépend en fin de compte fortement du point de vue. Il en va de même avec la comparaison OpenShift vs Docker.

Docker a popularisé la virtualisation des conteneurs et largement contribué au déclassement des machines virtuelles (VM) qui tenaient autrefois le haut du pavé. La généralisation des conteneurs d’applications a révolutionné la façon dont les applications sont construites, emballées et exécutées. Car les conteneurs constituent une unité logicielle normalisée. Ils s’utilisent facilement partout où un runtime de conteneurs approprié est disponible.

Contrairement aux machines virtuelles auparavant omniprésentes, mais assez imposantes, les conteneurs sont légers. Des dizaines, voire des milliers de conteneurs peuvent être exploités sur un hôte. Cet avantage inhérent à la virtualisation des conteneurs a conduit à la diffusion d’architectures de microservices distribuées. Au lieu de construire une application monolithique, on divise la palette de fonctions en composants individuels. Chaque composant est emballé comme un service dans son propre conteneur. Les conteneurs sont démarrés et les services communiquent entre eux via le réseau.

L’approche des microservices est particulièrement pratique pour le développement de logiciels, car elle permet de recourir aux technologies les plus adaptées à chaque service. Au lieu d’être emprisonnés dans des langages et des paradigmes de programmation individuels, ils peuvent varier d’un service à l’autre. Comme de nouvelles technologies se présentent de plus en plus, il est ainsi plus aisé de réimplémenter des services individuels.

La capacité à cloner plusieurs conteneurs similaires à partir d’une image de conteneur se traduit par l’évolutivité de l’ensemble du système. Des conteneurs supplémentaires sont démarrés quand la demande augmente, le service concerné est mis à l’échelle sur le plan horizontal. Ceci nécessite toutefois un système qui surveille les conteneurs en cours de fonctionnement et arrête ou démarre de nouveaux conteneurs selon les besoins. Les demandes entrantes doivent également être distribuées vers chaque conteneur.

La complexité du système augmente considérablement en parallèle à son évolutivité. Ceci concerne au moins tous les aspects suivants :

• Réception des demandes par répartiteur de charge
• Répartir les tâches entre chaque conteneur
• Surveillance de l’état des instances de conteneur
• Quitter et démarrer de nouvelles instances
• Mise en place d’un réseau entre les conteneurs
• Maintenance des conteneurs ou des images par des mises à jour, etc.

Tout cela, considéré en un bloc, entraîne une surcharge d’administration massive. Et ce n’est pas tout. À cela s’ajoute la gestion du système administratif lui-même. Ce niveau de contrôle, qui assure tous les points répertoriés ci-dessus, doit également être géré, surveillé et mis à jour. Il va sans dire que les utilisateurs ne doivent jamais ressentir des pertes de performances pendant ce temps. La sécurité du système global doit être en outre garantie de bout en bout.

Enfin, nous souhaitons également profiter de la possibilité d’orchestrer les clusters de conteneurs au-delà des frontières de l’infrastructure. Au plus tard à ce stade, la complexité du système s’est accrue à tel point qu’il devient difficile à gérer par des personnes. Des outils spéciaux sont donc nécessaires pour aider les organisations à maîtriser cette complexité. Les alternatives comparables à OpenShift sont nées de ce champ de tension.

Comme nous l’avons mentionné plus haut, les technologies OpenShift et Docker sont très éloignées l’une de l’autre. La comparaison est plus rationnelle quand on intègre le logiciel « Kubernetes », également connu sous l’appellation K8s, à l’analyse. Le pas franchi de Docker à K8s est comparable à l’évolution des organismes unicellulaires vers les organismes multicellulaires. Dans la même veine, le pas franchi de K8s à OpenShift est comparable à l’évolution des organismes individuels vers un groupe d’êtres vivants. Examinons à nouveau les technologies utilisées sous cet aspect :

En fait, OpenShift repose sur K8s, qui était à son tour basé au départ sur Docker. La séparation de Docker et de K8s est récente. Examinons ci-dessous les deux extrémités du spectre, OpenShift vs Docker, en détail.

Docker est une technologie open source qui permet d’emballer des applications dans des conteneurs ou d’exécuter des conteneurs d’applications. Docker permet de créer des conteneurs d’applications portables qui s’exécutent dans un environnement de Cloud ou sur un matériel informatique local. Le logiciel est fourni par la société homonyme Docker Inc. Outre la version open source gratuite, l’entreprise propose plusieurs produits payants.

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

1. Docker Engine, qui fournit les fonctionnalités principales de la virtualisation des conteneurs.
2. Docker Compose, une fonctionnalité qui permet d’orchestrer plusieurs conteneurs fédérés en groupe.
3. Docker Swarm, un mode qui permet l’orchestration de clusters de conteneurs sur plusieurs hôtes.

Docker Engine est à son tour constitué de trois composants principaux :

1. Docker Daemon, qui fonctionne 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 communiquer avec l’API Docker.

Docker Engine est natif de Linux. En outre, Docker Desktop s’accompagne d’un package facile à installer sous Mac et Windows. Docker Desktop simplifie la configuration et comprend une interface utilisateur graphique. D’autres technologies issues de Docker, comme Docker Compose, sont également incluses.

Docker s’est imposé comme la norme de virtualisation des conteneurs au cours de la dernière décennie. Il n’est donc pas étonnant que le logiciel fonctionne sur les systèmes d’exploitation les plus divers. Docker est relativement facile à installer, et la prise en main de la fonctionnalité de base est elle-même très aisée. L’énorme gamme d’images de conteneurs préfabriquées s’avère avant tout pratique. Ces dernières contiennent des environnements logiciels pour le développement et la production et peuvent être obtenues des registres de conteneurs publics. Comparé à OpenShift, Docker est une technologie beaucoup moins complexe.

Les principaux inconvénients de Docker résultent de la croissance désorganisée du logiciel au fil des ans. Ce qui a débuté au stade de la virtualisation des conteneurs est devenu aujourd’hui une plateforme monolithique qui en fait trop à la fois. Avec Docker Swarm et Docker Compose, l’utilisation de Docker dépasse largement les objectifs initiaux. Par rapport aux approches modernes, Docker est relativement faible en termes de sécurité et de performance.

Docker jouit d’un solide positionnement surtout en tant qu’outil de développement de logiciels. Les environnements de développement locaux sont encapsulés avec les outils et flux de travail utilisés dans des conteneurs. Les développeurs peuvent se partager les images ainsi générées qui constituent le socle d’un développement normalisé et reproductible.

Docker sert également de base aux technologies qui en découlent. Les outils de développement tels que DDEV et Lando font appel à Docker pour simplifier le développement local. Des outils puissants d’orchestration de conteneurs sont disponibles avec des plateformes comme Portainer et Mirantis (anciennement Docker Enterprise).

Comme mentionné précédemment, OpenShift opère tout en haut du spectre des conteneurs. OpenShift est utilisé pour mettre en place des environnements d’applications et de développement distribués et évolutifs selon le modèle Platform-as-a-Service (PaaS). Le logiciel met à disposition un environnement d’exécution complet dans lequel les conteneurs sont déployés, exécutés, gérés et orchestrés. Les outils intégrés simplifient les flux de travail modernes de développement et de déploiement.

Une distribution Kubernetes (K8s) dédiée est utilisée pour constituer le socle d’OpenShift. Cette solution peut être déployée au-delà des frontières du Cloud et de l’infrastructure, pour favoriser une expérience utilisateur cohérente. La fonctionnalité centrale de K8s est complétée par des fonctionnalités de sécurité et de surveillance et repose sur une gestion centralisée des politiques. Ceci apporte la garantie d’un haut niveau de qualité sur l’ensemble de l’organisation à travers son écosystème logiciel.

En premier lieu, OpenShift bride la complexité opérationnelle associée à l’administration de clusters K8s autogérés. Ainsi, plusieurs clusters K8s peuvent être gérés de manière centralisée au-delà des frontières des infrastructures de Cloud publiques et privées. Conformément à l’approche PAAS, les développeurs internes à l’entreprise peuvent demander des ressources 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 Continuous Integration et de Continuous Delivery (CI/CD) complètent la palette de fonctions et réduisent considérablement les délais de livraison.

Sous le capot, OpenShift repose sur une distribution K8s dédiée à l’orchestration des conteneurs et des clusters. À l’origine, K8s utilisait Docker en tant que runtime de conteneurs. Cette dépendance a été abandonnée au profit de « Container Runtime Interface » de l’Open Container Initiative (CRI-O). Ceci se traduit par des avantages en termes de sécurité et de performances.

D’une manière générale, OpenShift séduit par les dispositifs de sécurité intégrés. Un registre de conteneurs spécialement sécurisé est proposé avec « Quay ». L’autorisation et l’authentification de bout en bout limitent l’accès des utilisateurs aux différents secteurs du système. La possibilité d’héberger des clusters individuels dans différentes régions géographiques permet de garantir une meilleure conformité en termes de protection et de souveraineté des données.

OpenShift fonctionne uniquement sur des systèmes d’exploitation spécifiques de Red Hat, tels que « Red Hat Enterprise Linux CoreOS » (RHCOS) et « Red Hat Enterprise Linux » (RHEL). L’installation est considérée comme extrêmement fastidieuse. Une installation pour des projets d’envergure peut ainsi s’étaler sur plusieurs semaines. En raison des dispositifs de sécurité plus sévères, il n’est pas possible d’utiliser toutes les images de conteneurs des registres publics.

Il est possible de mettre en œuvre des plateformes en tant que service (PaaS), des logiciels en tant que service (SaaS) et des conteneurs en tant que service (CaaS) internes à l’entreprise sur la base d’OpenShift. On s’adresse ici clairement aux grandes organisations. Pour les développeurs individuels, OpenShift est définitivement trop grand et trop difficile à manipuler.

Même si la comparaison directe OpenShift vs Docker peut sembler relever d’un exercice d’équilibriste, certaines caractéristiques des deux technologies peuvent être mises en confrontation. Par souci d’intégralité, nous reprenons à nouveau Kubernetes (K8s) dans la comparaison :