Le projet Moby de Docker désassemble les composants fondamentaux du moteur Docker en une boîte à outils modulaire que d’autres systèmes basés sur des conteneurs peuvent réutiliser. Moby a été créé en 2017 à partir de la base de code de Docker, alors monolithique. Il s’est développé en une bibliothèque complète de composants dorsaux de conteneurs qui peuvent être combinés pour créer des solutions de conteneurs complètes comme Docker lui-même.

En tant qu’utilisateur final de Docker, vous n’interagissez pas directement avec le projet Moby. Il est destiné aux personnes qui créent des plateformes de conteneurisation, et non aux développeurs qui créent et exécutent des images de conteneurs. Cependant, vous pouvez rencontrer Moby dans la documentation de Docker ou lorsque vous déposez des rapports de bogue et des demandes de fonctionnalités.

Docker avant Moby

À l’origine, Docker était développé dans une seule base de code qui contenait tout ce dont le projet avait besoin. Cela allait de l’exécution du conteneur et des créateurs d’images aux fournisseurs de stockage, en passant par la gestion du réseau et le CLI.

Alors que l’adoption de Docker a explosé au milieu de la dernière décennie, on a constaté que cette approche tout-en-un freinait l’écosystème au sens large. Les outils complémentaires ne pouvaient pas s’appuyer sur des éléments spécifiques de Docker, car rien n’était décomposé. Les fournisseurs externes devaient intégrer l’ensemble de la plateforme tentaculaire de Docker.

Les unités fonctionnelles de base, telles que containerd, ont rapidement été divisées en modules autonomes. La communauté pouvait désormais créer de nouveaux systèmes de conteneurs sans réinventer le runtime qui assure la médiation avec le noyau pour démarrer les instances de conteneurs. D’autres composants comme runc et HyperKit ont suivi, étant séparés du projet Docker puis réintégrés dans les versions de Docker Engine sous forme de dépendances modulaires.

Moby a porté cette approche à un niveau supérieur en séparant encore plus de composants de Docker. L’ancien dépôt GitHub docker/docker est devenu moby/moby ; il contient les parties open-source du code de Docker Engine dans un emplacement accessible à la communauté, indépendamment des dépôts de produits fermés Docker CE et EE.

Le modèle d’assemblage

Avec Moby, tout le monde peut mélanger des parties de la technologie de Docker sans être obligé d’utiliser le tout. Il fournit des implémentations de tous les sous-systèmes clés qui constituent une plateforme de conteneurisation. Vous pouvez créer votre propre version de Docker, puis échanger des pièces pour utiliser des projets alternatifs dans des domaines fonctionnels spécifiques.

L’approche de Moby s’inspire de l’utilisation de plateformes partagées par l’industrie automobile. Les marques construisent des familles entières de modèles à partir d’une seule gamme de châssis et de moteurs. L’ajout d’une nouvelle option à la gamme est réalisé en prenant la plate-forme partagée et en l’adaptant aux exigences de conception du nouveau véhicule. La plateforme ne sera pas nécessairement utilisée telle quelle : un modèle qui sera proposé en tant que choix de performance pourra avoir des options de moteur et des modifications de châssis qui ne sont pas disponibles sur les autres modèles utilisant la plateforme.

Moby offre quelque chose de similaire aux développeurs de systèmes de conteneurs. Vous pouvez commencer par des assemblages de composants préconstruits qui offrent une compatibilité croisée éprouvée. Il s’agit de la plate-forme automobile partagée de base. À mesure que votre système évolue, vous remplacez les modules individuels par de nouvelles implémentations pour créer un outil plus puissant. Par exemple, vous pouvez remplacer le générateur d’images BuildKit par une solution plus performante. C’est un peu comme si un constructeur automobile remplaçait le petit moteur standard de sa plateforme par une alternative plus performante.

L’expérience du développeur Moby est donc une expérience d’assemblage et d’extension. Chaque projet basé sur Moby consommera un ensemble différent de pièces pour atteindre un objectif unique. Avant Moby, les développeurs n’avaient pas de point de départ accessible pour innover dans des domaines spécifiques de l’écosystème des conteneurs. Désormais, les développements peuvent être plus ciblés, car Moby comble les lacunes.

