翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

バックエンドのベストプラクティス

適切なリモートバックエンドを使用してステートファイルを保存することは、コラボレーションの有効化、ロックによるステートファイルの整合性の確保、信頼性の高いバックアップとリカバリの提供、CI/CD ワークフローとの統合、HCP Terraform などのマネージドサービスが提供する高度なセキュリティ、ガバナンス、管理機能の利用に不可欠です。

Terraform は、Kubernetes、 HashiCorp Consul、HTTP などのさまざまなバックエンドタイプをサポートしています。ただし、このガイドでは、ほとんどの AWS ユーザーに最適なバックエンドソリューションである Amazon S3 に焦点を当てています。

高い耐久性と可用性を提供するフルマネージドオブジェクトストレージサービスである Amazon S3 は、 で Terraform 状態を管理するための安全でスケーラブルな低コストのバックエンドを提供します AWS。Amazon S3 のグローバルフットプリントと耐障害性は、ほとんどのチームがステートストレージを自己管理することで達成できる範囲を超えています。さらに、 AWS アクセスコントロール、暗号化オプション、バージョニング機能、その他のサービスとネイティブに統合されているため、Amazon S3 は便利なバックエンドの選択肢になります。

このガイドでは、Kubernetes や Consul などの他のソリューションのバックエンドガイダンスは提供していません。主なターゲットオーディエンスは AWS 顧客であるためです。に完全に属しているチームの場合 AWS クラウド、Amazon S3 は通常、Kubernetes クラスターまたは HashiCorp Consul クラスターよりも理想的な選択肢です。Amazon S3 ステートストレージのシンプルさ、耐障害性、および緊密な AWS 統合により、 AWS ベストプラクティスに従うほとんどのユーザーに最適な基盤が提供されます。チームは、 AWS サービスの耐久性、バックアップ保護、可用性を活用して、リモートの Terraform の状態を高い回復力を維持できます。

このセクションのバックエンドの推奨事項に従うことで、エラーや不正な変更の影響を制限しながら、より協調的な Terraform コードベースが可能になります。適切に設計されたリモートバックエンドを実装することで、チームは Terraform ワークフローを最適化できます。

リモートストレージに Amazon S3 を使用する

Amazon DynamoDB を使用して Terraform 状態をリモートで Amazon S3 に保存し、状態ロックと整合性チェックを実装すると、ローカルファイルストレージよりも大きな利点があります。リモート状態により、チームのコラボレーション、変更追跡、バックアップ保護、リモートロックが可能になり、安全性が向上します。

