Docker: quelles sont les options pour le stockage persistant

DOCKER VOLUME

Un volume Docker fournit un mécanisme pour assurer la persistance des données d’un conteneur ou lui permettre « d’échanger » des données avec d’autres conteneurs partageant le même volume.

Un volume Docker est initialisé lors de la création d’un conteneur et est monté dans le conteneur comme un système de fichiers. Si l’image du conteneur contient déjà des données dans le répertoire dans lequel est monté le système de fichiers, ces données sont copiées dans le nouveau volume lors de son initialisation. Les volumes de données ont l’avantage particulier de survivre à l’arrêt du conteneur et par défaut, Docker n’efface pas les volumes, même lors de la destruction d’un conteneur associé. En fait, il est même impossible d’effacer un volume tant que ce dernier est référencé par un conteneur.

Il est possible de créer un volume avec la commande Docker volume create

Il est aussi possible de créer ou d’attacher un volume à un conteneur via les commandes docker create et docker run command. Il est à noter que, par défaut, un volume est monté en mode lecture-écriture, mais qu’il est possible de limiter l’accès au seul mode lecture. La commande ci-dessous crée par exemple un conteneur nommé web depuis l’image training/webapp avec un volume baptisé /webapp stocké sur l’hôte local.

$ docker run -d -P --name web -v /webapp training/webapp python app.py

Plusieurs options sont disponibles aujourd’hui pour stocker un volume :

La première consiste à monter un répertoire du système d’exploitation hôte comme un data volume. Cette option est simple d’utilisation, mais elle est à utiliser avec une grande précaution en production puisqu’une défaillance du système hôte se traduit par l’indisponibilité du volume. Le fait de monter un répertoire local est toutefois pratique pour les développeurs, que ce soit pendant la phase de développement ou pendant la phase de test. Il est à noter qu’il est aussi possible de monter un fichier unique comme un volume. 

La commande ci-dessous crée par exemple un conteneur baptisé web à partir de l’image training/webapp et monte le contenu du répertoire /src/webapp de l’hôte dans le répertoire /webapp du conteneur.

$ docker run -d -P --name web -v /src/webapp:/webapp training/webapp python app.py

 La seconde possibilité est de monter un volume de stockage partagé (iSCSI, FC ou NFS) comme data volume. Docker inclut un concept de plug-ins qui permet aux principaux fabricants de baies de stockage d’intégrer leurs systèmes de stockage avec la technologie de conteneurs. Le bénéfice évident de cette approche est que le volume n’est plus lié à un hôte, mais accessible à tous les hôtes d’un cluster (pour peu que ces hôtes aient accès à la baie de stockage et que le plug-in de stockage adapté soit déployé).

La commande ci-dessous crée un conteneur baptisé web depuis l’image training/webapp et crée également un volume attaché baptisé mon volume en utilisant le pilote convoy (qui supporte notamment l’accès en mode NFS et l’accès aux volumes EBS d’Amazon) :

$ docker run -d -P \

--volume-driver=convoy \

-v mon-volume :/webapp \

--name web training/webapp python app.py

DATA VOLUME CONTAINER

Docker propose également un mécanisme pour permettre de partager des données persistantes entre conteneurs. Baptisée Data Volume Container, ce mécanisme consiste à créer un conteneur nommé puis à lui attacher des volumes. Il sera ensuite possible de consommer ces volumes depuis d’autres conteneurs. Docker donne pour exemple le cas suivant, qui crée un conteneur baptisé dbstore à partir de l’image training/postgres.

$ docker create -v /dbdata --name dbstore training/postgres /bin/true

 En utilisant le paramètre --volumes-from avec Docker run, il devient possible de monter le volume /dbdata du conteneur dbstore dans d’autres conteneurs. C’est ce que réalisent les deux commandes suivantes en créant deux conteneurs baptisés db1 et db2 :

$ docker run -d --volumes-from dbstore --name db1 training/postgres

$ docker run -d --volumes-from dbstore --name db2 training/postgres

Dans le cas présent, le contenu du volume /dbdata remplace celui éventuellement présent dans l’image training/postgres. Cela permet aux conteneurs db1 et db2 de démarrer avec une base de données de référence identique.

Il est à noter que la suppression des conteneurs montant les volumes n’entraîne pas la suppression du volume lui-même. Pour éviter de se retrouver avec des volumes orphelins, il faut donc explicitement utiliser la commande docker rm –v sur le dernier conteneur référençant le volume. Docker indique qu’il est possible d’inventorier les volumes orphelins avec la commande docker volume ls -f dangling=true puis d’utiliser ensuite docker volume rm <nom_du_volume > pour supprimer les volumes indésirables.

Il est à noter qu’outre les problèmes de volumes orphelins, l’utilisation des data containers pose d’autres problèmes potentiels. Par exemple, Docker n’offre pas de mécanisme de sécurité additionnel pour assurer la sécurité des volumes. Il faut donc veiller à ce que les permissions pour les utilisateurs dans les conteneurs correspondent à celles du serveur hôte. Docker n’implémente pas non plus de mécanisme additionnel de verrouillage. Lorsque plusieurs conteneurs accèdent au même volume sur un hôte, les verrous sur les fichiers doivent être gérés par les applications tournant dans les conteneurs, sous peine d’éventuels risques de corruption. Ces problèmes n’existent pas sur un stockage partagé en réseau.