トラブルシューティング AWS CodeBuild - AWS CodeBuild
Apache Maven が間違ったリポジトリのアーティファクトを参照しているビルドコマンドがデフォルトでルートとして実行されるファイル名に英語以外の文字が含まれているとビルドが失敗する場合がありますAmazon EC2 パラメータストアからパラメータを取得する際にビルドが失敗する場合がある CodeBuild コンソールでブランチフィルタにアクセスできない ビルドの成功または失敗を表示できない ビルドステータスがソースプロバイダに報告されないWindows Server Core 2019 プラットフォームの基本イメージが見つからず、選択できない buildspec ファイルの以前のコマンドが、以降のコマンドで認識されないエラー: キャッシュのダウンロード時に「アクセスが拒否される」エラー: 「BUILD_CONTAINER_UNABLE_TO_PULL_IMAGE」カスタムビルドイメージを使用した場合 エラー：「ビルドを完了する前にビルドコンテナがデッドが見つかりました。ビルドコンテナはメモリ不足か、Docker イメージはサポートされていません。 ErrorCode: 500」 Error: "Cannot connect to the Docker daemon" when running a build (ビルドの実行時に「Docker デーモンに接続できません」)エラー：CodeBuild 「ビルドプロジェクトを作成または更新するときに sts: を実行する権限がありませんAssumeRole」 エラー：「 の呼び出しエラー GetBucketAcl: バケット所有者が変更されているか、サービスロールに s3: を呼び出すアクセス許可がありませんGetBucketAcl」 エラー: ビルドの実行時に「アーティファクトのアップロードに失敗しました: 無効な ARN」エラー: 「Git のクローンに失敗しました: 'your-repository-URL' にアクセスできません: SSL 証明書の問題: 自己署名証明書」エラー: ビルドの実行時に「アクセスしようとしているバケットは、指定されたエンドポイントを使用してアドレス指定する必要があります」エラー: "このビルドイメージではランタイムバージョンを少なくとも 1 つ選択する必要があります。"ビルドキューのビルドが失敗するとエラー「QUEUED:INSUFFICIENT_SUBNET」が表示されるエラー：「キャッシュをダウンロードできません: RequestError: x509: システムルートをロードできませんでしたが、ルートが指定されていません」が原因でリクエストの送信に失敗しましたエラー：「S3 から証明書をダウンロードできません AccessDenied」エラー: 「認証情報を見つけることができません」 RequestError プロキシサーバー CodeBuild での実行時のタイムアウトエラービルドイメージ内に Bourne シェル (sh) が必要警告 (ビルドの実行時): 「ランタイムのインストールをスキップします。このビルドイメージではランタイムバージョンの選択はサポートされていません」エラー： JobWorker 「ID を確認できません」ビルドの開始の失敗ローカルにキャッシュされたビルドの GitHub メタデータへのアクセスAccessDenied: レポートグループのバケット所有者が S3 バケットの所有者と一致しません...

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

トラブルシューティング AWS CodeBuild

このトピックの情報を使用して、問題を特定、診断、対処します。 CodeBuild ビルドのログ記録とモニタリングを行って問題のトラブルシューティングを行う方法については、「」を参照してくださいログ記録とモニタリング。

トピック

Apache Maven が間違ったリポジトリのアーティファクトを参照している

問題： AWS CodeBuildが提供する Java ビルド環境で Maven を使用する場合、Maven は https://repo1.maven.org/maven2 の安全な中央 Maven リポジトリからビルドとプラグインの依存関係を取得します。これは、ビルドプロジェクトの pom.xml ファイルが別の場所を使用すると明示的に宣言した場合でも発生します。

考えられる原因： CodeBuild が提供する Java ビルド環境には、ビルド環境の /root/.m2 ディレクトリにsettings.xmlプリインストールされている という名前のファイルが含まれます。この settings.xml には次の宣言が含まれています。これにより、Maven が常に https://repo1.maven.org/maven2 で、セキュアな中央 Maven リポジトリからビルドおよびプラグインの依存関係を引き出すように指示されます。

<settings>
  <activeProfiles>
    <activeProfile>securecentral</activeProfile>
  </activeProfiles>
  <profiles>
    <profile>
      <id>securecentral</id>
      <repositories>
        <repository>
          <id>central</id>
          <url>https://repo1.maven.org/maven2</url>
          <releases>
            <enabled>true</enabled>
          </releases>
        </repository>
      </repositories>
      <pluginRepositories>
        <pluginRepository>
          <id>central</id>
          <url>https://repo1.maven.org/maven2</url>
          <releases>
            <enabled>true</enabled>
          </releases>
        </pluginRepository>
      </pluginRepositories>
    </profile>
  </profiles>
