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

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

App Hosting は、使いやすくメンテナンスが少なくて済むように設計されており、デフォルトの設定がほとんどのユースケース向けに最適化されています同時に App Hosting には、バックエンドの管理と構成のためのツールが用意されています。カスタマイズが可能です。このガイドでは、これらのツールとプロセスについて説明します。

バックエンドを構成する

環境変数やランタイム設定などの高度な構成用機能を使用する場合は、サービスアカウントを作成して編集し、アプリのルートディレクトリにある 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.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）。

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 に設定する必要があります。パフォーマンスが向上します。

ビルド環境を構成する

場合によっては、ビルドプロセスに次のような追加の構成が必要になることがあります。サードパーティの 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 アプリの場合、同じ方法で NEXT_PUBLIC_ 接頭辞を使用することもできます。 dotenv ファイルで設定し、ブラウザで変数にアクセスできるようにします。

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 キーなどの機密情報はシークレットとして保存する必要があります。Google Chat では機密情報のチェックを回避するため、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 のすべての機能を使用するには、代わりにシークレットマネージャーを構成します。これを行う場合は、 CLI コマンド firebase apphosting:secrets:grantaccess を使用して、App Hosting バックエンドに権限を付与します。

Firebase Auth の状態を同期する

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

Service Worker の実装これは、サーバーへのリクエスト時にアプリの適切なヘッダーを追加するものです。
サーバー上のリクエストからヘッダーを取得し、それを認証に変換する FirebaseServerApp を持つユーザー。

バックエンドを管理する

App Hosting バックエンドの基本管理のコマンドは次のとおりです。 Firebase CLI で指定。一部 Firebase コンソールでも確認できます。このセクションではここでは、一般的な管理タスクについて説明します。これには、バックエンドの削除も行います

バックエンドの作成

App Hosting バックエンドは、Google Cloud 内でホストされている App Hosting は、ウェブアプリをビルドして実行するために作成します。Google Cloud コンソールの Firebase コンソールまたは App Hosting バックエンド Firebase CLI。

Firebase コンソール: [ビルド] メニューから [App Hosting] を選択し、 使ってみる

CLI:（バージョン 3.9 以降）バックエンドを作成するには、次のコマンドを実行します。ローカルプロジェクトのディレクトリのルートから project ID を引数として指定（プレビューの場合は、 us-central1 リージョンのみがサポートされています）。

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

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

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

通常は、これが package.json ファイルのある場所です。

live ブランチを設定する

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

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

バックエンドの削除

バックエンドを完全に削除するには、まず Firebase CLI を使用し、次に手動で関連アセットを削除してください。特に、注意が必要なリソースを削除しないように、他のバックエンドや Firebase プロジェクトの他の側面で使用されることがあります。

次のコマンドを実行して、App Hosting バックエンドを削除します。これにより、バックエンドのすべてのドメインが無効になり、関連付けられている Cloud Run サービス:
```
firebase apphosting:backends:delete BACKEND_ID --project PROJECT_ID --location us-central1
```
（オプション） Artifact Registry の Google Cloud コンソールのタブ「firebaseapphosting-images」にあるバックエンドのイメージを削除します。
Cloud Secret Manager で、次の操作を行います。「apphosting」を使用して Secret を削除する秘匿化する必要があります。 このようなシークレットが他のバックエンドや API で使用されないようにベストプラクティスをご覧ください。