Docker et le stockage, où en est-on ? (partie 3)

Docker et le stockage, où en est-on ? (partie 3)

Jusqu’ici tout allait bien, car les containers Docker ne posaient pas réellement de nouvelles problématiques de stockage.

A l’origine, Docker a été pensé pour pouvoir déployer massivement des micro-services. Ces derniers ont la particularité d’être stateless (sans état) et ne nécessitent donc pas de persistance de données : par défaut, à l’arrêt d’un container, les données sont effacées. C’était assez simple à gérer.

C’était sans compter sur son succès dans les infras. Les containers ont rapidement été utilisés pour déployer des applications de plus en plus complexes. Et ce qui devait arriver arriva : les containers ont finalement eu besoin de stockage persistant.

Où en est-on ?

Des premières idées ont donc été mises en place par Docker, comme l’utilisation des fonctions de volume. Cela permet d’avoir des données modifiables au sein des images docker. Ce mécanisme assure ainsi la persistance de données du container et lui permet d’échanger avec d’autres conteneurs partageant le même volume. Avantage : Docker n’efface pas les volumes, même si un container associé est détruit. Docker propose également un mécanisme pour permettre de partager des données persistantes entre conteneurs, en lui attachant des volumes.

Cette approche implique tout de même beaucoup de contraintes, que l’on a découvert au fur et à mesure des usages.

  • Les données qu’on peut adresser/modifier ont été dans, un premier temps, non routables. Elles étaient sur un réseau LAN ou réseau local. Dès que l’on est confronté à une dispersion géographique, cela se complique.
  • Les volumes doivent être montés sur des hôte docker : il faut mapper chaque serveur docker avec du stockage qui peut être vu par les containers, ce qui ne facilite pas la tâche.
  • Ces technologies ne gèrent pas les log. Lorsqu’une image docker veut accéder à une volumétrie et faire des modifications et qu’une autre image docker veut accéder à la même volumétrie, Docker ne sait pas gérer la concurrence d’accès. Lorsque plusieurs conteneurs accèdent au même volume sur un hôte, c’est à l’application tournant dans le conteneur de gérer cela, pour éviter les risques de corruption.
  • Docker n’offre pas de mécanisme de sécurité additionnel pour sécuriser les volumes. Il faut s’assurer que les permissions pour les utilisateurs dans les conteneurs correspondent à celles du serveur hôte.

 

L’orchestration, une solution de choix

Pour solutionner ces problématiques, Docker et sa communauté continuent d’évoluer. Désormais, un certain nombre d’acteurs du stockage intègrent de nouvelles fonctionnalités dans leurs baies pour rendre le stockage persistant plus adroit qu’avant. Des plug-ins ont été conçus dans ce but, qui permettent de monter un volume de stockage partagé, de type iSCSI, FC ou NFS comme un data volume. Ainsi le volume n’est plus lié à un hôte Docker.

Enfin l’idée actuelle est de mettre en place un orchestrateur au-dessus de Docker, comme Kubernetes ou Mesos qui permettent d’attaquer des couches d’API de plus haut niveau. Cette couche apporte de vraies fonctions de stockage persistant efficaces que ce soit sur du SAN, du fichier ou de l’objet. A terme, les acteurs du marché travaillent sur une standardisation pour assurer un service de qualité de stockage de données persistantes.

About The Author

Sebastien Hurst

Responsable Département Avant-Vente

Recevez par mail les articles et actualités de Au coeur des InfrasJe m'inscris à la Newsletter