Que comprend Moby ?

Moby a trois offres fonctionnelles distinctes :

Une bibliothèque de composants backend qui mettent en œuvre des fonctionnalités communes aux conteneurs, telles que la création d'images, la gestion du stockage et la collecte de journaux.
Un framework avec des outils de support qui vous aident à combiner, construire et tester des assemblages de composants dans votre propre système. La chaîne d'outils produit des artefacts exécutables pour toutes les architectures, systèmes d'exploitation et environnements en nuage modernes.
Exemples d'utilisation du framework, y compris un assemblage de référence. Cet assemblage de référence est le noyau open-source sur lequel le produit Docker est construit. Vous pouvez l'utiliser pour mieux comprendre comment les composants de Moby sont rassemblés en un système cohérent.

Ces pièces donnent aux constructeurs de systèmes tous les ingrédients nécessaires pour créer leur propre plateforme de conteneurisation. Ils facilitent l’innovation sans coupler les projets à Docker et à son écosystème fermé. Le modèle est décrit comme « des piles incluses mais interchangeables ».

Moby est entièrement open-source et dirigé par la communauté. Docker apporte ses composants open-source au projet et les parties externes peuvent également y ajouter des éléments. Docker s’est également engagé à continuer d’utiliser Moby en amont, ce qui signifie que les modifications apportées à Moby seront visibles lorsque vous installerez Docker.

Moby n’est pas vraiment la fin de l’arbre des dépendances de Docker. Certains composants, comme le runtime Containerd, ont été donnés à la CNCF et sont donc maintenus séparément de Moby. Moby utilise Containerd comme moteur d’exécution de conteneur par défaut, mais il est inclus comme dépendance en amont, et non comme membre du projet.

De Moby à Docker

Bien que Moby comprenne tous les éléments fondamentaux d’un système de conteneurs, son orientation vers les développeurs de systèmes signifie que l’installation de l’assemblage de référence ne vous donnera pas la meilleure expérience. C’est là que des projets en aval, comme Docker, apportent une valeur ajoutée. Ils s’appuient sur Moby pour créer une plateforme dont le fonctionnement est utile aux utilisateurs finaux qui travaillent avec des conteneurs et des images.

Par exemple, l’installation de Docker et l’exécution de docker pull ubuntu:latest sont possibles sans aucune configuration manuelle. Cela est dû au fait que Docker est préconfiguré pour tirer des références d’images non qualifiées de Docker Hub. Cela ne fonctionnerait pas avec l’assemblage de référence Moby ; bien qu’il soit capable de tirer des images, il n’a pas de registre par défaut et ne serait donc pas en mesure de résoudre la balise.

Les plateformes en aval ajoutent des avis à l’ensemble objectif des fonctionnalités offertes par Moby. Alors que les développeurs de systèmes de conteneurs ne voudront pas d’une URL de registre préconfigurée, c’est une fonctionnalité utile pour les créateurs d’images. Avant l’introduction de Moby, les développeurs de plateformes n’avaient aucun moyen de filtrer les décisions de Docker basées sur les produits.

Résumé

Moby est une boîte à outils modulaire de composants de conteneurs dorsaux. Il se situe en amont des plateformes destinées aux utilisateurs finaux qui construisent et exécutent des images de conteneurs. Moby est destiné aux personnes qui créent des systèmes comme Docker mais qui ne veulent pas hériter de ses défauts, de ses opinions et de ses liens avec Docker Inc.

Moby facilite un écosystème de conteneurs plus productif qui n’est plus dominé par le monolithe Docker. La plupart des utilisateurs de Docker n’auront pas remarqué ce changement, car l’introduction de Moby a surtout permis de rationaliser le développement d’outils tels que Kubernetes, Podman et d’autres environnements de conteneurs. Ces projets bénéficient du partage de composants clés qui ont été réduits à leur plus simple expression fonctionnelle.