浅谈Docker引擎

在Docker首次发布的时候，Docker引擎由两个核心构成，即：LXC和Dockerdaemon。 由LXC来基于Linux内核的容器虚拟化技术来提供像NameSpace,Cgruop等基础工具的操作技术；由Daemon来统一负责镜像的管理，容器生命周期的管理，认证等工作。这样做也带来了很多的缺点，首先：LXC是基于Linux的，这对于一个立志与跨平台的项目来说本身就是一个瓶颈；其次，使用一个外部工具来实现如此核心的功能也让Docker公司有些担心，出于此，docker公司自己开发了libcontainer,它可基于不同的内核向上层Docker提供必要的与容器交互的能力。另外的，由Docker daemon来负责如此多的事情，各个组件之间耦合程度非常高，如果遇到Docker daemon的版本更新，会要求Kill掉线上所有正在运行的容器，这对于生产环境来说可能是非常恐怖的。
于是，Docker公司开始着手于将Docker引擎模块化，到现在Docker引擎大致可以分为如下图的几个部分：

1.Docker客户端：docker客户端负责接受用户发出的指令(eg:docker version /docker pull)等，并将这些指令解析,转换成合适的API格式，并发送到正确的API端点。

2.Docker daemon:daemon守护进程用于镜像的管理，构建，接收docker-client的请求，身份认证等工作，但并不参与容器生命周期的管理，而是会向containerd发出指令，来创建容器。

3.containerd:containerd负责容器的整个生命周期，如容器的start/stop/rm等。除此之外，containerd还需要将docker的镜像以OCI bundle(OCI：开放容器计划(用来指定docker相关协议)，bundle:镜像)的格式传递给runc（容器运行时），来创建容器。

4。runc–容器运行时。runc可以作为独立的cli工具来创建容器，他是基于libcontainer的。runc天生的使命就是创建容器，也可被当作第三方工具使用。runc在创建完容器后就退出，所以就算有上百个容器在同时运行，也并不会有上百个runc实例。反而在runc退出后，由shim来接替runc成为容器的父进程管理容器，shim的主要工作有两点：首先时保证daemon因为某些原因宕掉后（比如更新版本时先结束daemon进程），容器不会因为管道的关闭和结束，也就是维护容器状态。第二点就是shim要在容器关闭时向daemon返回容器关闭信息。
这是自己在学习docker时做的一些笔记和整理，如果有错误或者补充的地方，欢迎联系我指正和交流。