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
评论