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

同じコードベースから複数の環境をデプロイし、それぞれにわずかに異なる構成を設定することは一般的です。たとえば、ステージング環境に割り当てる CPU と RAM を減らしたり、本番環境で少なくとも 1 つのインスタンスをアクティブにしてリクエストを処理できるようにしたりできます。使用する環境とリソースに応じて、異なる環境変数とシークレットを指定することもできます。

このガイドでは、本番環境とステージング環境をそれぞれ個別の Firebase プロジェクトにデプロイする方法について説明します。同じ原則に従って、他のさまざまな種類の環境にデプロイできます。環境の詳細については、環境の概要と Firebase プロジェクトの設定に関する一般的なベスト プラクティスをご覧ください。

前提条件

  • アプリケーション コードはすでに GitHub に保存されています。
  • 環境（my-production-firebase-project や my-staging-firebase-project など）ごとに個別のプロジェクトをすでに作成している。本番環境の Firebase プロジェクトに「本番環境」環境タイプのタグを付けるようにしてください。
  • 各プロジェクトで、ライブブランチがデプロイする GitHub ブランチ（main など）に設定された App Hosting バックエンドを作成しました。詳細については、App Hosting のスタートガイドをご覧ください。

ステップ 0: apphosting.yaml でデフォルト構成を作成する

App Hosting は、アプリのランタイム設定（CPU、同時実行、メモリ上限など）と環境変数を管理する apphosting.yaml という構成ファイルをサポートしています。また、Cloud Secret Manager で管理されるシークレットへの参照もサポートしているため、ソース管理に安全にチェックインできます。詳細については、バックエンドを構成するをご覧ください。

まず、アプリのルート ディレクトリに apphosting.yaml ファイルを作成します。これは、環境固有の構成ファイルが見つからない場合に使用されるフォールバック構成ファイルです。apphosting.yaml に保存される値は、すべての環境で安全に使用できるデフォルト値である必要があります。

以降のセクションでは、特定の環境で apphosting.yaml のデフォルト値をオーバーライドする方法について説明します。このサンプル フローは、ステージング環境を作成します。

ステップ 1: 環境名を設定する

各 App Hosting バックエンドには、環境名の設定があります。このフィールドは、バックエンドを環境固有の構成ファイルにマッピングするために使用され、いつでも変更できます。バックエンドごとに設定できる環境名は 1 つだけです。

バックエンドの環境名を設定するには:

  1. Firebase コンソールで、ステージング プロジェクト（この例では my-staging-firebase-project）を選択します。
  2. 左側のナビゲーションで App Hosting を選択します。
  3. 選択したバックエンドで [ダッシュボードを表示] をクリックします。
  4. [設定] タブで、[環境] を選択します。
  5. [環境名] に、環境の名前を入力します。環境には任意の名前を付けることができます。この例では staging です。
  6. [保存] をクリックします。

バックエンドの App Hosting ロールアウトが（git push またはコンソール経由の手動で）トリガーされると、App Hosting は apphosting.yaml にフォールバックする前に apphosting.ENVIRONMENT_NAME.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.firebasestorage.app
    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.firebasestorage.app
    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 を使用できます。

次のステップ