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 で使用されないように ベスト プラクティスをご覧ください。