## Conteneurs et machines virtuelles deux approches de la virtualisation
Si l’on peut faire remonter l’origine des mécanismes d’isolation de conteneurs à la commande chroot introduite en 1982 dans les systèmes UNIX, c’est au début des années 2000 que cette technologie va prendre sa forme actuelle avec des solutions telles que Linux-VServer (2000), Free BSD Jail (2000), OpenVZ (2005) ou Solaris Containers (2004)[^oslvlvirt].
Ces 10 dernières années, la virtualisation d’infrastructure informatique, jusqu’alors dominée par les machines virtuelles, a connu un grand changement, et les technologies basées sur les conteneurs sont devenues un incontournable pour de nombreuses applications : développement, hébergement d’application web, calcul intensif, IoT, déploiement d’applications…
Si l’on peut faire remonter l’origine des mécanismes d’isolation de conteneurs à la commande `chroot` introduite en 1982 dans les systèmes UNIX, c’est au début des années 2000 que cette technologie va prendre sa forme actuelle avec des solutions telles que Linux-VServer (2000), Free BSD Jail (2000), OpenVZ (2005) ou Solaris Containers (2004)[^oslvlvirt].
Introduite en 2013, Docker n’est pas la seule solution de conteneur existant sur le marché, mais elle reste l'une des plus populaires. Parmi ses concurrents, on peut citer [LXC](https://linuxcontainers.org/)(pour Linux Container) et son successeur LXD (Linux Container Daemon), [CoreOS rkt](https://coreos.com/rkt/docs/latest/)(ou simplement Rkt), [OpenVz](https://openvz.org/), [Apache Mesos](http://mesos.apache.org/documentation/latest/mesos-containerizer/), [Podman](https://podman.io/) ou encore [containerd](https://containerd.io/).
Devant ce grand nombre de solutions, l'[Open Container Initiative](https://www.opencontainers.org/)(OCI) de la Linux Foundation définit des spécifications afin de garantir l’interopérabilité entre les solutions à base de conteneurs. Elle a défini des spécifications pour le format d’image OCI `image-spec` le l’environnement d’exécution `runtime-spec` – basé sur `runC` développé initialement par Docker.
...
...
@@ -28,7 +28,7 @@ Les infrastructures « cloud » peuvent mettre en œuvre ces 2 mécanismes pou
Dans les deux cas (machine virtuelle ou conteneur), un **orchestrateur** peut-être utilisé pour gérer l’infrastructure :
- Un orchestrateur de machines virtuelles ([Vagrant](https://www.vagrantup.com/), [Open Nebula](https://opennebula.org), [Open Stack](https://openstack.org)…) permet de gérer un ou plusieurs hyperviseurs (KVM, Virtualbox, VMWare...) et d'y déployer des machines virtuelles.
- Un orchestrateur de conteneurs ([Docker Swarm](https://www.docker.com/products/docker-swarm), [Kubernetes](http://kubernetes.io), [Amazon ECS](https://aws.amazon.com/ecs/), [Azure Container Service](https://azure.microsoft.com/en-us/blog/azure-container-service-preview/)…) permet de déployer et de gérer les conteneurs sur plusieurs systèmes hôtes.
- Un orchestrateur de conteneurs ([Docker Compose](https://docs.docker.com/compose/), [Docker Swarm](https://www.docker.com/products/docker-swarm), [Kubernetes](http://kubernetes.io), [Podman](https://podman.io/), [Amazon ECS](https://aws.amazon.com/ecs/), [Azure Container Service](https://azure.microsoft.com/en-us/blog/azure-container-service-preview/)…) permet de déployer et de gérer les conteneurs sur plusieurs systèmes hôtes.
> **Note** : Certains orchestrateurs comme Vagrant, Open Nebula ou Terraform permettent de gérer tant des VM que des conteneurs.
...
...
@@ -56,7 +56,7 @@ De même, s’ils facilitent la mise en place de micro-services, **les conteneur
Malgré un mythe persistant, **les conteneurs ne peuvent remplacer les machines virtuelles dans tous les cas** ! Ils fournissent par exemple moins d’isolation que les machines virtuelles, puisque les conteneurs s’exécutent quand même dans un même système hôte. Si l’isolation d’un système est cruciale, une machine virtuelle reste donc préférable. Là où les conteneurs se révèlent intéressants, c’est qu’ils permettent facilement de mieux isoler entre elles des applications qui s’exécutaient déjà sur un même hôte.
Une autre limitation des systèmes de virtualisation à base de conteneur est que, comme ils opèrent au niveau du système d’exploitation et pas du hardware, **il n’est pas possible d’exécuter des conteneurs avec un système d’exploitation différent de celui de leur hôte**. Ainsi sous Linux, seuls des conteneurs Linux peuvent être exécutés. Il est toutefois possible d’exécuter des distributions Linux différentes de celle du système hôte, par exemple des conteneurs Debian ou CentOS peuvent sans problème s’exécuter sous Ubuntu, et de même une machine Ubuntu 18.04 peut sans problème exécuter d’autres versions d’Ubuntu. Déployer des conteneurs Linux sous MacOSX ou Windows nécessite donc une machine virtuelle Linux.
Une autre limitation des systèmes de virtualisation à base de conteneur est que, comme ils opèrent au niveau du système d’exploitation et pas du hardware, **il n’est pas possible d’exécuter des conteneurs avec un système d’exploitation différent de celui de leur hôte**. Ainsi sous Linux, seuls des conteneurs Linux peuvent être exécutés. Il est toutefois possible d’exécuter des distributions Linux différentes de celle du système hôte, par exemple des conteneurs Debian ou CentOS peuvent sans problème s’exécuter sous Ubuntu, et de même une machine Ubuntu 18.04 peut sans problème exécuter d’autres versions même plus récentes d’Ubuntu. Déployer des conteneurs Linux sous MacOSX ou Windows nécessite donc une machine virtuelle Linux.
Ajoutons à cela que **la majorité des solutions de virtualisation à base de conteneurs sont disponibles sous Linux uniquement**, puisqu’elles se basent pour la plupart sur les mêmes mécanismes du noyau Linux.
...
...
@@ -73,19 +73,19 @@ J'ai choisi Docker pour mon infrastructure pour les raisons suivantes :
-**Multi-architecture** : Docker est disponible pour diverses architectures matérielles et peut être déployé tant sur des serveurs que sur de l'IoT.
-**Large écosystème** : Docker fournit et supporte un large écosystème d’outils qui facilitent grandement le travail des informaticiens qu’ils soient administrateurs système, développeurs, packageurs d’application… Docker est de plus intégré comme backend à de nombreux outils : orchestrateurs (Vagrant), plateformes de CI/CD (Gitlab), outils d’automatisation (Ansible)
-**Disponibilité d’applications** : De nombreuses applications web sont déjà prêtes à être déployées avec Docker via l’outil `docker compose`. Des générateurs de configuration sont également disponibles sur le web.
-**Orchestrateurs** : Des outils d’orchestration de parcs informatiques compatibles Docker sont déjà disponibles comme Kubernetes, Rancher, Portainer, OpenShift… Docker lui-même supporte le déploiement sur un cluster nativement via Docker Swarm.
-**Portabilité dans le cloud** : Les conteneurs Docker peuvent être déployés dans le cloud (Azure, Amazon AWS) ou sur des « nano-ordinateurs (Raspberry, Olimex…) » afin de mettre en place des solutions IoT (Internet of Things).
-**Communauté et documentation** : Docker a une large communauté et une grande quantité de documentation (sites web, livres, MOOCS, tutoriels…) est disponible.
-**Orchestrateurs** : Des outils d’orchestration de parcs informatiques compatibles Docker sont déjà disponibles comme Kubernetes, Rancher, OpenShift… mais Docker lui-même intègre ses propres orchestrateurs permettant le déploiement sur un cluster via Docker Swarm ou sur une machine locale avec Docker Compose.
-**Portabilité dans le cloud** : Les conteneurs Docker peuvent être déployés dans le cloud (Azure, Amazon AWS) ou sur des « nano-ordinateurs » (Raspberry Pi, Olimex…) afin de mettre en place des solutions IoT (Internet of Things).
-**Communauté et documentation** : Docker a une large communauté et une grande quantité de documentation (sites web, livres, MOOCS, tutoriels…) est disponible. La documentation officielle est extrêmement complète et est fréquemment mise à jour.
### Les technologies derrière Docker
Comme plusieurs autres technologies de conteneurs telles que LXC, Docker se base sur des mécanismes et services de base du noyau Linux afin d’isoler les applications[^lxc] :
Comme plusieurs autres technologies de conteneurs telles que LXC[^lxc], Docker se base sur des mécanismes et services de base du noyau Linux afin d’isoler les applications :
-`cgroups` (control groups) assure la distribution des ressources du système hôte.
-`namespace` assurent l’isolation des processus entre eux.
-`namespace` assurent l’isolation des processus entre eux.
-`containerd` fournit des services nécessaires pour le fonctionnement des conteneurs.
Docker est donc une technologie intrinsèquement liée à Linux et ne peut s’exécuter sur les autres systèmes d’exploitation qu’à condition de passer par une machine virtuelle exécutant Linux, exception faite de Windows qui permet de faire s’exécuter des conteneurs Windows via une implémentation native de *runC* [^runc].
Comme je l'ai déjà évoqué plus haut, Docker est donc une technologie intrinsèquement liée à Linux et ne peut s’exécuter sur les autres systèmes d’exploitation qu’à condition de passer par une machine virtuelle exécutant Linux. Il y a toutefois une exception pour Docker sous Windows qui permet de faire s’exécuter des conteneurs Windows via une implémentation native de *runC* [^runc].
Docker s’est vu adjoindre **deux standards** importants :
-**Dockerfile** : les étapes nécessaires à la configuration et à la construction d'une image Docker sont décrites dans un *Dockerfile*.
-**Volume** : un *volume* est un stockage de fichier permanent ou volatile monté dans un conteneur. Un volume peut-être partagé entre plusieurs conteneurs et peut correspondre ou non à un emplacement sur le système de fichier de la machine hôte. Les volumes Docker peuvent également être distants (par exemple en utilisant NFS).
-**Réseau** : Docker permet de définir des interfaces réseaux virtuelles qui permettent aux conteneurs de communiquer entre eux au sein d’un hôte ou d’une *stack* ou avec l’extérieur. En particulier, les réseaux de type **overlay** permettent aux *services* d’une *stack* exécutés sur différents nœuds d’un cluster de communiquer entre eux.
-**Stack** : une *stack* (pile) est un ensemble de services (c’est-à-dire de conteneurs Docker) liés qui partagent une série de dépendances et peuvent être orchestrés (déployés et gérés) ensemble. Dans un *Swarm* Docker, une *stack* peut être répartie sur plusieurs hôtes Docker et certains services peuvent être répliqués afin de fournir une répartition de charge. Les stacks permettent la mise en place d’une architecture de type micro-services dans laquelle les composants nécessaires au fonctionnement d’une application (base de données, serveur web, environnement d’exécution PHP…) sont exécutés dans des conteneurs différents.
-**Stack** : une *stack* (pile) est un ensemble de services (c’est-à-dire d'applications qui s'exécutent dans des conteneurs Docker) liés qui partagent une série de dépendances et peuvent être orchestrés (déployés et gérés) ensemble. Dans un *Swarm* Docker, une *stack* peut être répartie sur plusieurs hôtes Docker et certains services peuvent être répliqués afin de fournir une répartition de charge. Les stacks permettent la mise en place d’une architecture de type micro-services dans laquelle les composants nécessaires au fonctionnement d’une application (base de données, serveur web, environnement d’exécution PHP…) sont exécutés dans des conteneurs différents.
-**Service** : un service est un des sous-éléments d’une *stack*. Un service peut-être répliqué, c’est à dire être rendus par plusieurs containers identiques que l'on nommera des *tasks* (ou tâches) dans le vocabulaire Docker. Cette réplication permet d’assurer le failover et un load balancing. Lorsque les services sont atomiques (chaque service intégrant une seule fonctionnalité comme un service serveur web, un service base de données et un service environnement d'exécution PHP-FPM), on parle alors de **micro-services**.
-**Orchestrateur** : outil de déploiement et de gestion de conteneurs, Docker en propose deux :
-**Docker Compose** : orchestrateur permettant de définir et de déployer des applications multi-services (*stack*) localement sur une machine. Cet outil est construit au-dessus de l'API de Docker. Même s'il peut être utilisé en production, il est plutôt destiné au développement ou à des architectures pour lesquelles Docker Swarm ne peut être utilisé (IoT par exemple).
-**Docker Swarm** : orchestrateur permettant le déploiement de services sur un cluster de plusieurs machines hôtes appelées nœuds. Docker Swarm est adapté pour les besoins de production.
-**Fichier docker-compose.yml** : bien que Docker Compose fournissent des commandes nécessaires pour déployer directement des services, ceux-ci peuvent également être définis dans un fichier de configuration `docker-compose.yml` qui reprend la définition de ses images, réseaux, volumes, options d’environnement… nécessaires au déploiement. Il devient alors possible de lancer tous les services en une seule commande. Ces fichiers `docker-compose.yml`peuvent aussi être utilisés pour déployer les services sur un cluster Docker Swarm.
-**Fichier docker-compose.yml** : bien que Docker fournisse des commandes nécessaires pour déployer directement des services, ceux-ci peuvent également être définis dans un fichier de configuration `docker-compose.yml` qui reprend la définition de ses images, réseaux, volumes, options d’environnement… nécessaires au déploiement. Il devient alors possible de lancer tous les services en une seule commande avec Docker Compose. Ces fichiers `docker-compose.yml`sont également utilisés pour déployer les services sur un cluster Docker Swarm.
-**Nœud** : hôte d’un cluster Docker Swarm. On distingue deux types de nœuds dans un cluster :
- les *managers* permettent la gestion du cluster (déploiement des services, états des ressources, création de volumes…),
- les *workers* exécutent les conteneurs des services.
Voici un exemple de fichier `Dockerfile` pour construire une image d'environnement d'exécution PHP :
Voici un exemple de fichier `Dockerfile` permettant de construire une image d'environnement d'exécution PHP :
```dockerfile
FROM phpdockerio/php72-fpm:latest
...
...
@@ -208,11 +208,13 @@ A cela s’ajoute des solutions liées à des clouds propriétaires :
***Azure Container Service** pour le cloud Azure
***Google Container Engine** pour le cloud Google
Toutefois, l’annonce de l’abandon de Docker dans **Kubernetes** fin 2020[^k8sdckrpanic] va fortement changer ce paysage. La question principale étant de savoir si les autres orchestrateurs compatibles Kubernetes comme OpenShift, Rancher et Microk8s vont suivre le même chemin ou s’ils vont continuer à proposer le support de Docker.
Toutefois, l’annonce de l’abandon de Dockershim (la couche permettant l'utilisation de Docker comme environnement d'exécution) dans **Kubernetes** fin 2020[^k8sdckrpanic] a créé une certaine panique et a changé ce paysage. Depuis sa version 1.24 sortie en 2022, Kubernetes utilise directement containerd sans passer par Docker[^k8snodckr].
Cette décision a donc créé deux écosystèmes différents, avec d'un côté les solutions compatibles avec Docker et de l'autre celles qui ont pris la même direction que Kubernetes. Il faudra sans doute encore attendre quelques mois voire quelques années pour voir quelles seront les conséquences de cette situation.
### Solution choisie dans le cadre de ce projet
Le cœur de ce brevet est construit autour de la mise en place d’une **infrastructure basée sur Docker Swarm avec Portainer comme interface de gestion**.
Le cœur de ce brevet est construit autour de la mise en place d’une **infrastructure basée sur Docker Swarm**.
Pourquoi ce choix ? Simplement par Docker Swarm est intégré à Docker qui était, au moment du démarrage de ce projet, le moteur de conteneur le plus populaire et ayant, de ce fait, la plus grande communauté et le plus de documentation disponible en ligne. De plus, Docker Swarm utilise des fichiers de déploiement de stack identiques à ceux de Docker Compose, lui-même utilisé pour de nombreuses applications. Cela permet d’écrire des fichiers de déploiement Docker Swarm pour de nombreuses applications et avec un minimum de travail d’adaptation.
...
...
@@ -260,19 +262,16 @@ Voici les raisons principales qui m'ont amené à choisir cette outil :
- Mettre en place un cluster prêt pour la production est très rapide environ 2h tout compris (c'est à dire y compris l'installation et la configuration des VM) pour un cluster de 5 machines; le mode swarm lui-même ne prend que 20 minutes pour sa mise en place !
> **Note** : Le mode Swarm de Docker est basé sur le projet open source Swarmkit[^swarmkit].
> - Le manager se base l’algorithme de consensus distribué RAFT pour gérer l’état global du cluster
### Noeuds en mode swarm
Dans un cluster en mode swarm, il existe deux types de nœuds[^swarmnodes] : *manager* et *worker*.
Un nœud de type *manager*est en charge de maintenir l'état du cluster, planifier les services et servir de point d’entrée à l’API REST de docker.
Les nœuds de type *manager* en charge de maintenir l'état du cluster, planifier les services et servir de point d’entrée à l’API REST de docker. Les managers se basent sur l’algorithme de consensus distribué RAFT pour gérer l’état global du cluster
Un nœud de type *worker*est en charge d’exécuter les conteneurs et services à la demande des nœuds *manager*.
Les nœuds de type *worker* en charge d’exécuter les conteneurs et services à la demande des nœuds *manager*.
> **Note** :
>
> - Sur une infrastructure de production, il est utile de multiplier le nombre de managers afin de garantir le fonctionnement du cluster en cas de perte de l’un d’entre eux. En règle générale, un cluster avec `N` nœuds manager résistera à la perte de `(N-1)/2` d’entre eux. Néanmoins augmenter le nombre de manager diminue les performances du cluster et il est déconseillé de dépasser 7 managers pour un cluster.
> - Les commandes `docker node [COMMAND] [OPTIONS]` permettent de gérer les nœuds du swarm.
> - Il est possible de changer le rôle d’un nœud avec les commandes `docker node promote` et `docker node demote`.
> - Il est possible d’exclure un manager des nœuds disponibles pour le déploiement de service du swarm en mettant sa disponibilité à la valeur `Drain` via la commande `docker node update`.
...
...
@@ -299,7 +298,7 @@ Afin d'assurer une redondance des managers, il est possible d'ajouter d'autres m
En particulier, les managers vont élire un Leader parmi eux via le système de consensus RAFT[^raft] [^swarmraft]. Celui-ci sera la référence pour l'état du swarm. S'il devient indisponible, les autres managers éliront un nouveau Leader parmi eux.
Typiquement, le nombre de manager sera de 1, 3 ou 5. Au-delà de 5, les performances du swarm risquent de diminuer à cause de la communication nécessaire entre les managers.
Typiquement, le nombre de manager sera de 1, 3 ou 5. Au-delà de 5, les performances du swarm risquent de diminuer à cause de la communication nécessaire entre les managers et il est déconseillé de dépasser 7 managers pour un cluster.
#### Redondance et distribution des managers
...
...
@@ -331,13 +330,12 @@ L'infrastructure de formation du portail est un exemple de swarm constitué d'un
L'infrastructure de développement du portail est un exemple d'un swarm avec 1 un seul manager et 2 workers.
Dans le cas des infrastructures de production et de QA du portail, le Swarm est constitué de 3 managers et d'un nombre variables de `D*n` workers où `D` est le nombre de data centers dans lequel les nœuds sont déployés et `n` le nombre de nœuds redondants. Pour les infrastructures du portail, à l'état initial, pour QA `n = 1`, pour la production `n = 3` répartis entre les 2 data centers (`D = 2` ).
Cela nous donne donc 2 workers pour la QA et 6 pour la production.
Dans le cas des infrastructures de production et de QA du portail, le Swarm est constitué de 3 managers et d'un nombre variables de `D*n` workers où `D` est le nombre de data centers dans lequel les nœuds sont déployés et `n` le nombre de nœuds redondants. Pour les infrastructures du portail, à l'état initial, pour QA `n = 1`, pour la production `n = 3` répartis entre les 2 data centers (`D = 2` ). Ce qui nous donne respectivement un total de 5 noeuds (3 managers et 2 workers) pour la QA et 9 pour la production (3 managers et 6 workers).
### Gérer les noeuds
Voici quelques commandes de gestion d'un Swarm Docker :
- Sortir un noeud worker (sur le worker à sortir) : `docker swarm leave`
- Rejoindre le swarm comme worker :
- sur le manager : `docker swarm join-token worker` (copier la commande obtenue)
...
...
@@ -438,6 +436,8 @@ En plus de ce mécanisme, Docker intègre un système de resolution de nom qui p
[^k8sdckrpanic]:Kubernetes Blog « Don't Panic: Kubernetes and Docker » https://kubernetes.io/blog/2020/12/02/dont-panic-kubernetes-and-docker/
[^k8snodckr]:« Kubernetes is Moving on From Dockershim: Commitments and Next Steps » https://kubernetes.io/blog/2022/01/07/kubernetes-is-moving-on-from-dockershim/
[^swarmkit]:« Swarmkit, a toolkit for orchestrating distributed systems at any scale » https://github.com/docker/swarmkit/
[^swarmnodes]:« How nodes work » https://docs.docker.com/engine/swarm/how-swarm-mode-works/nodes/
