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

コードベースから複数の環境をデプロイする

同じコードベースから複数の環境をデプロイするのが一般的ですが、少し異なる構成になっています。たとえば、スペースにステージング環境に割り当てる 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
カスタムドメインを接続する
バックエンドを構成します。
ロールアウト、サイトの使用状況、ログをモニタリングします。