Невозможно привязать том хоста в docker-compose для Docker Windows - PullRequest
Новая
       36

Невозможно привязать том хоста в docker-compose для Docker Windows

0 голосов
/ 03 февраля 2019

Я пытался решить эту проблему целую вечность, но кажется, что Docker для Windows только недавно смог успешно привязать тома с хоста Windows к его контейнерам Docker.Тем не менее, я не могу заставить работать ту же функциональность через docker-compose.У кого-нибудь есть какая-либо определенная информация, касающаяся этого, или мысли о том, как я могу заставить это работать?

Я прочитал довольно много проблем с GitHub, связанных с монтированием тома Windows, но кажется, что большинствоответы связаны с получением Docker для монтирования тома.У меня нет проблем, просто docker-compose.

Чтобы проиллюстрировать мою проблему, следующая команда выдает мне следующий вывод, который является правильным содержимым моего локального каталога, смонтированного в Docker: 

$ docker run --rm -v c:/Users/synta/go/src/github.com/syntaqx/example:/go/src/github.com/syntaqx/example alpine ls /go/src/github.com/syntaqx/example
LICENSE
README.md
cmd
docker-compose.yml
docs
go.mod
go.sum
example.go

Однако, учитывая ту же реализацию в docker-compose.yml: 

version: '3.6'
services:
  example:
    build:
      context: .
      dockerfile: Dockerfile
    volumes:
      - /c/Users/syntaqx/go/src/github.com/syntaqx/example:/go/src/github.com/syntaqx/example

И следующее Dockerfile: 

ARG GO_VERSION=1.11
ARG ALPINE_VERSION=3.8

FROM golang:${GO_VERSION}-alpine${ALPINE_VERSION} AS builder

WORKDIR /go/src/github.com/syntaqx/example
RUN ls -alh

ENTRYPOINT ["go"]

Мне буквально не дают вывода(ls -alh дает . и .., давая мне знать, что каталог определенно существует через WORKDIR, но не заполняется из привязки): 

$ docker-compose up -d --build
Building example
Step 1/6 : ARG GO_VERSION=1.11
Step 2/6 : ARG ALPINE_VERSION=3.8
Step 3/6 : FROM golang:${GO_VERSION}-alpine${ALPINE_VERSION} AS builder
 ---> be1230a1b343
Step 4/6 : WORKDIR /go/src/github.com/syntaqx/example
 ---> Using cache
 ---> a0ccb401a86a
Step 5/6 : RUN ls /go/src/github.com/syntaqx/example
 ---> Running in 0cd52d44a637
Removing intermediate container 0cd52d44a637
 ---> 4f362f738e49
Step 6/6 : ENTRYPOINT ["go"]
 ---> Running in 5d7a1e841bfe
Removing intermediate container 5d7a1e841bfe
 ---> 9da9cfcf372a

...

Возможно, я упускаю что-то очевидноездесь, но я пробовал дюжину способов выражения тома PATH (., C:\, /c/, ///c), причем относительные пути в Docker Windows явно сильно нарушены, а другие пути не изменилисьрезультат.

Также очень жаль, если это дубликат, но из того, что я видел, большинство других вопросов очень конкретно пытаются смонтировать тома хоста в Docker, точка.Или проблема с относительными путями, которые я с удовольствием пока оставлю в стороне.Повторяю, все это работает хорошо для меня, как показано в моем примере, просто docker-compose кажется сломанным.

Надеюсь, один из вас, ребята, может помочь мне!Чувствую себя очень глубоко здесь.

Версия

about docker

1 Ответ

0 голосов
/ 03 февраля 2019

Какой это был долгий путь.

Но я кое-что узнал: у меня действительно было фундаментальное недопонимание того, как монтируются тома в Docker.К моему удивлению, все, включая относительные пути томов, работают должным образом.

Фундаментальное недоразумение, которое я имел для монтирований томов, заключается в том, что они недоступны на этапах сборки , но монтирование подключенодо конечного контейнера.Docker налагает это требование, так как без него сборки не будут повторяться.

Таким образом, в приведенном выше сценарии использования единственная разница (хотя и не очевидная, пока я это не понял) между Dockerfile и *Команда 1010 * состоит в том, что мой Dockerfile активно строит контейнер и пытается выполнить команды, где docker run только запускает команду на предварительно скомпилированном alpine.

Итак, возможно ли это?делать то, что я делал? Сортировка

Я столкнулся с парой решений для сыра, которые используют шаблон цепочки decorator-ish entrypoint.sh, позволяющий объединить несколько выходов Dockerfile build в их окончательный контейнер, икогда он запускается, выполняет цепочечные команды до заданного CMD.Проще говоря, у вас есть куча докер-файлов, которые заканчиваются ENTRYPOINT ["entrypoint.sh"], а затем наметите шаги, которые вы ранее использовали RUN для:

  • ls.dockerfile
  • mod.dockerfile
  • final.dockerfile 
#!/bin/sh
set -eu

until /go/src/github.com/syntaqx/example && go mod download
do
    echo "Waiting for mount..."
done

sh -c "go $*"

Затем вы можете использовать каждую команду вставки файла dockerfile поверх последней.

Примечание: Я не использовал это один раз, как я опишу ниже, так что эта оболочка может не работать, но я подумал, что это крутая реализация, поэтому я хотел кивнуть.

Однако для моего случая использования все это было очень ненужным.Зная, почему команды терпят неудачу, я могу просто отложить команды RUN до финального ENTRYPOINT, создать единственное число entrypoint.sh, а затем запустить их в порядке, который я хотел во время сборки.Мне не выгодно кэширование зависимостей таким способом, но оно мне также не нужно для этого конкретного случая использования.

Спасибо за чтение, и я надеюсь, что вы тоже кое-что узнали!

...