投稿日：2019年12月8日
現在のサーバインフラ構築では、仮想化技術の進歩や、アプライアンス製品の普及、クラウドの利用、サービスのコンテナ化などでどんどん効率化が進み、物理的な機器であることの制約からはかなり自由になってきたと思います。
これまでは、サーバを構築するのに構築手順書を書いて、それに基づいてサーバ職人が目利きと手作業でひとつひとつセットアップする「一点もののインフラ」という世界でした。
故にサーバ構築の現場では、よく以下のような課題が定期的に上がります。
- サーバの設定を構築時に手動でやっている（構築コストの問題）
- 長年動作しているサーバどういう設定になっているか分からない。
再構築や、サーバ増設が困難となる。
操作のエビデンスや過去の変更履歴を追跡することで、構成の踏襲は可能であるが、それも限界はある。（品質の問題） - 個々のプログラムの保守作業が手動であるためミスが起こりやすい。ミスをおこらないようにするための工数がかかりすぎている。（品質、保守コストの問題）
そのため、サーバインフラの構築フェーズでは、下のようなケースがよく問題となっていました。
- 同じサーバにもかかわらず構築担当によって微妙に構成が違う
- サーバを増設しようとして、過去の手順書通りに作業したが動かない
- 同じシステムを構成するサーバプリケーションのバージョンが微妙に異なる
このような課題を解決するために、IaCが活躍します。IaC（Infrastructure as a Code）とは、文字通り、インフラ構築の手順をコードにしてしまおう、という考え方です。前記した課題へのアプローチはそれぞれ下記のようになります。
- サーバの設定を簡単にスクリプトで記載して、複数台のサーバ設定を一括で可能（構築コストの削減）
- スクリプトとDRY RUN機能※によって、現在のサーバの設定情報が確認可能（品質の向上）
- 操作手順をansibleにすることで作業の手順を減らし、簡単なオペレーションが可能（品質の向上、保守コストの削減）
※DRY RUN…実際の変更を伴わない実行のことで、実施前のチェックなどに利用されます。
サーバの構成情報をコードにすれば、それがそのまま構築手順書になりますし、同じ構成のサーバを大量にセットアップすることも簡単になります。
また、IaCはクラウドや仮想サーバ等とも親和性が高く、デプロイしたサーバを定義の通りに構築、そのままOS設定およびのミドルウェアなどセットアップも続けて行うことができます。
当初はこのような動作をシェルスクリプトなどで実現していましたが、冪等性※を考慮すると、コードが肥大化してしまいがちです。そこで、そのような点を考慮したツールも数多く登場してきました。
※冪等性（べきとうせい）…サーバなどに対してスクリプトを実行するときに、一回実行する場合と複数回実行する場合で、同じ結果が保証されること。
IaCを導入し、インフラ（サーバ）構成をコード化するメリットは
- コードが手順書代わりになる
- 同じサーバ構成で何度でも作れる
- 作業が楽になる
- 同じ作業が誰でもできる
などが挙げられます。
デメリットは
- インフラ（サーバ）構成をコードに書き起こさなければならない
- コードに誤りがあると、最悪の場合致命的な不具合が出る
- 各設定をトライ＆エラーで調整する場合、作業が困難となる場合がある
最初はサーバを操作しながら試し、そこからコードに起こすという方法でカバーできます。
さて、実際に「インフラ構成をコード化するってどうやるの？」という話になりますが、世の中に色々と構成管理ツールはあります。有名どころだと、Chef、Puppet、Ansibleなど。ここでは、Ansibleというツールをご紹介いたします。
Ansibleがインストールされたサーバから、他の複数台のサーバの設定を行うことができます。Ansibleにはplaybookと言う仕組みがあります。
PlaybookはYAMLフォーマットで書かれたファイルにサーバに対する操作を定義していき、それをansible-playbookコマンドで実行することで、サーバを常にplaybookで定義した状態にしておくことができます。
Ansibleは、他の構成管理ツールと比較しても、以下のメリットがあげられます。
- サーバ側に何もインストールする必要がない
Chefは管理対象ノードにクライアント用のエージェント（chef-client）をインストールする必要がありますが、ansibleはPython 2.4が入っていて、sshでログインできればOKです。既存のサーバをAnsibleで構成管理する場合など、この点が大きなメリットになります。 - シンプルな構造になっている
ansibleはとてもシンプルで動かすだけならインベントリ(ホスト名を列挙したもの)とymlコードの2つだけあれば動きます。とっても覚えることが少ないです。 - コードが分りやすい
Chefと違って、rubyのシンタックス等を意識しないで済むのでよりシンプル
Chefのコードが分りにくい点の一つに上から順に実行されるとは限らないというのがあります。対してansibleは（比較的）挙動が理解しやすいです。 - 過去の手順書の資産を流用しやすい
過去の構築手順は、コマンドラインになっているものが多いはず、それをansbileに置き換えやすい。 - 後で見た時に見やすい。
Chefだと色々と柔軟にレシピに記載出来てしまう。その結果、後々わけが分からなくなる。Ansibleでは、playbookに記載できることは制限されており、複雑な事をしたい場合は、モジュールを作るという形で、構造化でき、実行する側はその中身を気にする必要がありません。
導入に腰が重いところも多々あるかと思いますが、まだIaCを体験していないインフラエンジニアの方は、是非いちど試してみてください。「Ansible」はお手軽で導入も簡単です。
この記事を書いたヒト
N.Dクラスアクト サブマネージャ
徳島県出身。前職はソフトウェア開発現場で品質管理を担当の後情報システム部に配属される。前職を退職後、クラスアクト入社。様々な案件において主にサーバSI業務を担当。現在も変わらず、顧客とのやり取りに奔走する毎日。