Alternative à Docker : aperçu des technologies de conteneurs

Avec la plateforme de conteneurs Docker, la virtualisation au niveau du système d’exploitation (Operating system level Virtualization) est en plein renouveau. En effet, en quelques années, l'équipe de développement a réussi à relancer la technologie des conteneurs basée sur les fonctionnalités du noyau. Il a même dépassé les frontières de l'univers Linux et se présente comme une alternative économe en ressources à la virtualisation basée sur l'hyperviseur grâce à l'émulation matérielle.

Grâce à un bon écho médiatique et à un écosystème en constante évolution, Docker est devenu le leader technologique du marché dans le domaine de la virtualisation de conteneurs. Cependant, la plateforme de conteneurs est loin d’être le seul projet logiciel dans lequel des techniques de virtualisation sont développées au niveau du système d’exploitation.

Quelles sont donc les alternatives à Docker ? Et en quoi diffèrent-elles du mécanisme du leader du marché ?

Pour les systèmes de type Unix, tels que Linux, la virtualisation au niveau du système d'exploitation est généralement basée sur une implémentation avancée de mécanismes Chroot natifs. En outre, les projets de conteneurs comme Docker, rkt, LXC, LXC, LXD, Linux-VServer, OpenVZ/Virtuozzo et runC, tirent parti des fonctionnalités natives du noyau Linux pour la gestion des ressources afin de mettre en œuvre des environnements d'exécution isolés pour les applications ou pour l'ensemble du système d'exploitation.

Docker utilise les fonctions de base du noyau Linux pour protéger les processus les uns des autres et permet le fonctionnement en parallèle d’applications dans des conteneurs isolés, sans avoir besoin de systèmes invités qui sont gourmands en ressources, en utilisant l’environnement d’exécution runC développé en interne. Cela fait de la plateforme de conteneurs une bonne alternative à la virtualisation basée sur l'hyperviseur. Vous trouverez une description détaillée de la plateforme Docker et de ses composants de base dans notre tutoriel Docker pour débutants.

La plateforme Docker est distribuée en tant qu’édition communautaire gratuite (CE) ainsi qu’en tant que version Entreprise payante (EE) et offre en plus un support pour diverses distributions Linux. De plus, Docker CE est disponible en tant qu’application native pour Windows et MacOs depuis la sortie de la version 1.12. Alors que Docker pour Mac utilise l’hyperviseur mince xhyve pour virtualiser un environnement d’exécution pour le moteur Docker et les fonctions spécifiques au noyau Linux pour le daemon Docker, l’hyperviseur Hyper-V est utilisé dans le même but sous Windows.

Depuis septembre 2016, Docker EE est aussi disponible en version native pour Windows Server 2016. Microsoft, en étroite collaboration avec l’équipe de développement de Docker, a en effet mis en œuvre diverses extensions dans le noyau Windows qui permettent à Docker de démarrer des processus en tant que conteneurs dans un sandbox sans hyperviseur abstrait. Microsoft met le code source du pilote spécialement développé : hcsshim à la disposition de la communauté open source via GitHub.

Le tableau suivant montre les points clefs de la plateforme Docker :

Au fil du temps, un véritable écosystème s’est développé autour du projet de base de Docker. Selon les développeurs, le moteur Docker est désormais impliqué dans plus de 100 000 projets de tiers.

La principale critique de l’implémentation de la technologie des conteneurs Linux dans le projet Docker est le degré d’isolement des processus individuels sur un système hôte commun. Docker utilise les fonctions natives du noyau comme les groupes et les espaces de noms lors de l’exploitation des conteneurs d’applications. Cependant, ceux-ci n’encapsulent pas les conteneurs dans la même mesure que la virtualisation complète basée sur des machines virtuelles. Pour assurer un fonctionnement sécurisé des applications de conteneur sur les systèmes de production, les nouvelles versions de la plateforme de conteneur prennent en charge des extensions de noyau telles que AppArmor, SELinux, Seccomp et GRSEC, qui protègent en outre les processus isolés.

En février 2016, CoreOS a publié rkt version 1.0, la première version stable de l’environnement d‘exécution des conteneurs. Par rapport à Docker, le concurrent veut avant tout marquer des points avec des éléments de sécurité supplémentaires. En plus de l’isolation des conteneurs basée sur KVM, ceux-ci incluent la prise en charge de l’extension du noyau SELinux et la validation de signature pour les images de la spécification propriétaire App Container (appc). Il décrit le format App Container Image (ACI), l’environnement d’exécution, un mécanisme de découverte d’images et la possibilité de regrouper les images dans des applications multi-conteneurs, ce que l’on nomme les App Container Pods.

