まだシステムがシンプルでコンピューティングリソースが貴重だった頃は、機器の設計、調達に数カ月単位の期間をかけ、エンジニアが手作業でOSをインストールしたり、各種設定を投入していても十分間に合っていました。

しかしながら今は状況が一変しています。リソースが安価となり日々変化するビジネス上の要件に合わせて新たなサービスを作り、試し、うまくいかなければ壊してまた新たな仕組みを作り……そのサイクルを素早く回すには、人手で作業していては間に合いません。並行して、システムそのものがビジネスを支えるべく大規模化し、クラウド環境も含め複雑化しています。いくら目検やダブルチェックで確認していても、ヒューマンエラーをゼロにすることは困難です。人手不足を背景に、とても日々の運用に手が回らない、という声も聞こえてきます。

そこでこの数年、DevOpsとともに注目を集めているのが、「Infrastructure as Code（IaC）」です。インフラの構築・設定作業もコード化し、いわばインフラの構成そのものをソフトウェアとして扱って自動化しよう、というアプローチです。数十、数百ものリソースに適切な設定を施してデプロイするのに必要な手間も、時間も短縮でき、迅速なリリースを実現するとして、様々な企業で採用が広がっています。

このIaCを実現する方法はいくつかありますが、中でもエンジニアからの支持が高いツールが、オープンソースのIT自動化ツール「Ansible」です。「Playbook」と呼ばれる、一種の「プログラムが読み込める構築手順書」にしたがって、サーバやOS、アプリケーションやネットワーク機器、さらにはクラウドの構成、デプロイ作業を自動的に行います。レッドハットからはより複数のチームにまたがって効率的に自動化を推進することができる、「Ansible Tower」も提供されています。

今回は、大手システムインテグレーターで開発業務に携わるかたわら、Qiitaやその他の媒体でIaCやDevOps関連の記事を執筆し、よりよいサービスを支えるインフラの効率的な構築に取り組んでいる中山貴尋さんをお招きし、レッドハットの中島倫明さん（テクニカルセールス本部ソリューションアーキテクト）に、Ansible Towerの印象を尋ねてみました。

・作業の効率化を考えると避けては通れない「自動化」
・エンジニア個人から組織全体に自動化を広げる際の課題とは？
・インフラ構築・設定の「自動化」から「サービス化」へ
・Ansible Towerならではの機能、どう設定するの？

プロフィール

中山 貴尋（なかやま たかひろ）

@t_nakayama0714

日鉄ソリューションズ インフラエンジニア

三重県伊勢市出身。大学時代は関西で数学を学んだ後に、SIerへの就職を機に上京。インフラエンジニアとして主にOSSを組み合わせて仕事を行う傍ら、趣味としてQiitaなどでの情報発信を行っている。共著で「DevOps導入指南」を執筆。これまで書いたQiita記事の中では「不思議の国のSE用語」がおすすめ。

中島 倫明（なかじま ともあき）

テクニカルセールス本部クラウドソリューションアーキテクト部

ソリューションアーキテクト オートメーション&マネジメント・エキスパート

国内SIerを経て、現在はレッドハットへ勤務。戦略から実装まで、幅広く企業システムの自動化やクラウド化の促進を支援。その傍らで大学や研究機関での講師を勤め、クラウド時代のIT人材の育成に尽力する。OpenStackやAnsibleなどのユーザー会のメンバーとして、コミュニティの運営にも参加している。共著で「インフラCI実践ガイド」「絵で見てわかるクラウドインフラとAPIの仕組み」他数冊を執筆。

作業の効率化を考えると避けては通れない「自動化」

──「Ansible」というツールに興味を抱いたきっかけは何でしたか？

中山さん（以下：中山）：システム開発に携わる中で、作業を効率化していきたいのはいつの時代も思うことです。効率化の最たる例として、自動化もその一環で取り入れたいと思っていました。

自動化自体は昔からできたことですが、実現にはスキルが必要です。できる人はできるけれど、できない人を含めてできるようにすることは一朝一夕にとはいきません。そこが、システムインテグレータのように多くの人が共同でシステム開発に携わる場にはなかなかマッチしませんでした。そこに、2015年か16年ごろだったと思いますが、Ansibleのように簡単な書き方で作業を自動化できるツールが話題になり始め、成熟していく中で私自身も興味を持ちました。

