みなさん、こんにちは！
システムソリューション営業本部（略称「SSS」）の杉本です。
技術ブログにも関わらず技術的なことを書いていないような気がするのでAnsibleの導入からPlaybookの実行までシリーズ形式でお届けします。
今回はその第1弾！Ansibleってそもそも何？おいしいの？？といった疑問に答えていこうと思います。

Ansibleって何？

オープンソースの構成管理ツールである。サーバを立ち上げる際、あらかじめ用意した設定ファイルに従って、ソフトウェアのインストールや設定を自動的に実行する事が出来る。特に大規模なコンピュータ・クラスターを構築する時に、時間の短縮やミスの削減に有用である。構成管理に加え、オーケストレーションやソフトウェアデプロイメントの機能を持つ。（出典「フリー百科事典『ウィキペディア（Wikipedia）』」）

いきなりウィキペディアの引用から入りましたが、やはりウィキペディアは優秀ですね。
AnsibleはInfrastructure as Code（IaC）と呼ばれる構成管理ツールの一つです。
他にもIaCの代表的なツールとして「Chef」や「Puppet」などがあります。

IaCツールって何？

さらっと出てきた構成管理ツール（IaCツール）はあたかもプログラミングのようにコードを書いて、コードの内容通りにインフラを構成・管理・運用できます。
プログラミングでインフラ…例えばサーバー/クライアントさらにはネットワーク機器まで管理してしまいましょうというものです。
IaCツールの特徴は要約すると以下のようになります。

　1.インフラ機器のセットアップ（オペレーション/コマンド実行）を自動化する。
　2.インフラ機器の状態をコードで管理する。
　3.複数台のインフラ機器を一括して設定する。
　4.コードで指定した状態を維持するようにインフラ機器を整備する。

う～ん、1と3は他のツールでもできそうですね。そうなると重要になるのは2と4でしょうか？
でも、1と3もIaCを使うと楽になるので…簡単に掘り下げてみましょう！

インフラ機器のセットアップを自動化？

Webサービスなどを新規に展開するときにフロントエンドサーバーを何台も一度にセットアップするといったことを実施したことがあるかと思います。他にもクライアントPCの入れ替えで数百台のPCをマスターイメージから展開して個別設定なんてこともやられている方も多いかと思います。
一般的な導入までの流れは下図のような形になるかと思います。



構成管理ツールを使うと途中のステップを自動化できます。



そうです！展開作業が手作業ではなく自動化できるのです。さらにパラメーターシートが不要になります！！
現状と一致しないパラメータシート、設定を変更するたびに更新するパラメータシート、せっかく作ったのに有効利用された記憶のないパラメータシート…

それはさておき、手作業でやっていた部分を自動化できて、さらにコードを見れば設定がわかるIaCは最高です！
他にも設定後のパラメータ確認などの目視作業がなくても記述したとおりに設定されていることが担保されている（後述の冪等性によります）ので動作確認さえ問題なければ即、次工程に引き渡せます。

インフラをコードで管理する？

「インフラをコードで管理」という字面を見ると何か分かった感じがしますね。皆さんの頭に思い浮かんだとおりです！
例としてわかりやすいのがネットワーク機器ですが、コンフィグを流し込めばそのコンフィグの通りに設定されます。
このコンフィグがコードになり、ネットワーク機器だけでなくサーバーOS、クライアントOSなどにも適用できるということです。

この「コード」ですが、なんと1つの言語ですべてのインフラ機器を管理できるのです！
WindowsもUNIXもCiscoもNetAppもあれもこれも…すべての機器が1つの言語で管理できちゃうんです！
例えば、Webサービスの3層構成で開発をする場合はフロントはJava、AppはPython、DBではSQLと単純なWeb構成でも3つの言語を駆使することになります。ところがIaCツールでは1つの言語を覚えるだけですべてのインフラを管理できるのです。画期的！！

複数台のインフラ機器を一括で設定？

私は以前、似たような機能を持つサーバーやクライアントなど同じ設定を繰り返す作業ということを繰り返しやりました。ところがチェックシート片手に全く同じ設定にしたつもりでも、ちょっとずつ違っていて酷く怒られた記憶が…

そんな状況でもIaCなら対象マシンを並べてコマンド一つで一括設定できます。
しかも、人手を介さないのできれいに設定できます。
当然、運用中のサーバー/クライアントに対しても実行できますので日常の運用にも利用できます。

インフラを整える？

IaCツールの特徴として常に環境を一定の状態に保つことができるというものがあります。
難しい言葉で冪等性（べきとうせい）と言います。数学用語ですね。多分…ですよね？
私はこの言葉を何回やっても同じ「結果」になるという性質のことだと理解しています。
さてこの冪等性ですが、IaCツールにおいて環境を整えるためにとても重要な要素です。

複数のサーバーを運用していると必ず発生するのが設定差異だと思います。
簡単な例だと「ローカルネットワークの場合にプロキシを使用しない」のチェックボックスがどうなっているかとかですね。
運用には影響はありませんが、ちょっと違うみたいなことが運用中に発見されるとすべてのサーバーを目視でダブルチェックしながら確認みたいな作業が発生してしまいます。

IaCツールを使えばそんな状態にそもそもならない、なったとしても正しいコードを流せばすべてのサーバーが想定通りの設定になります。
常に正しい環境を維持することもIaCツールであれば簡単にできます。

なんでAnsible？

IaCツール自体は色々ありますので自分に合ったツールを使うのが正解だとは思います。
先に例に出したChefやPuppetも非常に良いツールです。そんな中でAnsibleをお勧めするにはいくつか理由があります。
下のグラフを見てください。



Googleトレンドのグラフですが、過去5年でAnsibleの検索数が伸びているのがわかります。IaCツールのメインストリームがAnsibleに流れている証左になります。

余談ですがGoogleトレンドで比較表を作るときに「Chef」を普通に指定すると料理人のシェフが混じってしまい、検索数がすごく伸びます。これを排除するのに苦労しました。「Puppet」も普通の名詞なのですがこちらはあまり検索している人少なかったですねぇ…いや、面白い！

次にChef、Puppet、Ansibleの比較表を作成しました。ただし、個人の見解です。社のブログですがなぜか会社の見解ですらありません…



表からAnsibleの優位点は「エージェントレス」、「汎用言語（YAML）での管理」、「導入が簡単」といったところでしょうか。

対象でSSLかWinRMが動いておりPythonが入っていればなんでも出来るという簡単さがおすすめする理由の一つです。

一方で、条件ごとに動作を変えて設定といった操作は苦手です。複雑なことをしたいのであればChefかPuppetをお勧めします。

ただ、構成管理ツールを使って複雑なことをするのはお勧めしません。というのも折角コードで構成を管理できるにも関わらず管理すべきコードが複雑化してしまうと読める人が少なくなってしまい、結局属人化してしまう恐れがあるからです。
個人的には、システムはシンプルであればあるほど良いっと思っていますので、難しいことはやらない方向で運用管理もしていきたいと考えます。

まとめ

色々あるIaCツールですが、私は今後の発展性と導入のしやすさからAnsibleをお勧めしています。
構築から運用、管理までを１つのツールで完結でき、管理対象にエージェントを導入する必要のないAnsibleは構成管理をするのに非常に有用だと思います。
次回はAnsibleの構築手順を説明したいと思います。

この記事でAnsibleに興味を持たれた方は是非一度ページ下部の「お問い合わせ」よりお問い合わせください。

※Ansibleは、米国Red Hat, Inc. の米国およびその他の国における登録商標もしくは商標です。