あえて失敗させて、
CloudWatch Logsで原因を探す

手順に迷ったときや、用語の意味を確かめたいときに開きましょう。

※ リンク切れの場合は、ページタイトルで検索してください。

フェーズ詳細だけを見る場合と、CloudWatch Logsまで見る場合とで、分かる情報の深さが変わります。

以下の要件を満たし、失敗の調査から修正までの一連の流れを体験してください。

「あえて失敗するソースを準備する」→「実行して失敗を確認する」→「ログで原因を特定し、修正する」という順番で進めます。

1. フェーズ1 — あえて失敗するソースを準備する

2. マネジメントコンソールにサインインし、リージョンを合わせる

   ブラウザで AWS マネジメントコンソールにサインインし、画面右上のリージョンが「アジアパシフィック（東京）ap-northeast-1」になっていることを確認します。

3. あえて失敗するbuildspec.ymlを作成し、ZIPにまとめる

   次の内容で buildspec.yml を作成します。cat コマンドが、存在しないファイルを読み込もうとする内容です。

   version: 0.2
   
   phases:
     build:
       commands:
         - echo "ビルドを開始します"
         - cat does-not-exist.txt

   このファイル1つだけをZIPにまとめます（他のファイルは不要です）。

4. S3バケットを作成し、ZIPをアップロードする

   入力用のS3バケットを1つ作成し（名前は一意に、例：codebuild-debug-input-yourname）、手順2で作成したZIPをアップロードします。

5. フェーズ2 — 実行して失敗を確認する

6. CodeBuildプロジェクトを作成し、ビルドを実行する

   CodeBuildコンソールで、ソースプロバイダーに「Amazon S3」を選び、手順3のバケットとZIPのオブジェクトキーを指定してプロジェクトを作成します。環境はマネージド型イメージ・Amazon Linux・Standardのままでよく、Artifactsは「No artifacts」のままで構いません。プロジェクトを作成したら「ビルドを開始」を選びます。

7. フェーズ詳細でステータスを確認する

   ビルドが完了すると、ステータスが「Failed」になります。フェーズ詳細の一覧で、どのフェーズ（おそらくBUILD）に失敗のマークが付いているかを確認します。

8. フェーズ3 — ログで原因を特定し、修正する

9. CloudWatch Logsのビルドログを開く

   ビルド詳細ページの「ビルドログ」を確認し、「View entire log（ログ全体を表示）」からCloudWatch Logsのログストリームを開きます。ログの末尾付近に、実行したコマンドとエラーメッセージが記録されています。

   [Container] ビルドを開始します
   cat: does-not-exist.txt: No such file or directory

10. buildspec.ymlを修正し、再実行する

    原因（存在しないファイルを参照していること）に対応する形で、cat does-not-exist.txt の行を削除（または存在するファイルを参照する内容に変更）し、ZIPを作り直して同じS3バケットにアップロードします。CodeBuildプロジェクトの設定でオブジェクトキーが同じであれば、再度「ビルドを開始」するだけで新しい内容が反映されます。

    これがゴール

    最初は何が起きているのか分からなかった失敗が、ログを見て原因が特定でき、修正後にSucceededへ変わる——この一連の流れを確認できたら、このハンズオンの目的は達成です。

初学者がよく引っかかる箇所を先回りでまとめました。答えそのものは載せていませんが、「どこを見直すか」の手がかりとして使ってください。

要件の再確認ではなく、画面のどこを見れば達成を確認できるかをまとめました。次を順に確かめましょう。

• 最初のビルドの履歴で、ステータスが「Failed」になっている。
• フェーズ詳細で、BUILD フェーズに失敗のマークが付いている。
• CloudWatch Logsのログに、No such file or directory のようなエラーメッセージが表示されている。
• 修正後に再実行したビルドの履歴で、ステータスが「Succeeded」に変わっている。

手を動かすことに加えて、次の問いに自分の言葉で答えられるようにしておくと、理解がより深まります。

1. ログを見る習慣がない場合、原因の特定にどれくらい時間がかかりそうでしょうか。
   ヒント

   エラーメッセージを読まずに、コードを推測だけで直そうとした場合との違いを考えてみましょう。
2. 同じような失敗が何度も起きる場合、どのような対策が考えられるでしょうか。
   ヒント

   毎回ログを見て直す方法と、最初からミスが起きにくい仕組みにしておく方法、それぞれの手間を比べてみましょう。
3. ビルドが失敗したことに、人が気づかずに放置されてしまうと、どんな問題が起こり得るでしょうか。
   ヒント

   失敗を自動的に知らせる仕組みがない場合、誰がいつ気づくのかを考えてみましょう（このハンズオンでは扱っていない発展的な内容です）。

作成したリソースを順番に削除します。

1. CodeBuildプロジェクトを削除する：CodeBuildコンソールのプロジェクト一覧から削除します。
2. CloudWatch Logsのロググループを削除する：プロジェクトを削除してもログは自動的には消えません。不要であれば、CloudWatch Logsコンソールから該当のロググループ（/aws/codebuild/プロジェクト名）を削除します。
3. 自動作成されたIAMロールを削除する：プロジェクト作成時に新規作成したサービスロールが残っている場合は、IAMコンソールから削除します。
4. S3バケットを空にして削除する：入力用バケットの中身を削除してから、バケット本体を削除します。