Невозможно выставить общий объем плавкого предохранителя в контейнер Docker
Я пытаюсь предоставить моему контейнеру докеров объем зашифрованной файловой системы для внутреннего использования.
Идея заключается в том, что контейнер будет записывать в том как обычно, но на самом деле хост будет шифровать данные перед их записью в файловую систему.
Я пытаюсь использовать EncFS - он хорошо работает на хосте, например:
encfs/encrypted/visible
Я могу писать файлы в /visible, и они зашифровываются.
Однако при попытке запустить контейнер с/видимым в качестве тома, например:
docker run -i -t --привилегированный -v/visible:/myvolume imagename bash
Я получаю том в контейнере, но он находится в исходной/зашифрованной папке, а не через EncFS. Если я отключу EncFS из /visible, я могу увидеть файлы, написанные контейнером. Излишне говорить/зашифровано пусто.
Есть ли способ, чтобы докеры монтировали том через EncFS, а не записывали напрямую в папку?
Напротив, докер работает отлично, когда я использую NFS mount в качестве тома. Он записывает сетевое устройство, а не в локальную папку, на которой я смонтировал устройство.
Спасибо
Ответы
Ответ 1
Я не могу дублировать вашу проблему локально. Если я попытаюсь открыть файловую систему encfs в качестве тома Docker, я получаю сообщение об ошибке, пытающееся запустить контейнер:
FATA[0003] Error response from daemon: Cannot start container <cid>:
setup mount namespace stat /visible: permission denied
Итак, возможно, у вас что-то другое происходит. В любом случае, это то, что решило мою проблему:
По умолчанию FUSE разрешает только пользователю, установившему файловую систему, доступ к этой файловой системе. Когда вы запускаете контейнер Docker, этот контейнер изначально запускается как root.
Вы можете использовать параметры монтирования allow_root или allow_other при монтировании файловой системы FUSE. Например:
$ encfs -o allow_root /encrypted /other
Здесь allow_root разрешает пользователю root иметь доступ к точке монтирования, тогда как allow_other разрешает любому иметь доступ к точке монтирования (при условии, что разрешения Unix в каталоге позволяют им получить доступ).
Если я смонтирован с помощью encfs filesytem с помощью allow_root, я могу затем разоблачить эту файловую систему как топор Docker, и содержимое этой файловой системы будет правильно видно изнутри контейнера.
Ответ 2
Это определенно потому, что вы запустили демона докеров, прежде чем хост смонтировал точку монтирования. В этом случае индекс inode для имени каталога все еще указывает на локальный диск hosts:
ls -i /mounts/
1048579 s3-data-mnt
то если вы монтируете с помощью демона плавкого предохранителя, например s3fs:
/usr/local/bin/s3fs -o rw -o allow_other -o iam_role=ecsInstanceRole /mounts/s3-data-mnt
ls -i
1 s3-data-mnt
Моя догадка заключается в том, что докер выполняет некоторую загрузку имен каталогов в inodes (кто-то, у кого есть больше знаний об этом, чем может заполнить этот пробел).
Ваш комментарий верен. Если вы просто перезагрузите докеры после завершения монтажа, ваш том будет правильно передан от хоста к вашим контейнерам. (Или вы можете просто задержать запуск докера до тех пор, пока все ваши крепления не будут завершены)
Что интересно (но теперь делает все от меня зависящее) заключается в том, что после выхода из контейнера и снятия монтирования точки монтирования на хосте все мои записи из контейнера в общий том волшебным образом появлялись (они сохранялись на inode на локальном диске хост-компьютеров):
[[email protected] s3-data-mnt]# echo foo > bar
[[email protected] s3-data-mnt]# ls /mounts/s3-data-mnt
total 6
1 drwxrwxrwx 1 root root 0 Jan 1 1970 .
4 dr-xr-xr-x 28 root root 4096 Sep 16 17:06 ..
1 -rw-r--r-- 1 root root 4 Sep 16 17:11 bar
[[email protected] s3-data-mnt]# docker run -ti -v /mounts/s3-data-mnt:/s3-data busybox /bin/bash
[email protected]:/mounts/s3-data# ls -als
total 8
4 drwxr-xr-x 3 root root 4096 Sep 16 16:05 .
4 drwxr-xr-x 12 root root 4096 Sep 16 16:45 ..
[email protected]:/s3-data# echo baz > beef
[email protected]:/s3-data# ls -als
total 9
4 drwxr-xr-x 3 root root 4096 Sep 16 16:05 .
4 drwxr-xr-x 12 root root 4096 Sep 16 16:45 ..
1 -rw-r--r-- 1 root root 4 Sep 16 17:11 beef
[email protected]:/s3-data# exit
exit
[[email protected] s3-data-mnt]# ls /mounts/s3-data-mnt
total 6
1 drwxrwxrwx 1 root root 0 Jan 1 1970 .
4 dr-xr-xr-x 28 root root 4096 Sep 16 17:06 ..
1 -rw-r--r-- 1 root root 4 Sep 16 17:11 bar
[[email protected] /]# umount -l s3-data-mnt
[[email protected] /]# ls -als
[[email protected] /]# ls -als /s3-stn-jira-data-mnt/
total 8
4 drwxr-xr-x 2 root root 4096 Sep 16 17:28 .
4 dr-xr-xr-x 28 root root 4096 Sep 16 17:06 ..
1 -rw-r--r-- 1 root root 4 Sep 16 17:11 bar
Ответ 3
Возможно, вы сможете обойти это, обернув вызов монтирования в nsenter, чтобы смонтировать его в том же пространстве имен монтирования Linux, что и демон докеров, например.
nsenter -t "$PID_OF_DOCKER_DAEMON" encfs ...
Вопрос в том, выживет ли этот подход при перезапуске демона.; -)
