Какая файловая система используется для монтирования тома при монтировании /var/run/docker.sock в контейнер? - PullRequest
Новая
       12

Какая файловая система используется для монтирования тома при монтировании /var/run/docker.sock в контейнер?

1 голос
/ 26 июня 2019

У меня есть контейнер, который содержит логику для координации развертывания микросервисов на хосте - назовем этот сервис deployer . Для этого я смонтировал файл /var/run/docker.sock с хоста в этот контейнер deployer .

Таким образом, при выполнении docker run hello-world в контейнере deployer , host запускает его. Эта система работает, как и ожидалось, за исключением одной вещи, в которой я сейчас не уверен, поскольку я столкнулся с неожиданным поведением.

При выполнении docker run -v "/path/to/src:/path/to/dest" hello-world на какую папку будет смотреть Docker? Я вижу две веские причины:

  • A) Монтируется /path/to/src из развертывателя в контейнер hello-world, так как это оболочка, которая выполняет команда.
  • B) Монтируется /path/to/src из источника в контейнер hello-world, так как docker.sock определяет контекст и команда запускается на хосте.

Что из этого верно? Более того, при использовании относительных путей (например, в docker-compose) какой путь будет использоваться?

Заранее спасибо

1 Ответ

1 голос
/ 26 июня 2019

Он всегда будет использовать файловую систему хоста.Невозможно напрямую смонтировать файловую систему одного контейнера в другой.

Например: 

host$ sudo docker run --rm -it -v /var/run/docker.sock:/var/run/docker.sock docker sh
0123456789ab# docker run -v /:/host --rm -it busybox sh
13579bdf0246# cat /host/etc/shadow

Последняя команда выведет зашифрованный файл паролей хоста, а не что-либо промежуточное.container.

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

Я почти уверен, что относительные пути в docker-compose.yml на самом деле не будут работать с этой настройкой (потому что вы не можете привязать объекты из промежуточного контейнера).Вам нужно будет смонтировать один и тот же контент в оба контейнера, чтобы один мог отправлять файлы другому.Использование именованных томов может быть полезным здесь (потому что имена томов на самом деле не зависят от путей к хостам);в зависимости от того, что именно вы делаете, может работать обходной путь docker create, а затем docker cp.

На уровне реализации существует только один демон Docker, и он работает на хосте.Вы можете опубликовать свой сокет в разных местах, но в конечном итоге этот демон получает запросы типа «создайте контейнер, который монтирует каталог хоста / x / y», и демон интерпретирует эти запросы в контексте хоста.Он не знает, что запрос поступил из другого контейнера (или, возможно, с другого хоста; но о проблемах безопасности см. Выше).

...