壊れた cf スタックのリストアと cdk の再同期 ::

2時に寝て6時半に起きた。インフラエンジニアになったのでみんなが作業していない時間にインフラの保守作業をするようにしている。昼はアプリケーションエンジニア、夜はインフラエンジニアみたいな生活になっていてしんどい。

壊れた cf スタックの更新⌗

テスト環境の cf スタックを手動で更新して壊れているのを cdk で管理できるように直した。壊れていたのは次の3つ。

rds をスナップショットからリストアしたので cf が管理している rds リソースが存在しない
iam の acl 設定が異なる
セキュリティグループのインバウンドルールが異なる

aws 的にもそういった状況は認識していて cdk で同期できなくなった cf スタックを更新する手順を提供している。

AWS CloudFormation スタックを削除したときにリソースの一部を保持する方法を教えてください。

ざっくり手順をまとめると次になる。

対象のリソースに DeletetionPolicy=Retain にセットする
テンプレートからリソースを削除して、スタックの更新を実行する
テンプレート内のリソースの実際の状態を describe して、スタック内に既存のリソースをインポートする

リソースの設定ぐらいなら既存のリソースからインポートしなくても cf のテンプレートを直接書き換えたものをアップロードしてスタックを更新するのでも大丈夫だったりする。しかし、cdk もそのテンプレートにあうように修正しないといけないため、cdk のコードとテンプレートのコードの両方をチェックしながら検証する必要がある。cdk でリソース管理ができるようになったからといって、それが変更前の既存のリソースの設定と同じかどうかは人間が目でみて検証しないといけない。これがあちこちで参照されているリソースだと追跡するのが面倒くさいといった手間暇がかかる。

cdk がよいものかどうか、私はまだ判断がつかないけど、cf を抽象化して便利になっているところは認めるものの、cf のスタックが壊れたときのトラブルシューティングが必要以上に複雑で厄介というのも事実ではある。一方で壊れた cf スタックを5時間ぐらいかけて直したのではまりポイントはいくつかも学ぶことができた。しんどかったけど。例えば、あるセキュリティグループのインバウンドルールに別のセキュリティグループを関連付けるとき、1つの設定ではうまくいかなくて次の2つの設定を追加した。これが適切かどうかわからないが、この設定で cdk でデプロイしたスタックの環境と既存リソースとの環境が整合した状態 (ドリフトが解消される) になった。こういうのが cdk の抽象化による訳のわからないところの1つ。

otherSecurityGroup.addIngressRule(
  ec2.SecurityGroup.fromSecurityGroupId(this, 'my security group', mySgId),
  ec2.Port.tcp(80),
  "my inboud rule",
)
otherSecurityGroup.addIngressRule(
  ec2.Peer.securityGroupId(mySgId),
  ec2.Port.tcp(80),
  "my inboud rule",
)