经过了一年的开发工作后, Ansible 2.0 终于发布,现在已经是 GA 版了。这是目前为止最为闪耀的一个 Ansible 版本,它折射出了社区所贡献的巨大力量,这一切也令所有人感动万分。大约有 300 个用户对这个版本贡献了代码;自上一个主要的 Ansible 版本发布后,约有 500 个用户贡献了代码。
我们为何要开始 V2 的开发?
重构软件的过程中会遇到很多陷阱,那么我们为何要开启这个项目呢?在我们开始进行v2 的开发时,Ansible 距离最初的发布已经有3 年多的时间了,并且有超过1,000 个贡献者为其贡献代码。这种持续的增长也导致代码中出现了技术债务,这些技术债务在我们不断添加新特性的时候开始显现出来。
最终,我们决定退回一步,重新编写现有代码基中那些容易产生问题的部分。我们还重写了负责解析Playbook 与其他YAML 文件的代码,从而使得添加语言特性能够变得更加轻松,同时提供关于解析问题的更多错误信息。最后,我们做了划分并重新组织代码,让查找变得更加容易,并且删除了一些“辅助”代码;这些“辅助”代码已经变成了零散物品的收集器,将那些不知道该放在什么地方的代码都容纳了进来,实际上这是不对的。
在这整个过程中,我们的一个基本目标是保持对既有Playbook 的向后兼容性。对于解析与运行Playbook 来说,我们相信自己已经达成所愿。不过,对于某些特性来说还是存在一些不兼容的情况,用户需要清楚这一点,后面也会进行介绍。
新特性有哪些?
Ansible 2.0 并不仅仅只是对既有系统的重构。更清晰的架构可以让我们添加一直想要添加的新特性;同时由于重构的原因,我们还添加了之前一直无法添加的新特性。
任务块
块(Blocks)引入了对 Playbook 异常处理的概念,它根据 Python 的 try/except/finally 结构进行建模(同时也是其他很多语言的使用方式)。这简化了 Playbook 与任务的开发工作,其中任务失败可以被捕获到,并且在单个 Playbook 中进行处理,这一切要比之前简单太多了。用户还可以通过块使用标签与条件(以及其他任务属性)对相关任务进行分组。
Playbook 解析、错误报告改进与动态包含
如前所述,我们几乎完全重写了负责解析与解释 Playbook 的代码。新的代码提供了更加清晰的错误识别能力,同时还给出了超越简单的 YAML 语法错误的修复建议。除此之外,包含任务现在可以动态执行了。在 Ansible 1.9.x 及之前的版本中,包含的行为更像是预处理语句,任务会内联展开。这会导致用户在循环中使用包含时出现问题(Ansible 1.6 删除了该特性)。Ansible 2.0 则将该特性又加回来了,甚至比之前更加灵活。
新的执行策略插件
该特性是由于重构才添加进来的。执行策略可以让用户修改 Ansible 在目标主机上运行任务的方式。经典的 Ansible 任务是个单任务,在转向下一个任务前需要在所有主机上运行(现在我们称之为“线性”策略)。Ansible 2.0 也包含了“自由”策略,可以让每个主机尽快处理任务列表(依然是按照顺序的),同时又不必等待其他主机的处理。由于这些都是以插件的形式出现的(就像 Ansible 中的其他插件),因此用户可以自由选择这些策略。
新的模块
Ansible 2.0 包含了 200 多个新模块,从而延续了我们一直以来所秉承的“电池内置”策略。一些主要模块有:
- 用于管理 OpenStack(主流的开源云计算框架)的全新模块集,这是与 OpenStack 社区合作开发的
- 30 个全新模块,用于改进与扩展对 Amazon Web Services 的支持
- 对于 VMware 环境配置与管理的进一步支持
- 对于 Microsoft Window 环境的进一步支持
- 对于 Docker 模块的实质性改进,以及新的 Docker 连接插件
Ansible 2.0 的已知问题
如前所述,Ansible 对于既有 Playbook 存在一些不兼容的情况,同时还有一些小问题,我们会在未来修复这些问题。
Plugin API 变化
在内部,我们所做的主要的代码清理工作之一就是让每个插件类(action、callback、lookup 等)都继承自一个共同的父类。这样就可以删除大量的重复代码。不过,这也意味着插件 API 发生了巨大的变化。已经编写过一些插件的用户可能需要更新其插件才能使用 Ansible 2.0。
动态包含问题
由于现在的包含任务是在运行期计算的,因此 Ansible 无法提前预知文件中应该包含哪些任务。这会在一些情况中出现问题(未来的版本中将会修复这些问题):
直到包含处理时才会看到任务标记,因此标记现在应该在包含任务上指定而非包含中的具体任务,否则将看不到他们。与之类似,–list-tags 选项无法展现只位于包含文件中的标记。只有当任务尝试通知时才会看到包含中的处理器,因此处理器这时应该避免使用包含。
丢失的标记
如果通过–tags 或是–skip-tags 指定了不存在的标记,那么 Ansible 2.0 现在是不会报错的。这也与之前提到的动态包含问题相关,一旦上面提到的问题解决后我们就将解决这个问题。
反斜杠转义
在 Ansible 1.9.x 及之前的版本中,某些情况下,反斜杠(“\”)需要转义两次,这会导致 4 个反斜杠序列(“\\\\”)。对于上面所提及的 Playbook 的改进意味着只需对反斜杠转义一次即可。还有其他一些细小的特性变化,我们会在迁移指南中以文档的形式记录下来。该指南还包含了对于诸如反斜杠转义等问题的解决办法。
评论 2 条评论