Como montar volumes locais na máquina docker

Estou tentando usar o docker-machine com o docker-compose. O arquivo docker-compose.yml tem definições da seguinte forma:

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

Ao executar o docker-compose up -d tudo vai bem até tentar executar o comando e um erro é produzido:

Não é possível iniciar o contêiner b58e2dfa503b696417c1c3f49e2714086d4e9999bd71915a53502cb6ef43936d: [8] Erro do sistema: exec: “./run_web.sh”: stat ./run_web.sh: nenhum arquivo ou diretório

Volumes locais não são montados na máquina remota. Qual é a estratégia recomendada para montar os volumes locais com o código do webapps?

Também corri para este problema e parece que os volumes locais não são montados ao usar o docker-machine. Uma solução de hack é

  1. obter o diretório de trabalho atual da instância docker-machine ssh pwd

  2. usar uma ferramenta de linha de comando como o rsync para copiar a pasta para o sistema remoto

     rsync -avzhe ssh --progress  username@remote_ip:. 

O pwd padrão é / root, então o comando acima seria rsync -avzhe ssh --progress username@remote_ip:/root

NB: você precisaria fornecer a senha para o sistema remoto. Você pode criar rapidamente um por ssh no sistema remoto e criar uma senha.

  1. altere o ponto de assembly do volume no arquivo docker-compose.yml de .:/app para /root/:/app

  2. executar docker-compose up -d

NB quando as alterações são feitas localmente, não se esqueça de reexecutar o rsync para empurrar as alterações para o sistema remoto.

Não é perfeito, mas funciona. Um problema está em andamento https://github.com/docker/machine/issues/179

Outro projeto que tenta resolver isso inclui o docker-rsync

Docker-machine automounts o diretório de usuários … link Mas às vezes isso não é suficiente.

Eu não sei sobre o docker 1.6, mas em 1.8 você pode adicionar uma assembly adicional ao docker-machine

Adicionar ponto de assembly da máquina virtual (parte 1)

CLI : (funciona apenas quando a máquina está parada)

VBoxManage sharedfolder add --name --hostpath --automount

Então, um exemplo no windows seria

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

