blocks|key|2289919|text|您的帖子中有两个问题，让我按顺序进行讨论。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2289920|1)为什么从外部挂载+/etc/{hosts,hostname,resolv.conf}+文件？|offset|length|style|BOLD|CODE|2289921|我至少看到了一个原因。|2289922|想象一下，如果容器引擎简单地将这些文件写入容器的文件系统和，用户将决定将/etc挂载为卷(这是完全合法且非常有用的-挂载/etc将允许用户在docker+run的一个-v参数中为容器提供多个配置文件)：|2289923|2289924|首先，卷被装载到容器的/etc文件中，其内容由容器引擎更改(写入/etc).|unordered-list-item|2289925|中的特定文件|2289926|在启动这个容器之后，用户尝试用相同的/etc卷启动另一个容器(同样，这是完全合法和有用的--例如，用户扩展一些服务并在实例之间共享/etc中的配置文件)，然后...第二个容器覆盖卷上的hostname、hosts和resolv.conf文件，影响第一个容器。|2289927|现在考虑当使用绑定挂载而不是直接写入时会发生什么：|2289928|directory;|2289929|the将卷装载到容器的filesystem;|2289930|
|2289931|bind-mounts+|2289932|将/etc/{hosts,hostname,resolv.conf}从主机上的某个位置绑定装载到容器的filesystem；|2289933|bind-mounts隐藏卷上这些文件的原始版本(如果有)，从而保证卷上的文件在容器设置期间不会被修改，也不会传播到其他容器。|2289934|2289935|2289936|2)为什么我将+/dev/sda1+视为这些装载的来源？|2289937|检查findmnt(8)而不是df(1)|2289938|$+docker+run+-it+ubuntu
root@5a8ab4d6e716:/#+findmnt
TARGET+++++++++++++++++++++++++++SOURCE
...
%7C-/etc/resolv.conf+++++++++++++++/dev/sda1[/var/lib/docker/containers/5a8ab4d6e71691f279cbbcf5a295b5fa90fd138f10418c996ad7ea4440452816/resolv.conf]
%7C-/etc/hostname++++++++++++++++++/dev/sda1[/var/lib/docker/containers/5a8ab4d6e71691f279cbbcf5a295b5fa90fd138f10418c996ad7ea4440452816/hostname]
`-/etc/hosts+++++++++++++++++++++/dev/sda1[/var/lib/docker/containers/5a8ab4d6e71691f279cbbcf5a295b5fa90fd138f10418c996ad7ea4440452816/hosts]|code-block|syntax|javascript|2289939|实际上，这里的每一行输出都显示了三个字段(挂载目标/etc/hosts、挂载源/dev/sda1和FS根/var/lib/<...>/hosts)，而df(1)没有显示第三个字段。|2289940|根据man+procfs关于/proc/PID/mountinfo文件的一段话(它是实用程序挂载信息的来源)：|2289941|(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".|2289942|对于大多数挂载，FS根目录是/+(因为您挂载的是整个文件系统)，因此在查看df(1)输出时不会丢失太多信息。但是，对于特定文件的绑定挂载，情况并非如此。|2289943|entityMap^0|0|0|A|B|X|19|3|B|X|0|0|S|1|10|4|1O|4|1Y|A|2B|2|0|0|B|4|W|4|0|0|I|4|1T|4|2K|8|2T|5|2Z|B|0|0|0|0|0|0|1|X|0|0|0|0|0|7|8|9|I|A|8|9|0|2|A|F|5|0|0|P|A|13|9|1G|K|23|5|0|2|A|E|J|0|0|E|1|11|5|0^^$0|@$1|2|3|4|5|6|7|1T|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1U|8|@$D|1V|E|1W|F|G]|$D|1X|E|1Y|F|G]|$D|1Z|E|20|F|G]|$D|21|E|22|F|H]]|9|@]|A|$]]|$1|I|3|J|5|6|7|23|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|24|8|@$D|25|E|26|F|G]|$D|27|E|28|F|H]|$D|29|E|2A|F|H]|$D|2B|E|2C|F|H]|$D|2D|E|2E|F|H]]|9|@]|A|$]]|$1|M|3|-4|5|6|7|2F|8|@]|9|@]|A|$]]|$1|N|3|O|5|P|7|2G|8|@$D|2H|E|2I|F|H]|$D|2J|E|2K|F|H]]|9|@]|A|$]]|$1|Q|3|R|5|6|7|2L|8|@]|9|@]|A|$]]|$1|S|3|T|5|6|7|2M|8|@$D|2N|E|2O|F|H]|$D|2P|E|2Q|F|H]|$D|2R|E|2S|F|H]|$D|2T|E|2U|F|H]|$D|2V|E|2W|F|H]]|9|@]|A|$]]|$1|U|3|V|5|6|7|2X|8|@]|9|@]|A|$]]|$1|W|3|X|5|6|7|2Y|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|P|7|2Z|8|@]|9|@]|A|$]]|$1|10|3|11|5|6|7|30|8|@]|9|@]|A|$]]|$1|12|3|13|5|P|7|31|8|@]|9|@]|A|$]]|$1|14|3|15|5|P|7|32|8|@$D|33|E|34|F|H]]|9|@]|A|$]]|$1|16|3|17|5|P|7|35|8|@]|9|@]|A|$]]|$1|18|3|-4|5|6|7|36|8|@]|9|@]|A|$]]|$1|19|3|-4|5|6|7|37|8|@]|9|@]|A|$]]|$1|1A|3|1B|5|6|7|38|8|@$D|39|E|3A|F|G]|$D|3B|E|3C|F|G]|$D|3D|E|3E|F|G]|$D|3F|E|3G|F|H]]|9|@]|A|$]]|$1|1C|3|1D|5|6|7|3H|8|@$D|3I|E|3J|F|H]|$D|3K|E|3L|F|H]]|9|@]|A|$]]|$1|1E|3|1F|5|1G|7|3M|8|@]|9|@]|A|$1H|1I]]|$1|1J|3|1K|5|6|7|3N|8|@$D|3O|E|3P|F|H]|$D|3Q|E|3R|F|H]|$D|3S|E|3T|F|H]|$D|3U|E|3V|F|H]]|9|@]|A|$]]|$1|1L|3|1M|5|6|7|3W|8|@$D|3X|E|3Y|F|H]|$D|3Z|E|40|F|H]]|9|@]|A|$]]|$1|1N|3|1O|5|1G|7|41|8|@]|9|@]|A|$1H|1I]]|$1|1P|3|1Q|5|6|7|42|8|@$D|43|E|44|F|H]|$D|45|E|46|F|H]]|9|@]|A|$]]|$1|1R|3|-4|5|6|7|47|8|@]|9|@]|A|$]]]|1S|$]]

You have two questions in your post, let me cover them sequentially.

1) Why <code>/etc/{hosts,hostname,resolv.conf}</code> files are mounted from outside?

I see at least one reason for this.

Imagine what would happen if the container engine would simply write these files to the container's filesystem and the user would decide to mount <code>/etc</code> as a volume (which is perfectly legal and pretty useful - mounting <code>/etc</code> would allow the user to provide the container with multiple config files in one <code>-v</code> argument for <code>docker run</code>):

<ul>
<li>first, the volume is mounted to container's <code>/etc</code> directory;</li>
<li>then its content is changed by the container engine (a write to specific files in <code>/etc</code>).</li>
</ul>

After launching this container, the user tries to launch one more with the same <code>/etc</code> volume (again, this is perfectly legal and useful - e.g. the user scales up some service and shares config files in <code>/etc</code> among instances), and... The second container overwrites <code>hostname</code>, <code>hosts</code> and <code>resolv.conf</code> files on the volume, affecting the first container.

Now consider what happens when bind-mounting is used instead of direct writes:

<ul>
<li>the volume is mounted to container's <code>/etc</code> directory;</li>
<li>the container engine bind-mounts <code>/etc/{hosts,hostname,resolv.conf}</code> from somewhere on the host to the container's filesystem;</li>
<li>bind-mounts hide the original versions (if any) of these files on the volume, hence the guarantee that the files on the volume will not be modified during the container setup and will not be propagated to other containers.</li>
</ul>

2) Why I see <code>/dev/sda1</code> as the source of these mounts?

Check <code>findmnt(8)</code> instead of <code>df(1)</code>:

<pre><code>$ 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]
</code></pre>

Actually, each line of output here shows three fields (mount target <code>/etc/hosts</code>, mount source <code>/dev/sda1</code> and FS root <code>/var/lib/&lt;...&gt;/hosts</code>), and the third one is not shown by <code>df(1)</code>.

According to <code>man procfs</code> paragraph about <code>/proc/PID/mountinfo</code> file (which is the source of information about mounts for utilities):

<pre><code>(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".
</code></pre>

For most mounts, FS root is <code>/</code> (because you mount whole filesystem), so you don't loose too much information when you look at the <code>df(1)</code> output. However, this is not the case for bind-mounts of specific files.

I run a simple docker container with <code>sudo docker run -it ubuntu:latest /bin/bash</code>

When I examine mounted file system, with: <code>df -h</code>, one

<pre><code>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
....
</code></pre>

I fail to understand the last line, i.e. <code>/dev/sda1 -&gt; /etc/hosts</code>, when I run <code>df -h</code> on the host machine, I get the mount <code>/dev/sda1 -&gt; /</code>.

So <code>/dev/sda1</code> is actually my hard drive, why is it mounted to <code>/etc/hosts</code> on the container, and how come <code>/etc/hosts</code> on the container is a file with correct content.

Any explanation of what is going on here? how does this work?

What is the meaning of mounting /dev/sda1 to /etc/hosts in Docker container

文件系统

容器

Docker

我用sudo docker run -it ubuntu:latest /bin/bash运行了一个简单的docker容器当我使用df -h检查已挂载的文件系统时，Filesystem      Size  Used Avail Use% Mounted onoverlay          63G  4.3G   5...

问将/dev/sda1挂载到Docker容器中的/etc/hosts有什么意义
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问将/dev/sda1挂载到Docker容器中的/etc/hosts有什么意义EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问将/dev/sda1挂载到Docker容器中的/etc/hosts有什么意义
EN