O cliente do Docker no WSL cria problemas de caminho de volume

Question

Windows 10 compilação 15063.11, executando o Windows subsistema para Linux (WSL) Xenial 16.04.2 LTS.

Há um cliente docker em execução no WSL que se conecta ao daemon do Windows Hyper-V. Diversão.

O único problema do qual não consigo me livrar é o mapeamento de caminho entre o WSL e o daemon do Hyper-V para volumes - de arquivos compostos . Os arquivos compostos devem ser de plataforma cruzada - eles são todos relativos, e se eu começar apenas a alterar o compose.yml apenas para se adequar à minha monstruosidade do WSL, os serviços não serão iniciados em nenhum outro lugar, o que não é totalmente prático. / p>

Existe algo como export MSYS_NO_PATHCONV=1 que eu posso fazer para fazer a WSL parar de mutilar os caminhos antes que eles sejam enviados para o daemon?

Onde esse problema precisa ser resolvido? No daemon? Em compor? na WSL? onde posso contribuir?

Os mapeamentos de volume fora dos arquivos de composição funcionam maravilhosamente porque você pode especificá-los de maneira absoluta e no formato adequado ao transmiti-los ao cliente / daemon.

por exemplo, docker run -v c:/my/stuff/is/here:/vars/now/here magicImage de dentro do WSL funciona de forma fantástica. É apenas compor a obtenção de nomes de arquivos absolutos do WSL que, na verdade, não são nomes de arquivos, por exemplo, /mnt/c/my/stuff/isnt/here , porque no universo do Hyper-V do daemon, /mnt/c/ é um absurdo.

follow-up: entrou em contato com docker / compose . docker-compose chama os.path.abspath para resolver os caminhos absolutos dos recursos, por isso parece provável que o problema seja mais provável no uso de Microsoft / BashOnWindows .

    

Answer 1

Acho que a resposta já está nos caminhos absolutos e incorretos do Docker para volumes · Problema nº 1854 · Microsoft / BashOnWindows tópico no GitHub, mas estou postando aqui para os outros verem:

Existem duas soluções possíveis: links simbólicos e montagem de ligação. Ambos funcionam, mas uma ligação provavelmente é melhor, pois alguns serviços não usam links simbólicos.

aseering fornece os comandos em um comentário no tópico GitHub .

$ sudo mkdir /c
$ sudo mount --bind /mnt/c /c
$ cd /c/path/to/project
$ docker-compose ...

A única desvantagem de uma ligação é que ela dura apenas enquanto a instância (neste caso, o container) por causa da maneira como inicializamos os contêineres. Então, a ligação precisaria fazer parte da rotina de inicialização do contêiner.