Docker proporciona 2 formas de hacer una copia de seguridad y sincronizar los datos del contenedor en la máquina local, es decir, volumen y Monte. Ambos se comportan de la misma manera, excepto por algunas cosas que noté:
- Un volumen siempre mantiene los datos en /var / lib/docker / volumes, mientras que los puntos de montaje se pueden crear donde queramos.
- Si a un contenedor al que se le asigna un punto de montaje también se le asigna un volumen, todos los datos del punto de montaje se copian en el volumen automáticamente, mientras que lo contrario no es cierto.
- No podemos describir un punto de montaje en un Dockerfile, pero podemos dar volúmenes en un Dockerfile.
Ok, entonces podemos decir que hay algunas ventajas y desventajas de la metodología, pero todavía hay algunas clasificaciones o diferencias en términos de optimización.
Proporcione una respuesta explicada.
En realidad, hay tres tipos de volúmenes:
- Volumen de Host: a lo que se refiere como montaje en un contenedor, el término más común es montaje de enlace.
- Volumen con nombre: cualquier volumen administrado por docker al que le asigne un nombre.
- Volumen anónimo: cualquier volumen sin origen, docker lo creará como un volumen local con un id único largo y se comportará como un volumen con nombre.
Los volúmenes tienen un origen y un destino. El origen identifica el tipo de volumen, por lo que una ruta (incluida la barra inclinada) a un archivo/directorio da como resultado un volumen host. Si no proporciona una fuente, obtendrá los volúmenes anónimos. Si define un volumen dentro de un Dockerfile, no puede especificar un origen allí, por lo que, de forma predeterminada, docker creará volúmenes anónimos a menos que indique lo contrario en tiempo de ejecución.
Para cada tipo, aquí están los pros/contras:
- Host:
- Pro: fácil acceso a los archivos subyacentes desde el host
- Con: se producen problemas de permisos de uid/gid cuando el uid del usuario del contenedor no coincide con el gid del host
- Con: los datos no se inicializan
- Nombrado:
- Pro: fácil de crear una interfaz entre diferentes contenedores / imágenes. Si solo le da un nombre sin ninguna otra configuración, el controlador local almacenará de forma predeterminada sus datos en /var/lib/docker/volumes, al que solo debería poder acceder el usuario root desde fuera de docker.
- Pro: inicializa el contenido en el contenido de la imagen cuando está vacío/nuevo y se crea el contenedor. Esta inicialización incluye los propietarios de los archivos y los permisos de la imagen, lo que puede resolver la mayoría de los problemas de uid/gid.
- Pro: Puede conectarse a cualquier cosa que pueda hacer un comando de montaje, incluido un montaje de enlace o un montaje NFS, con un controlador local. Otros controladores le permiten hacer referencia a datos en más ubicaciones (por ejemplo, proveedores de nube).
- Contras: la administración de contenido debe realizarse a través de un contenedor.
- Anónimo:
- Pro: no requiere planificación para su uso
- Con: los datos normalmente se pierden aquí, ya que no hay una asignación del volumen al contenedor/imagen que lo creó. Esta es la peor forma de almacenar volúmenes en mi opinión, y la razón por la que nadie debería definir un volumen dentro de su Dockerfile.
Cuando es posible, uso un volumen con nombre. La inicialización de datos y un mejor manejo de los problemas de uid/gid superan la conveniencia de un volumen de host. Si realmente necesito acceso fuera de docker directamente a los datos, trato de usar un volumen con nombre que apunte a un montaje de enlace en lugar de la configuración predeterminada del controlador local. Un ejemplo simple de esto es:
$ docker volume create --driver local \ --opt type=none \ --opt device=/home/user/test \ --opt o=bind \ test_vol
Para definir mis volúmenes, ya que no desea hacer esto en un Dockerfile, utilizo un docker-compose.yml y define mis volúmenes allí. Si se implementa con el modo de enjambre, apuntaré a un servidor NFS con un volumen con nombre para permitir que se llegue a los datos a medida que los contenedores migran a diferentes hosts. De lo contrario, es un volumen con nombre local que se puede usar fácilmente con docker-compose.
Los volúmenes en el dockerfile permiten especificar una ruta en la imagen que siempre debe crearse como un volumen. Esto omite inherentemente el sistema de archivos de unión que usa docker.
Los usuarios de dicha imagen siempre obtendrán un volumen en esa ubicación cuando ejecuten
docker run <imagename>
es decir, no hay razón para agregar nunca -v /my/mount/point:/mount/here y, por lo tanto, los usuarios no necesitan preocuparse por ello.
soportes de unión (como en el ejemplo anterior con -v) siempre deben estar presentes si se requieren. y no son portátiles entre imágenes.
las diferencias efectivas con la optimización son estas:
- los volúmenes se pueden usar donde se necesitan muchas operaciones de r / w y tiene escritura comercial en el sistema de archivos union (piense en bases de datos)
- los volúmenes no valen nada para montar cosas como volúmenes de datos. puedes hacerlo, pero recibes un enorme golpe de r/w porque no hay razón para que esto esté en el sistema de archivos de la unión.
- los montajes, sin embargo, almacenarán esto (lo anterior) bastante bien, ya que simplemente montan el directorio existente en un lugar dentro del contenedor e ignoran el sistema de archivos de unión para ese directorio en conjunto.
¿tiene sentido?