</settings>

推奨される解決策: 以下を実行してください。

  1. settings.xml ファイルをソースコードに追加します。

  2. この settings.xml ファイルでは、前述の settings.xml 形式をガイドとして使用して、Maven が代わりにビルドとプラグインの依存関係を取得するリポジトリを宣言します。

  3. ビルドプロジェクトの installフェーズで、 settings.xml に ファイルを構築環境の /root/.m2 ディレクトリにコピー CodeBuild するように指示します。たとえば、この動作を示す buildspec.yml ファイルの次のスニペットを考えてみましょう。

    version 0.2

phases:
  install:
    commands:
      - cp ./settings.xml /root/.m2/settings.xml

ビルドコマンドがデフォルトでルートとして実行される

Issue: AWS CodeBuild ビルドコマンドをルートユーザーとして実行します。これは、関連するビルドイメージの Dockerfile によって USER インストラクションが別のユーザーに設定された場合でも発生します。

原因： デフォルトでは、 はすべてのビルドコマンドをルートユーザーとして CodeBuild 実行します。

推奨される解決策: なし。

ファイル名に英語以外の文字が含まれているとビルドが失敗する場合があります

問題: 英語以外の文字 (漢字など) を含むファイル名のファイルを使用するビルドを実行すると、ビルドが失敗します。

考えられる原因： によって提供されるビルド環境 AWS CodeBuild では、デフォルトのロケールが に設定されていますPOSIX。 POSIXローカリゼーション設定は、米国以外の CodeBuild やファイル名との互換性が低くなります。 英語の文字 および により、関連するビルドが失敗する可能性があります。

推奨される解決策: buildspec ファイルの pre_build セクションに次のコマンドを追加します。これらのコマンドにより、ビルド環境はローカリゼーション設定に米国英語 UTF-8 を使用します。これは、米国以外の CodeBuild やファイル名と互換性があります。 英語の文字。

Ubuntu ベースのビルド環境の場合:

pre_build:
  commands:
    - export LC_ALL="en_US.UTF-8"
    - locale-gen en_US en_US.UTF-8
    - dpkg-reconfigure locales

Amazon Linux ベースのビルド環境の場合:

pre_build:
  commands:
    - export LC_ALL="en_US.utf8"

Amazon EC2 パラメータストアからパラメータを取得する際にビルドが失敗する場合がある

問題: ビルドが Amazon EC2 パラメータストアに保存されている 1 つ以上のパラメータの値を取得しようとすると、DOWNLOAD_SOURCE フェーズで「Parameter does not exist」というエラーが発生し、ビルドが失敗する。

考えられる原因： ビルドプロジェクトが依存するサービスロールに ssm:GetParametersアクションを呼び出すアクセス許可がないか、ビルドプロジェクトが によって生成 AWS CodeBuild され、 ssm:GetParametersアクションを呼び出すことができるサービスロールを使用していますが、パラメータには で始まらない名前が付けられています/CodeBuild/。

推奨される解決策:

  • サービスロールが によって生成されていない場合は CodeBuild、 が ssm:GetParametersアクション CodeBuild を呼び出せるように定義を更新します。たとえば、次のポリシーステートメントでは、ssm:GetParameters アクションを呼び出して /CodeBuild/ で始まる名前を持つパラメータを取得できます。

    {
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": "ssm:GetParameters",
      "Effect": "Allow",
      "Resource": "arn:aws:ssm:REGION_ID:ACCOUNT_ID:parameter/CodeBuild/*"
    }
  ]
}

  • サービスロールが によって生成された場合は CodeBuild、 が で始まる名前以外の名前で Amazon EC2 パラメータストアのパラメータ CodeBuild にアクセスできるように定義を更新します/CodeBuild/。たとえば、次のポリシーステートメントでは、ssm:GetParameters アクションを呼び出して指定された名前のパラメータを取得できます。

    {
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": "ssm:GetParameters",
      "Effect": "Allow",
      "Resource": "arn:aws:ssm:REGION_ID:ACCOUNT_ID:parameter/PARAMETER_NAME"
    }
  ]
}

CodeBuild コンソールでブランチフィルタにアクセスできない

問題： AWS CodeBuild プロジェクトを作成または更新するときに、ブランチフィルターオプションがコンソールで使用できない。

考えられる原因: ブランチフィルタオプションは廃止されました。このオプションはウェブフックフィルタグループに置き換えられています。これにより、 CodeBuild の新しいビルドをトリガーするウェブフックイベントの制御が強化されます。

