run - ¿Cómo implementa Docker Swarm el intercambio de volúmenes?

docker-compose

Question

Docker Swarm puede administrar dos tipos de almacenamiento: volumen y enlace. Si bien Docker Documentation no sugiere la vinculación, ya que crea una vinculación entre un directorio local (en cada Nodo de enjambre) a una tarea, no se menciona la implementación del método de volumen, por lo que no entiendo cómo se comparten los volúmenes entre las tareas.

¿Cómo Docker Swarm comparte volúmenes entre nodos? ¿Dónde se guardan los volúmenes (en un administrador? Y si hay más de uno administra?)?

No hay problema entre los nodos si se ejecuta en diferentes máquinas en diferentes redes? ¿Crea una VPN?

Answer 1

Después de buscar en la documentación y en las discusiones de la ventana acoplable, pude encontrar la siguiente información sobre este problema:

• enlazar el montaje de un directorio de host en un contenedor ( docker run -v /some/host/dir/:/container/path/ ) utiliza los archivos que están presentes en el host. Si el directorio del host no existe, se crea un nuevo directorio vacío en el host y se monta en el contenedor (esto cambiará en el futuro y se mostrará un error)
• el uso de un volumen " sin nombre " ( docker run -v /container/path ) creará un nuevo volumen y copiará el contenido de / container / path en ese volumen
• el uso de un volumen "con nombre " ( docker run -v somename:/container/path ) creará un nuevo volumen, llamado "somename", o usará el volumen "somename" existente, y usará los archivos que están presentes dentro de ese volumen. Si el volumen se acaba de crear, estará vacío.

Fuente: Discusión sobre Github

La razón de todo esto es:

No es un error, actuó así porque debería hacerlo. Para el volumen anónimo, Docker sabe que los volúmenes están completamente controlados por sí mismos, por lo que Docker puede hacer cualquier cosa que considere correcta (aquí está copiando archivos de imagen al volumen). Pero el volumen con nombre está diseñado para el complemento de volumen, por lo que Docker no sabe qué debe hacer y no hace nada.

Fuente: Discusión relacionada sobre Github

Por lo tanto, debe usar un controlador de volumen que admita lo que de hecho se puede encontrar en la tienda acoplable

Answer 2

El modo de enjambre en sí mismo no hace nada diferente con los volúmenes, ejecuta cualquier comando de montaje de volumen que proporcione en el nodo donde se ejecuta el contenedor. Si su montaje de volumen es local en ese nodo, sus datos se guardarán localmente en ese nodo. No hay una funcionalidad integrada 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 dejado atrás 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 realizar sus montajes en un sistema de almacenamiento externo (con suerte con su propia HA). El montaje de un sistema de almacenamiento externo tiene dos opciones, basadas en bloques o archivos. El almacenamiento basado en bloques (p. Ej., EBS) generalmente viene con un mayor rendimiento, pero se limita a estar solo montado en un solo nodo. Para esto, normalmente necesitará un controlador de complemento de volumen de terceros para dar acceso a su nodo acoplable a ese almacenamiento de 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 múltiples nodos, lo cual es útil para un servicio replicado.

El almacenamiento de red basado en archivos más común es NFS (este es el mismo protocolo utilizado por EFS). Y puede montar eso sin ningún controlador de complemento de terceros. El controlador de plugin de volumen "local" desafortunadamente con el que se entrega Docker le da la opción de pasar cualquier valor que desee al comando de montaje con opciones de controlador, y sin opciones, por defecto almacena volúmenes en el directorio docker / var / lib / acoplador / 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 utilizando 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"
  ...

Answer 3

Lo que estás preguntando es una pregunta común. Los datos de volumen y las características de lo que ese volumen puede hacer son administrados por un controlador de volumen. Al igual que puede usar diferentes controladores de red como overlay , bridge o host , puede usar diferentes controladores de volumen.

Docker y Swarm solo vienen con el controlador local estándar de fábrica. No tiene ningún conocimiento de Swarm, y solo creará nuevos volúmenes para sus datos en cualquier nodo en el que estén programadas sus tareas de servicio. Esto generalmente no es lo que quieres.

Desea un complemento de controlador de terceros que sea consciente de Swarm, y se asegurará de que el volumen que creó para una tarea de servicio esté disponible en el nodo correcto en el momento correcto. Las opciones incluyen el uso de "Docker for AWS / Azure" y su controlador CloudStor incluido, o la popular solución REX-Ray código abierto.

Hay muchos controladores de volumen de terceros, que puede encontrar en Docker Store .

Answer 4

Mi solución para AWS EFS, que funciona:

1. Cree EFS (no olvide abrir el puerto NFS 2049 en el grupo de seguridad)

2. Instale el paquete nfs-common:

   sudo apt-get install -y nfs-common

3. Comprueba si tu efs funciona:

   mkdir efs-test-point sudo chmod go+rw efs-test-point

   sudo mount -t nfs -o nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport [YOUR_EFS_DNS]:/ efs-test-point

   touch efs-test-point/1.txt sudo umount efs-test-point/ ls -la efs-test-point/

   el directorio debe estar vacío

   sudo mount -t nfs -o nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport [YOUR_EFS_DNS]:/ efs-test-point

   ls -la efs-test-point/

   el archivo 1.txt debe existir

4. Configure el archivo docker-compose.yml:

   services: sidekiq: volumes: - uploads_tmp_efs:/home/application/public/uploads/tmp ... volumes: uploads_tmp_efs: driver: local driver_opts: type: nfs o: addr=[YOUR_EFS_DNS],nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2 device: [YOUR_EFS_DNS]:/