run extension example ejemplos docker dockerfile

extension - Comprender la instrucción "VOLUME" en DockerFile



dockerfile volume example (5)

A continuación se muestra el contenido de mi "Dockerfile"

FROM node:boron # Create app directory RUN mkdir -p /usr/src/app # change working dir to /usr/src/app WORKDIR /usr/src/app VOLUME . /usr/src/app RUN npm install EXPOSE 8080 CMD ["node" , "server" ]

En este archivo espero la instrucción "VOLUME. / Usr / src / app" para montar el contenido del directorio de trabajo actual en el host que se montará en la carpeta / contenedor / usr / src / app.

Por favor, avíseme si esta es la forma correcta?

El comando VOLUME en un Dockerfile es bastante legítimo, totalmente convencional, absolutamente bueno de usar y no está en desuso de ninguna manera. Solo necesito entenderlo.

Lo usamos para señalar cualquier directorio en el que la aplicación en el contenedor escribirá mucho. No usamos VOLUME solo porque queremos compartir entre el host y el contenedor como un archivo de configuración.

El comando simplemente necesita un parámetro; una ruta a una carpeta, relativa a WORKDIR si está establecida, desde dentro del contenedor. Luego, docker creará un volumen en su gráfico (/ var / lib / docker) y lo montará en la carpeta del contenedor. Ahora el contenedor tendrá un lugar para escribir con alto rendimiento. Sin el comando VOLUME la velocidad de escritura en la carpeta especificada será muy lenta porque ahora el contenedor está utilizando su estrategia de copy on write en el propio contenedor. La estrategia de copy on write es una razón principal por la que existen volúmenes.

Si monta sobre la carpeta especificada por el comando VOLUME , el comando nunca se ejecuta porque VOLUME solo se ejecuta cuando se inicia el contenedor, algo así como ENV .

Básicamente con el comando VOLUME obtienes rendimiento sin montar externamente ningún volumen. Los datos también se guardarán en las ejecuciones de contenedores sin ningún montaje externo. Luego, cuando esté listo, simplemente monte algo sobre él.

Algunos buenos ejemplos de casos de uso:
- registros
- carpetas temporales

Algunos casos de mal uso:
- archivos estáticos
- configs
- código

El tutorial oficial de Docker dice:

Un volumen de datos es un directorio especialmente designado dentro de uno o más contenedores que omite el Sistema de archivos de la Unión. Los volúmenes de datos proporcionan varias características útiles para datos persistentes o compartidos:

  • Los volúmenes se inicializan cuando se crea un contenedor. Si la imagen base del contenedor contiene datos en el punto de montaje especificado,
    que los datos existentes se copian en el nuevo volumen tras volumen
    inicialización (Tenga en cuenta que esto no se aplica al montar un host
    directorio.)

  • Los volúmenes de datos se pueden compartir y reutilizar entre contenedores.

  • Los cambios en un volumen de datos se realizan directamente.

  • Los cambios en un volumen de datos no se incluirán cuando actualice una imagen.

  • Los volúmenes de datos persisten incluso si se elimina el contenedor en sí.

En Dockerfile puede especificar solo el destino de un volumen dentro de un contenedor. por ejemplo /usr/src/app .

Cuando ejecuta su contenedor, por ejemplo, docker run --volume=/opt:/usr/src/app my_image , puede que no tenga que especificar su punto de montaje ( / opt ) en la máquina host. Si no especifica el argumento --volume , el punto de montaje se elegirá automáticamente.

En resumen: No, su instrucción VOLUME no es correcta.

VOLUME de Dockerfile especifica uno o más volúmenes dados las rutas del lado del contenedor. Pero no permite que el autor de la imagen especifique una ruta de host. En el lado del host, los volúmenes se crean con un nombre de ID muy largo dentro de la raíz de Docker. En mi máquina esto es /var/lib/docker/volumes .

Nota: Debido a que el nombre autogenerado es extremadamente largo y no tiene sentido desde la perspectiva humana, estos volúmenes a menudo se denominan "sin nombre" o "anónimo".

