DeNAのサーバーサイドエンジニアが教える　構成管理ツール「Ansible」実践ガイド

Ansibleで始めるサーバーサイドのインフラ構築

佐藤学氏：お待たせいたしました。「Ansibleで始めるサーバーサイドのインフラ構築」と題して、佐藤がお届けします。よろしくお願いします。

オンラインでこれだけの人数の前で登壇というのは初めてなので、緊張していますが、それ以上に、どのようなレスポンスがあるかを楽しみしていますので、みなさんよろしくお願いいたします。

さっそく始めます。まず自己紹介です。私、佐藤といいます。得意分野はInfrastructure as Codeを長く実践していまして、その中でAnsibleですね。こちらは2015年ぐらいからやっているので、だいたい5～6年目ぐらいになります。

最近は、AWSのCDKというクラウドのデベロッパーキットがあり、そちらをけっこうやっています。著書としてちょっとだけ案内すると、『Ansible実践ガイド』という本がありまして、この最新版にも参加したので、もしよければ見てみてください。

目次です。アンケートを見て、けっこう初学者の方、もしくはAnsible自体を知らないよ、という方が多かったので、まずはAnsibleについて簡単に紹介します。

2番目にAnsibleの実行方法ですね。ちょっと簡単に、こうやって実行するんだよっていうのを説明します。

3番です。ここが一番ボリュームがあるんですけれども、ユースケースとして、Ansibleの「こういうふうに使う」「こういうふうに導入しました」というものを紹介します。

そして4番に簡単ではありますが、まとめます。

Ansibleの3つのコンセプト

まず「Ansibleについて」ということで、Ansibleを知らない方も多いということだったので、簡単に紹介します。

Ansibleとは、構成管理を行えるオープンソースのソフトウェアです。オープンソースと言っているので、「Ansible GitHub」とかで検索すると、たぶん一番上にヒットするかなと思います。Ansible自体はRed Hat社が保有していまして、Red Hatも含めて開発している状況です。

Ansibleのソースコード自体は、Pythonで開発されています。こちらの勉強会のみなさん、Pythonにたぶん興味があるというか、実践されている方が非常に多いかと思いますので、もしAnsibleを使ってみて「わからないなぁ」ということがありましたら、直接ソースコードを見たほうがみなさんは早いんじゃないかな、という勝手な想像をしています。

Ansibleを知る上で、Ansibleのコンセプトが3つありまして、「シンプル」「パワフル」「エージェントレス」です。この3つが基本であり、これだけ把握するだけでも、Ansibleがどういったものなのかをけっこう知れます。そのためこのコンセプトを、簡単にですが紹介します。

Ansible自身が構成管理ソフトウェアのジャンルに入るんですけれども、ほかの構成管理ソフトウェアと比較してどういった点が優れているかというところも合わせて、紹介します。

シンプル

今までですと、けっこうコードベースが多くて、簡単に言うと、「なんらかの言語で直接、ほとんどロジックを書いている」ようなものが多かったんですけれども、Ansibleに関しましては、YAMLが採用されています。そのYAMLにAnsibleで構成管理したい内容を明瞭記述する必要があります。

こちらの例では、yumを使用してhttpdの最新版をインストールする場合のサンプルとして記載しました。こちらがYAMLです。name:installってすごい簡単に書いてるんですけど、「yumを使ってhttpdの最新版をインストールします」というように、けっこう見た目で、なんとなくどういったことをするのかなっていうのは、わかりやすいかなと思います。

パワフル

続きまして「パワフル」です。簡単に言うと2つありまして、マルチレイヤーを構成管理できますといういうことが1点目。そして2点目として、冪等性を担保できるところを、この「パワフル」で表しています。

まずマルチレイヤーの構成管理というところから。簡単に言うとマルチレイヤー。マルチレイヤーっていうのは、いろんなOSであったりクラウドであったりネットワークであったりソフトウェアであったり、極端にストレージとか、そういったハードウェア寄りのところまでカバーしています。それを実現するために、Ansibleではモジュールというものを用意して、そのマルチレイヤーの構成管理を実現しています。

