のトラブルシューティング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 に問題が発生しています」エラー : ビルドプロジェクトを作成または更新する際、「CodeBuild は sts:AssumeRole の実行を許可されていません」 エラー: 「Error calling GetBucketAcl: バケット所有者が変更されたか、サービスロールに s3:GetBucketAcl を呼び出すアクセス許可がありません」 エラー: ビルドの実行時に「アーティファクトのアップロードに失敗しました: 無効な ARN」エラー: 「Git のクローンに失敗しました: 'your-repository-URL' にアクセスできません: SSL 証明書の問題: 自己署名証明書」エラー: ビルドの実行時に「アクセスしようとしているバケットは、指定されたエンドポイントを使用してアドレス指定する必要があります」エラー:「ポリシーのデフォルトバージョンが enhanced zero クリックロールの作成で作成されなかったか、enhanced zero クリックロールの作成で作成された最新バージョンではありませんでした。」エラー: "このビルドイメージではランタイムバージョンを少なくとも 1 つ選択する必要があります。"ビルドキューのビルドが失敗するとエラー「QUEUED:INSUFFICIENT_SUBNET」が表示されるエラー: 「キャッシュをダウンロードできません: RequestError: 送信リクエストは x509: システムのルートをロードできませんでした。ルートが指定されていません」エラー : 「S3 から証明書をダウンロードできません。AccessDenied"エラー: 「認証情報を見つけることができません」 RequestError プロキシCodeBuildサーバーで を実行する際のタイムアウトエラービルドイメージ内に Bourne シェル (sh) が必要警告 (ビルドの実行時): 「ランタイムのインストールをスキップします。このビルドイメージではランタイムバージョンの選択はサポートされていません」エラー: 「JobWorkerID を確認できません」ビルドの開始に失敗しましたローカルにキャッシュされたビルドのGitHubメタデータへのアクセスAccessDenied: レポートグループのバケット所有者が S3 バケットの所有者と一致しません...

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

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

トピック

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

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

考えられる原因: CodeBuild が提供する Java ビルド環境には、ビルド環境の settings.xml ディレクトリに事前にインストールされている /root/.m2 という名前のファイルが含まれています。この 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 フェーズで、CodeBuild ファイルをビルド環境の settings.xml ディレクトリにコピーするよう /root/.m2 に指示します。たとえば、この動作を示す buildspec.yml ファイルの次のスニペットを考えてみましょう。

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

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

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

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

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

ファイル名に米英語以外の文字が使用されていると、 英語の文字

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

考えられる原因: によって提供されるビルド環境AWS CodeBuildでは、デフォルトのロケールが に設定されていますPOSIXPOSIX のローカライズ設定は、 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 によって生成されていないサービスロールの場合は、その定義を更新して CodeBuild が ssm:GetParameters アクションを呼びだせるようにします。たとえば、次のポリシーステートメントでは、ssm:GetParameters アクションを呼び出して /CodeBuild/: で始まる名前を持つパラメータを取得できます。

    { "Version": "2012-10-17", "Statement": [ { "Action": "ssm:GetParameters", "Effect": "Allow", "Resource": "arn:aws:ssm:REGION_ID:ACCOUNT_ID:parameter/CodeBuild/*" } ] }
  • サービスロールが によって生成された場合はCodeBuild、その定義を更新して、 が で始まる名前以外の名前で CodeBuild パラメータストアのパラメータAmazon EC2にアクセスできるように/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 にステータスを報告するように指示します。詳細については、 reportBuildStatus API リファレンスAWS CodeBuildの「」を参照してください。

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

問題: 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 により最近無効化されています。

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

推奨される解決策: キャッシュ設定を更新した直後に初めて使用する場合、このエラーが表示されるのは普通です。このエラーが解消されない場合は、キャッシュを保持する S3 バケットへの s3:GetObject アクセス許可と s3:PutObject アクセス許可が、サービスロールに付与されているかどうかを確認する必要があります。詳細については、 https://docs.aws.amazon.com/AmazonS3/latest/dev/using-with-s3-actions.html 開発者ガイドのS3 アクセス許可Amazon 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) からビルドイメージをプルするアクセス許可がありません。

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

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

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

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

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

考えられる原因: エラーメッセージに "toomanyrequests", 、Docker Hub からイメージが取得されました。このエラーは、Docker Hub のプル制限に達したことを意味します。

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

エラー: 「ビルドの完了前にビルドコンテナの停止が検出されました。ビルドコンテナがメモリ不足のため停止したか、Docker イメージがサポートされていません」 ErrorCode: 500"

問題: AWS CodeBuild で Microsoft Windows または Linux コンテナを使用しようとすると、このエラーが 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?」のようなエラーがビルドログに表示される。

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

推奨される解決策: 特権モードでビルドを実行するには、次の手順に従います。

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

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

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

  4. Override images]、[環境.] の順に選択します。

  5. 環境イメージ、オペレーティングシステム、ランタイム、およびイメージを指定します。これらの設定は、失敗したビルドの設定と一致する必要があります。

  6. 特権付与.] を選択します。

    注記

    By default, Docker containers do not allow access to any devices. Privileged mode grants a build project's Docker container access to all devices. For more information, see Runtime Privilege and Linux Capabilities on the Docker Docs website.

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

  8. [ビルドの開始] を選択して、ビルドを再試行します。

エラー: ビルドを実行中に「CodeBuild に問題が発生しています」

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