Su ejemplo que usa un ''.'' el personaje ni siquiera se ejecutará en mi máquina, no importa si hago que el punto sea el primer o segundo argumento. Me sale este mensaje de error:

docker: Respuesta de error del daemon: error de tiempo de ejecución oci: container_linux.go: 265: el proceso de inicio del contenedor causó "process_linux.go: 368: el inicio del contenedor causó /" abrir / dev / ptmx: no existe tal archivo o directorio / "".

Sé que lo que se ha dicho hasta este punto probablemente no sea muy valioso para alguien que intente comprender VOLUME y -v y ciertamente no proporciona una solución para lo que intenta lograr. Entonces, con suerte, los siguientes ejemplos arrojarán algo más de luz sobre estos temas.

Minitutorial: especificación de volúmenes

Dado este Dockerfile:

FROM openjdk:8u131-jdk-alpine VOLUME vol1 vol2

(Para el resultado de este minitutorial, no hay diferencia si especificamos vol1 vol2 o /vol1 /vol2 ; no me pregunten por qué)

Constrúyelo:

docker build -t my-openjdk

Correr:

docker run --rm -it my-openjdk

Dentro del contenedor, ejecute ls en la línea de comando y notará que existen dos directorios; /vol1 y /vol2 .

La ejecución del contenedor también crea dos directorios, o "volúmenes", en el lado del host.

Mientras se ejecuta el contenedor, ejecute docker volume ls en la máquina host y verá algo como esto (he reemplazado la parte central del nombre con tres puntos por brevedad):

DRIVER VOLUME NAME local c984...e4fc local f670...49f0

De vuelta en el contenedor , ejecute touch /vol1/weird-ass-file (crea un archivo en blanco en dicha ubicación).

Este archivo ahora está disponible en la máquina host, en uno de los volúmenes sin nombre jajaja. Me tomó dos intentos porque primero probé el primer volumen listado, pero finalmente encontré mi archivo en el segundo volumen listado, usando este comando en la máquina host:

sudo ls /var/lib/docker/volumes/f670...49f0/_data

Del mismo modo, puede intentar eliminar este archivo en el host y también se eliminará en el contenedor.

Nota: La carpeta _data también se conoce como "punto de montaje".

Salga del contenedor y enumere los volúmenes en el host. Se han ido. Utilizamos el indicador --rm cuando --rm el contenedor y esta opción elimina efectivamente no solo el contenedor al salir, sino también los volúmenes.

Ejecute un nuevo contenedor, pero especifique un volumen usando -v :

docker run --rm -it -v /vol3 my-openjdk

Esto agrega un tercer volumen y todo el sistema termina teniendo tres volúmenes sin nombre. El comando habría -v vol3 si hubiéramos especificado solo -v vol3 . El argumento debe ser una ruta absoluta dentro del contenedor. En el lado del host, el nuevo tercer volumen es anónimo y reside junto con los otros dos volúmenes en /var/lib/docker/volumes/ .

Anteriormente se dijo que el Dockerfile no se puede asignar a una ruta de host, lo que nos plantea un problema al intentar traer archivos desde el host al contenedor durante el tiempo de ejecución. Una sintaxis -v diferente resuelve este problema.

Imagine que tengo una subcarpeta en mi directorio de proyectos ./src que deseo sincronizar con /src dentro del contenedor. Este comando hace el truco:

docker run -it -v $(pwd)/src:/src my-openjdk

Ambos lados del : personaje espera un camino absoluto. El lado izquierdo es una ruta absoluta en la máquina host, el lado derecho es una ruta absoluta dentro del contenedor. pwd es un comando que "imprime el directorio actual / de trabajo". Poner el comando en $() toma el comando entre paréntesis, lo ejecuta en un subshell y devuelve la ruta absoluta a nuestro directorio de proyecto.

Poniéndolo todo junto, suponga que tenemos ./src/Hello.java en nuestra carpeta de proyecto en la máquina host con el siguiente contenido:

