ビルド時のメモリー制限の場合の解決策

解決策については、メモリー制限を超えた場合のビルドの失敗を参照してください。

ビルド時にコンテナー・レジストリーに問題がある場合の解決策

このシナリオでは、コンテナ・レジストリにアクセスするためのレジストリ・シークレットが存在しないか、シークレットが正しくない。

1. 使用されているシークレットを判別します。 コマンドを使用する。 ibmcloud ce build get コマンドを使用して、使用されているレジストリ秘密を表示する。

2. .dockerconfigjson 鍵が存在するかどうか判別します。 レジストリー・シークレットには、 ibmcloud ce secret get コマンドを使用します。 シークレット・データは base64 でエンコードされているので、直接表示されないことに注意してください。ただし、シークレットには資格情報が含まれています。 コマンド出力の Data セクションを確認します。 .dockerconfigjson という鍵が含まれている必要があります。 .dockerconfigjson 鍵が表示されない場合には、このシークレットはコンテナー・レジストリーで認証を受けるには適していないので、正しいシークレットを作成し、ビルドでそのシークレットを参照する必要があります。 詳しくは、プライベート・コンテナー・レジストリーへのアクセス権限の追加を参照してください。

   出力例

   $ ibmcloud code-engine secret get -n <REGISTRY_SECRET>
   Getting secret <REGISTRY_SECRET>...
   OK
   
   Name:        <REGISTRY_SECRET>
   ID:          <REGISTRY_SECRET_ID>
   Project:     <PROJECT_NAME>
   Project ID:  <PROJECT_NAMESPACE>
   Age:         8s
   Created:     2021-02-12T10:26:59-06:00
   
   Data:
   ---
   .dockerconfigjson: <BASE64_STRING>
   

3. .dockerconfigjson 鍵が存在する場合、以下のコマンドを使用して鍵 (base64 でエンコードされているストリング) をデコードします。

   echo "<BASE64_STRING>" | base64 -d
   {"auths":{"<REGISTRY>":{"username":"<USERNAME>","password":"<PASSWORD>","auth":"<AUTH>"}}}
   

   このコマンドの出力には、通常、1 つの<REGISTRY>キーが含まれます。

4. 鍵に関する以下の情報を確認します。

   a. <REGISTRY>の値を確認します。 この値は、ビルドのイメージと一致する必要があります。

   • イメージ名がIBM Cloud Container Registry上にある場合 (例: us.icr.io/aNamespace/anImage)、<REGISTRY>はus.icr.ioである必要があります。

   • イメージ名がホスト名のないdocker.io/aNamespace/aRepositoryまたは/aNamespace/aRepositoryの場合、ビルドは Docker Hub を使用しています。 この場合、<REGISTRY>はhttps://index.docker.io/v1/でなければなりません。

   b. <USERNAME>の値を確認します。 レジストリーが IBM Cloud Container Registry の場合、API 鍵を認証に使用する必要があります。 <USERNAME>はiamapikeyである必要があり、パスワードは API キーである必要があります。 API 鍵を作成するステップについては、IBM Cloud Container Registry へのアクセスの自動化を参照してください。

   c. 資格情報を検証する必要があります。IBM Cloud® Identity and Access Management (IAM) を使用すると、きめ細かい方法で権限を割り当てることができます。 例えば、IBM Cloud Container Registry 名前空間へのアクセス権とイメージをプルするための許可を持つサービス ID が、イメージのプッシュを許可されていないことがあります。 しかし、この場合にはこの許可が必要になります。

5. 必要な変更について確認したら、修正された値を使用するコンテナー・レジストリー・シークレットを作成します。 ibmcloud ce secret create --format コマンドを使用します。例えば、次のようにします。

   ibmcloud ce secret create --format registry --name <REGISTRY_SECRET> --server <REGISTRY_SERVER> --username <USERNAME> --password <PASSWORD>
   

6. レジストリー・シークレットの名前を参照するようにビルドを更新します。

   a. ibmcloud ce build update コマンドを使用して、レジストリー・シークレットの名前を使用するようにビルド構成を更新します。以下に例を示します。

   ibmcloud ce build update --name <BUILD_NAME> --registry-secret <REGISTRY_SECRET>
   

   b. ibmcloud ce buildrun submit コマンドを使用して、新しいビルドを実行依頼します。 buildrun submit コマンドには、--build オプションを指定して、ビルド構成の名前を指定する必要があります。 必要に応じて、--name オプションを指定して、そのビルド実行の名前を指定することもできます。 --name オプションを指定した場合は、必ず、失敗したビルド実行とは異なるビルド実行名を使用するか、失敗したビルド実行を ibmcloud ce buildrun delete コマンドを使用して削除してください。 以下に例を示します。

   ibmcloud ce buildrun submit --build <BUILD_NAME> --name <BUILDRUN_NAME>
   

