web-dev-qa-db-fra.com

Comment choisir entre un conteneur de volume Docker et un volume Docker?

Après avoir lu les documents, je me suis senti quelque peu confus quant à la meilleure façon de gérer les données productives des applications/services.

Il semble y avoir 3 options:

  1. Mappez simplement le volume au répertoire hôte (c'est-à-dire -v argument pour docker run)
  2. Créez une image de conteneur Docker pour les données (c'est-à-dire un conteneur séparé et --volumes-from)
  3. Création d'un volume docker (c'est-à-dire docker volume create)

Maintenant, il semble que la pratique acceptée soit l'option n ° 2, mais je me demande alors quel est le but de la n ° 3.

En particulier, comment gérez-vous correctement ces scénarios avec docker volume et est-il préférable d'utiliser un conteneur de volume de données ou cela pour chaque situation?

  • Vous avez besoin des données d'application dans un volume et/ou un niveau de stockage distinct sur votre serveur
  • Sauvegarde
  • Restauration des données
storagedocker
24
dukeofgaming

Je pense que # 2 et # 3 sont à peu près la même chose, la principale différence est qu'il n'y a pas de conteneur arrêté avec # 3 (c'est littéralement, juste un volume nommé). Par exemple, vous pouvez créer un volume nommé et faire de même ce que vous feriez avec # 2 avec -v au lieu.

Créez un volume nommé:

$ docker volume create --name test

Montez et écrivez des données sur ce volume à partir d'un conteneur:

$ docker run -v test:/opt/test Alpine touch /opt/test/hello

Vous pouvez ensuite monter ce même volume test dans un autre conteneur et lire les données:

$ docker run -v test:/opt/test Alpine ls -al /opt/test     
total 8
drwxr-xr-x    2 root     root          4096 Jan 23 22:28 .
drwxr-xr-x    3 root     root          4096 Jan 23 22:29 ..
-rw-r--r--    1 root     root             0 Jan 23 22:28 hello

L'avantage ici est que le volume ne disparaîtra pas accidentellement si vous supprimez le conteneur de données uniquement. Vous le gérez maintenant avec le docker volume sous-commande.

$ d volume ls
DRIVER              VOLUME NAME
local               test

Il ouvre également des possibilités pour les pilotes de volume sur la route afin que vous puissiez être en mesure de faire des volumes partagés entre les hôtes (c'est-à-dire des volumes nommés sur NFS). Des exemples de cela pourraient être Flocker et Convoy . En ce qui concerne spécifiquement le déplacement ou la sauvegarde des données, Convoy a des sous-commandes spécifiques pour la sauvegarde des données et permet le stockage sur NFS ou EBS externe à votre hôte.

Pour cette raison, je pense que la méthode la plus nouvelle (Docker 1.9+) consiste à utiliser un volume nommé plutôt qu'un conteneur de données uniquement.

18
Andy Shinn

Depuis Docker 1.9, création de volumes nommés avec API Volumes (docker volume create --name mydata) sont préférés à un conteneur de volume de données. En février 2016, le Docker documentation des volumes est malheureusement obsolète. Les gens de Docker eux-mêmes suggèrent que les conteneurs de volumes de données " ne sont plus considérés comme un modèle recommandé ," " les volumes nommés devraient pouvoir remplacer les volumes de données uniquement dans la plupart (sinon tous) les cas) , "et" aucune raison que je puisse voir pour utiliser des conteneurs de données uniquement . "

22
Quinn Comendant