この記事は、Pulumi dotnet Advent Calendar 2019 の11日目です。
Terraform に慣れていると Pulumiもイメージしやすいところはあります。 一方で Terraform との違いでどうすればいいのかな? となることもあります。
どんなことがあるのか見ます。
目次
TL;DR
Pulumiは Pulumi のコンセプトを持っているので、Terraform と全く同じ挙動を期待するのはずれている。
Terraform でこうやっていた経験が Pulumi で生きないということに傾向はある、のでそれをまとめる。
継続して更新予定。
Pulumi で困ったこと
TL;DR と Summary 形式で紹介する。
State の操作時に Component を消すにはResource を先に削除をしておく必要がある
TL;DR
Component != Module
Summary
Terraform で、リソースを取りまとめるときには Module を利用する。
Moduleとその中のResource を丸っとState から消すときは、 terraform state rm module.xxxx とModuleを指定できる。
いちいち リソースを消したりしないで済むので、Module に取りまとめておくことでstate 操作時にリソースのグルーピング対応が可能である。
Pulumi で、リソースを取りまとめるときには ComponentResource を利用する。
ComponentResource とその中の Resource を丸っと State から消そうと思っても、pulumi state delete urn:pulumi:STACK::PROJECT::PARENT_COMPONENT$COMPONENT::COMPONENT_NAME と ComponentResourceを指定してもリソースが1つでも含まれていると削除できない。
いちいちリソースを削除しないといけないので、ComponentResource をつかってstate操作時のリソースのグルーピング対応ができない。
Pulumi の Auto-naming に沿うことによる構成の制約
TL;DR
terraform と違って自動でランダム文字が付く。
LB など命名が長くなると詰むリソースでは注意 or 無効にする。 ただし無効にしないほうが圧倒的に扱いやすいので、無効にするときはそのことを忘れないように。忘れないように (二度言うということはそういうことです)
Summary
Pulumi の Auto-naming に沿う場合、リソース作成時までリソースの名前は不明である。 ここで困るのが、IAM Policy でリソースを指定する + IAM を ComponentResource に取りまとめる場合である。
対象のリソースAの作成 -> IAM の作成 の場合、リソースA の作成結果をもってIAM を作れるので何も困らない。
しかし、リソースA を操作する リソースB を作成し、そのリソースB の権限にIAM でリソースA を指定する というケースでは、リソースA を作成するまで IAM でどのような指定をすればいいのかが不明となる。
対策は2つ。
- こういうリソースはAuto-Naming をやめて固定の名前で対処する.。(ResourceのArgs にある Name などのプロパティを指定するとAuto-naming 無効)
- 相互の情報を必要としない IAM Role まで作成をしておいて、IAM Policy の作成、Attachment は両方の情報がそろってから別途行う
2を選んだ場合、IAM の設定が IAM ComponentResourceだけでないところに露出し、追いきれなくなる、追い切れても ComponentResourceのParent の紐づけが苦しいことになる。 そのため、妥当な選択は 1 となる。
Auto-naming に基本的に沿っておけばいいとは思うが、紐づけができる範囲でのゆるっとした利用前提を置くのがいいだろう。
