为什么造那么多集装箱（来聊聊不一样的）

“没有集装箱，就不会有全球化。”1956年，当麦克莱恩第一次用集装箱运输货物时，肯定不会想到这种方式会用在IT行业的应用开发上。“Docker”的字面意思是码头工人，而他们搬运的箱子就是容器（Container），旨在将开发者的应用打包成一个包裹，发布到所有Linux机器上。有了支持Linux的基础，再加上微软、IBM、亚马逊等大厂商助阵，以及中小企业的围绕其进行开发，Docker的生态逐渐建立起来。不过，容器技术也并非一本万利，在开发部署的过程中仍然面临一些问题。

60年过去了 来聊聊不一样的“集装箱”

如果翻看容器的历史，其实这种概念并不是新鲜事，其最初只是被当做虚拟化的技术，作为LXC（内核虚拟化技术）容器管理子系统的前端，源代码托管在Github上，直到2013年被DotCloud当做公开项目发布，随后DotCloud也将公司名称改为Docker。从本质上来说，Docker提出了创建、装配、运行的思路，将容器向IT上下游产业链进行延伸，打通了软件应用生产、发布、使用的环节，并且结合DevOps提升了效率。与Java相比，容器所解决的问题并不局限于运行。

技术的成熟离不开标准化，容器的集装箱式交付将执行某一程序所需的配置文件、软件资料库、操作系统都打包在进程里，通过在码头（云服务商）之间搬运生成镜像，然后创建一个个新的集装箱，在应用在里面运行。这样一来，使用者无需使用单独的工具来管理、部署、监控应用，可以充分获得一致性，也提升了开发和交付效率。换句话说，容器技术在LXC与平台之间定义了标准接口，提供一种安全、可移植的执行环境。

需要注意的是，Docker公司只是容器技术的提供方之一，并不能完全代表容器，另外还有常被提及的Kubernetes容器管理技术。或许是出于商业原因，Docker在4月召开的DockerCon 2017大会上，将赖以成名的Docker项目更名为Moby。至于DockerCE这个产品，会由Moby旗下的Moby项目，以及其他项目构建和编译。将开源项目产品化，只能在官网下载使用，培养用户的付费习惯。究其原因，还得回到开源领域的盈利问题，Docker没有掌握绝对核心的技术，必须自谋出路，毕竟像红帽这样的成功例子鲜有。

言归正传，尽管容器技术的应用越来越广泛，但无论是对于开发者还是企业客户，仍有不少问题需要解决。首先是编排，从Kubernetes、Mesos，到Docker Swarm，还有公司内部的开发工具，容器编排的选择并不少，对企业的选择造成了困扰，而开发成熟度也需要社区和容器厂商共同完善。在这方面，Kubernetes在过去一年中获得的关注相对较高。

其次是网络，在去年的一项关于容器市场的调查中，有15%的受访者表示网络是容器应用的第二大障碍。虽然容器网络可以跨节点连接，但在配置操作和性能方面仍有不足。抛开网络预分配时额外步骤带来的错误率提升不说，如果是用网桥直接连到交换机，还有可能造成IP冲突，创建的过程也会受到影响。对此，有专家提出了overlay网络，相当于将每个docker主机放到一个子网中，并配有独立IP，简化了管理，便于扩容。

再者是工具的应用性和可控性。举例来说，库资源贡献了很多预置容器，但在沙盒机制中是存在不稳定风险的，有些大企业会倾向于建立私有库，还要配备专人管理。说到管控，分布式环境动态运行容器时，所谓的弹性部署变向增加了运维难度，使得技术研发碎片化，而部分企业在这方面的应对经验仍是缺失的。

还有就是数据的持续存储和处理。从调研机构的报告来看，超过四分之一的受访者将持久性存储列为最大挑战，这就迫使容器解决方案要贯穿整个生命周期，并且与存储后端无缝衔接。另一方面，容器应用还要让不断增长的数据更易于访问，尤其是要兼顾动态扩展，要在镜像转移后仍然可以找到原有的数据。

最后是安全。尽管Docker利用容器将资源有效隔离，但在云服务商的平台上运行时，由于需要考虑数据使用和共享等问题，就会让安全性变得复杂。一方面，Docker自身的安全防范不算严格，而对着这种新技术的相应安全措施也尚未普及。通常来说，小企业会创建小型容器应用降低风险，可大企业却遭了殃，要想确保成千上万个容器不出问题，不仅要加强实时可见性，还要制定严密的安全策略。例如，Twistlock就为开发人员提供了一种解决方案，用于发现和管理容器映像的漏洞。

如今，容器已经成为主流趋势，甚至有向上取代传统PaaS平台的野心。不过对于任何一项新技术，总要有成熟的过程，无论是在开发端或是应用端。基础层面，本地数据中心需要做好准备；部署层面，需要开源社区的生态支持；应用层面，Docker不是万能药，更适用于跨环境的新应用，相应的开发、运维人员也要跟上容器技术发展的节奏。只有这样，才能让航运公司运输集装箱的时候更有相率，货物的质量更高。