推奨される解決策: ウェブフックフィルタの導入前に作成したブランチフィルタを移行するには、正規表現 HEAD_REF で ^refs/heads/branchName$ フィルタを使用してウェブフックフィルタグループを作成します。たとえば、ブランチフィルタの正規表現が ^branchName$ の場合、HEAD_REF フィルタに入力する更新後の正規表現は ^refs/heads/branchName$ です。詳細については、「Bitbucket ウェブフックイベント」および「 GitHub ウェブフックイベントのフィルタリング (コンソール）」を参照してください。

ビルドの成功または失敗を表示できない

問題: 再試行されたビルドの成功または失敗を確認できない。

考えられる原因: ビルドのステータスを報告するオプションが有効になっていません。

推奨される解決策： CodeBuild プロジェクトを作成または更新するときに、レポートビルドステータスを有効にします。このオプションは、ビルドをトリガーするときに CodeBuild にステータスを報告するように指示します。詳細については、AWS CodeBuild API リファレンスの reportBuildStatus を参照してください。

ビルドステータスがソースプロバイダに報告されない

問題： GitHub または Bitbucket などのソースプロバイダーへのビルドステータスレポートを許可した後、ビルドステータスは更新されません。

考えられる原因: ソースプロバイダーに関連付けられたユーザーに、リポジトリへの書き込みアクセス許可がありません。

推奨される解決策: ソースプロバイダーにビルドステータスを報告できるようにするには、ソースプロバイダーに関連付けられたユーザーがリポジトリへの書き込みアクセス権を持っている必要があります。ユーザーが書き込みアクセス権を持っていない場合、ビルドのステータスは更新できません。詳細については、「ソースプロバイダーのアクセス」を参照してください。

Windows Server Core 2019 プラットフォームの基本イメージが見つからず、選択できない

問題: Windows Server Core 2019 プラットフォームの基本イメージを検索または選択できない。

考えられる原因： このイメージをサポートしていない AWS リージョンを使用しています。

推奨される解決策: Windows Server Core 2019 プラットフォームの基本イメージがサポートされている、次のいずれかの AWS リージョンを使用します。

  • 米国東部（バージニア北部）

  • 米国東部 (オハイオ)

  • 米国西部 (オレゴン)

  • 欧州 (アイルランド)

buildspec ファイルの以前のコマンドが、以降のコマンドで認識されない

問題: buildspec ファイルの 1 つ以上のコマンドの結果が、同じ buildspec ファイルの以降のコマンドで認識されない。たとえば、コマンドによってローカル環境変数が設定される場合がありますが、後で実行されるコマンドがそのローカル環境変数の値を取得できない可能性があります。

考えられる原因: buildspec ファイルバージョン 0.1 では、 AWS CodeBuild はビルド環境のデフォルトシェルの各インスタンスで各コマンドを実行します。つまり、各コマンドは他のすべてのコマンドとは独立して実行されます。デフォルトでは、以前のコマンドの状態に依存する単一のコマンドを実行することはできません。

推奨される解決策: buildspec バージョン 0.2 を使用してください。これにより、問題が解決されます。何らかの理由で buildspec バージョン 0.1 を使用する必要がある場合は、シェルコマンド連鎖演算子 (Linux の && など) を使用して、複数のコマンドを 1 つのコマンドにまとめることをお勧めします。または、複数のコマンドを含むソースコードにシェルスクリプトを組み込み、そのシェルスクリプトを buildspec ファイルの 1 つのコマンドから呼び出します。詳細については、「ビルド環境のシェルとコマンド」および「ビルド環境の環境変数」を参照してください。

エラー: キャッシュのダウンロード時に「アクセスが拒否される」

問題: キャッシュが有効になっているビルドプロジェクトでキャッシュをダウンロードしようとすると、Access denied エラーが発生する。

考えられる原因:

  • ビルドプロジェクトの一部としてキャッシングが設定されています。

  • キャッシュは、InvalidateProjectCache API により最近無効化されています。

  • によって使用されているサービスロールには、キャッシュを保持している S3 バケットに対する s3:GetObjectおよび アクセスs3:PutObject許可 CodeBuild がありません。

推奨される解決策: キャッシュ設定を更新した直後に初めて使用する場合、このエラーが表示されるのは普通です。このエラーが解消されない場合は、キャッシュを保持する S3 バケットへの s3:GetObject アクセス許可と s3:PutObject アクセス許可が、サービスロールに付与されているかどうかを確認する必要があります。詳細については、「Amazon S3 デベロッパーガイド」の「S3 アクセス許可の指定」を参照してください。

エラー: 「BUILD_CONTAINER_UNABLE_TO_PULL_IMAGE」カスタムビルドイメージを使用した場合

問題: カスタムビルドイメージを使用するビルドを実行しようとすると、ビルドは BUILD_CONTAINER_UNABLE_TO_PULL_IMAGE というエラーで失敗する。

考えられる原因: ビルドイメージの全体的な非圧縮サイズが、ビルド環境のコンピューティングタイプの使用可能ディスクスペースよりも大きい。ビルドイメージのサイズを確認するには、Docker を使用して docker images REPOSITORY:TAG コマンドを実行します。コンピューティングタイプで使用可能なディスク容量のリストについては、「ビルド環境のコンピューティングモードおよびタイプ」を参照してください。

推奨される解決策: 使用可能なディスク容量の大きなコンピューティングタイプを使用するか、カスタムビルドイメージのサイズを縮小します。

考えられる原因： AWS CodeBuild Amazon Elastic Container Registry (Amazon ECR) からビルドイメージをプルするアクセス許可がない。

推奨される解決策： がカスタムビルドイメージをビルド環境に CodeBuild プルできるように、Amazon ECR のリポジトリのアクセス許可を更新します。詳細については、「Amazon ECR のサンプル」を参照してください。

考えられる原因： リクエストした Amazon ECR イメージは、 AWS アカウントが使用している AWS リージョンでは使用できません。

推奨される解決策： AWS アカウントが使用しているイメージと同じ AWS リージョンにある Amazon ECR イメージを使用します。

考えられる原因： パブリックインターネットアクセスがない VPC でプライベートレジストリを使用しています。VPC のプライベート IP アドレスからイメージをプル CodeBuild することはできません。詳細については、「 の AWS Secrets Manager サンプルを使用したプライベートレジストリ CodeBuild」を参照してください。

推奨される解決策: VPC でプライベートレジストリを使用する場合は、VPC にパブリックインターネットアクセスがあることを確認してください。

考えられる原因: エラーメッセージに「toomanyrequests」が含まれており、イメージを Docker Hub から取得した場合、このエラーは Docker Hub のプル制限に達したことを意味します。

推奨される解決策: Docker Hub のプライベートレジストリを使用するか、Amazon ECR からイメージを取得します。プライベートレジストリの使用の詳細については、「 の AWS Secrets Manager サンプルを使用したプライベートレジストリ CodeBuild」を参照してください。Amazon ECR の使用方法の詳細については、「の Amazon ECR サンプル CodeBuild 」を参照してください。

エラー：「ビルドを完了する前にビルドコンテナがデッドが見つかりました。ビルドコンテナはメモリ不足か、Docker イメージはサポートされていません。 ErrorCode: 500」

問題： で Microsoft Windows または Linux コンテナを使用しようとすると AWS CodeBuild、このエラーは PROVISIONING フェーズ中に発生します。

考えられる原因:

  • コンテナ OS バージョンは、 ではサポートされていません CodeBuild。

  • HTTP_PROXY、HTTPS_PROXY、またはその両方がコンテナで指定されます。

推奨される解決策:

  • Microsoft Windows の場合は、Windows コンテナを、コンテナ OS バージョン microsoft/windowsservercore:10.0.x (microsoft/windowsservercore:10.0.14393.2125 など) で使用します。

  • Linux の場合は、Docker イメージの HTTP_PROXY 設定と HTTPS_PROXY 設定をクリアするか、ビルドプロジェクトで VPC 設定を指定します。

Error: "Cannot connect to the Docker daemon" when running a build (ビルドの実行時に「Docker デーモンに接続できません」)

問題: ビルドが失敗し、「Cannot connect to the Docker daemon at unix:/var/run/docker.sock. Is the docker daemon running?」のようなエラーがビルドログに表示される。

考えられる原因: 特権モードでビルドを実行していません。

推奨される解決策: このエラーを修正するには、特権モードを有効にし、次の手順を使用して buildspec を更新する必要があります。

ビルドを特権モードで実行するには、次の手順に従います。

  1. https://console.aws.amazon.com/codebuild/ で CodeBuild コンソールを開きます。

  2. ナビゲーションペインで、ビルドプロジェクト を選択し、ビルドプロジェクトを選択します。

  3. [Edit] (編集) から [Environment] (環境) を選択します。

  4. [Additional configuration (追加設定)] を選択します。

  5. 特権 から、Docker イメージを構築する場合、またはビルドで昇格された権限を取得したい場合は、このフラグを有効にする を選択します。

  6. [Update environment (環境の更新)] を選択します。

  7. [ビルドの開始] を選択してビルドを再度実行します。

また、コンテナ内で Docker デーモンを起動する必要があります。buildspec の installフェーズは次のようになります。

phases:
  install:
    commands:
      - nohup /usr/local/bin/dockerd --host=unix:///var/run/docker.sock --host=tcp://127.0.0.1:2375 --storage-driver=overlay2 &
      - timeout 15 sh -c "until docker info; do echo .; sleep 1; done"

buildspec ファイルで参照される OverlayFS ストレージドライバーの詳細については、Docker ウェブサイトの「Use the OverlayFS storage driver」を参照してください。

注記

基本オペレーティングシステムが Alpine Linux である場合は、buildspec.yml で -t 引数を timeout に追加します。

- timeout -t 15 sh -c "until docker info; do echo .; sleep 1; done"

を使用して Docker イメージを構築および実行する方法の詳細については AWS CodeBuild、「」を参照してくださいのカスタムイメージサンプルの Docker CodeBuild 。

エラー：CodeBuild 「ビルドプロジェクトを作成または更新するときに sts: を実行する権限がありませんAssumeRole」

問題: ビルドプロジェクトを作成または更新しようとすると、エラー「Code:InvalidInputException, Message:CodeBuild is not authorized to perform: sts:AssumeRole on arn:aws:iam::account-ID:role/service-role-name」が発生する。

考えられる原因:

  • AWS Security Token Service （AWS STS) は、ビルドプロジェクトを作成または更新しようとしている AWS リージョンで非アクティブ化されています。

  • ビルドプロジェクトに関連付けられた AWS CodeBuild サービスロールが存在しないか、 を信頼するための十分なアクセス許可がありません CodeBuild。