考えられる原因: AWS CodeBuild には大きすぎる環境変数がビルドで使用されています。CodeBuild では、すべての環境変数の長さ (すべての名前とすべての値の合計) が最大値の約 5,500 文字に達するとエラーが発生します。

推奨される解決策: Amazon EC2 Systems Manager パラメータストアを使用して大きな環境変数を保存し、buildspec ファイルから取得します。 Amazon EC2 Systems Managerパラメータストアは、4,096 文字以下の個々の環境変数 (名前と値を一緒にしたもの) を保存できます。大きな環境変数を保存するには、https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-paramstore.html ユーザーガイドの「Systems Manager パラメータストア」および「Amazon EC2 Systems ManagerSystems Manager パラメータストアコンソールチュートリアル.」を参照してください。これらを取得するには、「parameter-store」の buildspec の構文. マッピングを参照してください。

エラー : ビルドプロジェクトを作成または更新する際、「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 STS リージョン向けの AWS がアクティブ化されていることを確認します。詳細については、の「 リージョンAWS STSAWSでの のアクティブ化と非アクティブ化」を参照してくださいIAM ユーザーガイド

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

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

エラー: 「Error calling 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 がビルドからの出力を保存するバケット) が、AWS ビルドプロジェクトとは異なる CodeBuild リージョンにあります。

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

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

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

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

推奨される解決策:

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

  • プロジェクトを編集します。[Insecure SSL (安全でない SSL)] を選択してGitHub、エンタープライズサーバープロジェクトリポジトリに接続するときに SSL 警告を無視します。

    注記

    [Insecure SSL (安全でない 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 ビルドプロジェクトとは異なる AWS CodeBuild リージョンにあります。

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

エラー:「ポリシーのデフォルトバージョンが enhanced zero クリックロールの作成で作成されなかったか、enhanced zero クリックロールの作成で作成された最新バージョンではありませんでした。」

問題: コンソールでプロジェクトを更新しようとすると、このエラーが発生して更新が失敗する。

考えられる原因:

  • 対象の AWS CodeBuild サービスロールに付いていたポリシーを更新しました。

  • 対象の CodeBuild サービスロールに付いていた前のバージョンのポリシーを選択しました。

推奨される解決策:

  • CodeBuild プロジェクトを編集し、[Allow CodeBuild to modify this service role so it can be used with this build project] チェックボックスをオフにします。使用している CodeBuild サービスロールに十分な権限があることを確認します。CodeBuild プロジェクトを再度編集する場合は、このチェックボックスを再度オフにする必要があります。詳細については、「 」を参照してください。CodeBuild サービスロールの作成.

  • 新しいサービスロールを使用するように CodeBuild プロジェクトを編集するには、次の手順に従います。

    1. IAM コンソールを開き、新しいサービスロールを作成します。詳細については、「 」を参照してください。CodeBuild サービスロールの作成.

    2. Open the AWS CodeBuild console at https://console.aws.amazon.com/codesuite/codebuild/home.

    3. ナビゲーションペインで、[Build projects.] を選択します。

    4. ビルドプロジェクトの横にあるボタンを選択し、[編集]、[Environment (環境).] の順に選択します。

    5. [サービスロール] で、作成したロールを選択します。

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

エラー: "このビルドイメージではランタイムバージョンを少なくとも 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
注記

If you specify a runtime-versions section and use an image other than Ubuntu Standard Image 2.0 or later, or the Amazon Linux 2 (AL2) standard image 1.0 or later, the build issues the warning, "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 ブロックVPCsを持つ の場合、DNS サーバーの IP アドレスはプライマリ CIDR にあります。詳細については、 https://docs.aws.amazon.com/vpc/latest/userguide/VPC_DHCP_Options.html#AmazonDNS ユーザーガイドの「Amazon DNSAmazon VPC サーバー」を参照してください

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

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

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

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

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

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

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

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

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

考えられる原因:

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

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

推奨される解決策:

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

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

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

問題: AWS CLI を実行しようとするとき、AWS SDK を使用したり、別の同様のコンポーネントをビルドの一部として呼び出すと、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 の JavaScriptSDK: 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: 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 refused からAmazon S3。

考えられる原因:

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

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

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

推奨される解決策:

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

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

    1. プライベートサブネットのルーティングテーブルで、インターネット用トラフィックをプロキシサーバーにルーティングする追加済みのルールを削除します。詳細については、 https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/working-with-vpcs.html#AddaSubnet ユーザーガイドの「VPC でのサブネットAmazon VPCの作成」を参照してください

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

    3. [Enable Private DNS Name in ] Amazon VPC が選択されていることを確認します。詳細については、 https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpce-interface.html#create-interface-endpoint ユーザーガイドの「インターフェイスエンドポイント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) がビルドイメージに含まれていません。CodeBuild は、ビルドコマンドとスクリプトを実行するために sh を必要とします。

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

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

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

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

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

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

問題: CodeBuild コンソールを開くとJobWorker、「アイデンティティを検証できません」というエラーメッセージが表示されます。

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

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

ビルドの開始に失敗しました

問題: ビルドを開始すると、Build failed to start error メッセージが表示されます。

考えられる原因: 同時ビルドの数に達しました。

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

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

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

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

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

git rev-parse --git-dir

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

問題: テストデータを Amazon S3 バケットにアップロードするときに、 CodeBuild がテストデータをバケットに書き込むことができません。

考えられる原因:

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

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

推奨される解決策:

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

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