App Hosting は、複雑な一連のバックグラウンド タスクを処理して、アプリのデプロイを簡素化します。このページでは、そのタスクフローの主な部分について説明します。また、アプリのニーズに応じてフローをカスタマイズする必要があるポイントについても説明します。
Google Cloud と App Hosting のアーキテクチャ
App Hosting は、一連の Google Cloud プロダクトをオーケストレートして、ウェブアプリのデプロイ、サービング、モニタリングを行います。アプリは Cloud Build でビルドされ、Cloud Run で提供され、Cloud CDN にキャッシュに保存されます。Cloud Secret Manager などの統合サービスにより、API キーが安全に保管されます。
- コミットがライブブランチに push されると、Google Cloud Developer Connect は Firebase App Hosting にイベントを送信します。
- このイベントに応答して、Firebase App Hosting はリポジトリに接続されている各バックエンドの新しいロールアウトを開始します。
- Firebase App Hosting は、commit の新しい Cloud Build ビルドを作成します。このジョブでは、Google Cloud Buildpack がアプリケーションで使用されているフレームワークを特定し、アプリケーションに適したコンテナと構成（環境変数、シークレット、最小インスタンス数または最大インスタンス数、同時実行メモリ、CPU、VPC 構成など）を作成します。
- 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 サービスに送信されます。
フレームワークの統合
App Hosting は、次のフレームワークで開発されたウェブアプリの事前構成済みのビルドとデプロイのサポートを提供します。
- Next.js 13 以降
- Angular 17.2 以降
App Hosting は、リポジトリ内の package-lock.json ファイルまたは他のロックファイルを調べて、使用しているフレームワークを特定します。ロックファイルがない Node.js アプリをデプロイしようとすると、App Hosting がアプリのビルドと実行に失敗します。package-lock.json は、ルート ディレクトリで npm
install を実行して作成できます。
フレームワーク アダプター
App Hosting フレームワーク アダプタには、次の 2 つの重要な役割があります。
- ソースコードとフレームワーク固有の構成ファイル（
next.config.jsなど）を解析し、App Hosting インフラストラクチャの残りの部分で処理できる出力バンドルを生成します。 - アプリのビルドコマンドを実行して、静的アセットを生成し、製品版向けにアプリの最適化バージョンを作成します。
フレームワーク アダプタは npm run build を使用して Node.js アプリをビルドします。各フレームワークのデフォルトのビルド スクリプト（Next.js の場合は next build、Angular の場合は ng build）で最適に動作します。App Hosting はカスタム ビルド コマンドを使用してビルドを試みますが、成功を保証することはできません。
Next.js アダプターと Angular アダプターのソースは、firebase-framework-tools で入手できます。
その他のフレームワーク
App Hosting は、Nextjs と Angular に加えて、出力バンドルの仕様に一致するビルド出力を提供する任意のウェブ フレームワークもサポートしています。フレームワークの作成者は、出力バンドルの仕様を利用して、フレームワークが App Hosting でサポートされていることを確認できます。
サポート対象のフレームワークを追加する場合は、アダプタを作成するか、フレームワークのメンテナーに連絡して、ビルド出力を アプリ ホスティング形式に変換します。Nextjs アダプターと Angular アダプターは、アダプターを作成するすべてのユーザーにとって優れた参照例です。
サポートされているフレームワークについては、Firebase Open Source をご覧ください。
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 リポジトリにアクセスできるように承認します。
- Developer Connect は、プロジェクトの Secret Manager リポジトリに専用の GitHub 認証トークンを保存します。このトークンを変更または削除しないでください。
さらに、App Hosting は GitHub チェック API と統合され、ロールアウトのチェックを提供します。このチェックにより、GitHub でロールアウトのステータスを確認し、エラーが発生した場合にデプロイ プロセスをデバッグできます。
Firebase や他の Google サービスとの統合
App Hosting は、ビルド環境とランタイム環境の両方を設定するため、Google アプリケーションのデフォルト認証情報を使用して Firebase Admin SDK を初期化できます。これにより、バックエンドはビルドとデプロイの両方で他の Firebase プロダクトと通信できます。
App Hosting 個のロケーション
App Hosting デプロイメントは、特定のロケーションにバックエンド リソースを作成します。ウェブアプリの配置を柔軟に設定できることには、次のような主なメリットがあります。
- データをユーザーの地理的位置の近くに配置することで、パフォーマンスが向上し、レイテンシが短縮されます。
- 1 つのリージョンで App Hosting に致命的な障害が発生しても、他のリージョンにデプロイされたウェブアプリには影響しません。
コンソールまたは Firebase CLI から App Hosting バックエンドを作成する場合は、次のいずれかのリージョンを選択できます。
us-central1（アイオワ）asia-east1（台湾）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 または関連するロールを追加する必要があります。
主な用語と定義
- バックエンド: App Hosting がウェブアプリのビルドと実行のために作成するマネージド リソースのコレクション。
- ロールアウト: Git commit にリンクされた、公開中のアプリの特定のバージョン。
- 本番ブランチ: 本番 URL にデプロイされる GitHub リポジトリのブランチ。多くの場合、これは機能ブランチまたは開発ブランチが統合されるブランチです。
既知の問題と制限事項
App Hosting プレビューには、次のような既知の制限事項があります。
- 場合によっては、App Hosting バックエンドがアプリの URL で
Intermittent connection errorメッセージを返すことがあります。今後のリリースで修正される予定です。 - Cache-Control ヘッダーが変更され、CDN キャッシュが 60 秒に制限されるようになりました。将来、App Hosting がデプロイ時にキャッシュをすばやくパージできるようになると、この制限は解除されます。
- 画像の最適化はデフォルトで Cloud Run で行われ、最適化された画像は保持されません。より優れたソリューションが利用可能になるまで、画像の最適化を無効にするか、ローダを手動で指定することをおすすめします。
- パーセント エンコードされた文字を含む URL パスは、Cloud Run によってデコードされます。これにより、Next.js の並列ルーティングなど、エンコードされた URL パスのみを想定している機能で問題が発生する可能性があります。
- キャッシュに保存されていない静的ファイルは Cloud Run から提供されます。今後のリリースでは、パフォーマンスを向上させるため、App Hosting 送信元から保存および提供されます。
- App Hosting SKU は、Firebase コンソールのバックエンド使用状況ページに表示されない場合があります。今後のリリースで利用可能になる予定です。
- Firebase コンソールに、バックエンドの作成時に「ビルドが見つからず、無効です」というエラーが断続的に表示されることがあります。
- 同じプロジェクト内のすべてのバックエンドは、GitHub 組織/アカウントを共有します。これらのリポジトリは、その組織/アカウント内の異なるリポジトリに接続できます。異なる GitHub アカウントに接続するバックエンドを作成するには、それらを別々のプロジェクトに配置します。
- Next.js ミドルウェア、書き換え、リダイレクトは、CDN の背後にある Cloud Run で実行されます。これらはキャッシュに保存されたレスポンスを保護しないため、レンダリングするコンテンツに適切な制御ディレクティブを設定してください。