App Hosting のビルドプロセス

Firebase App Hosting は Cloud Build を使用して、アプリケーションのソースコードを Cloud Run へのデプロイに適したコンテナ化された形式に変換します。

ビルドプロセスは、次の主要な段階を経て行われます。

  1. ubuntu: ワークスペースの初期化。

  2. preparer: アプリケーションのソースコードと構成を収集します。

  3. pre-buildpack: Buildpack 環境を準備します。

  4. build: 依存関係をインストールして、アプリケーションをビルドします。

  5. publisher: 本番環境の Cloud Run コンテナを確定します。

これらの 5 つのステップは、 Cloud Build の Google Cloud コンソールに表示されるビルドステップに直接対応しています。

Cloud Build ステップの Google Cloud コンソール ビューのスクリーン キャプチャ

ワークスペースの初期化

このステージは、ubuntu ビルドステップに対応しています。 ビルド ワークスペースを初期化し、後続のビルドステップで使用されるディレクトリに適切なファイル権限が設定されるようにします。

準備ツール

このステージでは、ビルド前のロジックを処理します。ユーザー定義の環境変数を読み取り、サニタイズして書き込みます。apphosting.yaml ファイルで指定されたシークレットの参照を解除して固定します。

ビルド前パック

このステップでは、Cloud Native Buildpacks ライフサイクル の環境を準備します。これには、前のステージで準備した構成と環境変数を CNB ツールで想定される形式に変換するシムの実行が含まれます。

ビルド

これはビルドプロセスのコアであり、実行可能なコンテナ イメージと、ビルド構成を定義する bundle.yaml ファイルを生成します。 Cloud Native Buildpack と ライフサイクル クリエイター バイナリを使用して、 アプリケーションを効率的にパッケージ化します。bundle.yaml ファイルの詳細については、GitHub をご覧ください。

Buildpack は、アプリケーションのソースコードを本番環境に対応したコンテナ イメージに変換します。Firebase App Hosting は、 複数の Buildpack を連結してビルドプロセスを完了します。

  1. ランタイム Buildpack: 基本的な Node.js アプリケーションを実行するために必要なすべてのコンポーネントが含まれ、依存関係がインストールされていることを確認します。
  2. Monorepo Buildpack: さまざまな モノリポ シナリオを処理するように後続の Buildpack を構成します。

  3. フレームワーク Buildpack: 正しいフレームワーク アダプター（ Angular や Next.js など）をインストールし、後続の Buildpack を準備します。

    フレームワーク アダプターは、本番環境に対応したビルド コマンドを実行し、関連するフレームワーク固有の構成値を App Hosting で読み取り可能な標準形式にマッピングします。App Hosting

  4. パッケージ マネージャー Buildpack: 依存関係のインストールを実行し、 npm、yarn、pnpm を使用してアプリをビルドします。

  5. 出力バンドル Buildpack: 実行コマンドを定義し、実行用の出力 バンドルを準備します。

パブリッシャー

この最終ステージでは、アプリケーションのソースコードから抽出されたすべての情報とビルド コンテナ イメージをパッケージ化し、App Hosting バックエンドに送信します。App Hosting バックエンドは、この情報を使用して適切な構成で Cloud Run を設定します。

ビルド クリーンアップ ポリシー

Firebase App Hosting は、ビルドの保持とクリーンアップの自動化ポリシーを適用します。このポリシーでは、 App Hosting は過去 14 日間の成功したビルドと、それに関連付けられた Cloud Run リビジョンを保持します。また、常にロールバックできるビルドを確保するため、App Hosting は、成功した最新の 5 つのビルドとロールアウトを保持します。

App Hosting は、現在アクティブな トラフィック分割に含まれているビルドや、進行中のロールアウトに関連付けられているビルドを削除または削除することはありません。

古いビルドがこれらの保持上限を超えると、内部ステータスが EXPIRED に更新されます。EXPIRED ビルドに対して即時ロールバックを実行することはできません。また、これらのビルドにロールバックするオプションは Firebaseコンソールから削除されます。代わりに、同じソース（git コミット、Artifact Registry のコンテナ、Google Cloud Storage バケット）をターゲットとする新しいビルドを作成して、ロールアウトする必要があります。

ビルドリソースを節約する方法の一つは、自動ロールアウトをトリガーする頻度を制御することです。 自動ロールアウトの管理をご覧ください。

詳細

App Hosting のビルドプロセス全体がオープンソースです。