Terraform の状態とバックエンドについて

Infrastructure as Code (IaC) における最も重要な概念の 1 つは、状態 の概念です。IaC サービスは 状態を維持します。これにより、デプロイするたびにリソースを再作成することなく、IaC ファイル内のリソースを宣言できます。IaC ファイルは、デプロイの最後にすべてのリソースの状態を文書化し、その状態を次のデプロイで宣言されたターゲット状態と比較できるようにします。したがって、現在の状態に という名前の Amazon Simple Storage Service (Amazon S3) バケットが含まれmy-s3-bucket、受信する変更にも同じバケットが含まれている場合、新しいプロセスでは、すべての新しいバケットを作成するのではなく、既存のバケットに変更が適用されます。

次の表は、一般的な IaC 状態プロセスの例を示しています。

現在の状態	ターゲットの状態	アクション
という名前の S3 バケットはありません my-s3-bucket	という名前の S3 バケット my-s3-bucket	という名前の S3 バケットを作成する my-s3-bucket
my-s3-bucket バケットのバージョニングが設定されていない	my-s3-bucket バケットのバージョニングが設定されていない	アクションなし
my-s3-bucket バケットのバージョニングが設定されていない	my-s3-bucket バケットのバージョニングが設定されている	バケットmy-s3-bucketのバージョニングを設定する
my-s3-bucket バケットのバージョニングが設定されている	という名前の S3 バケットはありません my-s3-bucket	削除の試行 my-s3-bucket

AWS CloudFormation と Terraform のトラック状態に関するさまざまな方法を理解するには、 内で CloudFormation ホストされている と AWS クラウド Terraform が基本的にリモートであるという 2 つのツールの最初の基本的な違いを覚えておくことが重要です。この事実により、 CloudFormation は内部的に 状態を維持できます。 CloudFormation コンソールに移動して特定のスタックのイベント履歴を表示できますが、 CloudFormation サービス自体によって状態ルールが適用されます。

特定のリソースに対して CloudFormation で動作する 3 つのモードはCreate、、Update、および ですDelete。現在のモードは、前回のデプロイで何が起こったかに基づいて決定され、それ以外の方法では影響されません。決定されたモードに影響を与えるために CloudFormation リソースを手動で更新できますが、「このリソースについては、 Create モードで動作する CloudFormation 」というコマンドを に渡すことはできません。

Terraform は でホストされていないため AWS クラウド、状態を維持するプロセスはより設定可能である必要があります。このため、Terraform の状態は、自動的に生成された状態ファイル内で維持されます。Terraform デベロッパーは、 よりもはるかに直接的に 状態に対処する必要があります CloudFormation。覚えておくべき重要なことは、追跡状態が両方のツールで同じくらい重要であることです。

デフォルトでは、Terraform 状態ファイルは、Terraform スタックを実行するメインディレクトリの最上位にローカルに保存されます。ローカル開発環境から terraform apply コマンドを実行すると、Terraform が状態をリアルタイムで維持するために使用する terraform.tfstate ファイルを生成することがわかります。良い場合も悪い場合も、これにより Terraform の状態を よりもはるかに細かく制御できます CloudFormation。状態ファイルを直接更新しないでくださいが、デプロイ間で状態を更新する Terraform CLI コマンドがいくつか実行できます。例えば、Terraform のインポートでは、Terraform の外部で作成されたリソースをデプロイスタックに追加できます。逆に、Terraform ステート rm を実行することで、 状態からリソースを削除できます。

Terraform が状態をどこかに保存する必要があるという事実は、バックエンド には適用されない別の概念につながります CloudFormation。Terraform バックエンドは、デプロイ後に Terraform スタックがステートファイルを保存する場所です。これは、新しいデプロイが開始されたときに 状態ファイルを検索する場所でもあります。スタックをローカルで実行するときは、前述のように、Terraform 状態のコピーを最上位のローカルディレクトリに保持できます。これはローカルバックエンド と呼ばれます。

継続的インテグレーションおよび継続的デプロイ (CI/CD) 環境向けに開発する場合、ローカル状態ファイルは、バージョン管理の対象外となるように、通常 .gitignore ファイルに含まれます。次に、パイプライン内にローカル状態ファイルは存在しません。正しく動作するためには、パイプラインステージで正しい状態ファイルをどこかで見つける必要があります。 そのため、Terraform 設定ファイルにはバックエンドブロックが含まれていることがよくあります。バックエンドブロックは、状態ファイルを見つけるために独自の最上位ディレクトリのどこかを探す必要があることを Terraform スタックに示します。

Terraform バックエンドは、Amazon S3 バケット 、API エンドポイント、リモート Terraform ワークスペース など、ほぼどこにでも配置できます。 https://developer.hashicorp.com/terraform/language/settings/backends/remoteAmazon S3 バケットに保存されている Terraform バックエンドの例を次に示します。

terraform {
  backend "s3" {
    bucket = "my-s3-bucket"
    key    = "state-file-folder"
    region = "us-east-1"
  }
}

Terraform 設定ファイルに機密情報を保存しないように、バックエンドは部分的な設定もサポートしています。前の例では、バケットへのアクセスに必要な認証情報は設定に存在しません。認証情報は、環境変数から取得することも、 などの他の方法を使用して取得することもできます AWS Secrets Manager。詳細については、「 AWS Secrets Manager と HashiCorp Terraform を使用した機密データの保護」を参照してください。

一般的なバックエンドシナリオは、テスト目的でローカル環境で使用されるローカルバックエンドです。terraform.tfstate ファイルは .gitignore ファイルに含まれているため、リモートリポジトリにプッシュされません。その後、CI/CD パイプライン内の各環境は独自のバックエンドを維持します。このシナリオでは、複数のデベロッパーがこのリモート状態にアクセスできる可能性があるため、状態ファイルの整合性を保護する必要があります。複数のデプロイが実行されていて、状態が同時に更新されている場合、状態ファイルが破損している可能性があります。このため、ローカル以外のバックエンドでは、通常、 状態ファイルはデプロイ中にロックされます。