同じコードベースから複数の環境をデプロイするのが一般的ですが、 少し異なる構成になっています。たとえば、スペースに ステージング環境に割り当てる CPU と RAM を少なくするか、 本番環境で少なくとも 1 つのインスタンスがアクティブで、利用可能な状態にある できます。環境変数と環境変数を指定することもできます。 使用する環境とリソースによって異なります。
このガイドでは、本番環境とステージング環境をそれぞれデプロイして、 作成する必要があります。同じ原則に従って、VM にデプロイして 実行することもできます。環境について詳しくは、このモジュールの 詳しくは、 環境と全般 Firebase の設定に関するベスト プラクティス プロジェクト。
前提条件
- アプリケーション コードはすでに GitHub に保存されています。
- 各プロジェクトに個別のプロジェクトがすでに作成されている
環境(例:
my-production-firebase-project
、my-staging-firebase-project
。本番環境の Firebase に必ずタグを付けてください。 「production」環境 type。 - 各プロジェクトで、App Hosting バックエンドを作成し、
デプロイする GitHub ブランチ(
main
など)に設定します。詳しくは、 App Hosting を使ってみる 情報です。
ステップ 0: apphosting.yaml でデフォルト構成を作成する
App Hosting は、apphosting.yaml
という構成ファイルをサポートしています。
ランタイム設定(CPU、同時実行、メモリ上限など)と環境
変数を設定します。また、Cloud KMS で管理されるシークレットへの参照も
安全にソース管理にチェックインできます。詳細
詳しくは、
バックエンドです。
まず、アプリのルート ディレクトリに apphosting.yaml
ファイルを作成します。
これは代替構成ファイルです。
見つからない場合です。格納される値には、
apphosting.yaml
は、すべての環境で安全に使用できるデフォルト値にする必要があります。
次のセクションでは、apphosting.yaml
のデフォルト値をオーバーライドする方法について説明します。
専用の環境を提供します。この例のフローでは、ステージング環境を作成します。
ステップ 1: 環境名を設定する
各 App Hosting バックエンドには [Environment name] 設定があります。このフィールドは マッピングを使用してバックエンドを環境固有の構成ファイルにマッピングし、 いつでも変更できます。バックエンドごとに設定できる環境名は 1 つのみです。
バックエンドの環境名を設定するには
- Firebase コンソールで、ステージング プロジェクト(この例では、 my-staging-firebase-project です。
- 左側のナビゲーションで [App Hosting] を選択します。
- 選択したバックエンドで [ダッシュボードを表示] をクリックします。
- [Settings] タブで、[Deployment] を選択します。
- [環境名] に、環境の名前を入力します。名前は 自由に設定できます。この例では staging です。
- [保存] をクリックします。
バックエンドで App Hosting ロールアウトがトリガーされたとき(git
push するか、コンソールから手動で操作する場合、App Hosting は
apphosting.ENVIRONMENT_NAME.yaml
ファイルの前
apphosting.yaml
にフォールバックします。
ステップ 2: 環境固有の apphosting.yaml
ファイルを作成する
環境固有の構成の場合は、次の名前のファイルを作成します。
apphosting.ENVIRONMENT_NAME.yaml
:
環境固有のオーバーライドを指定します。このファイルの形式は、
デフォルトの apphosting.yaml であり、このファイルは次のフォルダに配置する必要があります。
apphosting.yaml
と一緒にアプリのルート ディレクトリに配置します。
ビルド時に、App Hosting は優先順位に基づいてこれら 2 つのファイルをマージします。
値をベース apphosting.yaml
の環境固有の YAML ファイルに記述します。
表示されます。
この例では、apphosting.staging.yaml
という名前のファイルを
アプリケーションのルート ディレクトリに配置します。
runConfig:
cpu: 1
memoryMiB: 512
concurrency: 5
env:
- variable: API_URL
value: api.staging.service.com
availability:
- BUILD
- variable: DATABASE_URL
secret: secretStagingDatabaseURL
次のような apphosting.yaml
がすでにあるとします。
runConfig:
cpu: 3
memoryMiB: 1024
maxInstances: 4
minInstances: 0
concurrency: 100
env:
- variable: API_URL
value: api.service.com
availability:
- BUILD
- RUNTIME
- variable: STORAGE_BUCKET
value: mybucket.appspot.com
availability:
- RUNTIME
- variable: API_KEY
secret: secretIDforAPI
Cloud Build のログで調べることができる最終的なマージされた出力は、 次のようになります。
runConfig:
cpu: 1
memoryMiB: 512
maxInstances: 4
minInstances: 0
concurrency: 5
env:
- variable: API_URL
value: api.staging.service.com
availability:
- BUILD
- variable: STORAGE_BUCKET
value: mybucket.appspot.com
availability:
- RUNTIME
- variable: API_KEY
secret: secretIDforAPI
- variable: DATABASE_URL
secret: secretStagingDatabaseURL
なお、CPU などの特定の runConfig
値も上書きされています。
使用できます。
ステップ 3: コードベースをデプロイする
環境固有の apphosting.ENVIRONMENT_NAME.yaml
ファイルの編集が終了したら、ファイルを GitHub に push します。
$ git add apphosting.<ENVIRONMENT_NAME>.yaml
$ git commit -m "Added environment specific yaml file"
$ git push
この環境名でタグ付けされたバックエンドは、特定のオーバーライドを使用します
対応する YAML ファイルで指定され、変数に
apphosting.yaml
: 値が見つからない場合。リソースが関連付けられていないバックエンドの場合、
使用したい場合は、引き続き apphosting.yaml を使用できます。
次のステップ
- さらに詳しく: ホストされるアプリを Firebase Authentication と Google AI の機能: Next.js | Angular
- カスタム ドメインを接続する
- バックエンドを構成します。
- ロールアウト、サイトの使用状況、ログをモニタリングします。