upstream_stateという機能を入れた。別のCarinaコンポーネントのstateを参照するための仕組みで、Terraformでいうterraform_remote_stateに相当する。
ただ、Terraformのremote stateを使っていて気になる点があったので、Carinaでは少し違う設計にしてみた。その違いについて書いておく。
Terraformのremote stateのおさらい
Terraformで別コンポーネントのstateを参照するときは、terraform_remote_state data sourceを使う。
data "terraform_remote_state" "network" {
backend = "s3"
config = {
bucket = "my-tfstate"
key = "network/terraform.tfstate"
region = "ap-northeast-1"
}
}
resource "aws_security_group" "web" {
vpc_id = data.terraform_remote_state.network.outputs.vpc_id
}
参照元のoutputsをdata.terraform_remote_state.network.outputs.vpc_idのような形で読む。参照される側はoutputブロックで値を公開する。
使っていて気になる点がいくつかある。
参照する側がbackendの設定を知っている必要がある
networkコンポーネントのbackendがS3なのか、バケット名は何か、キーは何か、といった情報を、それを使うweb側のコードにも書く必要がある。参照元のnetwork側ではこう書いて、
# network/main.tf
terraform {
backend "s3" {
bucket = "my-tfstate"
key = "network/terraform.tfstate"
}
}
参照する側のweb側ではこう書く。
# web/main.tf
data "terraform_remote_state" "network" {
backend = "s3"
config = {
bucket = "my-tfstate"
key = "network/terraform.tfstate"
}
}
bucketとkeyが両方に登場しているのが分かる。実質的に同じ情報を二重管理している状態になる。
呼び出すのに長い文字列を書く必要がある
参照するときの記述がdata.terraform_remote_state.network.outputs.vpc_idとなって、なかなか長い。data.terraform_remote_state.と.outputs.が毎回ついてくる。
複数の値を参照していると、この長い名前があちこちに出てきて冗長になる。localsで別名をつけて短くする、みたいな回避策を取ることになる。
補完が効かない
outputsの中身は実際のstateを読まないと分からないので、エディタで補完が効かない。
補完が効かないので、typoしても実行するまで気付けない。terraform validateは実際のremote stateを読まずに構文チェックだけするので、ここでは検出されない。別コンポーネントでoutputの名前を変えたときに、参照側が壊れていることをplanやapplyのタイミングで初めて知ることになる。
参照元が未applyだとplanできない
共通の通知基盤となるSNS topicをmonitoringコンポーネントで管理し、各サービス側のCloudWatchアラームからそのtopicを参照する、という構成を考える。
monitoring側に新しい通知先（たとえばcritical_alerts_topic_arn）を追加し、同じPRでweb側の新しいアラームからそれを参照する、というPRを出したとする。
# monitoring/main.tf
resource "aws_sns_topic" "critical_alerts" {
name = "critical-alerts"
}
output "critical_alerts_topic_arn" {
value = aws_sns_topic.critical_alerts.arn
}
# web/main.tf
resource "aws_cloudwatch_metric_alarm" "web_5xx" {
alarm_name = "web-5xx"
metric_name = "5XXError"
# ...
alarm_actions = [
data.terraform_remote_state.monitoring.outputs.critical_alerts_topic_arn,
]
}
このPRをCIでplanにかけると、monitoring側がまだapplyされていないので新しいoutputがstateに存在せず、web側のplanはエラーになる。
planエラーを回避したい場合、以下のようにtry()でフォールバックする、という手もある。
alarm_actions = try(
[data.terraform_remote_state.monitoring.outputs.critical_alerts_topic_arn],
[],
)
ただ、これだとPRレビュー時に見えるplanはalarm_actions = []になり、monitoringをapplyした後の本来のplanとは異なる。
結局、monitoring側のPRとweb側のPRを2回に分けてマージする、という対応になりがち。
そもそもremote stateで参照するほど密に依存しているなら、コンポーネントを分割している設計自体を見直したほうがいいケースもある。ただ、stateを分けざるを得ない事情（チーム境界、applyの責任範囲、リソースへのアクセス権限を分けたい都合など）もあり、そういう場合はこの面倒さと付き合うしかない。
remote stateの代わりに、data sourceで名前やタグから引く、という方法もある。これだとremote stateのように「outputが追加されたか」は気にしなくていい。ただし結局、参照先のリソースが実在していないとdata sourceの読み込みに失敗するので、upstreamを先にapplyする必要があるのは変わらない。
さらにdata sourceはstateではなく実際のAWS APIを叩いてリソース情報を取得するので、参照が増えるとstate refreshが遅くなる。どちらを取るかは悩ましい。
Carinaのupstream_state
Carinaでは、参照する側はupstreamコンポーネントのディレクトリを指すだけにした。
let network = upstream_state {
source = '../network'
}
awscc.ec2.SecurityGroup {
group_description = 'Web security group'
vpc_id = network.vpc_id
tags = {
Name = 'web-sg'
}
}
sourceはupstreamコンポーネントのディレクトリで、.crnファイルからの相対パスで解決される。letで束縛した名前（この例ではnetwork）を通じて、upstream側が公開している値にアクセスできる。
ディレクトリ参照なので、別リポジトリにあるコンポーネントを参照するにはsubtreeで取り込むなどの工夫がいる。自分にはリポジトリをまたいでstateを参照したいニーズがないので、いまはこれで割り切っている。必要になったらそのとき考える。
公開する側はこんな感じ。
backend s3 {
bucket = 'my-carina-state'
key = 'network/carina.state.json'
}
let main = awscc.ec2.Vpc {
cidr_block = '10.0.0.0/16'
}
exports {
vpc_id = main.vpc_id
}
exportsブロックで公開したい値を宣言する。Terraformのoutputブロックに相当する。型は自動的に推論されるので、この例ではvpc_idはVpcId型として公開される。
Terraformと違うところ
先に挙げた4つの点が、それぞれupstream_stateではどうなっているかを書いていく。
backend設定を書かなくていい
参照する側に書くのはsource（ディレクトリ）だけ。backend設定は書かない。
# web/main.crn
let network = upstream_state {
source = '../network'
}
Carinaはsourceで指定されたディレクトリの.crnファイルを読み込み、そこに書かれているbackendブロックを解決し、stateを読み出す。
# network/main.crn
backend s3 {
bucket = 'my-carina-state'
key = 'network/carina.state.json'
}
つまり、backendの場所を知っているのはupstream側だけで、参照する側はそれを意識しなくていい。
ディレクトリ参照なので、LSPでパス補完が効く。さらに、存在しないパスを指定した場合はcarina validateの時点でエラーになる。エディタ上でも赤線で知らせてくれる。
いっぽうTerraformのterraform_remote_stateのconfigは、bucket名やkeyをtypoしていても構文的には通るので、planを実行してbackendを叩きに行くまで間違いに気付けない。
呼び出しが短い
let network = upstream_state { source = '../network' }と束縛しておけば、参照はnetwork.vpc_idで済む。data.terraform_remote_state.や.outputs.のような定型的な部分がない。
letで束縛する名前は自由につけられるので、短くしたければnetでも何でもいい。
補完が効く
upstream_stateはsourceでupstreamのディレクトリを指しているので、Carinaはupstreamの.crnファイルを直接読める。stateを読まずとも、exportsブロックの宣言だけで、何が公開されているかが分かる。
さらにCarinaのDSLは静的な型を持っているので、exportsで公開される値にも型がつく。型がついていれば、参照側で必要としている型と照合できる。
たとえば参照側でawscc.ec2.SecurityGroupのvpc_id（型はVpcId）を埋めようとすると、同じVpcId型を持つupstreamのexportsがLSPの補完候補に上がってくる。
存在しないexportを参照すればエラーになる。typoしている場合は近い名前の候補も提示される。
型が合わない場合もエラーになる（vpc_id: String = main.vpc_idのように型アノテーションをつけた場合の例）。
未定義のexport参照や型不一致はcarina validateでもエラーになるので、planやapplyを待たずに検出できる。sourceパスが存在しない場合も同様にcarina validateで検出される。
参照元が未applyでもplanできる
carina validateはstateの内容は見ず、正しい型でexportされているかどうかだけをチェックするので、参照元が未applyでも当然動く。ではplanの場合はどうか。
upstream側のstate自体がまだ存在しない状態でplanを実行すると、こんな出力になる。
Warning: upstream_state 'network': no state found at /path/to/network;
dependent values will display as `(known after upstream apply: ...)`
Refreshing state...
✓ awscc.ec2.SecurityGroup.ec2_security_group_39f08cea [0.0s]
Execution Plan:
+ awscc.ec2.SecurityGroup ec2_security_group_39f08cea
group_description: "Web security group"
tags:
Name: "web-sg"
vpc_id: (known after upstream apply: network.vpc_id)
group_id: (known after apply)
id: (known after apply)
Plan: 1 to add, 0 to change, 0 to destroy.
upstream側のstateが無くてもplanは止まらず、参照値は(known after upstream apply: network.vpc_id)というプレースホルダで表示される。「この値はupstreamをapplyすれば確定する」というのがplan時点で見える。
upstream側のstateは存在するが、新しいexport値がまだ入っていない（exportを追加してまだ再applyしていない）場合も、Warningが出ないだけで参照値は同じプレースホルダで表示される。
Refreshing state...
✓ awscc.ec2.SecurityGroup.ec2_security_group_39f08cea [0.0s]
Execution Plan:
+ awscc.ec2.SecurityGroup ec2_security_group_39f08cea
group_description: "Web security group"
tags:
Name: "web-sg"
vpc_id: (known after upstream apply: network.vpc_id)
group_id: (known after apply)
id: (known after apply)
Plan: 1 to add, 0 to change, 0 to destroy.
Terraformでは参照先のstateが無いとremote stateの読み込みで失敗してplan自体が出せないが、Carinaはプレースホルダで表示するので、planは出せる。前述のtry()での回避策のように「実際とは違うplan」が表示されるわけでもない。upstreamをapplyした後にもう一度planを取れば、プレースホルダが実際の値に置き換わるだけ。
まとめ
Terraformのremote stateで気になる点と、Carinaのupstream_stateでの対応を並べるとこんな感じ。
| Terraformのremote state | Carinaのupstream_state |
|---|---|
参照側がbackend設定を書く必要があり、設定のtypoはplanまで気付けない |
sourceにディレクトリを指定するだけ。パスの間違いはcarina validateで検出できる |
data.terraform_remote_state.network.outputs.vpc_idと長い |
letで束縛してnetwork.vpc_id |
outputsの中身はstateを読むまで分からず補完が効かない |
exportsは型付きで補完が効く |
typoや存在しないoutput参照はplan/applyまで気付けない |
未定義のexport参照や型不一致はcarina validateで検出できる |
| 参照元が未applyだとplanすら失敗する | (known after upstream apply: ...)として未確定値で表示され、planは通る |
