IaCとは ― 宣言型と手続き型の違い

開発用・テスト用・本番用と、同じ構成の環境を管理画面で何度も作っていると、どこかで設定が食い違います。IaC（Infrastructure as Code）は、サーバやネットワークの構成をファイルに書き、そのファイルからツールに環境を作らせる方法です。管理画面を操作して1台ずつ作る代わりに、あるべき構成をコードとして残します。

ここでのインフラは、アプリを動かすためのサーバ・ネットワーク・ストレージなどを指します。NISTは、IaCを、仮想のインフラを作るのに必要な設定値を書いたコードと説明しています。そのコードの内容は、クラウドやデータセンターの管理用のAPIを通して反映されます。APIとは、プログラムから機能を呼び出すための窓口です。

手作業では、担当者が管理画面を操作して、環境を直接変えます。IaCでは、担当者はまずファイルを書き換えます。ファイルの内容を確かめてから、ツールがその内容を環境に反映します。

ファイルはテキストなので、ソースコードと同じようにバージョン管理できます。AWSのサービスであるCloudFormationの公式ドキュメントは、誰が・いつ・何を変えたかが分かると説明しています。前の版のファイルを使えば、変更を取り消すこともできます。

反映する前に、何が変わるかを確かめる仕組みもあります。IaCツールのTerraformは、作る・変える・消すリソースを並べた実行計画を作り、承認を得てから反映します。CloudFormationでは、変更セットが同じ役目を持ちます。

宣言型とは、最終的にどうなっていてほしいかを書き、そこへ至る手順はツールに任せる書き方です。手続き型とは、作業の手順を、実行する順に書く書き方です。手続き型は、命令型とも呼ばれます。

Webサーバを2台用意する例で比べます。どちらも説明のための書き方で、特定のツールの文法ではありません。

Webサーバ:
  台数: 2

1. Webサーバを1台作る
2. Webサーバを1台作る

宣言型のファイルには、Webサーバは2台とだけ書きます。ツールはいまの環境と比べて、0台なら2台作り、1台なら1台だけ足します。手続き型のスクリプトは、書いた手順を、そのとおりに実行します。

図の手続き型は、いまの状態を確かめずに、手順だけを書いた例です。手続き型でも、実行の前にいまの状態を確かめる処理を書けば、同じ結果にできます。ただし、その確かめる処理は、手順ごとに自分で書く必要があります。

NISTは、IaCを宣言型のコードと位置づけています。Microsoftも、できるだけ宣言型の定義ファイルを使うよう勧めています。手続き型のスクリプトは、年月とともに保守の負担が積み重なりやすいからです。あるべき状態を書いて差を埋めさせる考え方は、Kubernetesのコンテナの管理にも使われています。

冪等性（べきとうせい）とは、ある操作を1回行っても、くり返し行っても、結果が同じになる性質です。サーバの設定を自動化するツールAnsibleの用語集も、この意味で冪等を定義しています。

前の節の図で、宣言型のファイルを2台ある環境に適用すると、何も変わりませんでした。これが冪等性です。Microsoftは、始める前の環境がどんな状態でも同じ構成に設定されることを、IaCの大事な原則に挙げています。

冪等性があると、同じファイルから、開発・テスト・本番の環境を同じ構成で作れます。CloudFormationの公式ドキュメントは、一度書いたテンプレートで、同じリソースを複数のリージョンに何度でも作れると説明しています。環境ごとに手で作ったときに出る、小さな違いが生まれにくくなります。

Ansibleでは、個々の処理の単位をモジュールと呼びます。多くのモジュールは、目標の状態になっているかを先に確かめ、なっていれば何もしません。ただし公式ドキュメントは、すべてのモジュールがそう動くわけではないと注意しています。

ドリフトとは、実際の環境の構成が、IaCのファイルに書いた構成からずれた状態です。CloudFormationの公式ドキュメントは、設定値が変わった場合と、リソースが消された場合の両方をドリフトに含めています。

