Docker在广大开发人员和行业专业人士当中仍然是个热门话题。先简要介绍一下Docker的功能：它作为一个容器系统来运行，拿来运行软件应用程序所需的构建模板(代码、运行时环境、系统工具和系统库)后，将它们包装成可以在任何服务器上执行的小巧程序包。Docker的优点在于，能够让在一台服务器上运行的应用程序实例数量比使用虚拟机这种方法多出两三倍。就未来的应用开发而言，这是一种大有前景的工具，但是即便Docker已取得了令人难以置信的进步，它依然存在诸多缺点。不妨看一下Docker的五大陷阱：

1. 多个Docker主机上的容器之间的联网有待加强

Docker公司首席执行官Solomon Hykes在LinuxCon大会上亲口说了这番话：Docker缺少容器之间的高层次联网功能。问题的一方面在于，Docker最佳实践并不鼓励在一个容器中运行多个服务;而这意味着与其他容器进行联系显得至关重要。在大规模环境下，如果容器需要与可能不在同一个Docker主机上的其他容器进行联系，这可能成为一大问题。由于许多应用程序出于安全和功能的考量而需要特定的联网环境，试图解决这个大规模问题时，Docker的原生联网功能多少受到了限制。

这个联网问题的另一个方面是，Docker缺少原生服务发现功能。由于应用程序和服务可能有众多广泛的组件，如果我们谈论大规模应用程序，服务发现功能变得必不可少。Docker社区在处理这个问题，一个办法就是实施etcd和skydns。

Docker 1.7推出了容器网络管理项目libnetwork;虽然它仍处于早期阶段，但是有望为解决原生Docker实施的网络难题提供一种方案。此外，已成立了Weave等第三方项目，扩展Docker的网络功能，但是这只不过给旨在简化开发、让开发应用程序和复杂更容易的软件增添了复杂性。

2. 规模扩展

对大多数初创企业而言，规模在一开始不是个问题。实际上，许多公司可能根本不需要好多台服务器来运行应用程序。然而，如果公司确实需要好多台服务器运行应用程序，构建Docker集群并非易事。许多项目围绕这个主题而日渐发展，包括Docker Swarm，Docker拿出的这个方案旨在将容器工作负载调度到Docker机器集群上。其主要问题是，Docker Swarm还没有准备好用于生产环境;对于那些现在就想开始构建Docker集群的公司而言，它们目前的选择很有限。

准备好用于生产环境的一种选择就是谷歌设立的项目：Kubernetes。其他选择基于Apache Mesos，或者以集群为中心的Linux发行版(比如CoreOS)。这些解决方案有一个共同点：安装架设起来并不容易。谷歌可以帮助你：你可以在谷歌计算引擎服务(Google Compute Engine)上轻松构建Kubernetes集群，但是那些想要构建专用Docker集群的企业客户又该如何是好?有一件事是肯定的，那就是构建Docker集群需要更容易些，围绕这方面的服务肯定会迅速涌现。

3. 安全

人们尚未就容器有多安全达成多大的一致，这本身就是个安全问题。相比虚拟机，容器提供的隔离和安全机制较弱。Docker的安全说明文档声称：

使用Docker运行容器(及应用程序)意味着要运行Docker守护进程。该守护进程目前需要根权限。

Docker需要访问根才能正常运行，而这意味着万一哪里出了岔子，有人大搞破坏的可能性会很大。为此，Docker给出的办法就是限制Docker只能被“可信用户”访问，但大家都知道，连可信用户有时也会设置安全性很差的密码。用户很容易做一些靠不住的事情，因为只要其中一个薄弱的密码被破解，主机上的所有容器就会遭殃。

虽然Docker能够将底层主机的许多方面与容器中运行的应用程序隔离开来，但这种隔离不如虚拟机来得强大。

NCR公司的安全专家Lenny Zeltzer强调了安全方面的差异：虚拟机在虚拟机管理程序上运行独立的操作系统实例，并不与底层操作系统共享内核。最终，只要黑客获得了容器操作系统的根访问权，随后就能够访问在Docker主机上以根用户身份运行的Docker守护进程――这确实可能会引起大麻烦。Docker的安全仍不成熟，也许更糟。

4. 并非适合每个人

Docker的现状会要求用户具备比普通开发人员更多的系统管理知识/技巧来使用Docker。许多Docker文章声称使用场合简单，却忽视了在多主机系统上使用Docker的复杂性。这可能会误人子弟，好多人不知道在开发环境下运行Docker实际需要什么。

在开发环境下使用Docker实际上需要开发人员在系统管理方面具备扎实的基础，学习过程可能很困难。换句话说，这根本不如想象的来得简单。

管理生产环境下的Docker需要具备还要多的技能。必须认真考虑诸多变化因素，比如：管理容器日志及数据、多个主机之间的联系、私有映像库、在没有停机的情况下指导容器部署以及更多变数。

5. 容器vs虚拟机

没错，相比虚拟机，容器具有明显的优点：能够在服务器实例上运行多个服务器实例，又不会减慢运行速度。而这种速度可能以降低了稳定性、安全性和兼容性为代价。在内核和用户空间中运行不相兼容或未经测试的实例会导致意想不到的行为。

虚拟机管理程序的性能比以往任何时候都要高;按需配置的虚拟机日益变得速度越来越快，成本越来越低。虚拟化性能大不一样，具体取决于工作负载的类型;繁重密集的应用程序显然会导致性能较低。这种情况下，容器化是一种比较好的方法，但是你应该使用容器以满足具体情况下的要求，不然可能不值得为了速度提升而冒风险。

Docker在更容易、更高效地、更快速地包装和交付应用程序方面确实大有希望。不管怎样，缺点相当明显，与现代虚拟机相比更是如此。撇开所有批评的声音，Docker正致力于为未来应用开发不断改进和创新，它已经迎来了1.8版本，正有条不紊地解决这些问题。

本文作者：佚名

来源：51CTO