App Hosting バックエンドの構成と管理

App Hosting は、使いやすさとメンテナンスの容易さを考慮して設計されており、デフォルト設定はほとんどのユースケースに合わせて最適化されています。同時に、App Hosting は、特定のニーズに合わせてバックエンドを管理および構成するためのツールを提供します。このガイドでは、これらのツールとプロセスについて説明します。

apphosting.yaml の作成と編集

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

apphosting.yaml を作成するには、次のコマンドを実行します。

firebase init apphosting

これにより、基本的なスターター apphosting.yaml ファイルが作成され、構成の例（コメントアウト）が追加されます。編集後の一般的な 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.firebasestorage.app
    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）。

cpu と memoryMiB の間には重要な関係があります。メモリは 128 ～ 32768 の任意の整数値に設定できますが、メモリ上限を増やすには 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.firebasestorage.app

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

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

env:
-   variable: STORAGE_BUCKET
    value: mybucket.firebasestorage.app
    availability:
    -   BUILD
    -   RUNTIME

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

env:
-   variable: NEXT_PUBLIC_STORAGE_BUCKET
    value: mybucket.firebasestorage.app
    availability:
    -   BUILD
    -   RUNTIME

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

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

ビルド スクリプトと実行スクリプトをオーバーライドする

App Hosting は、検出されたフレームワークに基づいてアプリのビルド コマンドと起動コマンドを推測します。カスタムのビルドコマンドまたは起動コマンドを使用する場合は、apphosting.yaml で App Hosting のデフォルトをオーバーライドできます。

scripts:
  buildCommand: next build --no-lint
  runCommand: node dist/index.js

ビルド コマンドのオーバーライドは、他のビルド コマンドよりも優先され、アプリがフレームワーク アダプタから除外され、App Hosting が提供するフレームワーク固有の最適化が無効になります。アプリの機能がアダプターで十分にサポートされていない場合に最適です。ビルドコマンドを変更しても、提供されているアダプタを使用する場合は、App Hosting フレームワーク アダプタで説明されているように、package.json でビルド スクリプトを設定します。

App Hosting で推測されたコマンドとは異なる、アプリの起動に使用する特定のコマンドがある場合は、実行コマンドのオーバーライドを使用します。

ビルド出力を構成する

App Hosting は、フレームワークで指定された未使用の出力ファイルを削除することで、デフォルトでアプリのデプロイを最適化します。アプリのデプロイ サイズをさらに最適化する場合や、デフォルトの最適化を無視する場合は、apphosting.yaml でオーバーライドできます。

outputFiles:
  serverApp:
    include: [dist, server.js]

include パラメータには、アプリのデプロイに必要なアプリのルート ディレクトリを基準としたディレクトリとファイルのリストを指定します。すべてのファイルを保持する場合は、include を [.] に設定すると、すべてのファイルがデプロイされます。

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

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

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

  -   variable: API_KEY
      secret: myApiKeySecret

Cloud Secret Manager の Secret には複数のバージョンを設定できます。デフォルトでは、ライブ バックエンドで使用可能なシークレット パラメータの値は、バックエンドがビルドされた時点で使用可能な最新バージョンのシークレットに固定されます。パラメータのバージョニングとライフサイクル管理の要件がある場合は、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 バックエンドに権限を付与する必要があります。

VPC アクセスを構成する

App Hosting バックエンドは Virtual Private Cloud（VPC）ネットワークに接続できます。詳細と例については、Firebase App Hosting を VPC ネットワークに接続するをご覧ください。

apphosting.yaml ファイルの vpcAccess マッピングを使用して、アクセスを構成します。完全修飾ネットワーク名または ID を使用します。ID を使用すると、異なるコネクタ/ネットワークを使用して、ステージング環境と本番環境間で移植できます。

runConfig:
  vpcAccess:
    egress: PRIVATE_RANGES_ONLY # Default value
    networkInterfaces:
      # Specify at least one of network and/or subnetwork
      - network: my-network-id
        subnetwork: my-subnetwork-id

バックエンドを管理する

App Hosting バックエンドの基本的な管理コマンドは、Firebase CLI と Firebase コンソールで提供されます。このセクションでは、バックエンドの作成や削除など、一般的な管理タスクについて説明します。

バックエンドの作成

App Hosting バックエンドは、ウェブアプリの構築と実行のために App Hosting が作成するマネージド リソースのコレクションです。

Firebase コンソール: [ビルド] メニューから [アプリ ホスティング] を選択し、[開始] を選択します。

CLI:（バージョン 13.15.4 以降）バックエンドを作成するには、ローカル プロジェクト ディレクトリのルートから次のコマンドを実行し、引数として projectID を指定します。

firebase apphosting:backends:create --project PROJECT_ID

コンソールまたは CLI のいずれの場合も、プロンプトに沿って リージョンを選択し、GitHub 接続を設定して、次の基本的なデプロイ設定を構成します。

  • アプリのルート ディレクトリを設定します（デフォルトは /）。

    通常、ここに package.json ファイルが配置されます。

  • ライブブランチを設定する

    これは、ライブ URL にデプロイされる GitHub リポジトリのブランチです。多くの場合、機能ブランチや開発ブランチがマージされるブランチです。

  • 自動ロールアウトを承認または拒否する

    自動ロールアウトはデフォルトで有効になっています。バックエンドの作成が完了したら、アプリをすぐに App Hosting にデプロイするように選択できます。

  • バックエンドに名前を割り当てます。

バックエンドの削除

バックエンドを完全に削除するには、まず Firebase CLI または Firebase コンソールを使用して削除してから、関連するアセットを手動で削除します。このとき、他のバックエンドや Firebase プロジェクトの他の側面で使用される可能性のあるリソースを削除しないように注意してください。

Firebase コンソール: [設定] メニューから [バックエンドを削除] を選択します。

CLI:（バージョン 13.15.4 以降）

  1. 次のコマンドを実行して、App Hosting バックエンドを削除します。これにより、バックエンドのすべてのドメインが無効になり、関連付けられた Cloud Run サービスが削除されます。

    firebase apphosting:backends:delete BACKEND_ID --project PROJECT_ID

  2. （省略可）Artifact Registry の Google Cloud コンソール タブで、「firebaseapphosting-images」にあるバックエンドのイメージを削除します。

  3. Cloud Secret Manager で、シークレット名に「apphosting」が含まれるシークレットを削除します。これらのシークレットが Firebase プロジェクトの他のバックエンドや他の側面で使用されていないことを確認してください。