Contrairement à Docker, rkt supporte d’autres formats en plus de ses propres images de conteneurs. L’environnement d’exécution est compatible avec les images Docker et offre un moyen de convertir n’importe quel format de conteneur en ACI avec l’outil open source Quay.

Alors que la plateforme Docker s’appuie sur un daemon central qui s’exécute avec les privilèges Root en arrière-plan, rkt fonctionne sans un tel processus en arrière-plan mais plutôt avec des systèmes établis init comme systemd et Upstart pour démarrer et gérer les conteneurs. Ainsi, rkt évite le problème résolu de Docker qui consiste à demander aux utilisateurs qui veulent lancer des conteneurs via le daemon d’avoir les privilèges Root et un accès complet au système hôte.

Contrairement à Docker, rkt n’est pas limité aux fonctions du noyau Linux comme les groupes et les espaces de noms lors de la virtualisation d’applications. Avec l’environnement d’exécution de CoreOS, les conteneurs basés sur KVM (Kernel-based Virtual Machine, par exemple LKVM ou QEMU) et la technologie Clear Container d’Intel peuvent aussi être démarrés en tant que machines virtuelles complètement encapsulées.

La spécification de l’application et son implémentation est soutenue par des leaders de l’industrie comme Google, Red Hat et VMware.

Afin de protéger les processus les uns des autres, les techniques d’isolation sont utilisées chez LXC :

• IPC-, UTS-, Mount-, PID-, réseau et espaces de noms d’utilisateurs
• Cgroups
• AppArmor- et SELinux-Profile
• Règles Seccomp
• Chroots
• Capacités du noyau

Le but du projet LXC est de créer un environnement pour les conteneurs logiciels qui diffère le moins possible d’une installation Linux standard. En plus des projets open source LXD, LXCFS et CGManager, LXC est développé dans le cadre du projet LinuxContainers.org.

LXC est conçu pour faire fonctionner différents systèmes de conteneurs (Full System Container) sur un système hôte commun. Un conteneur Linux démarre généralement une distribution complète à partir d’une image de système d’exploitation dans un environnement virtuel. Les utilisateurs interagissent avec lui d’une manière similaire à une machine virtuelle.

Les applications sont rarement démarrées dans des conteneurs Linux. Ceci différencie clairement le logiciel du projet Docker. Alors que LXC est principalement utilisé pour la virtualisation du système, Docker se concentre sur la virtualisation des applications individuelles et leur déploiement. Au début, les conteneurs Linux étaient aussi utilisés. Aujourd’hui, Docker s’appuie sur un format de conteneur développé par ses soins.

Une différence majeure entre les deux technologies de virtualisation est que les conteneurs Linux peuvent contenir n’importe quel nombre de processus, alors que les conteneurs Docker n’exécutent qu’un seul processus, de sorte que les applications Docker complexes se composent généralement de plusieurs conteneurs. Le déploiement efficace de ces applications multi-conteneurs nécessite des outils supplémentaires.

De plus, les conteneurs Docker et les conteneurs Linux diffèrent en termes de portabilité. Si un utilisateur développe un logiciel basé sur LXC sur un système de test local, on ne peut pas nécessairement supposer que le conteneur fonctionnera plus tard sans erreur sur d’autres systèmes (par exemple un système de production). La plateforme Docker, d’autre part, soustrait beaucoup plus fortement les applications de la nature du système sous-jacent. Ceci permet au même conteneur Docker de fonctionner sur n’importe quel hôte Docker (un système sur lequel le moteur Docker est installé), indépendamment du système d’exploitation et de la configuration matérielle.

LXC ne nécessite pas non plus de processus de daemon central. À la place, le logiciel de conteneur s’intègre de manière similaire à rkt dans les systèmes init comme systemd et Upstart pour démarrer et gérer les conteneurs.

LXD de Canonical

