トラブルシューティング

最終更新日: 2025年1月6日
R8 | R9

CodePipelineを使わずにCodeBuildを手動で実行する

Designerからの「転送」処理により、S3からCodeBuildへ進み、このときにDockerイメージを作成します。しかし何らかの問題が発生してイメージの作成に失敗した場合、この作成処理を手動で行う方法を説明します。

Dockerイメージの作成

次のコマンドを実行します。

aws codebuild start-build --project-name wmsaapp1test

コマンドの出力例を示します。

{
    "build": {
        "id": "wmsaapp1test:aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee",
        "arn": "arn:aws:codebuild:ap-northeast-1:000000000000:build/wmsaapp1test:aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee",
        "buildNumber": 1,
        "startTime": "2020-07-01T14:46:46.070000+09:00",
        "currentPhase": "QUEUED",
        "buildStatus": "IN_PROGRESS",
...

次のコマンドで現在の進捗を確認します。

aws codebuild batch-get-builds --ids "wmsaapp1test:aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee" --query builds[0].currentPhase
aws codebuild batch-get-builds --ids "wmsaapp1test:aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee" --query builds[0].buildStatus

これらのコマンドで、それぞれ currentPhase 値と buildStatus 値を確認することができます。

起動に失敗するアプリケーションを転送した

"起動に失敗するアプリケーション" とは、コンパイルエラーが残っている、もしくは設定ファイルが古い状態にも関わらずフルビルドした状態のアプリケーションを指します。

このような(起動に失敗する)アプリケーションを転送した場合、CodePipeline処理の途中で失敗を検出し、転送の直前に実行していた環境(コンテナ)に戻します。

直前ではなく任意の環境(コンテナ)に戻したい場合は、ECSのタスク定義を修正する必要があります。具体的には、戻したいDockerイメージのリビジョンを指定して、ECSのサービスに修正したタスク定義を指定するという手順となります。

ただし、ECRは容量の都合上、3イメージ以上は保持しないようになっています。そのため、これ以上前に戻したい場合は S3 にてどの時点の転送に戻したいかを調べて、CodeBuildに戻したい時点のコミットIDを指定してビルドするという手順が必要になります。

(具体的手順は複雑になるため、割愛します。Premium Support でお問い合わせください。)

環境に関する調査が必要な場合

データベースやEFS、Dockerイメージの中身を調査したい場合があるかも知れません。この場合は別途、EC2インスタンスを作成し、そのEC2インスタンスにSSHログオンして調査を行うとよいでしょう。

(詳細な手順は割愛します。)