Alternative à Docker : aperçu des technologies de conteneurs
L'équipe éditoriale IONOS
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é ?
Technologie de conteneur sous Linux
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.
Chroot signifie « change root ». C’est une ligne de commande disponible sous les systèmes d’exploitation de type Unix pour changer le répertoire racine (root) d’un processus en cours d’exécution et de ses processus enfants. Une application s’exécutant dans un tel environnement modifié (appelé Chroot Jail) ne peut généralement pas accéder à d’autres fichiers en dehors du répertoire sélectionné. Cependant, comme le Chroot n’a pas été développé en tant qu’élément de sécurité, cet isolement est relativement facile à surmonter.
Docker
Celui qui s’intéresse aux logiciels de conteneurs est tôt ou tard confronté à Docker. En seulement quelques années, le projet open source de la société de logiciels du même nom Docker Inc. a réussi à faire de la technologie des conteneurs un sujet de premier plan dans les domaines du déploiement de logiciels (Software Deployement), DevOps et Continuous-Delivery.
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 :
Configuration système requise et systèmes pris en charge
| Noyau Linux requis | Linux Version 3.10 ou au-dessus |
|---|---|
| Distributions Linux supportées | Docker Community Edition (CE) : Ubuntu, Debian, CentOS et Fedora, Docker Enterprise Edition (EE) : Ubuntu, Red Hat Enterprise Linux, CentOS, Oracle Linux et SUSE Linux Enterprise Server |
| Autres plateformes | Docker Community Edition (CE) : Microsoft Windows 10 (Pro, Enterprise ou Education avec 64 bits), MacOS (Yosemite 10.10.3 ou supérieur), Microsoft Azure, Amazon Web Services (AWS) Docker, Enterprise Edition (EE) : Microsoft Windows Server 2016, Microsoft Windows 10 (Pro, Enterprise ou Education avec 64 bits), Microsoft Azure, Amazon Web Services (AWS) |
| Format du conteneur | Conteneur Docker |
| Licence | Apache 2.0 |
| Langage de programmation | Go |
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.
| Avantages | Inconvénients |
|---|---|
| Docker prend en charge différents systèmes d’exploitation et plateformes de Cloud. | Le moteur Docker ne prend en charge que son propre format de conteneur. |
| Avec Swarm et Compose, la plateforme Docker offre déjà des outils natifs d’orchestration et de gestion de clusters. | Le logiciel est disponible sous la forme d’un fichier programme monolithique contenant toutes les caractéristiques. |
| Le Dokcer Hub fournit aux utilisateurs un registre local central pour les ressources de Dockers. | Les conteneurs Docker n’isolent que les processus individuels. Les conteneurs système complets ne sont pas pris en charge. |
| L’écosystème sans cesse croissant fournit aux utilisateurs divers outils de docker, plugins et composants d’infrastructure. |
la technologie de conteneurs a été développée à l’origine pour exécuter plusieurs systèmes d’exploitation virtuels dans des environnements isolés sur le même noyau. Dans ce cas, nous parlons de système conteneur complet. La plateforme de conteneurs Docker, quant à elle, se concentre sur les conteneurs d’applications, dans lesquels chaque application s’exécute dans son propre environnement virtuel. Alors que les conteneurs système complets sont conçus de manière à ce que divers processus puissent y être exécutés, une application de conteneur ne contient qu’un seul processus. Les applications complexes sont donc implémentées avec Docker en tant qu’applications multi-conteneurs.
rkt de CoreOS
Sur le marché de la virtualisation par conteneurs, le concurrent le plus féroce de Docker est l’environnement d‘exécution rkt (prononcé : « Rocket ») du distributeur Linux CoreOS. Le projet de logiciel a déjà été présenté en 2014.
Alex Polvi, le PDG, a cité l’insatisfaction à l’égard du développement du projet Docker comme l’une des raisons de l’abandon de la plateforme Docker qui, jusqu’alors, pouvait compter sur le soutien de l‘équipe de développement CoreOS. Selon Polvi, le leader du marché s’est en effet éloigné de l’objectif de développer une technologie de conteneur standard et se concentre plutôt sur la commercialisation d’une plateforme de développement d’applications monolithique.
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.
Configuration système requise et systèmes pris en charge
| Noyau Linux requis | Tout noyau amd64 moderne |
|---|---|
| Distributions Linux prises en charge | Arch Linux, CentOS, CoreOS, Debian, Fedora, NixOS, openSUSE, Ubuntu, Void |
| Autres plateformes | macOS ou Windows utilisant le logiciel de développement virtuel Vagrant |
| Format de conteneur | appc, Conteneur Docker ; d’autres images de conteneurs peuvent être converties au format rkt via Quay |
| Licence | Apache 2.0 |
| Langage de programmation | Go |
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.
depuis la version 1.11, les conteneurs ne sont plus exécutés directement par le daemon Docker, ni même avec Docker. A la place, un processus daemon appelé Containerd est utilisé.
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.
| Avantages | Inconvénients |
|---|---|
| En plus de son propre format de conteneur, rkt supporte aussi les conteneurs Docker et permet de convertir n’importe quelle image de conteneur via Quay au format rkt ACI. | Comparé à Docker, il y a beaucoup moins d’intégrations tierces disponibles pour rkt. |
| Des techniques comme la technologie KVM et la technologie Container d’Intel permettent de protéger les conteneurs logiciels les uns des autres. | rkt est optimisé pour le fonctionnement des conteneurs d’application. Les systèmes complets de conteneurs ne sont pas pris en charge. |
LXC
L’alternative de Docker, LXC, est un ensemble d’outils, de templates, de bibliothèques et de binding de langage, qui forment ensemble une interface d’espace utilisateur (userspace) avec les fonctions de conteneur natives du noyau Linux. LXC offre aux utilisateurs Linux un moyen pratique de créer et de gérer des applications et des systèmes de conteneurs.
les binding de langage sont des adaptateurs, appelés Wrapper (to wrap signifie envelopper) qui construisent des ponts entre les différents langages de programmation et permettent ainsi de relier les différentes parties du programmes les unes aux autres.
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.
Configuration système requise et systèmes pris en charge
| Noyau Linux requis | Linux Version 2.6.32 ou au-dessus |
|---|---|
| Distributions Linux prises en charge | LXC est inclus dans la plupart des distributions Linux, Les bibliothèques suivantes sont nécessaires : C-Bibliotheque : glibc, musl libc, uclib ou bionic, Bibliothèques supplémentaires : libcap, libapparmor, libselinux, libseccomp, libgnutls, liblua, python3-dev |
| Autres plateformes | aucune |
| Format de conteneur | Linux Container (LXC) |
| Licence | GNU LGPLv2.1+ |
| Langage de programmation | C, Python 3, Shell, Lua |
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.
| Avantages | Inconvénients |
|---|---|
| LXC est optimisé pour l’exploitation de systèmes complets de conteneurs. | Le fonctionnement des conteneurs d’applications ne fait pas partie du fonctionnement standard. |
| Il n’y a pas d’implémentation native pour les systèmes d’exploitation autres que Linux. |
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.
Nova est le composant informatique central du système d’exploitation OpenStack, qui sert à fournir et à gérer les systèmes virtuels dans les architectures de Cloud computing. OpenStack Nova supporte différentes technologies de virtualisation au niveau de l’hyperviseur et du système d’exploitation.
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.
Configuration système requise et systèmes pris en charge
| Noyau Linux requis | comme LXC |
|---|---|
| Distributions Linux prises en charges | Ligne de commande client (lxc) : Ubuntu 14.04 LTS, Ubuntu 16.04 LTS, nova-compute-lxd : Ubuntu 16.04 LTS |
| Autres plateformes | Aucune |
| Format de conteneur | Linux Container (LXC) |
| Licence | Apache 2.0 |
| Langage de programmation | Go |
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.
| Avantages | Inconvénients |
|---|---|
| LXD est optimisé pour l’exploitation de systèmes complets de conteneurs. | Le fonctionnement des conteneurs d’application n’est pas une application standard |
| Le client LXD peut être configuré pour Windows et MacOs et permet le contrôle à distance du daemon LXD via REST-API. | La daemon LXD nécessite un noyau Linux. |
Linux-VServer
Linux-VServer est une technique de virtualisation au niveau du système d’exploitation qui utilise des techniques d’isolation du noyau Linux similaires aux conteneurs logiciels. Plusieurs unités virtuelles sont exploitées sur un noyau Linux commun, dont les ressources (systèmes de fichiers, CPU, adresses réseau et mémoire) sont divisées en partitions compartimentées par un mécanisme de Jails. Dans la terminologie Linux VServer, une telle partition est appelée « Security Context » et est créée à l’aide de techniques standards telles que le routage segmenté, le Chroot et le quota. Un système virtualisé dans un tel Security Context est appelé Virtual Private Server (VPS).
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.
la virtualisation au niveau du système d’exploitation via Linux-VServer n’a rien à voir avec le projet Linux Virtual Server, dans lequel une technique de Load Balancing pour les clusters Linux est développée.
Configuration système requise et systèmes pris en charge
| Noyau Linux requis | Linux Version 2.6.19.7 ou plus élevée |
| Distributions Linux supportées | Toutes les distributions Linux |
| Autres plateformes | Aucune |
| Format de conteneur | Linux-VServer utilise un concept de conteneur similaire appelé Security Context |
| Licence | GNU GPL v.2 |
| Langage de programmation | C |
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.
| Avantages | Inconvénients |
|---|---|
| Alors que Docker ne peut enregistrer les changements dans un conteneur qu’en créant une nouvelle image à partir d’un conteneur en cours d’exécution, Linux-VServer fournit un système de fichiers commun pour tous les VPS sur l’hôte, dans lequel les états actuels peuvent être sauvegardés. | Linux-VServer nécessite une modification du noyau Linux. |
| Aucune nouvelle version depuis 2007 |
OpenVZ/Virtuozzo 7
Depuis juillet 2016, la version 7 de la plateforme de virtualisation OpenVZ des utilisateurs de Parallels est disponible en tant que distribution Linux indépendante. Le logiciel est basé sur Red Hat Enterprise Linux 7 (RHEL) et permet le fonctionnement de systèmes invités qui peuvent être implémentés sous forme de machines virtuelles ou bien sous forme de conteneurs. Avec la nouvelle base de code, OpenVZ se rapproche de Virtuozoo 7, que Parallels commercialise comme un produit Entreprise. Une comparaison directe des deux solutions de virtualisation peut être trouvée dans le Wiki OpenVZ Wiki.
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.
Configuration système requise et systèmes pris en charge
| Noyau Linux requis | RHEL7 (3.10) |
|---|---|
| Distributions Linux supportées | Virtuozzo Linux, RHEL7 |
| Autres plateformes | Aucune |
| Format de conteneur | Virtuozzo Containers |
| Licence | OpenVZ: GNU GPL v.2, Virtuozzo 7 : licence propriétaire |
| Langage de programmation | C |
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.
| Avantages | Inconvénients |
|---|---|
| Parallels offre une distribution Linux complète optimisée pour les scénarios de virtualisation avec OpenVZ et Virtuozzo. | OpenVZ et Virtuozzo fournissent des conteneurs pour faire fonctionner des systèmes d’exploitation complets. Si vous êtes à la recherche d’une alternative professionnelle pour isoler des processus individuels, vous devriez choisir une plateforme différente. |
| En plus des conteneurs système, OpenVZ et Virtuozzo peuvent également faire fonctionner des machines virtuelles avec un overhead minimum. | OpenVZ et Virtuozzo sont limités aux distributions Linux RHEL7 et Virtuozzo Linux. |
runC
Concernant runC, il s’agit moins d’une alternative à Docker qu’un spin-off de l’environnement d’exploitation de conteneurs développé par Docker en un projet open source indépendant sous le patronage de l‘Open Container Initiative (OCI).
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.
Configuration système requise et systèmes pris en charge
| Noyau Linux requis | Tous les noyaux Linux |
|---|---|
| Distributions Linux prises en charge | Toutes les distributions Linux actuelles |
| Autres plateformes | Aucune |
| Format de conteneur | OCI Bundle |
| Licence | Apache 2.0 |
| Langage de programmation | Go |
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.
| Avantages | Inconvénients |
|---|---|
| runC est basé sur le standard industriel de l’Open Container Initiative (OCI). | Des outils externes sont nécessaires pour créer des images de conteneurs. |
Comparatif des alternatives de Docker
Le tableau suivant montre une comparaison des alternatives Docker présentées.
| Docker | rkt | LXC | LXD | |
|---|---|---|---|---|
| Technologies de virtualisation | OS-Level | OS-Level, Hypervisor | OS-Level | OS-Level |
| Full System Container | Non | Non | Oui | Oui |
| App Container | Oui | Oui | Non | Non |
| Licence | Apache 2.0 | Apache 2.0 | GNU LGPLv2.1+ | Apache 2.0 |
| Format de conteneur | Docker-Container | appc, Docker-Container | Linux Container (LXC) | Linux Container (LXC) |
| Plateforme supportée | Linux, Windows, Mac0S, Microsoft Azure, Amazon Web Services (AWS) | Linux, Windows, MacOS | Linux | Linux |
| Dernière version | Avril 2017 | Février 2017 | Janvier 2017 | Mars 2017 |
| Patch du noyau Linux requis | Non | Non | Non | Non |
| Langage de programmation | Go | Go | C, Python 3, Shell, Lua | Go |
| Linux-VServer | OpenVZ | runC | |
|---|---|---|---|
| Technologies de virtualisation | OS-Level | OS-Level, Hyperviseur | OS-Level |
| Full System Container | Oui | Oui | Non |
| App Container | Non | Non | Oui |
| Licence | GNU GPL v.2 | GNU GPL v.2 | Apache 2.0 |
| Format de conteneur | Security Context | Virtuozzo Containers | OCI Bundle |
| Plateforme supportée | Linux | Linux (uniquement Virtuozzo Linux, RHEL7) | Linux |
| Dernière version | Avril 2007 | Juillet 2016 | Mars 2017 |
| Patch du noyau Linux requis | Oui | Distribution indépendante | Non |
| Langage de programamtion | C | C | Go |
Technologie des conteneurs dans d’autres systèmes d’exploitation
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.
FreeBSD Jail
Les Jail (« prisons ») sont l’une des principales caractéristiques de sécurité du système d’exploitation de type Unix FreeBSD. Un jail est un environnement Chroot étendu qui configure une instance virtuelle complète du système d’exploitation dans un répertoire BSD séparé et a un degré élevé d’isolation par rapport aux Jails Chroot sous Linux. Chaque Jail a sa propre arborescence de répertoires. En outre, la salle de traitement et l’accès aux groupes d’utilisateurs, aux interfaces réseau et aux mécanismes IPC sont limités. Ceci empêche les processus dans un environnement Jail d’accéder à d’autres répertoires ou fichiers en dehors de l’environnement isolé et d’affecter d’autres processus sur le système hôte. De plus, chaque Jail peut se voir attribuer son propre nom d’hôte et son adresse IP.
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.
FreeBSD est une version libre et open source de la Berkeley Software Distribution (BSD), une variante du système d’exploitation Unix développé à l’Université de Californie à Berkeley depuis 1977.
| Avantages | Inconvénients |
|---|---|
| Optimisé pour une virtualisation complète du système. | L’isolation des processus individuels (comme pour Docker) n’est pas prise en charge. |
| La virtualisation via Jail nécessite un système BSD (NetBSD, FreeBSD et OpenBSD). |
Oracle Solaris Zones
Même sous Solaris, vous pouvez configurer plusieurs environnements d’exécution, nommés zones, au sein d’une installation de système d’exploitation qui partage le noyau commun du système d’exploitation. Une distinction est faite entre les zones globales et les zones non globales.
- Zones globales : chaque installation Solaris comprend une zone globale qui fonctionne comme système d’exploitation par défaut et est utilisée pour l’administration. Tous les processus du système fonctionnent dans la zone globale, à moins qu’ils n’aient été externalisés dans des zones non globales.
- Zones non globales : les zones non globales sont des environnements virtuels distincts crées dans la zone globale d’une installation Solaris. L’isolation des zones individuelles non globales est basée sur un Jail Chroot modifié, similaire à FreeBSD. Chacune de ces zones se voit attribuer son propre nom d’hôte et une carte réseau virtuelle. Les parts de ressources du matériel sous-jacent sont allouées soit par le biais d’un calendrier de partage équitable, soit dans le cadre de la gestion des ressources.
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.
| Avantage | Inconvénient |
|---|---|
| L’implémentation native de zones Solaris permet une exploitation très efficace des environnements virtuels avec un overhead minimum. | L’utilisation des zones Solaris nécessite le système d’exploitation propriétaire Oracle Solaris ou sa variante open source OpenSolaris. |
Technologie de conteneurs sous Windows
Depuis l’intégration d’un port Docker natif dans Windows Server 2016, la technologie des conteneurs est également entrée dans l’univers Microsoft. En étroite collaboration avec l’équipe de développement de Docker, le noyau Windows a été amélioré avec des fonctionnalités qui fonctionnent de la même manière que les groupes de contrôle et les espaces de noms sous Linux, permettant ainsi une virtualisation qui économise les ressources au niveau du système d’exploitation.
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.
