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までの各バージョンとリリース年月は下記のようになっています。

バージョン	年月	開発コード	備考
0.01	2012/03	-	開発リリース
0.3	2012/04	Baluchitherium	初のリリース
1.0	2013/02	Eruption
1.1	2013/02	Mean Street	dry-run, diffモードの実装
1.2	2013/06	Right Now	start-at-task, retryオプションの実装
1.3	2013/09	Top of the World	role default, dependenciesの実装
1.4	2013/11	Could This Be Magic
1.5	2014/02	Love Walks In	include + with_* 組み合わせの無効化、ansible-vaultの登場
1.6	2014/05	And the Cradle Will Rock	$foo形式の変数参照を廃止
1.7	2014/08	Summer Nights	Windowsサポートの開始(Alpha)
1.8	2014/11	You Really Got Me
1.9	2015/03	Dancing In the Street	特殊タグ(all, always, ...)の追加
2.0	2016/01	Over the Hills and Far Away	RedHat買収後、初のリリース

開発コードにアーティストの曲名を選んでいるところがユニークですね。1.0系では Van Halen 、2.0系では Led Zeppelin からリリース名を取っているようです。
ちなみに、メジャーリリースにおけるCHANGELOGの単純な行数では、下記がTop3となっています。

2.0 (357 lines)
1.3 (146 lines)
1.1, 1.2 (133 lines)

これを見るだけでも2.0のアップデートがどれだけ巨大なものだったかが分かります。

Ansible 2.1

そうした中で、つい先日2016年2度目の大型アップデートである Ansible 2.1 がリリースされました。

Ansible 2.1のアップデート内容については、先ほど同様に CHANGELOG を見てもよいですが、下記のリリース記事が参考になります。

リリースの内容を大まかにまとめると、以下のようなものが挙げられます。

Windowsの正式サポート

上のリリース表にも書いている通り、Ansibleは1.7の頃からWindows環境のための機能実装を進めていました。
それが2014年から約2年を経て、Ansible 2.1において正式なWindowsサポートをアナウンスに至りました。
SSHをコアとするAnsibleにWinRMを迎え入れ、Windowsサポートを実現しています。

また、このWindows正式サポートに合わせ、Microsoft Azureへの対応強化も行っています。
クラウド界隈と同じように、AWS対応が先行していましたが、RedHatに買収されたことも手伝ってか、Azureへの対応も進んでいるようです。

Networkサポートの強化

Ansibleが元々実現していたのは構成管理ツールとして、OSより上のレイヤーをコントロールすることでした。
ところが、今や OVERVIEW において、

Ansible is a radically simple IT automation engine that automates cloud provisioning, configuration management, application deployment, intra-service orchestration, and many other IT needs.

と宣言するに至り、単なる構成管理ツールの枠を超え、環境全体をコントロールするツールに成長してきました。
そうした中で、オンプレミス環境のコントロールをも可能にすべく、Networkサポートの強化が図られました。
今回の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のリリース記事の結びでは、

