Terraformではじめてリソースつくる時に見てる資料とか
はじめに
Terraformでコード化していく時どう書き進めているかを共有します。
- 書く：見てる資料、どういう時に見ているか
- 書かない：HCLの文法、関連ファイルの構成管理
ステップ
アーキテクチャ（使いたいサービス）が決まり、いざ書く段になると次に挙げる確認作業を必要に応じて実施します。
terraform applyが正常に終了しリソースが目的の状態になるまで繰り返し確認します。
- サービスのドキュメントを読む
ex) https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/concepts.html - Terraform Registryのドキュメントを読む
ex) https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/instance - サービスのAPIリファレンスを読む
ex) https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_GetPasswordData.html -
terraform importしてみる
ex) https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/instance#import
サービスのドキュメントを読む
使いたいサービスの仕様を公式ドキュメントで確認します、
設定項目や依存する他のリソースを把握します。
Webコンソールから実際にリソース手順を実施すると、必須・重要な項目が捉えやすいです。
CLIでの作成コマンドは、オプション名がそのままTerrraformで記述する項目名になっていたり、必要なロールや関連リソースを作成する手順も併記されていたりと、Terraformのコードに起こしやすいです。
Terraform Registryのドキュメントを読む
tfファイルの具体的な書き方は、Terrafomのプロバイダのドキュメントを確認します。
AWSやGCPなどプロバイダごとに公開されています。
使いたいサービスのページを見つけ、サンプルやリファレンスを確認します。
同じ名前のリソースがResourcesとData Sourcesに存在する場合、以下の違いがあります。
- Resources：プロジェクト（Workspace）内でで作成・管理する時に使う構文
- Data Sources：既存で参照したい時に使う構文
google_compute_global_network_endpointとgoogle_compute_network_endpointなど、似た名前の違うリソースも存在します。
これらは公式ドキュメントやWebコンソールでは同じサービスとして扱われていて、1つの設定項目として見えている場合があります。
サービスのAPIリファレンスを読む
設定項目の値に何を書けばいいかわからないときは当該サービスのAPIリファレンスを確認します。
Terraform Registryのドキュメントからリンクされていることもあります。
値の形式や取りうる範囲など把握します。
terraform importしてみる
ドキュメントを読んだけど変更したい設定に該当するTerraformの項目がわからない時や、クラウド・プロバイダの推奨する設定で作成したい時があります。その場合、WebコンソールやCLIで作成した後にterraform importによりtfstateに取り込みます。他のリソースのURIを含む場合はそのリソースもインポートします。
その後tfstateからtfファイルに値を転記していきます。terraform planで差分がなくなるようにします。
参照関係の整理や変数化をする、扱いやすいようにmodule化するなど検討します。
インポートができないリソースも存在するため注意が必要です。
Discussion