将在深圳中州万豪酒店隆重举行。本次峰会以软件开发为主题，数十位专家级嘉宾将带来多场精彩的技术内容分享。届时，华为主任工程师梁辰晔将在微服务与容器技术分会场与来宾分享OCI容器标准的社区演进和OCI方案的实战的主题演讲，为大家详细阐述容器标准的目前发展状况及怎么样打造一套完整的OCI社区方案。51CTO诚邀您莅临大会，与我们共享技术带来的喜悦。
51CTO记者对即将参加大会演讲的梁辰晔老师进行了专访，让我们先睹为快，探听一下他是解读OCI方案实战的。
2015年，由Docker、IBM、微软、红帽及Google等厂商所组成的OCI联盟成立，并于2016年4月推出了***个开放容器标准。除推出OCI Runtime标准，让开发者打包、部署应用程序，并可以自由选用不同的容器Runtime外，还推出开放容器OCI镜像标准，由容器技术社区制定规范，确立容器镜像建立、认证、部署以及命名的方式。今年早一点的时候，***个标准OCI 1.0版终于正式出炉，此标准也意味容器离标准化更近一步。
runtime标准已经发布了1.0版本，相对来说还是比较成熟，当前的主流容器引擎包括runc, rkt, runv等都能兼容runtime标准。image 标准也已经发布了1.0版本，但是这个标准仅限于格式标准。OCI Image格式和Docker的镜像格式非常相似(因为OCI Image格式完全借鉴Docker的镜像格式)，包括一个完整的分层技术和描述文件。
目前，OCI社区提供工具来验证 “某个runtime是不是满足runtime标准”， 也提供工具来验证“某个image是不是满足image标准”。
对 runtime的验证，是用每个标准项的预期的结果和实际的结果作对比，如果全部一致，证明符合规定标准，反之则会报错。例如，要验证一个程序执行过程中的环境变量是否和设定的一致，那么只要把运行中的环境变量和配置里的环境变量作对比即可。对image的验证，是判断某个image的各层、各配置项是不是满足OCI含义，如果有不合规的配置，那么说明这个镜像 “非OCI标准”。
1. 镜像发现获取机制的欠缺， 这也是和主流的Docker/rkt的***差距
镜像标准制定了镜像的格式，但是“从哪获取镜像，如何获取”，都是问题。这就限制了OCI镜像的流行，因为用户或开发者根本找不到一个可用的镜像。针对于此，社区的做法是从Docker里面获取一个Docker镜像，然后转化成OCI镜像。但很明显，这个根本没办法商业化。
这也可以说明Docker为什么流行，就是Docker的镜像应用比较丰富，镜像的制作和发布很方便。OCI没有了镜像的分发机制，就只能是一个理论上的产物。
容器方案千差万别，OCI社区无法预知到一个能够符合所有场景的标准。比如 runV，也有一些选项是OCI不足以满足的。
梁辰晔老师表示，目前容器标准能够相安无事还是因为社区里面Docker一家独大，未来容器标准能否覆盖更多的方案还未知，当时才是真正考验“标准”社区的时候。
说到怎么样打造一套完整的OCI社区方案，目前可以借鉴的还是 Docker方案。
这里的 1~5，其实都与镜像相关，只有6与runtime相关。因此能看到，一个完整的 OCI方案，需要有大量的镜像相关的操作。而这些都是OCI里没有的，也是未来OCI社区要做的事情。
梁辰晔老师将在WOTD现场，用当前的开源项目为原型演示一个完整的OCI方案。
目前，OCI按照先易后难的原则聚焦运行时和镜像格式的标准化，1.0标准发布之后，OCI的标准范围会逐渐扩大到镜像发现机制、镜像获取机制等内容，引入新的项目。未来OCI社区的方案肯定会慢慢的“商业成熟”，当时才能真正体现OCI的价值。
对于PaaS云开发、部署和运维人员来说，到时就能不用特别担心集成的runtime和选用的镜像是否有兼容问题，只要符合OCI标准就能无缝的“获取”和“运行”。
梁辰晔，华为主任工程师，从事容器相关的开发以及社区组织工作。现为Linux/OCI社区maintainer，华为容器OS社区(EulerOS iSula)的负责人。拥有10多年的社区布道、社区开发和商业产品的交付经验。先后活跃于GNOME社区、openSUSE社区，对开源开发、开源到商业的转换有深刻的理解。
使用双十一特别优惠码[B310BD20D337F914]立减200元，和我一起去WOTD全球软件开发技术峰会!详情点击
containerd是容器技术标准化之后的产物，为了可以兼容OCI标准，将容器运行时及其管理功能从DockerDaemon剥离。理论上，即使不运行dockerd，也能够直接通过containerd来管理容器。(当然，containerd本身也只是一个守护进程，容器的实际运行时由后面介绍的runC控制。)
