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

同じコードベースからデプロイされる環境が複数あり、それぞれ構成が若干異なることはよくあります。たとえば、ステージング環境に割り当てる CPU と RAM を少なくする場合や、本番環境で少なくとも 1 つのインスタンスをアクティブにし、リクエストを処理できる状態に保ちたい場合があります。使用する環境とリソースに応じて、異なる環境変数とシークレットを指定することもできます。

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

前提条件

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

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

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

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

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

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

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

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

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

バックエンドで 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 を使用できます。

次のステップ