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

Después de leer los documentos, me encontré algo confundido sobre la mejor manera de administrar datos productivos de aplicaciones / servicios.

Parece que hay 3 opciones:

Simplemente asigne el volumen al directorio del host (es decir, -vargumento para docker run)
Crear una imagen de contenedor de docker para datos (es decir, contenedor separado y --volumes-from)
Crear un volumen acoplable (es decir 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 # 3.

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

Necesita datos de la aplicación en un volumen separado y / o nivel de almacenamiento en su servidor
Copia de seguridad
Restaurando datos

storage docker

— dukeofgaming
fuente

serverfault.com/q/576490/126632

— Michael Hampton

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

— dukeofgaming

# 1 no es una opción seria para la producción; Básicamente, nunca debe hacerse si existe una alternativa.

— Michael Hampton

@MichaelHampton datos ?, ¿Por qué no pueden ser dockerized pero el sistema operativo anfitrión todavía es gestionado por un equipo de infraestructura que los monitores y las copias de seguridad

— dukeofgaming

@dukeofgaming Sin mencionar que puedes ejecutarlo btrfs scrubpara encontrar y corregir archivos dañados. No estoy seguro de cómo funciona el material dockerizado, pero supongo que no protege contra la descomposición de datos, por lo que siempre necesito una restauración completa si ocurre algo malo en lugar de simplemente restaurar archivos individuales. Otro pensó 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.

— inf3rno

Respuestas:

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 volumen con nombre y hacer de manera similar lo que haría con # 2 en su -vlugar.

Crea un volumen con nombre:

$ docker volume create --name test

Monte y escriba algunos datos en ese volumen desde un contenedor:

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

Luego puede montar ese mismo testvolumen en otro contenedor y leer los datos:

$ 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

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

$ d volume ls
DRIVER              VOLUME NAME
local               test

También abre las posibilidades para los controladores de volumen en el futuro para que pueda hacer volúmenes compartidos entre hosts (es decir, volúmenes nombrados a través de NFS). Ejemplos de esto podrían ser Flocker y Convoy . Según su punto de vista específico sobre cómo mover o respaldar datos, Convoy tiene subcomandos específicos para respaldar datos y permite el almacenamiento en NFS o EBS externos a su host.

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

— Andy Shinn
fuente

Gracias, usted respondió la mayoría de mis preguntas, pero el punto de administrar los datos del contenedor en un nivel de volumen físico diferente aún no tiene respuesta y esa es la crítica ... supongamos que esta es una solución de gestión de repositorio git y necesito esa parte del contenedor datos (que es un volumen definido en un dockerfile) en el almacenamiento de Nivel 0 ubicado en un volumen de host físico diferente (es decir, otra partición, disco físico o lo que sea)

— dukeofgaming

Me tipo de hice con la mención de los conductores de volumen. En este momento, para almacenar datos fuera del controlador de almacenamiento local físico, necesitaría usar uno que hiciera específicamente lo que está buscando hacer. Fuera de mi cabeza, hay github.com/rancher/convoy y github.com/ClusterHQ/flocker . Convoy tiene soporte para NFS y GlusterFS en este momento, lo que parece más cercano a lo que está buscando. Modificaré la respuesta para aclarar esto.

— Andy Shinn el

El uso del controlador devicemapper parece responder a mi pregunta, ¡gracias! docs.docker.com/engine/userguide/storagedriver/…

— dukeofgaming

the volume won't accidentally disappear if you remove the data-only container. ¿Podrías dar más detalles? Gracias.

— Stephane

A partir de Docker 1.9, se prefiere crear volúmenes con nombre con la API de volúmenes ( docker volume create --name mydata) en lugar de un contenedor de volumen de datos. A partir de febrero de 2016, la documentación de los volúmenes de Docker está lamentablemente desactualizada. 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 (si no todos) los casos " y " no hay razón que pueda ver para usar contenedores de solo datos ".

— Quinn Commandado
fuente