推奨される解決策:

  • ビルドプロジェクトを作成または更新しようとしている AWS リージョンで AWS STS が有効になっていることを確認します。詳細については、IAM ユーザーガイドの「 AWS リージョン AWS STS での のアクティブ化と非アクティブ化」を参照してください。

  • ターゲット CodeBuild サービスロールが AWS アカウントに存在することを確認します。コンソールを使用していない場合は、ビルドプロジェクトを作成または更新したときにサービスロールの Amazon リソースネーム (ARN) のスペルを間違えていないことを確認してください。

  • ターゲット CodeBuild サービスロールに、 を信頼するための十分なアクセス許可があることを確認します CodeBuild。詳細については、CodeBuild サービスロールの作成の「信頼関係のポリシーステートメント」を参照してください。

エラー：「 の呼び出しエラー GetBucketAcl: バケット所有者が変更されているか、サービスロールに s3: を呼び出すアクセス許可がありませんGetBucketAcl」

問題: ビルドを実行すると、S3 バケット所有者や GetBucketAcl アクセス許可の変更に関するエラーが発生する。

考えられる原因: s3:GetBucketAcl および s3:GetBucketLocation のアクセス許可を IAM ロールに追加しています。これらのアクセス許可は、プロジェクトの S3 バケットを保護し、バケットにアクセスできるユーザーを自分に限定します。これらのアクセス許可を追加した後で、S3 バケットの所有者が変更されています。

