Honeycomb 团队访谈：将基础设施作为代码放到 CD 管道的收益和挑战

Honeycomb 工具能够对生产系统进行内省和探查。该团队长期以来都是基础设施即代码（infrastructure-as-code，IaC）的先锋，目前他们使用 HashiCorp Terraform 进行配置即代码（configuration-as-code）管理。最近，他们 推动 将二进制发布过程的严格性引入到基础设施配置发布之中。

InfoQ 有幸采访到了该团队，询问了他们转向集中式 push-on-green（即自动化测试通过之后自动部署——译者注）部署的情况，并了解了这种做法如何降低可靠性风险以及以前有多么痛苦。

InfoQ：在最初的文章中你们曾建议，通过不断地将基础设施部署为代码，已经消除了运维的风险。付出这样的代价这么做，值得吗？

Honeycomb 团队：是的，这种方式能够让我们更快地行动，从稳定状态的每周两到四次 Terraform 部署加快到每天两次以上的部署，我们还用到了一些新的 AWS 和 Terraform 特性。

基础设施工程师担心现在我们可能会面临另一方面的风险，尽管我们比以前行动更加快速，但是相对于做出的变更，风险增长的比例要更低。他的担心在于我们已经对大规模的 Terraform 变更习以为常，以至于对它们的审查要比理应的情况少得多……但是，我们也反驳说，这些变更可能已经在人们的 Terraform 客户端执行过了，而没有运行线上运行的审查。

InfoQ：这帮助你们实现基础设施成本节省了吗？

Honeycomb：与其他 SaaS 分析初创公司类似，我们的云账单占了总支出的很大一部分。作为这种转变的一部分，升级 Terraform 实例意味着我们可以使用 2018 年 11 月发布的 AWS 特性 ，该特性允许将我们已经使用的自动伸缩组与峰值负载的 Spot 请求结合起来，实现自动替换 / 重调度实例。

InfoQ：我注意到你们使用了 HashiCorp 的 Terraform CI 工具。你们建议其他人也使用这种方式吗？

Honeycomb：是的，尤其要考虑到 Terraform Cloud 要比我们之前使用的工具便宜得多。我们现有的 CI 工具没有管理 Terraform 状态，同时，我们也不希望让它访问可变的生产环境。借助易于理解的 Terraform 的开箱即用功能，再加上购买了 HashiCorp 的支持和 bug 优先解决的特权，这些保证了我们的胜利。在此之前，我想说的是，如果没有 Terraform Enterprise 的收费服务，为 Terraform 实现合适的 CI/CD 是很有挑战性的。我们的报价是几万美元，这对我们来说有点贵，因为我们公司有四个人已经接触过 Terraform。

InfoQ：你们下一步作何打算呢？

Honeycomb：我们还有很多的工作要做，以支撑 Honeycomb 的特性和正在进行中的操作，以及明年的规模扩张。另外，我还知道，在我们的 2020 愿望清单中，包括中心化 Chef 管理，这是因为，虽然我们使用 Terraform 将 AWS 基础设施作为代码来处理，但我们还使用 Chef 引导单个节点，这个过程没有我们希望的那么平滑。

InfoQ：你们有计划降低基础设施工程师主管所提到的更高的风险吗，或者你们是否认为这种风险是可接受的？

Honeycomb：我们想要编写更多的“策略即代码（policy as code） Sentinel 脚本 ，加强整体路径的可用性和抗成本风险的能力。目前，这件事还排不到最重要的前五件事中，因为基础设施应该服务于业务需求，在列车轨道没有达到那么远之前，设想那么远没有太大的意义。

InfoQ：在将你们的基础设施即代码引入 CI/CD 管道时，面临的最大挑战是什么，其他人可以在你们的经验中学到什么？

Honeycomb：这个过程挺简单，也没有太多的痛苦。将 backend s3 替换为 backend remote {} 是非常简单的，但是显然，我们必须让大家将使用 Terraform Cloud 账号作为初始工作流的一部分，而不是在本地自己的机器上运行工作流。

最痛苦的可能是对 Terraform 的升级，这个升级并不是强制性的但仍然会有一定的用处。在此之前，我们使用的是 0.10 版本上，迁移到 Terraform 0.12 引入了语言更改，但是使用它们的迁移工具，也会有很大的代码差异。

原文链接：

Benefits and Challenges of Bringing Infrastructure as Code into a CD pipeline: Honeycomb Q&A