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

チェック

checkブロックは、通常のリソースライフサイクルの外でインフラストラクチャを検証できます。チェックブロックは、適用後とインフラストラクチャの機能検証の間のギャップに対処します。

チェックブロックを使用すると、OpenTofuのプランまたは適用操作の全体的なステータスに影響を与えることなく、すべてのOpenTofuプランまたは適用操作で実行されるカスタム条件を定義できます。チェックブロックは、OpenTofuがインフラストラクチャを計画またはプロビジョニングした後、プランまたは適用の最後のステップとして実行されます。

構文​

checkブロックは、ローカル名、0個または1個のスコープ付きデータソース、および1個以上のアサーションで宣言できます。

次の例では、Webサイトをロードし、期待されるステータスコード200が返されることを検証します。

コードブロック
check "health_check" {
  data "http" "opentofu_org" {
    url = "https://www.opentofu.org"
  }

  assert {
    condition = data.http.opentofu_org.status_code == 200
    error_message = "${data.http.opentofu_org.url} returned an unhealthy status code"
  }
}

スコープ付きデータソース​

checkブロック内のスコープ付きデータソースとして、任意のプロバイダーの任意のデータソースを使用できます。

checkブロックには、ネストされた（別名、スコープ付き）データソースをオプションで含めることができます。このdataブロックは、外部のデータソースのように動作しますが、囲んでいるcheckブロックの外で参照することはできません。さらに、スコープ付きデータソースのプロバイダーがエラーを発生させた場合、それらは警告としてマスクされ、OpenTofuが操作の実行を継続することを妨げません。

スコープ付きデータソースを使用して、通常OpenTofuリソースライフサイクルの外でインフラストラクチャの状態を検証できます。上記の例では、opentofu_orgデータソースのロードに失敗した場合、checkブロックの外でこのデータソースを宣言した場合に発生するブロックエラーではなく、警告が表示されます。

メタ引数​

スコープ付きデータソースは、depends_onおよびproviderメタ引数をサポートしています。スコープ付きデータソースは、countまたはfor_eachメタ引数をサポートしていません。

depends_on​

depends_onメタ引数は、スコープ付きデータソース内で使用すると特に強力になります。

前の例で、OpenTofuが最初のプランを作成したとき、OpenTofuがまだ構成を適用していないため、プランは失敗します。つまり、このWebサイトが存在するようにリソースを作成する必要があるため、このテストは失敗します。したがって、OpenTofuがこのチェックを初めて実行すると、常に気を散らす可能性のあるエラーメッセージがスローされます。

depends_onをスコープ付きデータソースに追加することで、ロードバランサーなど、サイトのインフラストラクチャの重要な部分に依存するようにすることで、これを修正できます。チェックは、Webサイトの重要な部分が準備できるまで、適用後に既知を返します。この戦略により、セットアップ中に不要な警告が発生するのを防ぎ、チェックは後続のプランと適用中に実行されます。

この戦略の1つの問題は、スコープ付きデータソースがdepends_on依存しているリソースが変更された場合、OpenTofuがそのリソースを更新するまで、チェックブロックが適用後に既知を返すことです。ユースケースによっては、この動作が許容される場合と問題となる場合があります。

スコープ付きデータソースが別のリソースの存在に依存しており、それを直接参照していない場合は、depends_onメタ引数を実装することをお勧めします。

アサーション​

チェックブロックは、assertブロックを使用してカスタムアサーションを検証します。各checkブロックには、少なくとも1つ、場合によっては多数のassertブロックが必要です。各assertブロックには、condition属性と、error_message属性があります。

他のカスタム条件とは異なり、アサーションはOpenTofuの操作の実行に影響を与えません。失敗したアサーションは、進行中の操作を停止することなく警告を報告します。これは、OpenTofuがすぐにエラーを生成し、操作を停止して将来のリソースの適用または計画をブロックする、事後条件などの他のカスタム条件とは対照的です。

assertブロック内の条件引数は、囲んでいるcheckブロック内のスコープ付きデータソース、および現在のモジュール内の任意の変数、リソース、データソース、またはモジュール出力を参照できます。

アサーションの詳細.

メタ引数​

チェックブロックは現在、メタ引数をサポートしていません。この機能に関するフィードバックをまだ収集しているため、チェックブロックでメタ引数をサポートするとユースケースが改善される場合は、お知らせください。

TACOS（TF自動化およびコラボレーションソフトウェア）での継続的な検証​

TACOS（TF自動化およびコラボレーションソフトウェア）は、OpenTofuが新しいインフラストラクチャをプロビジョニングした後、ワークスペースの構成内のチェックが引き続き成功するかどうかを自動的に検証できます。

チェックまたは他のカスタム条件の選択​

チェックブロックは、OpenTofu内で最も柔軟な検証ソリューションを提供します。チェックアサーション内で出力、変数、リソース、およびデータソースを参照できます。また、チェックを使用して、他のすべてのカスタム条件をモデル化することもできます。ただし、これはすべてのカスタム条件をチェックブロックに置き換えるべきという意味ではありません。

チェックブロックのアサーションと他のカスタム条件の間には、動作に大きな違いがあります。主な違いは、チェックブロックはOpenTofuの操作実行に影響を与えないということです。この非ブロック動作を利用して、ユースケースに最適な検証タイプを決定できます。

出力と変数​

出力の事後条件と変数の検証はどちらも、入力と出力に関するアサーションを行います。

これは、OpenTofuにそれ以上の実行をブロックさせたい場合に該当します。

例えば、OpenTofuが入力変数を含む構成全体を適用した後に、その入力変数が無効であると警告しても役に立ちません。この場合、チェックブロックは無効な入力変数を警告しますが、操作を中断しません。同じ入力変数の検証ブロックは、無効な変数を警告し、計画または適用操作を停止させます。

リソースの事前条件と事後条件​

事前条件と事後条件とチェックブロックの違いは、より微妙です。

事前条件は、リソースの変更が適用または計画される前に実行されるという点で、カスタム条件の中で独自です。事前条件と事後条件の選択は、事前条件と事後条件の選択に関するガイダンスを提供しており、事前条件とチェックブロックの選択にも同じことが当てはまります。

多くの場合、事後条件をチェックブロックと相互に使用して、リソースとデータソースを検証できます。

例えば、上記のcheckブロックの例を事後条件を使用するように書き換えることができます。以下のコードでは、postconditionブロックを使用して、ウェブサイトが期待されるステータスコード200を返すことを検証します。

コードブロック
data "http" "opentofu_org" {
  url = "https://www.opentofu.org"

  lifecycle {
    postcondition {
        condition = self.status_code == 200
        error_message = "${self.url} returned an unhealthy status code"
    }
  }
}

checkとpostconditionのブロックの例はどちらも、計画または適用操作中にウェブサイトが200のステータスコードを返すことを検証します。2つのブロックの違いは、それぞれが失敗をどのように処理するかです。

postconditionブロックが失敗した場合、OpenTofuは現在の操作の実行をブロックします。checkブロックが失敗した場合、OpenTofuは操作の実行をブロックしません。

上記の例の事後条件が失敗した場合、回復することは不可能です。計画段階で事後条件が満たされない場合、OpenTofuは将来の計画または適用操作をブロックします。この問題が発生するのは、事後条件がOpenTofuの構成に直接依存するのではなく、複数のリソース間の複雑な相互作用に依存するためです。

インフラストラクチャ全体のステータスを検証するには、チェックブロックを使用することをお勧めします。事後条件は、リソースの構成に基づいて単一のリソースに関する保証が必要な場合にのみ使用することをお勧めします。