19.2.4 资源编排架构与核心组件

资源编排架构围绕“统一入口、模型驱动、执行分层、状态可观测”构建，目标是将资源从申请、分配、配置、交付到回收的流程标准化与自动化，并与 CMDB、监控、工单协同一致。以下给出架构原理、核心组件、安装与示例、排错与练习。

原理草图（资源编排分层）

核心组件与作用
- 资源模型与编排模板：统一资源规格、标签、依赖与约束，模板化交付可复用。
- 流程与审批引擎：多级审批、超配与例外处理，提供可审计流程。
- 任务调度与执行器：任务拆分、并发控制、幂等与重试机制，保障执行可靠。
- 资源连接器/适配器：对接云 API、虚拟化平台、裸金属 PXE、存储与网络控制面。
- 配置与密钥管理：参数化配置、凭据管理与敏感信息脱敏。
- 状态与事件中心：资源状态同步、事件驱动与变更可追溯。
- 可观测性模块：编排过程指标、日志与告警，支持失败诊断与 SLA 统计。

关键设计要点
- 以资源模型为核心，做到“模型驱动编排”而非“脚本驱动运维”。
- 保障执行幂等性与可回滚性，避免半配置状态。
- 使用标签、资源组与环境分层提升可管理性与可治理性。
- 与 CMDB 双向同步，确保资产数据一致与实时更新。

示例：最小可行资源编排原型（Ansible + 状态记录）#

该示例用于演示“编排层 → 执行层 → 状态层”的最小闭环。

1）安装执行器（Ansible）

# 以 Rocky/Alma/CentOS 为例
sudo dnf install -y ansible-core python3
ansible --version

预期效果：输出 Ansible 版本信息。

2）准备资源模型与编排模板

# /opt/orchestrator/models/web_vm.yaml
resource:
  type: vm
  name: web-01
  cpu: 2
  mem_gb: 4
  disk_gb: 40
  image: rocky-9
  network: prod-net
  tags: [web, prod]

# /opt/orchestrator/templates/provision_web.yaml
- hosts: web_hosts
  become: true
  tasks:
    - name: Install nginx
      dnf:
        name: nginx
        state: present
    - name: Enable and start nginx
      systemd:
        name: nginx
        state: started
        enabled: true
    - name: Write build info
      copy:
        dest: /usr/share/nginx/html/build.txt
        content: "provisioned_by=orchestrator\n"

3）执行编排并记录状态

# /opt/orchestrator/run.sh
set -e

STATE_FILE=/opt/orchestrator/state/web-01.json
mkdir -p /opt/orchestrator/state

ansible-playbook -i "10.0.0.11," \
  -u root /opt/orchestrator/templates/provision_web.yaml

cat > ${STATE_FILE} <<'EOF'
{"resource":"web-01","state":"provisioned","time":"'"$(date -Iseconds)"'"}
EOF

echo "State written to ${STATE_FILE}"

chmod +x /opt/orchestrator/run.sh
/opt/orchestrator/run.sh

预期效果：目标主机安装并启动 Nginx，状态文件写入 provisioned。

4）验证交付

curl -I http://10.0.0.11
curl http://10.0.0.11/build.txt

预期效果：HTTP 200，build.txt 返回 provisioned_by=orchestrator。

示例：资源状态与事件中心（最小实现）#

# /opt/orchestrator/event.log
echo "$(date -Iseconds) resource=web-01 event=provisioned" >> /opt/orchestrator/event.log
tail -n 3 /opt/orchestrator/event.log

预期效果：事件日志写入，便于回放与审计。

典型排错路径（含命令与解释）#

1）执行失败：权限或 SSH 问题

ssh -i /root/.ssh/id_rsa root@10.0.0.11 "hostname"

解释：验证控制节点到目标节点连通与免密。

2）幂等性问题：重复执行导致配置冲突

ansible-playbook -i "10.0.0.11," -u root /opt/orchestrator/templates/provision_web.yaml --check

解释：--check 用于预演，检查变更是否可重复执行。

3）状态不一致：CMDB 与执行结果不符

cat /opt/orchestrator/state/web-01.json
systemctl status nginx --no-pager

解释：对比状态中心记录与实际服务状态。

4）可观测性缺失：定位失败任务

ANSIBLE_STDOUT_CALLBACK=debug \
ansible-playbook -i "10.0.0.11," -u root /opt/orchestrator/templates/provision_web.yaml -vvv

解释：启用详细输出，定位失败任务与模块参数。

练习#

1）扩展资源模型
- 在 web_vm.yaml 中新增 env: staging 与 owner: devops。
- 在执行完成后，将字段写入 state 文件。

2）实现回滚
- 编写 rollback_web.yaml，卸载 nginx 并删除 build.txt。
- 通过脚本在失败时调用回滚 Playbook。

3）加入审批模拟
- 在 run.sh 中加入参数校验：若未提供 APPROVED=true 则退出。
- 练习命令：

APPROVED=true /opt/orchestrator/run.sh

19.2.4 资源编排架构与核心组件

示例：最小可行资源编排原型（Ansible + 状态记录）#

示例：资源状态与事件中心（最小实现）#

典型排错路径（含命令与解释）#

练习#

本页内容