Совместное использование FUSE FS, смонтированного внутри док-контейнера, через тома - PullRequest
Новая
       5

Совместное использование FUSE FS, смонтированного внутри док-контейнера, через тома

0 голосов
/ 05 декабря 2018

Я создал док-контейнер, в котором я смонтировал предохранитель S3QL FS.И это работает.

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

Для краткости я запускаюКонтейнер таким образом: 

docker run --rm -d -v /s3ql:/s3ql \
           --cap-add SYS_ADMIN --device /dev/fuse \
           --name myContainer \
                myS3qlIimage mount.s3ql swiftks://url:container /s3ql

docker exec myContainer ls /s3ql показывает фактическое содержимое S3QL, но /s3ql на хосте пуст.1014 *https://gitlab.com/Salokyn/docker-s3ql

Как вы думаете, возможно ли сделать эту работу?

1 Ответ

0 голосов
/ 05 декабря 2018

Обычно при запуске контейнера Docker он запускается в закрытом пространстве имен монтирования: это означает, что (a) файловые системы, установленные внутри контейнера, не будут видны на хосте, и (b) файловые системы, смонтированные на хостене будет виден внутри контейнера.

Вы можете изменить это поведение, используя флаг bind-пропаганду для опции --mount.Для этого флага доступно шесть значений:

  • shared: дополнительные монтирования исходного монтирования открыты для монтирования реплик, а субмонтирования монтирования реплик также распространяются наисходное монтирование.
  • slave: аналогично общему монтированию, но только в одном направлении.Если исходное монтирование предоставляет субмонтирование, монтирование реплики может видеть его.Однако, если для монтирования реплики используется подмонтирование, исходное монтирование не может его увидеть.
  • private: монтирование является частным.Субмонтирование в нем не доступно для монтирования реплики, а субмонтирование монтирования реплики не предоставляется оригинальному монтированию.
  • rshared: То же, что и совместно используемое, но распространение также распространяется на и сТочки монтирования, вложенные в любую из исходных точек монтирования или точек реплики.
  • rslave: То же самое, что и ведомое устройство, но распространение также распространяется на точки монтирования, вложенные в любую из исходных точек монтирования или точки монтирования реплики, и обратно.1023 *
  • rprivate: по умолчанию.То же самое, что и личное, что означает, что ни одна точка монтирования нигде в исходной точке или точке монтирования реплики не распространяется ни в одном из направлений.

Исходя из вашего вопроса, вы, вероятно, захотите параметр rshared, которыйпозволит монтировать внутри контейнера, чтобы быть видимым на хосте.Это означает, что ваша docker командная строка будет выглядеть примерно так: 

docker run --rm \
  --mount type=bind,source=/s3ql,target=/s3ql,bind-propagation=rshared \
  --cap-add SYS_ADMIN --device /dev/fuse --name myContainer \
  myS3qlIimage mount.s3ql swiftks://url:container /s3ql

Но здесь может быть вторая проблема: если для установки вашего предохранителя требуется постоянный процесс для работы, это не будет работать,потому что ваш контейнер собирается завершиться, как только команда mount завершит работу, принимая любые процессы с ней.В этом случае вам нужно будет организовать, чтобы контейнер зависал до тех пор, пока вам нужно активное монтирование: 

docker run -d \
  --mount type=bind,source=/s3ql,target=/s3ql,bind-propagation=rshared \
  --cap-add SYS_ADMIN --device /dev/fuse --name myContainer \
  myS3qlIimage sh -c 'mount.s3ql swiftks://url:container /s3ql; sleep inf'

(Это предполагает, что у вас есть версия команды sleep, которая поддерживаетаргумент inf для сна навсегда).

Также обратите внимание, что объединение --rm и -d не имеет никакого смысла: опция --rm реализована клиентом, и с помощью -d клиент завершает работу, пока контейнер продолжает работать, нет ничего, что могло бы обработать опцию --rm.

...