ansible 在 linux ci/cd 流水线中作为环境执行层，专注制品拉取、环境配置与健康验证；需职责清晰、分阶段编写 playbook、加密敏感信息、支持预检回滚及环境快照，杜绝配置漂移。
在 Linux CI/CD 流水线中集成 Ansible 部署，关键是把 Ansible 当作“环境执行层”来用——它不编译代码、不打镜像，而是精准拉取制品、准备环境、启动服务并验证就绪状态。整个过程要可触发、可预检、可回滚、可追溯。
明确 Ansible 在流水线中的职责边界
Ansible 不替代 CI 工具（如 Jenkins、GitLab CI），也不替代容器运行时（如 Docker）。它只做三件事：
- 从制品库（Nexus、Artifactory、私有 Registry）下载二进制包或拉取镜像
- 配置运行环境：创建用户、设置目录权限、开放防火墙端口、配置 systemd service 或 Nginx 反向代理
- 部署后执行健康检查：curl 接口、检查进程、验证端口监听、运行 smoke test 脚本
Playbook 设计要适配流水线节奏
避免写“一锅炖”式大剧本，按交付阶段拆分职责：
- setup.yml：统一基础加固（SSH 设置、时区、NTP、基础软件包）
- deploy.yml：拉取制品、解压/部署、启停服务（带 version 变量控制发布版本）
- verify.yml：调用 check_health.sh 或 curl http://localhost:8080/health，失败即中断流水线
- 所有敏感字段（如数据库密码、API key）必须用 ansible-vault 加密，不进 Git
CI/CD 中嵌入安全可靠的执行方式
以 GitLab CI 为例，在 .gitlab-ci.yml 中定义部署阶段：
- 使用
ansible-playbook -i inventory/prod deploy.yml --extra-vars "version=$CI_COMMIT_TAG"绑定发布版本 - 上线前加
--check --diff做模拟运行，输出变更预览，人工确认后再执行真实部署 - 为防误操作，生产环境 playbook 必须启用 require_approval 或依赖手动审批 job
- 每次执行后运行
ansible-cmdb -t html -o cmdb-report.html生成当前环境快照，自动归档到制品库
防止配置漂移与快速回滚
线上机器被手动改动是常态，Ansible 要主动盯住：
- 每天凌晨定时运行 facts 收集任务，保存
host_facts_$(date +%F).json - 流水线中加入 diff 检查步骤：对比本次 facts 和上次 baseline，发现异常（如多装了 docker、sshd 配置被改）立即告警
- 回滚不是重跑旧 Playbook，而是用
ansible-playbook rollback.yml --extra-vars "target_version=v1.2.3"精准切回指定版本的部署包与配置 - 目标主机 SSH 用户需限制命令范围（
ForceCommand /usr/bin/ansible-authorized），禁止交互式 shell 登录
