Terraformのstateを管理する方法

編集者注： この記事はもともと CloudSkiff.comに掲載されました。 CloudSkiffは 2021年10月にSnykに加わりました。

Terraformのstateを管理するには？そもそもTFStateファイルとは何でしょうか？TFStateファイルによってTerraformのコードはほかの構成管理ツールとどう異なるのでしょうか？また、どのようなベストプラクティスがあるのでしょうか？

Terraformのstateを管理するには？

Terraformのstateを管理する方法を知ることは重要です。まず、TFStateとは何でしょうか？

TerraformのTFStateファイルは、Terraformをほかのシステムと大きく異なるものにしています。Chef、Saltstack、Ansibleなどの構成管理ツールでもインフラを構築・起動できますが、Terraformとの最大の違いは、このstateにあります。

TFStateファイルは、インフラの実態を表す大きなJSON構造として捉えることができます。Terraformコードと連携し、実現したい、いわゆる「望ましい状態」を宣言します。

この望ましい状態は宣言型です。コード内で特定の構成を持つ特定のリソースが必要だと宣言し、そのコードをapplyすると、TerraformはクラウドプロバイダーのAPIとやり取りして、必要なリソースをすべて作成します。完了すると、クラウドプロバイダー側でのデプロイの実態を、このJSONファイルに書き込みます。

最終的には、次の3つの要素が存在します。

• コード

• クラウドプロバイダーのアカウント上の実態

• stateファイル

stateファイルは、コードの最後に成功したapplyの状態をそのまま反映したものです。あらゆる種類のリソースで機能します。つまり、インフラリソースの起動に関心があるならクラウドプロバイダーで使えますし、あらゆる種類のプロバイダーでも利用できます。

TerraformでHelmチャートをデプロイするとしましょう。その場合、デプロイのstateファイルも作成されます。GitHubも同様です。GitHubプロバイダーを使ってユーザーを定義し、同じユーザーがGoogle CloudのプロジェクトとAWSのIAMでGitHubユーザーとして使われている場合、そのユーザーに関する情報が出力され、すべてTerraformのstateファイルに紐づけられます。

コード内から参照できる、既存インフラの実態を示す基準として考えてください。

つまりstateファイルとは、Terraformコードで宣言した意図に基づく、クラウドプロバイダー上のデプロイの実態です。

Terraformのstateはどのように扱い、どこに保存すればよいのでしょうか？

デフォルトでは、保存先の選択肢はありません。Terraformコードを使ってGitリポジトリを初期化し、簡単なTerraformコードを初めて適用すると、TFStateはGitHubリポジトリのルートに直接作成されます。どこかに保存する必要があります。デフォルトのままGitHubにプッシュしたくなるかもしれません。実際、多くの人がそうしています。しかし、stateファイルにはシークレットが含まれる可能性があるため、GitHubにシークレットをプッシュしたくない場合は、これはベストプラクティスとは言えません。

それでもstateファイルは保存する必要があります。保存しないと、Terraformが「既存のインフラ」と認識しているものを失ってしまいます。削除して再度applyを実行すると、インフラ全体を「新規」としてもう一度適用しようとするため、これは避けたいはずです。

ベストプラクティスは、Amazon S3バケットなど、AWS、Azure、Google Cloud上のストレージバケットに共有して保存することです。

1resource "aws_instance" "vm" {
2  ami                    = data.aws_ami.amazon-linux.id
3  instance_type          = var.instance_type
4  tags = {
5    Name = "DEMO VM DESTROY ME - ${terraform.workspace}",
6    Terraform = "true"
7  }
8}
9
10data "aws_ami" "amazon-linux" {
11  most_recent = true
12  owners = ["amazon"]
13
14  filter {
15    name   = "name"
16    values = ["amzn-ami-hvm-*"]
17  }
18
19}

基本的には、バックエンドを宣言します。この例は、単一のVMをデプロイする非常にシンプルなコードです。デモ用で、Terraformのワークスペースを試したりテストしたりするために使っています。大規模な作業には使わないでください。

Terraformのキーワードを使って設定し、「TerraformのバックエンドにはS3を使い、S3のバケットはこれにする」と指定できます。

stateファイルの保存先を指定します。これだけです。次回Terraform applyを実行すると、Terraformは一時的なstateファイルをローカルで使った後、S3バケットにアップロードします。

以降、作業するたびにこのファイルが使われます。

1terraform {
2  backend "s3" {
3    bucket = "cs-tfstates-demo-sj-frankfurt-1"
4    key    = "tfstates/terraform.tfstate"
5  }
6}

最後に、データベースにロックファイルを追加することも忘れないでください。ロックが存在すれば、2人が同時に破壊的な操作を開始したり、Terraformを同時にapplyしたりするのを防げます。

Terraformコードをセキュリティで保護する

Snyk IaCなら、Terraformの設定（Kubernetes、CloudFormation、ARMテンプレートも！）をコーディング中に保護し、ガイド付き修正を提案するため、安心してマージして次に進めます。記述しながらテストできるほか、Gitリポジトリの変更を監視し、デプロイ前にビルドパイプラインでテストを自動化できます。無料プランなら数分で使い始められます。一方、IaCの設定ミスによる侵害は、長く続く被害を招く可能性があります。以下から登録して、設定の保護を始めましょう。