App Hosting とその仕組みを理解する

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 つの重要なロールがあります。

  1. アプリの構成動作を理解するために、ソースコードとフレームワーク固有の構成ファイル(next.config.js など)を解析します。
  2. アプリのビルドコマンドを実行して静的アセットを生成し、本番環境用に最適化されたアプリのバージョンを作成します。

フレームワーク アダプタは、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 アプリのインストールが順を追って示されます。このプロセスの主な手順は次のとおりです。

  1. Developer Connect に Secret Manager 管理者のロールを付与します。これにより、認証情報は Cloud Secret Manager に「シークレット」として安全に保存されます。
  2. Firebase GitHub アプリに GitHub リポジトリへのアクセスを許可します。
  3. Developer Connect は、専用の GitHub 認証トークンをプロジェクトの Secret Manager リポジトリに保存します。このトークンの変更や削除は行わないでください。

また、App Hosting は GitHub Checks API と統合されており、ロールアウトのチェックを行います。このチェックにより、GitHub でのロールアウトのステータスを確認し、エラーが発生した場合にデプロイ プロセスをデバッグできます。

Firebase や他の Google サービスとの統合

App Hosting はビルド環境とランタイム環境の両方を設定するので、Google アプリケーションのデフォルト認証情報を使用して Firebase Admin SDK を初期化できます。これにより、ビルドとデプロイの両方でバックエンドが他の Firebase プロダクトと通信できます。

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 のプレビュー版には、いくつかの既知の制限事項があります。

  • 現在、root\_directory が Firebase コンソールまたは CLI で構成されているかどうかにかかわらず、ネストされた package.json ファイルを含むプロジェクトはサポートされていません。今後のリリースで修正される予定です。
  • 画像の最適化はまだ利用できません。
  • 場合によっては、App Hosting のバックエンドがアプリの URL で Intermittent connection error メッセージを返すことがあります。今後のリリースで修正される予定です。
  • キャッシュ ヘッダーは、CDN キャッシュを 60 秒に制限するように変更されています。今後、App Hosting がデプロイ時にキャッシュをすばやく削除できるようになると、この上限は解除されます。
  • キャッシュされていない静的ファイルは Cloud Run から提供されます。今後のリリースでは、パフォーマンスを向上させるため、保存されて App Hosting の送信元から提供されることになります。
  • 今後のリリースでは、カスタム ドメインとしてのワイルドカード サブドメインが利用可能になる予定です。
  • Firebase コンソールの [バックエンドの使用状況] ページに App Hosting SKU が表示されない場合があります。今後のリリースで利用できるようになります。
  • バックエンドの作成時に Firebase コンソールで「build was not found and is invalid」というエラーが断続的に表示されることがあります。
  • 現在、同じプロジェクト内のすべてのバックエンドは GitHub の組織/アカウントを共有しています。それらのリポジトリは、その組織/アカウントの別のリポジトリに接続できます。異なる GitHub アカウントに接続するバックエンドを作成するには、それらのバックエンドを別々のプロジェクトに配置します。
  • 現時点では、us-central1 リージョンのみがサポートされています。