熟悉云计算和虚拟化的同学应该知道，容器的历史由来已久。从90年代的Java和J2EE开始，这种通过底层平台为应用程序创建单独使用环境实例的方式就为人所知。随着企业上云成为趋势，如何在本地数据中心与公有云之间为应用迁移构建桥梁，让大家再次想到了容器。事实上，容器引擎在混合云编排中的贡献着实不小。

　　跨云离不开容器（图片来自Yahoo）

容器为应用创建了隔离边界，使得多个程序在单一操作平台上可以独立运行。对于使用者来说，不需要为每个应用都创建虚拟化，相应的也可以有效利用硬件资源，这种针对容器执行和规模的管理在容器编排引擎上同样适用。常见的编排工具包括Kubernetes（谷歌开源工具）、Docker Swarm、Apache Mesos、Rancher等，它们能够处理复杂任务，例如查找最优运行位置、处理失败任务、分享储存卷或创建负载均衡与容器间通讯的覆盖网络。

通常，企业内部对数据在本地和云端之间的迁移要求是无缝即时的，而容器要做的就是基于底层提供一个抽象层让应用“随意交互”。Kubernetes使用了计算集群部署并管理容器，通过均衡工作负载来维护性能。在集群中运行时，Kubernetes的自复制性可以从横向或纵向扩展容器数量，以满足多应用迁移的需求。

再举个例子，微博的架构在三年前容器化，之后打通私有云和公有云部署了初始化环境（包括Docker、Swarm），在编排向调度层下发任务时会根据资源进行分配。也就是说，有资源的调度，没资源的时候向主机层申请。成功申请后，会自行创建机器环境，而初始化起到的作用就是带来了可运行的Docker编排环境。有了容器编排引擎，开发人员可以自行创建本地数据中心与公有云之间的应用移植架构。

拿红帽来说，Red Hat OpenShift提供了高度模块化特性，用户可以有多种选项进行定制，而且不会丢失任何功能。当然，企业也不用在Docker或Kubernetes之间做二选一，Red Hat OpenShift ContainerPlatform 3.4允许使用者跨云分配上述两个编排工具的资源，组件集成、上线测试等流程均交给服务商，让用户实现了自动化。另一个开源编排系统Cloudify，甚至能够让应用自动化在不同云平台上部署，支持容器应用在非容器化环境同时运行，只需通过一个控制器。

对于任何一家企业而言，打包交付的方式都是首选，但遗憾的是现有工具无法在用户使用容器时提供完全自动化的方案。也就是说，工作负责耦合分离等问题的存在，让开发者即使用了容器引擎或管理平台，依然难以避免花费大量时间在传统的业务流程。但不管怎样，专注于核心业务，善用容器编排引擎仍是跨云迁移的好办法。