ansible虽无原生dag引擎，但可通过depends_on声明任务依赖、block/rescue/always控制阶段闭环、include_tasks动态加载阶段任务、inventory分组驱动环境差异化流程，构建稳定可维护的多阶段部署流水线。
Ansible 本身不提供原生的“任务依赖图”或 DAG 引擎，但通过合理组合语言特性与结构设计，完全可以构建稳定、可读、可维护的多阶段部署流水线。关键不在于强行模拟依赖调度器，而在于用清晰的语义表达执行顺序与前置条件。
用 depends_on 显式声明任务级依赖
Ansible 2.12+ 原生支持 depends_on（需启用 community.general 插件或使用较新核心模块），它让任务执行逻辑更贴近真实运维意图。不是靠位置先后，而是靠结果判定：
- 依赖目标必须是已
register的任务，且其changed或failed状态可被判断 - 若依赖任务失败或跳过，当前任务默认跳过（可设
ignore_errors: true覆盖） - 适用于强耦合场景，比如“只有数据库服务真正启动成功，才继续部署应用”
示例：
- name: 检查数据库连接可用性
community.mysql.mysql_ping:
login_host: "{{ db_host }}"
login_user: "{{ db_user }}"
register: db_ping_result
ignore_errors: true
- name: 部署应用配置文件 template: src: app.conf.j2 dest: /etc/app/config.conf depends_on: db_ping_result when: db_ping_result.ping is defined and db_ping_result.ping
用 block + rescue + always 控制阶段边界
多阶段部署常含“准备→验证→上线→回滚”完整闭环。block 是组织阶段最自然的单元，配合 rescue 可定义失败时的标准化补救动作，always 则确保收尾操作（如清理临时文件、发通知）必执行：
- 每个 block 对应一个逻辑阶段：如
stage: pre-deploy、stage: deploy、stage: post-check - 在
rescue中调用 rollback playbook 或执行反向操作，避免手动介入 - 用
vars在 block 内定义阶段专属变量，隔离不同阶段的上下文
用 include_tasks + when + tags 实现环境/阶段路由
同一份 playbook 可面向开发、预发、生产三套环境运行，但各阶段任务内容不同。不推荐写大量 when 判断，而是按阶段拆分子任务文件，再动态包含：
- 目录结构示例：
stages/precheck.yml、stages/deploy.yml、stages/validate.yml - 主 playbook 中用
include_tasks加条件加载：include_tasks: stages/{{ deploy_stage }}.yml - 配合
tags可单独运行某阶段：ansible-playbook deploy.yml --tags validate - 变量
deploy_stage可从 inventory、extra-vars 或 vault 中注入，实现环境解耦
用 inventory 分组 + group_vars 驱动阶段行为差异
不同环境的部署阶段数可能不同——比如开发环境跳过灰度，生产环境必须走金丝雀发布。利用 inventory 的分组能力，让主机自动“知道自己该走哪条路径”：
- 将主机划入
[production]、[staging]、[dev]组，并为每组设置group_vars/<group>.yml</group> - 在变量中定义
deployment_phases: ["precheck", "canary", "full"]，playbook 循环执行对应阶段 - 避免硬编码判断，所有策略由数据（变量）驱动，便于审计和复用
