この記事は、Pulumi dotnet Advent Calendar 2019の11日目です。
Terraformに慣れているとPulumiもイメージしやすいところはあります。 一方でTerraformとの違いでどうすればいいのかな? となることもあります。
どんなことがあるのか見ます。
概要
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に基本的に沿っておけばいいですが、紐づけができる範囲でのゆるっとした利用前提を置くのがいいでしょう。
