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

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

環境変数を設定して更新する

ビルドプロセスに追加の構成が必要になることがあります。App Hosting では、Firebase コンソールまたは apphosting.yaml で、プロジェクトのこのタイプのデータを保存および取得するための環境構成が提供されています。

コンソールで環境変数を設定するのが、最も手軽な方法です。シークレットパラメータを保存してアクセスする必要がある場合、ビルド時または実行時にのみ使用可能な変数を設定する必要がある場合、または複数の環境間で環境変数を共有する必要がある場合は、apphosting.yaml を使用します。コンソールと apphosting.<env>.yaml の両方で、環境ごとに異なる値を設定できます。

Firebase コンソール

環境変数を追加するための Firebase コンソールのダイアログのスクリーンショット

`apphosting.yaml`

env:
-   variable: STORAGE_BUCKET
    value: mybucket.firebasestorage.app

変数を更新する

環境変数の追加と編集は、バックエンドの [設定] タブの Firebase コンソールで行えます。[View Backend] >> [Settings] >> [Environment] に移動し、環境変数を追加、編集、削除します。

apphosting.yaml, で環境変数を追加して編集するには、ファイルを手動で作成して編集します。

変更は次回のロールアウト時にのみ有効になり、現在のロールアウトには影響しません。保存して新しいロールアウトを作成するか、変数を保存して後でデプロイします。

変数の可用性を設定する

Firebase コンソールで作成された環境変数は、ビルド時と実行時の両方で使用できます。これは、availability プロパティを使用してスコープを絞り込んでいない限り、apphosting.yaml で定義された変数のデフォルトの条件でもあります。apphosting.yaml では（コンソールでは不可）、環境変数をビルド環境でのみ使用可能にするか、ランタイム環境でのみ使用可能にするように制限できます。

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

Next.js の dotenv ファイル

Next.js アプリの場合、環境変数を含む dotenv ファイルは App Hosting で動作します。

バックエンドを作成または更新するときに、dotenv ファイルの内容全体をコピーして、[環境変数設定] の [新規追加] フォームの最初の [キー] フィールドに貼り付けることで、dotenv ファイルから Firebase コンソールに環境変数を転送できます。

入力が次のような形式であれば、このようにコピーされたすべての環境変数は、個別に各変数を入力する必要なく、フォームにきちんとフォーマットされます。

KEY1=value1
KEY2=value2
KEY3=value3

任意のフレームワークで複雑な環境変数をきめ細かく制御する場合は、apphosting.yaml の使用をおすすめします。

変数の階層

Firebase App Hosting は、変数のソースに基づいて優先順位を適用します。たとえば、コンソールで設定された値は、apphosting.yaml ファイルと dotenv ファイルで設定された値よりも常に優先されます。

優先順位の完全な順序は次のとおりです。

Firebase コンソール → コンソールで設定された変数
apphosting.<env>.yaml → apphosting.staging.yaml などの環境固有の YAML ファイルで指定された変数（複数の環境をデプロイするをご覧ください）
apphosting.yaml → apphosting.yaml ファイルで指定された変数
Firebase システム → firebase_config json または firebase_webapp_config の値を含む Firebase によって設定された変数と、SSR アプリのホスト名とポートを設定する環境変数（bundle.yaml の App Hosting アダプタによって設定）

予約済みの名前と制限事項

有効な変数キーは、先頭を英大文字として、英大文字、数字、アンダースコアのみを使用する必要があります。一部の環境変数キーは内部使用のために予約されています。構成ファイルで以下のキーを使用しないでください。

空の文字列（""）
「=」を含む変数
X_FIREBASE_ で始まる変数
PORT
K_SERVICE
K_REVISION
K_CONFIGURATION
重複するキー

`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 はリクエストの処理中にのみ割り当てられます。

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

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 を使用して Secret を作成できます。必要な権限を追加するよう求められます。このフローでは、シークレット参照を 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 を使用すると、異なるコネクタ/ネットワークを使用して、ステージング環境と本番環境間で移植できます。

ダイレクト VPC 下り（外向き）構成（`apphosting.yaml`）:

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

サーバーレスコネクタの構成（`apphosting.yaml`）:

runConfig:
  vpcAccess:
    egress: ALL_TRAFFIC
    connector: connector-id

バックエンドを管理する

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

バックエンドの作成

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

Firebase コンソール: [ビルド] メニューから 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 以降）

次のコマンドを実行して、App Hosting バックエンドを削除します。これにより、バックエンドのすべてのドメインが無効になり、関連付けられた Cloud Run サービスが削除されます。
```
firebase apphosting:backends:delete BACKEND_ID --project PROJECT_ID
```
（省略可）Artifact Registry の Google Cloud コンソールタブで、「firebaseapphosting-images」にあるバックエンドのイメージを削除します。
Cloud Secret Manager で、シークレット名に「apphosting」が含まれるシークレットを削除します。これらのシークレットが Firebase プロジェクトの他のバックエンドや他の側面で使用されていないことを確認してください。