Stockage traditionnel vs Conteneurs : la bataille s'annonce à l'heure du DevOps

Les avantages des conteneurs sont multiples, à commencer par leur simplicité de provisioning et de déploiement, leur efficacité, sans oublier les possibilités avancées d’orchestration offertes par les grands frameworks du marché comme Docker Swarm, Kubernetes ou Mesos Marathon.

Les avantages des conteneurs proviennent pour l’essentiel du fait qu’ils fournissent un mécanisme d’isolation bien plus léger que la virtualisation. Ainsi les conteneurs déployés sur un serveur partagent le noyau de l’OS hôte et les services qu’il offre. Ce qui fait que leur empreinte mémoire et stockage et bien plus réduite que celle de VM qui arrivent chacune avec son propre système d’exploitation.

Mais cette légèreté a ses contreparties. Par exemple, en matière de sécurité, tous les conteneurs d’un même serveur partagent le même sous-système réseau, ce qui n’est pas idéal. Mais l’un des principaux problèmes émergent est celui de la persistance des données, les conteneurs ayant à l’origine été conçus pour héberger des applications sans état.

Cette question de la persistance des données dans les conteneurs n’a commencé à être traitée qu’il y a deux ans ou trois ans, avec la montée en puissance de leur usage pour héberger des applications comme des bases de données (SQL ou NoSQL) ou des services ayant besoin de « mémoire » (Moteur de recherche, etc..).

Dans un premier temps, des mécanismes ont été ajoutés pour assurer la persistance locale des données sur l’hôte. Puis, peu à peu, des architectures ont émergé pour gérer aussi bien la mobilité des conteneurs que celles des volumes de données qui leur sont associés, que ces données soient locales ou hébergée sur des baies de stockage.

L’objectif est bien sûr de pouvoir conserver les caractéristiques de mobilité qui font la force des conteneurs, tout en s’assurant que, si besoin, les données associées à ces conteneurs resteront accessibles en cas de mouvement de ces derniers.

Cette bataille pour la persistance est encore loin d’être achevée. Certains constructeurs comme Dell EMC ou IBM ont choisi de s’y attaquer avec leurs propres projets open source afin de fournir un framework complet entre leurs baies de stockage et les architectures de conteneurs.

D’autres constructeurs ont décidé de s’appuyer sur Flocker, une technologie open source de persistance de données, créée par ClusterHQ et qui a récemment fait l’actualité du fait du dépôt de bilan son fondateur. D’autres, enfin, ont préféré travailler avec Docker en développant des plug-ins pour leurs baies de stockage, en misant sur l’enrichissement progressif des services d’orchestration de données offerts par Docker.

Aucune de ces approches n’a pour l’instant pris l’ascendant sur les autres. On voit même émerger des approches nouvelles comme celles de MapR avec PACC pour la fourniture d’une plate-forme complète de données optimisée pour Docker basée sur son Filesystem.

Docker lui-même, d’ailleurs, n’est pas en reste et travaille à sa propre architecture de stockage open source depuis le rachat du français Infinit en 2016. Si ses projets se concrétisent, il pourrait à terme devenir un concurrent redoutable pour les fournisseurs de stockage traditionnels.