Towerでチームでのインフラ自動化を!現役SEが見るインフラ構築の今TweetShareHatenaPocketRSSまだシステムがシンプルでコンピューティングリソースが貴重だった頃は、機器の設計、調達に数カ月単位の期間をかけ、エンジニアが手作業でOSをインストールしたり、各種設定を投入していても十分間に合っていました。今は状況が一変しています。リソースが安価となり日々変化するビジネス上の要件に合わせて新たなサービスを作り、試し、うまくいかなければ壊してまた新たな仕組みを作り......そのサイクルを素早く回すには、人手で作業していては間に合いません。並行して、システムそのものがビジネスを支えるべく大規模化し、クラウド環境も含め複雑化しています。いくら目検やダブルチェックで確認していても、ヒューマンエラーをゼロにすることは困難です。人手不足を背景に、とても日々の運用に手が回らない、という声も聞こえてきます。Code(IaC)」です。インフラの構築・設定作業もコード化し、いわばインフラの構成そのものをソフトウェアとして扱って自動化しよう、というアプローチです。数十、数百ものリソースに適切な設定を施してデプロイするのに必要な手間も、時間も短縮でき、迅速なリリースを実現するとして、様々な企業で採用が広がっています。このIaCを実現する方法はいくつかありますが、中でもエンジニアからの支持が高いツールが、オープンソースのIT自動化ツール「Ansible」です。「Playbook」と呼ばれる、一種の「プログラムが読み込める構築手順書」にしたがって、サーバやOS、アプリケーションやネットワーク機器、さらにはクラウドの構成、デプロイ作業を自動的に行います。Tower」も提供されています。Towerの印象を尋ねてみました。関西で数学を学んだ後に、SIerへの就職を機に上京。インフラエンジニアとして主にOSSを組み合わせて仕事を行う傍ら、趣味としてQiitaなどでの情報発信を行っている。共著で「DevOps導入指南」を執筆。これまで書いたQiita記事の中では「不思議の国のSE用語」がおすすめ。オートメーション&マネジメント・エキスパート国内SIerを経て、現在はレッドハットへ勤務。戦略から実装まで、幅広く企業システムの自動化やクラウド化の促進を支援。その傍らで大学や研究機関での講師を勤め、クラウド時代のIT人材の育成に尽力する。OpenStackやAnsibleなどのユーザー会のメンバーとして、コミュニティの運営にも参加している。共著で「インフラCI実践ガイド」「絵で見てわかるクラウドインフラとAPIの仕組み」他数冊を執筆。──「Ansible」というツールに興味を抱いたきっかけは何でしたか?中山さん(以下:中山):システム開発に携わる中で、作業を効率化していきたいのはいつの時代も思うことです。効率化の最たる例として、自動化もその一環で取り入れたいと思っていました。自動化自体は昔からできたことですが、実現にはスキルが必要です。できる人はできるけれど、できない人を含めてできるようにすることは一朝一夕にとはいきません。そこが、システムインテグレータのように多くの人が共同でシステム開発に携わる場にはなかなかマッチしませんでした。そこに、2015年か16年ごろだったと思いますが、Ansibleのように簡単な書き方で作業を自動化できるツールが話題になり始め、成熟していく中で私自身も興味を持ちました。──IaCのような世界を実現するためのツールは、他にもあったように思いますが。中山:やはり、エージェントレスというのが大きかったですね。当時、比較対象としてよく挙がっていたのが「Chef」でした。YAMLで簡単に設定を記述できるのも魅力的でした。──それで、Ansibleを導入して使い始めたんですね。自分一人、あるいは対面で使い方を教えられるくらいの特定少数で使う分にはいいんですが、一定以上の規模で使いたい、作ったものを同じように横展開したいとなったときに、ちょっと難しさを感じていました。「簡単だから各々の環境でAnsibleをセットアップしてください」と言うのは易しいですが、実際のフォローを踏まえるとなかなか難しいところがありまして......。Towerがありませんでしたから、Jenkinsをかぶせて使うようにしてました。できないことはないけれど、ちょっと無理くり感がありましたね、そもそもツールとしての性質が違うので。Automationエンジニア個人から組織全体に自動化を広げる際の課題とは?中島さん(以下:中島):確かに、自動化の作り込む作業はエンジニアにとって楽しいですし、皆さんも頑張って作るんですよ。自動化で本当に難しいのは運用フェーズに入ってからです。1つ目の課題は、いかに安全に自動化の仕組みを動かしていくかということです。今までならば、エンジニアが入力したコマンドの影響範囲はログイン先のホストに限定されていましたが、自動化すると、たった一行で膨大な数のホストに対していろんなコマンドが流れていくので、その安全性をちゃんと管理しないといけません。それに、中山さんがおっしゃった、組織の中に広げていく過程での課題もあります。自動化の仕組みを複製していろんな人に渡していくと便利でればあるほどどんどん組織の中でコードが分散していきます。一箇所のバグに気づいたり、改善しようとしても、分散した先すべてに反映しなければならないのですが、それをどう管理するかも難問でした。中山:そうですね、そのあたりの課題はまさにおっしゃる通りです。今のところオープンソースのツール、具体的には「Jenkins」などを駆使して管理される方が多いと思いますが、Jenkinsは基本はCI/CDツールであり、ITインフラの自動化を管理するコントローラではありません。そのためAnsibleのジョブを制御するのにいろいろ作り込みをしなければならず、結局、自動化の仕組みを作る部分よりJenkinsの管理にコストがかかってしまうといった課題がありました。Towerは、元々Playbookを動かすことに最適化されており、組織として自動化に取り組み、効率的に動かすための環境に必要な機能を提供しています。中山:Jenkinsって、オープンソースのプラグインが豊富なこともあり、確かにやりたいことは一通り何でもできるんですが、きれいな形でやるのが難しいんです。必要だからといっていろいろ付け加えるうちに、他のチームに伝えて同じように使ってもらうことが難しくなり、自動化利用のハードルが上がってしまいます。そこが悩みどころでした。1つ、これは大手企業での情報漏洩事件を転機に高まってきたニーズなのですが、会社として「誰がどんな操作をしたか」をとても気にするようになりました。現場に不信感があるわけではないのですが、セキュリティの方向性として、誰がどんな操作をできるのかという権限管理と、何かあったときに調査できるためのロギングが非常に重視されるようになっています。認証と認可、ロギング、監査、こういったこともJenkinsでやろうと思えばできるんですが、やはり非常に不格好になるんですよ。仕組みが重くなり、管理することが難しくなってしまうという課題感がありました。さっき中島さんがおっしゃったとおり、数行のコマンドならばともかく、数百行ものコマンドを一気に実行すると、その人が影響を及ぼせる範囲が非常に広がるんですよね。便利だからとなしくずし的に自動化が広げていく中、昔と同じような考え方で作業し、ふとしたタイミングで間違えてしまうと、たった一度で甚大なダメージを負うリスクがありますよね。Towerは、「プラットフォーム」として使えるような仕組みが必要という考えから生み出された中島:そうですね。Towerはそこに対して、「このユーザーはこれを実行してもいい」「このユーザーには編集権限だけ」といった具合に、人やチームに対してロールベースのアクセス権限管理を行えるようになっています。1つ、それ以前の話として、自動化すると至る所で「秘密情報」を受け渡すシーンが出てきます。サーバにログインするにも、その先でデータベースを操作するにもクレデンシャルが必要ですし、新規ユーザーを作成したら同時にパスワードを設定します。こんな風にインフラの作業にはいろいろな秘密情報があるのですが、それをきちんと隠蔽した状態で受け渡すのってけっこう難しいですよね。ログにパスワードなどの情報がそのまま出力されてもいけません。Towerを使うと、こうした秘密情報をきちんと隠蔽しながらいろんな作業を行え、かつ監査も実施できます。大手金融機関の中には、この部分を評価して大規模にTower導入したところもあります。2.0」というキーワードを使って、自動化というものをサービスに置き換えていこうと提案しています。従来の自動化って、誰かに依頼されて行う作業をPlaybookで置き換えるという発想でした。それを、「このボタンを押せばそれだけで、仮想マシンが起動するとか、パッケージをインストールするといった作業ができるようになっています。あなたの好きなタイミングで押してください」というサービスに置き換えていこう、という考え方です。先ほど説明した権限管理や証跡管理も、結局はサービスを成り立たせるために必要な機能という位置付けです。Towerを使うことで、社内のいろんな業務をこういう「ボタン」、つまりAPIに置き換えていって、最終的にはそれらボタンを連結させることで、多くの業務が成り立つようにしていきたいと考えています。インフラは作業をやるものではなく、サービスを提供するものですから。色々な技術を通して、複雑化するインフラの様々な作業手順を隠蔽できるようになりました。進んで、アプリケーション側が欲しいと思ったタイミングで「ボタンをクリックするだけでOK」という状態になれば、インフラの用意はエンジニアの仕事というよりも、「セルフサービス」になっていくのではないでしょうか。「欲しいと思った時が納期」となってアプリケーション側にとってもいいですし、インフラ側の仕事もどんどん軽くなる...そこに至るまでまだ溝はありますが、望ましい方向性だと思います。なく、インフラという機能やサービスを「開発者」になっていくのかもしれませんね。Towerのこれからの進化にも期待が高まる中山:ある日突然「インフラサービスの開発者になれ」と言われると、「えっ」と思うかもしれませんが、一つ一つの段階を見ると何も不思議なことはやっていないはずなんです。Towerを入れて...という感じで、一つ一つステップ踏んでいこうと考えることに何も難しいことはありません。自分たちの仕事をよりよくしていこうとする施策として、たまたまこういうスタイルがあっただけの話だと思います。この5年くらい、Ansibleのほかにもコンテナやサーバレスなど次々に色々な技術が出てきています。技術が成熟に向かう際には、混迷を極める時期もありますが、その技術やトレンドの関心事とともに、常に「この技術で何を解決し、何を目指すのか」を大事にしていたいと思います。Towerは初めてでした。提供いただいたラボ環境を使って試してみましたが、Ansibleの概念が分かってさえいれば、それに特化したユーザーインターフェイスになっているので、違和感なく使えて、「こういうことをやりたいな」っていうのに合わせて画面を探していくと見つかりますね。中島:オススメしたいのが「ワークフロー」という機能です。Towerではグローバル変数のようなイメージで、Playbookの中でset_statsで変数を設定すると、Playbookをまたがって変数を保持できるようになります。中山:今、まさにその部分をJenkinsとの組み合わせでやっているんですが、ちょっと面倒な部分でした。これが使えれば簡単になりますね。1つ課題と感じているのが、ジョブそのものの管理なんですが...。Tower上のジョブもYAMLで管理できるようになります。中山:そこまでできるようになると、管理者視点の構成管理と、利用者が自由に使えるという利点のバランスをどう取るかも課題になりそうですね。3.6なんですが、ここでは大きな追加要素として「コレクション」という新しい概念が入ってきました。ロールをコレクションという意味のある単位にまとめて、より共有を促進するための機能です。Webhookを受けられるようになったので、例えばGitHubでプッシュすると特定のジョブのテンプレートが動いて、Jenkinsを使わなくても簡易的なCIを回せるようになりました。AnsibleはCIツールではないので、テストのマトリックスを組んでいろんなパターンを一気に流す場合にはやはりCIツールとの組み合わせが有効です。Towerは様々な管理オブジェクトを持っています。代表的なものが、自動化の対象を管理する「インベントリ」や対象へのログインに利用する「認証情報」、Playbookを管理する「プロジェクト」です。これらのオブジェクトを組み合わせて「ジョブテンプレート」を作っていきます。それが「ボタン」になり、このボタンを押せば自動化が動き出すわけです。この時、各オブジェクトには権限を割り当てることができます。「ユーザーAはこのオブジェクトを使うだけ」「Bは編集も可能」「Cは監査専用」という具合に、どんなロールを持つかを割り当てていきます。中島:監査に関して評判がいいのは、特別な設定をせずに実行結果が全て記録されることです。裏側で動いているモジュールの戻り値も全部取ってきるので便利です。中山:これはいいですね。タスクごとに、処理がいつ実行されたか表示されるのもありがたいですね。どこで詰まっているかがわかるのは、地味に便利です。中島:サービス化については、このように、画面上でいろんなオブジェクトを組み合わせて、ボタンを作っていく形です。GUIのエディターを使って「まずこのジョブテンプレートを実行して成功したら次にこれ、失敗の場合はあれ」という風に、複数のボタンをまとめた、より大きなボタンを作ることができます。Towerを介してPlaybookを取ってきて実行する、ということもできます。中山:いちエンジニアとして思うのは、こういうツールが整ってきたことで、様々なアイデアを試しやすくなりましたね。「いろいろ試行錯誤したい」というタイプのエンジニアには、インターネットで情報が手に入りやすくなったことを含めて、いい時代になったなと思います。昔のインフラエンジニアの仕事というのは、各種コマンドやConfigファイルに通じること、という印象でした。お二人の話の端々から、今まさに、その役割は変化しつつあるのだなと痛感。Towerのようなツールに単純だけれど面倒な部分を極力任せて、グランドデザインの設計だったり、あるいはコンテナ、さらにその次のトレンドにアンテナを張ったりと、好奇心を生かせる仕事に時間を費やせるようになるのではないかと、期待感を抱きました。一方で、あまりにインフラが抽象化、隠蔽化されてしまうと、いざトラブルが起きた時に適切に切り分けて対処ができるかな、という不安もあります。身につけておかなければいけない知識にキリはないのかもしれません。