Download Ansible 2.1 and let us know what you think. In the very near future, we’ll publish a proposed roadmap to the community for feedback targeting Ansible version 2.2. We’d love to hear your feedback.
(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について現在は

We are currently trying to finalize the 2.2 Roadmap, targeted for September delivery. We are seeking community feedback for 2.2.
(現在私たちは、9月リリース をターゲットとした2.2ロードマップの仕上げに取りかかっています。2.2に関するコミュニティからのフィードバックを受け付けている最中です。)

という状況であることがわかります。
では、具体的なロードマップを順に確認してみましょう。

ROADMAP_2_2.rst

Dockerサポートの拡張

2.1に引き続き、Docker対応が拡張されるようです。
モジュール名を見てみると、

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のサポート強化は続きます。
観点としては2種類あるようで、

WindowsサポートとLinuxサポートの同等化
Windows固有の機能拡張

でトピックがまとめられています。
Windows固有の機能拡張ではKerberos認証に関係する部分や、Windows Server 2016への対応、気になるところとしてNano Serverに対する対応も目指されているようです。
今のところNano Serverを使っているというようなことを聞いたことはないですが、本気になったMicrosoftさんがコンテナホストとしての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を全く同じに(mirroring)対応することは単純にはできませんから、おそらくそうした点に対して、

AnsibleModule is a huge class with many unrelated utility functions. Maybe we should redesign both at the same time?
(Ansibleモジュールは無数のユーテリティを伴った非常に大きなクラスとなっており、この対応と一緒に再設計をしたほうがいいのでは？)

というコメントが添えられています。
まずはLinux側に追いつくことがWindows側の大きな目標だと思いますが、Windowsサーバ界隈の動きと合わせてウォッチしておきたいと思います。

Networkサポートの強化

こちらも引き続きサポートが強化されていきます。
気になる点としては、

Add support for config diff and replace on supported platforms

とあるように、Network機器に対してもdiff確認ができるようになるようです。

role revamp機能の取り込み

role revamp機能なるものがコアコミッタである @bcoca によって開発されているようです。
モチベーションとしては、

Roles are a good way to share and reuse resources, but they are a bit limited in application. This proposal aims at expanding the usefulness and reusability of roles.
(ロール機能は、資産の共有と再利用にいい方法である。ただ、それらは少しアプリ依存な部分がある。この提案では、ロールの利便性と再利用性をさらに向上させることを狙っている。)

ということのようです。
具体的にどういうことかというと、

roleのmain.yml実行制御
roleからのinclude

を盛り込んでいきたいそうです。

現状では、roleを使うと無条件にmain.ymlが実行されますが、ここに新たな属性である exec_main: false を宣言することで、main.ymlの実行を制限することができるそうです。

    - roles:
        - role: myrole
          exec_main: no

また、下記のようにincludeタスクにrole属性でロールを指定してやると、ロール内のタスクが個別にincludeできるようになるとか。

    - include: tasks.yml
      role: myrole

今の時点では、「便利なような...」「そうでもないような...」という印象ですが、暖かく見守ってみましょう。

Vaultサポートの強化

Ansible 1.5から登場した ansible-vault ですが、まぁこれが中々のじゃじゃ馬でした。
もちろん構成管理をしていく上で、様々なパスワードを扱わざるを得ず、このような暗号化のアイデアが生まれるのは当然のことではありました。
ただ、現段階でのvaultはファイルをまるっと暗号化してしまうため、変数を1ファイルにまとめた場合に暗号化する必要のない変数まで読解不能になり、メンテナンスがしづらくなってしまうなどの問題もありました。

しかし、2.2の内容を見てみると、

Add "per variable" vault support
Add vault/unvault filters

などが見え、ファイル単位でなく変数単位での暗号化が可能なようになっていくようです。
基本的にイタチごっこの様相を呈するパスワード管理ではありますが、最近流行りのパスワード管理ツールのように、様々な構成情報に散在するパスワードを強力なansible-vaultで守りつつ、ストレスフリーに自動化を実現できる手段が存在することは大変喜ばしいことだと思います。

Python 3対応

最後に大物がやってきました。
Pythonで実装されているOSSは最近どこでもこういった話をしていますが、その例に漏れずAnsibleでもPython 3対応に向けて着々と準備を進めていくようです。
Python 3対応の背景には、

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

があるようで、Python 3対応を high priority と位置づけています。
もちろんAnsible 2.0かそれ以上の大規模対応になるため、2.2での対応完了を目指しているわけではありません。
段階的なゴールとして、

Ansible 2.2
- コントローラ側のコードがPython 3で動く
- ユーティリティモジュールをPython2/3の両対応にし、ユニットテストを充実させる
- ...
Ansible 2.3
- 基本的なモジュールのPython 3化を進める(パッケージマネージャ等)
- Python 2.6+ 対応のモジュールをPython 3に対応させる
- モジュールが"Python 3で動く"とはどういうことか理解して整理する
- ...

というようなものを挙げていますが、基本的には「 がんばる 」と言っているようなレベルですので、中々息の長い取り組みになりそうです。
いずれにせよ、RHEL8がおそらく2020年までには出ますので、それまでにはこの対応が完了している必要があります。
Ansible1系から2系に移行した方はわかるかと思いますが、何だかんだで色々な対応が必要になるかと思いますので、既存資産をどうしていくかなどを考えていく必要がありそうです。

おわりに

こうして、Ansibleのこれまでとこれからを見てみると、構成管理ツールのAnsibleとしてはずいぶん機能成熟を迎えているように思いました。
現在は環境全体を見据えたネットワークからクラスタリングまでをその範囲としており、さらに一段踏み込んだ使い方を検討できるところにきているのではないでしょうか。

巷で言われているように、AnsibleはYAMLとともに非常に使いやすいツールです。
開発コミュニティはより力を増し、少ない機能を強引に使い倒すようなことをしなくても済むようになってきました。
ロードマップを見だすとキリがないかもしれませんが、世の中の賢い人達はこういった世界観を見据えて次の一手を考えているのかと思えば、自分が日々触っている環境に対するアイデアも浮かんでくるかもしれません。