Docker comme solution de virtualisation : théorie

Source : Wikimédia. Image sous licence Apache 2.

Source : Wikimédia. Image sous licence Apache 2.

Ça fait un petit moment maintenant que l’on entend un peu partout parler de la plateforme de virtualisation révolutionnaire qu’est Docker. Tellement qu’OVH va même la proposer sur son cloud (ou la propose déjà ?) via sa filiale RunAbove. En tant que passionné je ne pouvais pas passer à côté de cette techno, et je ne pouvais pas non plus m’empêcher de partager tout cela avec vous.

Je vous propose donc de découvrir Docker et ce que nous allons pouvoir faire avec, et on commence aujourd’hui avec un peu de théorie.

Docker est donc une plateforme de virtualisation par conteneur qui, contrairement à la virtualisation sur hyperviseur où vous devez créer de nouvelles machines complètes pour isoler celles-ci les unes des autres et s’assurer de leur indépendance, va vous permettre de créer des conteneurs qui vont uniquement contenir votre ou vos applications. Empaquetées sous forme de conteneurs, ces applications pourront ainsi être facilement déployées sur tout hôte exécutant Docker, chaque conteneur restant parfaitement indépendant !

Le nom et le vocabulaire de cette technologie n’ont pas été choisis au hasard : tout comme les conteneurs en métal, toujours fabriqués selon les mêmes standards, peuvent être pris en charge par n’importe quel transporteur (et peu importe ce qu’il y a dedans), une application « Dockerisée » doit pouvoir être exécutée sur n’importe quel hôte faisant tourner Docker, peu importe son contenu !

Allez, comme c’est toujours plus facile en image, voici deux beaux schémas !
La virtualisation par hyperviseur.

La virtualisation par hyperviseur (Erratum : KVM est considéré comme un hyperviseur de type 1).

Avec la virtualisation par hyperviseur de type 2 (VMware Workstation, VirtualBox…), chaque hôte invité virtualise un environnement complet, ce qui permet notamment de pouvoir exécuter un système virtualisé différent du système hôte (typiquement du Windows sur une Red Hat par exemple).

La virtualisation par conteneur telle que Docker la propose permet à un système Linux de contenir un ou plusieurs processus dans un environnement d’exécution indépendant : indépendant du système hôte et des conteneurs entre eux.

La virtualisation par conteneur.

La virtualisation par conteneur.

Dans ce cas, conteneur virtualisé et système hôte sont fortement liés et c’est pour cela que cette technologie, qui existe pourtant depuis longtemps (OpenVZ a déjà presque 10 ans !), était peu répandue jusqu’à maintenant. Certains appellent d’ailleurs ce type de virtualisation la paravirtualisation… Mais alors comment ça marche ?

Docker simplifie l’utilisation d’outils existants

Et c’est sa principale force. S’il est possible d’isoler des conteneurs : processus, interfaces réseau, points de montage, c’est grâce à l’utilisation des namespaces Linux. Un processus qui s’exécute dans un espace de nom correspondant à un conteneur ne sera visible que par ce conteneur et le système hôte exécutant ce conteneur, point. Les deux précédents schémas vous feront comprendre aussi que la virtualisation par conteneur est plus rapide que la virtualisation par hyperviseur car les conteneurs ont directement accès aux ressources matérielles de l’hôte. La consommation de ces ressources pouvant être gérées par l’hôte en question grâce aux control groups (cgroups) du noyau Linux.

Tout ceci fait donc de Docker un chroot dopé aux stéroïdes.

À ses débuts Docker était une couche d’abstraction à LXC car il permettait de s’affranchir de la complexité de ce dernier en gérant pour nous un certain nombre d’opérations, plus facilement. Aujourd’hui Docker va beaucoup plus loin que LXC puisqu’il dispose de sa propre plate-forme : Libcontainer (bien que LXC soit toujours proposé sous forme de plugin).

Et ce qui démarque Docker des autres, c’est la rapidité des flux de travail que vous allez pouvoir mettre en place : tout est fait pour réduire le temps entre le développement, les tests, le déploiement et l’utilisation de votre application en production. Et pour cela, on trouve les images.

Une image est le composant de base de Docker. C’est un instantané d’un système d’exploitation (par exemple Debian). Ces images sont disponibles sur un dépôt public, géré par Docker, appelé le registre. Schématisons ceci de manière plus précise…

Les images Docker

Les images Docker

L’exemple ci-dessus se compose de deux conteneurs, parfaitement isolés (d’où les couleurs différentes). On trouve à la base les composants nécessaires à Docker, et qui sont fournis par le noyau Linux de l’hôte. On trouve ensuite deux images : Debian et BusyBox.

Une image ne peut être modifiée directement, elle reste toujours en lecture seule.

Remarquez qu’un environnement d’exécution peut nécessiter l’empilement de plusieurs images (ici emacs, puis Nginx), rendu possible par les fonctionnalités de copy-on-write des modules de stockages utilisés par Docker (AuFS, Btrfs).

Enfin, on trouve la couche supérieure, accessible en écriture, qui contiendra toutes les modifications apportées à l’application.

Pour résumer : lorsque nous allons lancer un conteneur pour exécuter une application à partir d’une image, Docker va monter le système de fichier de l’image souhaitée en lecture seule, et ajouter une couche accessible en écriture par dessus, via UnionFS.

On fait donc de sacrées économies de consommation puisque plusieurs conteneurs utilisant la même image de base utiliseront le même système de fichiers !

Le Hub, un GitHub pour vos images Docker

Si vous souhaitez conserver les modifications que vous avez apporté à votre application, vous pouvez enregistrer celles-ci dans un nouvelle image qui sera uniquement composée des différences apportées. Cette image sera identifiée par Docker grâce à un numéro unique, et vous pourrez pousser (push) et stocker cette image vers le dépôt public Docker.

À travers le Docker Hub, vous aller pouvoir gérer vos images de la même manière que vous gérer votre code avec Git. Le vocabulaire est le même…

Pour conclure cette première approche…

J’espère que je n’ai perdu personne… Docker repose sur des concepts qui ne sont pas forcément évidents au premier abord. Vous verrez néanmoins que toutes ces explications seront plus claires lorsque nous commencerons à manipuler images et conteneurs.

Si je vous parle aussi de Docker, c’est parce que les phases de test de Sonerezh approchent, et qu’il va falloir tester notre bébé sous différentes architectures avant de le proposer au public : différentes versions de PHP, Apache, Nginx, etc. Nous verrons donc dans les prochains articles comment utiliser Docker, et les exemples se feront donc avec Sonerezh.

À bientôt 😉

Cet article fait partie d’une suite :

  1. Docker comme solution de virtualisation : théorie
  2. Docker comme solution de virtualisation : installation
  3. Docker comme solution de virtualisation : les conteneurs
  4. Docker comme solution de virtualisation : les commits
  5. Docker comme solution de virtualisation : les liaisons
  6. Docker comme solution de virtualisation : les volumes

Cet article vous a plu ? Partagez-le sur les réseaux sociaux !

Twitter Facebook Google Plus email