tag run library imagenes hub example dockers container docker dockerfile docker-compose

run - dockers container download



Cómo montar volúmenes locales en la máquina acoplable (11)

Estoy tratando de usar docker-machine con docker-compose. El archivo docker-compose.yml tiene las siguientes definiciones:

web: build: . command: ./run_web.sh volumes: - .:/app ports: - "8000:8000" links: - db:db - rabbitmq:rabbit - redis:redis

Cuando se ejecuta docker-compose up -d todo funciona bien hasta que se intenta ejecutar el comando y se produce un error:

No se puede iniciar el contenedor b58e2dfa503b696417c1c3f49e2714086d4e9999bd71915a53502cb6ef43936d: [8] Error del sistema: exec: "./run_web.sh": stat ./run_web.sh: no existe dicho archivo o directorio

Los volúmenes locales no están montados en la máquina remota. ¿Cuál es la estrategia recomendada para montar los volúmenes locales con el código de webapps?

Después de resumir las publicaciones aquí, adjunto script actualizado, para crear un punto de montaje de host adicional y montar automáticamente cuando se reinicie Virtualbox. El resumen del entorno de trabajo es el siguiente: - Windows 7 - docker-machine.exe versión 0.7.0 - VirtualBox 5.0.22

#!env bash : ${NAME:=default} : ${SHARE:=c/Proj} : ${MOUNT:=/c/Proj} : ${VBOXMGR:=C:/Program Files/Oracle/VirtualBox/VBoxManage.exe} SCRIPT=/mnt/sda1/var/lib/boot2docker/bootlocal.sh ## set -x docker-machine stop $NAME "$VBOXMGR" sharedfolder add $NAME --name c/Proj --hostpath ''c:/' --automount 2>/dev/null || : docker-machine start $NAME docker-machine env $NAME docker-machine ssh $NAME ''echo "mkdir -p $MOUNT" | sudo tee $SCRIPT'' docker-machine ssh $NAME ''echo "sudo mount -t vboxsf -o rw,user $SHARE $MOUNT" | sudo tee -a $SCRIPT'' docker-machine ssh $NAME ''sudo chmod +x /mnt/sda1/var/lib/boot2docker/bootlocal.sh'' docker-machine ssh $NAME ''sudo /mnt/sda1/var/lib/boot2docker/bootlocal.sh'' #docker-machine ssh $NAME ''ls $MOUNT''

Docker-machine monta automáticamente el directorio de usuarios ... Pero a veces eso no es suficiente.

No sé sobre Docker 1.6, pero en 1.8 PUEDES agregar un montaje adicional a la máquina acoplable

Agregar punto de montaje de máquina virtual (parte 1)

CLI : (solo funciona cuando la máquina está parada)

VBoxManage sharedfolder add <machine name/id> --name <mount_name> --hostpath <host_dir> --automount

Entonces, un ejemplo en Windows sería

/c/Program/ Files/Oracle/VirtualBox/VBoxManage.exe sharedfolder add default --name e --hostpath ''e:/' --automount

GUI : (NO requiere que la máquina se detenga)

  1. Inicie "Oracle VM VirtualBox Manager"
  2. Haga clic con el <machine name> derecho en <machine name> (predeterminado)
  3. Configuraciones ...
  4. Carpetas compartidas
  5. El icono de carpeta + a la derecha (Agregar recurso compartido)
  6. Ruta de la carpeta: <host dir> (e :)
  7. Nombre de carpeta: <mount name> (e)
  8. Marque "Montaje automático" y "Hacer permanente" (lea solo si lo desea ...) (El montaje automático no tiene sentido actualmente ...)

Montaje en boot2docker (parte 2)

Montar manualmente en boot2docker :

  1. Hay varias formas de iniciar sesión, usar "Mostrar" en "Oracle VM VirtualBox Manager", o ssh / putty en docker por la dirección IP docker-machine ip default , etc.
  2. sudo mkdir -p <local_dir>
  3. sudo mount -t vboxsf -o defaults,uid=`id -u docker`,gid=`id -g docker` <mount_name> <local_dir>

Pero esto solo es bueno hasta que reinicie la máquina, y luego se pierde el soporte ...

Agregar un montaje automático a boot2docker :

Mientras está conectado a la máquina

  1. Editar / crear (como root) /mnt/sda1/var/lib/boot2docker/bootlocal.sh , sda1 puede ser diferente para usted ...

  2. Añadir

    mkdir -p <local_dir> mount -t vboxsf -o defaults,uid=`id -u docker`,gid=`id -g docker` <mount_name> <local_dir>

Con estos cambios, debería tener un nuevo punto de montaje. Este es uno de los pocos archivos que pude encontrar que se llama en el arranque y es persistente. Hasta que haya una mejor solución, esto debería funcionar.

Método antiguo: menos recomendado , pero dejado como alternativa

  • Editar (como root) /mnt/sda1/var/lib/boot2docker/profile , sda1 puede ser diferente para usted ...

  • Añadir

    add_mount() { if ! grep -q "try_mount_share $1 $2" /etc/rc.d/automount-shares ; then echo "try_mount_share $1 $2" >> /etc/rc.d/automount-shares fi } add_mount <local dir> <mount name>

