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 buildng build(Angular 用)App Hosting はカスタムビルドでビルドを試みます 成功は確実に保証できません。

App Hosting リポジトリ統合の仕組み

GitHub リポジトリと App Hosting 間の重要な接続 処理されるため Developer Connect、 Google Cloud の接続プラットフォーム 外部 DevOps ツールにも使用できますApp Hosting バックエンドの作成中に、次の処理が行われます。 Developer Connect の UI ワークフローの手順に沿って、 Firebase GitHub アプリ。このプロセスの主なステップは次のとおりです。

  1. デベロッパーは、 Secret Manager 管理者 なります。これにより、システムは認証情報を「シークレット」として安全に保存できる Cloud Secret Manager
  2. Firebase GitHub アプリに GitHub へのアクセスを許可します。 リポジトリをご覧ください。
  3. Developer Connect は、 Secret Manager リポジトリに保存します。変更または削除しないでください。

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

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

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

App Hosting バックエンド サービス アカウント

ビルド時とランタイム時に、App Hosting バックエンドの認証が行われます。 他の Google サービスにサービス アカウントを関連付けることもできます。デフォルトのサービス アカウントは、 これらの目的は、Cloud コンソールで初めて App Hosting を有効にしたときに作成されます。 Firebase プロジェクト:

firebase-app-hosting-compute@PROJECT ID.iam.gserviceaccount.com

このサービス アカウントは、デフォルトですべてのバックエンドに適用され、最小限のリソースと 権限を付与して、アプリをビルド、実行、モニタリングできるようにします。また、 付与する権限を アプリケーションのデフォルト認証情報を使用して Admin SDK を認証する Cloud Firestore からのデータの読み込みなどのオペレーションの実行。詳しくは、 Firebase の App Hosting ロール

ビルド時にアプリが他の Google サービスとやり取りする必要がある場合、 デフォルトのサービス アカウントをカスタマイズする場合は、 ロールの追加が可能です。たとえば、アプリが Vertex AI の権限を必要とする場合は、 必要に応じて roles/aiplatform.user ロールを割り当てる必要があります。

主な用語と定義

  • バックエンド: App Hosting を実行するマネージド リソースのコレクション ウェブアプリをビルドして実行します。
  • ロールアウト: git commit にリンクされたライブアプリの特定のバージョン。
  • ライブブランチ: デプロイされる GitHub リポジトリのブランチ 公開 URL を入力します。多くの場合、機能ブランチまたは 統合されます。

既知の問題と制限事項

App Hosting プレビューには、次のような既知の制限事項があります。

  • バックエンドの削除が機能していません。
  • 画像の最適化はまだ利用できません。
  • 場合によっては、App Hosting バックエンドが アプリの URL に Intermittent connection error 件のメッセージがあります。修正すると、 今後のリリースで使用できます。
  • CDN キャッシュが 60 秒に制限されるように Cache-Control ヘッダーが変更されています。の 将来(App Hosting が Google Cloud 上のキャッシュをすばやく削除する) この上限は解除されます
  • Set-Cookie ヘッダーは、 App Hosting データプレーン。今後のリリースで修正が提供される予定です。
  • キャッシュに保存されていない静的ファイルは Cloud Run から配信されます。 後のリリースでは、App Hosting オリジンに保存され、提供されます。 パフォーマンスが向上します
  • App Hosting SKU が、次のバックエンドの使用状況ページに表示されない場合があります: Firebase コンソール。今後のリリースで利用できるようになる予定です。
  • Firebase コンソールで、「build was not found and は無効ですエラーが発生します。
  • 現在、同じプロジェクト内のすべてのバックエンドが GitHub 組織/アカウントを共有しています。 その組織/アカウントの異なるリポジトリに接続できます。 異なる GitHub アカウントに接続するバックエンドを作成するには、 別々のプロジェクトに配置してください
  • 現時点では、us-central1 リージョンのみがサポートされています。
  • Next.js ミドルウェア、書き換え、リダイレクトは CDN の背後にある Cloud Run。これらはキャッシュに保存されている レスポンスを表示するには 適切な制御ディレクティブを レンダリングするコンテンツのサイズに応じて 異なるサイズを指定します