Ansible 剧本检查器

问题背景

Ansible 的 playbook 和 role 本质上是声明式配置，一个不起眼的拼写错误、一次不完整的 handlers 定义，都可能在目标主机上表现为难以定位的执行失败。更麻烦的是，这类问题往往不在语法层面：yamllint 能拦住缩进错误，却拦不住「同一个 task 重复执行结果不同」这类幂等性问题，也拦不住 var_name、VariableName、variable_name 三种命名风格混用带来的维护成本。等到流水线跑完才发现，排查成本已经很高了。

核心能力与工作流程

这个技能把两类检查整合到一个入口：

• 双引擎校验：通过 ansible-lint 与 yamllint 的 API 分别处理语义规则和 YAML 结构问题，而不是简单地在命令行跑一遍 lint。
• 自定义规则配置文件：重点落在三条实践上——幂等性、变量命名规范、handlers 的正确使用。规则集中在配置文件中，团队可以按自己的约定调整，而不必修改 lint 工具本身。
• 校验对象：同时覆盖 playbook 文件和 role，role 内部的 task、defaults、handlers 都在检查范围内。

典型的工作流是：把技能指向仓库中的 playbook 或 role，它加载自定义规则配置，调用两个 lint API 并聚合结果，然后按规则输出违规项。

适用边界与注意事项

需要说清楚它不能做什么：

• 技能只做静态检查，不会真正连接到目标主机执行 playbook。运行时才暴露的问题——比如某个模块对特定系统版本的依赖——不在覆盖范围内。
• 如果 playbook 大量依赖动态 inventory 或临时任务，静态分析能看到的范围是有限的。
• 想跟上 Ansible 上游最新行为的开发者可以关注 devel 分支，它包含最新特性；但生产环境通常建议锁定稳定分支。
• 另外，Ansible 的模块并不要求只能用 Python 写，用其他动态语言开发的模块同样可以接入，这类自定义模块自身的规范性仍需团队自行把关。