Watch demos on how to build & run AI-powered apps with Firebase at Demo Day '24. Watch now.

このページは Cloud Translation API によって翻訳されました。

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

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

バックエンドを構成する

環境変数や、同時実行、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 ～ 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.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

シークレットパラメータを保存してアクセスする

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

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 を使用して Secret を作成すると、必要な権限を追加するよう求められます。このフローでは、シークレット参照を apphosting.yaml に自動的に追加できます。

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

Firebase Auth の状態を同期する

Firebase Auth を使用するアプリでは、Firebase Web SDK を使用して、認証状態をクライアントとサーバーの間で同期することを検討してください。これは、サービスワーカーで FirebaseServerApp を実装することで実現できます。基本的なタスクフローは次のとおりです。

サーバーへのリクエストでアプリに適切なヘッダーを追加するサービスワーカーを実装します。
サーバーでリクエストからヘッダーを取得し、FirebaseServerApp を使用して認証ユーザーに変換します。

バックエンドを管理する

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

バックエンドの作成

App Hosting バックエンドは、App Hosting がウェブアプリの構築と実行のために作成するマネージドリソースのコレクションです。プロジェクトオーナーは、Firebase コンソールまたは Firebase CLI を使用して、プロジェクトの最初の App Hosting バックエンドを作成できます。この初期設定後、App Hosting 管理者は追加のバックエンドを作成して管理することもできます。詳細については、Firebase App Hosting IAM ロールをご覧ください。

Firebase コンソール: [Build] メニューで [App Hosting]、[Get started] の順に選択します。

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

firebase apphosting:backends:create --project PROJECT_ID --location us-central1

コンソールまたは CLI のどちらでも、プロンプトに沿ってバックエンドに名前を割り当て、GitHub 接続を設定し、次の基本的なデプロイ設定を構成します。

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

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

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

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

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

バックエンドの削除

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

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