5.2 外部系统集成
5.2 外部系统集成
本节摘要：Ansible 作为执行器嵌入外部系统的四类集成：被 CI/CD 流水线触发（入向）、把结果推送监控与消息系统（出向）、操作容器与虚拟化平台（目标扩展）、从外部数据源取数（数据扩展）。本节给出各类集成的架构要点与失效模式。
入向：让流水线成为唯一触发入口
手工触发剧本的问题不只是效率：无审计、无凭据统一管理、无环境一致性。集成 CI/CD 的核心原则是"剧本的执行权收归流水线"——开发者提变更进仓库，流水线自动跑 lint 与测试，合并后由流水线对目标环境执行。一个典型的流水线阶段划分：
# 流水线配置（示意，各平台语法略同） stages: - lint: script: ansible-lint playbooks/ roles/ - test: script: molecule test --all # 角色级回归 - dry-run: script: ansible-playbook site.yml -i inventory/staging --check --diff - deploy-staging: script: ansible-playbook site.yml -i inventory/staging - approve: # 人工卡点：生产发布需审批 manual: true - deploy-prod: script: ansible-playbook site.yml -i inventory/production
四个工程要点。要点一，凭据不进仓库：流水线以受控方式注入 Vault 口令或 SSH 私钥（平台提供的受保护变量机制），仓库与日志里都不能出现。要点二，干跑阶段放在实跑之前且输出留档：--check --diff 的输出就是这次发布将要发生什么的预告，评审与事后审计都用得上。要点三，生产前设人工卡点：自动化到"一键发布"就够了，"自动发布到生产"要慎重——卡点的价值不是技术而是责任归属的清晰化。要点四，失败即熔断：staging 失败绝不允许跑到生产阶段，这个约束写在流水线结构里而不是口头约定里。
出向：结果回送监控与消息系统
剧本执行产生的两类信息值得外送：执行结果（成败、耗时、变更内容）与业务事件（发布完成、证书更新）。两条通道。通道一，回调插件：把执行结果结构化后推送——轻量做法是启用现成的通知类回调（邮件、聊天工具等社区回调插件都有），复杂做法写自定义回调对接内部审计（3.5 节给过时机判断）。通道二，任务内显式上报：在剧本收尾用 uri 模块调用内部接口，第 4.4 节 block-always 的例子里已经示范过。选择依据：通道一覆盖"所有执行"适合审计，通道二覆盖"特定业务动作"适合通知，两者共存不冲突。
与监控系统的集成有一个易被忽视的方向：把"配置漂移"变成监控指标。定期任务跑 ansible-playbook --check，把 changed 计数上报指标系统——changed 长期非零的主机就是在漂移的机器，监控图上一目了然。这把第 1.1 节讲的"无代理没有持续收敛"短板补上了一块观测拼图。
目标扩展：容器与虚拟化平台
Ansible 管理的对象不止传统主机。对容器平台，kubernetes.core 集合让剧本直接操作集群资源——典型场景是发布剧本的收尾动作：镜像构建完成后用 k8s 模块更新工作负载的镜像版本，把"改一行 YAML 再 kubectl apply"写成有审计、可回滚的声明式任务。对虚拟化平台，各厂商集合（libvirt、vmware 等）覆盖建机、快照、模板克隆——第 6.5 节复盘里"发布前打快照"的动作就由它完成。这个方向的使用心法：Ansible 在这里扮演的是"编排翻译层"，把平台 API 翻译成声明式任务，平台本身的重度运维（集群调优、存储策略）依然属于平台工具自身的能力域。
数据扩展：查找与动态清单的对外取数
集成不只是"被触发与发通知"，还有"运行时从外部取数"。3.5 节的查找插件与 4.3 节的动态清单已经给过语法，这里补架构视角：剧本运行时消费的外部数据（资产系统的机器属性、密钥系统的凭证、服务发现的目标列表）形成了第三类集成——数据平面集成。它的失效模式值得预演：外部系统抖动时，剧本会在取数阶段批量失败。对策是缓存（动态清单的缓存窗口、事实缓存）与降级（lookup 的 default 兜底、失败时的明确报错而非静默用旧值）。
图 5-2：四类集成的架构位置
集成的自检清单
给已经或正在做集成的团队五个检查项：生产执行是否已经全部由流水线触发（还有没有人在自己电脑上跑生产剧本）？流水线凭据是否轮换有期？干跑输出是否留档可审计？剧本失败会不会静默（有没有通知通道）？外部取数有没有缓存与降级？五项全绿，Ansible 才真正从"个人工具"变成了"系统组件"。## 一个最小可用的集成参考
把四类集成压缩成一份"最小可用"参考，供起步团队对照实施。入向：一条流水线，四个阶段——lint、staging 实跑、人工审批、production 实跑；凭据用平台的受保护变量注入；干跑输出存为构建产物。出向：剧本收尾一个 uri 任务上报发布事件到内部消息群（标题、版本、变更统计、操作人）；不先搞回调插件，先让通知出现。目标：容器平台场景用 kubernetes.core 更新镜像版本一个动作起步，先跑通再扩展。数据：动态清单一个插件加一份筛选配置，机器列表从此单源。这份参考的全部组件加起来一天能搭完，却覆盖了四类集成的最小闭环——集成架构的正确起步方式是先有最短的完整链路，再逐段加厚，而不是先设计完备再动工。
集成后的运行自检
集成上线不等于集成健康，建议每月跑一次自检五问：过去一个月有没有生产执行发生在流水线之外（查平台执行记录与堡垒机记录的对差）；受保护凭据有没有到期未换（凭据台账核验）；干跑产物是否每份发布都可回溯（抽查三份）；失败的通知到达率如何（人为制造一次失败验证通知链）；数据源故障演练过吗（停掉资产系统接口十分钟，看剧本的降级表现是否符合预期）。五问的成本一小时以内，换来的却是"集成体系是否在悄悄腐化"的早期信号——集成与代码一样会漂移，漂移要有观测手段。