检查模式能预演什么
加 --check 启动的检查模式（也叫 dry run）会照常连着目标机、照常做变量与模板计算，但要求模块只报告“将会改成什么”而不真正落盘。它的价值在于把变更清单先摊开让人看，再决定是否执行。代价是：只有实现了检查模式的模块才能预演，纯命令执行类模块给不出可信的预测，所以检查模式是过滤器，不是安全网。
基本信息
| 命令行开关 | ansible-playbook --check（常与 --diff 合用） |
|---|---|
| 任务级覆盖 | check_mode: true 强制检查、check_mode: false 在检查运行中真实执行 |
| 依赖前提 | 目标机可达、变量可解析；检查模式仍会建立连接 |
| 无法预演 | command/shell 这类无状态模块在检查模式下被跳过，需要 creates、removes 或显式关掉检查 |
| 配置项 | ansible.cfg 中 check_mode 相关默认值，可在一个仓库内统一 |
| 权限 | 与真实执行一致，需要提权才能预演提权动作 |
典型使用场景
- 发布前评审：把“将新建/修改/删除哪些文件与服务”导出来给变更评审看
- 验证模板与变量：确认渲染结果符合预期，又不落地到目标机
- 新人熟悉仓库：在测试环境用检查模式看一个陌生 playbook 会动什么
- 定时巡检：定期检查配置是否漂移，发现 should change 就说明被手工改过
- 长时间分批运行前的预检：先看整批主机是否存在明显的变量缺失
- 配合 check_mode: false 读取现网状态，再做判断而不修改
用法与覆盖
用法与覆盖
# 预演并显示差异（差异需要模块支持）
ansible-playbook -i inventory site.yml --check --diff
# 只预演某个标签、限制到一台主机，降低干扰
ansible-playbook -i inventory site.yml --check --tags config --limit web1
# 任务级开关的写法（yaml 片段）
# - name: 读取当前版本，不修改
# ansible.builtin.command: cat /opt/app/VERSION
# check_mode: false # 检查运行里也真实执行
# register: cur
#
# - name: 强制以检查模式评估
# ansible.builtin.template:
# src: app.conf.j2
# dest: /etc/app/app.conf
# check_mode: true预演结果怎么读
| 输出状态 | 含义 | 后续动作 |
|---|---|---|
| ok | 状态已符合期望，无需变更 | 正常，说明无漂移 |
| changed | 检查模式下判定“将会变更” | 重点复核，确认变更是否符合预期 |
| skipping | 模块不支持检查模式，本任务被跳过 | 这部分必须在测试环境真跑一遍才算验证 |
| failed | 变量、模板或参数有问题 | 修好再执行，检查模式不能绕过参数错误 |
| unreachable | 目标机连不上 | 先解决连通性，预演无从谈起 |
检查模式跳过命令类任务时，后面的任务可能因为缺少前一步的产物而报错，chain 越长的 playbook 预演结果越不可信。把命令类任务拆小、用 creates/removes 声明幂等条件，能让预演覆盖更多步骤。
check_mode: false 会让任务在检查运行中真实执行。只用于读取状态这类无副作用操作；一旦误用在写操作上，--check 就成了实际变更，预演的前提被破坏。
可信边界在哪
只由声明式模块（包管理、模板、文件、服务）组成的 playbook，检查模式的结果基本可信；一旦中间夹了脚本、命令、API 调用，预演就退化成“前面的步骤能不能算出参数”。判断一个 playbook 是否适合靠检查模式把关，就看它的任务里命令类占比：占比高就补幂等条件，占比低可以直接信任预演。