¿Cómo decidir entre un contenedor de volumen de docker y un volumen de docker?

Después de leer los documentos, me encontré un poco confundido en cuanto a la mejor manera de administrar los datos productivos de aplicaciones/servicios.

Parece que hay 3 opciones:

  1. Simplemente asigne el volumen al directorio de host (es decir, -v argumento a favor docker run)
  2. Cree una imagen de contenedor de docker para datos (es decir, contenedor separado y --volumes-from)
  3. Creación de un volumen de docker (p. ej. docker volume create)

Ahora, parece que la práctica aceptada es la opción # 2, pero luego me pregunto cuál es el propósito de la #3.

Especialmente, ¿cómo maneja correctamente estos escenarios con docker volume ¿y es mejor usar un contenedor de volumen de datos o esto para cada situación?

  • Necesita datos de aplicaciones en un volumen o nivel de almacenamiento independiente en el servidor
  • Copia de seguridad
  • Restauración de datos

A partir de Docker 1.9, la creación de volúmenes con nombre con API de Volúmenes (docker volume create --name mydata) sobre un Contenedor de Volumen de Datos. A partir de febrero de 2016, la ventana acoplable documentación de volúmenes está lamentablemente desactualizado. La gente de Docker sugiere que los Contenedores de Volumen de datos "ya no se consideran un patrón recomendado,” “los volúmenes con nombre deberían poder reemplazar los volúmenes de solo datos en la mayoría de los casos (si no en todos) ,” y “no veo ninguna razón para usar contenedores de solo datos.”

Creo que #2 y #3 son más o menos lo mismo, la principal diferencia es que no hay un contenedor detenido con #3 (es literalmente, solo un volumen con nombre). Por ejemplo, puede crear un nombre de volumen y hacer de manera similar en lo que haría con el #2 con -v en su lugar.

Crear un volumen con nombre:

$ docker volume create --name test

Montar y escribir algunos datos en ese volumen desde un contenedor:

$ docker run -v test:/opt/test alpine touch /opt/test/hello

A continuación, puede montar el mismo test volumen en otro contenedor y leer los datos:

$ docker run -v test:/opt/test alpine ls -al /opt/test     total 8drwxr-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

La ventaja aquí es que el volumen no desaparecerá accidentalmente si elimina el contenedor de solo datos. Ahora lo gestionas con el docker volume subcomando.

$ d volume lsDRIVER              VOLUME NAMElocal               test

También abre las posibilidades de los controladores de volumen en el futuro, por lo que es posible que pueda hacer volúmenes compartidos entre hosts (es decir,. volúmenes con nombre sobre NFS). Ejemplos de esto podrían ser Floculante y Convoy. Para su punto específico sobre el movimiento o la copia de seguridad de datos, Convoy tiene subcomandos específicos para realizar copias de seguridad de datos y permite el almacenamiento en NFS o EBS externos a su host.

Por esta razón, creo que la forma más novedosa (Docker 1.9+) es usar un volumen con nombre en lugar de un contenedor de solo datos.

@MichaelHampton ¿Por qué?, es posible que los datos no se acoplen, pero el sistema operativo host sigue siendo administrado por un equipo de infraestructura que supervisa y realiza copias de seguridad

@MichaelHampton me di cuenta de que debería reformular mi pregunta

@dukeofgaming Sin mencionar que puede ejecutar `btrfs scrub ’ en él para encontrar y corregir archivos dañados. No estoy seguro de cómo funcionan las cosas acopladas, pero supongo que no protegen contra la descomposición de los datos, por lo que siempre necesito una restauración completa si sucede algo malo en lugar de solo restaurar archivos individuales. Otro pensamiento es que agrega otra capa de abstracción, por lo que ralentiza aún más la lectura y escritura de archivos. De alguna manera, no veo las ventajas de #2 y #3, pero no tengo experiencia con docker, por lo que esto podría cambiar.

El # 1 no es una opción seria para la producción; básicamente, nunca se debe hacer si existe una alternativa.