推奨される解決策: S3 バケットの所有者が自分であることを確認し、IAM ロールへのアクセス許可を追加し直します。詳細については、「S3 バケットへの安全なアクセス」を参照してください。

エラー: ビルドの実行時に「アーティファクトのアップロードに失敗しました: 無効な ARN」

問題: ビルドを実行すると、UPLOAD_ARTIFACTS ビルドフェーズが失敗し、「Failed to upload artifacts: Invalid arn」というエラーが表示される。

考えられる原因： S3 出力バケット ( がビルドからの出力 AWS CodeBuild を保存するバケット) が、 CodeBuild ビルドプロジェクトとは異なる AWS リージョンにある。

推奨される解決策： ビルドプロジェクトと同じ AWS リージョンにある出力バケットを指すようにビルドプロジェクトの設定を更新します。

エラー: 「Git のクローンに失敗しました: 'your-repository-URL' にアクセスできません: SSL 証明書の問題: 自己署名証明書」

問題: ビルドプロジェクトを実行しようとすると、このエラーが発生してビルドが失敗する。

考えられる原因: ソースリポジトリには自己署名証明書がありますが、S3 バケットから証明書をビルドプロジェクトの一部としてインストールする選択をしていません。

推奨される解決策:

  • プロジェクトを編集します。[証明書] で [S3 から証明書をインストールする] を選択します。[証明書のバケット] では、SSL 証明書が保存されている S3 バケットを選択します。[証明書のオブジェクトキー] に、S3 オブジェクトキーの名前を入力します。

  • プロジェクトを編集します。Enterprise Server プロジェクトリポジトリへの接続中に SSL 警告を無視するには、安全でない SSL GitHub を選択します。

    注記

    [Insecure SSL] はテストのみに使用することが推奨されます。本番環境では使用しないでください。

