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

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

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

トピック

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

問題: 提供の Java ビルド環境で Maven を使用すると、Maven はビルドおよびプラグインの依存関係を AWS CodeBuildhttps://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

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

問題: 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 パラメータストアからパラメータを取得する際にビルドが失敗する場合がある

問題: パラメータストアに保存された 1 つ以上のパラメータの値をビルドが取得しようとすると、Amazon EC2 フェーズでは 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ウェブフックイベントのフィルタリング (コンソール)」を参照してください。

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

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

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

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

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

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

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

推奨される解決策:

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

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

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

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

  • 米国東部(バージニア北部)

  • 米国東部 (オハイオ)

  • 米国西部 (オレゴン)

  • 欧州 (アイルランド)

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

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

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

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

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

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

考えられる原因:

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

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

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

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

エラー: 「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 でプライベートレジストリを使用しています。CodeBuild は VPC のプライベート IP アドレスからイメージをプルできません。詳細については、「 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"

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

考えられる原因:

  • コンテナ 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 設定を指定します。

エラー: ビルドの実行時に「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 では、すべての環境変数の長さ (すべての名前と値を一緒にしたもの) が最大約 5,500 文字に達するとエラーが発生します。CodeBuild

推奨される解決策: パラメータストアを使用して大きな環境変数を保存し、buildspec ファイルから取得します。Amazon EC2 Systems ManagerAmazon 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 パラメータストアコンソールチュートリアル」を参照してください。これらを取得するには、「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 がアクティブ化されていることを確認します。詳細については、AWS STS の「AWS リージョンでの のアクティブ化と非アクティブ化」を参照してください。IAM ユーザーガイド

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

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

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

問題: ビルドを実行すると、S3 バケットの所有権と GetBucketAcl アクセス許可の変更に関するエラーが表示されます。

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

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

エラー: "アーティファクトをアップロードできませんでした: Invalid 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 オブジェクトキーの名前を入力します。

  • プロジェクトを編集します。Enterprise Server プロジェクトリポジトリに接続するときの SSL 警告を無視するには、[Insecure 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 ビルドプロジェクトとは異なる AWS CodeBuild リージョンにあります。

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

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

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

考えられる原因:

  • 対象の 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 マネージドイメージを使用する場合、buildspec ファイルの CodeBuild セクションでランタイムバージョンを指定する必要があります。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」を参照してください。

エラー: "キュー: ビルドキューのビルドが失敗した場合、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 VPCAmazon DNS サーバー」を参照してください。

  • 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 ユーザーガイドの「Amazon VPCVPC とサブネットのサイズ設定」を参照してください。

エラー: "キャッシュをダウンロードできません。RequestError : 次の理由により送信リクエストが失敗しました: x509: Failed to load system roots and no roots provided」

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

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

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

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

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

考えられる原因:

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

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

推奨される解決策:

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

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

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

問題: を実行しようとするとき、AWS CLI SDK を使用したり、別の同様のコンポーネントをビルドの一部として呼び出すと、AWS、AWS CLI SDK、またはコンポーネントに直接関連するビルドエラーが発生します。AWSたとえば、「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 Go 用 SDK: 1.2.5

    • AWS SDK for Java: 1.11.16

    • AWS 用 JavaScript SDK: 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 ベータ

    • 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 ユーザーガイドの「Amazon VPCVPC でのサブネットの作成」を参照してください。

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

    3. の [プライベート DNS 名を有効にする] が選択されていることを確認します。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 ID を確認できません」CodeBuild

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

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

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

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

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

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

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

git rev-parse --git-dir