Oui, les conteneurs peuvent permettre à votre entreprise d'emballer beaucoup plus d'applications dans un seul serveur physique qu'une machine virtuelle (VM). Les technologies de conteneurs, comme Docker, surpassent les machines virtuelles dans le cloud ou le datacenter. Oui, les machines virtuelles consomment beaucoup de ressources système. Une VM n’exécute pas seulement une copie complète d'un système d'exploitation, mais elle exécute une copie virtuelle de tout le hardware dont le système d'exploitation a besoin pour fonctionner. Ce mode opératoire augmente rapidement et de manière conséquente le nombre de cycles de RAM et de CPU. Comparativement, tout ce dont un conteneur a besoin, c’est d'un système d'exploitation, des programmes et bibliothèques compatibles, et les ressources système qui permettent de faire tourner un programme spécifique.

Cela signifie en pratique qu’avec des conteneurs, on peut charger deux à trois fois plus d’applications sur un serveur que l’on peut en mettre dans une machine virtuelle. En outre, avec des conteneurs, il est possible de créer un environnement qui peut servir pour le développement, les tests et le déploiement. C’est, comme diraient certains, le tiercé gagnant. Mais, si tous les avantages revenaient exclusivement aux conteneurs, nous pourrions annoncer dès maintenant la mort des machines virtuelles. Certes, il est possible de mettre un grand nombre d’applications dans les conteneurs, mais les VM présentent d’autres avantages, et pas des moindres. 

La sécurité, problème n° 1 des conteneurs

Le problème majeur, souvent négligé dans l’engouement qui prévaut aujourd’hui pour les conteneurs, est celui de la sécurité. Comme l’explique Daniel Walsh, un ingénieur en sécurité de Red Hat qui travaille principalement sur Docker et sur les conteneurs, « les conteneurs ne contiennent rien ». Si l’on prend Docker, par exemple, qui utilise libcontainers comme technologie de conteneur : pour travailler avec Linux, libcontainers accède à cinq espaces de noms - Process, Network, Mount, Hostname et Shared Memory. C'est très bien en soi, mais un grand nombre de sous-systèmes du noyau Linux se trouvent en dehors du conteneur. C’est le cas de tous les appareils, de SELinux, de Cgroups et de tous les systèmes de fichiers sous/sys. Cela signifie que si un utilisateur ou si une application possède des privilèges de super utilisateur dans le conteneur, le système d'exploitation sous-jacent pourrait, en théorie, être compromis. Et ce n’est pas très rassurant. 

Certes, il existe beaucoup de manières de sécuriser Docker et d'autres technologies de conteneurs comme CoreOS. Par exemple, il est possible de monter un système de fichiers /sys en lecture seule, de forcer le conteneur à écrire uniquement sur des systèmes de fichiers de conteneurs spécifiques, et de créer un espace de noms réseau qui ne se connecte uniquement avec un intranet privé spécifique, et ainsi de suite. Mais, rien de tout cela n’est disponible par défaut. Il faut investir beaucoup de temps pour sécuriser les conteneurs. La règle de base, c’est de traiter les conteneurs exactement comme n’importe quelle application serveur. Autrement dit, comme Daniel Walsh le préconise : « 1 - il faut mettre fin aux privilèges aussi vite que possible ; 2 - chaque fois que c’est possible, il ne faut pas faire tourner ses services en mode root ; 3 - Il faut gérer la racine dans un conteneur comme si cette racine était à l'extérieur du conteneur ».

Attention aux applications déjà conteneurisées 

Un autre problème de sécurité se pose quand les utilisateurs, de plus en plus nombreux, livrent des applications conteneurisées. Or, certaines de ces applications sont pires que d'autres. Si, par exemple, vous ou votre personnel avez tendance à être, dirions-nous, un peu paresseux, et si vous installez le premier conteneur qui vous passe entre les mains, vous aller peut-être faire entrer un cheval de Troie dans votre serveur. Vous devez expliquer à vos collègues qu'ils ne peuvent pas télécharger des applications à partir d'Internet comme ils téléchargent des jeux pour leur smartphone. Au passage, rappelez-leur aussi qu’ils ne doivent pas non plus télécharger de jeux, mais c'est un autre problème de sécurité ! 

Autres inquiétudes sur les conteneurs

