以前terraform testを試しましたが、Terraformモジュールやリソースのテストを実行することができる機能として、terraform testの他にTerraformのv1.5よりcheckブロックの機能が追加されております。
今回は本機能を試してみようと思います。
checkブロックとは
checkブロックは、リソースの作成後にその状態が期待通りかどうかを検証する機能です。
インフラ構築後の疎通確認や設定検証を効率的に行うことが可能になります。
前提条件
前提条件として、以下Terratermバージョンが必要となります。
- Terraformのバージョン：v1.5 以上
事前準備
リソース作成用のTerraform定義ファイルを作成する
リソース作成用の定義ファイルを作成します。
今回は、既存のリソースグループにApp ServiceとApp Service Planを作成し、その接続をcheckブロックで確認する定義ファイルを作成しました。
【main.tf】
# Env info provider "azurerm" { features {} subscription_id = var.subscription_id tenant_id = var.tenant_id } # Azure Provider terraform { required_providers { azurerm = { source = "hashicorp/azurerm" version = "~>4.32.0" } } # Store Terraform state in Azure Storage backend "azurerm" { resource_group_name = "<Resource Group名(状態格納用ストレージアカウントが格納されているResource Group)>" storage_account_name = "<Storage Account名>" container_name = "<Blob Container名>" # Statment File Name key = "terraform.tfstate" } }
【rg.tf】
#------------------------------- # Resource Group #------------------------------- # Resource Group data "azurerm_resource_group" "rg" { name = var.resource_group_name }
【app.tf】
#------------------------------- # App Service #------------------------------- # App Service Plan resource "azurerm_service_plan" "asp" { name = var.asp_name location = data.azurerm_resource_group.rg.location resource_group_name = data.azurerm_resource_group.rg.name sku_name = var.asp_sku os_type = var.asp_os depends_on = [ data.azurerm_resource_group.rg ] } # 乱数を生成 resource "random_id" "suffix" { byte_length = 4 } # App Service resource "azurerm_windows_web_app" "app" { name = "${var.app_name}-${random_id.suffix.hex}" location = data.azurerm_resource_group.rg.location resource_group_name = data.azurerm_resource_group.rg.name service_plan_id = azurerm_service_plan.asp.id public_network_access_enabled = true site_config { application_stack { current_stack = var.app_cs dotnet_version = var.app_dv } } depends_on = [ azurerm_service_plan.asp, random_id.suffix ] }
【variables.tf】
#------------------------------- # 基本変数定義 #------------------------------- # Subscription ID variable "subscription_id" {} # TenantID variable "tenant_id" {} # Region variable "location" { default = "japaneast" } #------------------------------- # Resource Group #------------------------------- # Resource Group Name variable "resource_group_name" { default = "nishiyamas-tf-rg" } #---------------------------------- # App Service #---------------------------------- # App Service Plan Name variable "asp_name" { default = "nishiyamas-tf-asp01" } # App Service Plan SKU variable "asp_sku" { default = "B1" } # App Service Plan OS variable "asp_os" { default = "Windows" } # App Service Name variable "app_name" { default = "<App Service名>" } # App Service Current Stack variable "app_cs" { default = "dotnet" } # App Service Dotnet Version variable "app_dv" { default = "v4.0" }
【terraform.tfvars】
# Tenand ID tenant_id = "<Tenant ID>" # SubScription ID subscription_id = "<Subscription ID>"
check.tfを作成する
次に、checkブロックを定義するファイルを作成します。
このブロックではApp Serviceが正常に応答しているかを確認します。
【check.tf】
#------------------------------- # Check #------------------------------- # App Service Check check "app_service_health" { data "http" "app_health" { url = "https://${azurerm_windows_web_app.app.default_hostname}" } assert { condition = data.http.app_health.status_code == 200 error_message = "App Service が正常に応答していません。Status Code：${data.http.app_health.status_code}）" } }
実行する
App Serviceへの接続が可能な状態で実行する
まずは、App Serviceへの接続が可能な状態で実行します。
実行コマンドについては以下URLの「Terraformコマンドの実行」をご参照ください。
App Serviceへの接続が可能な状態ですと、問題なくapplyが完了することが確認できます。
App Serviceへの接続が不可な状態で実行する
次に、App Serviceへの接続が不可な状態で実行します。
app.tfを一部変更する
app.tfのパブリックアクセスを「true」より「false」に変更します。
【app.tf ※一部抜粋】
public_network_access_enabled = false #更新
再度実行する
再度実行します。実行コマンドについては以下URLの「Terraformコマンドの実行」をご参照ください。
※今回はdestryコマンドでリソースを一度削除した後に、再度実行をしています。
App Serviceへの接続が不可な状態では、checkブロックにて指定したエラーメッセージが表示されることを確認できます。
おわりに
本記事を最後までお読みいただき、ありがとうございます。
これまではリソース作成後に別途リソースの状態確認が必要でしたが、Terraformのcheckブロックを利用することでリソースの作成時にその状態が期待通りかどうかを検証でき、インフラ構築後の疎通確認や設定検証を効率的に行うことが可能になるように感じました。
本記事がTerraformを使用する際の参考となれば幸いです。
