アプリのホスティングを構成する

環境変数や、同時実行、CPU、メモリの上限などのランタイム設定などの高度な構成の場合は、アプリのルート ディレクトリに apphosting.yaml ファイルを作成して編集する必要があります。このファイルは、Cloud Secret Manager で管理されるシークレットへの参照もサポートしているため、ソース管理に安全にチェックインできます。

一般的な apphosting.yaml ファイルは次のようになります。これには、バックエンドの Cloud Run サービスの設定、環境変数、Cloud Secret Manager によって管理されるシークレットへの参照が含まれます。

# Settings for Cloud Run
runConfig:
  minInstances: 2
  maxInstances: 100
  concurrency: 100
  cpu: 2
  memoryMiB: 1024

# Environment variables and secrets
env:
  - variable: STORAGE_BUCKET
    value: mybucket.appspot.com
    availability:
      - BUILD
      - RUNTIME

  - variable: API_KEY
    secret: myApiKeySecret

    # Same as API_KEY above but with a pinned version.
  - variable: PINNED_API_KEY
    secret: myApiKeySecret@5

    # Same as API_KEY above but with the long form secret reference as defined by Cloud Secret Manager.
  - variable: VERBOSE_API_KEY
    secret: projects/test-project/secrets/secretID

    # Same as API_KEY above but with the long form secret reference with pinned version.
  - variable: PINNED_VERBOSE_API_KEY
    secret: projects/test-project/secrets/secretID/versions/5

このガイドの残りの部分では、これらの設定例の詳細とコンテキストについて説明します。

Cloud Run サービス設定を構成する

apphosting.yaml 設定を使用して、Cloud Run サービスのプロビジョニング方法を構成できます。Cloud Run サービスで使用可能な設定は、runConfig オブジェクトで提供されます。

  • cpu – サービスを提供する各インスタンスで使用される CPU の数(デフォルトは 0)。
  • memoryMiB - サービスを提供する各インスタンスに割り当てられたメモリ量(MiB 単位、デフォルトは 512)
  • maxInstances - 一度に実行するコンテナの最大数(デフォルトは 100、割り当てで管理)
  • minInstances - 常に存続するコンテナの数(デフォルトは 0)。
  • concurrency - サービスを提供する各インスタンスが受信できるリクエストの最大数(デフォルトは 80)。

cpumemoryMiB の重要な関係に注意してください。メモリは 128 ~ 32, 768 の任意の整数値に設定できますが、メモリ上限を増やすと CPU 上限を増やす必要がある場合があります。

  • 4 GiB を超える場合は少なくとも 2 つの CPU が必要です
  • 8 GiB を超える場合は 4 個以上の CPU が必要
  • 16 GiB を超える場合は 6 個以上の CPU が必要
  • 24 GiB を超える場合は 8 個以上の CPU が必要

同様に、cpu の値は同時実行の設定に影響します。1 CPU 未満の値を設定する場合は、同時実行を 1 に設定する必要があります。これにより、リクエストの処理中にのみ CPU が割り当てられます。

ビルド環境を構成する

サードパーティの API キーや調整可能な設定など、ビルドプロセスに追加の構成が必要になる場合があります。App Hosting では、プロジェクトでこのタイプのデータを保存および取得するための環境構成が apphosting.yaml に用意されています。

env:
-   variable: STORAGE_BUCKET
    value: mybucket.appspot.com

Next.js アプリの場合、環境変数を含む dotenv ファイルも App Hosting で動作します。フレームワークできめ細かい環境変数制御を行うには、apphosting.yaml を使用することをおすすめします。

apphosting.yaml では、availability プロパティを使用して、環境変数にアクセスできるプロセスを指定できます。環境変数をビルド環境のみ、またはランタイム環境のみで使用できるように制限できます。デフォルトでは、両方で使用できます。

env:
-   variable: STORAGE_BUCKET
    value: mybucket.appspot.com
    availability:
    -   BUILD
    -   RUNTIME

Next.js アプリの場合は、dotenv ファイルと同じように NEXT_PUBLIC_ 接頭辞を使用して、ブラウザで変数にアクセスできるようにすることもできます。

env:
-   variable: NEXT_PUBLIC_STORAGE_BUCKET
    value: mybucket.appspot.com
    availability:
    -   BUILD
    -   RUNTIME

有効な変数キーは A ~ Z の文字またはアンダースコアで構成されます。一部の環境変数キーは内部使用のために予約されています。構成ファイルで次のキーを使用しないでください。

  • X_FIREBASE_ で始まる変数
  • PORT
  • K_SERVICE
  • K_REVISION
  • K_CONFIGURATION

シークレット パラメータの保存とアクセス

API キーなどの機密情報はシークレットとして保存する必要があります。apphosting.yaml でシークレットを参照することで、機密情報をソース管理にチェックインしないようにできます。

secret 型のパラメータは、Cloud Secret Manager に保存されている値を持つ文字列パラメータを表します。シークレット パラメータは、値を直接導出するのではなく、Cloud Secret Manager に存在するかどうかを確認し、ロールアウト中に値を読み込みます。

  -   variable: API_KEY
      secret: myApiKeySecret

Cloud Secret Manager のシークレットには複数のバージョンを含めることができます。デフォルトでは、ライブ バックエンドで使用可能なシークレット パラメータの値は、バックエンドのビルド時に使用可能な最新バージョンのシークレットに固定されます。パラメータのバージョニングとライフサイクル管理の要件がある場合は、Cloud Secret Manager を使用して特定のバージョンに固定できます。たとえば、バージョン 5 に固定するには、次のようにします。

  - variable: PINNED_API_KEY
    secret: myApiKeySecret@5

CLI コマンド firebase apphosting:secrets:set を使用してシークレットを作成できます。必要な権限を追加するよう求められます。このフローでは、シークレット参照を apphosting.yaml に自動的に追加するオプションを利用できます。

Cloud Secret Manager のフルパッケージを使用するには、代わりに Cloud Secret Manager コンソールを使用します。その場合は、CLI コマンド firebase apphosting:secrets:grantaccess を使用して App Hosting バックエンドに権限を付与する必要があります。

Firebase Auth の状態を同期する

Firebase Auth を使用するアプリでは、Firebase Web SDK を使用して、クライアントとサーバー間で認証状態の同期を維持することをおすすめします。これは、Service Worker で FirebaseServerApp を実装することで簡単に行えます。基本的なタスクフローは次のとおりです。

  1. サーバーへのリクエスト時にアプリの適切なヘッダーを追加する Service Worker を実装します。
  2. サーバー上のリクエストからヘッダーを取得し、FirebaseServerApp を使用してそれを認証ユーザーに変換します。