Bon, alors, si nous pouvons régler le problème de la sécurité, les conteneurs pourront tout gérer, n’est-ce pas ? Pas du tout. Il y a d'autres aspects dont il faut tenir compte à propos des conteneurs. Rob Hirschfeld, CEO de RackN et membre du conseil d’administration de la Fondation OpenStack, fait remarquer que « l'emballage est toujours délicat. Créer une boîte fermée à clé permet de résoudre une partie du problème en aval (vous savez ce que vous avez), mais pas le problème en amont (vous ne savez pas de quoi vous dépendez) ».

Les objectifs

Il faut ajouter que, même si nous sommes confrontés ici à un problème de sécurité, il y a aussi un problème d'assurance qualité. Bien sûr, le conteneur X peut exécuter le serveur web Nginx, mais est-ce la version que l’on souhaite ? Est-ce qu’elle inclut la mise à jour TCP Load Balancing ? Il est facile de déployer une application dans un conteneur, mais si vous installez la mauvaise application, vous perdez encore plus de temps. Rob Hirschfeld fait également remarquer que l'étalement peut poser un réel problème. Selon lui, il faut comprendre que « le fractionnement des déploiements en parties discrètes plus fonctionnelles est certes une bonne chose, mais qu’au final, il y a plus d’éléments à gérer. Il y a un point d'inflexion entre le fractionnement des problèmes et leur étalement ».

Il ne faut pas oublier que le rôle essentiel d’un conteneur est de faire tourner une application. Plus on ajoute de fonctionnalités dans le conteneur, plus l’option de la machine virtuelle devrait s’imposer en premier lieu. Certes, certaines technologies de conteneurs, comme les conteneurs Linux (LXC), peuvent être utilisées en lieu et place d'une VM. Par exemple, il est possible d’utiliser LXC pour exécuter des applications Red Hat Enterprise Linux (RHEL) 6 spécifiques sur une instance RHEL 7. D'une manière générale il est préférable d’utiliser des conteneurs pour exécuter une seule application et des machines virtuelles pour exécuter plusieurs applications.

Alors, conteneurs ou machines virtuelles ?

Au final, comment choisir entre les machines virtuelles et les conteneurs ? Scott S. Lowe, un architecte en ingénierie de VMware, suggère de considérer la « portée » du travail. En d'autres termes, si l’on veut exécuter plusieurs copies d'une seule application, par exemple MySQL, il est préférable, selon lui, d’utiliser un conteneur. Mais si l’on veut avoir la possibilité d’exécuter plusieurs applications, il est préférable de choisir une machine virtuelle. En outre, les conteneurs ont tendance à enfermer l’utilisateur dans une version particulière du système d'exploitation. C’est parfois une bonne chose : inutile de se préoccuper des dépendances quand l'application fonctionne correctement dans un conteneur. Mais c’est aussi un facteur limitant. Avec les machines virtuelles, quel que soit l'hyperviseur utilisé - KVM, Hyper-V, vSphere, Xen - il est possible de faire tourner à peu près n’importe quel système d'exploitation. Et si vous avez besoin d'exécuter une application obscure qui ne fonctionne que sur QNX ? C'est facile avec une machine virtuelle. Mais ce n’est pas simple avec la génération actuelle de conteneurs.

En conclusion, et pour dire les choses clairement…

Si vous avez besoin de faire tourner un maximum d’applications particulières sur un minimum de serveurs, alors il faut utiliser des conteneurs - en gardant à l'esprit que vous devrez garder un œil sur les systèmes qui font tourner des conteneurs tant que leur sécurité n’est pas verrouillée. Si vous avez besoin d'exécuter plusieurs applications sur des serveurs et/ou d’avoir une grande variété de systèmes d'exploitation, mieux vaut vous orienter vers les machines virtuelles. Et si la sécurité est la priorité numéro un de votre entreprise, alors il faut aussi préférer pour l’instant les machines virtuelles.

Dans le monde réel, il est probable que vous utiliserez à la fois des conteneurs et des machines virtuelles dans le cloud et dans vos centres de données. L'économie d’échelle que procurent les conteneurs ne peut être ignorée. Dans le même temps, les machines virtuelles conservent toujours leurs avantages. Alors que la technologie de conteneurs arrive à maturité, « l’association VM/conteneurs constituera le nirvana de la portabilité cloud » comme le dit Thorsten von Eicken, CTO de RightScale, une entreprise spécialisée dans la gestion des plateformes cloud. Nous n’en sommes pas encore là, mais c’est vers cela que nous nous dirigeons.