代码改变世界

docker进程分析

2018-11-03 10:11  tlnshuju  阅读(1708)  评论(0编辑  收藏  举报
版权声明:本文为博主原创文章,未经博主同意不得转载。 https://blog.csdn.net/TM6zNf87MDG7Bo/article/details/80970541
序言

     闷热。无风。。。   

 

    非常久没写技术文章,所以今天分析一下docker相关的进程。

容器相关的进程

    安装容器的时候。一句话就够了,yum -y install docker-ce,前提是配置好docker的yum源,可是有的时候配置好了源,总是会发现timeout,呵呵哒。。

。尝试下阿里云的yum源。

640?wx_fmt=png

    安装完毕docker之后,就会发现如上的文件。除去了相关的帮助文档,在当中能够看到,分为各种各样的二进制程序,docker表示为docker的client。一个命令行程序的使用。dockerd主要是服务端程序,在默认的情况下。client发送的请求都是由dockerd接收。而dockerd则是一个restfull的api接口;docker-containerd能够看出来包含三部分。一部分是client名称为ctr,一个是containerd用来提供grpc的接口,主要用来进行容器的管理,镜像的管理。存储和网络的管理。一个是containerd-shim,主要是用来执行容器的进程;而docker-runc则是容器的执行时。docker-proxy主要是来实现网络转发功能,docker-init看名字是初始化的意思,应该是初始化网络,生成相关的文件。


    在安装完毕之后,启动docker服务例如以下:

640?</p><p>wx_fmt=png

    启动完毕之后。就看到生成文件,执行时文件,而且生成了一个桥接的网络接口。

640?wx_fmt=png

    容器的根文件夹主要用来存放一些镜像,网络配置情况,编译image的缓存。执行时环境,挂载的卷等元数据信息。

    在没有启动容器的时候。进程信息例如以下所看到的:

640?wx_fmt=png

    执行一个容器之后,进程信息例如以下所看到的:

640?</p><p>wx_fmt=png

    进程与线程:

640?</p><p>wx_fmt=png

    从进程的id能够看出来。dockerd生成了docker-containerd,docker-containerd生成了docker-containerd-shim。那么docker-runc去哪里了。


    1、 docker-runc是容器的执行时,专门用来做容器的创建,启动,停止,删除操作,当每次执行完毕之后,就会退出。容器的执行时已经成为标准,在docker-ce里面使用的runc。而在原来的版本号中使用的lxc,其它的版本号还有rkt等。

    2、 docker-containerd-shim主要是来负责容器的执行,而且用来向docker-containerd来汇报容器的状态。从而容器的状态数据不用存放在内存中。而每一个容器都会使用一个docker-containerd-shim的进程来进行管理。


    3、 docker-containerd主要是用来负责容器生命周期的管理,镜像,存储,网络的管理。这个开放了一个grpc的接口。从而能够适配非常多平台,上层能够直接调用。而dockerd则是一个详细的实现,其它还有lxd等。


    4、 dockerd主要是服务端程序,提供了restfull接口,能够使用curl直接訪问

640?wx_fmt=png

    支持远程訪问的时候。须要改动启动參数:

640?</p><p>wx_fmt=png

    查看执行时环境:

640?wx_fmt=png

    为什么要使用docker-containerd-shim。主要是为了防止dockerd和containerd挂掉,也是为了热迁移做准备,例如以下杀掉containerd之后,依然能訪问容器的服务:

640?wx_fmt=png

    无法连接docker主机(也有可能是docker服务未启动):

640?</p><p>wx_fmt=png

        

闲扯    

    当分析完这个进程之后。陷入了深深的沉思。。

。分析这些进程有个毛的用。。。

640?</p><p>wx_fmt=png

    查看服务是否启动,假设dockerd进程被杀,会被systemd自己主动拉起

640?</p><p>wx_fmt=png

   

    假设带有有用性的目的去看这些进程。一点用处都没有。假设从了解原理的方面,倒是略有所获。从dockerd一个容器引擎分离出几个进程,containerd,shim,runc。除了标准化之外,也从另外一个方面说出了各个组件的专一职责原则。从而能够进行替换,并不怕一家公司进行垄断,另外在进行分层的时候。也表现了上层仅仅是对下层的一层的封装,并提供额外的功能,比如dockerd提供了从registry上传和下载的作用,而containerd则是提供管理容器生命周期的功能,而runc则是从执行容器的工具。


    从标准化的指定上来说。不管runc的标准话还是image的标准化。整体的目标是弱依赖,仅仅要提供对应的接口就能够提供服务,仅仅要符合标准,那么就是能够执行的。