トラブルシューティング

最終更新日: 2020年11月9日
R8 | R9

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

Designerからの「転送」処理により、CodeCommitから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イメージ以上は保持しないようになっています。そのため、これ以上前に戻したい場合は CodeCommit にてどの時点のコミットに戻したいかを調べて、CodeBuildに戻したい時点のコミットIDを指定してビルドするという手順が必要になります。

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

転送したあとのアプリケーションを編集する

AWSマネージメントコンソール(Web画面)からCodeCommitにアクセスすると、作成したCodeCommitリポジトリに含まれるアプリケーション(例 wmsaapp1test-appなど)を直接、修正することができます。

しかしAWSマネージメントコンソール画面から直接編集すると、改行コードがCR LFとなってしまう問題があります。

いくつかのシェルスクリプト (run_tomcat.shなど) は、改行コードがLFでなければならないという制約があります。これらのファイルを修正してしまうと、ECSの実行時に起動に失敗してしまいます。

よって編集作業はAWSマネージメントコンソール画面を使わず、原則として次のようにしてください。

  1. 当該ファイルを(開発者のPCに)ダウンロードする。
  2. 改行コードが維持されるテキストエディタを使って修正する。
  3. CodeCommitリポジトリへアップロードする。

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

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

(詳細な手順を準備中)