テンプレートのデバッグプロセスを高速化するにはどうすればよいですか、または間違いを犯してから30分後に間違いに気づき続けるのですか?
複雑なCloudFormationテンプレート開発の反復速度の向上に特に焦点を当てた、いくつかのベストプラクティスの提案を次に示します。
CloudFormationツールを使用して、テンプレートとスタックの更新を検証します
AWSは、独自のベストプラクティスドキュメントでこれらの概要をすでに説明しているため、繰り返しません。
このステップのポイントは、スタックの作成/更新を実際に実行する前に、明らかな構文エラーまたは論理エラーをキャッチすることです。
リソースを分離してテストする
複雑なスタックで個々のCloudFormationリソースを使用する前に、より小さなスタンドアロンスタックで動作をテストすることにより、使用量の制限や通常の起動/破棄時間など、リソースの作成/更新/削除動作の全範囲を完全に理解してください。最初。
- サードパーティのカスタムリソースを開発または使用している場合は、言語プラットフォームに適したライブラリを使用して単体テストを記述し、アプリケーションロジックがすべてのユースケースで期待どおりに動作することを確認します。
- 個々のリソースが作成/更新/削除する時間は、基になるAPI呼び出しの動作に応じて、リソースタイプ間で大きく異なる可能性があることに注意してください。たとえば、複雑な
AWS::CloudFront::Distribution
リソースの作成/更新/削除には30〜60分かかる場合がありAWS::EC2::SecurityGroup
ますが、更新には数秒かかる場合があります。
- 個々のリソースには、実装にバグ/問題/制限がある場合があります。これは、はるかに大きなスタック内ではなく、単独でテストした場合のデバッグと回避策の開発がはるかに簡単です。個々のAWSアカウント設定に応じたAWSサービス制限、またはスタックを作成するリージョンに応じたサービスのリージョン可用性などの制限に注意してください。
複雑なスタックを少しずつ構築する
スタックの作成/更新を実行するときに、単一のリソースで障害が発生すると、スタックはリソース変更のセット全体をロールバックします。これにより、正常に作成された他のリソースが不必要に破壊され、長い複雑なスタックを構築するときに非常に長い時間がかかる可能性があります。関連するリソースの依存関係グラフ。
これに対する解決策は、スタックを小さな更新バッチで段階的に構築し、一度に1つ(またはいくつか)のリソースを追加することです。このように、リソースの作成/更新で障害が発生した場合、ロールバックによってスタックのリソース全体が破棄されることはなく、最新の更新で変更されたリソースのセットのみが破棄されます。
スタック更新の進行状況を監視する
作成/更新の実行中にスタックのイベントを表示して、スタック更新の進行状況を必ず監視してください。これは、個々のリソースに関するさらなる問題をデバッグするための開始点になります。