四、环境准备：搭建本地 Secrets 服务与 SDK

说实话，环境准备这步看着简单，但坑是真不少。我记得最早做类似的调优测试时，就在本地环境上折腾了大半天。后来总结出一个习惯：先把本地开发环境搭得跟生产环境尽可能接近，但资源消耗要小得多——Vault 的 dev 模式就是个好选择。

这一章咱们重点做三件事：起一个本地 Vault 服务、装好 Python 的 SDK（hvac 和 boto3）、做基础配置验证。你想想看，如果没有一个稳定的本地环境，后面的并发压测根本没法跑。所以别急，一步步来。

4.1 本地 Vault 服务搭建（Dev 模式）

Vault 的 dev 模式说白了就是为了开发测试用的。它自动帮你初始化、解封，还自带一个 root 。我个人习惯用 Docker 来跑，干净、快、用完就删。

先看命令，我一般用这个一行搞定：

# 启动 Vault dev 模式，指定端口和 root 
docker run -d --name vault-dev \
  -p 8200:8200 \
  -e 'VAULT_DEV_ROOT__ID=myroot-' \
  vault:1.13.3 server -dev

启动后，验证一下服务是否正常。习惯用 curl 或者直接看容器日志：

# 查看 Vault 是否就绪
curl -s http://127.0.0.1:8200/v1/sys/health | jq .

你会看到类似这样的输出：

字段	值	含义
initialized	true	已初始化
sealed	false	已解封，可以读写
standby	false	非 standby 模式

4.2 安装 Secrets SDK（hvac & boto3）

SDK 是咱们和 Vault 打交道的桥梁。压测场景下，我一般用 hvac 这个纯 Python 客户端库，它封装了 Vault 的 HTTP API，用起来非常顺手。boto3 是 AWS 的 SDK，但注意，它也能通过 IAM 角色或静态凭证访问 AWS Secrets Manager 或其他密钥服务。不过本章我们主要测试 hvac。

安装很简单：

pip install hvac boto3

你可以用虚拟环境隔离依赖，我习惯这么做：

python -m venv venv
source venv/bin/activate
pip install hvac==1.2.0 boto3==1.28.0

版本这块我特意锁了一下，避免因为版本更新导致的兼容性问题。你想想看，压测时如果 SDK 内部有个小 bug，排查起来多痛苦。

下面是个简单的验证脚本：

import hvac

client = hvac.Client(
    url='http://127.0.0.1:8200',
    ='myroot-'
)
print(f"Vault 是否就绪: {client.is_authenticated()}")

如果输出 True，说明 SDK 已经能正常连上 Vault 服务了。

4.3 基础配置与常用环境变量

环境变量是配置管理的好方法，尤其是在压测时需要切换不同环境时。我建议把所有配置集中管理，而不是散落在代码里。

环境变量	示例值	说明
VAULT_ADDR	http://127.0.0.1:8200	Vault 服务地址
VAULT_	myroot-	认证
VAULT_NAMESPACE	（空）	企业版才需要
VAULT_SKIP_VERIFY	true	开发环境跳过 TLS 验证

我在项目里通常会写一个 .env 文件，然后用 python-dotenv 加载。这样做的好处是：不同团队成员各自维护自己的配置文件，互不影响。

4.4 基础读写与 管理

配置好环境后，咱们试试最基础的操作：写一个 secret 进去，再读出来。这步虽然简单，但能帮你快速确认管道是否通畅。

import hvac

client = hvac.Client(url='http://127.0.0.1:8200', ='myroot-')

# 写一个 secret
client.secrets.kv.v2.create_or_update_secret(
    path='myapp/config',
    secret={'db_password': 's3cret!', '': 'abc123'}
)

# 读出来
read_response = client.secrets.kv.v2.read_secret_version(
    path='myapp/config'
)
print(read_response['data']['data'])

这段代码会输出你刚写入的字典。嗯，这里要注意：Vault 的 KV 引擎分 v1 和 v2 版本。Dev 模式默认启用 v2，多了版本控制和删除保护。我问你，如果压测时频繁写入同一个 key，v2 的版本管理会不会成为瓶颈？答案是会的——所以后面章节我们会专门优化这块。

管理也很重要。Dev 模式的 root 权限太大，我建议创建一个有限权限的 用于压测：

# 创建一个只读策略
policy = '''
path "myapp/data/*" {
  capabilities = ["read", "list"]
}
'''
client.sys.create_or_update_policy(name='readonly-policy', policy=policy)

# 创建  并绑定策略
new_ = client.auth..create(
    policies=['readonly-policy'],
    ttl='1h'
)
print(new_['auth']['client_'])

这样做的好处是：压测时即使 泄漏，影响范围也小。我在之前的项目中就吃过 权限过大的亏，后来养成了“最小权限原则”的习惯。

4.5 本章知识体系结构

下面我用一张 SVG 图把整个环境准备的流程串起来，方便你理解各部分之间的关系。

这张图把本章的三个主要步骤串起来了：先搭 Vault 服务，再装 SDK，最后做基础读写验证。我自己每次搭新环境都会画类似的图，防止漏掉哪个环节。

4.6 验证清单

最后，我列个快速检查清单。你每次换环境或重启 Vault 后，按这个清单过一遍就行：

• Vault 容器是否运行：docker ps | grep vault
• API 健康检查：curl http://127.0.0.1:8200/v1/sys/health 返回 200
• SDK 鉴权：hvact 客户端 is_authenticated() 返回 True
• 基本读写：能成功写入并读取一个 secret
• 权限：压测用的 只有必要路径的权限