構成管理と自動化のツールAnsibleの最新バージョンと将来の姿
Linuxディストリビューションの最大手であるレッドハット株式会社は、2015年に買収したオートメーションツールAnsibleの最新バージョンを解説する記者発表会を開催した。Ansibleに関する記者発表会は、4月に次いで2回目となる。
記者発表会に続いて、今回来日したAnsible製品ジェネラルマネージャーのJustin Nemmers氏(以下、JN)、アジア・パシフィック地域担当Business Development DirectorのAnirban Mukherjee氏(以下、AM)、レッドハット株式会社プロダクト ソリューション本部クラウド担当ビジネスデベロップメントマネージャーの中村誠氏にインタビューを行った。
まず最初に、日本でのAnsibleコミュニティの状況について教えて下さい。
中村:日本でも、多くのエンジニアにAnsibleへの興味を持っていただいています。今回、日本でも9月1日にMeetupを行ったのですが、100名の参加枠をはるかに上回る申込みをいただきました。実際、100名分の枠は募集から1時間で満員になってしまって、最終的にキャンセル待ちが200名近くまでになってしまいました。
JN:世界的に見ても、日本のコミュニティは盛り上がっているのを感じています。それぐらいにAnsibleが必要とされていると思います。
その場合、参加者はエンドユーザーなのですか? それともシステムインテグレーターなどのベンダーのエンジニアなのでしょうか?
中村:参加されているエンジニアは、まだ大多数がシステムインテグレーターやRed Hatのパートナーの方たちですね。この辺は、日本におけるITエンジニア人口の構造的な特徴が出ているということになると思います。ただMeetupでも、積極的にセッションなどで知見を共有しているパートナーさんもいますので、興味の高さは感じますね。
Ansibleは自動化のツールということですが、実際にはどのような製品と競合になるのですか?
AM:私はアジア・パシフィックを中心にエンタープライズのお客様と接していますが、他社の製品と競合になることはあまり多くありません。そもそもサーバーなどのIT資産の構成管理自体が、まだ自動化されていないというのが実情だと思います。
JN:そうです。「AnsibleがChefやPuppetなどと競合になる」というよりも、それらのソフトウェアと連携しながら共存しているというのが正しい認識だと思います。実際にIT資産の構成の自動化という意味で言えば、一番の競合はユーザー自家製のシェルスクリプトだろうと思います。
AM:様々なお客様の環境を見ても、自動化が行われている例はまだまだ少ないですね。
JN:Ansibleはオープンソースソフトウェアとして、他の様々なソフトウェアと共存できるようになっています。日本ではシステムインテグレーターやISVが運用管理のツールを開発、使用していますが、それらのツールの中にAnsibleを組み込んで使おうとするベンダーが多いというのも特徴だと思います。またAnsibleには、モジュールという形で様々なIT資産の構成を自動化することができます。これはオープンソースソフトウェアの良いところだと思いますが、コミュニティが必要に応じて新しいモジュールを開発して、公開するということが起こっています。これらのモジュールはRed Hatが関知しないものが大半で、対象は様々なネットワーク機器やレガシーなサーバー、OSなど非常に多様です。
また、とても興味深いOracleのデータベースを管理するモジュールの使い方も聞きました。これはハッキングなどの攻撃の結果、サーバー内に勝手にOracleのデータベースが作成されてデータが盗難されるという状況の際に、Ansibleで管理されていないデータベースがあることを発見できるのです。単に運用の自動化だけではなく、セキュリティの面でもAnsibleが使われていることがわかります。
コンテナやPaaSといった今どきのアプリケーションへの対応は進んでいますか?
JN:すでにAnsible Containerというモジュールがありますし、PaaS向けにはAnsible OpenShift Brokerというモジュールがあります。これはAnsibleを使ってコンテナを管理すること、同じくAnsibleからOpenShiftの上でコンテナの管理ができることを意味しています。つまり最新のワークロードに対しても、Ansibleを使ったオーケストレーションが有効であることの証拠なのです。しかし、全てのエンタープライズのアプリケーションがいきなりコンテナ化されるというのはリスクがあります。例えば金融機関が、これまで使っていたアプリケーションを全部コンテナに移行するというのは大きな賭けだと思います。そこで、まずAnsibleを使って開発やテスト環境を自動化して、次に本番環境を自動化するという段階を踏んだ導入であれば、アプリケーション自体は変わりませんから、今のビジネスを支えるアプリケーションには何も影響を与えることはありません。そして開発環境でうまく動くことを充分に確認した上で、移行をすれば良いのです。
コンテナも管理できる、オーケストレーションできるとなれば機能的にはKubernetesと重なると思いますが?
JN:「オーケストレーション」という言葉は様々な意味で使われているので、少し整理が必要だと思います。Kubernetesは例えて言えば、コンテナ用のvCenterだと思えば良いと思います。つまり仮想マシンではなく、コンテナを管理するツールですね。それに比べてAnsibleは、もっと多様なリソースをオーケストレーションできるツールなので、Ansibleのほうが対象は広いのです。
もう一つの違いは、Ansible GalaxyというAnsibleで使えるモジュールを共有するサービスがあります。ここには数え切れないくらいの様々なモジュールがRoleという形で公開、共有されています。自社の使っているレガシーなアプリケーションを自動化したいと思った時に、ここで検索すれば見つかることも多いのです。例えば、ある企業での打ち合わせの際に「うちのアプリケーションはLotus Dominoで動いているのだが、DominoサーバーはAnsibleで自動化可能か?」とCIOから訊かれました。私はDominoのことは初めて知りましたが、検索してみたところ、Ansible-DominoのモジュールがGitHubに公開されていました。CIOの人は目を丸くしていましたよ(笑)。
Galaxyがコミュニティで開発されたモジュールのハブになっているのは良いと思いますが、良いものばかりではなく質の悪いものも存在するのではないですか?
JN:例えば、iPhoneのAppStoreやAndroidのGoogle Playみたいなアプリケーションのストアのように、ですね? しかしAnsibleのモジュールは全て人間が読める内容になっているので、アプリケーションのように使ってみないとわからないということはありません。そのため、質の悪いものは自然と淘汰されるか、必要に応じてコミュニティで改善されていくことになると思います。
ではAnsibleの将来の姿について教えてください。
JN:Ansibleは様々なITリソースを構成管理して、自動化することができます。それをさらに発展させて考えれば、スマートホームの自動化の仕組みとしても応用ができるのです。つまりAnsibleをコミュニケーションの手段と考えれば、アマゾンのAlexaに話しかけて、電灯を点けたり消したりするのと同じように、Alexaに「このサーバーをインストールしてくれと」いうようなことも考えられます。単にサーバーだけではなく、AWSのLambdaのようなサーバーレスのリソースにも対応を予定しています。
またコネクテッドカーのシステム管理にも使えるでしょう。エージェントレスなアーキテクチャーであることと、モジュールを誰でも開発できることの利点が、ここにも表れていると思います。より近い将来で言えば、Red Hatの他の製品との連携がさらに強化されるということですね。すでにRed Hat Enterprise Linuxの最新バージョンでは、Ansibleによる構成管理がデフォルトになっています。またサービスであるRed Hat Insightについても、単にポータルとして不具合などを告知するだけではなく、その不具合を解決するための方法をAnsibleのPlaybookの形で提案するような統合が進んでいます。つまり「このバージョンのOSとこのソフトウェアでは不具合があるのでUpgradeしてください」というだけではなく、それを実行するためのスクリプトをAnsibleのPlaybookの形で提供できるのです。単に情報を提供するだけではなく、その解決方法を提供してすぐに実行できるわけです。
今回の発表はAnsibleの製品ラインの拡張が主な内容であったが、Ansibleが持つ可能性についてRed Hatだけではなく、コミュニティも大きな期待をかけていることが感じられた。日本でも書籍が多く出版されており、今までにない盛り上がりをみせているという。まだRed Hatに買収されてから2年という短い期間のうちに、順調にRed Hat製品ともインテグレーションが行われているほか、他社のネットワーク製品用のモジュールのRed Hatによるサポートも始まっており、今後の利用拡大が期待される。
なお、今回発表されたAnsibleのGUIコンソールであるAnsible Towerのコミュニティ版、AWX Projectについてその名前の由来を聞いたところ、「Ansibleは昔Ansible Worksという社名だったのです。その頃からのソースコードには、社名の略称である“AWX”がまだ多く残っているのです。ソースコードの中を一括変換で他の単語に変更することもできましたが、何が起こるかはわかりません(笑)。そこで、今回コミュニティ版のTowerを公開するに際して、当時の名前をそのまま使おうということになりました。ということで、AWXはAnsible Worksの略です」ということだ。
連載バックナンバー
Think ITメルマガ会員登録受付中
全文検索エンジンによるおすすめ記事
- Ansibleの機能を拡張するAnsible Tower
- Red Hat Summitで脚光を浴びたAnsibleの担当VPが語るオートメーションツールに必要な要件とは?
- 構成管理ツールとしてAnsibleを選ぶべき理由
- 構成管理ツールのAnsibleが目指す「Infrastructure as YAML」とは?
- Red Hat、サーバ設定自動化フレームワーク「Ansible Tower 3.1」リリース
- Ansible Towerのクラウド連携機能による効率化を目指す
- Ansible Towerによる権限の管理
- 「Ansible Galaxy」のオープンソース化、仮想マシンイメージ「Container-VM Image」の正式リリース、ほか
- SIの労働生産性を高めるIaCとは?ITエンジニアのためのコミュニティ「IaC活用研究会」キックオフイベントレポート
- Red Hat Summit 2024、Red HatのAI戦略を読み解く