ずれの多くは、ツールを通さない変更から起きます。たとえば、障害の対応を急いで、管理画面からサーバの設定を直した場合です。ファイルは古いままなので、次に適用したときに、直した設定が元に戻ることがあります。

NISTは、ファイルの構成と実際の環境が同じかを、反映の直後と運用中に定期的に確かめるよう求めています。管理画面やコマンドからの変更は、IaCのファイルに反映されないからです。Microsoftの説明のとおり、変更するときは環境ではなく、ファイルを直します。

ずれの見つけ方は、ツールごとに違います。Terraformは、ふだんの設定では、実行計画を作るたびに実際の環境を読み直し、ファイルとの違いを調べます。違いがあれば、環境をファイルに合わせる変更が計画に入り、適用すると元に戻ります。

CloudFormationには、ドリフトを検出する機能があり、ずれたリソースと設定値を示します。検出の機能は、ずれを示すだけで、環境は変えません。見つけたずれは、ドリフトに対応した変更セット（drift-aware change set）を使うと、テンプレートの設定に戻せます。逆に、テンプレートのほうを、実際の設定に合わせて書き直す方法もあります。

IaCのツールは、対象のクラウドと書き方がそれぞれ違います。次の表は、よく名前が挙がるツールを並べたものです。

TerraformはHashiCorpのツールで、プロバイダーというプラグインを足して、AWS・Azure・Google Cloudなどを扱います。CloudFormationはAWSのサービスで、BicepはMicrosoftがAzure向けに用意している言語です。Ansibleでは、プレイブックというYAMLのファイルに、サーバのあるべき状態を書きます。プレイブックのタスクは、上から順に実行されます。

NISTは、インフラと構成管理を分けて説明しています。仮想マシンを起動してネットワークにつなぐまでがインフラで、起動後にWebサーバのソフトを入れて設定するのが構成管理です。Ansibleの公式ドキュメントは、プレイブックを、構成管理と複数台への配備を行う仕組みと説明しています。

ネットワーク機器の設定に使う例は、ネットワーク自動化の記事にあります。どのツールが向くかは、使うクラウドや、管理する対象によって変わります。CloudFormationのテンプレートとスタックの扱いは、CloudFormationの記事で説明しています。

メリット

• 同じファイルから、同じ構成の環境を何度でも作れる
• 変更の履歴が残り、誰が何を変えたかを追える
• 反映の前に、変更の内容をレビューできる
• 問題が起きたら、前の版のファイルに戻して変更を取り消せる

同じ構成のサーバを何台も作れるので、IaCはスケールアウトと相性がよい方法です。サービスごとに環境を作るマイクロサービスでも、構築とデプロイの自動化が重視されます。同じ構成の本番環境を2つ用意して切り替える方法は、ブルーグリーンデプロイとカナリアリリースの記事で説明しています。

構成がファイルに残るので、別の事業者へ移すときに、何を作り直せばよいかを見通せます。1つの事業者から移れなくなる問題は、マルチクラウドとベンダーロックインの記事で説明しています。

費用の持ち主を表すタグも構成のファイルに書いておくと、付け忘れを防げます。タグで費用を分ける方法は、FinOpsの記事で説明しています。

注意点

• ファイルの誤りも、そのまま環境に反映される
• 管理画面から直接変えると、ドリフトが起きる
• ツールごとに書き方が違い、使うツールの書き方を覚える必要がある

NISTは、IaCのコードにも、脆弱性につながる誤りが入りうると指摘しています。そのため、ファイルを取り込む前に、問題が無いかを検査するよう求めています。この検査を変更のたびに自動で行う流れが、CI/CDです。

• NIST Special Publication 800-204C「Implementation of DevSecOps for a Microservices-based Application with Service Mesh」（4.3 CI/CD Pipeline for Infrastructure as Code）
• Microsoft Learn「What is infrastructure as code (IaC)?」・「What is Bicep?」
• HashiCorp「What is Terraform?」・「terraform plan」
• AWS CloudFormation User Guide「What is CloudFormation?」・「drift detection」・「Using drift-aware change sets」
• Ansible Documentation「Glossary」・「Ansible playbooks」