Qu’est qu’un conteneur exactement ?

Pour introduire ce qu’est un conteneur, nous allons rappeler les avantages et les inconvénients des environnements à disposition aujourd’hui pour fournir une pile applicative à une application pour la faire fonctionner : les serveurs physiques, les serveurs virtuels et les conteneurs.

Les serveurs physiques

Le moyen standard pour faire tourner une application.

Avantages :

• Utilisation de 100% des ressources système CPU, RAM, disque, réseau. il n’y a pas d’overhead.
• Isolation complète et physique d’une application.

Inconvénients :

• Temps de déploiement : pour l’acquisition de nouveaux serveurs, il faut passer une commande qui peut prendre du temps ou bien avoir du stock de spare ce qui est couteux.
• Gaspillage de ressources : bien qu’il présente le meilleur ratio coût / ressource, il n’est pas dimensionnable ce qui peut provoquer du gaspillage de ressources.
• Scalabilité : Toute modification nécessitera l’action de l’hébergeur et le temps dépendra de sa réactivité.
• Portabilité : Deux serveurs physique ne seront pas exactement les mêmes, cela peut aboutir à des problèmes lors de migrations d’applications.

Les serveurs virtuels

Avantages :

• Provisionnement adéquat des ressources : l’introduction d’un hyperviseur va permettre de séparer les ressources allouées aux différentes machines virtuelles au sein d’un cluster physique. Chaque VM possède aussi son propre OS différent.
• Facile à dimensionner, sauvegarder et déplacer : les solutions de virtualisation embarquent les outils pour dimensionner facilement les instances, les sauvegarder sous forme de snapshot et les installer ailleurs.
• Coût : Les fournisseurs Cloud facturent à la minute, ce qui peut être avantageux.

Inconvénients :

• Overhead : une petite partie des ressources physique est utilisée pour gérer le fonctionnement de l’hyperviseur (entre 5 et 10% de la RAM par exemple).
• Dépendance au constructeur : le choix d’une solution de virtualisation nous empêche de migrer les machines virtuelles sur l’infrastructure d’un autre constructeur.
• Configuration différente en Dev et en Prod : pour passer une application en production, le choix de la configuration des services est laissée à l’appréciation des administrateurs système, même une documentation ne permettra pas d’avoir en environnement égal bit-à-bit à celui du développeur.

Les conteneurs :

La différence ici par rapport aux machines virtuelles est que les conteneurs vont utiliser le même kernel du serveur, l’isolation des ressources est assuré par des développements au sein du noyau Linux, des développements plus ou moins récent.

Avantages :

• Isolation : chaque service, application tourne dans son propre conteneur, son propre système de fichier, sa propre mémoire, ses propres devices et interfaces réseau.
• Légèreté : Les conteneurs n’utilisant pas d’hyperviseur, ils sont beaucoup plus légers pour fonctionner qu’une machine virtuelle, nous pouvons mettre des centaines voire des milliers de conteneurs par serveur.

Inconvénients :

• Architecture : Les conteneurs partagent le même Kernel de l’OS du serveur, ce qui signifie qu’ils sont limités à leur l’architecture.

Qu’apporte Docker de nouveau ?

Il est important de rappeler que les « conteneurs » en tant que volonté d’isoler un processus ne sont pas un concept nouveau mais Docker a introduit deux choses novatrices : standardiser les conteneurs et créer une communauté open-source autour.

C’est ce qui rend cette plate-forme si intéressante: vous obtenez bien plus qu’un simple accès à un ensemble d’outils de hautes qualités, vous avez accès à une communauté et tout un écosystème de produits et services qui vous aident dès les premières étapes du développement de votre application jusqu’à la production.

D’abord une simple API et un moteur, Docker propose maintenant les outils suivants :

• Docker Engine (Docker Daemon)
• Docker Hub (Registry)
• Docker Machine (Host provisioning)
• Docker Swarm (Host clustering)
• Docker Compose (Container Orchestration)
• Kitematic (GUI)

Docker et son écosystème

Dans la mouvance Docker, il est apparu un certain nombre de projets open-source, dont certains se structurant en entreprise commerciale, le principale est CoreOS, une distribution initialement dédiée à fournir de plate-forme pour Docker et qui aujourd’hui a créé ses propres projets et solution de conteneur et d’orchestration.

Avant que Docker soit officiellement estampillé prêt pour la production, un grand nombre de personne ont commencé à l’utiliser pour des tests unitaires, en effet le fait de pouvoir lancer un nouvel environnement vierge d’une application en quelques millisecondes va permettre de pouvoir lancer très rapidement toute une batterie de tests depuis le point de départ du parcours de test. Beaucoup de solutions SAAS (Circle CI, Shippable, Drone, Codeship) ou de projet open-source (modules Jenkins) proposant des fonctionnalités de CI/CD proposent aujourd’hui une intégration de Docker.

Bien qu’un cycle Docker allant du développement, aux tests puis à la production apporte beaucoup de simplification, cela a soulevé aussi de nouvelles problématiques dans le monde de la production pour les administrateurs systèmes. Comment orchestre-t-on les conteneurs ? comment les fait-on communiquer ? Comment gérer les maj de sécurité, les logs, les backups ? Comment gérer les données stateful ? Pour ces questions, un certain nombre de projets majeurs a vu le jour aussi comme Weave ou Flannel pour le réseau, Flocker pour les données persistantes, Docker Swarm ou Kubernetes de Google pour l’orchestration.

Les concepts mis en jeu par ces outils d’orchestration, encore loin d’être mature, permettent de mettre en pratique le concept d’infrastructure « immutable », qui consiste lors de la moindre montée de version d’application, de détruire tous les services/conteneurs/serveurs en place et de les remplacer petit à petit par des conteneurs avec la dernière version.

Yves-Marie S.