構成管理ツールのAnsibleが目指す「Infrastructure as YAML」とは？

レッドハット株式会社は、構成管理と自動化のツールであるAnsibleに関するブリーフィングを行った。これはレッドハット本社のAnsible担当のTechnical Marketing EngineerであるSean Cavanaugh氏の来日に伴って開催されたものだ。2度目の来日であるというCavanaugh氏に、インタビューをお願いした。忙しい時間を縫ってのメディア対応ということになる。

Ansibleは2015年にRed Hatが買収した構成管理ツールで、現在は全てオープンソースソフトウェアとして公開されている。Ansibleについては、レッドハットのエバンジェリストである平初氏が書いた記事を参考にしていただきたい。

参考：構成管理ツールとしてAnsibleを選ぶべき理由

自己紹介をお願いします。

私はRed HatでAnsibleのTechnical Marketing Engineerとして、セールス活動の支援をやっています。Ansibleの中でも特にネットワークデバイスの自動化、構成管理を行うAnsible Networkを担当しています。過去にはCumulus Networks、Cisco Systemsなどでネットワークエンジニアをしていました。私のバックグラウンドが主にネットワークエンジニアだったということが、現在Ansible Networkを担当している理由のひとつですね。さらにその前は、米国陸軍でITエンジニアをやっていました。兵士ではなく、彼らを支えるNerd（オタク）という役割でしたけども（笑）。

インタビューに応えてくれたSean Cavanaugh氏

今回は、「Ansibleを使ったネットワークの自動化」というトピックについてご説明したいと思います。ネットワークの自動化は、Red Hatが推進するネットワーク管理の方向です。それを私は「Infrastructure as Code」ではなく「Infrastructure as YAML」と呼んでいます。

「Code」ではなく「YAML」という理由は？

一番の理由は、「コード」だとネットワークエンジニアにとって難しいという感覚を持たれることを避けたかったから、ですね。コードだと、プログラム言語を使ってプログラミングをしなければいけないような感じがしませんか？　でもそれは違うのです。インフラエンジニアが普段使い慣れているYAMLを使って構成を記述するだけなのに、あまり難しいことであると思って欲しくないとということです。

私はCiscoで働いていたので、CCNAなどのシステム管理者のことはよくわかっていますが、ネットワーク管理者にとって各デバイスのコマンドラインを叩いて管理をするというのは、いわゆる職人芸に近いものがあります。実際には、単にサイロ化されたものを個別のスキルで対応するということに他なりません。しかし近代化は進んでおり、ネットワークの管理も自動化することが求められているわけです。そのために共通の言語でネットワークインフラストラクチャーを管理、自動化できるツールが求められていたのです。実際に2016年に行われたNetDevOpsという調査では、AnsibleはGitに並んで使っている、もしくは関心のあるツールとして挙げられています。ChefやPuppetなどと比べても、倍以上の数ですでに本番環境で使われていることがわかっています。

Gitに次いでAnsibleが認識されているということには、大きな意味があると思います。NetDevOpsというのはネットワークから開発そして運用までを連携して行うという新しいコンセプトですが、単にサーバーなどのインフラストラクチャーだけではなく、ネットワークデバイスなども含めて開発と運用管理を繋げていこうとする大きな流れが起こっているということですね。

ネットワークの管理はインフラストラクチャーの中でもかなり専門性が高く、職人化してしまうというのは納得できます。AnsibleがYAMLを使うことでインフラストラクチャーエンジニアにとってもとっつきやすくすることは理解できました。その効果を具体的に教えてください。

私がネットワークエンジニアなどに語っていることは、常に「時間の短縮が可能である」ということです。数ある効果の中でも、それが一番大きいのではないかと思います。例えば英国陸軍の事例では、パッチを適用するだけで従来は数週間という時間が必要だったものを数時間、数十分に短縮できました。これまで手作業で行っていた作業を自動化することで、時間が短縮できると同時に、ミスも減らすことができます。サーバーやスイッチなどに一々ログインして手作業でコマンドを入力する、コマンドもコピーアンドペーストして実行するなどと言った作業から解放されることが、直接的には最も大きな効果だと思います。

事例にもありますが、アメリカの医療機関向けの情報サービスを行っているSurescriptsという企業は、Ansibleを使ってRHELサーバー、Windowsサーバー、F5のロードバランサーなどを管理しています。特に障害発生時には、データセンター間のトラフィックを振り分けるために、F5のロードバランサーをマニュアルで操作する必要がありました。しかしそれを全てAnsibleで自動化することで、数時間というダウンタイムを数分というレベルにまで短縮することができました。

F5は日本でも多くのエンタープライズで利用されているロードバランサーですが、F5との連携も進んでいるということですか？

そうです。5月に行われるRed Hat Summitでは、F5だけではなく他社のネットワーク製品との連携のセッションが多く行われるので、そこでより詳しい解説を聞いてもらえたらと思います。

最後にAnsibleの製品構成について教えてください。

Ansibleの製品構成。左はOSS版、右が商用サポート版だ

Ansibleには「Engine」と呼ばれる基本的な機能を備えたソフトウェアと、「Tower」と呼ばれるGUIを持つソフトウェアの2つがあります。それぞれオープンソースソフトウェアであるコミュニティバージョンと、レッドハットがサポートを提供するバージョンがあります。これらの関係は、RHEL（Red Hat Enterprise Linux）とFedoraの関係を理解しているとわかりやすいと思います。コミュニティバージョンが、AnsibleとAWX、サポートバージョンがEngineとTowerということですね。

2016年の5月にAnsible 2.1が出て、今年の3月に出荷したAnsible 2.5まで5回のリリースを行っています。その間、対象となるデバイス、プラットフォームとモジュールは拡大しています。特にモジュールは、2.1の28から2.5では572にまで増えました。開発のサイクルは3ヶ月ごとと非常に速いので、次の2.6についても少しづつ情報が出てきています。顧客からは要望の多かった、ネットワークのトポロジーマップをTowerのGUIから見る機能については、すでにTech Previewという形で公開されています。

Ansibleのコミュニティは非常に活発で、ミートアップなどは世界のどこかで毎週開催され、多くのエンジニアが情報交換をしているという。日本でも「レッドハット主催のもの以外に、パートナーが行っているものもあるので、正確には把握できていない」とレッドハット株式会社の担当者がコメントするように「Infrastructure as Code」ではなく「Infrastructure as YAML」は確実に浸透しているのかもしれない。Red Hat Summit 2018でのAnsible関連のセッションから、より詳しい情報をお届けする予定だ。