我用sudo docker run -it ubuntu:latest /bin/bash
运行一个简单的Docker容器
当我检查挂载的文件系统时,带有: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
是具有正确内容的文件。
这里发生了什么解释吗?如何运作?
答案 0 :(得分:1)
您的帖子中有两个问题,让我依次介绍。
1)为什么/etc/{hosts,hostname,resolv.conf}
个文件是从外部装入的?
我至少知道原因之一。
想象一下,如果容器引擎将这些文件简单地写入容器的文件系统 ,并且用户决定将/etc
挂载为卷,那将会发生什么情况(这完全合法并且非常有用) -挂载/etc
将允许用户在-v
的一个docker run
参数中为容器提供多个配置文件:
/etc
目录; /etc
中的特定文件)。启动此容器后,用户尝试使用相同的/etc
卷再次启动一次(同样,这完全合法且有用-例如,用户扩展了一些服务并共享{{1}中的配置文件}),以及......第二个容器将覆盖卷上的/etc
,hostname
和hosts
文件,从而影响第一个容器。
现在考虑使用绑定安装而不是直接写入时会发生什么:
resolv.conf
目录; /etc
从主机上的某个位置绑定到容器的文件系统; 2)为什么我将/etc/{hosts,hostname,resolv.conf}
视为这些坐骑的来源?
检查/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
和FS根/dev/sda1
),以及第三个/var/lib/<...>/hosts
未显示。
根据有关df(1)
文件的man procfs
段落(这是有关实用程序安装的信息的来源):
/proc/PID/mountinfo
对于大多数挂载,FS根目录为(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".
(因为您挂载了整个文件系统),因此在查看/
输出时不会丢失太多信息。但是,特定文件的绑定安装不是这种情况。