エフェメラルローカルストレージまたはセルフマネージドソリューションの代わりに Amazon S3 を S3 標準ストレージクラス (デフォルト) で使用すると、99.999999999% の耐久性と 99.99% の可用性保護が提供され、偶発的な状態データ損失を防ぐことができます。Amazon S3 や DynamoDB などの AWS マネージドサービスは、ほとんどの組織がストレージを自己管理する際に達成できる範囲を超えるサービスレベルアグリーメント (SLAsを提供します。リモートバックエンドへのアクセスを維持するには、これらの保護に依存します。

リモート状態ロックを有効にする

DynamoDB ロックは、同時書き込み操作を防ぐために状態アクセスを制限します。これにより、複数のユーザーからの同時変更が防止され、エラーが軽減されます。

状態ロックを使用したバックエンド設定の例：

terraform {
  backend "s3" {
    bucket         = "myorg-terraform-states"
    key            = "myapp/production/tfstate"
    region         = "us-east-1"
    dynamodb_table = "TerraformStateLocking"
  }
}

バージョニングと自動バックアップを有効にする

追加の保護のために、Amazon S3 バックエンド AWS Backup で を使用して自動バージョニングとバックアップを有効にします。 Amazon S3 バージョニングは、変更が行われるたびに、以前のすべてのバージョンの 状態を保持します。また、不要な変更をロールバックしたり、事故から回復したりするために、必要に応じて以前の動作状態のスナップショットを復元することもできます。

必要に応じて以前のバージョンを復元する

バージョニングされた Amazon S3 ステートバケットを使用すると、以前の既知の正常な状態のスナップショットを復元することで、変更を簡単に元に戻すことができます。これにより、偶発的な変更から保護し、追加のバックアップ機能が提供されます。

HCP Terraform を使用する

HCP Terraform は、独自のステートストレージを設定する代わりに、フルマネージド型のバックエンドを提供します。HCP Terraform は、追加の機能のロックを解除しながら、状態と暗号化の安全なストレージを自動的に処理します。

HCP Terraform を使用すると、状態はデフォルトでリモートに保存されるため、組織全体で状態の共有とロックが可能になります。詳細なポリシーコントロールは、状態アクセスと変更を制限するのに役立ちます。

その他の機能には、バージョン管理統合、ポリシーガードレール、ワークフロー自動化、変数管理、SAML とのシングルサインオン統合などがあります。Sentinel ポリシーをコードとして使用してガバナンスコントロールを実装することもできます。

HCP Terraform では Software as a Service (SaaS) プラットフォームを使用する必要がありますが、多くのチームにとって、セキュリティ、アクセスコントロール、自動ポリシーチェック、コラボレーション機能の利点により、Amazon S3 または DynamoDB を使用した自己管理状態ストレージよりも最適な選択肢となります。

また GitHub 、 や などのサービスとの簡単な統合 GitLab や、マイナーな設定により、クラウドや SaaS ツールを完全に活用してチームワークフローを改善するユーザーにとっても魅力的です。

チームコラボレーションの円滑化

リモートバックエンドを使用して、Terraform チームのすべてのメンバー間で状態データを共有します。これにより、チーム全体にインフラストラクチャの変更を可視化できるため、コラボレーションが容易になります。共有バックエンドプロトコルと状態履歴の透明性を組み合わせることで、内部変更管理が簡素化されます。インフラストラクチャの変更はすべて確立されたパイプラインを経由するため、企業全体のビジネスの俊敏性が向上します。

を使用して説明責任を改善する AWS CloudTrail

Amazon S3 バケット AWS CloudTrail と統合して、ステートバケットに対して行われた API コールをキャプチャします。CloudTrail イベントをフィルタリングしてPutObject、 DeleteObject,およびその他の関連する呼び出しを追跡します。

CloudTrail ログには、状態変更の各 API コールを行ったプリンシパルの AWS ID が表示されます。ユーザーの ID は、マシンアカウントまたはバックエンドストレージを操作するチームのメンバーと照合できます。

CloudTrail ログと Amazon S3 ステートバージョニングを組み合わせて、インフラストラクチャの変更を適用したプリンシパルに関連付けます。複数のリビジョンを分析することで、マシンアカウントまたは担当チームメンバーに更新を関連付けることができます。

意図しない変更や破壊的な変更が発生した場合、ステートバージョニングはロールバック機能を提供します。 は変更をユーザーに CloudTrail 追跡するため、予防的改善について議論できます。

また、IAM アクセス許可を適用してステートバケットへのアクセスを制限することもお勧めします。全体として、S3 バージョニングと CloudTrail モニタリングは、インフラストラクチャの変更全体の監査をサポートします。チームは、Terraform の状態履歴に対する説明責任、透明性、監査機能を改善できます。

環境ごとにバックエンドを分離する

アプリケーション環境ごとに個別の Terraform バックエンドを使用します。バックエンドは、開発、テスト、本番稼働の間で分離状態を分離します。

影響範囲の縮小

状態を分離することで、より低い環境の変化が本稼働インフラストラクチャに影響を与えないようにできます。開発環境やテスト環境におけるインシデントや実験の影響は限られています。

本番稼働用アクセスの制限

本番稼働状態のバックエンドのアクセス許可を、ほとんどのユーザーの読み取り専用アクセスにロックダウンします。本番稼働用インフラストラクチャを変更できるユーザーを CI/CD パイプラインに制限し、グラスロールを破棄します。

アクセスコントロールの簡素化

バックエンドレベルでアクセス許可を管理すると、環境間のアクセスコントロールが簡素化されます。アプリケーションと環境ごとに異なる S3 バケットを使用すると、バックエンドバケット全体に幅広い読み取りまたは書き込みアクセス許可を付与できます。

共有ワークスペースを避ける

Terraform ワークスペースを使用して環境間で状態を分離することはできますが、個別のバックエンドを使用すると、より強力な分離が可能になります。ワークスペースを共有している場合、インシデントは引き続き複数の環境に影響を与える可能性があります。

環境バックエンドを完全に分離しておくことで、1 回の障害や違反の影響を最小限に抑えることができます。個別のバックエンドも、アクセスコントロールを環境の機密性レベルに合わせます。例えば、本番環境の書き込み保護と、開発環境とテスト環境の広範なアクセスを提供できます。

リモート状態のアクティビティを積極的にモニタリングする

潜在的な問題を早期に検出するには、リモート状態のアクティビティを継続的にモニタリングすることが重要です。異常なロック解除、変更、またはアクセス試行がないか探します。

不審なロック解除に関するアラートを受け取る

ほとんどの状態変更は、CI/CD パイプラインを介して実行する必要があります。状態のロック解除がデベロッパーワークステーションを介して直接発生すると、未許可またはテストされていない変更を通知する可能性のあるアラートを生成します。

アクセス試行のモニタリング

ステートバケットでの認証の失敗は、偵察アクティビティを示している可能性があります。複数のアカウントが 状態にアクセスしようとしているか、異常な IP アドレスが表示されて、認証情報が侵害されたことを示します。