Terraformで書いて・確かめて・作って・消すまでを通しでやってみよう(総合演習)

terraform versionで本体とプロバイダの版を確かめたら、まずterraform initです。

これを済ませるまで、他のコマンドは全部失敗します。試しに先にterraform planを打つとCould not load pluginと返ってきます。

initが何をしているのか。設定ファイルを読んで「AWSを使うと書いてあるな」と判断し、AWS用のプロバイダ(部品)をダウンロードして.terraform/に置きます。Terraform本体はクラウドの操作方法を知らず、プロバイダが実際の通信を担当する——この分担があるから、同じTerraformでAWSもGCPも扱えます。

initを打ち直す場面は決まっています。プロバイダを追加したとき、版を変えたとき、モジュールを足したとき、そして誰かのリポジトリを最初にcloneしたときです。.terraform/はgitに入れないのが普通なので、cloneした直後は必ずinitからになります。

terraform providersで、この設定が必要としているプロバイダとその版の条件が読めます。~> 5.0は「5系の最新を使うが、6系には上げない」という意味です。版を固定しておかないと、ある日突然プロバイダが上がって挙動が変わります——チームで使うときは必ず範囲を指定します。

いきなりapplyせず、3段階で確かめます。この順番には意味があります。

terraform fmtはインデントや空白を公式の書式に整えるコマンドです。何も表示されなければ、直すところが無かったということ——整えたファイルがあれば、その名前が並びます。

見た目の話に見えて、実は差分の話です。書式がばらばらだと、中身を変えていない行まで差分に出て、レビューで本当の変更が埋もれます。だからチームではfmtを保存時に自動で走らせます。

terraform validateは文法と型の検査です。閉じ括弧の抜け、存在しない属性名、型の食い違いを見つけます。クラウドには一切問い合わせません——だから一瞬で終わり、認証情報も要りません。

そしてterraform plan。これがTerraformの心臓です。設定ファイルと現在の状態を突き合わせて、差を埋めるために何をするつもりかを全部見せてくれます。

読み方は記号です。+が作成、-が削除、~が変更、-/+が作り直し。最後の行のPlan: 2 to add, 0 to change, 0 to destroyが要約です。

-/+(作り直し)を見たら、必ず手を止めてください。設定を1文字変えただけのつもりが、サーバーをいったん削除してから作り直す計画になっていることがあります。中のデータは消えます。本番で起きる事故の多くは、この行を読み飛ばしたときに起きます。

terraform plan -out=tfplanで、計画をファイルに保存します。そしてterraform apply tfplanで、その保存した計画を実行します。

なぜわざわざ2段階にするのか。引数なしのterraform applyは、その場でもう一度planを作り直して、yesと打たせてから実行します。つまり、あなたが確認した計画と、実際に実行される計画は「別物」です。

ふだんは同じ結果になります。ただし、確認してから実行するまでの間に誰かが手で何かを変えていたら、違う計画が走ります。「レビューでは何も消えないはずだったのに、本番では消えた」——これが起きる仕組みです。

-outで保存した計画には、実行する内容がそのまま固定されています。だからapply tfplanは確認を聞いてきません。聞く必要が無いからです——中身は既にあなたが読んだものと同一だと保証されています。

チームで運用するときの定番がこれです。CIがplan -outを実行して結果をレビューに出し、承認されたらそのまったく同じファイルをapplyする。人が見たものと実行されるものが一致します。

実行するとCreating...からCreation completeまで流れ、最後にApply complete! Resources: 2 added。この時点で、Terraformはterraform.tfstateに「何を作ったか」を記録しています。次のステップで、その中身を見ます。

terraform state listで、Terraformが管理しているリソースの一覧が出ます。aws_instance.webとaws_s3_bucket.dataの2つです。

ここでstate(状態ファイル)の役割をはっきりさせておきます。Terraformはterraform.tfstateに「設定ファイルのこの記述が、クラウド上のこのIDに対応する」という対応表を書いています。この対応表があるから、2回目のapplyで同じサーバーがもう1台できたりしないのです。

