Docker公司被收购，开源界尴尬不？

谁拿了Docker公司被谁收了?

Docker？米兰蒂斯.“米兰蒂斯”是做什么的？

这家公司在中国可能不出名。它在以前的OpenStack社区非常有名，也是一个风云人物。

让我们来看看开放堆栈基金会迄今为止各制造商提交的官方代码总数:

所以，米兰蒂斯从未在开放堆栈社区做过红帽。“库本内斯社区”怎么样？红帽代码贡献了16.5%，前几名没有看到Docker和MItantis:

在Docker社区？红帽仍然排在第三位，码头工人排在第二位。红帽在码头社区的排名没有改变，它的份额确实下降了。

所以，由于许多开源PaaS解决方案都是基于Docker的，Docker被之前制作OpenStack的MItantis收购，这对开源社区来说是不是很尴尬？

为什么？请看下面。

红帽一点也不尴尬！

为什么？请看下面。

容器操作的爱、恨、爱和愤怒

对着下图先说故事脉络：

谁拿了总结

从概念上来说，从PaaS的顶层到底层的调用关系是:

Orchestration API-containereIne API-Kernel API

Existing Openshift 3调用框架:

Red Hat OpenShift4调度框架:

有些开发人员想使用以下模式:

谁拿了完整故事

@LXC·多克尔第一次启动集装箱时，行业中最早的集装箱网格正在运行。码头工人首先开始使用LXC，感到孤立无援，开发libcontainer，并最终形成runC。因此，runC是Docker的独生子。库伯内斯(Kubernetes)发行时，发现Docker在市场上相当受欢迎，所以它被用作集装箱管理工具。码头工人越来越重了。CoreOS已经制作了rkt容器格式(CoreOS已经被红帽收购)。Rkt和Kubernetes合作得更好。容器运行时格式有点多。Linux基金会领导的开源项目说:我们需要制定一个容器运行时标准。OCI。将来，容器在运行时应该符合这个标准。码头工人的独子runC首先达到了OCI标准。库本内斯提出了CRI(容器运行时接口)标准，以便与容器运行时(主要是Docker)分离。它是一组与Kubernetes和容器运行时交互的接口。因此，CRI和OCI没有冲突:库本内斯定义了它调用容器运行时的标准接口，而OCI定义了容器运行时本身的标准。在容器运行时的OCI标准提出后，红帽公司想专门为库本内斯制造一个轻量级的容器运行时。红帽自然会考虑库本内斯发布的CRI标准(库本内斯红帽代码贡献了第二个)，因此它决定重用runC等基本组件来启动容器并实现最小的CRI接口。它被称为cri-o。因此，cri-O是CRI的标准实现。当红帽开发它的CRI-O时，Docker也在研究CRI标准，这导致了另一个运行时的创建，称为containerd(实际上是从Docker引擎中剥离出来的)。所以新版本的Docker将有一个额外的容器层。库伯内斯将集装箱与CRI的标准相联系。CRI-containerd@

谁拿了CRI-O

码头工人是第一个推广集装箱的制造商。起初，Docker使用LXC，但它的隔离层不完整，所以Docker编写了libcontainer，并最终成为runC。后来，Docker成为部署容器的事实标准。当它在2014年发布时，库本内斯自然使用Docker，因为Docker是当时唯一可用的运行时。然而，Docker是一家雄心勃勃的公司，一直致力于开发新的功能。例如，Docker Cost和Kubernetes同时达到1.0，两个项目之间有一些重叠。虽然有许多方法可以使用像Kompose这样的工具来使这两个工具互操作，但是Docker通常被认为是一个做了太多事情的大型项目。这种情况导致CoreOS以rkt的形式发布了一个更简单的独立运行时，其解释如下:rkt的一个创新是通过appc规范来标准化图像格式。Rkt的Kubernes兼容层(rktlet)尚未通过所有Kubernes集成测试，仍在开发中。

containerd：Docker的运行时获取API

看到这些新标准，红帽认为应该创建一个更简单的运行时，并且只需要库本内斯所需要的。“skunkworks”项目最终被称为CRI-O，并实现了一个最小的CRI接口。

红帽公司负责在2016年底推出其OpenShift平台。该项目还受益于英特尔和SUSE的支持。红帽公司主持了CRI-O开发者乌纳尔·帕特尔先生的演讲。CRI-O与CRI(运行时)规范以及OCI和多克图像格式兼容。

CRI-O重用基本组件(如runC)来启动容器，并重用软件库(如为skopeo项目创建的容器/映像和容器/存储)来提取容器映像和创建容器文件系统。名为oci-runtime-tool的独立库准备容器配置。

结论

当红帽开发其OCI的实现时，Docker也在研究该标准，这导致了另一个名为containerd的运行时的创建。新的守护程序是内部Docker组件的重新配置，以结合OCI特定的位，如执行、存储和网络接口管理。它已经反映在1.12 Docker版本中。虽然我们称containerd为“运行时”，但它并不直接实现CRI接口，这是由另一个名为cri-containerd的守护进程所覆盖的。因此，容器需要比库本内斯的CRI-O (5，CRI-O是3)更多的守护进程。库伯内斯将集装箱与CRI的标准相联系。

与CRI-O的不同之处在于容器通过gopi支持库本内斯生态系统之外的工作负载。虽然容器定义了一个清晰的发布过程来改变应用编程接口和命令行工具，但是应用编程接口还不稳定。像CRI-O一样，containerd是完全功能性的，并且通过了所有库本内测试，但是它不与systemd的cgroup进行互操作。

为了与oci更加兼容，库本内斯还孵化了cri-o，并成为cri和oci之间的桥梁。这样，当运行更多符合oci标准的容器时，连接kubernetes以供集成使用是很方便的。可以预测，通过cri-o，kubernetes的兼容性和使用的普遍性将得到进一步加强。