エラー: ビルドの実行時に「アクセスしようとしているバケットは、指定されたエンドポイントを使用してアドレス指定する必要があります」

問題: ビルドを実行すると、DOWNLOAD_SOURCE ビルドフェーズが失敗し、「The bucket you are attempting to access must be addressed using the specified endpoint. Please send all future requests to this endpoint」というエラーが表示される。

考えられる原因： 構築済みのソースコードが S3 バケットに保存され、そのバケットがビルドプロジェクトとは異なる AWS CodeBuild AWS リージョンにある。

推奨される解決策: 構築済みのソースコードが含まれているバケットを指すように、ビルドプロジェクトの設定を更新します。バケットがビルドプロジェクトと同じ AWS リージョンにあることを確認します。

エラー: "このビルドイメージではランタイムバージョンを少なくとも 1 つ選択する必要があります。"

問題: ビルドを実行すると、DOWNLOAD_SOURCE ビルドフェーズが失敗し、「YAML_FILE_ERROR: This build image requires selecting at least one runtime version」というエラーが表示される。

考えられる原因: ビルドでバージョン 1.0 以降の Amazon Linux 2 (AL2) 標準イメージ、またはバージョン 2.0 以降の Ubuntu 標準イメージが使用されていますが、buildspec ファイルでランタイムが指定されていません。

推奨される解決策： aws/codebuild/standard:2.0 CodeBuild マネージドイメージを使用する場合は、buildspec ファイルの runtime-versionsセクションでランタイムバージョンを指定する必要があります。たとえば、PHP を使用するプロジェクトでは、次の buildspec ファイルを使用します。

version: 0.2

phases:
  install:
    runtime-versions:
        php: 7.3
  build:
    commands:
      - php --version
artifacts:
  files:
    -  README.md
注記

runtime-versions セクションを指定して、Ubuntu 標準イメージ 2.0 以降や Amazon Linux 2 (AL2) 標準イメージ 1.0 以降以外のイメージを使用した場合は、ビルドで「Skipping install of runtimes. Runtime version selection is not supported by this build image」の警告が表示されます。

詳細については、「Specify runtime versions in the buildspec file」を参照してください。

ビルドキューのビルドが失敗するとエラー「QUEUED:INSUFFICIENT_SUBNET」が表示される

問題: ビルドキューのビルドが QUEUED: INSUFFICIENT_SUBNET のようなエラーで失敗する。

考えられる原因: VPC に指定された IPv4 CIDR ブロックが、リザーブド IP アドレスを使用している。各サブネット CIDR ブロックの最初の 4 つの IP アドレスと最後の IP アドレスは使用できず、インスタンスに割り当てることができません。たとえば、CIDR ブロック 10.0.0.0/24 を持つサブネットの場合、次の 5 つの IP アドレスが予約されます。

  • 10.0.0.0: ネットワークアドレスです。

  • 10.0.0.1: VPC ルーター AWS 用に によって予約されています。

  • 10.0.0.2: によって予約されています AWS。DNS サーバーの IP アドレスは、常に VPC ネットワークのベースに 2 を付加したものですが、各サブネット範囲のベースに 2 を付加したアドレスも予約されています。複数の CIDR ブロックを持つ VPC の場合、DNS サーバーの IP アドレスはプライマリ CIDR にあります。詳細については、Amazon VPC ユーザーガイドの「Amazon DNS サーバー」を参照してください。

  • 10.0.0.3: 将来の使用 AWS のために によって予約されています。

  • 10.0.0.255: ネットワークブロードキャストアドレスです。VPC でのブロードキャストはサポートされていません。このアドレスは予約されています。

推奨される解決策: VPC でリザーブド IP アドレスが使用されていることを確認します。予約済みの IP アドレスを、予約されていないアドレスに置き換えます。詳細については、Amazon VPC ユーザーガイドのVPC とサブネットのサイズ設定を参照してください。

エラー：「キャッシュをダウンロードできません: RequestError: x509: システムルートをロードできませんでしたが、ルートが指定されていません」が原因でリクエストの送信に失敗しました

問題: ビルドプロジェクトを実行しようとすると、このエラーが発生してビルドが失敗する。

考えられる原因: ビルドプロジェクトの一部としてキャッシュを設定し、有効期限が切れたルート証明書を含む古い Docker イメージを使用しています。

推奨される解決策： AWS CodeBuild プロジェクトで使用されている Docker イメージを更新します。詳細については、「が提供する Docker イメージ CodeBuild」を参照してください。