public class Hello { public static void main(String... ignored) { System.out.println("Hello, World!"); } }

Construimos este Dockerfile:

FROM openjdk:8u131-jdk-alpine WORKDIR /src ENTRYPOINT javac Hello.java && java Hello

Ejecutamos este comando:

docker run -v $(pwd)/src:/src my-openjdk

Esto imprime "¡Hola, mundo!".

La mejor parte es que somos completamente libres de modificar el archivo .java con un nuevo mensaje para otra salida en una segunda ejecución, sin tener que reconstruir la imagen =)

Observaciones finales

Soy bastante nuevo en Docker, y el "tutorial" mencionado anteriormente refleja la información que obtuve de un hackathon de línea de comandos de 3 días. Estoy casi avergonzado de no haber podido proporcionar enlaces a documentación clara en inglés que respalde mis declaraciones, pero honestamente creo que esto se debe a la falta de documentación y no al esfuerzo personal. Sé que los ejemplos funcionan según lo anunciado usando mi configuración actual que es "Windows 10 -> Vagrant 2.0.0 -> Docker 17.09.0-ce".

El tutorial no resuelve el problema "cómo especificamos la ruta del contenedor en el Dockerfile y dejamos que el comando ejecutar solo especifique la ruta del host". Puede haber una manera, simplemente no la he encontrado.

Finalmente, tengo el presentimiento de que especificar VOLUME en el Dockerfile no solo es infrecuente, sino que probablemente sea una mejor práctica nunca usar VOLUME . Por dos razones. La primera razón por la que ya hemos identificado: no podemos especificar la ruta del host, lo cual es bueno porque los Dockerfiles deben ser muy independientes de los detalles de una máquina host. Pero la segunda razón es que las personas podrían olvidarse de usar la opción --rm al ejecutar el contenedor. Uno podría recordar quitar el contenedor pero olvidarse de quitar el volumen. Además, incluso con la mejor memoria humana, podría ser una tarea desalentadora descubrir cuál de todos los volúmenes anónimos es seguro eliminar.

Especificar una línea VOLUME en un Dockerfile configura un poco de metadatos en su imagen, pero es importante cómo se usan esos metadatos.

Primero, qué hicieron estas dos líneas:

WORKDIR /usr/src/app VOLUME . /usr/src/app

La línea WORKDIR allí crea el directorio si no existe, y actualiza algunos metadatos de imagen para especificar todas las rutas relativas, junto con el directorio actual para comandos como RUN estarán en esa ubicación. La línea VOLUME allí especifica dos volúmenes , uno es la ruta relativa . , y el otro es /usr/src/app , ambos resultan ser el mismo directorio. Muy a menudo, la línea VOLUME solo contiene un único directorio, pero puede contener múltiples como lo ha hecho, o puede ser una matriz con formato json.

No puede especificar una fuente de volumen en el Dockerfile : una fuente común de confusión cuando se especifican volúmenes en un Dockerfile está tratando de hacer coincidir la sintaxis de tiempo de ejecución de una fuente y un destino en el momento de la creación de la imagen, esto no funcionará . El Dockerfile solo puede especificar el destino del volumen. Sería una hazaña de seguridad trivial si alguien pudiera definir la fuente de un volumen, ya que podría actualizar una imagen común en el Docker Hub para montar el directorio raíz en el contenedor y luego iniciar un proceso en segundo plano dentro del contenedor como parte de un punto de entrada que agrega inicios de sesión a / etc / passwd, configura systemd para lanzar un minero de bitcoin en el próximo reinicio, o busca en el sistema de archivos tarjetas de crédito, SSN y claves privadas para enviar a un sitio remoto.

¿Qué hace la línea VOLUME? Como se mencionó, establece algunos metadatos de imagen para decir que un directorio dentro de la imagen es un volumen. ¿Cómo se usan estos metadatos? Cada vez que cree un contenedor a partir de esta imagen, Docker forzará ese directorio a ser un volumen. Si no proporciona un volumen en su comando de ejecución, o redacta un archivo, la única opción para Docker es crear un volumen anónimo. Este es un volumen con nombre local con una identificación única larga para el nombre y ninguna otra indicación de por qué se creó o qué datos contiene (los volúmenes anónimos se pierden). Si anula el volumen, apuntando a un volumen con nombre o de host, sus datos irán allí.

