连接性Docker的网络能力相当原始，容器中的服务对相同主机的其它容器是可见的，并且Docker可以映射端口到主机操作系统，使得服务在网络中也是可见的。Libchan是Docker官方赞助的连接方法，它提供了Go语言的网络服务库，类似于channels。在libchan找到自己应用的道路之前，还是有空间留给第三方程序来提供一些补充性的网络服务。例如，Flocker采用了基于代理的方法，这使得服务（连同底层的存储）可以在主机间进行迁移。 合成Docker有个原生的机制来连接容器，它所依赖的元数据可以被传送到相关的容器中，这些元数据被用做环境变量和主机入口。类似Fig和geard这样的应用合成工具，可以在单文件中表达这种依赖关系图，这样多个容器就可以互相配合成为一个系统。CenturyLink的Pannamax合成工具在底层采用了和Fig、geard相似的方法，但加入了基于Web的用户接口，并且直接和GitHub进行了集成，这样就可以分享合成后的应用了。 编制编制系统包括Decking、New Relic公司的Centurion和谷歌公司的Kubernetes，它们的目标都是帮助实现容器的部署和它的生命周期管理。也有很多基于Apache Mesos系统（特别是它为应用长期运行设计的Marathon框架）的商业化实现（比如Mesosphere），它们可以和Docker一起使用。通过提供在应用需求和底层架构间的抽象（例如，需求表达为CPU核数和内存大小），编制工具提供了两者之间的解耦，这种设计简化了应用开发和数据中心的运维。还有各种各样的编制系统，这主要是因为之前许多内部系统工具冒出来了，它们之前开发出来是用于管理容器大规模部署的。例如Kubernetes就是基于谷歌的Omega系统，而Omega系统是用来管理整个谷歌云环境中的容器。 合成工具和编制工具功能上会有部分的重合，所以使用时它们彼此可以作为补充。例如Fig可以用来描述容器功能上如何交互，同时Kubernetes pods（译者注：pods可以被看成一个容器组）可以用来提供相关的监测和扩展功能。 平台即服务有很多原生于Docker的PaaS实现，例如Deis和Flynn，已经体现出Linux容器在支持开发灵活性上的强大优势（而不是那些自以为是给定的一套语言和框架）。其它的云平台如CloudFoundry、OpenShift和Apcera Continuum，已经采用集成基于Docker相关功能到现有系统中的技术路线，这样基于Docker镜像（或者是创建它们的Dockerfiles）的应用在部署和管理的同时，仍然可以使用之前系统支持的语言和框架。 所有的云由于Docker可以运行在任何有合理数据内核的Linux虚拟机上，所以它可以运行在很多IaaS提供的云上。许多大的云提供商宣布了对Docker和它的生态系统的附加支持。 亚马逊已经引入Docker到它的弹性豆茎（Elastic Beanstalk）系统中（这是在IaaS之上的编制服务）。谷歌使Docker成为可管理的虚拟机（managed VMs），它提供了在应用程序引擎的PaaS和计算引擎的的IaaS之间的中间站。微软和IBM也都宣布了基于Kubernetes的服务，这样在他们的云上就可以部署和管理多容器应用了。 为了给当前使用的广泛多样的后端提供一致性的接口，Docker团队引入了libswarm，它会被集成到多数的云和资源管理系统中。Libswarm一个明确的目标是“通过切换服务来源的办法来防止供应商锁定”。这通过呈现一组一致性的服务(以及相关的API)来完成，这些服务会附着到特定后端的实现上。比如Docker服务器服务会呈现Docker远程API到本地Docker命令行工具中，这样众多的服务提供者就可以管理相关的容器了。 基于Docker的新的服务类型仍在起步阶段。虽然位于伦敦的果园实验室（Orchard labs）可以提供Docker容器的托管服务,但Docker公司表示,在它收购果园实验室后相关服务不会被置于优先位置。Docker公司还向cloudControl公司出售了其先前的DotCloud PaaS 业务。如OpenVZ之类基于旧的容器管理系统的服务已经比较普通了,所以在一定程度上Docker需要向主机提供商们证明其价值。 Docker和它的发行版Docker已经成为主流Linux版本的标准特性，比如Ubuntu, Red Hat Enterprise Linux (RHEL) 和CentOS。遗憾的是这些Linux发行版与Docker项目在步调上并不一致，从而导致这些Linux发行版中Docker的版本比当前能用的老得多。例如Ubuntu 14.04的Docker版本是0.9.1，并且在Ubuntu升级到14.04.1时Docker的版本也没有变（当时Docker项目版本是1.1.2）。在官方库中还有一个命名空间冲突的问题，因为Docker也是KDE系统托盘的名字，所以在Ubuntu 14.04中Docker包和命令行工具起了另一个名称“docker.io”。 在企业级Linux发行版中情况也没有太大的不同，CentOS 7中Docker的版本是0.11.1，这是Docker公司宣布1.0版本产品准备就绪之前的一个开发版。Linux发行版用户如果要使用最新的版本以保证稳定性、性能和安全，那么按照Docker安装指导操作并使用Docker公司提供的库，要比使用Linux发行版中的版本要好得多。 Docker的到来也催生了新的Linux发行版，比如CoreOS和Red Hat的Project Atomic，它们设计成能运行容器的最小环境系统。这些发行版相比传统Linux发行版本，有比较新的内核和Docker版本，对内存和硬盘的占用也比较小。新的发行版本中也有一些新的工具用来管理大容量的容器部署，比如fleet负责分布式系统启动，而etcd负责元数据管理。这些Linux发行版针对自身的分布式更新采用了新的机制，这样就可以使用最新版本的内核和Docker了。这表示对Docker应用的其中一种效果的认可，那就是把注意力重心从发行版和包管理解决方案转到Linux内核(和使用内核的Docker子系统)上来。 尽管新发行版（译者注：类似于CoreOS）可能是Docker最佳的运行方式，但支持容器的传统发行版和它们的包管理工具仍然非常重要。Docker Hub上提供了 Debian、Ubuntu和CentOS的正式镜像，还有“半官方”Fedora的镜像库。RHEL没有在Docker Hub上的镜像，因为它们是直接由Red Hat发行的。这意味着Docker Hub上的自动构建机制只对那些纯开源的Linux发行版本可用（并愿意信任那些起源于Docker公司团队策划的基础镜像）。 Docker Hub同时集成了源控制系统，如GitHub和Bitbucker，用来自动构建包管理器。包管理器可以在镜像构建过程中生成构建规格（在Dockerfile中）和最终构建镜像之间的复杂关系。构建过程的结果具有不确定性，这不是Docker的特定问题，而和包管理器如何工作相关。今天构建的是这个版本，在另一个时间构建可能会得到一个新的版本，这也就是包管理器需要更新功能的原因。容器抽象（即较少关注容器中的内容）与容器扩展（因为轻量级资源利用率）可能会使这种不确定性成为Docker相关的痛点。 Docker的未来Docker公司已经建立了清晰的道路，即发展核心能力（libcontainer）、跨业务管理（libswarm）和容器间消息（libchan）。与此同时，通过收购果园实验室（Orchard labs），Docker公司表达了利用自身生态系统的意愿。但是，这不仅仅关注Docker公司，这个项目的贡献者还来自于一些大牌公司，如谷歌、IBM和Red Hat。在仁慈的独裁者、首席技术官Solomon Hykes的掌舵下，Docker公司和Docker项目的技术领先有着明确的联系。在项目初始的18个月里，它已经显示出通过自己的输出来快速前进的能力，并且没有减弱的迹象。 许多投资者正着眼于十年前VMware公司ESX/ vSphere平台的功能矩阵，试图找出已经由虚拟机普及而驱动的企业预期和现有Docker生态系统之间的差距（和机会）。在网络存储和细粒度的版本管理（用于容器中的内容）领域，现有Docker生态系统做得并不好，这就为初创企业和在职人员提供了机会。 随着时间的推移，虚拟机和容器（Docker中的“运行”部分）之间的区别很可能变得不再那么重要，这将使注意力转到“构建（build）”和“交付（ship）”方面。这些变化将使 “Docker会发生什么？”的问题，相比“Docker会带给IT业什么？”的问题，变得更不重要。 关于作者
查看英文原文：Docker: Present and Future |
Chris Swan 是云网络软件供应商
