最終更新:

Terraformの仕組み — 「こうしたい」を書き、差分を確かめる


書いた状態と、適用した状態は別

設定:ひよこ望む状態を書くplan:変更案を確認apply:適用して記録
本文はterraform_dataだけの練習です。クラウドの例ではProviderから実物も読み、Stateに管理対象との対応を記録します。
ひよこ ひよこ
Terraformの仕組みを、クラウドの契約なしで試せる?
ペンギン先生 ペンギン先生
試せるよ。今回はterraform_dataに「ひよこ」という値を持たせる小さな例にしよう。クラウドのサーバーは作らず、設定した値をStateへ記録して、差分を見るんだ。
ひよこ ひよこ
設定を書くと、すぐ変更されるの?
ペンギン先生 ペンギン先生
書いただけでは変わらないよ。initで準備し、planで変更案を確認してからapplyする。plan単独では提案した作成や変更を実行しないんだ。
ひよこ ひよこ
Stateは、クラウドの現状そのもの?
ペンギン先生 ペンギン先生
設定のresourceと実物のIDなどを結び付ける記録だよ。通常のplanはProviderを通じて管理対象の実物を読み、記録を更新して差分を考える。Stateだけを見て、常に現状と同じだとは判断できないね。
ひよこ ひよこ
Providerって何をするの?
ペンギン先生 ペンギン先生
サービスのAPIなどとやり取りする担当だよ。AWSやAzureなどに応じたProviderを選ぶ。今回は外部Providerの設定を要しない組み込みのterraform_dataを使うので、クラウド認証は不要だよ。
ひよこ ひよこ
HCLでは繰り返しが書けないの?
ペンギン先生 ペンギン先生
望む状態を宣言する書き方だけど、複数のリソースにはcountやfor_each、値の加工には式も使えるよ。普通のプログラムの行順を、そのまま実物の作成順にする仕組みではないんだ。
ひよこ ひよこ
チームで同時に変更すると困るよね?
ペンギン先生 ペンギン先生
共有するStateと、対応するバックエンドのロックを使うよ。S3バックエンドはuse_lockfile = trueでロックを有効にできる。DynamoDBを使う旧方式は非推奨だね。ロックの対応や有効化はバックエンドごとに確認しよう。
ひよこ ひよこ
planを見れば、何が起きても安全?
ペンギン先生 ペンギン先生
確認は大切だけど保証ではないよ。削除や置き換え、権限、費用、対象環境を確かめる。実行中に失敗すれば途中まで変更される場合もあるし、前のコードに戻すだけで全変更が自動で巻き戻るわけではないんだ。
ひよこ ひよこ
まず何を覚えればよい?
ペンギン先生 ペンギン先生
望む状態を書く、差分を読む、適用する、対応を記録する、のつながりだね。小さな例で新規作成と変更なしを比べよう。Stateや保存したplanには秘密が含まれる場合があり、公開Gitへ入れないことも大切だよ。

まず、名前の記録で動きを確かめる

Terraformを公式のインストール案内で用意し、terraform versionを確認します。次はTerraform 1.4以降の組み込みリソースを使う練習です。新しい空フォルダーにmain.tfを作ります。既存のクラウド用プロジェクトでは実行しません。

resource "terraform_data" "name" {
  input = "ひよこ"
}

output "name" {
  value = terraform_data.name.output
}
terraform init
terraform plan
terraform apply

planでは1件の作成案を読みます。applyは確認してyesを入力すると、ローカルのStateに記録されます。この例にはクラウドリソースの作成や外部コマンドの実行はありません。もう一度terraform planを実行し、変更がないことを確認しましょう。

次にinputを"ペンギン"へ変えると、planに値の変更が現れます。編集したことと、適用したことは別です。この違いをつかめれば、実際のインフラの差分も読み始められます。

設定、記録、実物を分けて考える

要素役割小さな例
設定望む状態を書く名前をひよこにする
State設定と管理対象の対応・属性を記録適用した名前の記録
Provider実物への読み取りや変更を担当今回は組み込みリソース
plan変更案を作る作成・更新・削除など
apply案に従い適用する確認後に記録を作る

クラウドの例では、通常のplanは管理対象の実物を読んでから設定と比べます。手作業で作った全資源が自動で管理対象になるわけではありません。既存資源は取り込み方や管理範囲を確かめます。

チームで使うときの入口

Stateを別々に持つと、同じ実物を別の記録から変更してしまうおそれがあります。共有State、対応バックエンドのロック、権限、復旧できる保管を整えます。S3のuse_lockfileは既定で無効なので、S3を選んだだけでロックまで有効とは思わないでください。

秘密をsensitiveで画面上から隠しても、Stateや保存したplanには残る場合があります。保管先と権限を確認し、公開リポジトリに含めないようにします。

もう少し詳しく:順序と失敗

Terraformは依存関係を使って処理を進めます。モジュールは設定をまとめる単位で、複数環境へ再利用できますが、入力・Provider・権限が違えば結果も変わります。applyの失敗は、データベースの一括ロールバックと同じではありません。差分と現在の状態を読み直して対処します。

ペンギン先生のまとめ

「Terraform」って出てきたら「こうしたいを書いて、差分を見てから適用する」と思えばだいたいOK! Terraform入門で、計画を読む練習を続けましょう。

参考資料