Consul 负载测试 AMI 构建实战：使用 Packer 定制 Consul 与 k6 压测镜像-开发者社区

Consul 负载测试 AMI 构建实战：使用 Packer 定制 Consul 与 k6 压测镜像

【免费下载链接】consulConsul is a distributed, highly available, and data center aware solution to connect and configure applications across dynamic, distributed infrastructure.项目地址: https://gitcode.com/gh_mirrors/con/consul

本指南以 Consul 仓库中的test/load/packer/README.md为核心，完整讲解如何用 Packer 在 AWS 上构建两类负载测试镜像：预装 Consul 并接入 Datadog 遥测的 Consul AMI，以及预装 k6 压测引擎的 Load Test AMI。读完本文，你将掌握完整的环境变量配置、packer build流程、镜像内各配置脚本的作用，以及 k6 压测脚本的参数含义，并能为后续 Terraform 部署负载测试基础设施准备好 AMI ID。

负载测试体系概览

在深入 Packer 构建之前，先了解这套 AMI 在整个负载测试体系中的位置。根据 test/load/README.md，该负载测试用于在压力场景下采集 Consul 的基准性能指标，确保版本发布或重大变更期间不出现性能回退。默认情况下，测试运行10 分钟，由 k6 发起25 个虚拟用户的并发请求；测试实例规格为t2.small，Consul 集群节点规格为m5n.large；Consul 的全部指标会推送到 Datadog 仪表盘供分析。

基础设施搭建依赖 Gruntwork 的 Terraform AWS Consul 模块，默认在3 个可用区创建3 台 Consul Server。负载测试实例（预装了 k6）将请求发送到负载均衡器，负载均衡器把流量分发到 Consul Client，再由 Client 转发到 Server。

整个流程分为两个阶段：

使用Packer生成 Consul AMI 与 Load Test AMI（即本文主题）；
使用Terraform在 AWS 中拉起基础设施，packer与terraform两个目录分别对应这两个阶段，目录结构见 test/load/packer 与 test/load/terraform。

前置准备

开始构建前需要准备以下内容：

安装 Terraform 与 Packer；
一个 AWS 账户，并配置好凭据——最简便的方式是设置AWS_ACCESS_KEY_ID、AWS_SECRET_ACCESS_KEY、AWS_DEFAULT_REGION三个环境变量；
一个 Datadog 账户，并在账户设置中创建 API Key（无需下载 Datadog 客户端）。

构建成功后，Packer 会输出 AMI ID，务必保存，因为后续 Terraform 阶段会用到。生成的 AMI 带有公共标签Environment = "consul-load-test"，便于在 AWS 控制台或 Terraform 中筛选识别。典型输出如下：

==> Builds finished. The artifacts of successful builds are: --> amazon-ebs: AMIs were created: us-east-1: ami-19601070

构建 Consul AMI

Consul AMI 的目标是产出一个预装 Consul、并已接入 Datadog 遥测的 Ubuntu 18.04 镜像。所有相关文件位于 test/load/packer/consul-ami 目录。

环境变量配置

在consul-ami/目录下依次执行：

# 1) 获取你的 Datadog API Key，并设置为环境变量 export DD_API_KEY=$YOURDDAPIKEYHERE # 2) 设置 Packer 使用的 AWS 区域 export AWS_DEFAULT_REGION=us-east-1 # 3) 配置 AWS 凭据 export AWS_ACCESS_KEY_ID=#YOURAWSKEYID export AWS_SECRET_ACCESS_KEY=YOURAWSKEY

这三个环境变量分别对应consul.pkr.hcl中声明的两个变量：aws_region默认取${env("AWS_DEFAULT_REGION")}，dd_api_key默认取${env("DD_API_KEY")}，源码见 consul.pkr.hcl。

执行构建

packer build consul.pkr.hcl

构建模板源码剖析

consul.pkr.hcl 的关键逻辑如下：

基础镜像选择：通过data "amazon-ami"数据源，在指定区域过滤ubuntu/images/hvm-ssd/ubuntu-bionic-18.04-amd64-server-*命名的官方 Ubuntu 18.04 AMI（owner 为099720109477），取最新一个作为源镜像，要求架构x86_64、卷类型gp2、根设备ebs；
构建源：使用amazon-ebs构建器，实例类型t2.micro，AMIs 命名格式为consul-ubuntu-<日期>T<时间>-<uuid>，并打上Environment = "consul-load-test"标签；
构建流程（依次执行多个 provisioner）：
1. 创建/home/ubuntu/scripts目录；
2. 将本地scripts/目录上传到/home/ubuntu；
3. 执行 setup-systemd-resolved 脚本，配置系统 DNS 转发到 Consul；
4. 通过 Datadog 官方安装脚本安装 Datadog Agent 7（DD_AGENT_MAJOR_VERSION=7）；
5. 以 sudo 执行 move-files.sh，把 Datadog 与 Consul 的配置放到正确位置。

镜像内配置脚本详解

DNS 转发脚本 setup-systemd-resolved：仅支持 Ubuntu 18.04，通过iptables将本机 53 端口的 UDP/TCP 流量重定向到 Consul DNS 端口（默认 8600），并修改/etc/systemd/resolved.conf，使~consul域的查询转发到 Consul（默认127.0.0.1）。相关配置可参考 Consul 官方文档与 hashicorp/consul 的 issue #4155。

