让我们回顾一下Ansible在2017年的表现

1 年 ago

文, 翔

1 minute

首先

我之前写过这样的文章。

Ansible 2.0リリース！

Ansible 2.0がリリースされたときに書いたもの
Ansible 2.0リリース記事の日本語訳

Ansibleのこれまでとこれから

Ansible 2.1がリリースされたときに書いたもの
これまでの振り返りとロードマップの解説

然后，仔细思考后，我注意到虽然Ansible 2.2已经发布了，但却没有任何相关文章，这是一个严重问题。
因此，为了填补Advent Calendar的空缺，我开始撰写了这篇文章。

Ansible 2.2 – 安赛布尔 2.2

现在我们会从CHANGELOG和发布文章中了解一下Ansible 2.2发布版的特点。

Ansible 2.2带来了性能提升、扩展容器和Windows自动化能力以及几个新模块，其中包括网络、云服务提供商平台和扩展的保险库支持。

听说是这样的。
在2.0和2.1版本中也有类似的公告，但Ansible 2系会继续推出针对「容器」、「Windows」、「网络」和「云」的功能。

Ansible 2.3 分析参数配置。

好了，接下来让我们来看看未来的话题吧。
这个信息来源是 2.3 路线图文件。

当我开始跟踪这个人时，首先

目标：2017年2月/3月

我注意到的一点是，发布计划在2017年的2-3月期间。上一次的Ansible版本是在2016年10月发布的，所以这次的更新距离上一次只有半年的时间。

看看每个主题标题的例子，

Plugin Loader

「整体支持」「Windows支持」「网络支持」「Python3支持」「云端支持」等等都可以看作是很重要的组成部分。让我们再仔细看看这些方面。

整体配合

查看核心团队的普遍评论时，

Ansible Core 2.3与我们之前的两个主要版本略有不同。除了进行功能改进外，我们还利用了本版本的一部分时间来减少一些非纯开发领域的积压工作。

以下所述内容：
這段文字提到了另外一些事情。具體來說，它似乎是關於開發團隊的管理、代碼庫的運營和Ansible文件的更新。也許這些方面被紅帽收購後有所改善和強化。無論如何，這都是令人讚嘆的事情。

兼容Windows

Ansible 2.1中开始正式支持Windows环境，但与Linux环境相比，功能仍然不足。
虽然在Ansible 2.2版本中添加了许多功能，但在接下来的Ansible 2.3中，我们可以看到一些加强措施，例如缩短执行时间的管道操作（Pipelining），进行权限提升的become，以及与Kerberos认证的集成等，这些都强化了Ansible本身的功能。
就Windows环境而言，添加了一些*域模块（win_domain_）*的功能应该是重要的改进之一。

网络兼容

雖然作為描述的量並不多，但 Ansible 2.0 後的 Network 功能的重點支援似乎仍在 Ansible 2.3 中繼續。
正如 CHANGELOG 中所提到的，Ansible 2.2 在 F5 BIG-IP 和 Cisco NXOS 上添加了許多模組。
不知不覺間，Ansible Docs 的 Network 模組頁面變得相當長。

代码稳定性和整理

根据某些迹象，对于迅速增长的网络功能需要继续高度重视进行维护的可能性很大。

Python3 兼容

我本身也有一些顾虑，但Ansible目前正在推进Python3的兼容性。
Ubuntu已经将Python3作为标准捆绑软件了，而且从RHEL的发行记录来看，明年或后年可能会发布Python3成为标准的RHEL8。
换句话说，从Ansible这个与RedHat为伍的角度来看，必须在RHEL8发布之前务必完成Python3的兼容性。

所以，

对于2.3版本：

我们希望所有测试都通过（大部分测试都通过了，但还有10-20个需要修复的）
如果用户报告在Python3上出现了漏洞，我们应该对其进行修复，并将优先工作于迁移其他模块。

目標はAnsible 2.3中通过所有测试。顺便提一下，

注意：目前大部分ansible功能已经测试通过。但仍有许多代码未经过测试。

据一种说法，已经大致可以运作了。

云端可用

那么现在让我们来看一下云端适用性的部分。
这里有所谓的“AWS适用”和“Azure适用”。根据最近的调查结果来看，尽管AWS仍然是市场上的霸主，但是与其后继者Microsoft（Azure）、Google（GCP）和IBM（Bluemix）相比，可以看出Microsoft的增长非常明显。
在这种情况下，Ansible也引人注目地进行了AWS和Azure功能的扩展。
在AWS方面，它似乎在支持ALB以及重构Dynamic Inventory脚本ec2.py等方面进行了改进。