VOLUME rompe cosas: no puede deshabilitar un volumen una vez definido en un Dockerfile. Y lo más importante, el comando EJECUTAR en Docker se implementa con contenedores temporales. Esos contenedores temporales obtendrán un volumen anónimo temporal. Ese volumen anónimo se inicializará con el contenido de su imagen. Cualquier escritura dentro del contenedor desde su comando RUN se realizará en ese volumen. Cuando finaliza el comando EJECUTAR, se guardan los cambios en la imagen y se descartan los cambios en el volumen anónimo. Debido a esto, recomiendo no definir un VOLUME dentro del Dockerfile. Resulta en un comportamiento inesperado para los usuarios intermedios de su imagen que desean extender la imagen con datos iniciales en la ubicación del volumen.

¿Cómo debe especificar un volumen? Para especificar dónde desea incluir volúmenes con su imagen, proporcione un docker-compose.yml . Los usuarios pueden modificar eso para ajustar la ubicación del volumen a su entorno local, y captura otras configuraciones de tiempo de ejecución como puertos de publicación y redes.

¡Alguien debería documentar esto! Ellos tienen. Docker incluye advertencias sobre el uso de VOLUME en su documentación en el Dockerfile junto con consejos para especificar la fuente en tiempo de ejecución:

  • Cambiar el volumen desde el Dockerfile: si alguno de los pasos de compilación cambia los datos dentro del volumen después de que se haya declarado, esos cambios se descartarán.

...

  • El directorio del host se declara en tiempo de ejecución del contenedor: el directorio del host (el punto de montaje) depende, por su naturaleza, del host. Esto es para preservar la portabilidad de la imagen, ya que no se puede garantizar que un directorio de host determinado esté disponible en todos los hosts. Por este motivo, no puede montar un directorio de host desde el Dockerfile. La instrucción VOLUME no admite la especificación de un parámetro host-dir . Debe especificar el punto de montaje cuando cree o ejecute el contenedor.

Para comprender mejor la instrucción de volume en dockerfile, aprendamos el uso de volumen típico en la implementación del archivo docker oficial mysql.

VOLUME /var/lib/mysql

Referencia: https://github.com/docker-library/mysql/blob/3362baccb4352bcf0022014f67c1ec7e6808b8c5/8.0/Dockerfile

/var/lib/mysql es la ubicación predeterminada de MySQL que almacena archivos de datos.

Cuando ejecuta el contenedor de prueba solo con fines de prueba, no puede especificar su punto de montaje, p. Ej.

docker run mysql:8

entonces la instancia del contenedor mysql usará la ruta de montaje predeterminada que se especifica mediante la instrucción de volume en dockerfile. los volúmenes se crean con un nombre de ID muy largo dentro de la raíz de Docker, esto se llama volumen "sin nombre" o "anónimo". En la carpeta del sistema host subyacente / var / lib / docker / volume.

/var/lib/docker/volumes/320752e0e70d1590e905b02d484c22689e69adcbd764a69e39b17bc330b984e4

Esto es muy conveniente para propósitos de prueba rápida sin la necesidad de especificar el punto de montaje, pero aún puede obtener el mejor rendimiento al usar Volumen para el almacenamiento de datos, no la capa de contenedor.

Para un uso formal, deberá especificar la ruta de montaje anulando el punto de montaje para usar el volumen con nombre, por ejemplo

docker run -v /my/own/datadir:/var/lib/mysql mysql:8

El comando monta el directorio / my / own / datadir desde el sistema host subyacente como / var / lib / mysql dentro del contenedor. El directorio de datos / my / own / datadir no se eliminará automáticamente, incluso se eliminará el contenedor.

Uso de la imagen oficial de mysql: Referencia: https://hub.docker.com/_/mysql/