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など）を解析し、アプリに構成されている動作を把握します。 - アプリのビルドコマンドを実行して、静的アセットを生成し、製品版向けにアプリの最適化バージョンを作成します。
フレームワーク アダプタは npm run build を使用して Node.js アプリをビルドします。各フレームワークのデフォルトのビルド スクリプト（Next.js の場合は next build、Angular の場合は ng build）で最適に動作します。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 リポジトリへのアクセスを許可します。
- 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 で実行されます。これらはキャッシュに保存されたレスポンスを保護しないため、レンダリングするコンテンツに適切な制御ディレクティブを設定してください。