Terraform：マルチテナントのための状態管理

Question

マルチテナントSaaSのための当社のAnabilitiesプロビジョニングプロセスを（部分的に）置き換えるTerraformの評価が進行中であるため、私たちは扱うことができるようにTerraformの利便性、インフラストラクチャがスムーズに変更（追加/削除）され、インフラストラクチャの状態が追跡されます（非常にクールです）。

私たちのアプリケーションは、私たちが顧客のために別々のインスタンスを提供するマルチテナントSaaSです。我々は独自の動的インベントリを持っています（EC2ダイナミックインベントリと全く同じです）。多くのTerraformの本/チュートリアルやベストプラクティスでは、複数の環境状態をTerraformで個別に&で管理することを推奨していますが、それらはすべて静的なenv（Dev/Staging/Prodなど）のように見えます。

マルチテナントアプリの動的インベントリ管理の管理に関するベストプラクティスまたは実際の例はありますか？私たちは、各顧客セットのインスタンスの状態を追跡して、簡単に変更を入力したいと考えています。

顧客ごとにディレクトリを作成し、* .tfスクリプトを内部に配置する方法があります。このスクリプトは、どこかグローバルにホストされたモジュールを呼び出します。状態ファイルがS3に置かれる可能性があるので、必要に応じて個々の顧客に変更を加えることができます。

Answer 1

あなたの提案されたアプローチは私には正しいと思っていますが、あなたがやりたいことがいくつもあります。

はバージョン管理アーティファクト（例えばためのGitのレポ、）として、元のテラフォームテンプレート（下のツリーで_template）を維持し、ちょうどあなたのインフラストラクチャを再作成できるようにするのKey-Valueプロパティを渡します。この方法では、ディレクトリに配置されたTerraform設定コードを貼り付けたコピーの量が非常に少なくなります。

これは、それがどのように見えるかです：

/tf-infra 
├── _global 
│   └── global 
│    ├── README.md 
│    ├── main.tf 
│    ├── outputs.tf 
│    ├── terraform.tfvars 
│    └── variables.tf 
└── staging 
    └── eu-west-1 
     ├── saas 
     │   ├── _template 
     │   │   └── dynamic.tf.tpl 
     │   ├── customer1 
     │   │   ├── auto-generated.tf 
     │   │   └── terraform.tfvars 
     │   ├── customer2 
     │   │   ├── auto-generated.tf 
     │   │   └── terraform.tfvars 
... 

二ヘルパースクリプトが必要です。

1. テンプレートのレンダリング。使用のいずれかsedはmodule's source attributeを生成したり（例えばそれがairbnb/streamalertで行われるように）

2. ラッパースクリプトを、より強力なツールを使用しています。通常は実行terraform -var-file=...で十分です。他の層は、それらにアクセスできるように、グローバルでなければなりません十分なリソース（ディレクトリ上記_global）としてテラフォームの状態のファイルを共有

は、S3に保存することができます。

PS：これは上で動作するように興味深い作業ですので、私は、非常にオープンな提案された解決策のコメントの午前:)テラフォームがすべて.tfファイルに引っ張って、フォルダレベルで動作

Answer 2

（とすることによりデフォルトはterraform.tfvarsファイル）。

私たちはAntonのanswerと似たようなことをしますが、sedを使ってテンプレートを使用すると複雑になりません。だから、基本的な例として、あなたの構造は次のようになります。ここでは

$ tree -a --dirsfirst 
. 
├── components 
│   ├── application.tf 
│   ├── common.tf 
│   ├── global_component1.tf 
│   └── global_component2.tf 
├── modules 
│   ├── module1 
│   ├── module2 
│   └── module3 
├── production 
│   ├── customer1 
│   │   ├── application.tf -> ../../components/application.tf 
│   │   ├── common.tf -> ../../components/common.tf 
│   │   └── terraform.tfvars 
│   ├── customer2 
│   │   ├── application.tf -> ../../components/application.tf 
│   │   ├── common.tf -> ../../components/common.tf 
│   │   └── terraform.tfvars 
│   └── global 
│    ├── common.tf -> ../../components/common.tf 
│    ├── global_component1.tf -> ../../components/global_component1.tf 
│    ├── global_component2.tf -> ../../components/global_component2.tf 
│    └── terraform.tfvars 
├── staging 
│   ├── customer1 
│   │   ├── application.tf -> ../../components/application.tf 
│   │   ├── common.tf -> ../../components/common.tf 
│   │   └── terraform.tfvars 
│   ├── customer2 
│   │   ├── application.tf -> ../../components/application.tf 
│   │   ├── common.tf -> ../../components/common.tf 
│   │   └── terraform.tfvars 
│   └── global 
│    ├── common.tf -> ../../components/common.tf 
│    ├── global_component1.tf -> ../../components/global_component1.tf 
│    └── terraform.tfvars 
├── apply.sh 
├── destroy.sh 
├── plan.sh 
└── remote.sh 

を、あなたの計画を実行/ラッパーシェルスクリプトがディレクトリにcd'ingとterraform get -update=trueを実行しているようなものを扱うルートレベルから破壊する/適用されますが、また、フォルダにterraform initを実行すると、S3用の独自の状態ファイルキーが得られ、各フォルダの状態を個別に追跡できます。

上記のソリューションには、物事に共通のインターフェイスを提供するためのリソースをラップする汎用モジュールがあります（たとえば、EC2インスタンスには入力変数やプライベートRoute53レコードに応じて特定のタグが付けられます） "

これらのコンポーネントには、同じフォルダにTerraformによって適用される一連のモジュール/リソースが含まれています。 ELB、アプリケーションサーバ、データベースをapplication.tfにして、それをある場所にシンボリックリンクすることで、Terraformで制御する場所を1つにすることができます。場所のリソースに差異がある場合は、それらを切り離すことになります。上記の例では、staging/globalにはglobal_component2.tfが存在し、プロダクションには存在しません。これは、環境へのインターネットアクセスを防止するために、一部のネットワーク制御などの非本番環境でのみ適用されるものである可能性があります。

本当のメリットは、開発者が望むTerraformコードを生成するテンプレート作成ステップを行うのではなく、開発者用のソース管理ですべてを簡単に見ることができることです。

また、環境内の唯一の違いは、場所内のファイルにあるterraform.tfvarsファイルのDRYにあり、各フォルダがほぼ同じであるため、変更をテストするのが簡単になります。