En tant que projet suiveur de LXC, le distributeur Linux Canonical a lancé l’alternative à Docker LXD (prononcé : Lexdi) en novembre 2014. Le projet s’appuie sur la technologie des conteneurs Linux et l’étend par le processus Daemon LXD. Le logiciel est une sorte d’hyperviseur de conteneur. La structure technique de la solution de conteneur se compose de trois composants : LXC fonctionne comme client en ligne de commande et un plugin OpenStack Nova est intégré avec nova-compute-lxd. La communication entre le client et la daemon se fait via un REST-API.

L’objectif du projet logiciel est d’offrir aux utilisateurs une expérience utilisateur basée sur la technologie des conteneurs Linux similaire à celle des machines virtuelles sans avoir à accepter l’overhead de l’émulation des ressources matérielles.

Comme LXC, LXD se concentre sur l’apport de systèmes complets de conteneurs. Ce rôle d’outil de gestion de machine sépare LXD de Docker et le dissocie, dont les fonctions centrales se situent plutôt dans le domaine du déploiement de logiciels. LXD utilise les mêmes technologies d’isolation que le projet LXC sous-jacent.

La daemon de la solution conteneur nécessite un noyau Linux. Les autres systèmes d’exploitation ne sont pas pris en charge. Comme la communication avec la daemon se fait via une API REST, il est possible d’avoir l’accès à distance avec un client Windows ou MacOs. Comment le client LXD standard peut être configuré pour le système d’exploitation désiré est décrit par Stéphane Graber, chef de projet de LXD, dans un billet de blog du 9 février 2017.

Comme les VPS fonctionnent comme des processus isolés sur le même système hôte et utilisent la même interface d’appel système, l’émulation ne crée pas d’overhead supplémentaire.

Le projet open source initié par Jacques Gélinas était dirigé par l’autrichien Herbert Pötzl jusqu’au bout. Cette technologie est utilisée, par exemple, par les fournisseurs d‘hébergement Web qui veulent offrir à leurs clients des machines virtuelles séparées sur une base matérielle commune.

Pour fournir au noyau Linux une fonctionnalité de virtualisation au niveau du système d’exploitation, il doit être patché. Cette modification du noyau Linux rend la technologie fondamentalement différente des conteneurs Linux (LXC), qui utilisent des fonctions d’isolation natives avec des groupes et des espaces de noms.

La dernière version était VServer 2.2 en 2007.

Par rapport à la version précédente, OpenVZ 7 offre un ensemble de nouveaux outils en ligne de commande appelés outils invités. Ceux-ci permettent aux utilisateurs d’effectuer des tâches sur les systèmes invités directement à partir du terminal du système hôte. En outre, l’hyperviseur développé par l’entreprise pour l’exploitation de machines virtuelles a été remplacé par les technologies standards KVM et QEMU.

Pour l’exploitation des conteneurs, OpenVZ continue d’utiliser son propre format avec les conteneurs Virtuozzo. Comme LXC, il est principalement utilisé pour la virtualisation de systèmes complets (VPS) et se distingue ainsi de Docker et de rkt. Contrairement à LXC, OpenVZ offre l’option de migration en direct via Checkpoint/Restore In Userspace (CRIU) pour créer des images persistantes d’un conteneur en cours d’exécution.

Techniquement, OpenVZ et Virtuozzo sont une extension du noyau Linux qui fournit divers outils de virtualisation de niveau utilisateur. Les systèmes invités sont réalisés dans des environnements virtuels (VE), qui fonctionnent de manière isolée sur le même noyau Linux. Ceci permet d’éviter l’overhead de la simulation matérielle basée sur l’hyperviseur, comme c’est le cas avec les autres technologies de conteneurs présentées. Cependant, le noyau Linux partagé signifie que tous les systèmes invités virtualisés sont fixés à l’architecture système et à la version de base du système hôte.

Les principales caractéristiques d’OpenVZ comprennent le partitionnement dynamique en temps réel, la gestion des ressources et la gestion centralisée de plusieurs serveurs physiques et virtuels.

• Partitionnement dynamique en temps réel : Chaque VPS représente une partition isolée du serveur physique sous-jacent. L’isolation comprend les systèmes de fichiers personnalisés, les groupes d’utilisateurs (y compris les utilisateurs root personnalisés), les arbres de processus, les adresses réseau et les objets IPC.
• Gestion des ressources : l’allocation des ressources matérielles chez OpenVZ se fait via des paramètres de gestion des ressources, qui sont gérés par l’Administrateur système dans le fichier de configuration globale et les fichiers de configuration des conteneurs correspondants.

