ansible-lint 的理念

Ansible 的**剧本、角色和集合**应该像文档一样易于阅读，具备生产就绪性，清晰明了，并提供一致的结果。

Ansible-lint 应该被视为一个值得信赖的顾问，帮助 Ansible 内容创建者编写和打包高质量的 Ansible 内容。虽然并非所有规则都适用于所有情况，但应尽可能遵循这些规则。

ansible-lint 的目标是确保不同人员创建的内容具有相似的外观和感觉。这使得 Ansible 内容在社区和企业中的采用和使用更加容易。通过将可配置功能的数量保持在最低限度，可以实现作者之间的一致性结果。

历史与未来

ansible-lint 已经存在近十年了，其当前的规则列表是许多人合作的结果。该工具起源于一个社区项目，目前是 Ansible Galaxy 提交和验证流程的一部分。

未来，它将成为 Red Hat Ansible Automation Platform 的正式组件，用于集合认证流程，并成为 Red Hat 客户推荐的 Ansible 内容代码检查工具。

从 2022 年开始，将添加更多规则，以帮助内容创建者准备好其内容以供生产使用。通过使用 ansible-lint 和这些规则，开发人员可以确信他们的剧本、角色和任务文件易于理解，并在运行于任何环境（从家庭实验室中的服务器到云中的关键任务系统）时都能产生一致的结果。

风格和格式

Ansible 内容创建者应关注自动化、结果和可读性，而不是风格或格式。这就是为什么我们遵循与其他代码格式工具（如 black 和 prettier）相同的概念。

采用ansible-lint 将节省时间，使审查重点放在内容质量上，而不是格式和样式的细微差别上。

由于代码格式不是一门艺术，我们可以通过应用标准化的代码风格和格式来节省您的项目时间和精力。

问答

为什么 ansible-lint 不接受所有有效的 Ansible 语法？

ansible-core 持续发展的同时，保持着与早期版本的向后兼容性。ansible-lint 从未打算支持所有历史 Ansible 语言语法的变体，而只是支持其中最好的部分。

它支持广泛的关键词和样式词汇表。随着时间的推移，语言的变化为 Ansible 内容的作者和使用者带来了更好的体验。ansible-lint 中的规则建议使用这些模式。

正是这些用作ansible-lint 中规则的使用模式，提高了**剧本、角色**和**集合**的可读性。代码检查器在它接受的内容方面总是更严格和更武断。这是其设计的一部分。我们不必保持与 Ansible 相同的向后兼容性级别，因此我们可以告诉人们出于各种原因避免使用特定语法，例如已弃用、不安全或难以维护。

基于ansible-lint 的广泛历史和用户反馈，它会在ansible-core 开始这样做之前通知您不建议的做法。

如果我不同意某条特定规则怎么办？

我们认识到，某些项目会发现至少有一条规则可能不适合他们的需求。使用skip_list 功能暂时绕过该规则，直到您有时间更新您的 Ansible 内容。

谁决定哪些最佳实践会被采用到 ansible-lint 中？

新想法的主要来源一直是我们的社区。在提出更改之前，请咨询一些在不同项目上工作的其他 Ansible 用户，看看他们是否觉得它有用。

最好在开始实施新规则之前，在我们的讨论论坛上获得足够的相关反馈。如果建议的规则看起来很受欢迎并且不与现有规则冲突，核心团队（维护者）会告诉您可以将建议的规则添加到 ansible-lint 中，这样您就可以开始工作而不用担心被拒绝。

核心团队将决定如何添加新规则。通常，它们被添加为实验性的（仅警告）甚至作为可选功能，只有在发布主要版本时才隐式地启用。

我的集合是否需要通过所有规则才能获得认证？

不是的。认证流程可能会只使用一部分规则。目前，我们正在努力创建该列表。

为什么许多官方 Ansible 文档示例无法通过代码检查？

大多数官方示例都是为了举例说明特定功能而编写的，有些可能与我们的规则冲突。尽管如此，我们计划在未来将官方示例的代码检查包含在内，并在需要时添加特定的排除项，从而更有可能使从文档复制/粘贴不会引发大量代码检查违规。

为什么 ansible-lint 需要比我在生产环境中使用的 Ansible 版本更新的版本？

将ansible-lint用作内容的**静态分析**工具。您可以使用与生产环境中使用的 Ansible 版本不同的版本运行它。这有助于您为将来准备内容，因此不要害怕以这种方式使用它。