podman-1-容器运行时的OCI规范

浅析容器运行时奥秘——OCI标准
容器化到容器编排之旅

容器运行时和管理工具。

容器技术火起来了以后，Docker的容器镜像和容器运行时已然成为行业的标准。此后，为了推进容器生态的健康发展。在Linux基金会的主导下，Docker和各大云厂商Google, Amazon, CloudFoundary, Microsoft积极响应于2016年成立了 Open Container Initiative(开放式容器倡议)，旨在主导容器的生态发展方向，促进容器生态的健康发展。

1 背景

一、2013年Docker开源了容器镜像格式和运行时以后，为我们提供了一种更为轻量、灵活的计算、网络、存储等资源虚拟化和管理的解决方案，在业界迅速火了起来。

二、2014年更是容器技术发展的一个爆发点，各种容器编排工具也逐步开始发力。值得一提的是Google发布了k8s的第一个Release版本，现已成长为容器编排领域的领导者。

我们知道Docker的容器运行时解决方案采用的两个核心技术：Namespace(资源隔离)和Cgroup(资源管理)。

这两项技术并不是Docker实现的，其实在Docker之前早已进入Linux内核，换种说法就是Docker的容器解决方案离不开Linux内核的支持。这就是说行业的各个大佬如果自己想搞，都可以利用这两项技术自己做一套类似于Docker的容器解决方案。

容器技术火起来了以后，Docker的容器镜像和容器运行时已然成为行业的标准。

彼时Docker正当红，对各大佬(Linux基金会、谷歌、微软等)提出的合作邀请充耳不闻，态度强硬，力图独自主导容器生态的发展。加上Docker在Runtime的向下兼容性的问题，社区口碑较差。此时，各大佬就纷纷表示要另起炉灶、自已干，其中比较有代表性的就是Google声称要fork一个分支自己干。不过，Linux基金会最后还是拉着前边提的这些大佬向Docker施压，最终Docker屈服。

三、2015年6月在Docker大会DockerCon上推出容器标准，随后便成立了OCI(Open Container Initiative开放容器倡议)，并发展成为Linux基金会下的一个项目。

2015年6月22日，Docker、CoreOS、Google、RedHat等公司共同宣布：Docker公司将Libcontainer捐出，并改名RunC项目，交由一个中立的基金会管理。然后以RunC为依据，共同制定一套容器和镜像的标准和规范。

在OCI的官网可以看到如下描述：
The Open Container Initiative (OCI) is a lightweight, open governance structure (project), formed under the auspices of the Linux Foundation, for the express purpose of creating open industry standards around container formats and runtime. The OCI was launched on June 22nd 2015 by Docker, CoreOS and other leaders in the container industry.
开放容器倡议(OCI)是一个轻量级的开放治理结构(项目)，由Linux基金会赞助成立，其明确目的是围绕容器格式和运行时创建开放的行业标准。OCI于2015年6月22日由Docker、CoreOS和其他容器行业领导者发起。

The OCI currently contains two specifications: the Runtime Specification (runtime-spec) and the Image Specification (image-spec). The Runtime Specification outlines how to run a “filesystem bundle” that is unpacked on disk. At a high-level an OCI implementation would download an OCI Image then unpack that image into an OCI Runtime filesystem bundle. At this point the OCI Runtime Bundle would be run by an OCI Runtime.
OCI当前包含两个规范：运行时规范(runtime-spec)和镜像规范(image-spec)。运行时规范概述了如何运行解压到磁盘上的文件系统捆绑包。在高层级，一个基于OCI实现的应用将下载一个OCI镜像，然后将该镜像解压到OCI运行时的文件系统捆绑包中。此时，这个OCI运行时捆绑包将由OCI运行时运行。

在这两段描述中透露出2点关键信息：

(1)OCI是在Linux基金会主导下的轻量级的开源管理项目，旨在为容器格式和运行时构建开放的行业标准。
(2)OCI标准目前包含两部分内容：

