Cinq inconvénients des conteneurs (et comment y remédier)

1. Incompatibilité avec certaines tâches

Thomas Bittman fait remarquer que les conteneurs, bien que polyvalents, sont loin de pouvoir remplacer tous les déploiements de machines virtuelles (VM) existants. En effet, tout comme d'anciennes applications se prêtaient mieux à des déploiements physiques aux premiers temps de la virtualisation, certaines applications ne conviennent pas du tout à une virtualisation en conteneurs.

Par exemple, les conteneurs sont la solution idéale pour le développement d'applications de type microservice. Cette approche permet de configurer des applications plus complexes à partir de composants élémentaires, chacun de ces composants étant déployé dans un conteneur et les conteneurs constitutifs étant reliés entre eux pour former l'application complète.

Pour faire évoluer les fonctionnalités de l'application, il suffit alors de déployer de nouveaux conteneurs renfermant les composants appropriés au lieu de créer entièrement de nouvelles itérations de l'application.

Cependant, certaines applications ne peuvent fonctionner que de façon monolithique. Ainsi conçues, elles sont difficilement compatibles avec des avantages tels que l'évolutivité ou le déploiement rapide. Dans ces cas-là, les conteneurs ne font que rigidifier encore la charge de travail.

La meilleure méthode consiste souvent à faire des essais pour voir quelles applications existantes peuvent bénéficier d'une conteneurisation. Les nouveaux modèles de développement d'applications en tireront sans doute parti. En revanche, les applications qui ne se prêtent pas à cette transformation pourront toujours s'exécuter comme des VM entièrement fonctionnelles adossées à un hyperviseur conventionnel.

Comme l'indique un architecte informatique d'une grande compagnie d'assurance, « Les conteneurs sont intéressants, mais notre équipe informatique aurait pas mal de retard à rattraper pour apprendre à s'en servir correctement. »

2. Problème des dépendances

Les VM classiques sont extrêmement autonomes, chacune comprenant un système d'exploitation (OS) unique, des pilotes et des composants d'application. Elles peuvent également migrer vers n'importe quel autre système du moment qu'un hyperviseur approprié est disponible.

De leur côté, les conteneurs s'exécutent sur un OS et partagent la majeure partie du noyau sous-jacent ainsi qu'un grand nombre de fichiers binaires et de bibliothèques. D'après Bittman, les dépendances imposées aux conteneurs peuvent limiter la portabilité entre serveurs.

Par exemple, les conteneurs Linux sous Docker ne peuvent pas être exécutés sur les versions actuelles de Windows Server.

La réponse est plus un constat qu'une véritable solution : les conteneurs peuvent être créés et multipliés en quelques secondes, tandis que les systèmes d'exploitation évoluent pour créer des variantes « micro » ou « nano » capables d'offrir une formidable stabilité et des redémarrages extrêmement rapides.

Au niveau natif, les conteneurs sont plus disponibles dans ces environnements et il est toujours possible de les déplacer ou d'en supprimer tant que d'autres serveurs sont disponibles dans le datacenter.

Ces dépendances s'allègent au fur et à mesure que de nouveaux OS apparaissent. Ainsi, Windows Server 2016 prévoit la prise en charge de Docker et des conteneurs Hyper-V natifs. Par ailleurs, outre Docker, de nombreuses plateformes de conteneurs sont disponibles : LXC, Parallels Virtuozzo, Joyent, Canonical LXD, Spoon et d'autres encore. Même VMware entre dans la course.

3. Faiblesse relative de l'isolement

Les VM reposant sur un hyperviseur offrent un degré élevé d'isolement les unes des autres, car les ressources matérielles du système sont toutes virtualisées et présentées aux VM par le biais de l'hyperviseur.

Autrement dit, une bogue, un virus ou une intrusion peut porter atteinte à une VM sans se propager aux autres.

Les conteneurs, eux, sont plus vulnérables, car ils partagent un noyau et des composants systèmes et leur fonctionnement exige déjà un niveau d'autorisation élevé (généralement l'accès root dans les environnements Linux).

En conséquence, les erreurs et attaques ont bien plus de chances de se répercuter sur un OS sous-jacent et sur d'autres conteneurs, risquant ainsi de propager des activités malveillantes bien au-delà de l'événement d'origine.

Certes, les plateformes de conteneurs évoluent dans le sens d'une séparation des droits des OS et d'une restriction des comportements contraires à la sécurité. Mais, comme l'explique Thomas Bittman, les administrateurs peuvent d'ores et déjà renforcer la sécurité en exécutant les conteneurs dans une VM. Par exemple, il est possible de configurer une VM Linux sur Hyper-V et d'y installer des conteneurs Docker.

Dans cette configuration, même en cas d'atteinte aux conteneurs, la faille ne s'étendra pas en dehors de la VM, limitant ainsi la portée des dégâts potentiels.

4. Risque de prolifération

Si la gestion du cycle de vie des VM est importante dans les environnements basés sur un hyperviseur, elle s'avère absolument essentielle pour les conteneurs. En effet, ces derniers offrent l'avantage non négligeable de pouvoir être mis en service et dupliqués à la vitesse de l'éclair.

Le revers de la médaille est qu'il est également possible de consommer une grande quantité de ressources informatiques sans vraiment s'en rendre compte.

Ce n'est pas très grave si les conteneurs qui composent l'application sont arrêtés ou supprimés dès lors qu'ils ne sont plus nécessaires. Mais en cas d'oubli, la montée en charge d'une application conteneurisée peut se traduire par des coûts de Cloud Computing tout aussi importants qu'inutiles pour l'entreprise.

Evidemment, comme le souligne Bittman, les fournisseurs de Cloud se frottent les mains (puisqu'ils font leur beurre en louant de la puissance de traitement). C'est donc aux utilisateurs qu'il revient de surveiller le déploiement des conteneurs.

5. Outils de gestion limités

Les types d'outils nécessaires pour surveiller et gérer les conteneurs sont encore rares dans le secteur. Le phénomène n'est pas nouveau : déjà, aux premiers temps de la virtualisation sur hyperviseur, on manquait d'outils adaptés.

Et maintenant qu'il en existe pour la surveillance et la gestion des VM, de nouveaux outils commencent à apparaître pour les conteneurs. On peut citer Kubernetes, outils de gestion Docker open source de Google, DockerUI qui remplace les fonctions de ligne de commande Linux par une interface Web, Logspout qui achemine les logs des conteneurs vers un emplacement centralisé, etc.

Thomas Bittman suggère aux administrateurs de pallier la pénurie d'outils en utilisant des conteneurs dans des VM afin de tirer parti des outils de VM pour assurer certaines fonctions de surveillance et de gestion.

En effet, puisque les outils de VM sont plus nombreux et plus avancés, ils peuvent servir de substituts en attendant que les outils dédiés aux conteneurs arrivent à maturité.

Pour finir, Bittman ne tarit pas d'éloges sur les conteneurs, mettant l'accent sur leur capacité de déploiement rapide et léger dans des environnements haute densité et évolutifs, sur les E/S natives (non virtualisées) pour de meilleures performances, sur les infrastructures de développement prêtes à l'emploi comme Docker et sur les outils renommés de partage et de collaboration tels que GitHub et autres.

Cependant, les conteneurs ne constituent pas la panacée pour toutes les tâches de virtualisation. Simple article dans la panoplie des outils de virtualisation, ils font souvent bon ménage avec les traditionnelles VM.