Le mode Swarm lui-même ne fait rien de différent avec les volumes, il exécute toute commande de montage de volume que vous fournissez sur le nœud sur lequel le conteneur est exécuté. Si votre montage de volume est local sur ce nœud, vos données seront enregistrées localement sur ce nœud. Il n'y a pas de fonctionnalité intégrée pour déplacer automatiquement les données entre les nœuds.
Il existe des solutions de stockage distribué basées sur des logiciels comme GlusterFS, et Docker en a une appelée Infinit qui n'est pas encore GA et le développement sur qui a pris un siège arrière à l'intégration de Kubernetes dans EE.
Le résultat typique est que vous devez soit gérer la réplication du stockage dans votre application (par exemple, etcd et d'autres algorithmes basés sur des radeaux), soit vous effectuez vos montages sur un système de stockage externe (avec un peu de chance avec son propre HA). Le montage d'un système de stockage externe comporte deux options, basées sur des blocs ou des fichiers. Le stockage basé sur des blocs (par exemple EBS) offre généralement des performances plus élevées, mais il est limité à être monté sur un seul nœud. Pour cela, vous aurez généralement besoin d'un pilote de plug-in de volume tiers pour donner à votre nœud docker l'accès à ce stockage de bloc. Le stockage basé sur des fichiers (par exemple, EFS) a des performances inférieures, mais est plus portable et peut être monté simultanément sur plusieurs nœuds, ce qui est utile pour un service répliqué.
Le stockage réseau basé sur des fichiers le plus courant est NFS (il s'agit du même protocole utilisé par EFS). Et vous pouvez monter cela sans aucun pilote de plugin tiers. Le pilote de plug-in de volume "local" malheureusement nommé qui est livré avec docker vous donne la possibilité de passer toutes les valeurs que vous voulez à la commande de montage avec les options du pilote, et sans option, il stocke par défaut les volumes dans le répertoire docker / var / lib / docker / volumes. Avec les options, vous pouvez lui transmettre les paramètres NFS, et il effectuera même une recherche DNS sur le nom d'hôte NFS (ce que vous n'avez normalement pas avec NFS). Voici un exemple des différentes manières de monter un système de fichiers NFS à l'aide du pilote de volume local:
# create a reusable volume
$ docker volume create --driver local \
--opt type=nfs \
--opt o=nfsvers=4,addr=192.168.1.1,rw \
--opt device=:/path/to/dir \
foo
# or from the docker run command
$ docker run -it --rm \
--mount type=volume,dst=/container/path,volume-driver=local,volume-opt=type=nfs,\"volume-opt=o=nfsvers=4,addr=192.168.1.1\",volume-opt=device=:/host/path \
foo
# or to create a service
$ docker service create \
--mount type=volume,dst=/container/path,volume-driver=local,volume-opt=type=nfs,\"volume-opt=o=nfsvers=4,addr=192.168.1.1\",volume-opt=device=:/host/path \
foo
# inside a docker-compose file
...
volumes:
nfs-data:
driver: local
driver_opts:
type: nfs
o: nfsvers=4,addr=192.168.1.1,rw
device: ":/path/to/dir"
...
Si vous utilisez l'exemple de fichier de composition à la fin, notez que les modifications apportées à un volume (par exemple, la mise à jour du chemin ou de l'adresse du serveur) ne sont pas reflétées dans les volumes nommés existants tant qu'ils existent. Vous devez renommer votre volume ou le supprimer pour permettre à swarm de le recréer avec de nouvelles valeurs.
L'autre problème courant que je vois dans la plupart des utilisations de NFS est l'activation du "root squash" sur le serveur. Cela entraîne des problèmes d'autorisation lorsque des conteneurs exécutés en tant que root tentent d'écrire des fichiers sur le volume. Vous avez également des problèmes d'autorisations UID / GID similaires où l'UID / GID du conteneur est celui qui a besoin d'autorisations pour écrire sur le volume, ce qui peut nécessiter la propriété du répertoire et des autorisations ajustées sur le serveur NFS.