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

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

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

トピック

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

問題: AWS CodeBuild が提供する Java ビルド環境で Maven を使用すると、Maven はビルドおよびプラグイン依存関係を Maven の安全な中央リポジトリ (https://repo1.maven.org/maven2) から取得します。これは、ビルドプロジェクトの 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

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

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

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

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

ファイル名に米英語以外の文字が使用されていると、ビルドが失敗する場合がある

問題: ビルドを実行する際に、ビルドで使用するファイルの名前に米英語以外の文字 (中国語の文字など) が含まれていると、ビルドが失敗する。

考えられる原因: AWS CodeBuild が提供するビルド環境では、デフォルトロケールが POSIX に設定されています。POSIX のローカライズ設定は、CodeBuild および米英語以外の文字を含むファイル名との互換性が低いため、関連するビルドが失敗する場合があります。

推奨される解決策: buildspec ファイルの pre_build セクションに次のコマンドを追加します。これらのコマンドは、ビルド環境のローカライズ設定で、CodeBuild および米英語以外の文字を含むファイル名との互換性が高い米英語 UTF-8 を使用することを強制します。

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 によって生成されたサービスロールの場合は、その定義を更新して、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 の新しいビルドをトリガーするウェブフックイベントの制御が強化されます。

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

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

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

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

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

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

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

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

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

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

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

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

推奨される解決策: Windows Server Core 2016 プラットフォームの基本イメージがサポートされている、次のいずれかの 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 アクセス許可が、サービスロールに付与されているかどうかを確認する必要があります。詳細については、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) からビルドイメージを取得するアクセス許可がありません。

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

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

推奨される解決策:

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

  • CodeBuild がカスタムビルドイメージをビルド環境にプルできるように、Amazon ECR のリポジトリの権限を更新します。詳細については、「Amazon ECR サンプル」を参照してください。

  • AWS アカウントで使用しているのと同じ AWS リージョンにある Amazon ECR イメージを使用します。

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

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

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

考えられる原因:

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

  • HTTP_PROXYHTTPS_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. [特権付与] を選択します。

    注記

    デフォルトでは、Docker コンテナはどのデバイスにもアクセスできません。権限モードは、ビルドプロジェクトの Docker コンテナにすべてのデバイスへのアクセスを許可します。詳細については、Docker Docs Web サイトの「Runtime Privilege and Linux Capabilities」を参照してください。

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

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

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

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

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

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

エラー : ビルドプロジェクトを作成または更新する際、「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 リージョン向けの AWS Security Token Service (AWS STS) が非アクティブ化されました。

  • ビルドプロジェクトに関連付けられた 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 オブジェクトキーの名前を入力します。

  • プロジェクトを編集します。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 CodeBuild ビルドプロジェクトとは異なる AWS リージョンにあります。

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

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

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

考えられる原因:

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

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

推奨される解決策:

  • CodeBuild プロジェクトを編集し、[Allow to modify this service role so it can be used with this build project (このサービスロールの変更を CodeBuild に許可し、このビルドプロジェクトで使用できるようにする)] のチェックボックスをオフにします。使用している 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. [ Service role (サービスロール)] で、作成したロールを選択します。

    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
注記

runtime-versions セクションを指定して、Ubuntu Standard Image 2.0 以降、または Amazon Linux 2 (AL2) Standard Image 1.0 以降以外のイメージを使用すると、ビルドは警告「Skipping install of runtimes. Runtime version selection is not supported by this build image。」を出します。

詳細については、「buildspec ファイルのランタイムバージョンの指定」を参照してください。

ビルドキューのビルドが失敗するとエラー「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 イメージを更新します。詳細については、「CodeBuild に用意されている Docker イメージ」を参照してください。

エラー : 「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 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
    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 .

プロキシサーバーで CodeBuild を実行しているときの RequestError タイムアウトエラー

問題: 次のいずれかのような 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. プライベートサブネットのルーティングテーブルで、インターネット用トラフィックをプロキシサーバーにルーティングする追加済みのルールを削除します。詳細については、Amazon VPC ユーザーガイドの「VPC でのサブネットの作成」を参照してください。

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

    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) がビルドイメージに含まれていません。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 以降を使用する場合にのみ必要です。