案例研究:

使小型分布式团队轻松部署

Dan Farrelly 用木工类比来解释他的公司 Buffer ，随着过去几年的发展，公司开始有这个问题。

“如果你自己做一张桌子，这很好！”公司的架构师说。“如果你请另一个人一起来做这个桌子，也许这个人可以在你抛光桌面时开始对腿进行抛光。但是，当你把第三个或第四个人带进来时，有人也许应该在另外一张桌子上工作。”需要处理越来越多不同的桌子，使 Buffer 走上了 Kubernetes 实现微服务和容器化的道路。

自2012年左右以来，Buffer 开始使用 Elastic Beanstalk ,这是亚马逊网络服务提供的网络基础设施编排服务。“我们部署了一个单一的PHP应用程序,它是在五六个环境中相同的应用程序，”Farrelly 说。“我们在很大程度上是一家产品驱动型的公司。” 这一切都是为了尽快给应用推出新功能并进行交付，如果能够正常运行，我们就不会花太多时间在上面。如果产品变得有点慢，我们可能会使用更快的服务器或只是增加一个实例，这些就已经足够了。然后继续前进。

但事情在2016年就到了头。随着应用提交修改的数量不断增加，Farrelly 和 Buffer 当时的首席技术官 Sunil Sadasivan 决定,是重新思考和构建其基础架构的时候了。“这是一个典型的单一庞大编码基数问题，”Farrelly说。公司的一些团队已经在开发环境中成功使用Docker，但在生产环境中，运行在 Docker 上的唯一应用程序是一个看不到真实用户流量的营销网站。他们希望在使用 Docker 上更进一步,下一步是寻找业务流程的选项。

首先，他们考虑了Mesosphere、DC/OS和Amazon Elastic Container Service(他们的数据系统团队已经将其用于某些数据管道作业)。虽然他们对这些产品印象深刻，但他们最终还是与 Kubernetes 合作。 Farrelly 说：“我们的应用仍在 AWS 上运行，但是我们的团队通过 Kubernetes 无需手动配置即可创建服务并按需创建负载均衡器，这是使用 Kubernetes 的最佳入门体验。”“我们不需要考虑如何配置这个或那个,特别是相较于以前的 Elastic Beanstalk 环境，它为我们提供了一个自动配置的负载均衡器。我真的很喜欢 Kubernetes 对命令行的控制，只需要对端口进行配置，这样更加灵活。Kubernetes 是为做它所做的事情而设计的,所以它做得非常好。”

Kubernetes 所做的所有事情都很好地适应了 Buffer 的需求。Farrelly 说：“我们希望拥有一种流动基础架构，开发人员可以创建一个应用程序，并在必要时部署并进行水平扩展。”“我们很快就使用一些脚本来设置几个测试集群，在容器中构建了一些小的概念性验证应用程序，并在一小时内部署了这些内容。我们在生产中运行容器方面经验很少。令人惊奇的是,我们能很快地用 Kubernetes 来处理。”

最重要的是，它为公司最显著的特征之一提供了强大的解决方案：他们的远程团队分布在十几个不同的时区。Farrelly 说：“对我们的基础设施有深入了解的人生活在不同于我们相对集中的时区，而我们的大部分产品工程师都住在其他地方。”“因此，我们确实希望有人能够尽早掌握这套系统并利用好它，而不必担心部署工程师正在睡觉。否则，人们会为了一些东西必须得等待12到24小时左右。看到人们前进得更快，这真的很酷。”

Farrelly 说，Buffer 拥有相对较小的工程团队，只有 25 人，只有少数人从事基础设施工作，大多数前端开发人员都需要“一些强大的配置能力，以便部署任何他们想要的内容。”以前，“只有几个人知道如何用旧的方式设置一切。有了这个系统，审查文档变得很容易，并且能很快地看到效果。它降低了我们获取在开发环境中所需要一切的门槛。因为我们团队的人数不足以来构建所有这些工具或像其他大公司那样管理基础架构。”

