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

Après avoir lu les documents, je me suis retrouvé 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 l' -vargument pour docker run)
2. Créer une image de conteneur Docker pour les données (c.-à-d. Conteneur séparé et --volumes-from)
3. Créer un volume docker (ie 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.

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

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

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 à la place ce que vous feriez avec # 2 -v.

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 testvolume 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 la docker volumesous-commande.

$ d volume ls
DRIVER              VOLUME NAME
local               test

Il ouvre également les 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 les 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.

Depuis Docker 1.9, la création de volumes nommés avec l' API Volumes ( docker volume create --name mydata) est préférable à un conteneur de volume de données. En février 2016, la documentation des volumes Docker 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 être en mesure de remplacer les volumes de données uniquement dans la plupart (sinon tous) les cas » et « aucune raison que je vois d'utiliser conteneurs de données uniquement . "