──IaCのような世界を実現するためのツールは、他にもあったように思いますが。

中山：やはり、エージェントレスというのが大きかったですね。当時、比較対象としてよく挙がっていたのが「Chef」でした。今はそうでもないのですが、当時のChefは基本的に、受け手となるエージェントが必要だったのに対し、AnsibleにはSSHでつなぐことさえできればいい手軽さがありましたし、 YAMLで簡単に設定を記述できるのも魅力的でした。

──それで、Ansibleを導入して使い始めたんですね。

中山：はい。ただ、自分一人、あるいは対面で使い方を教えられるくらいの特定少数で使う分にはいいんですが、一定以上の規模で使いたい、作ったものを同じように横展開したいとなったときに、ちょっと難しさを感じていました。「簡単だから各々の環境でAnsibleをセットアップしてください」と言うのは易しいですが、実際のフォローを踏まえるとなかなか難しいところがありまして……。

──結局どうしていたのですか？

中山：その時はまだAnsible Towerがありませんでしたから、Jenkinsをかぶせて使うようにしてました。できないことはないけれど、ちょっと無理くり感がありましたね、そもそもツールとしての性質が違うので。

Ansibleに興味を持ったきっかけを語る中山さん

Ansibleをこれから始めたいという方に
マンガでわかる Ansible Automation

エンジニア個人から組織全体に自動化を広げる際の課題とは？

中島さん（以下：中島）：確かに、自動化の作り込む作業はエンジニアにとって楽しいですし、皆さんも頑張って作るんですよ。でも、自動化で本当に難しいのは運用フェーズに入ってからです。

1つ目の課題は、いかに安全に自動化の仕組みを動かしていくかということです。今までならば、エンジニアが入力したコマンドの影響範囲はログイン先のホストに限定されていましたが、自動化すると、たった一行で膨大な数のホストに対していろんなコマンドが流れていくので、その安全性をちゃんと管理しないといけません。

それに、中山さんがおっしゃった、組織の中に広げていく過程での課題もあります。自動化の仕組みを複製していろんな人に渡していくと便利でればあるほどどんどん組織の中でコードが分散していきます。一箇所のバグに気づいたり、改善しようとしても、分散した先すべてに反映しなければならないのですが、それをどう管理するかも難問でした。

中山：そうですね、そのあたりの課題はまさにおっしゃる通りです。

中島：なので、自動化を単なる「ツール」ではなく、「プラットフォーム」として使えるような仕組みが必要だ、と考えて生み出されたのがAnsible Towerです。

今のところオープンソースのツール、具体的には「Jenkins」などを駆使して管理される方が多いと思いますが、Jenkinsは基本はCI/CDツールであり、ITインフラの自動化を管理するコントローラではありません。そのためAnsibleのジョブを制御するのにいろいろ作り込みをしなければならず、結局、自動化の仕組みを作る部分よりJenkinsの管理にコストがかかってしまうといった課題がありました。これに対しAnsible Towerは、元々Playbookを動かすことに最適化されており、組織として自動化に取り組み、効率的に動かすための環境に必要な機能を提供しています。

中山：Jenkinsって、オープンソースのプラグインが豊富なこともあり、確かにやりたいことは一通り何でもできるんですが、きれいな形でやるのが難しいんです。必要だからといっていろいろ付け加えるうちに、他のチームに伝えて同じように使ってもらうことが難しくなり、自動化利用のハードルが上がってしまいます。そこが悩みどころでした。

もう1つ、これは大手企業での情報漏洩事件を転機に高まってきたニーズなのですが、会社として「誰がどんな操作をしたか」をとても気にするようになりました。現場に不信感があるわけではないのですが、セキュリティの方向性として、誰がどんな操作をできるのかという権限管理と、何かあったときに調査できるためのロギングが非常に重視されるようになっています。認証と認可、ロギング、監査、こういったこともJenkinsでやろうと思えばできるんですが、やはり非常に不格好になるんですよ。どんどん仕組みが重くなり、管理することが難しくなってしまうという課題感がありました。

さっき中島さんがおっしゃったとおり、数行のコマンドならばともかく、数百行ものコマンドを一気に実行すると、その人が影響を及ぼせる範囲が非常に広がるんですよね。便利だからとなしくずし的に自動化が広げていく中、昔と同じような考え方で作業し、ふとしたタイミングで間違えてしまうと、たった一度で甚大なダメージを負うリスクがありますよね。

