本文共 2006 字，大约阅读时间需要 6 分钟。

Checkly是一款验证API端点正确性和浏览器点击流的监控工具。Checkly创始人Tim Nolet分享了他们在AWS上基于Docker的基础设施中借助Terraform实现零宕机部署的经验。

Checkly使用“工作者（worker）”运行用户提交的作业。每名工作者在一个Docker容器中运行，5个容器运行在一个EC2实例上。Checkly面临的挑战是，在不影响用户体验的情况下部署到AWS，同时支持代码的多版本和工作者代码的独立升级。他们使用Terraform的模块、滚动更新和自定义远程执行程序代码来实现这一目标。

Checkly使用Puppeteer框架自动化浏览器操作。Puppeteer是一个面向Chrome浏览器的无头Node API。每个Checkly工作者是一个Node进程，可以接受参数和运行测试，而不需要保存任何状态，这样便于根据请求流量进行横向扩展。用户请求被cron作业压入一个AWS SQS队列，工作者从中取出，并把结果放入另一个队列。失败的作业不会调用SQS API来删除消息，而是会重试。部署一个新版本到AWS是通过一个基于Docker的生命周期，后续使用Terraform原语进行滚动更新。代码会经过三个环境——开发、测试和生产。为了解更多信息，InfoQ联系了Checkly创始人Tim Nolet：

Docker容器中内置了单元测试代码，build、tag、push等Docker命令作为脚本包含在package.json中。我们把容器（标记上一个版本号和“测试”标签）push到我们的私有Docker注册库，然后完成一个测试EC2实例周期，后者会使用Terraform的“taint”命令pull最新的测试容器。

Terraform中的“taint”命令会强制销毁和重新创建资源（在本例中是EC2实例）。Checkly的团队让测试实例运行几天。如果一切顺利，Docker镜像将被重新标记为“最新”，所有生产EC2实例都将重复“taint”命令，从而完成滚动更新。Checkly的其中一个目标是允许应用程序的多个版本共存，这可能需要在代码或数据存储和消息队列中进行额外的处理。例如，如果SQS消息中使用的JSON格式发生了变化，那么在较短的时间内，这两种格式都必须处理，旧格式减少而新格式增加。Nolet详细阐述了他们的方法：

由于我们还很年轻，所以在整个数据传输对象或消息传递方案中还没有发生很大的变化。但我总是会在代码中解决这个问题。队列总线、存储和所有其他中间件都不是做这件事的合适位置。因此，如果这意味着要用一堆额外的if语句或case switch来处理这两种消息类型，那就这样吧。我们使用Postgres作为主要的数据存储，因为JSON字段非常适合于数据模型的小幅调整，不会带来很多麻烦。

Terraform提供了create_before_destroy等原语，以及Checkly使用的远程执行程序。create_before_destroy标志可以用于所有Terraform托管资源，用于确保在删除旧资源之前创建一个替换资源。当Terraform调用底层AWS配置程序时，remote-exec命令会不断检查Node进程是否在容器中运行，是就返回，然后向Terraform发出资源就绪的信号。它使用一个简单的grep命令来实现这一点。Checkly的Terraform代码被组织成模块，每个AWS区域一个模块。

Terraform代码可以通过测试工具包进行测试，比如Terratest，它可以验证Terraform管理的基础设施。然而，Checkly并没有为此使用任何测试框架，而是依赖于这样一个事实，“测试和生产环境相同，任何主要问题都可以在测试环境中发现”，Nolet如是说。

Checkly的基础Docker镜像是基于Ubuntu的，其中包含运行Puppeteer和无头Chrome所需的所有包，这增加了一些额外的库和字体。Docker容器运行一个PM2进程，该进程会启动一个Node进程。按照Nolet的说法，Docker策略这一部分很稳定，可能导致部署回滚的错误通常出现在实际的产品代码中。Checkly同时使用AWS CloudWatch和AppOptics进行监控。CloudWatch针对AWS队列大小、延迟以及实例的基本健康状况发出警告。AppOptics更侧重于应用程序，检查一些指标，比如最近10分钟里给定区域内的运行次数，或者给定区域内的运行时间。Checkly的状态仪表板是公开的。

查看英文原文：

活动推荐

转载地址：http://kqnnx.baihongyu.com/