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

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

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

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

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

Firebase コンソール

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

`apphosting.yaml`

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

変数を更新する

Firebase コンソールまたは apphosting.yaml を使用して、環境変数を追加、編集、削除できます。

Firebase コンソール:
1. Firebase コンソールで、[**Hosting とサーバーレス**] > [**App Hosting**] に移動します。
2. [バックエンドを表示] > [設定] > [環境] に移動します。
3. 環境変数を追加、編集、削除します。
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 ファイルの内容全体を Firebase コンソールの [新規追加] フォームの最初の [キー] フィールドにコピーして貼り付けることで、dotenv ファイルから環境変数を転送できます。 [環境変数設定]

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

KEY1=value1
KEY2=value2
KEY3=value3

フレームワークで複雑またはきめ細かい環境変数制御を行う場合は、we recommend using apphosting.yaml。

自動的に設定される環境変数

App Hosting によって自動的に設定される環境変数があります。これには、によって設定される環境変数と、設定時にバックエンドに appId が設定されている場合の Firebase 固有の環境変数があります。Google Cloud

FIREBASE_CONFIG:（ビルド環境とランタイム環境で使用可能）次のような Firebase プロジェクトの構成情報を提供します。
```
{
  "databaseURL": 'https://DATABASE_NAME.firebaseio.com',
  "storageBucket": 'PROJECT_ID.firebasestorage.app',
  "projectId": 'PROJECT_ID'
}
```
引数を指定せずに Firebase Admin SDK を初期化すると、この構成が自動的に適用されます。
FIREBASE_WEBAPP_CONFIG:（ビルド環境でのみ使用可能）次のような Firebase プロジェクトの構成情報を提供します。
```
{
  "apiKey": 'API_KEY',
  "appId": 'APP_ID',
  "authDomain": 'AUTH_DOMAIN.firebaseapp.com',
  "databaseURL": 'https://DATABASE_NAME.firebaseio.com',
  "messagingSenderId": 'PROJECT_NUMBER',
  "projectId": 'PROJECT_ID',
  "storageBucket": 'PROJECT_ID.firebasestorage.app',
}
```
Firebase JS SDK は、ビルド時に postinstall スクリプトでこの FIREBASE_WEBAPP_CONFIG 環境変数を自動的にチェックするため、引数なしでクライアント SDK を初期化することもできます。

これらの環境変数を使用して SDK を初期化する方法について詳しくは、Firebase Admin SDK とウェブ SDK を自動的に初期化するをご覧ください。

実際の Firebase 構成の値は、プロジェクトでプロビジョニングした特定のリソースに対応します。

変数の階層

Firebase App Hosting は、ソースに基づいて優先順位を付けて変数を適用します。たとえば、Firebase コンソールで設定された値は、apphosting.yaml と dotenv ファイルで設定された値を常にオーバーライドします（優先されます）。

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

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

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

Cloud Run コンテナランタイムの契約で定義されている環境変数は予約されているため、設定はできません。

環境によって提供される環境変数（自動的に設定される変数を除く）は、将来のランタイムバージョンで変更される可能性があります。明示的に設定していない環境変数に依存する、またはそれらの変数を変更しないことをおすすめします。競合を回避するため、環境変数の前に一意のキーを付けることを検討してください。

一部の環境変数キーは内部使用のために予約されています。構成ファイル内で以下のキーを使用しないでください。

空の文字列（""）
「=」を含むキー
X_FIREBASE_、X_GOOGLE_、CLOUD_RUN_ で始まるキー
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 は、検出されたフレームワークに基づいてアプリのビルドコマンドと起動コマンドを推測します。カスタムのビルドコマンドまたは起動コマンドを使用する場合は、 App Hosting のデフォルトを apphosting.yaml でオーバーライドできます。

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

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

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

ビルド出力を構成する

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

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

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

Secret パラメータを保存してアクセスする

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

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

  -   variable: API_KEY
      secret: myApiKeySecret

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

  - variable: PINNED_API_KEY
    secret: myApiKeySecret@5

Secret は、Firebase CLI コマンド firebase apphosting:secrets:setで作成できます。必要な権限を追加するよう求められます。このフローでは、Secret 参照を apphosting.yaml に自動的に追加できます。

Cloud Secret Manager のすべての機能を使用するには、Cloud Secret Manager コンソールを使用します。この場合は、App Hosting バックエンドに権限を付与する必要があります。これには、Firebase CLI コマンド firebase apphosting:secrets:grantaccess を使用します。

VPC アクセスを構成する

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

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 コンソールとFirebase CLI で提供されます。このセクションでは、バックエンドの作成や削除など、一般的な管理タスクについて説明します。

バックエンドの作成

App Hosting バックエンドは、 App Hosting がウェブアプリのビルドと実行のために作成する管理対象リソースのコレクションです。

Firebase コンソール: [Hosting とサーバーレス] > [App Hosting] に移動し、 [バックエンドを作成] をクリックします（Firebase プロジェクトで最初のバックエンドの場合は、[使ってみる] をクリックします）。

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

firebase apphosting:backends:create --project PROJECT_ID

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

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

通常、package.json ファイルはここにあります。

ライブブランチ を設定します

これは、一般公開 URL にデプロイされる GitHub リポジトリのブランチです。多くの場合、機能ブランチまたは開発ブランチがマージされるブランチです。
自動ロールアウト を承諾または拒否します

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

バックエンドの削除

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

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

Firebase CLI: （v13.15.4 以降）

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