可能你立刻就能想到,这应该是一个关于MountNamespace的问题:容器里的应用进程理应‘看到”一套完全独立的文件系统°这样它就可以在自己的容器目录比如

Namespace跟其他Namespace的使用略有不同的地方:它对容器进程视图的改变—定要伴随着挂载操作才能生效。

执行chroot

这个挂载在容器根目录上用来为容器进程提供隔离后执行环境的文件系统’就是所谓的容器镜像。

dock

Namespace配置;设置指定的Cgroups参数;切换进程的根目录change

root

只是—个操作系统所包含的文件、配置和目录’并不包括操作系统内核。

在Llnux操作系统中这两部分是分开存放的’操作系统只有在开机启动时才会加载指定版本的内核镜像。

rootfS只是—个操作系统所包含的文件、配置和目录’并不包括操作

系统内核°在Llnux操作系统中’这两部分是分开存放的’操作系统只有在开机启动时才会加载指定版本的内核镜像°

正是由于rootfS的存在’容器才有了—个被反复强调至今的重要特:一致性

由于云端与本地服务器环境不同’因此应用的打包过程一直是使用PaaS时最麻烦的一个步骤。

’有了容器镜像rootfs之后,这个问题就被非常优雅地解决了。

由于root色里打包的不只是应用’而是整个操作系统的文件和目录,这就意味着’应用以及它运行所需要的所有依赖都被封装在了一起。

难道每开发—个应用或者升级现有应用’都要重复制作—次rootfS吗?

这样所有人都只需要维护相对于base

docker在镜像的设计中引人了层layer的概念。

也就是说,用户制作镜像的每一步操作都会生成—个层,也就是一个增量

用到了—种叫作UnionFSunlon∏lesystem’联合文件系统的能力。

它最主要的功能是将不司位置的下。

比如有两个C里’有a、b、x这3个文件并且x文件只有一份。

这就是合并的含义。

此外,如果你在A、B中生效

docker

3600这个所谓的‘镜像”’实际上就是一个Ubuntu操作系统的rootfs,它的内容是Ubuntu操作系统的所有文件和目录不过,

AuFS

5个镜像层是如何被联合挂载成这样—个完整的Ubuntu文件系统的呢

rowh

你要删除只读层里一个名为foo的文件那么这个删除操作实际上是在可读写层创建了—个名为

.wh.foo的文件。

而当我们使用完了这个修改过的容器之后,还可以使用

docker

push指令保存这个修改过的可读写层’并上传到DockerHub上供他人使用。

Init

结尾的层,夹在只读层和可读写层之间。

Init层是Docker项目单独生成的—个内部层’专门用来存放/etc/hosts、

/etc/resolvconf

但是用户往往需要在启动容器时写人一些指定的值比如hostname

docker

所以,Docker做法是在修改了这些文件之后以—个单独的层挂载出来。

而用户执

docker