ビルド時に Dockerfile が見つからない場合の解決策

Docker ビルドには、コンテナー・イメージのビルド方法を指定する Dockerfile が必要です。 ソース・リポジトリーにそのようなファイルが含まれていない場合、このファイルを提供するか、ビルド・ストラテジーとしてビルドパックを検討する必要があります。 詳しくは、ビルドの計画を参照してください。

1. Dockerfile が存在するものの、名前が異なる場合や、ルート・ディレクトリーにない場合には、追加の設定をビルドで指定する必要があります。

   • Dockerfile がソース・リポジトリーのルート・ディレクトリーにない場合、--context-dir 引数を指定して、Dockerfile が含まれているディレクトリーのパスを提供する必要があります。
   • Dockerfile の名前が Dockerfile 以外の場合、--dockerfile 引数を指定して、Dockerfile の名前を提供する必要があります。

2. 必要に応じて --context-dir オプションまたは --dockerfile オプションを使用するようビルドを更新します。

   a. ibmcloud ce build update コマンドを使用して、必要に応じて --context-dir オプションまたは --dockerfile オプションを使用するようビルド構成を更新します。次に例を示します。

   ibmcloud ce build update --name <BUILD_NAME> [--context-dir <CONTEXT_DIR>] [--dockerfile <DOCKERFILE_NAME>]
   

   b. ibmcloud ce buildrun submit コマンドを使用して、新しいビルドを実行依頼します。 buildrun submit コマンドには、--build オプションを指定して、ビルド構成の名前を指定する必要があります。 必要に応じて、--name オプションを指定して、そのビルド実行の名前を指定することもできます。 --name オプションを指定した場合は、必ず、失敗したビルド実行とは異なるビルド実行名を使用するか、失敗したビルド実行を ibmcloud ce buildrun delete コマンドを使用して削除してください。 以下に例を示します。

   ibmcloud ce buildrun submit --build <BUILD_NAME> --name <BUILDRUN_NAME>
   

ビルド中に IBM Cloud Container Registry の割り当て量制限に達した場合の解決策

IBM Cloud Container Registry には、無料プランと標準プランという 2 つのサービス・プランがあります。 無料プランの場合、IBM Cloud Container Registry では厳格な制限が適用されます。特に、合計で保管できるイメージ・サイズ (500 MB) に関して制限があります。 標準プランの場合、割り当て量を自分で構成できます。 詳しくは、IBM Cloud Container Registry の概要を参照してください。

1. 以下のいずれかのアクションを実行してください。

   • 使用されていないイメージを IBM Cloud Container Registry 名前空間から削除して、使用可能なスペースを増やします。
   • 無料プランから標準プランにアップグレードします。
   • IBM Cloud Container Registry 名前空間の割り当て量を増やします。

   エラー・メッセージにイメージ URL が含まれているので、影響を受ける IBM Cloud Container Registry 名前空間を特定するのに役立ちます。 名前空間は、IBM Cloud プロジェクト以外の別の IBM Cloud Code Engine アカウントに存在することもあります。

2. 修正アクションの実行後、ibmcloud ce buildrun submit コマンドを使用して、新しいビルドを実行依頼します。 buildrun submit コマンドには、--build オプションを指定して、ビルド構成の名前を指定する必要があります。 必要に応じて、--name オプションを指定して、そのビルド実行の名前を指定することもできます。 --name オプションを指定した場合は、必ず、失敗したビルド実行とは異なるビルド実行名を使用するか、失敗したビルド実行を ibmcloud ce buildrun delete コマンドを使用して削除してください。 以下に例を示します。

   ibmcloud ce buildrun submit --build <BUILD_NAME> --name <BUILDRUN_NAME>
   

ビルド・ソースが正しく指定されていない場合の解決策

通常、このエラーが生じる理由は、ビルド・ソースが Git リポジトリーのルート・ディレクトリーになく、子ディレクトリーにあることです。 ビルド・ソースがルート・ディレクトリー内にない場合、ビルドの位置を指定します。

1. ibmcloud ce build update コマンドの --context-dir オプションを使用して Git リポジトリーのソースのパスを指定するようにビルド構成を更新します。以下に例を示します。

   ibmcloud ce build update --name <BUILD_NAME> --context-dir <CONTEXT_DIR>
   

2. ibmcloud ce buildrun submit コマンドを使用して、新しいビルドを実行依頼します。 buildrun submit コマンドには、--build オプションを指定して、ビルド構成の名前を指定する必要があります。 必要に応じて、--name オプションを指定して、そのビルド実行の名前を指定することもできます。 --name オプションを指定した場合は、必ず、失敗したビルド実行とは異なるビルド実行名を使用するか、失敗したビルド実行を ibmcloud ce buildrun delete コマンドを使用して削除してください。 以下に例を示します。

   ibmcloud ce buildrun submit --build <BUILD_NAME> --name <BUILDRUN_NAME>
   

