Virtualisation: la résurgence des conteneurs

Une des présentations qui a frappé les esprits lors de la conférence GlueCon 2014, qui se tenait les 21 et 22 mai 2014 à Bloomfield, Colorado, était celle de Joe Beda, un développeur senior de Google: « Containers at Scale« .

Il y expliquait que Google utilisait les conteneurs Linux sur tous ses serveurs en interne, et qu’elle démarrait 2 milliards de conteneurs par semaine. Ce qui semble vraiment beaucoup, avec 3307 conteneurs par seconde.

Les conteneurs ne sont pas nouveaux. Mais ils intéressent à nouveau un public plus large à l’ère du cloud, où les entreprises cherchent à maximiser l’efficacité de leurs serveurs.

 

Machines virtuelles

Le modèle dominant utilisé sur le cloud est la virtualisation matérielle. L’hyperviseur contrôle et présente le matériel à des machines virtuelles (VMs) qui peuvent héberger des systèmes d’exploitation différents, et qui ont l’impression de contrôler la machine.

Parmi les avantages, on notera la flexibilité, la sécurité, la fiabilité (si une machine virtuelle bloque, elle n’empêche pas les autres de tourner) et la simplicité, puisqu’il est possible de créer une machine virtuelle à partir de serveurs existant sans difficulté spéciale.

N’oublions pas l’optimisation de l’utilisation des serveurs physiques, notamment de la puissance de calcul, généralement sous-utilisée sur un serveur classique, et l’agrément pour les nombreuses applications serveurs, qui ne fonctionnent bien que quand elles ont un serveur qui leur est exclusivement dédié.

Parmi les désavantages, on notera le coût en ressources (notamment en mémoire), puisque chaque VM reçoit une copie entière du système d’exploitation. Et éventuellement un coût en licences.

 

 

Conteneurs

Les conteneurs sont un autre compromis avec une granularité moins fine.

La technique n’est pas nouvelle, elle a été d’abord développée sur BSD (BSD Jails) et Solaris, en 2005 (Solaris Zones puis Solaris Containers), dont se sont largement inspirés AIX, en 2007  (WPAR, workload partitioning) et plus tard Linux avec les Linux Containeurs (LxC).

Un seul système d’exploitation isole les applications dans des conteneurs séparés, et leur partage un certain nombre de facilités. Le conteneur apporte une virtualisation de l’environnement d’exécution (Processeur, mémoire, réseau, système de fichiers, …) et non pas de la machine. Tous ces processus tournent dans la même instance de noyau qui les voit comme des groupes de processus. On parle de virtualisation légère ou de virtualisation au niveau du système d’exploitation.

Il y a donc toute une gamme de possibilités de partitionnement, du chroot aux conteneurs aux machines virtuelles.

Avec les VMs, on peut changer et relancer chaque machine virtuelle indépendamment. À l’inverse, comme les conteneurs se partagent le même noyau, il faut fermer tous les conteneurs avant de modifier et de redémarrer le noyau.

L’avantage des conteneurs est leur coût limité en ressources (de l’ordre de 40 MB de mémoire vive), qui permet d’en faire tourner des centaines, alors que les machines virtuelles tournent plus par dizaines. Leur lancement est beaucoup plus rapide, de l’ordre de quelques secondes, puisqu’il n’est pas nécessaire de relancer tout un système d’exploitation, comme c’est le cas pour une machine virtuelle relancée en quelques dizaines de secondes, voir de quelques minutes.

Les inconvénients sont aussi nombreux. C’est une technologie pas encore mature sur Linux. Par exemple, la limitation de mémoire vive d’un conteneur n’est pas visible de ce dernier qui ne peut agir en conséquence, il n’est pas possible de migrer à chaud sans interruption de service. Certaines fonctionnalités sont incompatibles (autofs). La liste des processus est commune à tous les conteneurs, ce qui peut confondre certaines applications, et il n’y a qu’une table de routage pour tous les conteneurs.

Les conteneurs sont largement dépendants de leur système d’exploitation : un conteneur Linux ne tournera pas sur Solaris. Il n’y a pas d’API unique, même si Docker est devenu le standard de fait pour l’automatisation des conteneurs Linux.

Enfin, la sécurité est plus faible que dans une machine virtuelle. Un processus qui réussit à sortir de son conteneur peut modifier le noyau et prendre le contrôle de tous les autres conteneurs.

 

Les conteneurs sur Google Compute Engine

Depuis quelques jours, il est possible d’utiliser des conteneurs en aperçu sur Google Compute  Engine (pas de SLA, pas de garantie sur des changements futurs incompatibles). Google a développé sa propre variante de LXC, appelée lmctfy (Let Me Contain That For You), la version open source des conteneurs utilisés en interne par Google.

ContainerInGCE

La machine virtuelle optimisée pour les conteneurs est préinstallée avec Docker et Node Container Manager.
Elle démarre avec les conteneurs énoncés dans le manifeste manifest.yaml.
Pour l’instant, il n’y a pas d’intégration avec l’UI et pas de

Conclusion

La virtualisation légère par conteneurs est idéale pour certains types de processus (on pense notamment à certains traitements Big Data) et certaines entreprises. Elle ne remplacera pourtant pas les machines virtuelles,  mieux adaptées en termes de sécurité, de facilité d’administration, de flexibilité et de compatibilité, à de nombreuses applications.