デプロイメントの失敗

アプリケーションをデプロイする際、ビルドまたはロールアウトの段階でエラーが発生し、失敗する場合があります。こちらのページでは、特定のデプロイメントエラーのトラブルシューティング方法をご紹介します。それそれ以下の手順に従ってもエラーが解決しない場合は、一般的なトラブルシューティング方法をご覧ください。

ビルドプロセス失敗「No Buildpack Groups Passed Detection」

アプリケーションをデプロイする際、ビルドプロセスでアプリケーションのBuildpackの検出に問題があると、「デプロイメントの詳細」に以下のようなエラーが表示されることがあります。

ビルドプロセス失敗
不明なビルドエラーが発生しました

「デプロイメントの詳細」のエラーをクリックして、ビルドプロセスのログを表示し、以下のようなエラーを探してください。

===> DETECTING
ERROR: No buildpack groups passed detection.
ERROR: Please check that you are running against the correct path.
ERROR: failed to detect: no buildpacks participating
ERROR: failed to build: executing lifecycle: failed with status code: 20

このエラーは、アプリケーションの種類を正しく検出するための情報が十分でない場合に発生します。通常、以下のいずれかが原因です。

• Gitリポジトリにアプリケーションに必要なすべてのファイルが含まれていない
• コードや設定によって誤ったBuildpackが選択されている
• ビルドパスが正しくない

Git リポジトリ

リポジトリにアプリケーションに必要なファイルがすべて反映されていることを確認してください。

Buildpack

アプリケーションの追加時に「コンテナイメージを自動で設定」を選択すると、Buildpackを使ってアプリケーション用のコンテナが自動的に決定、セットアップされます。アプリケーションに追加のBuildpackが必要な場合は、アプリケーションの「設定」画面で追加可能です。

Buildpackを使用する場合は、アプリケーションのファイルに正しい言語バージョンが含まれているかどうかを確認してください。詳しくは、NixpacksまたはBuildpacksに関するドキュメントをご覧ください。

ビルドパス

ビルドパスは、アプリケーションのビルドに必要なファイルへのリポジトリ内のパスを意味します。通常はリポジトリのルートとなり、アプリケーションの追加時にビルドパスを設定する必要はありません。

アプリケーションのビルドパスが異なる場合は、アプリケーションを追加する際に設定するか、「設定」（「設定」＞「情報を編集」＞「ビルドパス」）で変更することができます。例えば、アプリケーションをサブディレクトリ（例：app）からビルドする場合は、「ビルドパス」のフィールドに、そのサブディレクトリのパス「/app」を入力します。

プロセスが早く終了したことによるビルドの失敗

アプリケーションのデプロイ時に、ビルド処理に問題がある場合、以下のようなエラーが表示されることがあります。

プロセスが早く終了したため、ビルドが失敗しました。これはおそらく、システムがメモリ不足に陥ったか、誰かがプロセスに対してkill -9を呼び出したことを意味します

通常、アプリケーションビルドマシンのシステムメモリが不十分であることが原因です。

このエラーを解決するには、アプリケーションのビルドマシンのサイズを引き上げることができます。「プロセス」の「ビルドの更新」をクリックして、より大きなビルドマシンを選択し、「ビルドの更新」をもう一度クリックして、変更を確認します。

ロールアウトの失敗

アプリケーションのデプロイ時に何かしらのエラーが生じた場合、以下のようなエラーメッセージが表示されることがあります。

アプリケーションでロールアウトエラーが発生しました。ドキュメントで対処法をご紹介しています。これを参考にしても問題が解決しない場合には、お気軽にカスタマーサポートまでお問い合わせください

ビルドプロセス失敗
不明なビルドエラーが発生しました

ロールアウトプロセスがすぐに失敗した場合、またはビルドプロセスに失敗した場合、Podは作成されず、実行ログも生成されることはありません。主にウェブプロセスでの不正なstartコマンドが正しくないことが原因です（Dockerfileでビルドされたアプリケーションは、Dockerfileの正しくないENTRYPOINTも原因になります）。

ロールアウトプロセスが1～2分実行された後に失敗した場合も、通常Podと実行ログは作成されず、何かしらの誤りが原因でプロセスが停止したことを意味します。この場合は、アプリケーションの実行ログを閲覧し、エラーメッセージを確認してください。エラーメッセージはアプリケーションのコードのバグを特定するのに役立ち、効率的に問題のデバッグを行うことができます。

以下にご紹介するトラブルシューティングを行った上で、エラーの原因を特定できない場合は、弊社カスタマーサポートまでお問い合わせください。

Gitリポジトリ

アプリケーションの正しいファイルが、すべてリポジトリに反映されていることを確認してください。

言語

アプリケーションを追加し、コンテナイメージの作成にNixpacksまたはBuildpacksを選択すると、アプリケーション用のコンテナが自動的に検出、設定されます。また、NixpackまたはBuildpackを使用する場合は、アプリケーションのファイルに正しい言語バージョンが含まれていることを確認してください。詳細については、Buildpacksの言語バージョンの指定またはNixpacksの言語バージョンの指定に関するドキュメントをご覧ください。