GUI : (não requer que a máquina seja parada)

  1. Inicie o “Oracle VM VirtualBox Manager”
  2. Clique com o direito em (padrão)
  3. Configurações…
  4. Pastas partilhadas
  5. A Pasta + Ícone à Direita (Adicionar Compartilhamento)
  6. Caminho da pasta: (e 🙂
  7. Nome da pasta: (e)
  8. Verifique em “Auto-mount” e “Make Permanent” (Leia somente se você quiser …) (A assembly automática é uma espécie de inútil atualmente …)

Montagem no boot2docker (parte 2)

Montar manualmente no boot2docker :

  1. Existem várias maneiras de fazer login, usar “Mostrar” em “Oracle VM VirtualBox Manager” ou ssh / putty na janela de encaixe pelo endereço IP do docker-machine ip default , etc …
  2. sudo mkdir -p
  3. sudo mount -t vboxsf -o defaults,uid=`id -u docker`,gid=`id -g docker`

Mas isso só é bom até você reiniciar a máquina, e então a assembly é perdida …

Adicionando um automount ao boot2docker :

Enquanto logado na máquina

  1. Editar / criar (como root) /mnt/sda1/var/lib/boot2docker/bootlocal.sh , sda1 pode ser diferente para você …
  2. Adicionar

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

Com essas alterações, você deve ter um novo ponto de assembly. Este é um dos poucos arquivos que eu encontrei que é chamado na boot e é persistente. Até que haja uma solução melhor, isso deve funcionar.


Método antigo: Menos recomendado , mas deixado como alternativa

  • Editar (como root) /mnt/sda1/var/lib/boot2docker/profile , sda1 pode ser diferente para você …
  • Adicionar

     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   

Como último recurso , você pode pegar a alternativa um pouco mais tediosa, e você pode apenas modificar a imagem de boot.

  • git -c core.autocrlf=false clone https://github.com/boot2docker/boot2docker.git
  • cd boot2docker
  • git -c core.autocrlf=false checkout v1.8.1 #ou sua versão apropriada
  • Editar rootfs/etc/rc.d/automount-shares
  • Adicione a linha try_mount_share direita antes de fi no final. Por exemplo

     try_mount_share /ee 

    Apenas certifique-se de não configurar o para qualquer coisa que o sistema operacional precise, como / bin, etc …

  • docker build -t boot2docker . # Isso levará cerca de uma hora na primeira vez 🙁
  • docker run --rm boot2docker > boot2docker.iso
  • Faça o backup do antigo boot2docker.iso e copie o novo em seu lugar, em ~ / .docker / machine / machines /

Isso funciona, é apenas longo e complicado

versão do docker 1.8.1, versão do docker-machine 0.4.0

No momento, eu não consigo ver nenhuma maneira de montar volumes em máquinas, então a abordagem agora seria de alguma forma copiar ou sincronizar os arquivos que você precisa na máquina.

Há conversas sobre como resolver esse problema no repository github da máquina do docker. Alguém fez uma solicitação pull implementando o scp no docker-machine e ele já está mesclado no master, então é muito provável que o próximo lançamento o inclua.

Como ele ainda não foi lançado, recomendamos que, se você tiver seu código hospedado no github, apenas clone seu repository antes de executar o aplicativo.

 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 

Atualização: Procurando mais Eu descobri que o recurso já está disponível nos binários mais recentes , quando você os conseguir, você poderá copiar seu projeto local executando um comando como este:

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

Sendo esta a forma geral:

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

Então você pode copiar arquivos de, para e entre máquinas.

Felicidades 1

Se você escolher a opção rsync com docker-machine, poderá combiná-la com o comando docker-machine ssh do docker-machine ssh como este:

rsync -rvz --rsh='docker-machine ssh ' --progress :

Ele usa este formato de comando do rsync, deixando o HOST branco:

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

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

Desde outubro de 2017, há um novo comando para docker-machine que faz o truque, mas verifique se não há nada no diretório antes de executá-lo, caso contrário, ele pode se perder:

docker-machine mount :

Consulte os documentos para mais informações: https://docs.docker.com/machine/reference/mount/

PR com a mudança: https://github.com/docker/machine/pull/4018

Eu suponho que o arquivo run_web.sh esteja no mesmo diretório que o seu arquivo docker-compose.yml . Então o comando deve ser o command: /app/run_web.sh .

A menos que o Dockerfile (que você não está divulgando) cuide de colocar o arquivo run_web.sh na imagem do Docker.

Depois de resumir as postagens aqui, anexe o script atualizado, para criar um ponto de assembly e um ponto de assembly adicionais para o host quando o Virtualbox for reiniciado. O ambiente de trabalho breve como abaixo: – Windows 7 – docker-machine.exe versão 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' 

Finalmente descobri como atualizar o Windows Docker Toolbox para a v1.12.5 e manter meus volumes funcionando adicionando uma pasta compartilhada no gerenciador do Oracle VM VirtualBox e desabilitando a conversão de caminho. Se você tem o Windows 10+, é melhor usar o Docker mais recente para o Windows.

1º o upgrade Dor:

  1. Desinstale o VirtualBox primeiro.
    • Sim, isso pode quebrar coisas em outras ferramentas, como o Android Studio. Obrigado Docker 🙁
  2. Instale a nova versão do Docker Toolbox.

Banco de dados Redis Exemplo: redis: image: redis:alpine container_name: redis ports: - "6379" volumes: - "/var/db/redis:/data:rw"

No Docker Quickstart Terminal ….

  1. executar o docker-machine stop default – certifique-se de que a VM esteja em execução

No Oracle VM VirtualBox Manager …

  1. Adicionado uma pasta compartilhada na VM via default ou linha de comando
    • D:\Projects\MyProject\db => /var/db

Em docker-compose.yml

  1. Volume de redis mapeado como: "/var/db/redis:/data:rw"

No Docker Quickstart Terminal ….

  1. Configure COMPOSE_CONVERT_WINDOWS_PATHS=0 (para a versão do Toolbox> = 1.9.0)
  2. execute o docker-machine start default para reiniciar a VM.
  3. cd D:\Projects\MyProject\
  4. docker-compose up deve funcionar agora.

Agora cria o database redis em D:\Projects\MyProject\db\redis\dump.rdb

Por que evitar caminhos de host relativos?

Evitei caminhos de host relativos para o Windows Toolbox, pois eles podem introduzir caracteres ‘\’ inválidos. Não é tão bom quanto usar caminhos relativos ao docker-compose.yml mas pelo menos meus colegas desenvolvedores podem fazê-lo facilmente, mesmo que a pasta do projeto esteja em outro lugar sem ter que hackear o arquivo docker-compose.yml (ruim para SCM).

Edição original

FYI … Aqui está o erro original que recebi quando usei caminhos relativos limpos e relativos que costumavam funcionar bem para versões mais antigas. Meu mapeamento de volume costumava ser apenas "./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

Isso quebra por dois motivos.

  1. Não pode acessar a unidade D:
  2. Caminhos de volume não podem include \ caracteres
    • docker-compose adiciona-os e, em seguida, culpa você por isso !!
    • Use COMPOSE_CONVERT_WINDOWS_PATHS=0 para parar este absurdo.

Eu recomendo documentar seu mapeamento de pasta compartilhada VM adicional em seu arquivo docker-compose.yml pois você pode precisar desinstalar o VirtualBox novamente e redefinir a pasta compartilhada e, de qualquer maneira, seus colegas devs irão amá-lo por isso.

Estou usando o docker-machine 0.12.2 com a unidade virtualbox em minha máquina local. Descobri que existe um diretório /hosthome/$(user name) de onde você tem access aos arquivos locais.

Pensei em mencionar que usei o 18.03.1-ce-win65 (17513) no Windows 10 e percebi que, se você compartilhou anteriormente uma unidade e armazenou as credenciais em cache, depois de alterar sua senha, a janela de encaixe começará a ter os volumes montados em contêineres como em branco.

Ele não dá nenhuma indicação de que o que realmente está acontecendo é que agora ele está falhando ao acessar o compartilhamento com as credenciais armazenadas em cache antigas. A solução neste cenário é redefinir as credenciais por meio da interface do usuário (Configurações-> Unidades compartilhadas) ou desativar, em seguida, renomear o compartilhamento de unidade e inserir a nova senha.

Seria útil se o docker-compose desse um erro nessas situações.

Isso parece funcionar para mim

volumes: - $PWD/drupal-prod-files:/drupal-prod-files