El modo Swarm en sí no hace nada diferente con los volúmenes, ejecuta cualquier comando de montaje de volumen que proporciones en el nodo donde se ejecuta el contenedor. Si su montaje de volumen es local para ese nodo, sus datos se guardarán localmente en ese nodo. No hay una funcionalidad incorporada para mover datos entre nodos automáticamente.
Hay algunas soluciones de almacenamiento distribuido basadas en software como GlusterFS, y Docker tiene una llamada Infinit que aún no es GA y el desarrollo ha pasado a un segundo plano frente a la integración de Kubernetes en EE.
El resultado típico es que necesita administrar la replicación del almacenamiento dentro de su aplicación (por ejemplo, etcd y otros algoritmos basados en balsa) o realiza sus montajes en un sistema de almacenamiento externo (con suerte con su propio HA). El montaje de un sistema de almacenamiento externo tiene dos opciones, basado en bloques o en archivos. El almacenamiento basado en bloques (p. Ej., EBS) suele tener un rendimiento superior, pero está limitado a montarse en un solo nodo. Para esto, normalmente necesitará un controlador de complemento de volumen de terceros para darle acceso a su nodo Docker a ese almacenamiento en bloque. El almacenamiento basado en archivos (por ejemplo, EFS) tiene un rendimiento más bajo, pero es más portátil y puede montarse simultáneamente en varios nodos, lo que es útil para un servicio replicado.
El almacenamiento de red basado en archivos más común es NFS (este es el mismo protocolo que usa EFS). Y puede montar eso sin ningún controlador de complemento de terceros. El controlador del complemento de volumen "local", lamentablemente llamado, que viene con la ventana acoplable, le da la opción de pasar los valores que desee al comando de montaje con las opciones del controlador, y sin opciones, por defecto almacena volúmenes en el directorio de la ventana acoplable / var / lib / Docker / volúmenes. Con las opciones, puede pasarle los parámetros de NFS, e incluso realizará una búsqueda de DNS en el nombre de host de NFS (algo que normalmente no tiene con NFS). Aquí hay un ejemplo de las diferentes formas de montar un sistema de archivos NFS usando el controlador de volumen 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 usa el ejemplo de archivo de redacción al final, tenga en cuenta que los cambios en un volumen (por ejemplo, la actualización de la ruta o dirección del servidor) no se reflejan en los volúmenes con nombre existentes mientras existan. Debe cambiar el nombre de su volumen o eliminarlo para permitir que swarm lo vuelva a crear con nuevos valores.
El otro problema común que veo en la mayoría de los usos de NFS es que "root squash" está habilitado en el servidor. Esto da lugar a problemas de permisos cuando los contenedores que se ejecutan como root intentan escribir archivos en el volumen. También tiene problemas de permisos de UID / GID similares en los que el UID / GID del contenedor es el que necesita permisos para escribir en el volumen, lo que puede requerir que la propiedad del directorio y los permisos se ajusten en el servidor NFS.