Como último recurso , puede tomar la alternativa un poco más tediosa, y simplemente puede modificar la imagen de arranque.

  • git -c core.autocrlf=false clone https://github.com/boot2docker/boot2docker.git
  • cd boot2docker
  • git -c core.autocrlf=false checkout v1.8.1 #o su versión adecuada
  • Edite rootfs/etc/rc.d/automount-shares

  • Agregue try_mount_share <local_dir> <mount_name> línea justo antes de fi al final. Por ejemplo

    try_mount_share /e e

    Solo asegúrese de no configurar todo lo que el sistema operativo necesita, como / bin, etc.

  • docker build -t boot2docker . # Esto tomará aproximadamente una hora la primera vez :(
  • docker run --rm boot2docker > boot2docker.iso
  • Haga una copia de seguridad del viejo boot2docker.iso y copie el nuevo en su lugar, en ~ / .docker / machine / machines /

Esto funciona, es largo y complicado

docker versión 1.8.1, docker-machine versión 0.4.0

Estoy usando docker-machine 0.12.2 con la unidad virtualbox en mi máquina local. Descubrí que hay un directorio /hosthome/$(user name) desde el que tiene acceso a los archivos locales.

Finalmente descubrí cómo actualizar Windows Docker Toolbox a v1.12.5 y mantener mis volúmenes funcionando agregando una carpeta compartida en el administrador de Oracle VM VirtualBox y desactivando la conversión de ruta. Si tiene Windows 10+, lo mejor es usar el Docker más nuevo para Windows.