Nixpacksでコンテナイメージを設定し、PHPまたはPythonアプリケーションをデプロイしてロールアウトに失敗する場合は、アプリケーションのコードに言語バージョンの指定がない可能性が高いです。以下を確認し、言語バージョンが設定されていることを確認してください。

PHP

リポジトリにcomposer.jsonファイルがある場合は、requireキーとPHPバージョンを含む必要があります。

{
  "require": {
    "php": "~8.1.0"
  }
}

Python

Pythonのバージョンを指定するには、アプリケーションのruntime.txtファイルに次のように記述してください。

python-3.10.13

startコマンドまたは ENTRYPOINT

アプリケーションは、ウェブプロセスのstartコマンド、またはENTRYPOINTによって起動します。これに誤りがある場合、アプリケーションは実行されません。このコマンドは、MyKinstaで確認可能です。

• 「プロセス」＞「ランタイムプロセス」＞「ウェブプロセス」
• 「デプロイメント」＞「履歴」に移動し、該当のアプリケーションを選択して、「デプロイメントの詳細」画面下に表示される「ロールアウトプロセス」の文字を見つける

Dockerfileを使用してコンテナイメージをセットアップする場合は、コンテナの実行に、DockerfileでのENTRYPOINT指定が必要になります。アプリケーションのENTRYPOINTを指定する方法については、Dockerfileについての公式ドキュメントをご覧ください。

言語別コマンド例についてはこちらをご覧ください。

ビルドパスまたはDockerfileコンテキスト

アプリケーションを追加する際は、NixpackまたはBuildpackを使用してコンテナイメージを自動設定するか、Dockerfileを使用してコンテナイメージを設定するかを選択します。

• ビルドパス：NixpackとBuildpackにのみ適用され、アプリケーションのビルドに必要なファイルへのリポジトリ内のパスを意味します。一般的には、リポジトリルート（.）からビルドされますが、別のビルドパスがある場合は、このフィールドで指定してください。アプリケーションをサブディレクトリ（例：app）からビルドする場合は、このフィールドに「app」と入力します。これはモノレポを使用している場合にも便利です。
• コンテキスト：Dockerfilesにのみ適用され、アプリケーションのビルドに必要なリポジトリ内のパスを意味します。一般的には、リポジトリルートからビルドされるため、その場合は、このフィールドにリポジトリルート（.）を入力してください。アプリケーションをサブディレクトリ（例：app）からビルドする場合は、このフィールドに「app」と入力します。

ビルドパスおよびDockerfileのコンテキストは、アプリケーションの「設定」画面で確認・変更可能です。

環境変数

環境変数は、アプリケーションに対してその外から情報を与えるものです。環境変数に誤りがあると、アプリケーション実行の妨げになることがあります。環境変数は「設定」＞「環境変数」で確認可能です。

この画面で正しい環境変数が存在し、有効な値が含まれていることを確認します。環境変数の作成・確認の際には、以下の点に注意してください。

• 各キーはすべて一意で、一度しか使用できません。
• 括弧を使用することはできません。デプロイ中に使用可能になるタイミングにもよりますが、ビルドまたはロールアウト処理に失敗する可能性があります。
• エスケープされていないカンマ（ , ）はロールアウトプロセスで区切り文字として認識されるため、使用できません。環境変数の値でカンマを使用するには、バックスラッシュ（\）でエスケープする必要があります。
• エスケープされていない二重引用符（ ” ）は無視されるか、ロールアウト処理の失敗の原因となります。環境変数で二重引用符を使用する必要がある場合は、バックスラッシュ（\）でエスケープする必要があります。

内部接続とビルドプロセス

内部接続はランタイム時に利用可能ですが、ビルドプロセス中に利用することはできません。

この理由から、ビルドプロセス中にアプリケーションが内部接続でデータベースに接続しようすると、データベースが実行できないことを伝えるエラーが発生し、ビルドに失敗します。

これを回避するいくつかの方法があります。

方法1. データベースに接続するロジックをアプリケーションのビルドコマンドからstartコマンドに移動する。例）ビルドプロセスにprisma migrateのようなコマンドがあり、そのコマンドをstartコマンドに移動させると、アプリケーションは実行時にのみデータベースにアクセスするようになり、ビルドに成功します。

方法2. データベース接続に必要な環境変数を個別に追加し、1つはビルドプロセスで、もう1つはランタイムでのみ使用できるようにする。一方がビルドプロセス中にのみ、他方がランタイム時にのみ利用可能である限りは、同じキー（例: DB_CONNECTION_URL）でも問題ありません。ビルドプロセスで使用する変数の値は、データベースの外部接続の情報（「データベース」＞（データベース名）＞「補足」＞「外部接続」）を使用します。

ポート

アプリケーションホスティングでは、ポート80と443のみ開かれています。アプリケーションでポートを開く場合は、8080を使用してください。

無効なパッケージ名

package.jsonの無効なパッケージ名は、エラーを引き起こすことがあるため、パッケージ名に「js」や「node」は使用しないでください。詳しくは、npmの公式ドキュメントをご覧ください。