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

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

適切なリモートバックエンドを使用してステートファイルを保存することは、コラボレーションの有効化、ロックによるステートファイルの整合性の確保、信頼性の高いバックアップとリカバリの提供、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 Standard ストレージクラス (デフォルト) で使用すると、99.999999999% の耐久性と 99.99% の可用性保護を実現し、偶発的な状態データ損失を防止できます。Amazon S3 や DynamoDB などの AWS マネージドサービスは、ほとんどの組織がストレージを自己管理する際に達成できる範囲を超えるサービスレベルアグリーメント (SLAs) を提供します。リモートバックエンドにアクセスできるようにするには、これらの保護に依存します。

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

ステートロックは、同時書き込み操作を防ぐためにアクセスを制限し、複数のユーザーによる同時変更によるエラーを減らします。Terraform は、Amazon S3 バックエンドの 2 つのロックメカニズムをサポートしています。

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

移行中の下位互換性のために、Amazon S3 と DynamoDB の両方のロックを同時に設定できます。ただし、DynamoDB ベースのロックは廃止されているため、Amazon S3 ネイティブロックに移行することをお勧めします。

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

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

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

バージョニングされた 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 パイプラインに制限し、Break Glass ロールを制限します。

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

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

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

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

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

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

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

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

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

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

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