エラー：「S3 から証明書をダウンロードできません AccessDenied」

問題: ビルドプロジェクトを実行しようとすると、このエラーが発生してビルドが失敗する。

考えられる原因:

  • 証明書に正しくない S3 バケットが選択されています。

  • 証明書に誤ったオブジェクトキーが入力されています。

推奨される解決策:

  • プロジェクトを編集します。[証明書のバケット] では、SSL 証明書が保存されている S3 バケットを選択します。

  • プロジェクトを編集します。[証明書のオブジェクトキー] に、S3 オブジェクトキーの名前を入力します。

エラー: 「認証情報を見つけることができません」

問題： を実行したり AWS CLI、 SDK を使用した AWS り、ビルドの一部として別の類似コンポーネントを呼び出したりしようとすると、 AWS CLI、 AWS SDK、または コンポーネントに直接関連するビルドエラーが発生します。たとえば、「Unable to locate credentials」などのビルドエラーが発生する場合があります。

考えられる原因:

  • ビルド環境の AWS CLI、 AWS SDK、またはコンポーネントのバージョンは、 と互換性がありません AWS CodeBuild。

  • Docker を使用するビルド環境で Docker コンテナを実行しており、コンテナはデフォルトで AWS 認証情報にアクセスできません。

推奨される解決策:

  • ビルド環境の AWS CLI、 AWS SDK、または コンポーネントのバージョンが次の 以上であることを確認します。

    • AWS CLI: 1.10.47

    • AWS SDK for C++: 0.2.19

    • AWS SDK for Go: 1.2.5

    • AWS SDK for Java: 1.11.16

    • AWS の SDK JavaScript: 2.4.7

    • AWS SDK for PHP: 3.18.28

    • AWS SDK for Python (Boto3): 1.4.0

    • AWS SDK for Ruby: 2.3.22

    • Botocore: 1.4.37

    • CoreCLR: 3.2.6-beta

    • Node.js: 2.4.7

  • ビルド環境で Docker コンテナを実行する必要があり、コンテナに AWS 認証情報が必要な場合は、ビルド環境からコンテナに認証情報を渡す必要があります。buildspec ファイルでは、以下のような Docker run コマンドを組み込みます。この例では、aws s3 ls コマンドを使用して、使用可能な S3 バケットを一覧表示します。-e オプションは、コンテナが AWS 認証情報にアクセスするために必要な環境変数を渡します。

    docker run -e AWS_DEFAULT_REGION -e AWS_CONTAINER_CREDENTIALS_RELATIVE_URI your-image-tag aws s3 ls

  • Docker イメージを構築し、ビルドに AWS 認証情報が必要な場合 (Amazon S3 からファイルをダウンロードする場合など）、ビルド環境から Docker ビルドプロセスに認証情報を次のように渡す必要があります。

    1. Docker イメージ用ソースコードの Dockerfile に、次の ARG インストラクションを指定します。

      ARG AWS_DEFAULT_REGION
ARG AWS_CONTAINER_CREDENTIALS_RELATIVE_URI

    2. buildspec ファイルでは、以下のような Docker build コマンドを組み込みます。--build-arg オプションは、Docker ビルドプロセスが AWS 認証情報にアクセスするために必要な環境変数を設定します。

      docker build --build-arg AWS_DEFAULT_REGION=$AWS_DEFAULT_REGION --build-arg AWS_CONTAINER_CREDENTIALS_RELATIVE_URI=$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI -t your-image-tag .

RequestError プロキシサーバー CodeBuild での実行時のタイムアウトエラー

問題: 次のいずれかのような RequestError エラーが表示される。

  • RequestError: send request failed caused by: Post https://logs.<your-region>.amazonaws.com/: dial tcp 52.46.158.105:443: i/o timeout CloudWatch Logs から。

  • Error uploading artifacts: RequestError: send request failed caused by: Put https://your-bucket.s3.your-aws-region.amazonaws.com/*: dial tcp 52.219.96.208:443: connect: connection refusedAmazon S3 の 。

考えられる原因:

  • ssl-bump が適切に設定されていません。

  • 組織のセキュリティポリシーで ssl_bump を使用することが許可されていません。

  • buildspec ファイルに、proxy 要素を使用して指定されたプロキシ設定がありません。

推奨される解決策:

  • ssl-bump が適切に設定されていることを確認します。プロキシサーバーに Squid を使用している場合は、「 明示的なプロキシサーバーとしての Squid の設定」を参照してください。

  • Amazon S3 と Logs のプライベートエンドポイントを使用するには、次の手順に従います。 CloudWatch

    1. プライベートサブネットのルーティングテーブルで、インターネット用トラフィックをプロキシサーバーにルーティングする追加済みのルールを削除します。詳細については、「Amazon VPC ユーザーガイド」の「VPC でサブネットを作成する」を参照してください。

    2. プライベート Amazon S3 エンドポイントと CloudWatch Logs エンドポイントを作成し、Amazon VPC のプライベートサブネットに関連付けます。詳細については、「Amazon VPC ユーザーガイド」の「VPC エンドポイントサービス」を参照してください。

    3. Amazon VPC の [プライベート DNS 名を有効にする] が選択されていることを確認します。詳細については、Amazon VPC ユーザーガイドのインターフェイスエンドポイントの作成を参照してください。

  • 明示的なプロキシサーバーに ssl-bump を使用しない場合は、proxy 要素を使用して buildspec ファイルにプロキシ設定を追加します。詳細については、「 明示的なプロキシサーバーでの CodeBuild の実行」および「buildspec の構文」を参照してください。

    version: 0.2
proxy:
  upload-artifacts: yes
  logs: yes
phases:
  build:
    commands:

ビルドイメージ内に Bourne シェル (sh) が必要

問題： によって提供されていないビルドイメージを使用していて AWS CodeBuild、ビルドが失敗してメッセージ が表示されるBuild container found dead before completing the build。

考えられる原因： Bourne シェル (sh) は、ビルドコマンドとスクリプトを実行するshためにビルド image. CodeBuild needs に含まれていません。

推奨される解決策: ビルドイメージに sh が含まれていない場合、イメージを使用するビルドを開始する前に必ずそれを含めてください  （ビルドイメージshにCodeBuild は既に が含まれています）。

警告 (ビルドの実行時): 「ランタイムのインストールをスキップします。このビルドイメージではランタイムバージョンの選択はサポートされていません」

問題: ビルドを実行すると、この警告がビルドログに表示される。

考えられる原因: ビルドでバージョン 1.0 以降の Amazon Linux 2 (AL2) 標準イメージ、またはバージョン 2.0 以降の Ubuntu 標準イメージが使用されておらず、buildspec ファイルの runtime-versions セクションにランタイムが指定されています。

推奨される解決策: buildspec ファイルに runtime-versions セクションが含まれていないことを確認します。runtime-versions セクションは、Amazon Linux 2 (AL2) 標準イメージ以降または Ubuntu 標準イメージのバージョン 2.0 以降を使用する場合にのみ必要です。

エラー: CodeBuild コンソールを開くときに JobWorker 「ID を確認できません」

問題： CodeBuild コンソールを開くと、 JobWorker 「ID を確認できません」というエラーメッセージが表示されます。

考えられる原因: コンソールのアクセスに使用されている IAM ロールに、jobId をキーとするタグがあります。このタグキーは 用に予約 CodeBuild されており、存在する場合はこのエラーが発生します。

推奨される解決策: jobId キーを持つカスタム IAM ロールタグを変更して、jobIdentifier などの別のキーを持つようにします。

ビルドの開始の失敗

問題: ビルドを開始すると、「ビルドを開始できませんでした」というエラーメッセージが表示される。

考えられる原因: 同時に実行できるビルド数の上限に達しています。

推奨される解決策: 他のビルドが完了するまで待つか、プロジェクトの同時実行のビルド制限を増やして、ビルドを再度開始します。詳細については、「プロジェクトの設定」を参照してください。

ローカルにキャッシュされたビルドの GitHub メタデータへのアクセス

問題: 状況によっては、キャッシュされたビルドの .git ディレクトリは、ディレクトリではなく、テキストファイルである場合があります。

考えられる原因： ビルドでローカルソースキャッシュが有効になっている場合、 は .git ディレクトリの gitlink CodeBuild を作成します。つまり、.git ディレクトリは、単にディレクトリへのパスを含むテキストファイルです。

推奨される解決策: すべての場合において、次のコマンドを使用して Git メタデータディレクトリを取得します。このコマンドは、.git のフォーマットに関係なく機能します。

git rev-parse --git-dir

AccessDenied: レポートグループのバケット所有者が S3 バケットの所有者と一致しません...

問題： テストデータを Amazon S3 バケットにアップロードすると、 CodeBuild はテストデータをバケットに書き込めません。

考えられる原因:

  • レポートグループのバケット所有者に指定されたアカウントが、Amazon S3 バケットの所有者と一致しません。

  • サービスロールには、バケットへの書き込みアクセスがありません。

推奨される解決策:

  • Amazon S3 バケットの所有者と一致するよう、レポートグループのバケット所有者を変更します。

  • Amazon S3 バケットへの書き込みアクセスを許可するようにサービスロールを変更します。