ビルドパイプライン

ビルドは Lizard のビルドノード上で実行されます：ローカルに Docker は不要です。デプロイすると、プラットフォームは固定の判定順序に従って、ソースをどのようにコンテナイメージへ変換するかを決定し、その後そのイメージを分離された pod で実行します。すべての container as a service がイメージをビルドしてくれるわけではありません。このブログでは、このカテゴリにある 3 つの形態を比較しています。

ビルドの判定順序

プラットフォームは次の順序で、ビルド戦略をちょうど 1 つ選びます:

1. dockerfilePath のリポジトリ Dockerfile：サービスに dockerfilePath が設定されている場合、ビルドコマンドや開始コマンドが設定されていても、その Dockerfile が変更されずに使用されます。startCommand が設定されていれば、実行時には Dockerfile の ENTRYPOINT と CMD がそれに置き換えられます。Dockerfile でデプロイする を参照してください。
2. 合成された Dockerfile：それ以外で、サービスに buildCommand および/または startCommand が設定されている場合（または lizard up --build-command / --start-command 経由で渡された場合）、Lizard はそれらのコマンドから Dockerfile を生成します。lizardpack は呼び出されません。
3. ソース内の Dockerfile：それ以外の場合、ビルドディレクトリのルートにある Dockerfile が使用されます（後述の GitHub の例外を参照）。
4. lizardpack 自動検出：それ以外の場合、プラットフォームはビルドパック / Dockerfile ジェネレーターである lizardpack を実行します。

lizardpack 自動検出

lizardpack はリポジトリを検査し、最適化されたマルチステージイメージをビルドします。サポートされるスタックは次の順序で照合されます:

Hugo → Go → Node → Python → Rust → Ruby → PHP → Java → static

本番用スクリプト、アダプター、出力パス、ポートについては フレームワークガイド を参照してください: Hugo、Go、Node (Node.js、Next.js、Nuxt、SvelteKit、Astro、React、Vue、Docusaurus、VitePress)、Python (Django、FastAPI、Streamlit)、Ruby (Rails)。検出はプロジェクトファイルと依存関係を調べます。複数のプロバイダーに一致する場合は、この順序で選びます。Node.js や Python のバージョンを固定するには、ランタイムバージョン を参照してください。

この経路では:

• アップロードされたソース（lizard up）では、ルートの Dockerfile が常に書かれたとおりに使用されます。
• GitHub ソースでは、ルートの Dockerfile は不完全に見えない限り、書かれたとおりに使用されます。不完全と見なされるのは、build、dist、out、.next、public を末尾のスラッシュなしで COPY していて（COPY dist /usr/share/nginx/html）、npm、yarn、pnpm、bun、pip、pip3、bundle、cargo、go build、mvn、gradle で始まる RUN 行がない場合です。その場合は lizardpack が代わりの Dockerfile を生成します。
• Dockerfile がない場合は、lizardpack が生成します。
• 開始コマンド は自動検出されます: Procfile web: の行（Python/Ruby）または package.json scripts.start（Node）が自動的に検出されます。Django、Flask、FastAPI がそれぞれ必要とする正確な行については、Pythonアプリホスティング を参照してください。
• ポート は EXPOSE、フレームワークのデフォルト、または明示的な PORT 環境変数から推定されます。

注意: GitHub ソースでは、事前ビルド済みの出力をコピーし（COPY dist /dest）、パッケージマネージャーの RUN ステップがない Dockerfile は、不完全と見なされ、lizardpack によって再生成されます。実際のビルドステップを追加するか、dockerfilePath を設定してそのまま使用するよう強制してください。Dockerfile の変更が反映されない を参照してください。

何が再ビルドを引き起こすか

二重にビルドしないでください。 稼働中のサービスでビルドフィールドを変更する service set の後は、再ビルドが自動で始まります：その後に lizard redeploy を続けないでください。そのビルドがキャンセルされ、最初からやり直しになります (理由)。クラッシュしたサービスや一度もデプロイされていないサービスは、自動では再ビルドされません。lizard redeploy を実行してください。

ビルド時の変数

Lizard は次の 2 つの場合に、VITE_* と NEXT_PUBLIC_* 変数を ENV 行として Dockerfile に書き込みます:

• dockerfilePath のない GitHub サービス: lizardpack の Dockerfile、またはリポジトリのルートの Dockerfile に書き込まれます。
• buildCommand または startCommand があり、合成された Dockerfile が Node のビルドであるサービス。

ビルドコマンドも開始コマンドもなしに lizard up でデプロイしたサービスには、ビルド時に Lizard の変数は渡されません。COMMIT_SHA 以外のビルド引数はどのサービスにも渡されないため、Dockerfile 内の ARG は空のままになります。lizard up で公開値を使うには、.env.production にコミットする（.gitignore で除外されていないか確認してください）、Dockerfile に書き込む、または Node のサーバーアプリなら buildCommand と startCommand の両方を設定する、のいずれかを行ってください。

ビルドを監視する

ビルドログは lizard up 中にストリーミングされます。どのサービスでも:

lizard logs --build            # the most recent build's logs
lizard events                  # deploy history + replica status

ビルドが失敗した場合は、lizard logs --build を読み、原因を修正し（リポジトリ内、または lizard service set 経由で buildCommand / startCommand を調整して）、その後 lizard redeploy を実行してください。

ランタイムに関する注意

• Docker の HEALTHCHECK はありません。 ランタイムは Docker の healthcheck ループを実行しないため、HEALTHCHECK ディレクティブは無視されます。代わりに Lizard はポートに対して TCP プローブを実行します（worker mode ではスキップされます）。
• 求められていないのに Dockerfile を書かないでください。 lizardpack はほとんどのスタックを自動検出します：まずデプロイを試し、自動ビルドが合わない場合にのみ Dockerfile を追加する（または dockerfilePath を設定する）ようにしてください。

ビルド設定リファレンス

これらはいずれも lizard service set <svc> --set <field>=<value> で設定できます。フィールドをクリアするには、--set buildCommand= のように空の値を指定します。lizard service を参照してください.

更新日 2026年10月21日