67 lines
2.5 KiB
Markdown
67 lines
2.5 KiB
Markdown
# 🎯 HashiCorp Stack 运维集思录
|
||
|
||
## 📍 关键里程碑记录
|
||
|
||
### ✅ 2025-09-30 标志性成功
|
||
**Nomad完全恢复正常运行**
|
||
- **成功指标**:
|
||
- Nomad server集群: 7个节点全部在线 (ch2.global为leader)
|
||
- Nomad client节点: 6个节点全部ready状态
|
||
- 服务状态: nomad服务运行正常
|
||
- **关键操作**: 恢复了Nomad的consul配置 (`address = "master:8500,ash3c:8500,warden:8500"`)
|
||
|
||
---
|
||
|
||
### ❌ 当前大失败
|
||
**Vault job无法部署到bj-warden节点**
|
||
- **失败现象**:
|
||
```
|
||
* Constraint "${node.unique.name} = bj-warden": 5 nodes excluded by filter
|
||
* Constraint "${attr.consul.version} semver >= 1.8.0": 1 nodes excluded by filter
|
||
```
|
||
- **根本原因发现**: consul-cluster job约束条件为 `(master|ash3c|hcp)`，**warden节点被排除在外**！
|
||
- **历史教训**: 之前通过移除service块让vault独立运行，但这导致vault无法与consul集成，项目失去意义
|
||
- **深层问题**: 不是consul没运行，而是**根本不允许在warden节点运行consul**！
|
||
|
||
---
|
||
|
||
## 🎯 核心矛盾
|
||
**Vault必须与Consul集成** ←→ **bj-warden节点没有consul**
|
||
|
||
### 🎯 新思路：给Nomad节点打consul标签
|
||
**用户建议**: 给所有运行consul的nomad节点打上标签标识
|
||
- **优势**: 优雅、可扩展、符合Nomad范式
|
||
- **实施路径**:
|
||
1. 给master、ash3c等已有consul节点打标签 `consul=true`
|
||
2. 修改vault job约束条件，选择有consul标签的节点
|
||
3. 可选：给warden节点也打标签，后续部署consul到该节点
|
||
|
||
---
|
||
|
||
### 🔍 当前发现
|
||
- 所有节点Attributes为null，说明Nomad客户端配置可能有问题
|
||
- 用nomad拉起consul不能自动让节点具备consul属性
|
||
- **重大发现**：nomad node status -verbose 和 -json 输出格式数据不一致！
|
||
- verbose模式显示Meta中有"consul = true"
|
||
- JSON格式显示Meta为null
|
||
- 可能是Nomad的bug或数据同步问题
|
||
|
||
### 🎯 下一步行动
|
||
1. **调查Attributes为null的原因** - 检查Nomad客户端配置
|
||
2. **考虑用ansible部署consul** - 确保consul作为系统服务运行
|
||
3. **验证meta数据一致性** - 解决verbose和json格式数据不一致问题
|
||
4. **重新思考节点标签策略** - 基于实际可用的数据格式制定策略
|
||
|
||
---
|
||
|
||
## 📋 待办清单
|
||
- [ ] 检查bj-warden节点的consul配置
|
||
- [ ] 在bj-warden节点启动consul服务
|
||
- [ ] 验证vault job成功部署
|
||
- [ ] 确认vault与consul集成正常
|
||
|
||
---
|
||
|
||
## 🚫 禁止操作
|
||
- ❌ 移除vault job的service块 (会导致失去consul集成)
|
||
- ❌ 忽略consul版本约束 (会导致兼容性问题) |