为什么Docker不能解决云上的所有问题

本文作者主要讲述了将业务迁移至Docker或者容器上需要了解的问题以及实现考虑的事情。很认同作者说的“having a powerful engine doesn’t get you far if you don’t have the rest of the car built to support it（即使有强大的引擎，缺少飞车的其余部件，你也不能走的更远）”，所以Docker只是一个引擎，真正应用到生产环境，还需要Kubernetes等相关工具的支持。

Docker和其他容器服务极具吸引力的原因是它们轻巧灵活。对于许多公司来说，为了让平台成熟度更上一层，他们希望将运行时的资源需求减少到和裸机运行一致（至少这是他们的意图）。

当你深入研究容器所带来的好处时，很容易看出为什么这么多公司已经开始着手：

对于规模小、松耦合的软件开发模式，能够更好地围绕容器化进行架构设计。我们（作者）是Threat Stack的大粉丝，我们持续投入资源支持那些依赖于Threat Stack的客户。实际上，我们最近发表官方声明我们的代理服务（agent）已经支持CoreOS。

不过，我们发现对于Docker以及其他容器服务的疑惑并不少见（考虑到容器服务快速成长与变化速度，这并不奇怪），比如说：

当然，容器是有很多好处，它提供了很好的方式让你探寻如何为你的公司更好地应用容器。不过，我们最好是能够先剥离其外表的酷炫，找到更好应用容器技术的方式。

许多公司目前正在运行大量的AWS实例用以加速新的应用程序、服务、数据库等，从而扩大自身业务。当从业务量特别小开始扩张时，会逐步感受到其带来的各种类型的开销：

这将导致无节制扩张、核心思想的不一致以及流程与预算挑战。财务部门希望了解Ops团队如何规划他们的增长和支出，安全团队会尽量插足业务增长情况，以确保公司达到其安全策略的目标，而工程师希望获知如何能够在他们需要快速部署的新组件上得到足够的灵活性。与此同时，业务还需要不断增长。

因此，一个关键问题是：我们该如何优化我们的流程，优化我们AWS环境（用以省钱），同时还能做我们需要做的事情？

Docker - 至少在表面上 - 似乎为这个难题提供了一个答案。

我们从具有很多AWS实例的公司那了解到一个常见的共同主题是通过增加单个实例配置和其上运行容器的规模来减少原始实例的数量。

在短期内，上述变化可能适用于某些用例。但从长远来看，与许多技术选型一样，你正在为另一种方式提供一套复杂性。为什么？

一种全新的技术栈

随着你开始大规模运行容器，你需要投入资源到一个管理与编排平台用以管理你的容器和资源。这需要一个容器自身的整体技术栈。

而且由于容器的使用模式仍然是一个比较新的课题，因此没有很多最佳做法可以参考借鉴，所以制定策略的过程取决于具体的实现，这将意味着生产和公司投入需要持续的迭代，这可能会影响交付计划。

管理度挑战

应用容器的其他较大挑战包括：

目前，就上述三个问题，我们能够找到很多“Docker合理化”建议。这就意味着很多公司正在转向容器化方案，因为他们能够解决他们遇到的具体用例。这是一件好事（演变的发生需要不断地迭代），但是当需要确定对于平台可用性、安全性以及成本效率的影响时，最好是提前制定出一套清晰的用例目标。

安全风险

虽然从表面上看将你的工作负载迁移到容器上是有意义的，但难题经常发生在细节处理上。随着容器具备更大的自由性与可选性，我们需要管理新的风险类型。 对于容器而言，安全性可能是非常具有挑战性的，因为你没有靠得住的最佳实践可以依赖。

随着你业务的扩展，你将需要了解如何对你正在使用的镜像，它们的构建方式以及提供给进程的访问范围进行适当的控制。你应该事先知道如下问题的答案：

一开始就明确这些问题的答案将有助于让你的实现过程清晰明确。

很多公司正在揭露容器复杂性方面所遇到的挑战，我们所了解到的一些难题如下：

问题会从很多维度产生。需要谨记的最重要的事情之一是，尽管Docker确实可以帮助你运行得更快，但即使拥有强大的引擎，缺少构建飞车的其余部件，也不能让你走的更远。

很明显，容器是云计算基础设施未来的重要组成部分，我们在Threat Stack中正在拥抱容器。我们希望看到越来越多的公司能够以开放的态度应用容器技术，从而与容器化中固有的风险认知相平衡。

好消息是将你的工作负载迁移到容器中并不会真正减少可见性，但你必须意识到Docker不能解决云上的所有问题，就像任何其他技术一样，应该用乐观和怀疑的态度来应用它。