App Hosting مجموعه پیچیده ای از وظایف پس زمینه را انجام می دهد تا استقرار برنامه شما را ساده کند. این صفحه بخش‌های کلیدی آن جریان کار را شرح می‌دهد و اطلاعاتی درباره نقاطی که ممکن است بخواهید جریان را بسته به نیاز برنامه‌تان سفارشی کنید، ارائه می‌کند.
یکپارچه سازی چارچوب
App Hosting پشتیبانی از ساخت و استقرار از پیش تنظیم شده را برای برنامه های وب توسعه یافته در این چارچوب ها ارائه می دهد:
- Next.js 13+
- Angular 17.2+
App Hosting با بررسی فایل package-lock.json یا سایر فایل‌های قفل موجود در مخزن، مشخص می‌کند که از کدام چارچوب استفاده می‌کنید. اگر سعی کنید یک برنامه Node.js را اجرا کنید که فایل قفلی ندارد، App Hosting در ساخت و اجرای برنامه شما شکست خواهد خورد. با اجرای npm install در دایرکتوری ریشه خود می توانید package-lock.json ایجاد کنید.
آداپتورهای چارچوب
آداپتورهای چارچوب App Hosting دو نقش کلیدی دارند:
- آنها کد منبع شما و هر فایل پیکربندی خاص چارچوب (مانند
next.config.js) را تجزیه می کنند و یک بسته خروجی ایجاد می کنند که می تواند توسط بقیه زیرساخت های میزبانی برنامه پردازش شود. - آنها دستور ساخت برنامه شما را برای تولید دارایی های ثابت و ایجاد یک نسخه بهینه از برنامه شما برای تولید اجرا می کنند.
آداپتورهای چارچوب برنامه Node.js شما را با npm run build می‌سازند، که بهترین کار را با اسکریپت‌های ساخت پیش‌فرض برای هر فریم‌ورک دارد: next build برای Next.js و ng build برای Angular. App Hosting سعی می کند با دستورات ساخت سفارشی بسازد، اما نمی تواند موفقیت را تضمین کند.
منبع آداپتورهای Next.js و Angular در firebase-framework-tools موجود است.
سایر چارچوب ها
علاوه بر Nextjs و Angular، میزبانی برنامه همچنین از هر چارچوب وب که قادر به ارائه خروجی ساخت مطابق با مشخصات بسته خروجی ما باشد، پشتیبانی می‌کند. نویسندگان چارچوب می توانند از ویژگی های بسته نرم افزاری خروجی استفاده کنند تا اطمینان حاصل کنند که چارچوب آنها توسط میزبانی برنامه پشتیبانی می شود.
اگر می‌خواهید از چارچوب‌های اضافی پشتیبانی شود، می‌توانید یک آداپتور ایجاد کنید یا با نگه‌دارنده‌های چارچوب تماس بگیرید تا خروجی‌های ساخت را به فرمت میزبانی برنامه تبدیل کنند. آداپتورهای Nextjs و Angular نمونه های مرجع خوبی برای هر کسی است که یک آداپتور ایجاد می کند.
چارچوب های پشتیبانی شده را می توان در Firebase منبع باز یافت.
چگونه یکپارچه سازی مخزن App Hosting کار می کند
ارتباط مهم بین مخزن GitHub شما و باطن App Hosting توسط Developer Connect ، پلت فرم اتصال Google Cloud برای ابزارهای DevOps خارجی انجام می شود. در طول ایجاد پشتیبان App Hosting ، گردش کار رابط کاربری Developer Connect شما را از طریق نصب برنامه Firebase GitHub راهنمایی می کند. مراحل کلیدی در این فرآیند عبارتند از:
- شما به Developer Connect نقش مدیر Secret Manager را می دهید. این به سیستم اجازه می‌دهد تا اعتبارنامه‌ها را به‌عنوان «اسرار» در Cloud Secret Manager به‌طور ایمن ذخیره کند.
- شما به برنامه Firebase GitHub اجازه دسترسی به مخزن GitHub خود را می دهید.
- Developer Connect یک توکن مجوز اختصاصی GitHub را در مخزن مخفی مدیر پروژه شما ذخیره می کند. این نشانه را اصلاح یا حذف نکنید.
علاوه بر این، App Hosting با API چک‌های GitHub ادغام می‌شود تا یک بررسی برای عرضه ارائه کند. این بررسی به شما امکان می دهد وضعیت عرضه خود را در GitHub مشاهده کنید و در صورت بروز هر گونه خطایی، فرآیند استقرار را اشکال زدایی کنید.
ادغام با Firebase و سایر خدمات Google
App Hosting هر دو محیط ساخت و زمان اجرا شما را تنظیم می‌کند تا بتوانید Firebase Admin SDK را با اعتبار پیش‌فرض Google Application راه‌اندازی کنید . به این ترتیب، باطن شما می‌تواند با سایر محصولات Firebase در حین ساخت و توسعه ارتباط برقرار کند.
مکان های App Hosting
استقرار App Hosting منابع پشتیبان شما را در یک مکان خاص ایجاد می کند. این انعطاف پذیری در مکان برنامه وب شما دارای مزایای کلیدی است:
- بهبود عملکرد و کاهش تاخیر با نزدیک کردن داده ها از نظر جغرافیایی به کاربران شما.
- یک شکست فاجعه بار برای App Hosting در یک منطقه بر برنامه های وب مستقر در مناطق دیگر تأثیر نمی گذارد.
هنگام ایجاد پشتیبان App Hosting از کنسول یا Firebase CLI، می توانید یکی از این مناطق را انتخاب کنید:
-
us-central1(آیووا) -
asia-east1(تایوان) -
europe-west4(هلند)
حساب خدمات باطن App Hosting
در حین ساخت و در زمان اجرا، باطن App Hosting شما با سایر سرویس‌های Google با یک حساب سرویس احراز هویت می‌شود. اولین باری که App Hosting در پروژه Firebase فعال می‌کنید، یک حساب سرویس پیش‌فرض برای این اهداف ایجاد می‌شود:
firebase-app-hosting-compute@ PROJECT ID .iam.gserviceaccount.com
این حساب سرویس به طور پیش‌فرض برای همه بک‌اندها اعمال می‌شود و دارای حداقل مجموعه مجوزهایی است که به شما امکان می‌دهد برنامه خود را بسازید، اجرا کنید و نظارت کنید. همچنین مجوز احراز هویت Admin SDK با اعتبار پیش فرض برنامه را برای انجام عملیاتی مانند بارگیری داده از Cloud Firestore دارد. نقش‌های App Hosting Firebase را ببینید.
اگر برنامه شما نیاز به تعامل با سرویس‌های اضافی Google در زمان ساخت یا از یک باطن در حال اجرا دارد، می‌توانید با افزودن نقش‌ها، حساب سرویس پیش‌فرض را سفارشی کنید. برای مثال، اگر برنامه شما به مجوزهای Vertex AI نیاز دارد، ممکن است لازم باشد roles/aiplatform.user یا برخی از نقش‌های مرتبط را اضافه کنید.
اصطلاحات و تعاریف کلیدی
- Backend : مجموعه ای از منابع مدیریت شده که App Hosting برای ساخت و اجرای برنامه وب شما ایجاد می کند.
- انتشار : نسخه خاصی از برنامه زنده شما که به یک git commit پیوند داده شده است.
- شعبه زنده : شاخه ای از مخزن GitHub شما که در URL زنده شما مستقر می شود. اغلب، این شاخه ای است که شاخه های ویژگی یا شاخه های توسعه در آن ادغام می شوند.
مسائل و محدودیت های شناخته شده
پیش نمایش App Hosting دارای برخی محدودیت های شناخته شده است:
- در برخی موارد، یک برنامه پشتیبان App Hosting ممکن است پیام‌های
Intermittent connection errorدر URL برنامه شما برگرداند. یک اصلاح در نسخه بعدی در دسترس خواهد بود. - هدرهای Cache-Control برای محدود کردن حافظه پنهان CDN به 60 ثانیه اصلاح شده اند. در آینده، زمانی که App Hosting قابلیت پاکسازی سریع حافظه پنهان در هنگام استقرار را داشته باشد، این محدودیت برداشته خواهد شد.
- بهینه‌سازی تصویر به‌طور پیش‌فرض در Cloud Run انجام می‌شود و تصاویر بهینه‌سازی‌شده باقی نمی‌مانند—توصیه می‌کنیم بهینه‌سازی تصویر را غیرفعال کنید یا به صورت دستی یک بارگذار را مشخص کنید تا راه‌حل بهتری در دسترس باشد.
- فایل‌های استاتیک ذخیره نشده خارج از Cloud Run ارائه می‌شوند. در نسخه بعدی، برای عملکرد بهتر، از مبدا App Hosting ذخیره و ارائه خواهند شد.
- SKUهای App Hosting ممکن است در صفحه استفاده از Backend در کنسول Firebase نمایش داده نشوند. آنها در نسخه بعدی در دسترس خواهند بود.
- کنسول Firebase ممکن است به طور متناوب خطای "build was not found and is invalid" را در ایجاد backend نشان دهد.
- در حال حاضر، همه پشتیبان‌ها در یک پروژه یک سازمان/حساب GitHub مشترک دارند. آنها را می توان به مخازن مختلف تحت آن سازمان/حساب متصل کرد. برای ایجاد backendهایی که به حساب های مختلف GitHub متصل هستند، آنها را در پروژه های جداگانه قرار دهید.
- میان‌افزار Next.js، بازنویسی‌ها و تغییر مسیرها در Cloud Run ، پشت CDN اجرا می‌شوند. از آنجایی که این موارد از پاسخ‌های حافظه پنهان محافظت نمی‌کنند، حتماً دستورالعمل‌های کنترلی مناسبی را برای محتوایی که ارائه می‌کنید تنظیم کنید.