配置文件移动脚本 move-files.sh：负责把conf.yaml移动到 Datadog Consul 集成目录、datadog.yaml移动到 Datadog Agent 配置目录、telemetry.json移动到/opt/consul/config/，并用sed将DD_API_KEY写入datadog.yaml的api_key字段，同时设置dd-agent用户对相关文件的所有权。

Datadog Consul 集成配置 conf.yaml：启用 Consul check，采集http://localhost:8500的指标，并开启 leader 自检（self_leader_check）、网络延迟检查（network_latency_checks）与目录检查（catalog_checks）。

Datadog Agent 配置 datadog.yaml：除了api_key、logs_enabled外，还定义了一组dogstatsd_mapper_profiles，用正则把 Consul 的 DogStatsD 指标映射为更易查询的指标名：

匹配模式	映射后的指标名	附加标签
`consul\.http\.([a-zA-Z]+)\.(.*)`	`consul.http.request`	`http_method`、`path`
`consul\.raft\.replication\.appendEntries\.logs\.([0-9a-f-]+)`	`consul.raft.replication.appendEntries.logs`	`consul_node_id`
`consul\.raft\.replication\.appendEntries\.rpc\.([0-9a-f-]+)`	`consul.raft.replication.appendEntries.rpc`	`consul_node_id`
`consul\.raft\.replication\.heartbeat\.([0-9a-f-]+)`	`consul.raft.replication.heartbeat`	`consul_node_id`

这意味着你在 Datadog 仪表盘中可以直接按 HTTP 方法、请求路径、节点 ID 维度检索 Consul 的通信指标——测试完全基于对 Consul HTTP 端点的请求，这部分指标恰恰是评估压测结果最相关的。

Consul 遥测配置 telemetry.json：声明 Consul 所在数据中心与 DogStatsD 上报地址：

{ "datacenter": "us-east-2", "telemetry": { "dogstatsd_addr": "127.0.0.1:8125" } }

注意：README 说明该文件中的 datacenter 默认值为us-east-1，而当前仓库中实际值为us-east-2。构建前请按你的实际测试区域调整。

自定义 Consul AMI

添加 Datadog 标签：可在scripts/datadog.yaml文件的tags字段中追加自定义标签，例如"consul_version" : "consulent_175"。这些标签会随指标上报，可在 Datadog 仪表盘中直接检索过滤；
修改数据中心：通过调整scripts/telemetry.json中的datacenter字段实现。

构建 Load Test AMI

Load Test AMI 预装了 k6 压测引擎与压测脚本，相关文件位于 test/load/packer/loadtest-ami 目录。

构建步骤

# 1) 设置 Packer 使用的 AWS 区域 export AWS_DEFAULT_REGION=us-east-1 # 2) 执行构建 packer build loadtest.pkr.hcl

构建模板与安装脚本

loadtest.pkr.hcl 与 Consul AMI 的模板结构类似：同样基于 Ubuntu 18.04 官方 AMI、t2.micro实例、associate_public_ip_address = true；构建时上传scripts/目录后执行 install-k6.sh。

install-k6.sh 完成三件事：

调高系统文件句柄上限（写入fs.file-max = 2097152并提升ulimit），保证高并发压测时不因句柄耗尽而失败；
通过官方 APT 源安装 k6（导入 GPG 公钥C5AD17C747E3415A3642D57D77C6C491D6AC1D69并添加https://dl.k6.io/deb软件源）；
为压测脚本设置可执行权限。

k6 压测脚本解析

k6 执行的压测脚本为 loadtest.js。每个虚拟用户（VU）的迭代会做两件事：

写入 K/V：生成 UUID 作为 key，向/v1/kv/<key>发起PUT，写入 JSON 值，断言响应码必须为 200，否则fail中止；
注册服务：读取service.json模板并覆写Name字段为 UUID，向/v1/agent/service/register发起PUT，同样断言 200。

请求目标地址由环境变量LB_ENDPOINT在运行时注入（http://${__ENV.LB_ENDPOINT}:8500），指向负载均衡器。脚本选项（options）定义了默认压测参数：

export let options = { // 25 virtual users vus: 25, // 10 minute duration: "10m", // 95% of requests must complete below 2.5s thresholds: { http_req_duration: ["p(95)<2500"] }, };

即25 个虚拟用户、持续 10 分钟，并设置阈值：95% 的请求必须在 2.5 秒内完成，否则视为测试不达标。如需向更多 Consul 端点发起请求，直接修改此脚本即可；k6 的更多用法可参考其官方文档。

服务注册模板 service.json：定义了注册服务的默认载荷，包括Address（127.0.0.1）、Port（8000）、Meta（如redis_version）以及 HTTP 健康检查Check配置（请求方法、Header、Body、超时、间隔、临界后自动注销时间等）。

从 AMI 到完整压测链路

构建完成两类 AMI 后，接下来：

保存输出的 AMI ID（两条构建各产出一个）；
阅读 test/load/terraform/README.md，按说明在 AWS 中拉起负载测试基础设施；
测试结果可在 Datadog 仪表盘查看，也可直接查看 Terraform Apply 的输出。

关于结果分析，Consul 暴露了数百个指标，压测本质是持续向 HTTP 端点发起请求，因此 Datadog 关于 Consul 通信类指标（communication）的分析最值得关注——这也正是 datadog.yaml 中那些映射规则存在的意义：把consul.http.*、consul.raft.replication.*指标解析成带方法、路径、节点 ID 标签的规范化指标，方便在仪表盘上直接聚合对比。