Ansible 通过 Git 版本管理、目录隔离、变量控制及安全重启机制实现可靠回滚。关键在于用 Git 管理 Playbook 与配置，按环境分分支、打 tag；roles 中按版本分目录（old/new）；用 deploy_version 变量动态指定配置；配合 handlers、健康检查与 block/rescue 保障回滚安全。

Ansible 本身不直接存储历史配置快照，但通过合理设计 Playbook 结构、配合 Git 版本管理与目录隔离策略，就能实现快速、可靠的回滚。关键不是“Ansible 自带回滚功能”，而是用它执行你已准备好的历史配置。

用 Git 管理 Playbook 和配置文件版本

所有 Ansible 文件（playbook、roles、templates、vars）都应纳入 Git 仓库。每次上线前提交一次，附清晰描述，比如：
git commit -m "v2.1.0: 更新 Nginx TLS 配置，启用 HTTP/2"
这样你随时能 checkout 到任意历史 commit，再运行对应 Playbook，就完成了逻辑回滚。

• 为不同环境（dev/test/prod）建独立分支，避免互相干扰
• 在 CI/CD 流程中自动打 tag，例如 v2.1.0，比 commit hash 更易识别
• 敏感变量（如密码）不要硬编码，用 ansible-vault 加密后提交

按版本隔离部署内容（目录式回滚）

对需频繁更新的配置（如 Nginx 虚拟主机、应用配置），推荐在 roles 中按版本分目录存放：

• roles/nginx_config/
  ├── old/               ← 上一版配置备份
  ├── new/              ← 当前待发布配置
  └── templates/         ← 公共模板
• 发布时：把新配置复制进 new/，运行 playbook；
  回滚时：只需把 old/ 内容同步覆盖目标路径，再 reload 服务即可
• 可用 rsync 或 copy 模块完成目录切换，速度快、原子性强

用变量控制部署目标版本

在 playbook 中引入版本变量，让单个文件支持多版本部署：

• 定义变量：
  deploy_version: "v2.0.0"
• 在 tasks 中引用：
  src: "files/{{ deploy_version }}/app.conf"
• 执行时指定：
  ansible-playbook deploy.yml -e "deploy_version=v1.9.2"
• 搭配 Git tag 使用，可直接映射到真实代码/配置快照

配套：确保服务重启安全可控

回滚不只是换配置，更要验证服务是否正常启动：

• 在 handlers 中定义 restart nginx 或 reload systemd service，只在配置变更时触发
• 添加健康检查任务（如 uri 模块访问 /health 端点），失败则中断后续步骤
• 用 block/rescue 结构捕获异常，自动尝试恢复上一版配置或发送告警