Ansible 的禅意
Ansible 的禅意
这篇博文基于我在芝加哥 AnsibleFest 2022 和线上的演讲。
最近，有人建议采用Tim Peters 的“Python 之禅”作为设计优秀自动化内容的总体指导原则。这让我停顿了一下，因为它在我看来似乎并不合适。虽然“Python 之禅”中确实有一些非常好的建议可以应用于 Ansible 内容，但完全采用它并不能提供 Ansible 所能够并且已知的最佳用户体验。将其作为内容设计的指导原则会产生错误的印象，并强化我们不希望推荐的心态。
这让我思考，Ansible 的“禅意”是什么？
我考虑了“Python 之禅”的精神，然后回到了我早在 2016 年红帽峰会上首次联合发表的 Ansible 最佳实践演讲。在那次演讲中，我说 Ansible 从一开始就设计了一种理念。
“Ansible 方式”是提供一种简单、强大且无需代理的自动化工具。Ansible 使得没有特殊编码技能的用户能够跨多个 IT 领域执行强大的操作。其人类可读的自动化可以被每个 IT 团队使用和共享，以便他们能够快速提高工作效率并贡献自己的专业知识。其无需代理的架构提供了跨所有 IT 基础设施领域的灵活应用能力。
正是这种设计理念，本文中的所有内容都以某种方式与之相关联。
除了“Python 之禅”和我的 Ansible 最佳实践演讲之外，我还考虑了我多年来在 Ansible 生态系统中与数百位用户交谈时听到的内容。我总结了以下 20 条 Ansible 格言。
- Ansible 不是 Python。
- YAML 不适合编写代码。
- Playbook 不是用于编程的。
- Ansible 用户（很可能）不是程序员。
- 清晰优于杂乱。
- 简洁优于冗长。
- 简单优于复杂。
- 可读性至关重要。
- 帮助用户完成任务最重要。
- 用户体验胜过意识形态的纯洁性。
- “魔法”征服手动操作。
- 在为用户提供选项时，使用约定优于配置。
- 声明式优于命令式——大多数情况下。
- 专注避免复杂性。
- 复杂性降低生产力。
- 如果实现难以解释，那它就是一个坏主意。
- 每个 shell 命令和 UI 交互都是一个自动化机会。
- 仅仅因为某些东西有效，并不意味着它不能改进。
- 应尽可能消除摩擦。
- 自动化是一段永无止境的旅程。
您的 Ansible 自动化内容不一定必须遵循这些指导，但它们是需要牢记的好主意。这些格言是观点，可以进行辩论，有时也可能存在矛盾。重要的是，它们传达了一种从 Ansible 和您的自动化中获得最大收益的心态。
让我带您更深入地了解每一条格言，并解释它们对您的自动化实践意味着什么。
Ansible 不是 Python。YAML 不适合编写代码。Playbook 不是用于编程的。Ansible 用户（很可能）不是程序员。
这些格言是为什么将编程语言的指导原则应用于优秀的 Ansible 自动化内容在我看来并不合适的核心原因。正如我所说，这会产生错误的印象，并强化我们不希望推荐的心态——即 Ansible 是一种用于编写 playbook 的编程语言。
这些格言都以不同的方式表达了相同的意思——当然前三条尤其如此。如果您试图在您的 playbook 和角色中“编写代码”，那么您就是在自找麻烦。Ansible 基于 YAML 的 playbook 从未打算用于编程。
因此，当我看到 Python 风格渗透到 Ansible 用户的视野和行为中时，我感到困扰。如果您用 Python 编写代码，这可能是自然而然的，并且是有意义的，但大多数 Ansible 用户并不是 Python 爱好者。因此，当这些风格被纳入其中时，可能会带来挑战和困惑，从而产生摩擦，降低他们的用户体验和 Ansible 提供的价值。
由于 Ansible 不是一种编程语言，因此组织的各个部门都可以参与到整个 IT 堆栈的自动化中，而不是依赖于熟练的程序员来理解您的操作，并为其编写和维护代码。
如果您是创建 Ansible 模块和插件的程序员，请假设您不是您正在开发的目标受众，并且您的目标受众不会拥有您所拥有的相同技能和资源。
清晰优于杂乱。简洁优于冗长。简单优于复杂。可读性至关重要。
这些实际上只是“Python 之禅”中格言的解读。最后一个直接取自其中，因为您无法改进完美。
在最初的 Ansible 最佳实践演讲中，我们建议用户优化可读性。这在今天甚至更加重要。如果操作得当，您的内容可以成为工作流自动化的文档。花时间使您的自动化尽可能清晰简洁。迭代您创建的内容，并始终寻找简化和澄清的机会。
这些格言不仅适用于编写 playbook 和创建角色的人。如果您是模块开发人员，请考虑您的工作如何帮助用户，保持清晰简洁，简单地做事，并完成任务。
帮助用户完成任务最重要。用户体验胜过意识形态的纯洁性。
无论您是创建模块、插件和集合，还是编写 playbook 或设计跨域混合自动化工作流——Ansible 都是为了帮助您完成任务。始终考虑并努力最大化用户体验。不要陷入对某些严格的标准或意识形态纯洁性的解读，从而将负担转移到最终用户身上。
“魔法”征服手动操作。
亚瑟·克拉克写道：“任何足够先进的技术都与魔法无法区分。”
Ansible 中的“魔法”是其 playbook 引擎和模块系统。它是 Ansible 如何以简单易懂的方式提供强大而灵活的功能，通过将用户从底层所有复杂的实现细节中抽象出来。这使用户免于执行耗时且容易出错的手动操作或编写脆弱的一次性脚本和代码，使他们能够将宝贵的专业知识用于需要的地方。
设计使用户惊叹的自动化可以使困难或乏味的任务变得轻松而几乎毫不费力。努力提供强大的节省时间的功能，这些功能易于部署和使用，并利用它们来完成任务。
在为用户提供选项时，使用约定优于配置。
我非常支持约定优于配置，并且认为它在 Ansible 社区中没有得到足够的重视。约定优于配置是一种设计范式，它试图减少开发人员需要做出的决策数量，而无需牺牲灵活性，因此他们不必重复自己。它是由 Ruby on Rails 推广的。
利用您工作的 playbook 开发人员只需要指定其自动化任务和工作流中独特且非传统的方面，仅此而已。努力减少用户需要做出的决策和实现细节的数量。花时间为他们处理最常见的使用案例。尽可能为模块、插件和角色提供合理的默认值。优化用户快速完成任务。
声明式优于命令式——大多数情况下。
这条格言尤其针对 Ansible 内容集合开发人员。Ansible 按照设计是一种期望状态引擎。首先考虑声明式。如果确实无法以声明式方式设计某些内容，则使用命令式（过程式）方法。
声明式意味着配置由一组事实保证，而不是由一组指令保证，例如，“应该有 10 台 RHEL 服务器”，而不是“根据正在运行的 RHEL 服务器的数量，启动/停止服务器直到您拥有 10 台，并告诉我它是否成功”。
这条格言是“用户体验胜过意识形态的纯洁性”格言在实践中的一个例子。Ansible 结合了声明式和命令式方法，而不是严格坚持声明式的方法来进行自动化。这种混合为您提供了灵活性，可以专注于您需要做的事情，而不是严格遵循一种范式。
专注避免复杂性。复杂性降低生产力。
请记住，复杂性降低生产力。红帽的 Ansible 团队真的非常重视这一点，并且相信这一点。这不仅仅是一个营销口号。自动化可以克服复杂性，并为您提供您永远无法获得足够多的东西——时间。
遵循Linux 的“做好一件事，并做好”的原则。使角色和 playbook 专注于特定目的。多个简单的 playbook 比一个包含条件和 Ansible 不太适合的“编程”的大型 playbook 更好。
我们努力简化 Ansible 的设计方式，并鼓励您也这样做。努力简化您自动化的内容。
如果实现难以解释，那它就是一个坏主意。
这条格言，就像“可读性至关重要”一样，也直接取自“Python 之禅”，因为您无法改进完美。
在关于文学编程的论文中，Donald Knuth写道：“与其认为我们的主要任务是指示计算机该做什么，不如让我们专注于向人类解释我们希望计算机做什么。”因此，如果您无法轻松地解释或记录您的实现，那么它就是一个需要重新考虑或放弃的坏主意。如果它难以解释，那么其他人理解、使用和调试它的可能性有多大？Kernighan 定律指出：“调试的难度是编写代码的两倍。因此，如果您尽可能巧妙地编写代码，那么根据定义，您不够聪明，无法调试它。”
Ansible 的设计理念源于人们的真实思考和工作方式。还记得之前我提到过 Ansible Playbook 是人类可读的自动化脚本，无需任何特殊的编码技能吗？充分利用这一点。然后，如果你在解释想要做什么时遇到困难，请暂停并重新考虑你的实现方式以及你试图自动化的流程。如何才能更容易地解释？我的流程是否可以改进或简化？如何简化和澄清？能否将其分解成更小、更集中的部分并进行迭代？
这将帮助你尽早识别出不好的想法，并避免那些会随着时间的推移而拖慢你和组织速度的摩擦点。
每个 shell 命令和 UI 交互都是一个自动化机会。
这句格言源于我多年来与人讨论 Ansible 和自动化的个人经验。有时有人会问我应该自动化什么。其他时候，有人会质疑像 Ansible 这样的自动化工具是不必要的，或者不适用于他们正在做的事情。无论我们讨论的是 RHEL、Windows、网络基础设施、安全、边缘设备还是云服务，多年来我的回答基本上都是一样的。我重复了这么多次，以至于我开玩笑地将这个观点总结成了我自己的自动化定理。所以，如果你愿意，可以称之为“Appnel 的自动化定理”。
如果你想知道应该自动化什么，请查找任何人在 Linux shell 中输入的内容以及在用户界面中点击的操作。然后问问自己“这是否可以自动化？”然后问“自动化这件事有什么价值？”大多数 Ansible 模块都封装了命令行工具或使用了 UI 后面的相同 API。
在确定了足够多的自动化对象后，从那些造成最大痛苦且可以快速完成的对象开始。记住，你希望创造一个良性循环，在你的组织中发布可靠性、反馈并建立信任。快速展示进度和业务价值将有助于实现这一点。
仅仅因为某些东西有效，并不意味着它不能改进。应尽可能消除摩擦。
这第一句格言恰好出自电影《黑豹》，它优雅地表达了在 Ansible 自动化方面的一些重要智慧。
始终迭代并适应来自你运营的真实世界反馈。优化可读性。继续寻找方法来简化并减少你组织及其流程中的摩擦。随着时间的推移，你的环境和 IT 策略中引入的变化将产生新的摩擦和痛点。它们也将创造新的机会，让你能够应用自动化实践来消除这些问题。
自动化是一段永无止境的旅程。
古希腊哲学家赫拉克利特说：“变化是生活中唯一不变的事物。除了变化，没有什么是永恒的。”
任何在 IT 行业工作过一段时间的人都知道，变化是持续不断的。这就是为什么敏捷性和快速可靠地响应持续变化、创新和业务需求至关重要的原因。
自动化不是终点。它是一种实践。它是一种文化、一种思维方式和一种态度。自动化是一个持续的反馈和学习、适应变化以及改进之前所做工作的过程。
自动化创造了机遇，我们在 Red Hat 看到自动化无处不在。
所以我向你提出的问题是：你的自动化之旅将把你带到哪里？
进一步阅读
如果你想更深入地了解 Ansible 的禅意及其起源，我推荐以下资源。
Ansible 社区实践 (CoP) 已汇集了 一个关于 Ansible 内容开发“最佳实践”的综合资源库。 Ansible Lint 工具 现已添加到 Red Hat Ansible Automation Platform 中，并将许多这些实践编纂成规则和配置文件，以帮助你快速识别并强制执行一致的应用到你的工作中。
如果你有兴趣更多地了解“Python 之禅”，我建议从 Al Sweigart 对这些格言的解释 开始。
