Docker 在 CoreOS 的 Rocket 发布之后的一些最初想法

当Docker开展的18个月前，我们就开始了一项任务，以建立“按钮”的方式，可以使任何应用程序立即持续的运行在任何地点的任何服务器上。

我们的第一个任务是定义一个标准的容器格式，将任何应用程序打包在一个轻量级的容器中，可以让它运行在任何的基础框架上。

正是有很多的辛勤工作者参与到了Docker的整个社区，Docker的功能才会变得很强大，我们可以做出一些比较成功的Docker容器，让其可以运行在所有主要的基础设施上；因此，我们建立一个强大的生态系统，包括：

• 超过700个投稿人（其中95%人没有工作于Docker.Inc.）
• 超过65000个自由dockerized语言、框架和应用程序（服务）
• 支持每个主要DevOps的工具、公共云，和所有主要的操作系统
• 第三方工具建立在Docker一个强大的生态系统上。现在有超过18000个项目在GitHub上标有Docker标题
• 在40多个国家，有超过175个以上的关于Docker的聚会团体
• Docker用户已达数百万

在这个过程中，我们构建了一个健壮、开放的设计和治理结构，可以让用户、供应商和贡献者来帮忙指导 Docker 项目的发展方向。

在过去的九个月，我们对 Docker 进行拓展，使之超出饿了一个简单容器的范畴。不过 Docker 继续定义着单一容器格式。很明显，绝大多数我们的用户和贡献者以及供应商都希望 Docker 可以支持在运行在多个主机的多个离散容器中分发应用程序。

我们认为，当我们转向一个多容器、分布式应用的世界时，单个Docker容器应用的简单、开放的接口，无论何地的可移植性，健壮的生态工具集如果丢失，将是非常令人遗憾的。因此，我们一直在推广更加全面的编排服务集(set of orchestration services)，涵盖网络、调度、组合、集群等功能。更多细节可以在这周阿姆斯特丹举办的 DockerCon上获取到，其中一些设计点值得注意：

1. 多容器编排能力(multi-container orchestration capacibilities) - 与容器标准本身一样，这种能力应该由基于社区和生态系统内的协作和反馈的开放设计流程(open design process)创建。
2. 这些编排功能应该通过开放API来分发，使用开放设计流程进行公开开发
3. 这些能力不能是单一庞大的(monolithic)。每个人都应该可以自由使用、修改，或者不使用这些服务及其高层API
4. 这些能力和API应该支持插件(plug-ins)，这样大家可以选取最适合自身情况的调度、集群、日志或者其他服务，而不应该牺牲可移植性，跨基础设计工作的能力，使用65K+ Docker化的应用或者基于Docker的18K+工具的能力。这个插件模型在执行引擎(比如libcontainer, LXC)和文件系统(BTRFS, 设备映射/device mapper，AUFS,XFS)下工作的非常好。期待下这周更多的发布说明吧。

当然，不同的人对开源项目如何开发有不同的看法。如上文提到的，绝大多数的用户、贡献者、生态系统内的厂商都希望这个项目支持标准的、多Docker容器的分布式应用。很多厂商，无论大小，都欢迎并正在为此贡献努力(关于Docker开放治理的更多信息，查看下这篇文章)。

我们仍致力于生态系统内的用户、厂商和贡献者。无论大家向Docker贡献的形式，是作为构建Docker容器格式的独立项目，还是作为Docker编排API的插件，或者其他形式，我们都希望开放、分层的方法都能给全部相关者提供选择。但是，一小部分厂商不认可这个方向。有些表达了他们的担忧，当Docker扩大适用范围，他们创造差异化、增值业务的空间就变小了。某些情况下，这些厂商甚至希望创建为他们特定基础设施或业务量身定做的编排方案，因此不欢迎可移植性的概念。当然在另外一些情况下，会有些技术性或者哲学意义上的区别，这些区别看上去与Rocker最近的发布声明有关。我们希望能在后续的文章中解释Rocker项目带来的一些技术争论。

这里，我们要强调这只是一个健康的，开源过程。就像 Docker 是开源的，并遵守Apache开源协议，人们可以自由使用，修改，或者为了自己的需求进行改造。他们可以只把Docker作为一个简单的容器。他们可以自由的将更高级别的服务加入到Docker。当然他们也可以自由的推广另外一种概念作为新标准，就像Rocket团队已经做的那样。