【编者的话】本文作者主要讲述了将业务迁移至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等相关工具的支持。

【3 天烧脑式基于Docker的CI/CD实战训练营 | 北京站】本次培训围绕基于Docker的CI/CD实战展开，具体内容包括：持续集成与持续交付（CI/CD）概览；持续集成系统介绍；客户端与服务端的 CI/CD 实践；开发流程中引入 CI、CD；Gitlab 和 CI、CD 工具；Gitlab CI、Drone 的使用以及实践经验分享。

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

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

容器化他们的app以及支撑服务
实现隔离
减少环境差异
尽可能提升部署周期

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

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

如何实现容器的好处
对基础设施/运营的影响
对整体SDLC和Ops流程的影响

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

为什么是Docker？为什么是现在？

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

复用宿主机操作系统的计算资源
与应用程序无关的大量进程
管理更多的实例

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

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

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

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

例如，你有600个AWS实例，每个实例具有1个CPU和4-5GB的内存，那么你可能会思考可以通过Docker容器将AWS实例减少到100个，而每个实例具有32个GPU和64GB内存。然后你就可以减少AWS上的花费，因为你拥有了更少的实例数。这是正确的吗？其实没那么简单。

转向容器前应该思考什么

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

一种全新的技术栈

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

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

管理度挑战

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

如何管理容器
如何保持容器可见性
如何知道何时使用容器是适当的解决方案（何时又不是）

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

安全风险

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

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

开发人员是否被允许登录一个生产环境运行中的容器？
所有容器是否保持不变？
我们该怎么管理容器镜像大小？

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

真诚面对挑战

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

需要使用哪种类型以及相应数量的实例来运行这些容器？并且，真正的性能瓶颈是什么？
由于工作负载的特点随着时间的推移而变化，如何知道容器基础设施需要进行适配以及重新建模？
如何处理规模伸缩问题？何时向上扩展？何时向外扩展？该怎么减少外层规模而不引入SPoF？
如何处理容器的安全性，进程运行在容器中，它们可以访问哪些容器外部事物？

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

未来是光明的

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

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

原文链接：Why Docker Can’t Solve All Your Problems in the Cloud（翻译：肖远昊）