为了帮助解决这一问题，Buffer 开发人员编写了一个部署机器人，该机器人包装了 Kubernetes 部署过程，并且每个团队都可以使用。”“以前,我们的数据分析师会更新 Python 分析脚本，并且必须等待该团队的主管单击该按钮并部署它，”Farrelly 解释道。“现在，我们的数据分析师可以进行更改，输入 Slack 命令，‘/deploy’,它会立即进行部署。他们不需要等待这些缓慢的周转时间，他们甚至不知道它在哪里运行。这些都不重要了。

团队使用 Kubernetes 从头开始构建的第一个应用程序是一种新的图像大小调整服务。作为一种社交媒体管理工具，它允许营销团队通过发帖进行协作，并通过多个社交媒体配置文件和网络发送更新，Buffer 必须能够根据需要调整照片的大小，以满足不同的社交网络。Farrelly 说：“我们一直有这些拼凑在一起的解决方案。”

为了创建这项新服务，一位高级产品工程师被指派学习 Docker 和 Kubernetes，然后构建服务、测试、部署和监视服务，他能够相对快速地完成该服务。Farrelly说：“在我们以往的工作方式中，反馈循环流程要长得多，而且很微妙，因为如果你部署了某些东西，就存在破坏其他东西的风险。”“我们通过围绕 Kubernetes 构建的部署类型，能够及时检测 Bug 并修复它们，并使其部署得超快。这一秒正在修复漏洞,不一会就上线运行了。”

此外，与旧系统不同，他们只需一个命令就可以水平缩放内容。“当我们推出它,”Farrelly说，“我们可以预测，只需点击一个按钮。这使我们能够处理用户对系统的需求,并轻松扩展以处理它。”

他们以前不能做的另外一件事是金丝雀部署。Farrelly说，这种新功能“使我们在部署重大变革方面更加自信。”“以前，虽然进行很多测试但仍表现不错，但它也存在很多‘手指交叉’。这是每天运行 800000 次的东西，这是我们业务的核心。如果它不工作，我们的业务也无法运行。在 Kubernetes 世界中，我可以执行金丝雀部署以测试 1%，如果它不工作，我可以很快将其关闭。这使我们在快速部署和推出新更改的同时降低风险的能力得到了提高。”

到 2016 年 10 月，Buffer 54% 的流量都通过其 Kubernetes 集群。Farrelly 说：“我们很多传统功能仍然运行正常，这些部分可能会转移到 Kubernetes 或永远留在我们的旧设置中。”但该公司当时承诺，“所有新的开发，所有新功能,将在Kubernetes上运行。”

2017年计划是将所有旧应用程序迁移到新的 Kubernetes 集群，并运行他们从旧基础架构中撤出的所有内容，以及他们正在另一个 Kubernetes 集群上开发的新服务。Farrelly 说：“我想为团队中的每个人带来我们早期服务的所有好处。”

对于 Buffer 的工程师来说，这是一个令人兴奋的过程。“每次部署新服务时，我们都需要弄清楚:好的，体系结构是什么？这些服务如何沟通？构建此服务的最佳方式是什么？”Farrelly说。“然后，我们使用 Kubernetes 的特性将所有部分聚合到一起。在学习如何设计面向服务的体系结构时，它使我们能够进行试验。以前，我们只是不能做到这一点。这实际上给了我们一个空白的白板，所以我们可以做任何我们想要的。”

部分空白是 Kubernetes 提供的灵活性，如果某一天 Buffer 可能想要或需要改变他的云服务。“这是与云无关的，所以也许有一天我们可以切换到谷歌或其他地方，”Farrelly 说。“我们非常依赖亚马逊的基础服务，但很高兴知道，如果我们需要的话，我们可以搬走。”

此时，Buffer 团队无法想象以任何其他方式运行其基础结构，他们很乐意传播这一信息。Farrelly 说：“如果你想在生产中运行容器，拥有像谷歌内部使用的那种效果，那么 Kubernetes 就是一个很好的方法。”“我们是一个相对较小的团队，实际上运行 Kubernetes，我们之前从来没来做过这样的事情。因此，它比你想象的更容易上手，这正是我想要告诉正在尝试使用它的人们的一件很重要的事。挑几个应用，把它们准备好，在机器上运行几个月，看看它能处理的怎么样。通过这种方式你可以学到很多东西。”