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 结构捕获异常，自动尝试恢复上一版配置或发送告警