Ansible Towerは、「プラットフォーム」として使えるような仕組みが必要という考えから生み出された

中島：そうですね。Ansible Towerはそこに対して、「このユーザーはこれを実行してもいい」「このユーザーには編集権限だけ」といった具合に、人やチームに対してロールベースのアクセス権限管理を行えるようになっています。

もう1つ、それ以前の話として、自動化すると至る所で「秘密情報」を受け渡すシーンが出てきます。サーバにログインするにも、その先でデータベースを操作するにもクレデンシャルが必要ですし、新規ユーザーを作成したら同時にパスワードを設定します。こんな風にインフラの作業にはいろいろな秘密情報があるのですが、それをきちんと隠蔽した状態で受け渡すのってけっこう難しいですよね。ログにパスワードなどの情報がそのまま出力されてもいけません。Ansible Towerを使うと、こうした秘密情報をきちんと隠蔽しながらいろんな作業を行え、かつ監査も実施できます。大手金融機関の中には、この部分を評価して大規模にTower導入したところもあります。

自動化2.0の考え方やAnsibleの活用事例を知りたいという方に
Ansible Automates Tokyo 2019セミナースライド資料まとめ

インフラ構築・設定の「自動化」から「サービス化」へ

──Ansible Towerって、この先、どんな風に進化していくんですか？

中島：レッドハットでは「自動化 2.0」というキーワードを使って、自動化というものをサービスに置き換えていこうと提案しています。従来の自動化って、誰かに依頼されて行う作業をPlaybookで置き換えるという発想でした。それを、「このボタンを押せばそれだけで、仮想マシンが起動するとか、パッケージをインストールするといった作業ができるようになっています。だからあなたの好きなタイミングで押してください」というサービスに置き換えていこう、という考え方です。先ほど説明した権限管理や証跡管理も、結局はサービスを成り立たせるために必要な機能という位置付けです。

Ansible Towerを使うことで、社内のいろんな業務をこういう「ボタン」、つまりAPIに置き換えていって、最終的にはそれらボタンを連結させることで、多くの業務が成り立つようにしていきたいと考えています。インフラは作業をやるものではなく、サービスを提供するものですから。

中山：そうですね。色々な技術を通して、複雑化するインフラの様々な作業手順を隠蔽できるようになりました。さらに進んで、アプリケーション側が欲しいと思ったタイミングで「ボタンをクリックするだけでOK」という状態になれば、インフラの用意はエンジニアの仕事というよりも、「セルフサービス」になっていくのではないでしょうか。「欲しいと思った時が納期」となってアプリケーション側にとってもいいですし、インフラ側の仕事もどんどん軽くなる…そこに至るまでまだ溝はありますが、望ましい方向性だと思います。

中島：この先のインフラエンジニアの役割も、今までの「管理者、作業者」ではなく、インフラという機能やサービスを「開発者」になっていくのかもしれませんね。

Ansible Towerのこれからの進化にも期待が高まる

中山：ある日突然「インフラサービスの開発者になれ」と言われると、「えっ」と思うかもしれませんが、一つ一つの段階を見ると何も不思議なことはやっていないはずなんです。あるとき、自分やチームのために自動化を志してAnsibleを入れて、次にAnsible Towerを入れて…という感じで、一つ一つステップ踏んでいこうと考えることに何も難しいことはありません。自分たちの仕事をよりよくしていこうとする施策として、たまたまこういうスタイルがあっただけの話だと思います。

この5年くらい、Ansibleのほかにもコンテナやサーバレスなど次々に色々な技術が出てきています。技術が成熟に向かう際には、混迷を極める時期もありますが、その技術やトレンドの関心事とともに、常に「この技術で何を解決し、何を目指すのか」を大事にしていたいと思います。

Ansible Towerをより詳しく知りたい方に
ウェビナー：はじめてのAnsible Tower

Ansible Towerならではの機能、どう設定するの？

──では、実際にAnsible Towerを触ってみての感触はどうですか？

中山：オープンソース版の「AWX」は触ったことがあったのですが、Ansible Towerは初めてでした。提供いただいたラボ環境を使って試してみましたが、Ansibleの概念が分かってさえいれば、それに特化したユーザーインターフェイスになっているので、違和感なく使えて、「こういうことをやりたいな」っていうのに合わせて画面を探していくと見つかりますね。

