Infrastructure As Codeとは、インフラストラクチャの構成や変更をコードにより管理することを意味します。

Infrastructure As Codeの背景として、2つの課題をお伝えしました。
まず、従来のシステム基盤構築においては、台帳（エクセル等）でインフラストラクチャを一元的に管理するのが一般的でしたが、台帳のメンテナンスに多くの労力と手間を要し、実際のインフラストラクチャと台帳の内容が乖離する状況になっていました。
また、ソフトウェアの導入と構成管理では、セキュリティリスクに対応するために速やかなアップデートの適用が要求されますが、アップデートを適用する対象のソフトウェアが増加している現状では、手順書への反映が追いつかなくなり、人為的ミスが起きてしまうリスクが高まっていました。

これらの課題に対し、Infrastructure As Codeを導入することで、台帳管理のWeb化や作業の自動化、管理レベルの引き上げといったアプローチが可能になります。

従来の企業システムの課題を解決するための「Infrastructure As Code」に関するツールは多数存在しています。
そのため、ツール導入が目的となってしまうケースもよく耳にします。
適切なツールを選定するために、「イミュータブル」と「冪等性」の特性を理解することの重要性をご説明しました。

◆◆イミュータブル
不変性と訳されますが、これはインフラストラクチャを更新しないことに由来します。
新しくシステムをアップデートする際は、これまで運用していたインフラストラクチャは破棄し、ゼロから新しいインフラストラクチャを構築します。
これにより、インフラストラクチャを継続して運用した場合に抱える、潜在的な影響リスクを解消することができます。

イミュータブルを実現する代表的なツールとして「Terraform」をご紹介しました。
理想のインフラストラクチャをコードで定義し、インフラストラクチャの構築と破棄が何回でも可能になります。

◆◆冪等性
コマンド等の操作を複数回実行しても、常に想定したソフトウェア構成の状態にすることを言います。
想定したソフトウェア構成状態の例としては、特定バージョンのソフトウェアがインストール済みになっていること等を指します。

人力で想定のソフトウェアを構成することはできますが、数十台から数百台規模になった際は、全マシンを想定のソフトウェア構成の状態にするために、多くの時間と労力が必要になります。
また、失敗（作業の歩留まり）が発生した場合には、失敗したマシンと成功したマシンを区別して再度作業する必要があります。

冪等性を実現する代表的なツールとして「Ansible」をご紹介しました。
操作の対象となるマシンのソフトウェア構成をコード定義し、想定の状態にすることが可能です。

セミナーでは、AWSの環境へのWebシステム（WordPress）の導入を、「Terraform」と「Ansible」を利用しInfrastructure As Codeの形で実践するデモをお見せしました。

Terraformのパートでは、構築するインフラストラクチャ（仮想マシン、セキュリグループ）をコードに定義し、構築実行（terraform apply）することで、AWS上にWebシステムに必要なインフラストラクチャを構築しました。
また、破棄実行（terraform destroy）することでインフラストラクチャを確実に破棄しました。

Ansibleのパートでは、ソフトウェア（Webサーバ、アプリケーションサーバ、DBサーバ、ソースコード）の構成状態をコードに定義し、タスク実行（ansible-playbook）することで、Webシステム（WordPress）に必要なソフトウェアを仮想マシンに構成しました。