Как правильно организовать разделяемый монтируемый раздел (shared mounting volumes) в docker?

Question

[youngmysteriouslight]

Есть директория с определённой структурой, не обязательно хранимая явно на хосте.
Есть два разных docker-образа.

Нужно, чтобы эта директория была подключена в одно место при создании контейнера первого образа и во второе — второго.
Нужно, чтобы отдельные поддиректории были доступны в хосте под другим путём, причём нельзя использовать ls -s.
Нужно, чтобы любые изменения в любой из этих трёх точек (в присоединённых в первом и втором контейнере, в директориях хоста, связанных с отдельными поддиректориями структуры).

Если бы не было нужды в доступе с хоста, я бы создал volume и затем примонтировал в два контейнера.

Пробовал сделать так: создаю директорию на хосте (скажем, /shared), монтирую как есть в два контейнера, затем на хосте монтирую

mount --bind /shared/<путь к поддиректории> <путь, по которому поддиректория должна быть доступна на хосте>

Проблема в том, что приходится хранить список всех mount-bind на случай перегрузки машины, и монтировать нельзя делать в обратном порядке (скажем, уже есть директория /project на хосте, а нужно положить в поддиректорию /shared/user/data/project, то нельзя сделать mount-bind сразу, нужно сначала mv /project /shared/user/data/project, а затем mount --bind /shared/user/data/project /project).
Ещё есть мнение, что прямое монтирование директории хоста в контейнер создаёт дыру в безопасности.

Вопрос: как бы правильнее организовать разделяемый монтируемый раздел, чтоб и безопасность не пострадала, и удобно было работать?

Answer 1

[Дмитрий]

Может задействовать еще одну сущность?
Скажем развернуть NFS сервер и монтировать его shared folder и к хосту, и к контейнерам.
Примеров использования nfs в сети достаточно..

Answer 2

[Георг Гаал]

1. Особого смысла в bind mount нет, т.к. именованный volume точно так же доступен через фс хоста в каталоге /var/lib/docker/volumes/
2. если очень хочется обеспечить порядок монтирования - оберните запуск контейнеров в systemd unit, создание и подключение точки монтирования mount --bind на хосте тоже в юнит и настройке между ними порядок запуска. Докер, к сожалению, сам по себе эту проблему не решает. И если уж на то пошло - а Вы точно уверены, что Вам нужен докер? В простых случаях chroot окружение решает проблему изоляцию, а в systemd завезли namespaces и изоляцию. И даже полноценные контейнер вроде nspawn, управляемые через machinectl