問題タブ [terraform-provider-gcp]

cloud入力変数を受け入れ、それに応じて適用するクロスクラウド Terraform モジュール (Google および aws 用) を作成しています。次に例を示します。

このアプローチの問題は、両方ではなく、選択したクラウドの資格情報のみを提供したいということです-cloud=awsたとえば、次の設定を取得します。

選択されていないクラウドのクラウド プロバイダー資格情報を偽造する方法はありますか? または、ある種の Terraform テンプレートを実装する必要がありますか?

Terraform 状態ファイルでは、OpenStack に対する .tfstate ファイルのセクションを次に示します (これは AWS API を使用するため、AWS がプロバイダーです)。

コンソールでインスタンス/リソースを手動で削除するとします。Terraform 構成は、Terraform Plan が ai) 再作成 (+/-) または ii) 破棄 (-) および作成/追加 (+) をトリガーできるように変更できます。

質問: どちらの場合でも、作成される新しいノードが以前の状態ファイルと同じ「id」属性を持つ可能性はありますか?

つまり、"id"属性 ( "instance_id"GCP の場合) は、インフラストラクチャのライフサイクル全体で常に一意になりますか? (そのため、古い tfstate ファイルと新しい tfstate ファイル"id"または"instance_id"属性を比較するときに、新しいノードが確実に作成/再作成され、.tfstate が計画で発生すると言われていることを反映していることを確認できます。)

.tfstate が計画 (作成/再作成/破棄の正確な数) を反映しているかどうかを確認している理由は、「計画」に従って「適用」が行われるものの、.tfstate がそれを反映しない場合があるためです。

この理由は、「apply」の後、terraform がプロバイダーに対して GET 呼び出しを行って .tfstate ファイルを更新しているように見え、この GET 呼び出しがインフラストラクチャーの一貫性のない状態を返す場合があるためです (つまり、ノードの詳細が返されていても、ノードの詳細が返されない場合があります)。作成され、インフラストラクチャの一部です!)。

その場合、.tfstate が計画どおりに発生しなかったことを自動化ツールで通知する必要があるため、.tfstate ファイルに破損や不整合が発生している可能性があるため、手動インポートで修正する必要があります。