TFの
Terraformの「TFstate」ファイル扱いのグッドプラクティス
お世話になります。
Zennで初めての記事の管理ですから、変な日本語とかあれば申し訳ございませんです。
今日は自分の経験で今まで感じてたTerraform管理のグッド プラクティス
についてちょっと話したいです。
よろしくね。
対象者
- Terraformについてもっと知りたい人。
- 他の人のTerraformの使い方を知りたい人。
- IaCについて知りたい人。
まずは「IaC」と「Terraform」って何？
IaC「Infrastructure as Code」はシステムのインフラ「サーバー、ネットワークなど」をコードで構築のことです。
クラウド環境で動いてるシステムスですごく使われてるトレンドです。
TerraformはIaCの一つのツールであり、現在の開発世界で一番使われてるIaCツールだと個人的に思います。
説明は短かったですが、もっと情報を知りたかったらHashicorpのサイトでもっと詳しい説明ありますので必ずチェックしてください。
Hashicorp
それでは、今日の説明に：
今日は自分の経験でTFstateの扱い方について主に４つのグッドプラクティスを話したいです。
この４つのグッドプラクティスは多分当たり前のことだと思うかもしれませんがそれでも意識しながら稼働することは大事だと思って書きました。
TFstateとは？
TFstate は、あるシステムの現在で使われてるインフラサービスのリストとなります、TFstateはJSON系のファイルです。
TerraformのコマンドでApplyする時にローカル環境でTFstateは作られます。
Terraformの変更をApplyする時にTFstateファイルも自動で変更されます。
例：
{
"version": 1,
"terraform_version": "1.14",
"serial": 1,
"lineage": "86452065-5739-4aa5-e8e1-a1a753de43d1",
"outputs": {},
"resources": [
{
"mode": "managed",
"type": "aws_instance",
"name": "example",
"provider": "provider[\"registry.terraform.io/...\"]",
}
]
}
なお、自分の経験でTFstateファイルはこんな感じで扱いしたほうがいいと思ってます。
TFstateはできるだけ直接変更しなこと。
TFstateの中にはクラウド環境で使われてるすべてのデータが含まれてますので下手な使い方すると、重要なサービスを消したり、要らないサービス追加したりしてシステムや会社の状態に大きな影響を与える可能性があります。
代わりに、インフラの変更する時terraform CLI「terraform Plan・terraform Apply」の使用に集中し、変更を確定する時に必ずterraformのプラン結果変更を確認すること。
TFstateを1つの共有ストレージに保存
チームで作業してる時には、知ってる通り、アプリ開発と同じくチームメンバーは同じリポシトリーでの変更は行う。チームでTerraformを変更してる時にはメンバーそれぞれローカルTFstateで働いてたら、各メンバーのTFstateで差分が必ず出ますのでインフラの問題起こる可能性は高くなります。
代わりに、ローカルではなく、同じクラウド環境でTFstateを保存して、Terraform変更する時にそのストレージにアクセス仕組みを作るとインフラ変更の流れはもっと安全となります。
TFstateを環境ごとで分けること
「Simple is best」って諺はシステム開発にピッタリ合うと思います。
分かりやすいシステムインフラを作るためちゃんと整理されてるインフラコードは必要です。そのために１つの手段はTFstateのファイルを環境ごとで切り分けること。
TFstateをバックアップすること
TFstateファイルには大事だともうわかっております。なら、万が一のケースでTFstateは変更、破損、削除とかされたらバックアップをとってあればある程度の良い状況まで戻せることができます。その頻度をシステムのニーズに基づいて決めるといいです。
結論
IaC・Terraformはすごく便利でパワーフルツールとなることであります。しかし間違い扱いすると問題起こす可能性は高いのでこれからインフラコードでシステムのインフラを作る時にはその４つのグッドプラクティスを意識しながら稼働しましょう。
他のアイデアとか、異なる意見とかあればぜひコメントお願いします。
Discussion