結論
Terraformプロバイダ:snowsqlを使う (〜2023/6時点)
resource "snowflake_external_table" "external_table" {
# ... 中略 ...
}
data "snowsql_query" "notification_channel" {
statements = <<-EOT
SHOW EXTERNAL TABLES;
SELECT "notification_channel" FROM TABLE(RESULT_SCAN(LAST_QUERY_ID())) LIMIT 1;
EOT
depends_on = [
snowflake_external_table.external_table
]
}
output "snowflake_notification_channel" {
value = jsondecode(data.snowsql_query.notification_channel.results)[1]["notification_channel"]
}
これで、outputとして以下のような値が取得できる。
arn:aws:sqs:ap-northeast-1:000000000000:sf-snowpipe-XXXXXXXXXXXXXXXXXXXXXXXXXXXXX
moduleのアウトプットにすれば、この値を後続処理に引き渡すことができる。
経緯
Snowflake (on AWS) のリソースとして外部テーブル(S3)を作成したかった。
Snowflakeのワークシートで外部テーブルを作成すると、その後にSnowflake側で自動で作成してくれるnotification_channel(中身はAWS SQSのarn)が取得できる。
このarnを取得し、この後自前のAWSアカウントに入ってS3のイベント通知に設定することで、外部テーブルの自動更新ができるようになるというカラクリ。
(詳細はSnowflake公式の情報を参照)
これをTerrafromで定義すれば、GUI操作でSnowflakeとAWSを行き来することなく一通で設定できる...と思っていた。
そんな時に本件に引っかかってしまった。
Snowflake公式から提供されているTerraformプロバイダ:snowflakeがあり、これを用いることでSnowflakeのリソース作成をIaC化できる。
しかしながら、この本家Terraformプロバイダでできることはまだまだ限られている模様。
シェル(SnowCLI)やPython等を使って、一部分だけを外部処理にするのも面倒だ...。
Terrafromでなんとかしたい...。
そう思っていた時、任意のSQLが実行できる非公式プロバイダ:snowsqlがあって助かった。
ぼやき
そもそもSnowflakeプロバイダ経由では、AWSのリソース情報が取れないのかなと思ったけどそうではなさそう。
似たようなシチュエーションとして、ストレージ統合 (こちら) ではAWSのリソースとしてIAMユーザーのarnを持っている。
こちらに関しては、公式プロバイダーを用いることで「storage_aws_iam_user_arn」が取得できる。
# OK
snowflake_storage_integration.integration.storage_aws_iam_user_arn
一方、外部テーブル (こちら) 生成後に発行されるはずの「notification_channel」も同じノリで取得できてもいいんじゃなかろうかと思った次第。
# NG (こうやって値を取りたかった...)
snowflake_external_table.external_table.notification_channel