私が実務で使用しているものとしては、OSとクラウドと、ネットワークはあんまりないですね。OSとクラウドですかね、この2点を中心に行っています。

実際の導入事例として多いのはまあOSで、クラウドも多いんですが、たぶんネットワークが非常に最近多くて。Ansibleというソフトウェアはけっこうネットワークのデプロイ、自動化に強いので、そちらもフィーチャーされています。

「冪等性とは」ということですが、こちらはたぶんご存じの方も多いかと思うんですが、念のため紹介します。簡単に言うと、「Ansibleの操作を何回実行しても結果が変わらないことを指します」とあります。

先ほどのYAMLと同じなのでここは読み飛ばしまして、Ansibleを実行する場合、1回目の実行結果としては「changed」と返ってくるんですね。要はhttpdをインストールしましたよ、ということで結果が返ってきます。

2回目ですね。2回目に実行すると、もうインストール済みなので「インストールされている」という判断をAnsible側で勝手に行ってくれるので、「ok」と返ってきます。このように何度実行しても、例えば2回目をやったらエラーになるとか、そういったことがないように、冪等性を担保するのがAnsibleの強みです。

エージェントレス

最後に「エージェントレス」です。今までの構成管理ソフトウェアには、いろいろあるんですけれども、だいたいエージェントを必要とする場合が多かったんですね。Ansibleの場合はエージェントレスで動作いたしますので、エージェントのインストールが不要となります。エージェントのインストールが不要なので、管理も不要です。

エージェント型にもメリットがあるんですけれども、エージェント自体のバージョンアップ、メンテナンスが必要となりますので、そういった点のインストールする工数であったり、コストもそうですし、メンテナンスがいらないというのもAnsibleの強みだと思います。

Ansibleにおける構成管理の例

次にAnsibleの実行方法を紹介します。まず概要として、今回ちょっと簡単な例をもとに、コマンドとかを本当にミニマムにした状態で紹介します。この章で、どういうふうにAnsibleが動くのかというイメージをつかんでいただけたら。

ここではAnsibleのインストールなどは省いています。Ansibleのインストールはされていることを前提として、紹介します。

構成管理の対象です。まずAnsibleで構成管理する対象の情報として、いくつか挙げました。

まずOSですが、Windows Server 2016を対象としました。Linuxのほうがいろいろ例があって簡単なんですけれども、Windows Serverのほうが実例が少ないことと、サーバーを管理するという意味ではLinuxとかWindowsとかで、まぁ手順とかはいろいろ違うんですが、そこまでAnsibleの実行イメージとしては変わりません。Windows Serverのほうがいろいろ流用が効いたので、例として挙げました。

構成管理の内容です。どういった構成管理をWindows Serverに対して実行するかというと、まずタイムゾーンです。タイムゾーンとリージョンを、要は日本向けに変更するという内容になります。これ、それぞれモジュールが「win_timezone」であったりとか「win_region」というのが用意されていますので、こちらを利用します。

最後に、リージョンを変更した場合、Windowsの再起動が必要となる場合があるんですね。Windowsの再起動が必要であればWindowsの再起動を実行する、というのをここにあるYAMLで紹介しています。それには「win_reboot」というモジュールを使用します。

YAMLの例

ポイントは2番目の「Change Region」を行ったときの「register:result」です。ここでwin_regionっていうモジュールからresultとして結果を受け取ります。そしてresultのrestart_requiredを判定して、Windowsのサーバー再起動を行います。このresultのrestart_requiredがfalseであればWindows再起動が行われないという、けっこう便利な作りになっていますので、こちらはのちほど、どういう動きになるか紹介します。

実行と冪等性の確認

実行すると、PLAYはSetup Windows Server 2016という処理を実行してるんですけれども、TASKとして3つありまして、タイムゾーンの設定とリージョンの変更、リージョンの変更で再起動が必要な場合再起動します、という処理になっています。

ここでそれぞれchangedと書いてあるので、1回目の実行時はタイムゾーンの変更とリージョンの変更が行われて、そのリージョンの変更に伴って再起動されました、という表示になっています。okが3でchangedが3で、skippedが0、みたいになります。