Docker ハブのレート制限による問題の解決

Code Engine のアプリやジョブで使用するために Docker Hub から画像を取り込む場合、無料プラン（未認証）ユーザーの Docker 料金制限に注意してください。 429 エラーはプル速度の制限に達したことを示しているので、このエラーを受け取った場合はプルの限度になっている可能性があります。 このエラーを受け取った場合は、以下のいずれかの解決策を試してください。

• レート制限を増やします。 必要に応じて、 Docker Hub で認証することも、アカウントを Docker Pro または Team サブスクリプションにアップグレードすることもできます。

• ビルドしたイメージを Docker Hub からプルし、そのイメージを別のレジストリー ( IBM Cloud® Container Registryなど) に公開します。 次に、新しい場所からイメージをプルします。 Code Engine は、単一のシークレットの参照をサポートします。 Dockerfile ビルドの基本イメージが、結果のビルド・イメージがパブリッシュされたレジストリーとは異なるレジストリーからプルされ、両方のレジストリーで認証が必要な場合は、 kubectl を使用して、両方のレジストリーの資格情報を含むタイプ kubernetes.io/dockerconfigjson の Kubernetes シークレットを作成できます。 両方のレジストリーのアクセス資格情報の処理については、 プライベート・リポジトリーからイメージをプルする方法に関するKubernetes の資料を参照してください。

ビルド・ソースがビルドパックによってサポートされていない場合の解決策

ビルド・ソース・リポジトリーが Code Engine でサポートされているかどうかを確認するには、ビルド・ストラテジーを選択 (Choose a build strategy) でサポート対象ランタイムを確認してください。 使用している言語がリストされている場合、リンクされているサンプルを確認して、ソースを正しく構成し、ビルドパックがそのソースを正常に検出してビルドできるようにします。 ソースに適したビルドパックが見つからない場合、またはビルドパックでビルドを実行するための標準化された方法がお客様のニーズに合わない場合には、Dockerfile を指定し、Dockerfile 内にコンテナー・ビルドを手動で記述し、その後、ビルド構成で dockerfile ビルド・ストラテジーを使用するように切り替えることができます。

Docker ビルドに問題がある場合の解決策

ビルドとプッシュのステップが失敗する問題が、メモリー、コンテナー・レジストリー・シークレット、または Dockerfile の問題ではない場合、Docker ビルドに問題がある可能性があります。 この問題は、Dockerfile 自体のエラー (構文エラーなど)、または Dockerfile が実行する操作の正確さにある可能性があります。 また、Java® コードが組み込まれている場合など、コンパイルに失敗する可能性があるソース・コードに問題がある場合もあります。

ローカルでのプロジェクトのビルドが成功したのに、同じソース・コードを Code Engine でビルドできない場合は、Git リポジトリーに含まれていないファイルがローカルに存在する可能性があります。 例えば、Node.js プロジェクトでは、npm install コマンドをローカルで実行して、プロジェクトの依存関係をダウンロードし、プロジェクト・ディレクトリー内の node_modules ディレクトリーに配置することが一般的です。 Git リポジトリを小さく保つために、.gitignore ファイルに node_modules ディレクトリを含めるのは良い習慣です。 ただし、Dockerfile でも npm install (または npm ci) を実行しなければならないことを忘れるというミスがよくあります。 例えば Dockerfile で node_modules コマンドを使用してプロジェクト全体をコンテナーにコピーすれば、ローカルで実行する Docker ビルドはローカルの COPY . /app ディレクトリーにアクセスできます。 しかし、Code Engine ビルドは新しくチェックアウトされた Git リポジトリーから実行されるので、node_modules ディレクトリーにアクセスできません。 そのため、ビルドの一部として、Dockerfile で npm install (または npm ci) を実行する必要があります。

node_modules のようなディレクトリも .dockerignore ファイルに含めると、ローカルで実行する Docker ビルドが Code Engine ビルドと同じように動作します。

ローカルで正常にビルドできるプロジェクトが Code Engine のビルドで失敗するもう 1 つの原因は、セキュリティーの制限です。 アプリケーションやバッチ・ジョブ同様、Code Engine では、Code Engine クラスター内で任意のシステム操作は行えません。 こうしたシステム操作のほとんどは、Docker ビルドには関係ありません。 ただし、Code Engine では特権が付与されたポートでサーバー・ソケットを開くことはできません。 範囲は 0 to 1023 です。 例えば、Web アプリケーションをビルドし、ビルドに、Web アプリケーション・サーバーを起動するテスト・ステップが含まれる場合、このサーバーに大きな番号のポートを使用する必要があります。