Ansible过去与未来的发展

最近，Ansible 2.1已经发布。
我之前还写了一篇关于Ansible 2.0发布的文章，但这次是自2016年1月以来的一次重大更新。

这篇文章中提到

• Ansible 2.0まで

• Ansible 2.1のアップデート

Ansible 2.2のロードマップ

我想要关注一下Ansible过去和将来的发展。

Ansible过去的历程

当回顾 Ansible 从 GitHub 仓库的 CHANGELOG 来看，我们可以追溯到它的面世始于 2012 年。
以下是 2.0 版本之前各个版本及其发布年月的情况。

选择艺术家的歌曲名称作为开发代号的做法非常独特。在1.0版本中选择了Van Halen的歌曲名称，而在2.0版本中选择了Led Zeppelin的歌曲名称作为发布名称。顺便提一下，在主要发布的CHANGELOG中，根据简单的行数排序，以下是前三名。

1. 2.0（357行）

1.3（146行）

1.1和1.2（133行）

仅仅通过观看这一点，就能知道2.0版本的更新有多么巨大。

Ansible 2.1 – 安西布 2.1

在最近几天内，Ansible 2.1作为2016年第二次重大更新发布了。

您可以查看 Ansible 2.1 升级内容的 CHANGELOG，但以下的发行说明文章也是可以参考的。

• INTRODUCING ANSIBLE 2.1: NETWORKING, WINDOWS, AZURE, AND CONTAINERS

Red Hat Debuts Ansible 2.1, with Network Automation, Containers, Microsoft Windows, and Azure

总结发布内容的大致内容如下：

Windows的官方技术支持

正如上面的发布表所写的那样，Ansible从1.7版本开始就在推进针对Windows环境的功能实施。经过大约两年的时间，到了2014年，Ansible 2.1宣布正式支持Windows。通过将WinRM引入到以SSH为核心的Ansible中，实现了对Windows的支持。

同時に，我們也在加強對微軟Azure的支援，以迎合Windows的正式支援。在雲端領域中，AWS的支援一直處於領先地位，但由於被RedHat收購的原因，也可能為Azure的支援帶來幫助，看起來也在不斷進展中。

网络支持的加强

Ansible不仅作为配置管理工具，还能控制操作系统之上的层次。现在，在概述中。

Ansible是一个根本简单的IT自动化引擎，用于自动化云服务提供、配置管理、应用部署、服务之间协调和许多其他IT需求。

自声明以来，Ansible已经超越了仅仅是一个配置管理工具的框架，发展成为可以控制整个环境的工具。
在这个过程中，为了实现对本地环境的控制，增强了网络支持。
在这个Ansible 2.1版本中，

• Cisco

• HP

• Juniper

• Arista Networks

Cumulus Networks

通过添加相关模块，并通过API控制每个网络设备，实现了更加灵活的环境控制。

加强对Docker的支持

Ansible对于Docker的支持非常古老，可以追溯到1.4时代。然而，与Docker相关的模块添加进展缓慢，

• (1.4) docker: コンテナの作成/削除および管理

• (1.5) docker_image: Dockerイメージのbuild, load, pullおよびtag付け

(2.0) docker_login: Docker Registryへの認証およびローカルファイルへの認証情報追加

但是，在2.1的更新中，这些模块被重新构建，

• docker_service

• docker_container

• docker_image

• docker_login

docker_image Facts

在docker_service模块中特别提到了对Docker Compose和Docker Swarm的支持，这使得能够有效地支持Docker服务的部署。

Ansible的未来发展

在 Ansible 2.1 的发布文章的结尾部分，

请下载Ansible 2.1并告诉我们您的想法。在不久的将来，我们将向社区发布一份针对Ansible 2.2版本的建议路线图，希望能听到您的反馈意见。

根据此文章所述。
在2016年5月26日这篇文章发布时，尚未能确认2.2版本的路线图。然而，在6月6日突然查看了存储库后，发现2.2版本的路线图正在逐渐形成。

Ansible 2.2是一款软件。

(注意) 以下内容基于2016年6月7日的提交记录（commit: b33aeee）。

ROADMAP.rst

如果查看这个路线图，目前正在讨论Ansible 2.2方面的情况。

我们目前正在努力完成2.2版本的路线图，计划在九月交付。我们正在寻求社区对2.2版本的反馈。

在这种情况下可以看出。
那么，让我们逐步检查具体的路线图。

ROADMAP_2_2.rst

Docker支持的扩展

看起来Docker支持将继续扩展，就像2.1版本一样。
考虑到模块名称，

• Docker_network

• Docker_volume

• Docker_file

• Openshift modules

Kubernetes modules

可能是应该关注的有 Docker_network 和 Kubernetes modules 部分，过去只处理单个容器，但现在似乎正在朝着控制整个环境的方向发展，就像在2.1版本中对Docker Compose的支持一样。此外，由于是由RedHat进行开发，OpenShift的兼容性也在进一步发展。

核心功能的分离

看起来目标是在2.2版本或稍后实现核心功能的分离。
通过进行核心功能的分离，它们将不再依赖Ansible的核心开发，并能够按照社区标准进行开发。
未来计划包括

• モジュール位置の検討(Core or Extras)

• パッケージの分離

• 依存関係の解決

リリーススケジュールの策定

看起来会进行诸如这样的活动。

增强云支持

尽管已进行了2.0的大规模增强，但似乎仍在继续加强对各个云平台的支持。

