21 KiB

Raw Blame History

🏗️ 基础设施管理项目

这是一个现代化的多云基础设施管理平台，专注于 OpenTofu、Ansible 和 Nomad + Podman 的集成管理。

📝 重要提醒 (Sticky Note)

✅ Consul集群状态更新

当前状态：Consul集群运行健康，所有节点正常运行

集群信息：

Leader: warden (100.122.197.112:8300)
节点数量: 3个服务器节点
健康状态: 所有节点健康检查通过
节点列表:
- master (100.117.106.136) - 韩国主节点
- ash3c (100.116.80.94) - 美国服务器节点
- warden (100.122.197.112) - 北京服务器节点，当前集群leader

配置状态：

Ansible inventory配置与实际集群状态一致
所有节点均为服务器模式
bootstrap_expect=3，符合实际节点数量

依赖关系：

Tailscale (第1天) ✅
Ansible (第2天) ✅
Nomad (第3天) ✅
Consul (第4天) ✅ 已完成
Terraform (第5天) ✅ 进展良好
Vault (第6天) ⏳ 计划中
Waypoint (第7天) ⏳ 计划中

下一步计划：

继续推进Terraform状态管理
准备Vault密钥管理集成
规划Waypoint应用部署流程

🎯 项目特性

🌩️ 多云支持: Oracle Cloud, 华为云, Google Cloud, AWS, DigitalOcean
🏗️ 基础设施即代码: 使用 OpenTofu 管理云资源
⚙️ 配置管理: 使用 Ansible 自动化配置和部署
🐳 容器编排: Nomad 集群管理和 Podman 容器运行时
🔄 CI/CD: Gitea Actions 自动化流水线
📊 监控: Prometheus + Grafana 监控体系
🔐 安全: 多层安全防护和合规性

🔄 架构分层与职责划分

⚠️ 重要：Terraform 与 Nomad 的职责区分

本项目采用分层架构，明确区分了不同工具的职责范围，避免混淆：

1. Terraform/OpenTofu 层面 - 基础设施生命周期管理

职责: 管理云服务商提供的计算资源（虚拟机）的生命周期
操作范围:
- 创建、更新、删除虚拟机实例
- 管理网络资源（VCN、子网、安全组等）
- 管理存储资源（块存储、对象存储等）
- 管理负载均衡器等云服务
目标: 确保底层基础设施的正确配置和状态管理

2. Nomad 层面 - 应用资源调度与编排

职责: 在已经运行起来的虚拟机内部进行资源分配和应用编排
操作范围:
- 在现有虚拟机上调度和运行容器化应用
- 管理应用的生命周期（启动、停止、更新）
- 资源分配和限制（CPU、内存、存储）
- 服务发现和负载均衡
目标: 在已有基础设施上高效运行应用服务

3. 关键区别

Terraform 关注的是虚拟机本身的生命周期管理
Nomad 关注的是在虚拟机内部运行的应用的资源调度
Terraform 决定"有哪些虚拟机"
Nomad 决定"虚拟机上运行什么应用"

4. 工作流程示例

1. Terraform 创建虚拟机 (云服务商层面)
   ↓
2. 虚拟机启动并运行操作系统
   ↓
3. 在虚拟机上安装和配置 Nomad 客户端
   ↓
4. Nomad 在虚拟机上调度和运行应用容器

重要提醒: 这两个层面不可混淆，Terraform 不应该管理应用层面的资源，Nomad 也不应该创建虚拟机。严格遵守此分层架构是项目成功的关键。

📁 项目结构

mgmt/
├── .gitea/workflows/           # CI/CD 工作流
├── tofu/                       # OpenTofu 基础设施代码 (基础设施生命周期管理)
│   ├── environments/          # 环境配置 (dev/staging/prod)
│   ├── modules/               # 可复用模块
│   ├── providers/             # 云服务商配置
│   └── shared/                # 共享配置
├── configuration/             # Ansible 配置管理
│   ├── inventories/          # 主机清单
│   ├── playbooks/            # 剧本
│   ├── templates/            # 模板文件
│   └── group_vars/           # 组变量
├── jobs/                      # Nomad 作业定义 (应用资源调度与编排)
│   ├── consul/               # Consul 集群配置
│   └── podman/               # Podman 相关作业
├── configs/                   # 配置文件
│   ├── nomad-master.hcl      # Nomad 主节点配置
│   └── nomad-ash3c.hcl       # Nomad 客户端配置
├── docs/                      # 文档
├── security/                  # 安全配置
│   ├── certificates/         # 证书文件
│   └── policies/             # 安全策略
├── tests/                     # 测试脚本和报告
│   ├── mcp_servers/          # MCP服务器测试脚本
│   ├── mcp_server_test_report.md  # MCP服务器测试报告
│   └── legacy/               # 旧的测试脚本
├── tools/                     # 工具和实用程序
├── playbooks/                 # 核心Ansible剧本
└── Makefile                   # 项目管理命令

