配置管理概览

配置管理（Configuration Management, CM） 解决的是：成百上千台机器上的 OS 包、服务、配置文件、用户权限 如何 可重复、可审计、可回滚。它与 terraform-essentials 的 基础设施即代码（IaC） 互补——Terraform 管 云资源生命周期，CM 管 机器内部状态。本 track 补全 /roadmaps/devops 的 configuration-management 与 platform 节点，并与 devops-cloud-essentials、kubernetes-essentials 形成「云 + 容器 + 配置」三角。

学习目标

• 区分 IaC、CM、镜像构建、GitOps 各自边界与协作方式
• 理解 声明式 vs 命令式 配置模型及 idempotency（幂等）
• 为 CodeRoadMap 单机/多机部署画出 CM 在 DevOps 流水线中的位置

IaC 与 CM 分工

维度	IaC（Terraform 等）	CM（Chef/Puppet/Ansible 等）
管理对象	VPC、VM、LB、DNS、IAM	OS 包、systemd、配置文件、防火墙
触发时机	terraform apply	Agent 周期拉取 / push playbook
状态存储	远程 state	Node 清单 / PuppetDB / Chef Server
典型输出	一台「空」虚拟机	可运行应用的「就绪」主机

Git PR → CI 构建镜像/制品
    → Terraform 创建 VM + 网络（见 terraform-essentials）
    → CM 收敛主机配置（本 track）
    → K8s / systemd 启动应用（见 kubernetes-essentials）

Golden Image + CM 漂移修复 是常见组合：Packer 打基础镜像，CM 处理环境差异（staging vs prod 的 application.yml）。

声明式配置核心

无论 Chef Recipe、Puppet Manifest 还是 Salt State，本质都是 描述期望状态：

# 概念示例：Nginx 应处于运行且开机自启
nginx:
  pkg.installed: []
  service.running:
    - enable: true
    - require:
      - pkg: nginx

CM 工具周期性 对比期望 vs 实际，只应用差异——这就是 幂等：同一 Recipe 跑两次，第二次不应再改任何东西。

与云、K8s 的关系

• 裸机 / VM：CM 仍是主力（本 track 重点）
• 容器：Dockerfile / Helm 承担大部分配置；节点级仍可能需要 CM（kubelet、CNI、OS 补丁）
• 托管 PaaS：责任上移，CM 范围缩小（见 ）