App Hosting は、一連の複雑なバックグラウンド タスクを処理して、アプリのデプロイを簡素化します。このページでは、そのタスクフローの主要な部分について説明し、アプリのニーズに応じてフローをカスタマイズできるポイントについて説明します。
主な用語と定義
App Hosting フローの詳細を理解するには、いくつかの用語を具体的に定義しておくと便利です。基本的な用語は次のとおりです。
- バックエンド: App Hosting がウェブアプリのビルドと実行のために作成するマネージド リソースのコレクション。
- ビルド: アプリの特定のリビジョン。通常は git commit にリンクされています。ビルドを作成するプロセスには、多数のサブプロセスがあります。特に、Cloud Build でのアプリのビルドと、Cloud Run でのリビジョンのデプロイ（ロールアウトされるまで、最初はトラフィックの 0% を処理）があります。
- ロールアウト: ビルドをアクティブにトラフィックを処理するように設定するプロセス。git commit によって自動的にトリガーされると、App Hosting はまずライブブランチを使用してビルドを作成し、次にライブ トラフィックをそのビルドに転送するロールアウトを作成します。
- ライブブランチ: 一般公開 URL にデプロイされる GitHub リポジトリのブランチ。多くの場合、機能ブランチまたは開発ブランチがマージされるブランチです。
Google Cloud と App Hosting のアーキテクチャ
App Hosting は、一連の Google Cloud プロダクトをオーケストレートして、ウェブアプリのデプロイ、提供、モニタリングを可能にします。アプリは Cloud Build でビルドされ、Cloud Run で提供され、Cloud CDN にキャッシュされます。Cloud Secret Manager などの統合サービスにより、API キーが安全に保管されます。
- ライブ ブランチに commit が push されると、Google Cloud Developer Connect は Firebase App Hosting にイベントを送信します。
- このイベントに応答して、Firebase App Hosting はリポジトリに接続されたバックエンドの新しいビルドを作成します。
- まず、Firebase App Hosting が commit の新しい Cloud Build ビルドを作成します。このジョブでは、Google Cloud Buildpack が、アプリケーションで使用されているフレームワークを特定し、アプリケーションに適したコンテナと構成（環境変数、シークレット、最小インスタンス数、最大インスタンス数、同時実行、メモリ、CPU、VPC 構成など）を作成します。詳細については、App Hosting ビルドプロセスをご覧ください。
- Cloud Build ジョブが完了すると、コンテナは Firebase App Hosting 専用の Artifact Registry リポジトリに保存されます。Firebase App Hosting は、イメージと構成を使用して、新しい Cloud Run リビジョンを Cloud Run サービスに追加します。
- Cloud Run リビジョンが完了し、正常であることが確認されると、Firebase App Hosting はトラフィック構成を変更して、すべての新しいリクエストを新しい Cloud Run リビジョンに転送します。この時点で、ロールアウトは完了です。
- Firebase App Hosting でホストされているウェブサイトにリクエストが送信されると、Cloud CDN が有効になっている Google Cloud ロードバランサによってリクエストが処理されます。キャッシュに保存されていないリクエストは Cloud Run サービスに送信されます。Cloud CDN でパフォーマンスを最適化する方法については、アプリのコンテンツをキャッシュに保存するをご覧ください。
フレームワークの統合
App Hosting には、次のフレームワークで開発されたウェブアプリのビルドとデプロイをサポートする事前構成済みの機能が用意されています。
- Next.js 13.5.x 以降
- Angular 18.2.x 以降
特定のバージョンとサポートレベルの詳細については、サポート スケジュールをご覧ください。
Next.js と Angular に加えて、App Hosting は、出力バンドル仕様に一致するビルド出力を提供できるウェブ フレームワークもサポートしています。App Hosting でサポートされているフレームワーク、フレームワーク アダプタ、関連ツールの詳細については、App Hosting のフレームワークとツールをご覧ください。
App Hosting リポジトリ統合の仕組み
GitHub リポジトリと App Hosting バックエンド間の重要な接続は、外部 DevOps ツール用の Google Cloud の接続プラットフォームである Developer Connect によって処理されます。この接続を設定すると（通常は App Hosting バックエンドの作成時）、Developer Connect の UI ワークフローで Firebase GitHub アプリのインストール手順が表示されます。このプロセスの主な手順は次のとおりです。
- Developer Connect に Secret Manager 管理者のロールを付与します。これにより、システムは認証情報を「シークレット」として Cloud Secret Manager に安全に保存できます。
- Firebase GitHub アプリに GitHub リポジトリへのアクセスを許可します。適切なリポジトリにアクセスするには、追加の GitHub 権限が必要になる場合があります。
- Developer Connect は、専用の GitHub 認証トークンをプロジェクトの Secret Manager リポジトリに保存します。このトークンを変更または削除しないでください。
さらに、App Hosting は GitHub Checks API と統合され、ロールアウトのチェックを提供します。このチェックにより、GitHub でロールアウトのステータスを確認し、エラーが発生した場合にデプロイ プロセスをデバッグできます。
Firebase や他の Google サービスとの統合
App Hosting は、ビルド環境とランタイム環境の両方を設定します。これにより、Google アプリケーションのデフォルト認証情報を使用して Firebase Admin SDK を初期化できます。これにより、バックエンドはビルド時と実行時の両方で他の Firebase プロダクトと通信できます。アプリの初期化やその他の Firebase SDK 関連のトピックについては、ウェブアプリに Firebase SDK を統合するをご覧ください。
App Hosting 個のロケーション
App Hosting は、プライマリ リージョンと呼ばれる特定のロケーションにバックエンド リソースを作成します。App Hosting はグローバル CDN と統合して高速配信を実現しますが、キャッシュに保存されていないコンテンツはアプリのプライマリ リージョンから提供されます。ウェブアプリの場所を柔軟に選択できることには、次のような主な利点があります。
- データをユーザーの地理的位置に近づけることで、パフォーマンスを向上させ、レイテンシを短縮します。
- 1 つのリージョンで App Hosting に致命的な障害が発生しても、他のリージョンにデプロイされたウェブアプリには影響しません。
Firebase コンソールまたは Firebase CLI から App Hosting バックエンドを作成するときに、次のいずれかのリージョンを選択できます。
us-central1（アイオワ）us-east4（N. バージニア）us-east5（コロンバス）asia-east1（台湾）asia-southeast1（シンガポール）europe-west4（オランダ）
App Hosting バックエンド サービス アカウント
ビルド時とランタイム時に、App Hosting バックエンドはサービス アカウントを使用して他の Google サービスで認証を行います。これらの目的で使用されるデフォルトのサービス アカウントは、Firebase プロジェクトで App Hosting を初めて有効にしたときに作成されます。
firebase-app-hosting-compute@PROJECT ID.iam.gserviceaccount.com
このサービス アカウントは、デフォルトですべてのバックエンドに適用され、アプリのビルド、実行、モニタリングを可能にする最小限の権限セットを備えています。また、Cloud Firestore からのデータの読み込みなどのオペレーションを実行するために、アプリケーションのデフォルト認証情報で Admin SDK を認証する権限も付与されています。Firebase App Hosting ロールをご覧ください。
アプリがビルド時または実行中のバックエンドから追加の Google サービスとやり取りする必要がある場合は、ロールを追加してデフォルトのサービス アカウントをカスタマイズできます。たとえば、アプリに Vertex AI の権限が必要な場合は、roles/aiplatform.user または関連するロールを追加する必要があります。