5.1 自动化工具链
5.1 自动化工具链
本节摘要：围绕 Ansible 的工具链全景：开发期的 lint 与测试框架，运行期的导航器与执行环境，组织期的编排平台谱系。本节按"个人 → 团队 → 组织"三层给出工具选型，并说明每一层解决了上一层的什么痛点。
个人层：把写对变成默认状态
个人开发剧本时的两件必备武器。第一件，ansible-lint：静态检查器，剧本还没跑就先过一遍写法纪律——任务缺 name、包操作误用 shell、弃用语法、schema 不合规。把它装进编辑器保存钩子，坏味道在写下的那一刻就被标红：
pip install ansible-lint ansible-lint playbooks/ roles/ # 输出示例： # playbook: playbooks/site.yml # risky-shell-shell 而不是模块: tasks/install.yml:12 # name[template] 任务名含模板表达式: tasks/config.yml:8
第二件，molecule：角色测试框架。它把"起干净容器 → 应用角色 → 执行断言 → 销毁"整环自动化，配置文件声明场景（scenario），一条命令跑完：
molecule init scenario default -d docker # 初始化场景（驱动选 docker 或 podman） molecule test # 全环：创建、收敛、验证、销毁
场景里的断言文件（verify.yml）本身也是一份 Ansible 剧本，用 assert 检查"端口在听、配置行存在、服务自启"。molecule 的价值在回归：角色改动后一条命令确认没有把老功能改坏——4.5 节发布纪律里的"每次变更过测试环"，落到工具上就是它。
团队层：统一的运行时与入口
剧本代码一多，团队会撞上两个新问题："在我机器上是好的"（环境漂移），以及"每人一套触发姿势"（执行随意）。两个工具分别对应。
ansible-navigator 是文本模式下的统一运行入口：把引擎包在容器化运行时里跑，剧本、清单、集合版本全部锁定在执行环境镜像内。它同时提供交互式浏览——执行完直接翻看每台主机每个任务的结构化结果，比翻终端回滚缓冲舒服得多。
执行环境（Execution Environment）是这套思路的正式形态：把引擎版本、Python 依赖、集合与插件打包成 OCI 镜像，所有人（包括 CI 与平台）用同一个镜像跑剧本。环境定义文件声明构建材料：
# execution-environment.yml（节选） version: 3 images: base_image: name: 社区维护的基础执行环境镜像 dependencies: galaxy: requirements.yml # 4.2 节的依赖清单直接复用 python: requirements.txt
团队层的实施建议一句话：先锁集合版本（4.2 节），再锁运行时镜像。只做前者，引擎本身的差异仍会带来行为分歧；两件都做，"在我机器上是好的"才真正消失。
组织层：编排平台的谱系
当执行需要排队、审批、凭据托管与权限分级时，命令行就到了能力边界，该看平台了。谱系上三个位置：开源的 AWX 提供平台核心能力（Web 界面、任务模板、基于角色的访问控制、计划任务、凭据托管），适合自建自维护能力强的团队；商业化的 Ansible Automation Platform 在 AWX 能力之上叠加支持服务、执行环境集群调度、审计与认证集成，适合需要供应商背书的组织；此外各家 CI 平台（Jenkins、GitLab CI、GitHub Actions 等）都有 Ansible 集成插件，在"编排需求还很简单"的阶段，直接在流水线里跑 ansible-playbook 是成本最低的起步方式。
平台选型的判断维度不是功能清单而是三问：执行频次是否高到需要排队与并发控制？操作者与编写者是否是不同人群（需要界面与权限体系）？审计与合规是否要求执行记录与凭据隔离？三问两个以上答案是，上平台；全否，先把 CI 集成做扎实。
图 5-1：工具链版图与三层选型
从工具链看剧本仓库的形态
工具就位后，一个成熟的 Ansible 仓库长什么样？给出参考结构并解释每件东西为什么在那：
stardust-ansible/ ├── ansible.cfg # 项目级配置：清单路径、回调启用 ├── execution-environment.yml # 运行时定义（团队层锁定） ├── requirements.yml # 集合与角色依赖（版本锁定） ├── inventory/ │ ├── production/ # 分环境清单（3.1 节布局） │ └── staging/ ├── playbooks/ # 入口剧本（薄，只做编排声明） ├── roles/ # 自研角色（4.5 节流程开发） ├── molecule/ # 角色测试场景 └── .github 或 .gitlab 配置 # 流水线：lint → molecule → 干跑 → 分环境发布
这个结构里没有一件东西是"为了规范而规范"：每个文件都对应前面某节解决过的一个具体问题。对照你自己团队的仓库，缺哪件，就说明哪个问题还没被工具化解决。
本节边界
工具链的诱惑是全部上齐。给一个务实的采纳顺序：lint 当天可装且零风险，第一时间上；molecule 在角色数量过五之后收益明显；执行环境锁定在团队超过三个人同时改剧本后值得投入；平台则严格按三问判断。## 工具引入的决策记录
工具链章节最容易留下的坑是"工具上齐了，没人记得为什么上"。给团队一个轻量的对策：每个工具的引入写一页决策记录，四要素——当时解决什么问题、放弃了哪些替代方案、成功的判据是什么、谁负责维护。判据一项尤其重要：lint 的判据可以是"合并前静态检查拦截率"，执行环境的判据可以是"环境漂移类工单归零"，写下来才有得验收。半年后回看决策记录，判据未达的工具要么调整用法要么下线——工具链的健康度来自这种可证伪的引入方式，而不是装完就忘的堆叠。反过来，决策记录也保护工具不被盲目裁撤："为什么要花时间维护 molecule"这类质疑，翻出当年记录即可对答。工具决策的书面化，本质是把架构决策记录的轻量版搬到工具层，成本一页纸，收益是团队记忆的连续性。