Что означает монтирование / dev / sda1 в / etc / hosts в контейнере Docker - PullRequest
Новая
       42

Что означает монтирование / dev / sda1 в / etc / hosts в контейнере Docker

0 голосов
/ 13 июня 2019

Я запускаю простой контейнер докера с sudo docker run -it ubuntu:latest /bin/bash

Когда я проверяю смонтированную файловую систему, с: df -h, один 

Filesystem      Size  Used Avail Use% Mounted on
overlay          63G  4.3G   56G   8% /
tmpfs            64M     0   64M   0% /dev
tmpfs          1000M     0 1000M   0% /sys/fs/cgroup
/dev/sda1        63G  4.3G   56G   8% /etc/hosts
....

Мне не удается понять последнюю строку, т. Е. /dev/sda1 -> /etc/hosts, когда я запускаю df -h на хост-компьютере, я получаю монтирование /dev/sda1 -> /.

Так что /dev/sda1 на самом деле мой жесткий диск, почему он установлен на /etc/hosts на контейнере, и почему /etc/hosts на контейнере - это файл с правильным содержимым.

Любое объяснение того, что здесь происходит? как это работает?

1 Ответ

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

У вас есть два вопроса в вашем посте, позвольте мне обсудить их последовательно.

1) Почему /etc/{hosts,hostname,resolv.conf} файлы монтируются извне?

Я вижу нахотя бы одна причина для этого.

Представьте себе, что произойдет, если механизм контейнера просто запишет эти файлы в файловую систему контейнера и , когда пользователь решит смонтировать /etc как том (которыйсовершенно легально и довольно полезно - монтирование /etc позволит пользователю предоставить контейнеру несколько файлов конфигурации в одном аргументе -v для docker run):

  • во-первых, том смонтированв каталог /etc контейнера;
  • , затем его содержимое изменяется механизмом контейнера (запись в определенные файлы в /etc).

После запуска этого контейнера пользовательпытается запустить еще один с тем же томом /etc (опять же, это совершенно законно и полезно - например, пользователь масштабирует некоторые службы и делится файлами конфигурации в /etc среди экземпляров), и ... Второйконтейнер перезаписывает файлы тома hostname, hosts и resolv.conf, влияющие на первый контейнер.

Теперь рассмотрим, что происходит, если вместо прямой записи используется привязка:

  • том смонтирован в каталог /etc контейнера;
  • bind-mount движка контейнера * откуда-то с хоста в файловую систему контейнера;
  • bind-mounts скрыть исходные версии (если таковые имеются) этих файлов на томе, поэтому мы гарантируем, что файлы на томе не будут изменены во время установки контейнера и не будут распространены на другие контейнеры.

2) Почему я вижу /dev/sda1 в качестве источника этих креплений?

Проверьте findmnt(8) вместо df(1): 

$ docker run -it ubuntu
root@5a8ab4d6e716:/# findmnt
TARGET                           SOURCE
...
|-/etc/resolv.conf               /dev/sda1[/var/lib/docker/containers/5a8ab4d6e71691f279cbbcf5a295b5fa90fd138f10418c996ad7ea4440452816/resolv.conf]
|-/etc/hostname                  /dev/sda1[/var/lib/docker/containers/5a8ab4d6e71691f279cbbcf5a295b5fa90fd138f10418c996ad7ea4440452816/hostname]
`-/etc/hosts                     /dev/sda1[/var/lib/docker/containers/5a8ab4d6e71691f279cbbcf5a295b5fa90fd138f10418c996ad7ea4440452816/hosts]

Фактически, каждая строка вывода здесь показывает три поля (цель монтирования /etc/hosts, источник монтирования /dev/sda1 и корневой каталог FS /var/lib/<...>/hosts), а третья строка не отображается df(1).

Согласно man procfs абзацу о /proc/PID/mountinfo файле (which является источником информации о монтировании для утилит): 

(4)  root: the pathname of the directory in the filesystem which forms the root of this mount.
(5)  mount point: the pathname of the mount point relative to the process's root directory.
...
(10) mount source: filesystem-specific information or "none".

Для большинства монтирований корневой каталог FS равен / (потому что вы монтируете всю файловую систему), поэтому вы не теряете слишком много информации, когда выпосмотрите на вывод df(1).Однако это не относится к привязке определенных файлов.

...