Pour gérer les machines virtuelles et les conteneurs système, OpenVZ et Virtuozzo s'appuient sur l'outil de gestion libvirt de Red Hat, qui se compose d'une API open source, du daemon libvirtd et du programme de ligne de commande virsh.

Alors que le produit d'entreprise Virtuozzo est livré avec l'interface graphique intégrée Parallels Virtual Automation (PVA), OpenVZ est livré sans interface utilisateur graphique dans l'installation de base. Toutefois, les utilisateurs ont la possibilité de l’installer par l'intermédiaire d'un logiciel tiers. L'équipe de développement OpenVZ recommande le panneau Web OpenVZ de SoftUnity. D’autres alternatives peuvent être trouvées dans le Wiki OpenVZ.

En tant qu’organisation à but non lucratif de la Fondation Linux, l’OCI 2015 a été lancée par Docker et d’autres sociétés de conteneurs afin d’établir une norme industrielle libre pour les conteneurs de logiciels. Actuellement, l’OCI fournit des spécifications pour un environnement d’exécution de conteneur runtime-spec et un format d’image de conteneur image-spec.

L’environnement d’exécution runC open source peut être considéré comme une implémentation canonique de ces spécifications.

L'environnement d'exécution OCI ne prend en charge que les conteneurs regroupés OCI et ne nécessite qu'un système de fichiers racine (root) et un fichier de configuration OCI pour exécuter les conteneurs. Un outil pour créer des systèmes de fichiers root pour les conteneurs n'est pas fourni dans le projet. Cependant, les utilisateurs qui ont installé la plateforme Docker peuvent utiliser sa fonction d'exportation pour extraire un système de fichiers root d'un conteneur Docker existant, y ajouter un fichier config.json et créer un paquet OCI. En outre, d'autres outils externes de création d’images tels que oci-image-tools, skopeo et umoci sont aussi pris en charge.

Comme les alternatives à Docker rkt et LXC, runC n’utilise pas de processus de daemon central. À la place, l’environnement d’exécution de conteneur s’intègre avec le processus init systemd.

Le tableau suivant montre une comparaison des alternatives Docker présentées.

Le concept de partitionnement des ressources du système en utilisant les mécanismes d’isolation propres au noyau et en les rendant disponibles indépendamment les uns des autres pour encapsuler les processus sur le même système se retrouve dans divers systèmes d’exploitation de type Unix. Les conteneurs Linux sont comparables aux « Jail » sur les systèmes BSD et aux zones introduites dans la version Solaris 10. Les concepts de conteneurs Microsoft Drawbridge, WinDocks, Sandboxie, Turbo et VMware ThinApp sont disponibles pour les systèmes Windows.

Les groupes d’utilisateurs indépendants dont les droits sont limités à l’environnement Jail peuvent être définis pour chaque Jail via une administration des utilisateurs séparée. Cela signifie qu’un utilisateur disposant d’autorisations étendues au sein d’un Jail ne peut pas effectuer des opérations système critiques en dehors de l’environnement virtuel. Cela permet de s’assurer qu’un hacker ne peut pas causer de dommages importants au système à partir d’un Jail compromis.

Tout comme d’autres approches de virtualisation au niveau du système d’exploitation, les zones Solaris fournissent un moyen efficace de mettre en œuvre plusieurs systèmes d’exploitation isolés sur une instance de système commune.

Le moteur Docker natif pour Windows Server 2016 est fondamentalement différent de Docker pour Windows et Docker pour Mac. Alors que ces derniers permettent au moteur Docker développé pour Linux de fonctionner avec une machine virtuelle peu volumineuse, la version Docker pour Windows Server 2016 utilise directement le noyau Windows. Par conséquent, les conteneurs Docker classiques ne peuvent pas être exécutés sur Windows Server 2016. Au lieu de cela, le projet Docker a développé un nouveau format de conteneur appelé WSC (Windows server Container). De plus, Microsoft propose une variante de conteneur basée sur Hyper-V qui permet d’atteindre un degré d’isolation plus élevé.

