identityは「何を同一資源と見なすか」の規則であり、stateとは独立軸である
identityとは「何を同一資源と見なすか」の規則である。stateをどこに置き誰が運用責任を負うかという問い(章4の主題)とは別の独立軸であり、同じツールでも別々に設計できる。identityが変わればstate上では別リソース扱いになる — つまりidentityはstate内の参照の形を規定するが、state所有の設計判断とは独立している。
設計判断の中心は識別子をユーザが書くか、ツールが自動生成するかである。
| ツール | 識別子 | 生成方式 |
|---|---|---|
| Terraform | resource address (aws_s3_bucket.foo) | ユーザ制御(<type>.<ラベル>)、ハッシュ化なし |
| CDK | CFN論理ID (例: MyBucketF68F3FF0) | construct pathのMD5ハッシュ先頭8桁(大文字16進) |
| Pulumi | URN (urn:pulumi:<stack>::<project>::<parent$type>::<name>) | type/name/parent等をengineが連結 |
| Carina | named: binding名そのまま / anonymous: content-based hash | namedはユーザ制御、anonymousは自動生成 |
CDKのL2は内部でid ResourceのCfnBucketを生成するためpath長2となり必ずハッシュが付く。stack直下のL1のみが例外的にハッシュなしになる。CarinaのanonymousはSimHash 16 hex、create-only attrsからstandard hash 8 hexも用いる。
日常的に意識する頻度にも差が出る。Terraform / Carinaでは別リソースから参照するために識別子をコードに直接書くので常時意識する。CDK / Pulumiではホスト言語の変数(const bucket = new s3.Bucket(...)のbucket)経由で参照するため、識別子が表面化するのは運用時 — cdk diff、コンソール、state操作、cross-stack reference、override、import — に限られる。
入れ子構造がidentityを規定する点も共通する。CDKのnode.pathはscope列を/区切りで連結し、Pulumiのopts.parentはURNのtype部に親typeを$区切りで連結する。つまり抽象化機構の入れ子がそのままidentityの構造になる。