この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
この時期になると杉花粉へのヘイトが一気に高まるオンジーです！
Image BuilderはデフォルトでCloudWatch Logsへのログ出力が有効になっています。
いきなりですがphp7.4をインストールしてrebootテストを実行する簡単なパイプラインを組んで実行してみました。
Image Builderの基本的な使い方はこちらをご参考ください。
CloudWatch Logsに出力されるログは
- リアルタイムで見ることができるので初回実行時に見守るとき便利
- EC2上の標準出力と標準エラーがストリームで出力される
- 以下の様なトラブルシューティングか可能
- 「AccessDenied」「UnauthorizedOperation」が出力されたらIAMの権限不足を疑う
- 「TimedOut」が出力されたらNWの問題を疑う
しかしトラブルシューティングの際にこれだけだと限界があります。
例えばコマンドの実行エラー・APIのレスポンスエラー・EC2インスタンスやEBSのスペック不足での失敗といった要因は上記標準出力ではたどり着けないことが多いです。
そのためより詳細なログを見ることができるようにS3への出力を有効化します。
実際にやってみた
S3バケットを作成
今回は onzuka-test-imagebuilder という名前にしました。
S3バケットにアクセスするためのポリシーを追加する
Image BuilderではAMIをビルドおよびテストする一時的なEC2にIAMロールを設定します。
そのIAMロールに先ほど作成したバケットに対してPutObjectできるポリシーを追加します。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:PutObject"
],
"Resource": "arn:aws:s3:::onzuka-test-imagebuilder/*"
}
]
}
なお「AmazonSSMManagedInstanceCore」「EC2InstanceProfileForImageBuilder」はImage Builder用のEC2に必須のポリシーになります。
インフラストラクチャ設定を編集する
先ほどのIAMロールを選択しておきます。
「トラブルシューティング設定」より作成しておいたS3バケットを選択します。
インフラストラクチャ設定の編集が完了したら再度パイプラインを実行しますとS3にログが出力されました。
各ファイルについては以下のようになっており主に見ると良いのはapplication.logになります。
- 0__php-7-4-linux__1.0.0_1.yml
- 選択したビルドコンポーネントの実物
- 1__reboot-test-linux__1.0.0_1.yml
- 選択したテストコンポーネントの実物
- application.log
- より詳細なdebugレベルのログ
- chaining.json
- ビルド/テストコンポーネントの実行ログ
- console.log
- 標準出力/標準エラーログ(CloudWatch Logsと同等)
- detailedoutput.json
- オーケストレーションに関する全ての詳細情報を記述したファイル
(注意)Privateなサブネットで実行している際はS3へのエンドポイントも必要
Image Builder用のEC2はインターネットに出れる必要があります。
EC2を作成するPrivate subnetに、アクセス先のサービスのPrivateLinkを設定して通信経路を確保している場合はここにS3のPrivate Linkを更に追加する必要があります。
設定後は以下のようにImage Builderで必須の4つに加えてS3のエンドポイントが存在している状態になります。
参考
おわり
S3への保存コストは追加されますが困ったときのために基本的にはログ出力を有効にしておいた方が良さそうですね。 続きとして以下の小ネタもあります。
1
