Immutable Infrastructureとの違い

　Infrastructure as Codeと似た文脈で挙げられる概念として、「Immutable Infrastructure」がある。Immutable Infrastructureとは、一度構築したサーバの構成を変更しないという考え方である。構成を変更する場合は、サーバを新しく作り直す必要がある。

　具体的に、Infrastructure as CodeとImmutable Infrastructureの関係性、違いは何だろうか。両者の違いは「最初にサーバを構築した後に、構成を変更するかどうか」にあると考える。物理サーバ／仮想マシンの場合は、デプロイのたびに作り直すには時間がかかるので、構成管理ツールを利用して変更するプロセスが適している。一方「Docker」をはじめとするコンテナは、作成したイメージを高速に起動でき、コンテナの作り直しも簡単だ。そのためコンテナを変更する際は、構成を変更するのではなくImmutable Infrastructureの考え方で構築し直すことが多い。

　ただしImmutable Infrastructureは、Infrastructure as Codeに含まれる概念といえる。Dockerでは「Dockerfile」というスクリプトにコマンドを羅列してイメージを作成する。イメージの初期構築やコンテナの実行環境の構築、デプロイは構成管理ツールで実行することも可能である。現にAnsibleは、Dockerを扱うためのモジュールを充実させてきており、コンテナのデプロイやイメージの作成、複数のコンテナのオーケストレーションなどを行うことができる。その意味でも両者は親和性が高いといえるだろう。

業務はどう変わるのか

　では、Infrastructure as Codeによって業務をどう改善できるのか。

　例えば、情報システム部門が開発チーム向けに開発環境を用意するとしよう。従来であればインフラ担当者がサーバを構築して払い出し、その上で開発チームが仮想マシンを作成するというプロセスが考えられる。一方Infrastructure as Codeを取り入れれば、開発環境の構築を自動化、共通化することができる。一度、VagrantfileとPlaybookを作成してチームで共有しておけば、各自がVagrantとAnsibleを実行するだけで簡単に開発環境を作成可能だ。また作られた開発環境に差異が生まれない利点もある。

　次に本番環境の数十台のサーバにセキュリティパッチを適用する場合を考える。従来であれば、手順書を作成して検証し、変更管理簿を更新して、1台ずつ設定作業をする必要があっただろう。だが構成管理ツールを使えば、手順書を作成することなく、既にあるRecipeやPlaybookを修正し、「Pull Request」（注2）を出してレビューしてもらえば、複数台のサーバに一度にパッチ適用が可能となる。作業時間の短縮だけでなく、インフラのバージョン管理や人為ミスの削減が期待できる。

※注2　ソースコード共有サービス「GitHub」の変更管理機能。開発者のローカルマシン内のリポジトリ(ファイルやディレクトリの状態を記録する場所)での変更内容を、他の開発者に取り込んでもらうことができる。

　このように、Infrastructure as Codeの導入によって、インフラの管理を効率化することが可能になる。仮想マシンやコンテナを使っていなくても、構成管理ツールだけであれば、比較的導入のハードルは低いだろう。次回は最近人気のある構成管理ツールを幾つかピックアップし、それぞれのメリット／デメリットを紹介しながら比較する。

堀内晨彦（ほりうち・あきひこ）

生まれも育ちも香川県。香川大学大学院 情報科出身。学生時代は研究の傍ら、勉強会やコミュニティー活動に積極的に参加し、「Hubot×ChatOps勉強会」などを主催。2016年4月からは上京し、ICT企業でクラウドエンジニアの見習い中。趣味は料理とカメラ。

Webサイト：https://hico-horiuchi.github.io/