当我漫不经心地浏览云模块时，我觉得 AWS、Azure 和 VMware 这些供应商特别多。还有一些开放式虚拟化技术，比如 OpenStack 和 Ovirt。

许多企业希望在战略上更有效地利用IT，而往往会制定混合云和多云战略。考虑到诸如Ansible的配置管理在准备阶段的有效性，可以认为这种云端适配的趋势将持续下去。

Ansible 2.4：安锐百 2.4。

我已经写了相当多了，但请再陪我一段时间。
大约两周前的2016年12月13日，Ansible 2.4的2.4 Roadmap文档发布了。

頭部上

这是一个活的文件，除非在文件中另有说明，否则绝不是最终版本。

因为这是前言，所以还在制定中，但让我们先来看看目前的内容。首先，

交付目标：2017年6月/7月

根据某些消息，2017年6-7月似乎是发布的目标。
正如刚刚确认的那样，Ansible 2.3的发布是在2017年2-3月，因此发布将在不到半年的时间内进行，甚至可能会在3个月内完成。
在对话题进行进一步确认后，

Contributor Quality of Life

根据描述，感觉更像是一个维护版本而不是功能发布。让我们来看看具体内容。

Ansible-配置

为配置添加新的YAML格式-通过添加ansible-config命令来扩展当前配置系统的功能。

根据消息，终于开始处理被淹没在YAML中的ansible.cfg了。迄今为止的配置文件将被更新。

log_path=/var/log/ansible.log

就像这样，它变成了一种常见的形式。然而，随着Ansible的发展，变量的数量与模块的增长一样不断增加，在参考示例的同时，老实说我已经不太清楚能够进行的全部配置了。
这一点正好在今年的Ansible Advent Calendar 2016第16天中整理了ansible.cfg的项目列表，这让我有了一些动力。

一旦进入Ansible 2.4版本，将会引入ansible-config命令。

清除现有的配置设置
更新/写入配置条目
显示可用选项（ini条目、yaml、环境变量等）

似乎可以成为可能。
从公共关系方面来看，似乎已经公开了相当长时间，里程碑版本是2.2或2.3，所以似乎进展得相当长了。
虽然查看了2.0之后的路线图，但这是第一次听说这个消息，所以是否意味着即将确定发布的时间呢？非常期待。

存货大修

好的，刚刚在提到ansible.cfg时，我表达了“被YAML淹没的ansible被落下了”的观点，但还有一个方面被落下了。
没错，那就是Inventory。

通过重新设计 Dynamic Inventory，使其具有结构化相等的 JSON 表达能力，而 Static Inventory 继续采用了像 ini 格式这样的独特路线。

因此，在 Ansible 2.4 中，我们进行了 Inventory Overhaul（即库存全面改进）的工作。

目前的存货明显过于复杂、非模块化，并且大部分仍然是早期遗留下来的。我们还希望为大多数存货源添加一套共同的功能，但受限于当前的代码基础。

表明了这种动机。

作为问题的解决方案，提出了“摆脱伪插件”和“确保后向兼容性”等，但由于是关于内部运作的话题，所以还不清楚用户会有什么变化。

确实，虽然在操作上必须涉及库存管理，但 Ansible2 系列几乎没有发展，所以我觉得终于来了。

我个人正在尝试创建一个动态库存！在一篇文章中也写到了“动态库存一点也不可怕^^”，如果这样可以使静态库存的操作变得更容易，那就太好了。

贡献者的生活质量

这个标题为“贡献者生活质量”的部分，只有一条信息。

更多的机器人改进！

在查看Ansible的GitHub时，我注意到有一个叫ansibot的存在。虽然不太了解它的功能，但我想了解在像Ansible这样的大型开源软件开发中，是如何利用机器人的，并希望能够获得一些减少自己工作量的创意。

最后

又一次，我写了一篇观看路线图的文章。
不过，2.3和2.4似乎都会在2017年上半年左右发布，所以2017年对于Ansible的信息追赶来说将是一个非常忙碌的年份。
明年会有Ansible 3.0的构想之类的出现吗…。

今年也辛苦了。明年也請多關照！

2026年10月26日，宣布将IaaS品牌SoftLayer转向PaaS品牌Bluemix。