メインコンテンツへスキップ

リソースブロック

リソースは OpenTofu 言語で最も重要な要素です。各リソースブロックは、仮想ネットワーク、コンピューティングインスタンス、DNS レコードなどの高レベルコンポーネントなど、1つ以上のインフラストラクチャオブジェクトを記述します。

リソース構文​

リソース宣言には多くの高度な機能を含めることができますが、最初の使用に必要なのはその小さなサブセットのみです。複数の類似したリモートオブジェクトを生成する単一のリソース宣言などのより高度な構文機能については、このページで後述します。

コードブロック
resource "aws_instance" "web" {
  ami           = "ami-a1b2c3d4"
  instance_type = "t2.micro"
}

resource ブロックは、特定のローカル名 ("web") を持つ、特定の型 ("aws_instance") のリソースを宣言します。この名前は、同じモジュール内の他の場所からこのリソースを参照するために使用されますが、そのモジュールのスコープ外では意味がありません。

リソース型と名前は合わせて、特定のリソースの識別子として機能するため、モジュール内で一意である必要があります。

ブロック本体 ({ と } の間) には、リソース自体の構成引数があります。このセクションのほとんどの引数はリソース型に依存しており、実際、この例では、ami と instance_type の両方がaws_instance リソース型に固有に定義された引数です。

リソース型​

各リソースは、管理するインフラストラクチャオブジェクトの種類と、リソースがサポートする引数およびその他の属性を決定する単一のリソース型に関連付けられています。

プロバイダ​

各リソース型は、OpenTofu のプラグインであり、リソース型のコレクションを提供するプロバイダによって実装されます。プロバイダは通常、単一のクラウドまたはオンプレミスインフラストラクチャプラットフォームを管理するためのリソースを提供します。プロバイダは OpenTofu 自体とは別に配布されますが、OpenTofu はワーキングディレクトリの初期化時にほとんどのプロバイダを自動的にインストールできます。

リソースを管理するには、モジュールがどのプロバイダが必要かを指定する必要があります。さらに、ほとんどのプロバイダはリモート API にアクセスするためにいくつかの構成が必要であり、ルートモジュールはその構成を提供する必要があります。

詳細については、以下を参照してください

OpenTofu は通常、リソース型の名前に基づいて使用するプロバイダを自動的に決定します。（慣例として、リソース型の名前はプロバイダの推奨ローカル名で始まります。）プロバイダの複数の構成（または推奨されないローカルプロバイダ名）を使用する場合、provider メタ引数を使用して、代替のプロバイダ構成を手動で選択する必要があります。詳細については、provider メタ引数を参照してください。

リソース引数​

resource ブロックの本体内のほとんどの引数は、選択したリソース型に固有です。リソース型のドキュメントには、どの引数が利用可能で、その値をどのようにフォーマットする必要があるかが記載されています。

リソース引数の値は、式やその他の動的な OpenTofu 言語機能を十分に活用できます。

OpenTofu 自体によって定義され、すべてのリソース型に適用されるメタ引数もいくつかあります。（以下のメタ引数を参照してください。）

リソース型のドキュメント​

すべてのプロバイダーには、独自のリソースタイプとそれらの引数を記述したドキュメントがあります。

公開されているプロバイダーのほとんどは、Public Terraform Registry で配布されており、そこにはドキュメントもホストされています。OpenTofu Registryでプロバイダーのページを表示すると、ヘッダーにある「Documentation」リンクをクリックしてドキュメントを閲覧できます。レジストリ上のプロバイダードキュメントはバージョン管理されており、ヘッダーにあるドロップダウンバージョンメニューを使用して、表示するドキュメントのバージョンを切り替えることができます。

公開されているプロバイダーとそのドキュメントを閲覧するには、Public Terraform Registryを参照してください。

リソースの動作​

OpenTofuが構成を適用する際にリソースをどのように管理するかについての詳細は、リソースの動作を参照してください。

リソースの削除​

構成からリソースブロックを削除すると、OpenTofuはデフォルトの動作としてそれを破棄します。

ただし、対応するインフラストラクチャオブジェクトを破棄せずに、構成からリソースを削除したい場合があります。そのような場合は、リモートシステムで永続化させながら、OpenTofuの状態から削除できます。

これを実現するには、次の手順に従います。

  1. 構成からリソースを削除します。
  2. 代わりに、削除されたブロックを追加し、from属性で「忘れさせたい」リソースのアドレスを指定します。

例：

コードブロック
removed {
  from = aws_instance.web
}

tofu planを実行すると、OpenTofuはリソースが状態から削除される予定であることを示しますが、破棄はされません。

removedブロックは、特定のリソースや複数のリソースを含むモジュールを削除するために使用できます。例：

コードブロック
removed {
  from = module.some_module
}

メタ引数​

OpenTofu言語では、リソースの動作を変更するために任意のリソースタイプで使用できるいくつかのメタ引数が定義されています。

次のメタ引数は、個別のページに記載されています。

カスタム条件チェック​

preconditionブロックとpostconditionブロックを使用すると、リソースがどのように動作するかについての仮定と保証を指定できます。次の例では、AMIが適切に構成されているかどうかをチェックする前提条件を作成します。

コードブロック
resource "aws_instance" "example" {
  instance_type = "t2.micro"
  ami           = "ami-abc123"

  lifecycle {
    # The AMI ID must refer to an AMI that contains an operating system
    # for the `x86_64` architecture.
    precondition {
      condition     = data.aws_ami.example.architecture == "x86_64"
      error_message = "The selected AMI must be for the x86_64 architecture."
    }
  }
}

カスタム条件は、将来の保守担当者が構成の設計と意図を理解するのに役立つ前提を捕捉するのに役立ちます。また、エラーに関する有益な情報をより早くコンテキストで返すため、消費者が構成の問題をより簡単に診断するのに役立ちます。

詳細については、カスタム条件チェックを参照してください。

操作タイムアウト​

一部のリソースタイプには、特定の操作が失敗と見なされるまでにかかる時間をカスタマイズできる特別なtimeoutsネストされたブロック引数が用意されています。たとえば、aws_db_instance では、create、update、およびdelete操作のタイムアウトを設定できます。

タイムアウトはプロバイダーのリソースタイプの実装によって完全に処理されますが、これらの機能を提供するリソースタイプは、設定可能なタイムアウト値を持つ各操作の名前が付いたネストされた引数を持つtimeoutsという名前の子ブロックを定義するという規約に従います。これらの引数はそれぞれ、期間を文字列で表したもので、60分の場合は "60m"、10秒の場合は "10s"、2時間の場合は "2h" のように記述します。

コードブロック
resource "aws_db_instance" "example" {
  # ...

  timeouts {
    create = "60m"
    delete = "2h"
  }
}

設定可能な操作のセットは、各リソースタイプによって選択されます。ほとんどのリソースタイプはtimeoutsブロックをまったくサポートしていません。各リソースタイプのドキュメントを参照して、構成用に提供されている操作（もしあれば）を確認してください。