翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# トラブルシューティング AWS CodeBuild
このトピックの情報を使用して、問題を特定、診断、対処します。CodeBuild のビルドのログ記録とモニタリングを行い、問題のトラブルシューティングを行う方法については、「[ログ記録とモニタリング](logging-monitoring.md)」を参照してください。
**Topics**
+ [Apache Maven が間違ったリポジトリのアーティファクトを参照している](#troubleshooting-maven-repos)
+ [ビルドコマンドがデフォルトでルートとして実行される](#troubleshooting-root-build-commands)
+ [ファイル名に英語以外の文字が含まれているとビルドが失敗する場合があります](#troubleshooting-utf-8)
+ [Amazon EC2 パラメータストアからパラメータを取得する際にビルドが失敗する場合がある](#troubleshooting-parameter-store)
+ [CodeBuild コンソールでブランチフィルタにアクセスできない](#troubleshooting-webhook-filter)
+ [ビルドの成功または失敗を表示できない](#no-status-when-build-triggered)
+ [ビルドステータスがソースプロバイダに報告されない](#build-status-not-reported)
+ [Windows Server Core 2019 プラットフォームの基本イメージが見つからず、選択できない](#windows-image-not-available)
+ [buildspec ファイルの以前のコマンドが、以降のコマンドで認識されない](#troubleshooting-build-spec-commands)
+ [エラー: キャッシュのダウンロード時に「アクセスが拒否される」](#troubleshooting-dependency-caching)
+ [エラー: 「BUILD\$1CONTAINER\$1UNABLE\$1TO\$1PULL\$1IMAGE」カスタムビルドイメージを使用した場合](#troubleshooting-unable-to-pull-image)
+ [エラー: 「ビルドの完了前にビルドコンテナの停止が検出されました。ビルドコンテナがメモリ不足のため停止したか、Docker イメージがサポートされていません」 エラーコード: 500」](#windows-server-core-version)
+ [Error: "Cannot connect to the Docker daemon" when running a build (ビルドの実行時に「Docker デーモンに接続できません」)](#troubleshooting-cannot-connect-to-docker-daemon)
+ [エラー : ビルドプロジェクトを作成または更新する際、「CodeBuild は sts:AssumeRole の実行を許可されていません」](#troubleshooting-assume-role)
+ [エラー: 「GetBucketAcl の呼び出しエラー: バケット所有者が変更されたか、サービスロールには、呼び出された s3:GetBucketAcl へのアクセス許可がありません」](#troubleshooting-calling-bucket-error)
+ [エラー: ビルドの実行時に「アーティファクトのアップロードに失敗しました: 無効な ARN」](#troubleshooting-output-bucket-different-region)
+ [エラー: 「Git のクローンに失敗しました: `'your-repository-URL'` にアクセスできません: SSL 証明書の問題: 自己署名証明書」](#troubleshooting-self-signed-certificate)
+ [エラー: ビルドの実行時に「アクセスしようとしているバケットは、指定されたエンドポイントを使用してアドレス指定する必要があります」](#troubleshooting-input-bucket-different-region)
+ [エラー: "このビルドイメージではランタイムバージョンを少なくとも 1 つ選択する必要があります。"](#troubleshooting-build-must-specify-runtime)
+ [ビルドキューのビルドが失敗するとエラー「QUEUED:INSUFFICIENT\$1SUBNET」が表示される](#queued-insufficient-subnet-error)
+ [エラー: 「キャッシュをダウンロードできません: RequestError: 次の理由により送信リクエストが失敗しました: x509: システムのルートをロードできませんでした。ルートが指定されていません」](#troubleshooting-cache-image)
+ [エラー : 「S3 から証明書をダウンロードできません。AccessDenied"](#troubleshooting-certificate-in-S3)
+ [エラー: 「認証情報を見つけることができません」](#troubleshooting-versions)
+ [プロキシサーバーで CodeBuild を実行しているときの RequestError タイムアウトエラー](#code-request-timeout-error)
+ [ビルドイメージ内に Bourne シェル (sh) が必要](#troubleshooting-sh-build-images)
+ [警告 (ビルドの実行時): 「ランタイムのインストールをスキップします。このビルドイメージではランタイムバージョンの選択はサポートされていません」](#troubleshooting-skipping-all-runtimes-warning)
+ [エラー：CodeBuild コンソールを開くときに「JobWorker ID を確認できません」と表示される。](#troubleshooting-unable-to-verify-jobworker)
+ [ビルドの開始の失敗](#troubleshooting-build-failed-to-start)
+ [ローカルにキャッシュされたビルドの GitHub メタデータへのアクセス](#troubleshooting-github-metadata)
+ [AccessDenied: レポートグループのバケット所有者が S3 バケットの所有者と一致しません。](#troubleshooting-bucket-owner)
+ [エラー: CodeConnections で CodeBuild プロジェクトを作成するときに「認証情報に必要な権限スコープが 1 つ以上ありません」](#troubleshooting-permission-bitbucket)
+ [エラー: Ubuntu install コマンドでビルドするときに「申し訳ありません。ターミナルがまったくリクエストされていません - 入力を取得できません」](#troubleshooting-nvidia-container-toolkit)
## Apache Maven が間違ったリポジトリのアーティファクトを参照している
**問題:** AWS CodeBuildが提供する Java ビルド環境で Maven を使用すると、Maven は [https://repo1.maven.org/maven2](https://repo1.maven.org/maven2) の安全な中央 Maven リポジトリからビルドとプラグインの依存関係を取得します。これは、ビルドプロジェクトの `pom.xml` ファイルが別の場所を使用すると明示的に宣言した場合でも発生します。
**考えられる原因:** `settings.xml`CodeBuild が提供する Java ビルド環境には、ビルド環境の `/root/.m2` ディレクトリに事前にインストールされている という名前のファイルが含まれています。この `settings.xml` には次の宣言が含まれています。これにより、Maven が常に [https://repo1.maven.org/maven2](https://repo1.maven.org/maven2) で、セキュアな中央 Maven リポジトリからビルドおよびプラグインの依存関係を引き出すように指示されます。
```
securecentral
securecentral
central
https://repo1.maven.org/maven2
true
central
https://repo1.maven.org/maven2
true
```
**推奨される解決策:** 以下を実行してください。
1. `settings.xml` ファイルをソースコードに追加します。
1. この `settings.xml` ファイルでは、前述の `settings.xml` 形式をガイドとして使用して、Maven が代わりにビルドとプラグインの依存関係を取得するリポジトリを宣言します。
1. ビルドプロジェクトの `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 -f noninteractive 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/` で始まる名前を持つパラメータを取得できます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": "ssm:GetParameters",
"Effect": "Allow",
"Resource": "arn:aws:ssm:us-east-1:111122223333:parameter/CodeBuild/*"
}
]
}
```
------
+ CodeBuild によって生成されたサービスロールの場合は、その定義を更新して、 Amazon EC2 パラメータストア内の `/CodeBuild/` で始まる名前以外の名前のパラメータに CodeBuild がアクセスできるようにします。たとえば、次のポリシーステートメントでは、`ssm:GetParameters` アクションを呼び出して指定された名前のパラメータを取得できます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": "ssm:GetParameters",
"Effect": "Allow",
"Resource": "arn:aws:ssm:us-east-1:111122223333:parameter/PARAMETER_NAME"
}
]
}
```
------
## CodeBuild コンソールでブランチフィルタにアクセスできない
**問題:** AWS CodeBuild プロジェクトを作成または更新するときに、ブランチフィルターオプションをコンソールで使用することはできません。
**考えられる原因:** ブランチフィルタオプションは廃止されました。このオプションはウェブフックフィルタグループに置き換えられています。これにより、CodeBuild の新しいビルドをトリガーするウェブフックイベントの制御が強化されます。
**推奨される解決策:** ウェブフックフィルタの導入前に作成したブランチフィルタを移行するには、正規表現 `HEAD_REF` で `^refs/heads/branchName$` フィルタを使用してウェブフックフィルタグループを作成します。たとえば、ブランチフィルタの正規表現が `^branchName$` の場合、`HEAD_REF` フィルタに入力する更新後の正規表現は `^refs/heads/branchName$` です。詳細については、「[Bitbucket ウェブフックイベント](bitbucket-webhook.md)」および「[GitHub ウェブフックイベントのフィルタリング (コンソール)](github-webhook-events-console.md)」を参照してください。
## ビルドの成功または失敗を表示できない
** 問題: **再試行されたビルドの成功または失敗を確認できない。
**考えられる原因:** ビルドのステータスを報告するオプションが有効になっていません。
**推奨される解決策:** CodeBuild プロジェクトを作成または更新するときは、**[ビルドのステータスを報告]** を有効にします。このオプションは、ビルドをトリガーするときに CodeBuild にステータスを報告するように指示します。詳細については、*AWS CodeBuild API リファレンス*の「[ReportBuildStatus](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_ProjectSource.html#CodeBuild-Type-ProjectSource-reportBuildStatus)」を参照してください。
## ビルドステータスがソースプロバイダに報告されない
**問題:** GitHub や Bitbucket などのソースプロバイダーへのビルドステータスのレポートを許可した後で、ビルドステータスが更新されない。
**考えられる原因:** ソースプロバイダーに関連付けられたユーザーに、リポジトリへの書き込みアクセス許可がありません。
**推奨される解決策:** ソースプロバイダーにビルドステータスを報告できるようにするには、ソースプロバイダーに関連付けられたユーザーがリポジトリへの書き込みアクセス権を持っている必要があります。ユーザーが書き込みアクセス権を持っていない場合、ビルドのステータスは更新できません。詳細については、「[ソースプロバイダーのアクセス](access-tokens.md)」を参照してください。
## 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 つのコマンドから呼び出します。詳細については、「[ビルド環境のシェルとコマンド](build-env-ref-cmd.md)」および「[ビルド環境の環境変数](build-env-ref-env-vars.md)」を参照してください。
## エラー: キャッシュのダウンロード時に「アクセスが拒否される」
**問題:** キャッシュが有効になっているビルドプロジェクトでキャッシュをダウンロードしようとすると、`Access denied` エラーが発生する。
**考えられる原因:**
+ ビルドプロジェクトの一部としてキャッシングが設定されています。
+ キャッシュは、`InvalidateProjectCache` API により最近無効化されています。
+ CodeBuild を使用しているサービスロールには、キャッシュを保持する S3 バケットへの `s3:GetObject`アクセス許可と `s3:PutObject` アクセス許可がありません。
**推奨される解決策:** キャッシュ設定を更新した直後に初めて使用する場合、このエラーが表示されるのは普通です。このエラーが解消されない場合は、キャッシュを保持する S3 バケットへの `s3:GetObject` アクセス許可と `s3:PutObject` アクセス許可が、サービスロールに付与されているかどうかを確認する必要があります。詳細については、「Amazon S3 デベロッパーガイド」の「[S3 アクセス許可の指定](https://docs.aws.amazon.com/AmazonS3/latest/userguide/using-with-s3-actions.html)」を参照してください。**
## エラー: 「BUILD\$1CONTAINER\$1UNABLE\$1TO\$1PULL\$1IMAGE」カスタムビルドイメージを使用した場合
**問題:** カスタムビルドイメージを使用するビルドを実行しようとすると、ビルドは `BUILD_CONTAINER_UNABLE_TO_PULL_IMAGE` というエラーで失敗する。
***考えられる原因:** ビルドイメージの全体的な非圧縮サイズが、ビルド環境のコンピューティングタイプの使用可能ディスクスペースよりも大きい。ビルドイメージのサイズを確認するには、Docker を使用して `docker images REPOSITORY:TAG` コマンドを実行します。コンピューティングタイプで使用可能なディスク容量のリストについては、「[ビルド環境のコンピューティングモードおよびタイプ](build-env-ref-compute-types.md)」を参照してください。*
**推奨される解決策:** 使用可能なディスク容量の大きなコンピューティングタイプを使用するか、カスタムビルドイメージのサイズを縮小します。
***考えられる原因:** AWS CodeBuild Amazon Elastic Container Registry (Amazon ECR) からビルドイメージをプルするアクセス許可がありません。*
**推奨される解決策:** CodeBuild がカスタムビルドイメージをビルド環境にプルできるように、Amazon ECR のリポジトリの権限を更新します。詳細については、「[Amazon ECR のサンプル](sample-ecr.md)」を参照してください。
***考えられる原因:** リクエストした Amazon ECR イメージは、 AWS アカウントが使用している AWS リージョンでは使用できません。*
**推奨される解決策:** AWS アカウントが使用しているリージョンと同じ AWS リージョンにある Amazon ECR イメージを使用します。
***考えられる原因:**パブリックインターネットアクセスのない VPC でプライベートレジストリを使用しています。CodeBuild は、VPC 内のプライベート IP アドレスからイメージを取得できません。詳細については、「[CodeBuild AWS Secrets Manager のサンプルを含むプライベートレジストリ](sample-private-registry.md)」を参照してください。*
**推奨される解決策:** VPC でプライベートレジストリを使用する場合は、VPC にパブリックインターネットアクセスがあることを確認してください。
***考えられる原因:** エラーメッセージに「**toomanyrequests**」が含まれており、イメージを Docker Hub から取得した場合、このエラーは Docker Hub のプル制限に達したことを意味します。*
**推奨される解決策:** Docker Hub のプライベートレジストリを使用するか、Amazon ECR からイメージを取得します。プライベートレジストリの使用の詳細については、「[CodeBuild AWS Secrets Manager のサンプルを含むプライベートレジストリ](sample-private-registry.md)」を参照してください。Amazon ECR の使用方法の詳細については、「[CodeBuild の Amazon ECR サンプル](sample-ecr.md)」を参照してください。
## エラー: 「ビルドの完了前にビルドコンテナの停止が検出されました。ビルドコンテナがメモリ不足のため停止したか、Docker イメージがサポートされていません」 エラーコード: 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. CodeBuild コンソール ([https://console.aws.amazon.com/codebuild/](https://console.aws.amazon.com/codebuild/)) を開きます。
1. ナビゲーションペインで **[ビルドプロジェクト]** を選択し、該当するビルドプロジェクトを選択します。
1. **[Edit]** (編集) から **[Environment]** (環境) を選択します。
1. [**Additional configuration (追加設定)**] を選択します。
1. **[特権付与]** から、**[Docker イメージをビルドする場合、またはビルドで昇格された権限を取得する場合は、このフラグを有効にする]** を選択します。
1. [**Update environment (環境の更新)**] を選択します。
1. [**ビルドの開始**] を選択してビルドを再度実行します。
また、コンテナ内で 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](https://docs.docker.com/storage/storagedriver/overlayfs-driver/)」を参照してください。
**注記**
基本オペレーティングシステムが Alpine Linux である場合は、`buildspec.yml` で `-t` 引数を `timeout` に追加します。
```
- timeout -t 15 sh -c "until docker info; do echo .; sleep 1; done"
```
を使用して Docker イメージを構築および実行する方法の詳細については AWS CodeBuild、「」を参照してください[CodeBuild のカスタム Docker イメージのサンプル](sample-docker-custom-image.md)。
## エラー : ビルドプロジェクトを作成または更新する際、「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 CodeBuild サービスロールの大文字と小文字が、実際の IAM ロールと一致しません。
**推奨される解決策:**
+ ビルドプロジェクトを作成または更新しようとしている AWS リージョンで AWS STS が有効になっていることを確認します。詳細については、*IAM ユーザーガイド*[の「 AWS リージョン AWS STS での のアクティブ化と非アクティブ化](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_enable-regions.html)」を参照してください。
+ ターゲット CodeBuild サービスロールが AWS アカウントに存在することを確認します。コンソールを使用していない場合は、ビルドプロジェクトを作成または更新したときにサービスロールの Amazon リソースネーム (ARN) のスペルを間違えていないことを確認してください。IAM ロールでは大文字と小文字が区別されるため、IAM ロールの大文字と小文字が正しいことを確認してください。
+ 対象の CodeBuild サービスロールに、CodeBuild を信頼するための十分な権限があることを確認します。詳細については、[CodeBuild が他の AWS サービスとやり取りすることを許可する](setting-up-service-role.md)の「信頼関係のポリシーステートメント」を参照してください。
## エラー: 「GetBucketAcl の呼び出しエラー: バケット所有者が変更されたか、サービスロールには、呼び出された s3:GetBucketAcl へのアクセス許可がありません」
**問題:** ビルドを実行すると、S3 バケット所有者や `GetBucketAcl` アクセス許可の変更に関するエラーが発生する。
**考えられる原因:** `s3:GetBucketAcl` および `s3:GetBucketLocation` のアクセス許可を IAM ロールに追加しています。これらのアクセス許可は、プロジェクトの S3 バケットを保護し、バケットにアクセスできるユーザーを自分に限定します。これらのアクセス許可を追加した後で、S3 バケットの所有者が変更されています。
**推奨される解決策:** S3 バケットの所有者が自分であることを確認し、IAM ロールへのアクセス許可を追加し直します。詳細については、「[S3 バケットへの安全なアクセス](auth-and-access-control-iam-access-control-identity-based.md#secure-s3-buckets)」を参照してください。
## エラー: ビルドの実行時に「アーティファクトのアップロードに失敗しました: 無効な 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 オブジェクトキーの名前を入力します。
+ プロジェクトを編集します。GitHub Enterprise Server プロジェクトリポジトリに接続するときの SSL 警告を無視するには、[**Insecure SSL (安全でない SSL)**] を選択します。
**注記**
[**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 AWS CodeBuild リージョンにあります。
**推奨される解決策:** 構築済みのソースコードが含まれているバケットを指すように、ビルドプロジェクトの設定を更新します。バケットがビルドプロジェクトと同じ 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](build-spec-ref.md#runtime-versions-buildspec-file)」を参照してください。
## ビルドキューのビルドが失敗するとエラー「QUEUED:INSUFFICIENT\$1SUBNET」が表示される
**問題:** ビルドキューのビルドが `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 サーバー](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_DHCP_Options.html#AmazonDNS)」を参照してください。
+ `10.0.0.3`: 将来の使用 AWS のために によって予約されています。
+ `10.0.0.255`: ネットワークブロードキャストアドレスです。VPC でのブロードキャストはサポートされていません。このアドレスは予約されています。
**推奨される解決策:** VPC でリザーブド IP アドレスが使用されていることを確認します。予約済みの IP アドレスを、予約されていないアドレスに置き換えます。詳細については、*Amazon VPC ユーザーガイド*の[VPC とサブネットのサイズ設定](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Subnets.html#VPC_Sizing)を参照してください。
## エラー: 「キャッシュをダウンロードできません: RequestError: 次の理由により送信リクエストが失敗しました: x509: システムのルートをロードできませんでした。ルートが指定されていません」
**問題:** ビルドプロジェクトを実行しようとすると、このエラーが発生してビルドが失敗する。
**考えられる原因:** ビルドプロジェクトの一部としてキャッシュを設定し、有効期限が切れたルート証明書を含む古い Docker イメージを使用しています。
**推奨される解決策:** AWS CodeBuild プロジェクトで使用されている Docker イメージを更新します。詳細については、「[CodeBuild に用意されている Docker イメージ](build-env-ref-available.md)」を参照してください。
## エラー : 「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\$1\$1: 0.2.19
+ AWS SDK for Go: 1.2.5
+ AWS SDK for Java: 1.11.16
+ AWS SDK for 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
```
1. 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 .
```
## プロキシサーバーで CodeBuild を実行しているときの RequestError タイムアウトエラー
**問題:** 次のいずれかのような `RequestError` エラーが表示される。
+ `RequestError: send request failed caused by: Post https://logs..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 の設定](run-codebuild-in-explicit-proxy-server.md#use-proxy-server-explicit-squid-configure)」を参照してください。
+ Amazon S3 および CloudWatch Logs のプライベートエンドポイントを使用するには、次の手順に従います。
1. プライベートサブネットのルーティングテーブルで、インターネット用トラフィックをプロキシサーバーにルーティングする追加済みのルールを削除します。詳細については、「Amazon VPC ユーザーガイド」の「[VPC でサブネットを作成する](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-vpcs.html#AddaSubnet)」を参照してください。**
1. プライベート Amazon S3 エンドポイントと CloudWatch Logs エンドポイントを作成し、それらを Amazon VPC のプライベートサブネットに関連付けます。詳細については、「Amazon VPC ユーザーガイド」の「[VPC エンドポイントサービス](https://docs.aws.amazon.com/vpc/latest/userguide/endpoint-service.html)」を参照してください。**
1. Amazon VPC の **[プライベート DNS 名を有効にする]** が選択されていることを確認します。詳細については、「Amazon VPC ユーザーガイド」の[インターフェイスエンドポイントの作成](https://docs.aws.amazon.com/vpc/latest/userguide/vpce-interface.html#create-interface-endpoint)を参照してください。
+ 明示的なプロキシサーバーに `ssl-bump` を使用しない場合は、`proxy` 要素を使用して buildspec ファイルにプロキシ設定を追加します。詳細については、「[明示的なプロキシサーバーでの CodeBuild の実行](run-codebuild-in-explicit-proxy-server.md)」および「[buildspec の構文](build-spec-ref.md#build-spec-ref-syntax)」を参照してください。
```
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) 標準イメージ以降または Ubuntu 標準イメージのバージョン 2.0 以降を使用する場合にのみ必要です。
## エラー：CodeBuild コンソールを開くときに「JobWorker ID を確認できません」と表示される。
**問題:** CodeBuild コンソールを開くと、「JobWorker の ID を確認できません」というエラーメッセージが表示される。
**考えられる原因:** コンソールのアクセスに使用されている IAM ロールに、`jobId` をキーとするタグがあります。このタグキーは CodeBuild 用に予約されており、存在する場合にこのエラーを発生させます。
**推奨される解決策:** `jobId` キーを持つカスタム IAM ロールタグを変更して、`jobIdentifier` などの別のキーを持つようにします。
## ビルドの開始の失敗
**問題:** ビルドを開始すると、「**ビルドを開始できませんでした**」というエラーメッセージが表示される。
**考えられる原因:** 同時に実行できるビルド数の上限に達しています。
**推奨される解決策:** 他のビルドが完了するまで待つか、プロジェクトの同時実行のビルド制限を増やして、ビルドを再度開始します。詳細については、「[プロジェクトの設定](create-project.md#create-project-console-project-config)」を参照してください。
## ローカルにキャッシュされたビルドの GitHub メタデータへのアクセス
**問題:** 状況によっては、キャッシュされたビルドの .git ディレクトリは、ディレクトリではなく、テキストファイルである場合があります。
**考えられる原因:** ローカルソースキャッシュがビルドに対して有効になっている場合、CodeBuild は `.git` ディレクトリの gitlink を作成します。つまり、`.git` ディレクトリは、単にディレクトリへのパスを含むテキストファイルです。
**推奨される解決策:** すべての場合において、次のコマンドを使用して Git メタデータディレクトリを取得します。このコマンドは、`.git` のフォーマットに関係なく機能します。
```
git rev-parse --git-dir
```
## AccessDenied: レポートグループのバケット所有者が S3 バケットの所有者と一致しません。
**問題:** Amazon S3 バケットにテストデータをアップロードしたときに、CodeBuild がバケットにテストデータを書き込むことができない。
**考えられる原因:**
+ レポートグループのバケット所有者に指定されたアカウントが、Amazon S3 バケットの所有者と一致しません。
+ サービスロールには、バケットへの書き込みアクセスがありません。
**推奨される解決策:**
+ Amazon S3 バケットの所有者と一致するよう、レポートグループのバケット所有者を変更します。
+ Amazon S3 バケットへの書き込みアクセスを許可するようにサービスロールを変更します。
## エラー: CodeConnections で CodeBuild プロジェクトを作成するときに「認証情報に必要な権限スコープが 1 つ以上ありません」
**問題:** CodeConnections を使用して CodeBuild プロジェクトを作成するとき、Bitbucket ウェブフックをインストールするアクセス許可がありません。
**考えられる原因:**
+ 新しいアクセス許可スコープが Bitbucket アカウントで受け入れられていない可能性があります。
**推奨される解決策:**
+ 新しいアクセス許可を受け入れるには、**Action required - Scopes for AWS CodeStar has changed** by Bitbucket, という件名の E メールを受信しているはずです`notifications-noreply@bitbucket.org`。E メールには、既存の CodeConnections Bitbucket アプリのインストールにウェブフックのアクセス許可を付与するためのリンクが含まれています。
+ E メールが見つからない場合は、`https://bitbucket.org/site/addons/reauthorize?account=&addon_key=aws-codestar` または `https://bitbucket.org/site/addons/reauthorize?addon_key=aws-codestar` に移動するか、ウェブフックのアクセス許可を付与するワークスペースを選択することで、アクセス許可を付与できます。
![\[ワークスペースにウェブフックアクセス許可を付与します。\]](http://docs.aws.amazon.com/ja_jp/codebuild/latest/userguide/images/bitbucket-csc.png)
## エラー: Ubuntu install コマンドでビルドするときに「申し訳ありません。ターミナルがまったくリクエストされていません - 入力を取得できません」
**問題:** GPU コンテナ特権ビルドを実行している場合は、こちらの[手順](https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/latest/install-guide.html#installing-with-apt)で NVIDIA Container Toolkit をインストールしている可能性があります。最新の CodeBuild イメージリリースでは、CodeBuild は `nvidia-container-toolkit` を使用して、最新の選別されたイメージ `amazonlinux` および `ubuntu` に Docker をプリインストールして設定します。この手順を実行すると、Ubuntu install コマンドを使用したビルドに失敗し、次のエラーが発生します。
```
Running command curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | gpg --dearmor --no-tty -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg
gpg: Sorry, no terminal at all requested - can't get input
curl: (23) Failed writing body
```
**考えられる原因:** gpg キーが同じ場所に既に存在しています。
**推奨される解決策:** `nvidia-container-toolkit` がイメージに既にインストールされています。このエラーが表示された場合は、buildspec で Docker のインストールと再起動プロセスをスキップできます。