中島：オススメしたいのが「ワークフロー」という機能です。これまで、あるPlaybookの実行結果を次のPlaybookに渡そうとするとちょっと大変で、どこか別のファイルに形式を指定して書き込んだりしていたのですが、Ansible Towerではグローバル変数のようなイメージで、Playbookの中でset_statsで変数を設定すると、Playbookをまたがって変数を保持できるようになります。

中山：今、まさにその部分をJenkinsとの組み合わせでやっているんですが、ちょっと面倒な部分でした。これが使えれば簡単になりますね。もう1つ課題と感じているのが、ジョブそのものの管理なんですが…。

中島：Ansible Tower Moduleというものがあって、これを使うとAnsible Tower上のジョブもYAMLで管理できるようになります。

中山：そこまでできるようになると、管理者視点の構成管理と、利用者が自由に使えるという利点のバランスをどう取るかも課題になりそうですね。

中島：今の最新バージョンがAnsible 2.9とAnsible Tower 3.6なんですが、ここでは大きな追加要素として「コレクション」という新しい概念が入ってきました。ロールをコレクションという意味のある単位にまとめて、より共有を促進するための機能です。また、Webhookを受けられるようになったので、例えばGitHubでプッシュすると特定のジョブのテンプレートが動いて、Jenkinsを使わなくても簡易的なCIを回せるようになりました。ただ、AnsibleはCIツールではないので、テストのマトリックスを組んでいろんなパターンを一気に流す場合にはやはりCIツールとの組み合わせが有効です。

中島さんからレクチャーを受ける

──Ansible Towerで権限管理はどのように設定するんでしょうか？

中島：Ansible Towerは様々な管理オブジェクトを持っています。代表的なものが、自動化の対象を管理する「インベントリ」や対象へのログインに利用する「認証情報」、Playbookを管理する「プロジェクト」です。これらのオブジェクトを組み合わせて「ジョブテンプレート」を作っていきます。それが「ボタン」になり、このボタンを押せば自動化が動き出すわけです。この時、各オブジェクトには権限を割り当てることができます。例えば「ユーザーAはこのオブジェクトを使うだけ」「Bは編集も可能」「Cは監査専用」という具合に、どんなロールを持つかを割り当てていきます。

中島：監査に関して評判がいいのは、特別な設定をせずに実行結果が全て記録されることです。裏側で動いているモジュールの戻り値も全部取ってきるので便利です。

中山：これはいいですね。タスクごとに、処理がいつ実行されたか表示されるのもありがたいですね。どこで詰まっているかがわかるのは、地味に便利です。

中島：サービス化については、このように、画面上でいろんなオブジェクトを組み合わせて、ボタンを作っていく形です。GUIのエディターを使って「まずこのジョブテンプレートを実行して成功したら次にこれ、失敗の場合はあれ」という風に、複数のボタンをまとめた、より大きなボタンを作ることができます。

また、何らかのSCM（ソースコード管理システム）と連携することでPlaybookを一元的に管理し、必要に応じてAnsible Towerを介してPlaybookを取ってきて実行する、ということもできます。

中山：いちエンジニアとして思うのは、こういうツールが整ってきたことで、様々なアイデアを試しやすくなりましたね。「いろいろ試行錯誤したい」というタイプのエンジニアには、インターネットで情報が手に入りやすくなったことを含めて、いい時代になったなと思います。

編集後記

昔のインフラエンジニアの仕事というのは、各種コマンドやConfigファイルに通じること、という印象でした。けれどお二人の話の端々から、今まさに、その役割は変化しつつあるのだなと痛感。Ansible/Ansible Towerのようなツールに単純だけれど面倒な部分を極力任せて、グランドデザインの設計だったり、あるいはコンテナ、さらにその次のトレンドにアンテナを張ったりと、好奇心を生かせる仕事に時間を費やせるようになるのではないかと、期待感を抱きました。
一方で、あまりにインフラが抽象化、隠蔽化されてしまうと、いざトラブルが起きた時に適切に切り分けて対処ができるかな、という不安もあります。やっぱり、身につけておかなければいけない知識にキリはないのかもしれません。

取材／文：高橋睦美
撮影：伊藤圭