Dockerfile、Docker镜像和Docker容器的关系

来源:互联网 发布:sql update 数据 编辑:程序博客网 时间:2024/03/29 17:50

Dockerfile 是软件的原材料,Docker 镜像是软件的交付品,而  Docker 容器则可以认为是软件的运行态。从应用软件的角度来看,Dockerfile、Docker 镜像与 Docker  容器分别代表软件的三个不同阶段,Dockerfile 面向开发,Docker 镜像成为交付标准,Docker  容器则涉及部署与运维,三者缺一不可,合力充当 Docker 体系的基石。

简单来讲,Dockerfile构建出Docker镜像,通过Docker镜像运行Docker容器。

我们可以从Docker容器的角度,来反推三者的关系。首先可以来看下图:


 

我们假设这个容器的镜像通过以下Dockerfile构建而得:

FROM ubuntu:14.04  ADD run.sh /  VOLUME /data  CMD ["./run.sh"]  

2.1 Dockerfile与Docker镜像

首先,我们结合上图来看看Dockerfile与Docker镜像之间的关系。

FROM ubuntu:14.04:设置基础镜像,此时会使用基础镜像 ubuntu:14.04 的所有镜像层,为简单起见,图中将其作为一个整体展示。

ADD run.sh /:将 Dockerfile 所在目录的文件 run.sh 加至镜像的根目录,此时新一层的镜像只有一项内容,即根目录下的 run.sh。

VOLUME /data:设定镜像的 VOLUME,此 VOLUME  在容器内部的路径为 /data。需要注意的是,此时并未在新一层的镜像中添加任何文件,即构建出的磁层镜像中文件为空,但更新了镜像的 json  文件,以便通过此镜像启动容器时获取这方面的信息。

CMD ["./run.sh"]:设置镜像的默认执行入口,此命令同样不会在新建镜像中添加任何文件,仅仅在上一层镜像 json 文件的基础上更新新建镜像的 json 文件。

因此,通过以上分析,以上的Dockerfile可以构建出一个新的镜像,包含4个镜像层,每一条命令会和一个镜像层对应,镜像之间会存在父子关系。图中很清楚的表明了这些关系。

2.2 Docker镜像与Docker容器的关系

Docker镜像是Docker容器运行的基础,没有Docker镜像,就不可能有Docker容器,这也是Docker的设计原则之一。

可以理解的是:Docker镜像毕竟是镜像,属于静态的内容;而Docker容器就不一样了,容器属于动态的内容。动态的内容,大家很容易联想到进程,内存,CPU等之类的东西。的确,Docker容器作为动态的内容,都会包含这些。

为了便于理解,大家可以把Docker容器,理解为一个或多个运行进程,而这些运行进程将占有相应的内存,相应的CPU计算资源,相应的虚拟网络设备以及相应的文件系统资源。而Docker容器所占用的文件系统资源,则通过Docker镜像的镜像层文件来提供。

那么作为静态的镜像,如何才有能力转化为一个动态的Docker容器呢?此时,我们可以想象:第一,转化的依据是什么;第二,由谁来执行这个转化操作。

其实,转化的依据是每个镜像的json文件,Docker可以通过解析Docker镜像的json的文件,获知应该在这个镜像之上运行什么样的进程,应该为进程配置怎么样的环境变量,此时也就实现了静态向动态的转变。

谁来执行这个转化工作?答案是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会永远留在下层,但是没有影响。(责编/魏伟)

0 0