IaC ジェネレーター登場前
IaCジェネレーターの登場前はFormer2を使用して既存のリソースをIaC化することができました。
IaC化先もCloudFormationやTerraform,CDKなど色んな選択肢がありました。
詳細はOutputsを開くと出てきます。
一方でこれを使用するには2つの壁があるかと思います。
- IAMのCredentialをFormer2 に埋め込む
- そもそもプロキシ制限で会社の環境で使えない
一旦後者は置いておくとして、
AWSをほぼ触ったことがないけどIaC化してみようかなと思った当時の私は以下の躊躇と対峙しました。
"このCredential情報を渡して本当にいいんだろうか"
調べると下記のブログやFormer2を触った時に出てくるReadOnlyAccessを使えばいいのかと出てくるわけです。
これがIaC ジェネレーター登場前に
初心者がIaC化を楽にやってみようと思った時の心理と壁でした。
そして、職場利用させて欲しいと懇願するには既存リソース情報を全て持っていかれるのかをきちんと説明する必要もあったわけです。
救世主となるのか?
IaC ジェネレーターを試してみた
試しにVPC関連リソースをデフォルトで一気に作って、EC2を立ててしまいましょう。
IaC ジェネレーターはCloudFormationの中にいます。
とりあえず、スキャンしてテンプレート作成を実施してみます。
大きく今までのCloudFormation作成と違うのはこの辺りですね。
スキャンしたリソースを選択できます。
今回はEC2とVPC関連のNameタグがiac-generatorにしていたのでタグ名で絞って選択します。
そして出来上がったIaCをスタックにインポートしてCloudFormationから実行します。
実際にEC2インスタンスは構築したEC2と対応していました。
ここでスタックを削除して確認します。
一部リソースが削除できませんでした。
インターネットゲートウェイと
ルートテーブルに依存関係がありそうです。
結局マネジメントコンソールからVPC削除して解決していますが、
"どんなリソースがあるのかをコード化することが可能"は紛れもない事実かなと思います。
現状は本当にこの機能を業務で使うなら過信せずにParameterつかったりRef使ったり等、ある程度の書き直しをする前提の方がいいのかなと思います。
(もちろん、"依存関係は多少あっても、どんなリソースがあるのかをコード化する"ことが目的ならこれでも良い気がします)
ひょっとして既存リソースのお片付けの方が嬉しいのでは？
上記の作業で一番気になったのが既存リソースからIaC化するリソースを選択式で選ぶ際に"こんなに掃除してないIAMロールがあるのか"と思いました。
そして、そのままインポートしてスタック追加削除すれば掃除できるのではと。
依存関係エラーが起きようともちょっとした作業くらいはこちらでやればいいですし。
対象は以下になるイメージでやってみようかと思います。
スキャン結果からIaC化するインポートは該当するリソースがないとエラーになります。
スキャンは一日に回数が限られているのでIaC化する対象を絞ったり工夫が必要です。
ストーリー例と解決方法は以下です。
- アカウント内全体スキャンを実施する
- アカウント内全体スキャン結果からVPCとEC2を選択してテンプレートBを作成する
- テンプレートBからスタック作成を行い、スタック削除することでリソースも削除される
- アカウント内全体スキャン結果からテンプレートAをもう一度作成しようとするとインポートできずにエラーが出る
- テンプレートリソースタブから既に消したVPCとEC2を削除する
- VPCとEC2を除いたIaCが出来上がる
という訳で作成します。
CDKのアセットが入ったS3なんかは選べないようになってましたね。
出来上がったコードは6000行！
自動で作られるロールも沢山ありました！
そしてスタック作成、削除を豪快にやってみました。
気ままにいじり倒したAWS環境のリソースを一気に削除しようとして何%が完全に消すことができて、何%が消せないのか全く想像ができませんでした。
消えなかったものは以下です。
- デフォルトVPCとその関連
- CloudFrontの～～～ポリシー
- S3バケット
- 特定のロール
https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/troubleshoot_roles.html#troubleshoot_roles_cant-edit-delete-role
[自分の AWS アカウント でロールを編集または削除できない]を参照 - AWSマネージドキー
この AWS マネージドキーは、AWS のサービスによってお客様に代わって作成、管理、使用されます。お客様には、アカウントの AWS マネージドキーを表示し、AWS CloudTrail ログでその使用を監査するためのアクセス許可があります。ただし、AWS マネージドキーのプロパティの変更、そのローテーション、キーポリシーの変更、またはその削除のスケジュール設定はできません。
S3はまだしも、削除できないロールは完全に頭から抜けてました。
CloudFrontはどこから消すんだろう..ぱっと見いない..見間違いだろうか..
感想
ルートテーブルとインターネットゲートウェイの依存関係エラーからちょっと気になることもありますが、
既存のリソースを確認して選んでIaC化できるのがAWSで完結しているのがいいなと思います。
検証したときのものが一部残っていたらしくそのあたりがきちんと消えていたり、
昔作ったロールがごっそり消えていたので掃除としては更によく感じました！