架构分层说明:

tofu/ 目录包含 Terraform/OpenTofu 代码，负责管理云服务商提供的计算资源生命周期
jobs/ 目录包含 Nomad 作业定义，负责在已有虚拟机内部进行应用资源调度
这两个目录严格分离，确保职责边界清晰

注意： 项目已从 Docker Swarm 迁移到 Nomad + Podman，原有的 swarm 目录已不再使用。所有中间过程脚本和测试文件已清理，保留核心配置文件以符合GitOps原则。

🔄 GitOps 原则

本项目遵循 GitOps 工作流，确保基础设施状态与 Git 仓库中的代码保持一致：

声明式配置: 所有基础设施和应用程序配置都以声明式方式存储在 Git 中
版本控制和审计: 所有变更都通过 Git 提交，提供完整的变更历史和审计跟踪
自动化同步: 通过 CI/CD 流水线自动将 Git 中的变更应用到实际环境
状态收敛: 系统会持续监控实际状态，并自动修复任何与期望状态的偏差

GitOps 工作流程

声明期望状态: 在 Git 中定义基础设施和应用程序的期望状态
提交变更: 通过 Git 提交来应用变更
自动同步: CI/CD 系统检测到变更并自动应用到环境
状态验证: 系统验证实际状态与期望状态一致
监控和告警: 持续监控状态并在出现偏差时发出告警

这种工作流确保了环境的一致性、可重复性和可靠性，同时提供了完整的变更历史和回滚能力。

🚀 快速开始

1. 环境准备

# 克隆项目
git clone <repository-url>
cd mgmt

# 检查环境状态
./mgmt.sh status

# 快速部署（适用于开发环境）
./mgmt.sh deploy

2. 配置云服务商

# 复制配置模板
cp tofu/environments/dev/terraform.tfvars.example tofu/environments/dev/terraform.tfvars

# 编辑配置文件，填入你的云服务商凭据
vim tofu/environments/dev/terraform.tfvars

3. 初始化基础设施

# 初始化 OpenTofu
./mgmt.sh tofu init

# 查看执行计划
./mgmt.sh tofu plan

# 应用基础设施变更
cd tofu/environments/dev && tofu apply

4. 部署 Nomad 服务

# 部署 Consul 集群
nomad run /root/mgmt/jobs/consul/consul-cluster.nomad

# 查看 Nomad 任务
nomad job status

# 查看节点状态
nomad node status

⚠️ 重要提示：网络访问注意事项

Tailscale 网络访问：

本项目中的 Nomad 和 Consul 服务通过 Tailscale 网络进行访问
访问 Nomad (端口 4646) 和 Consul (端口 8500) 时，必须使用 Tailscale 分配的 IP 地址
错误示例：http://127.0.0.1:4646 或 http://localhost:8500 (无法连接)
正确示例：http://100.x.x.x:4646 或 http://100.x.x.x:8500 (使用 Tailscale IP)

获取 Tailscale IP：

# 查看当前节点的 Tailscale IP
tailscale ip -4

# 查看所有 Tailscale 网络中的节点
tailscale status

常见问题：

如果遇到 "connection refused" 错误，请确认是否使用了正确的 Tailscale IP
确保 Tailscale 服务已启动并正常运行
检查网络策略是否允许通过 Tailscale 接口访问相关端口
更多详细经验和解决方案，请参考：Consul 和 Nomad 访问问题经验教训

🔄 Nomad 集群领导者轮换与访问策略

Nomad 集群领导者机制：

Nomad 使用 Raft 协议实现分布式一致性，集群中只有一个领导者节点
领导者节点负责处理所有写入操作和协调集群状态
当领导者节点故障时，集群会自动选举新的领导者

领导者轮换时的访问策略：

动态发现领导者：

# 查询当前领导者节点
curl -s http://<任意Nomad服务器IP>:4646/v1/status/leader
# 返回结果示例: "100.90.159.68:4647"

# 使用返回的领导者地址进行API调用
curl -s http://100.90.159.68:4646/v1/nodes

