Ansibleの2017年を眺めておこう

はじめに

これまでにこんな記事を書いていました。

• Ansible 2.0リリース！
  • Ansible 2.0がリリースされたときに書いたもの
  • Ansible 2.0リリース記事の日本語訳
• Ansibleのこれまでとこれから
  • Ansible 2.1がリリースされたときに書いたもの
  • これまでの振り返りとロードマップの解説

と、よくよく考えてみたらAnsible 2.2がリリースされたのになんの記事も書いていないことに気づきました。これはまずい。
というわけで(Advent Calendarの穴埋めをかねて)この記事を書き始めました。

Ansible 2.2

それではいつものように CHANGELOG と リリース記事 あたりから Ansible 2.2 というリリースがどのようなものだったのか押さえておきましょう。

Ansible 2.2 brings performance enhancements, expanded container and Windows automation capabilities, and several new modules, including those for networking, cloud provider platforms, and expanded vault support.
(Ansible 2.2はパフォーマンスの向上、コンテナやWindows環境への自動化対応強化に加え、ネットワークやクラウド、Vault関連のモジュールを新たにもたらしました。)

とのことです。
2.0や2.1においても似たようなアナウンスをしていましたが、Ansible 2系としてこうした「コンテナ」「Windows」「ネットワーク」「クラウド」の動きは続いていくのでしょう。

Ansible 2.3

さて、それでは本題の未来の話を見ていきましょう。
こちらの情報ソースは 2.3 Roadmap Document になります。

頭から追っていくと、まず

Target: February/March 2017

というところが目に入ります。リリースのターゲットは2017年の2-3月のようです。
前回のAnsible 2.2が2016年10月でしたから半年でのアップデートになります。

個々のトピック見出しを見てみると、

• General Comments from the Core Team
• Repo Merge
• Metadata
• Documentation
• Windows platform
• Windows modules
• Azure modules
• Networking
• Python3
• Testing and CI
• Amazon resources
• Plugin Loader

と、「 全体対応 」「 Windows対応 」「 Network対応 」「 Python3対応 」「 クラウド対応 」などが大きなものとして見て取れます。そのあたりについてもう少し見てみましょう。

全体対応

General Comments from the Core Teamを見ると、

The 2.3 Ansible Core is just a little different than the past two major releases we've done. In addition to feature work, we're using part of the time for this release to reduce some of our backlog in other areas than pure development.
(Ansible 2.3は直近のメジャー2リリースとは少し違っています。機能追加の作業に加え、バックログ削減のため純粋な開発以外作業も行っています。)

ということが書かれています。
何のことかと言うと、開発チームのマネジメントやリポジトリの運用、Ansible Docsの見直しをするよということのようです。
このあたりもRedHatによる買収で組織力の強化などが効いているのでしょうか。いずれにせよ素晴らしいことですね。

Windows対応

Ansible 2.1で正式サポートとなったWindows環境ですが、Linux環境に比べればまだまだ機能不足な感がありました。
Ansible 2.2でも色々な機能を追加していましたが、次のAnsible 2.3では実行時間の短縮が図れる Pipelining や、権限昇格を行う become 、ケルベロス認証との統合など、Ansibleそのものの機能についての強化作業が見られます。
Windows環境に対する機能としては「win_domain_*」あたりの ドメイン系モジュールの追加 が大きなところかと思われます。

Network対応

記述量としてはあまり多くはないのですが、Ansible 2.0から続くNetwork系機能の重点対応はAnsible 2.3でもまだ続きそうです。
Ansible 2.2では CHANGELOG にあるように、F5 BIG-IPやCisco NXOSのモジュールを多く追加していました。
いつの間にやらAnsible Docsの Network Modules ページがずいぶん長くなっていました。
そのため、

Code stability and tidy up
(コードの安定性強化と整理)

とあるように、急速に成長したNetwork機能のケアは引き続き高い優先度で行われることになりそうです。

Python3対応

僕自身も気にしてはいるところなのですが、Ansibleは現在Python3対応を進めています。
Ubuntuは既に標準同梱がPython3ですし、RHELも リリース実績 を眺めていると来年か再来年にはPython3が標準となるRHEL8がリリースされてきそうです。
というかRedHatの仲間となったAnsibleからすれば、RHEL8が出るまでにはPython3対応を何としても終える必要があるでしょう。

というわけで、

• For 2.3:
  • We want all tests to pass (majority do but there’s 10-20 that still need fixes)
  • If users report bugs on python3, these should be fixed and will prioritize our work on porting other modules.

というように、Ansible 2.3において全てのテストを通過することを目標としています。
ちなみに、

Note: Most of the currently tested ansible features now run. But there’s still a lot of code that’s untested.

とあるように、既に大体は動くようです。

クラウド対応

それでは最後にクラウド対応のところを見てみましょう。
こちらはいわゆる「 AWS対応 」と「 Azure対応 」というものです。パブリッククラウド市場としては最近の 調査 結果によると、AWS1強の見え方は継続しているものの、後続のMicrosoft(Azure)、Google(GCP)、IBM(Blumix¹)を比べるとMicrosoftの成長が著しいことがわかります。
そうした状況を映してか、AnsibleにおいてもAWSとAzureの機能拡張が目を引きます。
AWSだとALBへの対応やDynamic Inventoryスクリプトである ec2.py のリファクタリングなどを行っているようです。

