Ansible实现CI/CD后的应用分发，核心是可靠、一致地推送构建产物到目标环境并完成启动、校验与回滚准备，不负责构建本身，专注交付后的分发与就绪动作。
Ansible 实现 CI/CD 后的应用分发，核心是把构建好的产物（如编译包、Docker 镜像、静态文件等）可靠、一致地推送到目标环境，并完成启动、校验和回滚准备。它不负责构建本身，而是专注“交付之后”的分发与就绪动作。
明确分发对象和目标环境
分发前需清晰定义两件事：一是你要分发什么，二是分发到哪里。常见组合包括：
- 前端静态资源 → Nginx/Apache 服务器的
/var/www/html目录 - Java JAR 包 → 应用服务器（如 Tomcat）的
webapps/或独立运行目录 - Docker 镜像 → 私有 Registry（如 Harbor），再由目标节点
docker pull启动 - Python Flask 应用 → 使用
copy模块同步代码 +systemd模块管理服务
这些信息要体现在 Inventory 分组中，例如：[app_servers]app1.prod ansible_host=10.0.2.10app2.prod ansible_host=10.0.2.11
编写幂等、可验证的分发 Playbook
Playbook 是分发逻辑的载体，关键在于“一次写对，多次执行无副作用”。典型结构包含：
-
前置检查：确认目标路径存在、磁盘空间充足、旧进程已停止（如
service: name=myapp state=stopped） -
安全传输：用
copy（本地文件）、unarchive（解压远程包）、get_url（拉取构建产物 URL）或docker_image（拉镜像） -
配置注入：用
template模块动态生成环境相关配置（如数据库地址、API 端点） -
服务启用：用
systemd或service模块启动并设为开机自启 -
健康验证：用
uri模块发起 HTTP 请求检查服务响应，失败则中断流程
示例片段（部署 Python 应用）：
- name: Ensure app directory exists
file:
path: /opt/myapp
state: directory
owner: appuser
group: appuser
<ul><li><p>name: Copy application package
copy:
src: ./dist/myapp-1.2.0.tar.gz
dest: /tmp/myapp.tar.gz</p></li><li><p>name: Extract and overwrite
unarchive:
src: /tmp/myapp.tar.gz
dest: /opt/myapp
remote_src: yes
owner: appuser
group: appuser</p></li><li><p>name: Render config from template
template:
src: config.j2
dest: /opt/myapp/config.py</p></li><li><p>name: Start service
systemd:
name: myapp
state: started
enabled: yes</p></li><li><p>name: Verify service is responsive
uri:
url: <a href="https://www.php.cn/link/0e1d435f47ab4e50f0cc55ff06738d5c">https://www.php.cn/link/0e1d435f47ab4e50f0cc55ff06738d5c</a>
status_code: 200
与 CI/CD 工具联动执行分发
Ansible 不自己监听代码变更，需由 CI/CD 工具触发执行。主流集成方式如下：
-
GitLab CI：在
.gitlab-ci.yml中添加 deploy job，用ansible-playbook命令调用对应 Playbook，通过ANSIBLE_INVENTORY环境变量指定生产 Inventory -
Jenkins Pipeline：在
stage('Deploy')中使用sh 'ansible-playbook -i inventory/prod deploy.yml'，支持参数化选择环境（如env=prod） -
GitHub Actions：用官方
actions/setup-python安装 Ansible，再运行 Playbook；敏感信息（如 SSH 私钥）通过 Secrets 注入
注意：CI/CD 执行节点需预装 Ansible，并具备访问目标服务器的 SSH 权限（推荐使用密钥认证+非 root 用户 + become 提权）。
支持灰度发布与安全回滚
真实生产分发不能“一刀切”，Ansible 可通过以下方式增强可控性：
-
滚动更新：用
serial: 2参数控制每次只更新 2 台机器，配合健康检查逐步推进 -
蓝绿部署：先部署新版本到备用集群（如
blue组），验证通过后切换负载均衡指向 -
一键回滚：将上一版包路径记录在变量中，回滚 Playbook 直接复制旧包 + 重启服务；或结合 Git 标签，用
git checkout v1.1.0拉取历史代码重新打包
回滚逻辑应与主部署 Playbook 平级存放，命名清晰（如 rollback.yml），避免临时手写命令引发误操作。
