DockerOCI容器标准和引擎架构

docker利用namespace技术，可以将进程放到一个隔离环境里面，同时cgroup技术将容器进程限制资源配额，可以通过pveryfs来模拟一个完整的这种文件系统。

那么业界又是如何定义这一切的呢？这就是OCI的容器标准了。

OCl 容器标准

Open Container Initiative

1. OCl 组织于2015年创建，是一个致力于定义容器镜像标准和运行时标准的开放式组织。
2. OCI定义了镜像标准（Image Specification）、运行时标准（Runtime Specification）和分发标准(Distribution Specification)

• 镜像标准定义         应用如何打包（其实也就是overyfs那块，怎么通过容器镜像的驱动来将分层的文件系统标准化）
• 运行时标准定义     如何解压应用包并运行（将容器镜像进行解压，并且运行）
• 分发标准定义         如何分发容器镜像

docker当时认为它是标准，但是docker本生实现是很重的，当kubernetes对接docker的时候会发现很多东西对不上的，中间功能会有相互冲突和覆盖的地方，所以kubernetes起了一个OCI的规范，它尝试去将容器技术规范化，标准化。当你要去实现一套自己定义容器规范的时候，那么那就需要去遵循这套规范。

docker 引擎架构

 在每台机器上你安装了docker之后，它会有一个docker daemon，这个是docker本身的一个后台服务端，它实际上就是rest api，同时机器上面还会安装docker command，这个时候就可以将请求给到docker daemon，现在新的docker版本都已经支持了对OCI的兼容，docker daemon接收到请求之后通过GRPC的调用将请求转到containerd里面去，containerd是真正用来控制这些运行时的，containerd也是一个单独可以运行的组件。

containerd会去真正启动containerd的shim进程，然后再通过runc，也就是底层运行时的一个接口

，通过runc再去启动容器进程。

通过上面，docker就整个和OCI规范完全匹配起来了。

docker shim它的作用是什么：在早期containerd和containerd shim是不存在的，在早期docker命令去启动容器的时候，这个容器进程是由docker daemon直接拉起的，也就是docker daemon下面是你的容器进程，这会有什么问题呢？docker daemon是你所有容器的父进程每当你去升级docker或者重启docker的时候，父进程就不存在了，那么所有的子进程就全部会重启。也就是说你不能轻易的去升级docker，在早期docker是有一个这样致命问题的。

所以后面就有了containerd，它是一个更加轻量级的容器管理进程，在启动容器进程的时候，不是以父进程的身份去启动，而是启动shim，这个shim进程是用来维护容器进程生命周期的，shim进程在运行起来之后，它会将shim进程交给操作系统的init system，由systemd去管理的。

这样的话containerd下面就不挂任何的子进程的，那么containerd就可以随便更新，升级，重启，下面的应用是不受影响的。

它就将控制组件和正真运行业务的组件分开了，所以containerd就相对docker优势就是可以随便升级，随意修改，后面docker也不得不这样，kubernetes是可以直接使用contained，因为contained已经是一个完整的运行时了。所以docker不得不加入支持containerd行列中来，所以就有了上面的架构。