Primero la actualización Pain:

  1. Desinstale VirtualBox primero.
    • Sí, eso puede romper cosas en otras herramientas como Android Studio. Gracias Docker :(
  2. Instale la nueva versión de Docker Toolbox.

Ejemplo de base de datos Redis: redis: image: redis:alpine container_name: redis ports: - "6379" volumes: - "/var/db/redis:/data:rw"

En la terminal de inicio rápido de Docker ...

  1. ejecutar docker-machine stop default - Asegúrese de que VM sea transportada

En Oracle VM VirtualBox Manager ...

  1. Se agregó una carpeta compartida en la máquina virtual default través de la línea de comando
    • D:/Projects/MyProject/db => /var/db

En docker-compose.yml ...

  1. Volumen redis asignado como: "/var/db/redis:/data:rw"

En la terminal de inicio rápido de Docker ...

  1. Establezca COMPOSE_CONVERT_WINDOWS_PATHS=0 (para la versión Toolbox> = 1.9.0)
  2. Ejecute docker-machine start default para reiniciar la VM.
  3. cd D:/Projects/MyProject/
  4. docker-compose up debería funcionar ahora.

Ahora crea la base de datos redis en D:/Projects/MyProject/db/redis/dump.rdb

¿Por qué evitar las rutas de host relativas?

Evité las rutas de host relativas para Windows Toolbox, ya que pueden introducir caracteres ''/' no válidos. No es tan bueno como usar rutas relativas a docker-compose.yml pero al menos mis colegas desarrolladores pueden hacerlo fácilmente incluso si su carpeta de proyecto está en otro lugar sin tener que hackear el archivo docker-compose.yml (malo para SCM).

Edición original

FYI ... Aquí está el error original que obtuve cuando utilicé rutas relativas limpias y buenas que solían funcionar bien para versiones anteriores. Mi mapeo de volumen solía ser solo "./db/redis:/data:rw"

ERROR: for redis Cannot create container for service redis: Invalid bind mount spec "D://Projects//MyProject//db//redis:/data:rw": Invalid volume specification: ''D:/Projects/MyProject/db/redis:/data

Esto se rompe por dos razones.

  1. No puede acceder a D: conducir
  2. Las rutas de volumen no pueden incluir / caracteres
    • docker-compose agrega y luego te culpa por ello!
    • Use COMPOSE_CONVERT_WINDOWS_PATHS=0 para detener estas tonterías.

Recomiendo documentar su asignación adicional de carpetas compartidas de VM en su archivo docker-compose.yml , ya que es posible que deba desinstalar VirtualBox nuevamente y restablecer la carpeta compartida y de todos modos sus colegas desarrolladores lo amarán por ello.

Por el momento, realmente no puedo ver ninguna forma de montar volúmenes en máquinas, por lo que el enfoque ahora sería copiar o sincronizar de alguna manera los archivos que necesita en la máquina.

Hay https://github.com/docker/machine/issues/179 sobre cómo resolver este problema en el repositorio github de la máquina acoplable. Alguien hizo una solicitud de extracción implementando scp en docker-machine y ya está fusionado en master, por lo que es muy probable que la próxima versión lo incluya.

Como aún no se ha lanzado, ahora recomendaría que si tiene su código alojado en github, simplemente clone su repositorio antes de ejecutar la aplicación

web: build: . command: git clone https://github.com/my/repo.git; ./repo/run_web.sh volumes: - .:/app ports: - "8000:8000" links: - db:db - rabbitmq:rabbit - redis:redis

Actualización: mirando más allá, descubrí que la función ya está disponible en los últimos binarios , cuando los obtenga, podrá copiar su proyecto local ejecutando un comando como este:

docker-machine scp -r . dev:/home/docker/project

Siendo esta la forma general:

docker-machine scp [machine:][path] [machine:][path]

Para que pueda copiar archivos desde, hacia y entre máquinas.

Saludos 1

Si elige la opción rsync con docker-machine, puede combinarla con el comando docker-machine ssh <machinename> esta manera:

rsync -rvz --rsh=''docker-machine ssh <machinename>'' --progress <local_directory_to_sync_to> :<host_directory_to_sync_to>

Utiliza este formato de comando de rsync, dejando HOST blanco:

rsync [OPTION]... SRC [SRC]... [USER@]HOST:DEST

( http://linuxcommand.org/man_pages/rsync1.html )

Solo pensé en mencionar que he estado usando 18.03.1-ce-win65 (17513) en Windows 10 y noté que si previamente compartió una unidad y almacenó en caché las credenciales, una vez que cambie su contraseña, la ventana acoplable comenzará a tener los volúmenes montados dentro de contenedores como en blanco.

No da ninguna indicación de que lo que realmente está sucediendo es que ahora no puede acceder a las credenciales compartidas en caché. La solución en este escenario es restablecer las credenciales a través de la interfaz de usuario (Configuración-> Unidades compartidas) o deshabilitar el uso compartido de la unidad que se puede renombrar e ingresar la nueva contraseña.

Sería útil si docker-compose produjera un error en estas situaciones.

Supongo que el archivo run_web.sh está en el mismo directorio que su archivo docker-compose.yml . Entonces el comando debería ser command: /app/run_web.sh .

A menos que el Dockerfile (que no esté Dockerfile ) se encargue de colocar el archivo run_web.sh en la imagen de Docker.

También se topó con este problema y parece que los volúmenes locales no están montados cuando se usa docker-machine. Una solución para hackear es

  1. obtener el directorio de trabajo actual de la instancia de docker-machine ssh <name> pwd

  2. use una herramienta de línea de comando como rsync para copiar la carpeta al sistema remoto

    rsync -avzhe ssh --progress <name_of_folder> username@remote_ip:<result _of_pwd_from_1>.

El pwd predeterminado es / root, por lo que el comando anterior sería rsync -avzhe ssh --progress <name_of_folder> username@remote_ip:/root

NB: necesitaría proporcionar la contraseña para el sistema remoto. Puede crear uno rápidamente mediante ssh en el sistema remoto y crear una contraseña.

  1. cambie el punto de montaje del volumen en su archivo docker-compose.yml de .:/app a /root/<name_of_folder>:/app

  2. ejecutar docker-compose up -d

Nota: cuando los cambios se realizan localmente, no olvide volver a ejecutar rsync para enviar los cambios al sistema remoto.

No es perfecto pero funciona. Hay un problema en curso https://github.com/docker/machine/issues/179

Otro proyecto que intenta resolver esto incluye docker-rsync

Todas las demás respuestas fueron buenas por el momento, pero ahora (Docker Toolbox v18.09.3) todo funciona de fábrica. Solo necesita agregar una carpeta compartida en VirtualBox VM.

Docker Toolbox agrega automáticamente C:/Users como carpeta compartida /c/Users en la máquina Linux virtual (usando la función de carpetas compartidas de Virtual Box), por lo que si su archivo docker-compose.yml se encuentra en algún lugar debajo de esta ruta y monta los directorios de la máquina host solamente bajo este camino, todo debería funcionar de la caja.

Por ejemplo:

C:/Users/username/my-project/docker-compose.yml :

... volumes: - .:/app ...

El . la ruta se convertirá automáticamente en la ruta absoluta C:/Users/username/my-project y luego a /c/Users/username/my-project . Y así es exactamente como se ve esta ruta desde el punto de vista de la máquina virtual de Linux (puede verificarla: docker-machine ssh y luego ls /c/Users/username/my-project ). Entonces, el montaje final será /c/Users/username/my-project:/app .

Todo funciona de forma transparente para ti.

Pero esto no funciona si su ruta de montaje de host no está en la ruta C:/Users . Por ejemplo, si coloca el mismo docker-compose.yml en D:/dev/my-project .

Sin embargo, esto se puede solucionar fácilmente.

  1. Detenga la máquina virtual ( docker-machine stop ).

  2. Abra la GUI de Virtual Box, abra la Configuración de la máquina virtual denominada default , abra la sección Shared Folders y agregue la nueva carpeta compartida:

    • Ruta de la carpeta: D:/dev
    • Nombre de la carpeta: d/dev

    Presione OK dos veces y cierre Virtual Box GUI.

  3. Inicie la máquina virtual ( docker-machine start ).

Eso es todo. Todas las rutas de la máquina host en D:/dev deberían funcionar ahora en docker-compose.yml montajes docker-compose.yml .