تنظيم صفحاتك في مجموعات
يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.
تعالج App Hosting سلسلة معقّدة من مهام الخلفية لتبسيط عملية نشر تطبيقك. توضّح هذه الصفحة الأجزاء الرئيسية من مسار المهام هذا، وتقدّم معلومات حول النقاط التي قد تحتاج إلى تخصيص المسار فيها وفقًا لاحتياجات تطبيقك.
المصطلحات والتعريفات الرئيسية
لفهم تفاصيل مسار App Hosting، من المفيد تحديد بعض المصطلحات بشكل دقيق جدًا. في ما يلي المصطلحات الأساسية:
الخلفية: هي مجموعة من الموارد المُدارة التي ينشئها App Hosting
لإنشاء تطبيق الويب وتشغيله.
الإصدار: هو نسخة محدّدة من تطبيقك، وعادةً ما يكون مرتبطًا بعملية git. تتضمّن عملية إنشاء إصدار العديد من العمليات الفرعية، وأبرزها إنشاء تطبيقك في Cloud Build ونشر مراجعة (يتم عرضها في البداية لنسبة% 0 من الزيارات إلى أن يتم طرحها) في Cloud Run.
الطرح: عملية إعداد إصدار لعرض المحتوى بشكل نشط.
عندما يتم تشغيلها تلقائيًا من خلال عملية git commit، تنفّذ App Hosting الخطوات التالية: أولاً، تنشئ إصدارًا باستخدام فرعك النشط، ثم تنشئ طرحًا لتوجيه الزيارات النشطة إليه.
الفرع النشط: هو فرع مستودع GitHub الذي يتم نشره على عنوان URL النشط. وغالبًا ما يكون هذا الفرع هو الذي يتم دمج فروع الميزات أو فروع التطوير فيه.
بنية Google Cloud وApp Hosting
تنسّق App Hosting مجموعة من منتجات Google Cloud لتتمكّن من نشر تطبيق الويب وعرضه ومراقبته. يتم إنشاء التطبيقات باستخدام Cloud Build، ويتم عرضها على Cloud Run، ويتم تخزينها مؤقتًا في Cloud CDN. تساعد الخدمات المدمجة، مثل Cloud Secret Manager، في الحفاظ على أمان مفاتيح واجهة برمجة التطبيقات.
عندما يتم إرسال عملية دمج إلى فرع البث المباشر، يرسل Google Cloud Developer Connect حدثًا إلى Firebase App Hosting.
عند الاستجابة لهذا الحدث، ينشئ Firebase App Hosting إصدارًا جديدًا من الخلفية المرتبطة بالمستودع.
أولاً، تنشئ Firebase App Hosting إصدار Cloud Build جديدًا لعملية الدمج. في هذه المهمة، تحدّد حِزم الإنشاء في Google Cloud إطار العمل المستخدَم في تطبيقك لإنشاء حاوية وإعدادات (بما في ذلك متغيرات البيئة والأسرار والحد الأدنى أو الأقصى من الآلات الافتراضية والذاكرة المتزامنة ووحدة المعالجة المركزية وإعدادات شبكة VPC) تناسب تطبيقك.
لمزيد من المعلومات، يُرجى الاطّلاع على عملية إنشاء App Hosting.
عند اكتمال مهمة Cloud Build، يتم تخزين الحاوية في مستودع Artifact Registry مخصّص Firebase App Hosting.
يضيف Firebase App Hosting بعد ذلك Cloud Run مراجعة جديدة إلى
Cloud Run خدمة باستخدام صورتك وإعداداتك.
بعد اكتمال مراجعة Cloud Run والتحقّق من سلامتها، تعدّل Firebase App Hosting إعدادات عدد الزيارات لتوجيه جميع الطلبات الجديدة إلى مراجعة Cloud Run الجديدة. في هذه المرحلة، يكون الطرح قد اكتمل.
عند إرسال طلب إلى موقع إلكتروني مستضاف على Firebase App Hosting، تتم معالجة الطلب من خلال موازنة حمل Google Cloud مع تفعيل Cloud CDN.
يتم إرسال الطلبات غير المخزّنة مؤقتًا إلى خدمة Cloud Run. راجِع مقالة
تخزين محتوى التطبيق مؤقتًا للحصول على إرشادات حول كيفية
تحسين الأداء باستخدام Cloud CDN.
دمج إطار العمل
توفر App Hosting إمكانية إنشاء التطبيقات ونشرها بشكل مسبق لتطبيقات الويب
المطوّرة في الأُطر التالية:
الإصدار 13.5.x من Next.js والإصدارات الأحدث
Angular 18.2.x والإصدارات الأحدث
يمكنك الاطّلاع على جداول الدعم لمعرفة تفاصيل حول إصدارات ومستويات دعم معيّنة.
بالإضافة إلى Next.js وAngular، تتوافق App Hosting أيضًا مع أي إطار عمل على الويب يمكنه توفير ناتج إصدار يتطابق مع مواصفات حزمة الناتج.
يمكنك الاطّلاع على الأُطر والأدوات الخاصة بـ
App Hosting لمزيد من المعلومات
حول الأُطر ومحوّلات الأُطر والأدوات ذات الصلة المتوافقة مع
App Hosting.
يخزّن Developer Connect رمزًا مميزًا مخصّصًا لتفويض GitHub في مستودع "إدارة الأسرار" الخاص بمشروعك، لذا لا تعدّل هذا الرمز المميز أو تحذفه.
بالإضافة إلى ذلك، تتكامل App Hosting مع GitHub Checks API لتوفير عملية تحقّق من عمليات الطرح. يتيح لك هذا الإجراء الاطّلاع على حالة الطرح في GitHub وتصحيح أخطاء عملية النشر في حال حدوث أي أخطاء.
التكامل مع Firebase وخدمات Google الأخرى
تُعدّ App Hosting بيئتَي الإنشاء ووقت التشغيل حتى تتمكّن من
تهيئة حزمة تطوير البرامج (SDK) الخاصة بـ Firebase Admin باستخدام
بيانات الاعتماد التلقائية للتطبيق على Google. بهذه الطريقة، يمكن لخادمك الخلفي التواصل مع منتجات Firebase الأخرى في وقت الإنشاء ووقت التشغيل. راجِع مقالة دمج حِزم تطوير البرامج (SDK) من Firebase في تطبيق الويب للحصول على مزيد من المعلومات حول تهيئة تطبيقك ومواضيع أخرى ذات صلة بحِزم تطوير البرامج (SDK) من Firebase.
App Hosting موقع جغرافي
App Hosting تنشئ موارد الخلفية في موقع جغرافي محدّد يُعرف باسم منطقتك الأساسية. على الرغم من أنّ App Hosting تتكامل مع شبكة توصيل محتوى عالمية لتوفير سرعة في التسليم، يتم عرض المحتوى غير المخزّن مؤقتًا من المنطقة الأساسية لتطبيقك. توفّر هذه المرونة في تحديد موقع تطبيق الويب مزايا رئيسية، وهي:
تحسين الأداء وتقليل وقت الاستجابة من خلال تقريب البيانات جغرافيًا من المستخدمين
لن يؤثّر حدوث عطل كارثي في App Hosting في منطقة واحدة في تطبيقات الويب التي تم نشرها في مناطق أخرى.
يمكنك اختيار أيّ من هذه المناطق عند إنشاء
App Hosting خلفية تطبيق من وحدة التحكّم أو واجهة سطر الأوامر Firebase:
us-central1 (أيوا)
asia-east1 (تايوان)
europe-west4 (هولندا)
حساب خدمة الخلفية App Hosting
أثناء عملية الإنشاء وفي وقت التشغيل، تتم مصادقة الخلفية App Hosting مع خدمات Google الأخرى باستخدام حساب خدمة. يتم إنشاء حساب خدمة تلقائي لهذه الأغراض عند تفعيل App Hosting لأول مرة في مشروع Firebase:
إذا كان تطبيقك بحاجة إلى التفاعل مع خدمات إضافية من Google، سواء في وقت الإنشاء أو من الخلفية أثناء التشغيل، يمكنك تخصيص حساب الخدمة التلقائي من خلال إضافة أدوار. على سبيل المثال، إذا كان تطبيقك يتطلّب أذونات للوصول إلى Vertex AI، قد تحتاج إلى إضافة
roles/aiplatform.user
أو بعض الأدوار ذات الصلة.
تاريخ التعديل الأخير: 2025-08-31 (حسب التوقيت العالمي المتفَّق عليه)
[[["يسهُل فهم المحتوى.","easyToUnderstand","thumb-up"],["ساعَدني المحتوى في حلّ مشكلتي.","solvedMyProblem","thumb-up"],["غير ذلك","otherUp","thumb-up"]],[["لا يحتوي على المعلومات التي أحتاج إليها.","missingTheInformationINeed","thumb-down"],["الخطوات معقدة للغاية / كثيرة جدًا.","tooComplicatedTooManySteps","thumb-down"],["المحتوى قديم.","outOfDate","thumb-down"],["ثمة مشكلة في الترجمة.","translationIssue","thumb-down"],["مشكلة في العيّنات / التعليمات البرمجية","samplesCodeIssue","thumb-down"],["غير ذلك","otherDown","thumb-down"]],["تاريخ التعديل الأخير: 2025-08-31 (حسب التوقيت العالمي المتفَّق عليه)"],[],[],null,["\u003cbr /\u003e\n\nApp Hosting handles a complex series of background tasks to simplify the\ndeployment of your app. This page describes key parts of that task flow,\nproviding information about points where you might want to customize the flow\ndepending on your app's needs.\n\nKey terms and definitions\n\nTo understand the details of the App Hosting flow, it's helpful to define\nsome of the terminology very specifically. Here are the fundamental key terms:\n\n- **Backend** : The collection of managed resources that App Hosting creates to build and run your web app.\n- **Build:** A specific revision of your app, typically linked to a git commit. The [process of creating a build](/docs/app-hosting/build) has numerous subprocesses, notably the *building* of your app in Cloud Build, and the *deployment* of a revision (initially serving 0% of traffic until it is rolled out) in Cloud Run.\n- **Rollout** : The process of setting a build to actively serving traffic. When automatically triggered by a git commit, App Hosting first creates a build using your live branch, then creates a rollout to direct live traffic to it.\n- **Live branch**: The branch of your GitHub repository that gets deployed to your live URL. Often, it's the branch into which feature branches or development branches are merged.\n\nGoogle Cloud and App Hosting architecture\n\nApp Hosting orchestrates a set of Google Cloud products so you can\ndeploy, serve, and monitor your web app. Apps are built with Cloud Build,\nserved on Cloud Run, and cached in Cloud CDN. Integrated services like\nCloud Secret Manager keep your API keys safe.\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n1. When a commit is pushed to your live branch, Google Cloud Developer Connect sends an event to Firebase App Hosting.\n2. Responding to this event, Firebase App Hosting creates a new build for the backend connected to the repository.\n 1. First, Firebase App Hosting creates a new Cloud Build build for your commit. In this job, [Google Cloud buildpacks](https://cloud.google.com/docs/buildpacks/overview) determine which framework is being used in your application to create a container and configuration (including environment variables, secrets, minimum or maximum instances, concurrency memory, CPU, and VPC configuration) that suits your application. See [the App Hosting build process](/docs/app-hosting/build) For more information.\n 2. When the Cloud Build job is complete, your container is stored in an Artifact Registry repository dedicated to Firebase App Hosting. Firebase App Hosting then adds a new Cloud Run Revision to a Cloud Run service using your image and configuration.\n3. Once your Cloud Run Revision is complete and verified healthy, Firebase App Hosting modifies its traffic configuration to point all new requests to your new Cloud Run Revision. At this point, the rollout is complete.\n4. When a request is sent to a website hosted on Firebase App Hosting, the request is served by Google Cloud Load Balancer with Cloud CDN enabled. Uncached requests are sent to your Cloud Run service. See [Cache app content](/docs/app-hosting/optimize-cache) for guidance on how to optimize performance with Cloud CDN.\n\nFramework integration\n\nApp Hosting provides preconfigured build and deploy support for web apps\ndeveloped in these frameworks:\n\n- Next.js 13.5.x and higher\n- Angular 18.2.x and higher\n\nSee the\n[support schedules](/docs/app-hosting/frameworks-tooling#next.js-support) for\ndetails on specific versions and levels of support.\n\nIn addition to Next.js and Angular, App Hosting also supports any web\nframework that is able to provide a build output that matches our [output bundle\nspecification](https://github.com/FirebaseExtended/firebase-framework-tools#app-hosting-output-bundle).\nSee [Frameworks and tooling for\nApp Hosting](/docs/app-hosting/frameworks-tooling) for more information\nabout frameworks, framework adapters, and related tooling supported by\nApp Hosting.\n\nHow App Hosting repository integration works\n\nThe important connection between your GitHub repository and the App Hosting\nbackend is handled by\n[Developer Connect](https://cloud.google.com/developer-connect/docs/overview),\nGoogle Cloud's connectivity platform\nfor external DevOps tools. During the creation of an App Hosting backend,\nDeveloper Connect's UI workflow guides you through the installation of the\nFirebase GitHub app. The key steps in this process are:\n\n1. You grant Developer Connect the [Secret Manager Admin](https://cloud.google.com/secret-manager/docs/access-control#secretmanager.admin) role. This allows the system to store credentials securely as \"secrets\" in [Cloud Secret Manager](https://cloud.google.com/secret-manager/docs).\n2. You authorize the Firebase GitHub app to [access your GitHub repository](https://docs.github.com/en/apps/using-github-apps/installing-a-github-app-from-a-third-party). You may need additional [GitHub permissions](https://docs.github.com/en/apps/using-github-apps/installing-a-github-app-from-github-marketplace-for-your-organizations#requirements-to-install-a-github-app-on-an-organization) in order to access the right repository.\n3. Developer Connect stores a dedicated GitHub authorization token in your project's secret manager repository; don't modify or delete this token.\n\nAdditionally, App Hosting integrates with the GitHub checks API to provide a\ncheck for rollouts. This check lets you view the status of your rollout in\nGitHub and debug the deployment process in case of any errors.\n\nIntegration with Firebase and other Google services\n\nApp Hosting sets up both your build and runtime environments so you can\n[initialize the Firebase Admin SDK](/docs/admin/setup#initialize-sdk) with\nGoogle Application Default Credentials. That way, your backend can communicate\nwith other Firebase products at both build and run time. See [Integrate\nFirebase SDKs in your web app](/docs/app-hosting/firebase-sdks) for more\ninformation on initializing your app and other Firebase SDK-related topics.\n\nApp Hosting locations\n\nApp Hosting creates your backend resources in a specific location, called\nyour primary region. While App Hosting integrates with a global CDN for fast\ndelivery, uncached content is served from your app's primary region. This\nflexibility in the location of your web app has key advantages:\n\n- Improved performance and reduced latency by bringing the data geographically closer to your users.\n- A catastrophic failure for App Hosting in one region wouldn't affect web apps deployed in other regions.\n\nYou can choose any of these regions when you create an\nApp Hosting backend from the console or the Firebase CLI:\n\n- `us-central1` (Iowa)\n- `asia-east1` (Taiwan)\n- `europe-west4` (Netherlands)\n\nThe App Hosting backend service account\n\nDuring build and at runtime, your App Hosting backend authenticates with\nother Google services with a service account. A default service account for\nthese purposes is created the first time you enable App Hosting in a\nFirebase project:\n\n`firebase-app-hosting-compute@`\u003cvar translate=\"no\"\u003ePROJECT ID\u003c/var\u003e`.iam.gserviceaccount.com`\n\nThis service account applies to all backends by default and has a minimal set of\npermissions to allow you to build, run, and monitor your app. It also has\npermission to\n[authenticate the Admin SDK with Application Default Credentials](/docs/admin/setup#initialize-sdk), for\nperforming operations like loading data from Cloud Firestore. See\n[Firebase App Hosting roles](/docs/projects/iam/roles-predefined-product#app-hosting).\n\nIf your app needs to interact with additional Google services either at build\ntime or from a running backend, you can customize the default service account by\nadding roles. For example, if your app requires permissions for Vertex AI, you\nmight need to add\n[`roles/aiplatform.user`](https://cloud.google.com/iam/docs/understanding-roles#aiplatform.user)\nor some related role."]]
