IaC（Infrastructure as Code）とは、サーバーやネットワークといったインフラの構成を、画面上の手作業ではなくコードとして書き残す手法のことである。コードとして書き残すことで、誰が実行しても同じ環境を何度でも再現できるようになる。構成の内容をファイルに宣言しておき、ツールがその通りに環境を組み立てることで、この再現性を実現する。コードベースで管理できるため、変更履歴を残し、レビューにかけ、間違えれば前の版へ戻せるメリットもある。
従来、サーバーの構築は担当者が画面を操作し、手順書を見ながら設定していた。この方法では、同じはずの環境でも少しずつ違いが生まれ、「あの担当者しか分からない」状態に陥りやすい。設定が少しずつずれて元に戻せなくなった状態を設定ドリフト（構成のずれ）と呼び、障害の温床になっていた。
語源・提唱者
Kief Morrisが2016年に著した書籍『Infrastructure as Code』を出したことで、多くの現場がこの考え方を共有するようになった。
キーフ・モリス 引用：https://share.google/fBB2kqVkKxkQb3GWh
IaCという考え方は、2000年代後半にWebサービスが一気に大規模化するなかで、手作業の限界から生まれた。「Infrastructure as Code」という呼び名自体は特定の一人が名づけたものではなく、開発と運用を一体で進める動きが広がるなかで現場が自然に使い始めた言葉である。
宣言型と命令型で書き分ける
IaCの書き方には、大きく2つの流儀がある。
- 宣言型（Declarative）：「最終的にこうあってほしい」という状態を書く。ツールが今の状態との差分を見て、必要な操作だけを実行する。TerraformやPuppetがこの方式で、何度実行しても同じ結果になる（この性質を冪等性（べきとうせい）と呼ぶ）。
- 命令型（Imperative）：「まずこれをして、次にこれをする」と手順を順に書く。従来のスクリプトに近く細かく制御できるが、途中で失敗したときの立て直しが難しい。
現代的なツールの多くは宣言型を基本にしている。実現したい状態さえ書いておけば、そこへ至る手順はツールが引き受けるため、書く側は「何を実現したいか」に集中できる。
検証環境をすぐ作れる
IaCが実務でいちばん力を発揮するのは、本番とそっくりの環境を一時的に用意する場面である。
新機能や性能を検証したいとき、構成をコードで書いておけば、コマンド一つで本番同等の環境を丸ごと立ち上げ、検証が終わったら丸ごと壊して費用を止められる。アプリの開発者とインフラの運用担当（SRE：Site Reliability Engineer）は、構成ファイルをレビューで共有しながら使うことが多い。構成ファイルはコードとしてリポジトリ（コードの保管庫）に蓄積され、次の環境づくりでもそのまま再利用できる。
ありがちなつまずきは、最初に一度書いたきりコードを放置し、その後の変更を画面から手で当ててしまうことである。すると実際の環境とコードが食い違い、せっかく防いだはずの設定ドリフトがぶり返す。回避するには、環境への変更を必ずコード経由で行う運用に統一し、手作業での直接変更を禁じるとよい。あわせて、現在の状態を記録するファイル（state）の共有場所と、複数人が同時に変更しないよう防ぐ仕組み（ロック）の取り決めも先に決めておく。