• Windows Server Container : avec Windows Server Container (WSC), Microsoft propose une technologie de conteneur pour la plateforme Docker qui permet d’isoler les processus avec des fonctions avancées du noyau Windows. Comme avec la technologie Linux, les conteneurs de serveur Windows partagent le noyau du système hôte sous-jacent (Container-Host).
• Hyper-V Container : avec les conteneurs Hyper-V, Microsoft offre un moyen supplémentaire de protéger les instances de conteneurs à l’aide de la virtualisation classique basée sur l’hyperviseur. Les conteneurs Hyper-V sont des machines virtuelles qui peuvent être contrôlées via la plateforme Docker tout comme les conteneurs de serveur Windows, mais qui ont un degré d’isolation beaucoup plus élevé grâce à leur propre noyau Windows.

Avant même que Microsoft n‘implémente des technologies de conteneur natives dans le noyau Windows dans le cadre de la coopération Docker, divers développeurs travaillaient sur des méthodes de virtualisation économisant les ressources pour les systèmes Windows. Parmi les projets bien connus, citons Microsoft Drawbridge, WinDocks, Sandboxie, Turbo et VMare ThinApp.

Microsoft Drawbridge

Sous le nom de Drawbridge, Microsoft a développé le prototype d’une technologie de virtualisation basée sur le concept Library-OS, un système d’exploitation qui est mis en œuvre comme un ensemble de bibliothèques au sein d’une application. Drawbridge exécute des applications avec le Library-OS dans des processus dits Pico. Ce sont des conteneurs d’isolation basés sur les processus avec interface noyau. Dans la documentation de Windows Server Container, Microsoft déclare que l’expérience de Drawbridge est un élément important pour le développement de la technologie des conteneurs sous Windows server 2016.

WinDocks

WinDocks est un port Docker pour Windows qui vous permet de créer et de gérer des conteneurs d’application pour les applications .NET et des conteneurs de données pour les serveurs SQL. Contrairement à Windows Server Containers, qui sont actuellement limités à Windows 10 et Windows Server 2016, WinDocks est également disponible pour les anciens systèmes d’exploitation tels que Windows Server 2012, Windows Server 2012 R2 et Windows 8 et 8.1. Le logiciel est offert en tant qu’édition communautaire gratuite et en tant que produit Entreprise avec support client.

Sandboxie

Sandboxie vous permet d’exécuter des applications Windows dans un environnement isolé appelé Sandbox. Semblable à la technologie de conteneur, cette méthode vise à protéger le système hôte sous-jacent et d’autres applications des activités de programmes d’une application isolée. Pour cela, l’outil bascule entre l’application et le système d’exploitation pour intercepter l’accès en écriture du disque dur et le rediriger vers une partie protégée. En plus de l’accès aux fichiers, les demandes d’écriture dans la base de registre Windows peuvent aussi être empêchées. Sandboxie est disponible pour toutes les versions actuelles de Windows ainsi que pour XP et Vista en version de base gratuite. De plus, des versions payantes avec une gamme étendue de fonctions sont proposées pour les utilisateurs privés et pour les entreprises.

Turbo (anciennement Spoon)

Turbo est une alternative Docker pour Windows qui permet de regrouper des applications incluant toutes les dépendances telles que .NET, Java ou des bases de données comme SQL Server ou MonhoDB dans des conteneurs isolés. Cependant, contrairement aux conteneurs de serveur Windows, ils ne sont pas supportés de manière native par le noyau Windows, donc similaire au Docker pour Windows, une machine virtuelle est alors nécessaire pour compenser les incohérences. Les conteneurs Turbo fonctionnent par conséquent sur le Spoon Virtual Machine Engine (SVM), qui sert d’interface avec le noyau Windows. Turbo échange aussi des applications pour conteneurs via un hub basé sur le Cloud. Le logiciel est bien documenté, mais reçoit peu d’attention et d’écho dans la presse spécialisée par rapport à Docker.

VMware ThinApp

VMware ThinApp est un outil de virtualisation d’applications de bureau. Le logiciel permet de fournir des applications dans des infrastructures informatiques complexes sans conflit. Pour cela, ils sont empaquetés dans un fichier exécutable EXE ou MSI, y compris toutes les dépendances, et donc isolés du système d’exploitation sous-jacent et d’autres applications. Le fichier créé par ThinApp peut être exécuté sans installation (et donc sans droits d’administration) sur n’importe quel système Windows, en option aussi à partir d’un support de stockage portable (par exemple une clef USB). ThinApp offre une alternative à Docker lors de la migration d’applications héritées ou de l’isolation de programmes critiques.