负载均衡方案：
- DNS 负载均衡：使用 Consul DNS 服务，通过 nomad.service.consul 解析到当前领导者
- 代理层负载均衡：在 Nginx/HAProxy 配置中添加健康检查，自动路由到活跃的领导者节点
- 客户端重试机制：在客户端代码中实现重试逻辑，当连接失败时尝试其他服务器节点
推荐访问模式：

# 使用领导者发现脚本
#!/bin/bash
# 获取任意一个Nomad服务器IP
SERVER_IP="100.116.158.95"
# 查询当前领导者
LEADER=$(curl -s http://${SERVER_IP}:4646/v1/status/leader | sed 's/"//g')
# 使用领导者地址执行命令
nomad node status -address=http://${LEADER}

高可用性配置：
- 将所有 Nomad 服务器节点添加到客户端配置中
- 客户端会自动连接到可用的服务器节点
- 对于写入操作，客户端会自动重定向到领导者节点

注意事项：

Nomad 集群领导者轮换是自动进行的，通常不需要人工干预
在领导者选举期间，集群可能会短暂无法处理写入操作
建议在应用程序中实现适当的重试逻辑，以处理领导者切换期间的临时故障

🛠️ 常用命令

命令	描述
`make status`	显示项目状态总览
`make deploy`	快速部署所有服务
`make cleanup`	清理所有部署的服务
`cd tofu/environments/dev && tofu <cmd>`	OpenTofu 管理命令
`nomad job status`	查看 Nomad 任务状态
`nomad node status`	查看 Nomad 节点状态
`podman ps`	查看运行中的容器
`ansible-playbook playbooks/configure-nomad-clients.yml`	配置 Nomad 客户端
`./run_tests.sh` 或 `make test-mcp`	运行所有MCP服务器测试
`make test-kali`	运行Kali Linux快速健康检查
`make test-kali-security`	运行Kali Linux安全工具测试
`make test-kali-full`	运行Kali Linux完整测试套件

🌩️ 支持的云服务商

Oracle Cloud Infrastructure (OCI)

✅ 计算实例
✅ 网络配置 (VCN, 子网, 安全组)
✅ 存储 (块存储, 对象存储)
✅ 负载均衡器

华为云

✅ 弹性云服务器 (ECS)
✅ 虚拟私有云 (VPC)
✅ 弹性负载均衡 (ELB)
✅ 云硬盘 (EVS)

Google Cloud Platform

✅ Compute Engine
✅ VPC 网络
✅ Cloud Load Balancing
✅ Persistent Disk

Amazon Web Services

✅ EC2 实例
✅ VPC 网络
✅ Application Load Balancer
✅ EBS 存储

DigitalOcean

✅ Droplets
✅ VPC 网络
✅ Load Balancers
✅ Block Storage

🔄 CI/CD 流程

基础设施部署流程

代码提交 → 触发 Gitea Actions
OpenTofu Plan → 生成执行计划
人工审核 → 确认变更
OpenTofu Apply → 应用基础设施变更
Ansible 部署 → 配置和部署应用

应用部署流程

应用代码更新 → 构建容器镜像
镜像推送 → 推送到镜像仓库
Nomad Job 更新 → 更新任务定义
Nomad 部署 → 滚动更新服务
健康检查 → 验证部署状态

📊 监控和可观测性

监控组件

Prometheus: 指标收集和存储
Grafana: 可视化仪表板
AlertManager: 告警管理
Node Exporter: 系统指标导出

日志管理

ELK Stack: Elasticsearch + Logstash + Kibana
Fluentd: 日志收集和转发
结构化日志: JSON 格式标准化

🔐 安全最佳实践

基础设施安全

网络隔离: VPC, 安全组, 防火墙
访问控制: IAM 角色和策略
数据加密: 传输和静态加密
密钥管理: 云服务商密钥管理服务

应用安全

容器安全: 镜像扫描, 最小权限
网络安全: 服务网格, TLS 终止
秘密管理: Docker Secrets, Ansible Vault
安全审计: 日志监控和审计

🧪 测试策略

基础设施测试

语法检查: OpenTofu validate
安全扫描: Checkov, tfsec
合规检查: OPA (Open Policy Agent)

应用测试

单元测试: 应用代码测试
集成测试: 服务间集成测试
端到端测试: 完整流程测试

MCP服务器测试

项目包含完整的MCP（Model Context Protocol）服务器测试套件，位于 tests/mcp_servers/ 目录：

context7服务器测试: 验证初始化、工具列表和搜索功能
qdrant服务器测试: 测试文档添加、搜索和删除功能
qdrant-ollama服务器测试: 验证向量数据库与LLM集成功能

测试脚本包括Shell脚本和Python脚本，支持通过JSON-RPC协议直接测试MCP服务器功能。详细的测试结果和问题修复记录请参考 tests/mcp_server_test_report.md。

运行测试：

# 运行单个测试脚本
cd tests/mcp_servers
./test_local_mcp_servers.sh

# 或运行Python测试
python test_mcp_servers_simple.py

Kali Linux系统测试

项目包含完整的Kali Linux系统测试套件，位于 configuration/playbooks/test/ 目录。测试包括：

快速健康检查 (kali-health-check.yml): 基本系统状态检查
安全工具测试 (kali-security-tools.yml): 测试各种安全工具的安装和功能
完整系统测试 (test-kali.yml): 全面的系统测试和报告生成
完整测试套件 (kali-full-test-suite.yml): 按顺序执行所有测试

运行测试：

# Kali Linux快速健康检查
make test-kali

# Kali Linux安全工具测试
make test-kali-security

# Kali Linux完整测试套件
make test-kali-full

📚 文档

🤝 贡献指南

Fork 项目
创建特性分支 (git checkout -b feature/amazing-feature)
提交变更 (git commit -m 'Add amazing feature')
推送到分支 (git push origin feature/amazing-feature)
创建 Pull Request

📄 许可证

本项目采用 MIT 许可证 - 查看 LICENSE 文件了解详情。

🆘 支持

如果你遇到问题或有疑问：

查看文档
搜索 Issues
创建新的 Issue

⚠️ 重要经验教训

Terraform 与 Nomad 职责区分

问题：在基础设施管理中容易混淆 Terraform 和 Nomad 的职责范围，导致架构设计混乱。

根本原因：Terraform 和 Nomad 虽然都是基础设施管理工具，但它们在架构中处于不同层面，负责不同类型的资源管理。

解决方案：

明确分层架构：
- Terraform/OpenTofu：负责云服务商提供的计算资源（虚拟机）的生命周期管理
- Nomad：负责在已有虚拟机内部进行应用资源调度和编排
职责边界清晰：
- Terraform 决定"有哪些虚拟机"
- Nomad 决定"虚拟机上运行什么应用"
- 两者不应越界管理对方的资源

工作流程分离：

1. Terraform 创建虚拟机 (云服务商层面)
   ↓
2. 虚拟机启动并运行操作系统
   ↓
3. 在虚拟机上安装和配置 Nomad 客户端
   ↓
4. Nomad 在虚拟机上调度和运行应用容器

重要提醒：严格遵守这种分层架构是项目成功的关键。任何混淆这两个层面职责的做法都会导致架构混乱和管理困难。

Consul 和 Nomad 访问问题

问题：尝试访问 Consul 服务时，使用 http://localhost:8500 或 http://127.0.0.1:8500 无法连接。

根本原因：本项目中的 Consul 和 Nomad 服务通过 Nomad + Podman 在集群中运行，并通过 Tailscale 网络进行访问。这些服务不在本地运行，因此无法通过 localhost 访问。

解决方案：

使用 Tailscale IP：必须使用 Tailscale 分配的 IP 地址访问服务

# 查看当前节点的 Tailscale IP
tailscale ip -4

# 查看所有 Tailscale 网络中的节点
tailscale status

# 访问 Consul (使用实际的 Tailscale IP)
curl http://100.x.x.x:8500/v1/status/leader

# 访问 Nomad (使用实际的 Tailscale IP)
curl http://100.x.x.x:4646/v1/status/leader

服务发现：Consul 集群由 3 个节点组成，Nomad 集群由十多个节点组成，需要正确识别服务运行的节点
集群架构：
- Consul 集群：3 个节点 (kr-master, us-ash3c, bj-warden)
- Nomad 集群：十多个节点，包括服务器节点和客户端节点

重要提醒：在开发和调试过程中，始终记住使用 Tailscale IP 而不是 localhost 访问集群服务。这是本项目架构的基本要求，必须严格遵守。

Consul 集群配置管理经验

问题：Consul集群配置文件与实际运行状态不一致，导致集群管理混乱和配置错误。

根本原因：Ansible inventory配置文件中的节点信息与实际Consul集群中的节点状态不匹配，包括节点角色、数量和expect值等关键配置。

解决方案：

定期验证集群状态：使用Consul API定期检查集群实际状态，确保配置文件与实际运行状态一致

# 查看Consul集群节点信息
curl -s http://<consul-server>:8500/v1/catalog/nodes

# 查看节点详细信息
curl -s http://<consul-server>:8500/v1/agent/members

# 查看集群leader信息
curl -s http://<consul-server>:8500/v1/status/leader

保持配置文件一致性：确保所有相关的inventory配置文件（如csol-consul-nodes.ini、consul-nodes.ini、consul-cluster.ini）保持一致，包括：
- 服务器节点列表和数量
- 客户端节点列表和数量
- bootstrap_expect值（必须与实际服务器节点数量匹配）
- 节点角色和IP地址

正确识别节点角色：通过API查询确认每个节点的实际角色，避免将服务器节点误配置为客户端节点，或反之

// API返回的节点信息示例
{
  "Name": "warden",
  "Addr": "100.122.197.112",
  "Port": 8300,
  "Status": 1,
  "ProtocolVersion": 2,
  "Delegate": 1,
  "Server": true  // 确认节点角色
}

更新配置流程：当发现配置与实际状态不匹配时，按照以下步骤更新：
- 使用API获取集群实际状态
- 根据实际状态更新所有相关配置文件
- 确保所有配置文件中的信息保持一致
- 更新配置文件中的说明和注释，反映最新的集群状态

实际案例：

初始状态：配置文件显示2个服务器节点和5个客户端节点，bootstrap_expect=2
实际状态：Consul集群运行3个服务器节点（master、ash3c、warden），无客户端节点，expect=3
解决方案：更新所有配置文件，将服务器节点数量改为3个，移除所有客户端节点配置，将bootstrap_expect值更新为3

重要提醒：Consul集群配置必须与实际运行状态保持严格一致。任何不匹配都可能导致集群不稳定或功能异常。定期使用Consul API验证集群状态，并及时更新配置文件，是确保集群稳定运行的关键。

🎉 致谢

感谢所有为这个项目做出贡献的开发者和社区成员！

脚本整理

项目脚本已重新整理，按功能分类存放在 scripts/ 目录中：

scripts/setup/ - 环境设置和初始化
scripts/deployment/ - 部署相关脚本
scripts/testing/ - 测试脚本
scripts/utilities/ - 工具脚本
scripts/mcp/ - MCP 服务器相关
scripts/ci-cd/ - CI/CD 相关

详细信息请查看脚本索引。

脚本整理

项目脚本已重新整理，按功能分类存放在 scripts/ 目录中：

scripts/setup/ - 环境设置和初始化
scripts/deployment/ - 部署相关脚本
scripts/testing/ - 测试脚本
scripts/utilities/ - 工具脚本
scripts/mcp/ - MCP 服务器相关
scripts/ci-cd/ - CI/CD 相关

详细信息请查看脚本索引。

21 KiB Raw Blame History Unescape Escape

🏗️ 基础设施管理项目

📝 重要提醒 (Sticky Note)

✅ Consul集群状态更新

🎯 项目特性

🔄 架构分层与职责划分

⚠️ 重要：Terraform 与 Nomad 的职责区分

1. Terraform/OpenTofu 层面 - 基础设施生命周期管理

2. Nomad 层面 - 应用资源调度与编排

3. 关键区别

4. 工作流程示例

📁 项目结构

🔄 GitOps 原则

GitOps 工作流程

🚀 快速开始

1. 环境准备

2. 配置云服务商

3. 初始化基础设施

4. 部署 Nomad 服务

⚠️ 重要提示：网络访问注意事项

🔄 Nomad 集群领导者轮换与访问策略

🛠️ 常用命令

🌩️ 支持的云服务商

Oracle Cloud Infrastructure (OCI)

华为云

Google Cloud Platform

Amazon Web Services

DigitalOcean

🔄 CI/CD 流程

基础设施部署流程

应用部署流程

📊 监控和可观测性

监控组件

日志管理

🔐 安全最佳实践

基础设施安全

应用安全

🧪 测试策略

基础设施测试

应用测试

MCP服务器测试

Kali Linux系统测试

📚 文档

🤝 贡献指南

📄 许可证

🆘 支持

⚠️ 重要经验教训

Terraform 与 Nomad 职责区分

Consul 和 Nomad 访问问题

Consul 集群配置管理经验

🎉 致谢

脚本整理

脚本整理

21 KiB

Raw Blame History