terraform showは、その中身を人が読める形で表示します。state listが名前だけの一覧なのに対し、showは各リソースの属性まで出します。実際に割り当てられたIDやIPは、ここで確かめます。

terraform outputは設定ファイルでoutputと宣言した値だけを取り出します。IPアドレスやバケット名——作ったあとで人や別のツールが必要とする値を、ここに出しておきます。

-jsonを付けると機械が読める形になるので、デプロイスクリプトに繋ぐときはこれを使います。

stateファイルは絶対にgitに入れないでください。データベースのパスワードなど、設定ファイルに書いた秘密がそのまま平文で入っています。チームで使うならS3などのリモートバックエンドに置き、同時に2人がapplyしないようロックを掛けます——同時に走ると、対応表が壊れます。

同じ構成の環境を、本番と検証で2つ持ちたいとします。設定ファイルをコピーするのは最悪の手です——片方だけ直し忘れて、いつのまにか別物になります。

terraform workspace new stagingで、同じコードのまま、state だけを別にした環境を作れます。

ここを自分の目で確かめてください。切り替えた直後にterraform state listを打つと——何も出ません。default で作った2つのリソースは、staging からは見えないのです。

これがワークスペースの正体です。設定ファイルは1つ、state はterraform.tfstate.d/staging/に分かれて置かれます。コードは共有し、実体は分ける。だから片方だけ直し忘れる、ということが起きません。

terraform workspace select defaultで戻ると、2つのリソースがちゃんと戻ってきます。workspace listの*が、いまどちらにいるかを示しています。

いまどのワークスペースにいるかを、applyの前に必ず確かめてください。ワークスペースの切り替えはプロンプトに表示されません。本番のつもりで検証を消した、検証のつもりで本番を消した——どちらも実際に起きています。terraform workspace listを打つ習慣が、いちばん確実な予防です。

なおワークスペースが向くのは「ほぼ同じ構成の環境」までです。本番と検証でサーバーの台数や構成そのものが違うなら、フォルダを分けたほうが素直になります。

terraform refreshは、実際のクラウドに問い合わせて、state を現実に合わせ直すコマンドです。

なぜズレるのか。誰かが管理画面から手でサーバーの設定を変えると、クラウドの実物と Terraform の対応表が食い違います。これをドリフトと呼びます。refreshすると state が実物に合わせて更新され、次のplanで「戻すために何をするか」が出てきます。

Terraformを使い始めたら、手で触るのをやめる——面倒に見えて、これが結局いちばん安全です。手を入れた場所は必ずどこかで食い違います。

そしてterraform destroy。この設定で作ったものを、全部削除します。

「全部」の範囲を正確に言うと、いま選んでいるワークスペースの state に載っているもの全部です。だからステップ5の注意がここに効いてきます——打つ前にterraform workspace listで、自分がどこにいるか確かめてください。

destroyもplanと同じで、実行前に消える対象を全部見せてからyesを求めます。その一覧を読まずにyesと打たない——これだけで、ほとんどの事故は防げます。

最後にterraform state listを打つと何も出ません。terraform planを打つとまた2 to add——設定ファイルは残っているので、applyすればいつでも同じものが作り直せます。

これがコードでインフラを書く意味です。作ったものは消してよい。必要になったら、同じコードから同じものが出てくる。「あのとき何を設定したか」を思い出す必要が、もうありません。

ページ下の疑似ターミナルで、ここまでを最初から自分の手で通してみてください。特にplanを読む癖は、打った回数だけ身につきます。

下は本物の疑似ターミナルです。まっさらな状態から始まるので、STEP1のコマンドから順に打って、マージまで辿り着いてください。読んで分かった気になるのと、自分で打てるのとは別物です。

詰まったら上のステップに戻って構いません。resetと打てば最初からやり直せます。