オーバーライドファイル

OpenTofuは通常、ディレクトリ内のすべての.tf、.tofu、.tf.json、および.tofu.jsonファイルを読み込み、それぞれが個別の設定オブジェクトのセットを定義することを期待します。 2つのファイルが同じオブジェクトを定義しようとすると、OpenTofuはエラーを返します。

まれに、既存の設定オブジェクトの特定部分を別のファイルでオーバーライドできると便利な場合があります。たとえば、OpenTofu言語のネイティブ構文で記述された人間が編集した設定ファイルを、プログラムで生成されたJSON構文のファイルを使用して部分的にオーバーライドできます。

このようなまれな状況のために、OpenTofuは、名前が_override.tf、_override.tofu、_override.tf.json、または_override.tofu.jsonで終わる設定ファイルを特別に処理します。 この特別な処理は、文字通りoverride.tf、override.tofu、override.tf.json、またはoverride.tofu.jsonという名前のファイルにも適用されます。

OpenTofuは、設定を読み込む際に最初にこれらの*オーバーライドファイル*をスキップし、その後、それぞれを順番に（辞書順に）処理します。 オーバーライドファイルで定義されている各トップレベルブロックについて、OpenTofuはそのブロックに対応する既に定義されているオブジェクトを見つけようとし、次にオーバーライドブロックの内容を既存のオブジェクトにマージします。

オーバーライドファイルは特別な状況でのみ使用してください。 オーバーライドファイルを過剰に使用すると、可読性が低下します。元のファイルのみを見ている読者は、存在するすべてのオーバーライドファイルを参照せずに、それらのファイルの一部がオーバーライドされていることを簡単に見ることができません。 オーバーライドファイルを使用する場合は、元のファイルにコメントを追加して、将来の読者に各ブロックにどのオーバーライドファイルが変更を適用するかを警告してください。

例​

次の内容のOpenTofu設定`example.tf`がある場合

resource "aws_instance" "web" {
  instance_type = "t2.micro"
  ami           = "ami-408c7f28"
}

...そして、次の内容のファイル`override.tf`を作成した場合

resource "aws_instance" "web" {
  ami = "foo"
}

OpenTofuは後者を前者にマージし、元の構成が次のようであったかのように動作します

resource "aws_instance" "web" {
  instance_type = "t2.micro"
  ami           = "foo"
}

マージ動作​

マージ動作はブロックタイプごとにわずかに異なり、特定のブロック内の特別な構成要素は特別な方法でマージされます。

ほとんどの場合に適用される一般的なルールは次のとおりです。

• オーバーライドファイルのトップレベルブロックは、同じブロックヘッダーを持つ通常の構成ファイルのブロックとマージされます。 ブロック*ヘッダー*は、ブロックタイプとその後に続く引用符で囲まれたラベルです。

• トップレベルブロック内では、オーバーライドブロック内の属性引数は、元のブロック内の同じ名前の引数を置き換えます。

• トップレベルブロック内では、オーバーライドブロック内のネストされたブロックは、元のブロック内の*すべて*の同じタイプのブロックを置き換えます。 オーバーライドブロックに表示されないブロックタイプは、元のブロックから残ります。

• ネストされた構成ブロックの内容はマージされません。

• 結果の*マージされたブロック*は、指定されたブロックタイプに適用される検証ルールに準拠している必要があります。

複数のオーバーライドファイルが同じトップレベルブロックを定義している場合、オーバーライド効果は複合化され、後のブロックが前のブロックよりも優先されます。 オーバーライドは、最初にファイル名（辞書順）、次に各ファイル内の位置の順に処理されます。

以下のセクションでは、特定のトップレベルブロックタイプ内の特定の引数に適用される特別なマージ動作について説明します。

`resource`および`data`ブロックのマージ​

`resource`ブロック内では、`lifecycle`ネストされたブロックの内容は、引数ごとにマージされます。 たとえば、オーバーライドブロックが`create_before_destroy`引数のみを設定する場合、元のブロックの`ignore_changes`引数は保持されます。

オーバーライドする`resource`ブロックに1つ以上の`provisioner`ブロックが含まれている場合、元のブロックの`provisioner`ブロックは無視されます。

オーバーライドする`resource`ブロックに`connection`ブロックが含まれている場合、元のブロックに存在する`connection`ブロックを完全にオーバーライドします。

`depends_on`メタ引数はオーバーライドブロックで使用できず、エラーが発生します。

`variable`ブロックのマージ​

variable ブロック内の引数は、上記で説明した標準的な方法でマージされますが、type 引数と default 引数の相互作用により、いくつかの特別な考慮事項が適用されます。

元のブロックで default 値が定義されていて、オーバーライドブロックで変数の type が変更された場合、OpenTofu はデフォルト値をオーバーライドされた型に変換しようとします。この変換が不可能な場合はエラーが発生します。

逆に、元のブロックで type が定義されていて、オーバーライドブロックで default が変更された場合、オーバーライドされたデフォルト値は元の型指定と互換性がなければなりません。

output ブロックのマージ​

`depends_on`メタ引数はオーバーライドブロックで使用できず、エラーが発生します。

locals ブロックのマージ​

各 locals ブロックは、いくつかの名前付き値を定義します。オーバーライドは、どの locals ブロックで定義されているかを無視して、値ごとに適用されます。

terraform ブロックのマージ​

terraform ブロック内の設定は、マージ時に個別に考慮されます。

required_providers 引数が設定されている場合、その値は要素ごとにマージされます。これにより、オーバーライドブロックは、他のプロバイダーの制約に影響を与えることなく、単一のプロバイダーの制約を調整できます。

required_version と required_providers の両方の設定で、各オーバーライド制約は、元のブロックの同じコンポーネントの制約を完全に置き換えます。ベースブロックとオーバーライドブロックの両方で required_version が設定されている場合、ベースブロックの制約は完全に無視されます。

オーバーライドファイル内のバックエンド（cloud または backend）を定義するブロックが存在する場合、元の構成でバックエンドを定義するブロックよりも常に優先されます。つまり、元の構成内で cloud ブロックが設定され、オーバーライドファイルで backend ブロックが設定されている場合、OpenTofu はマージ時にオーバーライドファイルで指定された backend ブロックを使用します。同様に、元の構成内で backend ブロックが設定され、オーバーライドファイルで cloud ブロックが設定されている場合、OpenTofu はマージ時にオーバーライドファイルで指定された cloud ブロックを使用します。