• AWS

• GCP

• OpenStack

• Azure

VMware

人们对OpenStack和Azure中的负载均衡服务（LBaaS）的支持表示关注。

加强对Windows支持

即使在2.2版本，Windows的支持也将继续增强。从观点上来说，似乎有两种不同的情况。

• WindowsサポートとLinuxサポートの同等化

Windows固有の機能拡張

这个话题已经总结了起来。
Windows特有的功能扩展涉及到与Kerberos认证有关的部分，以及与Windows Server 2016的兼容性，也意在解决与Nano Server相关的问题。
我从来没有听说过有人正在使用Nano Server，但是微软已经认真对待，并推出了Windows作为容器宿主机，所以未来的服务器行业变化难以预测。

此外，我还在默默关注着在同等化的背景下讨论的问题。

PS module API (mirror Python module API where appropriate)

这部分。

目前，对于Linux机器的Ansible执行是通过”通过SSH连接并执行Python程序”来实现的。
另一方面，对于Windows机器，则需要通过”通过WinRM连接并执行PowerShell程序”来实现。
无论连接方式如何，关键是要核心执行Python或PowerShell的区别。因此，为了确保在Linux和Windows中拥有相同的Ansible功能，我们需要巧妙地控制这种差异。

当然，将Python API和PS API完全镜像对应是不容易的，所以可能在这方面要有所适应。

AnsibleModule是一个包含许多不相关实用功能的庞大类。也许我们应该同时重新设计它们？

第一，我认为首先Linux方面要迎头赶上才能达到Windows方面的大目标，但与此同时我也想要密切关注Windows服务器领域的发展动向。

网络支持的增强

这方面的支持将继续得到加强。作为令人关注的一点，

Add support for config diff and replace on supported platforms

根据某些说法，看起来可以对网络设备进行差异确认。

角色改版功能的整合

似乎由核心贡献者@bcoca开发的角色改革功能正在进行中。
开发的动机是，

角色是一种很好的资源共享和重复利用的方式，但在应用方面有一定的限制。这个提案旨在扩大角色的实用性和可重复利用性。

似乎是这样的。
具体来说，这意味着什么？

• roleのmain.yml実行制御

roleからのinclude

据说他们想把“を盛り込んでいきたい”融入进去。

据说在目前的情况下，使用 role 命令会无条件执行 main.yml，但是通过声明一个新的属性 exec_main: false，可以限制执行 main.yml。

    - roles:
        - role: myrole
          exec_main: no

另外，如果在include任务中使用role属性指定角色，可以让角色内的任务可以被单独引用。

    - include: tasks.yml
      role: myrole

目前为止，对于现在的情况，我的印象是有点方便但也有点不方便，我们可以以温暖的态度继续观察。

强化Vault支持

Ansible 1.5以后推出的ansible-vault，在某种程度上可以说是一匹难以驯服的野马。
当然，在进行配置管理时，不可避免地需要处理各种密码，因此出现这样的加密想法也是很自然的。
然而，目前的vault会将整个文件进行加密，因此当将变量集中到一个文件中时，会导致不需要加密的变量也变得无法阅读，增加了维护的难度等问题。

然而，当我们看到2.2的内容时，

• Add “per variable” vault support

Add vault/unvault filters

看起来，我们能够看到一些变化，不仅文件级别上，而且在变量级别上也可以进行加密。
基本上，密码管理呈现出类似于捉迷藏的情况，但最近流行的密码管理工具可以通过强大的ansible-vault来保护散布在不同配置信息中的密码，并实现无压力的自动化，这是非常令人高兴的事情。

Python 3兼容

最近很多開源軟體都在討論這個問題，包括Python。而Ansible也如其他軟體一樣，似乎正在穩步地為Python 3進行準備。

• RHEL8においてPython2系がデフォルトで入らなくなる

非LTSのUbuntuでは既にPython2系がデフォルトでなくなっている

似乎有，他们把Python 3兼容性视为高优先级。当然，这并不意味着他们在2.2版本就能完成兼容，因为它需要Ansible 2.0或更高版本的大规模调整。作为分阶段的目标，

• Ansible 2.2

コントローラ側のコードがPython 3で動く
ユーティリティモジュールをPython2/3の両対応にし、ユニットテストを充実させる
…

Ansible 2.3

基本的なモジュールのPython 3化を進める(パッケージマネージャ等)
Python 2.6+ 対応のモジュールをPython 3に対応させる
モジュールが”Python 3で動く”とはどういうことか理解して整理する
…

我提出了一些建议，但基本上是表达了要”努力”，所以这可能会是一项相对长期的努力。

总之，RHEL 8可能在2020年前发布，所以在那之前要完成这些适配是必要的。从Ansible 1.x升级到2.x的人应该能够理解，可能需要做出各种适应措施，因此需要考虑如何处理现有资产。

最后

我认为，通过观察到目前为止和未来的Ansible，作为一种配置管理工具，Ansible在功能上已经非常成熟。
目前，它的范围已扩展到整个环境的网络到群集，我们可能已经到了可以进一步深入使用的阶段了。

如众所周知，Ansible是与YAML一起使用的非常易于使用的工具。
开发社区越来越强大，不再需要强制使用较少的功能。
尽管看不到路线图的尽头，但聪明的人们在考虑下一步时可能会考虑这种世界观，这可能会激发我对每天接触的环境的想法。