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:

Mappez simplement le volume au répertoire hôte (c'est-à-dire l' -vargument pour docker run)
Créer une image de conteneur Docker pour les données (c.-à-d. Conteneur séparé et --volumes-from)
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

storage docker

— dukeofgaming
source

serverfault.com/q/576490/126632

— Michael Hampton

@MichaelHampton J'ai réalisé que je devrais reformuler ma question

— dukeofgaming

# 1 n'est pas une option sérieuse pour la production; il ne devrait en principe jamais être fait s'il existe une alternative.

— Michael Hampton

@MichaelHampton Why?, Les données ne peuvent pas être dockées mais le système d'exploitation hôte est toujours géré par une équipe d'infrastructure qui surveille et sauvegarde

— dukeofgaming

@dukeofgaming Sans oublier que vous pouvez l'exécuter btrfs scrubpour trouver et corriger les fichiers endommagés. Je ne suis pas sûr de savoir comment les choses ancrées fonctionnent, mais je suppose que cela ne protège pas contre la pourriture des données, j'ai donc toujours besoin d'une restauration complète en cas de problème au lieu de simplement restaurer des fichiers individuels. Un autre a pensé qu'il ajoute une autre couche d'abstraction, ce qui ralentit encore plus la lecture et l'écriture des fichiers. Je ne vois pas en quelque sorte les avantages des n ° 2 et n ° 3, mais je ne suis pas expérimenté avec docker, donc cela pourrait changer.

— inf3rno

Réponses:

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.

— Andy Shinn
source

Merci, vous avez répondu à la plupart de mes questions, mais le point sur la gestion des données de conteneur dans un niveau de volume physique différent est toujours sans réponse et c'est le point critique ... supposons que c'est une solution de gestion de référentiel git et j'ai besoin de cette partie du conteneur données (qui est un volume défini dans un dockerfile) dans le stockage de niveau 0 situé dans un volume hôte physique différent (c'est-à-dire une autre partition, un disque physique ou autre)

— dukeofgaming

Je l'ai fait en quelque sorte avec la mention des pilotes de volume. À l'heure actuelle, pour stocker des données en dehors du pilote de stockage local physique, vous devez en utiliser un qui fait spécifiquement ce que vous cherchez à faire. Du haut de ma tête, il y a github.com/rancher/convoy et github.com/ClusterHQ/flocker . Convoy prend actuellement en charge NFS et GlusterFS, ce qui semble plus proche de ce que vous recherchez. Je vais modifier la réponse pour clarifier cela.

— Andy Shinn

L'utilisation du pilote devicemapper semble répondre à ma question, merci! docs.docker.com/engine/userguide/storagedriver/…

— dukeofgaming

the volume won't accidentally disappear if you remove the data-only container. Pourriez-vous élaborer? Merci.

— Stephane

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 . "

— Quinn Comendant
source