谁来执行这个转化工作?答案是Docker守护进程。也许大家早就理解这样一句 话:Docker容器实质上就是一个或者多个进程,而容器的父进程就是Docker守护进程。这样的,转化工作的执行就不难理解了:Docker守护进程 手握Docker镜像的json文件,为容器配置相应的环境,并真正运行Docker镜像所指定的进程,完成Docker容器的真正创建。
Docker容器运行起来之后,Docker镜像json文件就失去作用了。此时Docker镜像的绝大部分作用就是:为Docker容器提供一个文件系统的视角,供容器内部的进程访问文件资源。
再次回到上图,我们再来看看容器和镜像之间的一些特殊关系。首先,之前已经提及Docker镜像是分层管理的,管理Docker容器的时候,Docker镜像仍然是分层管理的。由于此时动态的容器中已经存在进程,进程就会对文件系统���角内的文件进行读写操作,因此,就会涉及一个问题:容器是否会篡改Docker镜像的内容?
答案自然是不会的。统一来讲,正如上图,所有的Docker镜像层对于容器来说,都是只读的,容器对于文件的写操作绝对不会作用在镜像中。
既然如此,实现的原理就很重要,究其根本:Docker守护进程会在Docker镜像的 最上层之上,再添加一个可读写层,容器所有的写操作都会作用到这一层中。而如果Docker容器需要写底层Docker镜像中的文件,那么此时就会涉及一 个叫Copy-on-Write的机制,即aufs等联合文件系统保证:首先将此文件从Docker镜像层中拷贝至最上层的可读写层,然后容器进程再对读 写层中的副本进行写操纵。对于容器进程来讲,它只能看到最上层的文件。
那最后我们再来说说:Docker容器的文件系统视角中,到底是不是存在一些内容,不是存储于Docker镜像中的?
这次的答案依旧是肯定的。
再次重申一点,Docker镜像中存储的都是一些静态文件。这些文件原则上应该和容器具体信息以及主机信息完全解藕。那么Docker容器中不存在Docker镜像中的内容主要有以下几点:
1. /proc以及/sys等虚拟文件系统的内容
2. 容器的hosts文件,hostname文件以及resolv.conf文件,这些事具体环境的信息,原则上的确不应该被打入镜像。
3. 容器的Volume路径,这部分的视角来源于从宿主机上挂载到容器内部的路径
4. 部分的设备文件
QA选集:问:为什么一个ubuntu:14.04镜像的镜像层的数量是4个,前三层的内容似乎有相同的,如etc?
孙宏亮:这一点,细心的大家肯定发现了。首先,虽然三层 都有,但是会存在两种情况,etc的子目录下有相同路径的文件,那么上层的会覆盖下层的文件;如果内部的文件路径不相同,那么都会存在,都会呈现给最上 层。[可别较真,说目录也是文件哈,意会]
问:关于docker安全性问题,对于安全是怎样处理的,如果我从hub下载镜像,能判别是否安全么2.层级之间的依赖会导致一个崩了整个docker 都崩了么?
孙宏亮:从流程上来讲,如果一切可控的话,我认为是安全的。但是依然会存在一些隐患,比如Dockerfile中基于的base images是否完全受信;镜像的传输过程是否受信;自己的private docker resgitry的安全级别达到什么样的层次,这些都有影响。
问:如何保证仅有的一个deamon的稳定性健壮性?
孙宏亮:这个问题首先需要知道docker daemon的稳定性在哪些方面,那种场景下比较差?的确,docker daemon存在弊病。比如,daemon和容器的耦合等,目前general来讲,docker daemon保证绝对的稳定应该还做不到。
问:生产环境中怎么用docker备份mysql数据?
孙宏亮:数据存储上docker,我目前的建议是:三思。举个简单的例子,官方的mysql镜像运行出来的 容器,密码是明文的,明文的密码存在于:docker inspect container_name, container.json文件中,容器的环境变量中,甚至在日志文件中都会存在,just think about it。当然也有办法解决,缓解这种情况。
问:如果是多层构建,中间的一个层做了升级或者bugfix,会潜在影响上层吧?
孙宏亮:这个bugfix会在上层有体现,但是使用效果是不会有影响的,还有之前的bug会永远留在下层,但是没有影响。
Docker安装应用(CentOS 6.5_x64)