容器运行时规范： 该规范定义了如何根据相应的配置构建容器运行时。
容器镜像规范： 该规范定义了容器运行时使用的镜像的打包规范。

总的来说OCI的成立促进了社区的持续创新，同时可以防止行业由于竞争导致的碎片化，容器生态中的各方都能从中获益。

2 OCI规范

2.1 OCI Runtime规范

OCI规范了容器的配置、执行环境和生命周期管理。

容器的配置信息由config.json配置文件来管理。规范容器的执行环境可以保证容器内运行的应用在生命周期内拥有一致的运行环境。

总的来说OCI希望通过规范容器的配置、执行环境和生命周期管理，进而达到Docker所提出的Build, Ship, and Run any app, anwhere愿景，为了达到这个目的，OCI在制定之初提出了以下5个理念：

(1)操作标准化：
对容器整个生命周期内相关的标准化进行标准化，包括：创建、启动、停止、创建快照、暂停、恢复等操作。规范每个操作的具体含义，将容器的具体操作进行原子化规范。

(2)内容无关：
内容无关指不管针对的具体容器内容是什么，容器标准操作执行后都能产生同样的效果。如容器可以用同样的方式上传、启动，不管是PostgreSQL还是MySQL数据库服务。

(3)基础设施无关：
容器可以运行在任何支持OCI的基础设施上。

(4)为自动化而生：
由于容器的标准操作与基础设施无关，这样就为我们更好的进行自动化管理提供了良好的基础。以前那些耗时、耗力需要投入大量人力的工作，现在就可以利用容器进行自支管理。

制定容器统一标准，使的操作内容无关化、平台无关化的根本目的之一，就是为了可以使容器操作全平台自动化。

(5)工业级交付：
容器标准化能够使软件应用的分发可以达到工业级的交付。标准容器使得我们可以构建自动化的软件交付流水线。不管是内部的DevOps流，还是外部的软件交付机制，容器正在一点点的改变我们对软件打包和交付的认识。

2.2 OCI Image规范

OCI的Image格式规范是容器ship anywhere的基础, 最终落地时体现为Runtime中的bundle，以此为基础为用户提供一致的运行时依赖环境。该规范由Docker贡献，并由社区维护，包含manifest, image index 和 filesystem layers三部分内容。
(1)manifest: 货单
对于指定架构和OS的容器镜像， manifest定义了它所依赖的相关配置信息和对应的layer镜像层信息。
(2)image index:
比manifest更高层的抽象，包含了额外的配置信息。
(3)filesystem layer:
给出了如何将容器的文件系统进行序列化，如何创建和使用这些layer。我们知道容器的启动速度可达秒级，主要的原因是我们常见的aufs, devicemapper等均采用了COW(copy on write)的技术，使得相同镜像的不同容器实例可以共享bundle，write(修改)的数据也是在layer中。

3 runC

OCI规范实际上将Runtime和容器镜像从Docker项目中剥离。Runtime与操作系统kernel紧密协作，为容器提供运行环境。

OCI定义了容器的Runtime和镜像格式两个核心的规范，现在有了规范，还需要一个落地的实体。

3.1 runC是什么

runC是轻量级容器运行工具，它根据OCI规范来创建和运行容器。

runC是Docker公司2015年发布的容器Runtime工具，是一个符合OCI规范的轻量级容器运行时生命周期管理工具，runC由Libcontainer演变而来，由Docker贡献给社区。

业界其他Runtime有Linux上的LXC，CoreOS的rkt等。

3.2 runC与docker的关系

docker由docker client和 dockerd组成，前者为客户端，后者为对容器相关操作的api的最上层封装。docker client通过rest api调用dockerd。

containerd是dockerd和runc之间的一个中间交流组件，通过grpc的方式与dockerd通讯。

docker-shim是一个运行容器的真实载体，每启动一个容器都会启动一个新docker-shim进程。

最终docker-shim运行runc去运行容器里面的程序。