IaCとTerraform — 完成図を書くだけで、街が建つ
サーバーやネットワークを、管理画面でポチポチ作る代わりにテキストファイルに書いて作る。これが IaC(Infrastructure as Code)です。代表的な道具が Terraform です。
たとえるなら設計図を書くだけで街が建つレゴブロックです。書くのは「どう組み立てるか」の手順ではなく、「完成したらこうなっていてほしい」という完成図。Terraformが今の街と見比べて、足りない分を建て、余った分を壊します。図1で設計図を書き換え、plan と apply を押してみてください。
書くのは手順ではなく、完成図
図1のコードには「サーバーを作れ」という命令がどこにもありません。書いてあるのは count = 2、つまり「web サーバーが2台ある状態」だけです。これを宣言的な書き方と呼びます。
だから count を 2 から 4 に変えれば2台だけ足し、3 に戻せば1台だけ壊します。どう変えるかを考えるのは Terraform の仕事で、人間は最終的な形だけを考えればよいのです。
plan — 工事の前に、見積もりを見る
plan は、完成図と今の実物を見比べて差分の見積もりを出します。+ は作る、~ は変える、- は壊す。本番のデータベースを間違って壊すような変更も、工事の前に気づけます。チームでは、この plan の結果をレビューしてから apply するのが定番です。
「誰かが管理画面で web[0] を消す」も押してみてください。コードを変えていないのに、次の plan でweb[0] を作り直す見積もりが出ます。手作業で生まれた実物と完成図のズレ(ドリフト)を、Terraform は完成図に合わせて戻そうとします。完成図がいつも正しい、という前提があるからこそ、手で触らない運用が大事になります。
何回実行しても、同じ街になる
完成図を渡す方式には、もう1つ大きな利点があります。同じコードを何回 apply しても、結果が変わらないことです。図2で、手順を書いたスクリプトと比べてみてください。
create_server web create_server web
resource "aws_instance" "web" {
count = 2
} - IaC
- Infrastructure as Code。サーバーやネットワークの構成をコードとして書き、管理すること。
- Terraform
- 完成図(HCLというコード)を渡すと、クラウド上の実物をその形に合わせてくれる道具。
- 宣言的
- 手順ではなく「最終的にどうなっていてほしいか」を書くスタイル。
- plan / apply
- plan は差分の見積もりを出すだけ。apply はその見積もりを実行する。
- state
- Terraform が「自分が作ったもの」を覚えておく台帳ファイル。コードと実物を結びつける。
- ドリフト
- 手作業などで、実物がコードの完成図からずれてしまうこと。
まとめ
IaCは、インフラを完成図のコードで持つやり方です。Terraform は完成図と実物を見比べ、plan で差分の見積もりを見せ、apply で差分だけを工事します。何回実行しても同じ街になり、手作業のズレも元に戻せる。コードなので、レビューもでき、履歴も残ります。