Cloud Modules をぼんやり眺めていると、ベンダ固有のものとしては「 AWS 」「 Azure 」「 VMware 」の数が特に多いように思いますね。あとは「 OpenStack 」「 Ovirt 」のオープン系仮想化技術でしょうか。

ITを戦略的に使おうとする企業は往々にしてハイブリッドクラウドやマルチクラウドの戦略を掲げますが、その下準備としてAnsibleなどを用いた構成管理化が有効であることを考えると、こうしたクラウド対応の流れも継続的に続いていくものと思われます。

Ansible 2.4

もうずいぶん書いてしまいましたが、もうしばらくお付き合いください。
2週間ほど前の2016年12月13日にAnsible 2.4に対する 2.4 Roadmap Document が公開されました。

頭に

This is meant to be a living document, and is by no means FINAL until stated otherwise in the document.
(これは 生きたドキュメント です。そのため、これが最終版ということではありません。)

と前置きされているので、まだまだ策定中ではありますが、現時点での内容を眺めてみましょう。
まず、

Target Delivery: June/July 2017

とあるように、リリースのターゲットとなるのは2017年6-7月のようです。
先ほど確認したように、Ansible 2.3のリリースが2017年2-3月だったので、半年どころか3カ月程度でのリリースとなります。
トピックを確認していくと、

• Ansible-Config
• Inventory Overhaul
• Facts Refreshening
• Cloud Provider Support
• Contributor Quality of Life

とあり、機能リリースというよりはメンテナンスリリースのような印象を受けます。
内容も見てみましょう。

Ansible-Config

New yaml format for config - Extend the ability of the current config system by adding creating an ansible-config command

ということで、YAMLだらけのAnsibleから取り残されていた ansible.cfg についに手が入るようです。
これまでのコンフィグは

log_path=/var/log/ansible.log

のように、ありがちといえばありがちな形式となっていました。
しかし、Ansibleの成長に合わせてモジュールと同じように変数が増え続け、サンプル を参考にしつつも、正直全体として何が設定できるのかよくわからなくなってきていました。
このあたりはちょうど今年の Ansible Advent Calendar 2016 16日目の ansible.cfgの項目をリスト化してみた で整理されていたので、少しやる気が出たところです。

それがAnsible 2.4になると、 ansible-config コマンドが導入されることにより、

• Dump existing config settings
• Update / write a config entry
• Show available options (ini entry, yaml, env var, etc)

が可能になるようです。
PR 的には結構前からオープンされていたようで、マイルストーンが2.2だったり2.3だったりしているので結構長引いているようですね。
ロードマップは2.0以降すべて見ていますが、この話が出たのは初めてなので、そろそろリリースの目途が立ったということなのでしょうか。大いに期待します。

Inventory Overhaul

さて、先ほど ansible.cfg のところで「YAMLだらけのAnsibleから取り残されていた」と表現しましたが、もう1つYAML化から取り残されている輩がいます。
はい、Inventoryです。

Dynamic Inventory では構造的に同等の表現力を持つJSONになので改善されていると言えますが、対する Static Inventory では ini 形式のような、そうでないような独自路線が継続していました。
そこで、Ansible 2.4では Inventory Overhaul(インベントリ見直し) と題して、

Current inventory is overtly complex, non modular and mostly still a legacy from inception. We also want to add a common set of features to most inventory sources but are hampered by the current code base.
(現在のインベントリは明らかに複雑で、モジュール化がされておらず、ほとんどの部分が 最初期からの遺産 となっています。共通的な機能を追加していきたいと思うものの、現在のコードによって妨げられている状況です。)

というモチベーションが表明されています。
Issue としては解決方針として、「なんちゃって(pseudo)Pluginからの脱却」「後方互換性の確保」などが挙げられていますが、内部挙動の話なのでユーザ目線でどういう変化があるのかまだわからないといったところでしょうか。
確かにインベントリまわりは運用上必須で触らなければいけないにもかかわらず、Ansible2系になってもほとんど進化がなかったところなのでついにきたかという感じです。

個人的に Dynamic Inventoryをつくろう！ なんて記事で「Dynamic Inventoryこわくないよ^^」的なことも書いているのですが、これでStatic Inventoryの運用も楽になるなら万々歳ですね。

Contributor Quality of Life

コントリビュータのQoLと題されたこちらのセクション、メッセージは1つです。

More bot improvements!
(もっとbotを強化していこう！)

AnsibleのGitHubを眺めていると ansibot くんが存在します。
どういう動きになっているのかさっぱりですが、Ansibleのような大規模OSS開発においてbotがどう活用されているかチェックして、自分の仕事を減らすアイデアを得られたらと思ったり。

おわりに

また今回もロードマップを眺める記事を書いてしまいました。
とはいえ、2.3も2.4も2017年の前半くらいには大方出てきそうな雰囲気なので、2017年のAnsibleも情報のキャッチアップに大忙しな年になりそうです。
来年には Ansible 3.0 の構想とか出てきたりするのでしょうか...。

本年もお疲れ様でした。また来年もよろしくお願いいたします！

1. 2016年10月26日にIaaSブランドであったSoftLayerをPaaSブランドのBluemixに寄せることが 発表 されました。 ↩