次なんですけれども、ここがポイントでして「冪等性の確認」ということで。先ほどの章でもあったんですけれども、同一のコマンドを再度実行して、冪等性が担保されているかを確認します。

この場合Change Regionはすでに変更済み、実施済みとなっており、モジュール側は再起動を不要と判断するので、Windows再起動は行われません、と表示されています。それがこちらです。TASK [test:Set Timezone]がokで、Change Regionがok。つまりなにもしませんでしたよ、もう設定されてますよ、ということだったので、その結果Rebootがskipされました、という結果になります。

ユースケース

ここまでがAnsibleの実行方法のサンプルです。続いて3番のユースケースです。ここが一番ボリュームがあるところです。

ユースケースということで、ちょっと過去というかけっこう前なんですけれども、Windowsにおいて、ある作業を自動化した場合の構築手順を、この資料向けに簡素化したものをイチから作って記述しました。この構築手順を部分的に掲載して、Ansible化したコードと比較して、どれぐらい作業が簡略化されているか確認していきます。

Ansible化する内容としましては、先ほどと同じくWindows Server 2016を使います。構成管理の内容といたしましては、.NET Framework3.5をインストールするという、みなさん使われてる方も、いるかいないかアレなんですが、当時はけっこう必要でした。それを自動化します。先ほどと同じように、再起動が必要であれば再起動します。こうしたステップの構成管理の内容を書いていきます。

まず構築手順です。これはまず完全にAnsibleとかなにもなしで、手動で実行していることを前提に記載したものです。構築手順書は、こういう方眼紙Excelです。同じ列幅になって、みたいな感じで手順書を作ってて、エビデンスとして同じような画面を貼りつけて。久しく作っていないんですが、こういうExcelで作るテスト仕様書がありました、当時は。

構築手順のエビデンスです。要は作業した場合どういったものを（エビデンスとして）取るかというと、1、2、3……とどんどんいって、結果的には最後.NET Frameworkをインストールしたら再起動します、みたいなステップで、計12ですね、構築手順を実施する必要があります。

こういう実施手順があった場合、これを例えばAnsibleに置き換えたらどうなるかというと、こんな感じです。

まずYAMLとしまして、win_featureというモジュールを使って.NET Frameworkをインストールします。上のWindows featureに書かれた命令で.NET Framework3.5がインストールされます。その下は先ほどと一緒ですね。Windowsの再起動が必要であれば再起動します、という処理フローになっています。YAMLとしてはこんな感じです。

実行結果としましては、1個目がchanged、changedで変更されて、最後2回目ですね。冪等性確認ということで、本当に反映されたかというと……あぁ、すいません。冪等性確認のほうちょっと動きがありますね。changedってあるこれはokが返ってきて、TASKとしてはskippingになります。

手動で実行した場合とAnsibleで表現した場合との比較

ここでちょっと、手動で実行した場合とAnsibleのYAML化した、要はAnsibleで表現した場合の比較をします。まずこちら、一番言われるのは作業時間・作業内容の比較です。手動で実行した場合は、ステップ1～12をひたすらGUIを操作してエビデンスを取得して、みたいなのをずっと繰り返して、最後まで終わったらテスト仕様書に「OK」みたいな感じで結果を記入するかと思います。

それと異なってAnsibleは、先ほどご説明したとおり、YAMLを書いたらあとはAnsibleを実行して、2回目に冪等性を確認して終わり、みたいな。

これは、時間というよりは、この時間差を見てもらいたいのですが、構築作業を1台で行う場合には、実際には、もうちょっと差はあると思うんですけど、あんまり変わらないと思います。

問題なのは、3桁台数、100台以上を導入しなきゃいけなかった場合です。例えば対象が100台とした場合、簡単に言うと、先ほどの1～12の部分が100台ぶん掛け算になりますので、直列で実行した場合を計算すると、だいたい3時間20分かかりますよ、というのが手動のほうになります。で、テスト仕様書に結果を記入ってところは変わらなくて。

