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

创作场景

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