App Hosting は、複雑な一連のバックグラウンド タスクを処理して、アプリのデプロイを簡素化します。このページでは、そのタスクフローの主な部分について説明します。また、アプリのニーズに応じてフローをカスタマイズする必要があるポイントについても説明します。
フレームワークの統合
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 で行われ、最適化された画像は保持されません。より優れたソリューションが利用可能になるまで、画像の最適化を無効にするか、ローダを手動で指定することをおすすめします。
- キャッシュに保存されていない静的ファイルは Cloud Run から提供されます。今後のリリースでは、パフォーマンスを向上させるため、App Hosting 送信元から保存および提供されます。
- App Hosting SKU は、Firebase コンソールのバックエンド使用状況ページに表示されない場合があります。今後のリリースで利用可能になる予定です。
- Firebase コンソールには、バックエンドの作成時に「ビルドが見つからず、無効です」というエラーが断続的に表示されることがあります。
- 現在、同じプロジェクト内のすべてのバックエンドは GitHub の組織/アカウントを共有しています。これらのリポジトリは、その組織/アカウント内の異なるリポジトリに接続できます。異なる GitHub アカウントに接続されたバックエンドを作成するには、それらを別々のプロジェクトに配置します。
- Next.js ミドルウェア、書き換え、リダイレクトは、CDN の背後にある Cloud Run で実行されます。これらはキャッシュに保存されたレスポンスを保護しないため、レンダリングするコンテンツに適切な制御ディレクティブを設定してください。