一方、Ansibleで実行した場合は100台を並列処理できます。つまり何台あろうが、たぶん帯域とかその他リソースが均等に、1台ごと同等で使えるという前提にはなるんですけれども、100台並列で行うので、理論上は1台と変わらない時間になるということになります。

それは2回目の冪等性を確認した場合も同一でして、当時は、結果的に、1台も100台もあまり時間は変わらないということになりました。例えばですけど構築作業を100台で行う場合には、構築時間にけっこうな差が生じますよ、という結果になります。

Ansible化したほうがよい場面と、しないほうがよい場面

まず1番は、手順化されている作業です。GUIにしろコマンドラインにしろ、ある程度コマンド化されていれば、Ansible化して実行させることによって、けっこう工数の削減であったりとか、メンテナンスコストは下がると思います。

次に、繰り返し行う場合です。同一の作業を永続的に実施する場合、とくに運用チームみたいなものが当時はありましたので、そういったところだとひたすら同じ作業を毎日、例えばですけどサーバールームみたいなところに、2人で入ってぽちぽち同じ作業を繰り返すみたいなものも、Ansibleとかに置き換えると人的コストも下げられますし、リスクも少なくなるかと思います。

それと似てるんですけれども、複数の環境です。先ほどの例でたくさん構築する場合などは、これもAnsibleに置き換えてしまったほうがいいかなと思います。なぜかというと、やはりたくさんある環境というのは、例えばGUIなんてとくにそうなんですけれども、同じ作業をずっとやってるとけっこうミスが多くなることと、確認がすごくしづらくなるので、こういったときもAnsibleに置き換えてもいいかなと思います。

次にAnsibleに向いていない場合です。例えば手順化されてないとき。まぁこれは手順化してしまえばいいというのもあるんですけど、その作業の頻度であったり内容にもよるので、実際にすぐAnsible化するというのには、あまり向いてないと思います。

次なんですけれども、繰り返し行わないものです。突発で発生するようなものをAnsibleに焼き直してテストしてってやっていると、それよりもパパッと実行したほうが早い場合もあります。ケースバイケースにはなるんですけれども、考慮いただけるといいかなと思います。

（最後の早急に環境を提供した場合に関しては）一番難しいんですが、これはAnsibleに限らなくて、インフラをコード化しようと言うとだいたい出てくるんですけど。

そもそもインフラをコード化しますというときに、早急に環境に適応したい場合とかあると思うんです。早急に環境に適応したい場合に、Ansible化とかインフラのコード化というのをやるより、とっとと作ってですね、例えばサービスリリースとか、そういったビジネスロジックに乗せる場合は、意外とこういうものを使わずに、最初に手で作っちゃってリリースというのは多いかと思います。むしろそこに時間割いてる余裕ないということもあるかと思います。

こちらに挙げたものも、場合によって、例えばAnsibleをすでに導入していて、その他のサーバーを構築する場合とか、いろんなケースによって変わってくるとは思います。けれどもいきなり、例えば今から「Ansibleを最初から導入します」ということであれば、ここに書いた「手順化された作業で、繰り返し行うもの」から始めると良いかなと思います。導入に際して例えば、SIerさんであればお客様に対しての提案にもなりますし、自社サービス等であれば、自社の工数削減とかにも活かしやすいと思います。

正直、喋りたいことはたくさんある

ちょっと長くなり、派生しましたが、最後、まとめます。今回、ユースケースであったり実行結果であったりのところを紹介しました。

正直喋りたいことはまだたくさんあります。今回はアンケートを事前に見て、「Ansibleを知らない」という方がけっこういたので、そちらの方向けの内容にしました。

ただ今後機会があれば、例えばOSをあまり紹介していないのでLinuxとか、OS以外のクラウドだったり、また、ネットワークはあまり経験がないですが、そういったほかの部分やソフトウェア、機器なども、紹介したいと思っています。

それからCI／CDですね。このあとのプレゼンでも出るかもしれませんが、Ansibleを使用したCI／CDも導入経験があるので、そちらについても紹介できたらと思います。

ちょっと駆け足になりましたが、ご清聴ありがとうございました。