App Hosting برای سهولت استفاده و نگهداری کم طراحی شده است، با تنظیمات پیش فرض برای اکثر موارد استفاده بهینه شده است. در همان زمان، App Hosting ابزارهایی را برای مدیریت و پیکربندی backendها برای نیازهای خاص خود در اختیار شما قرار می دهد. این راهنما آن ابزارها و فرآیندها را توصیف می کند.
یک باطن را پیکربندی کنید
برای پیکربندی پیشرفته مانند متغیرهای محیطی یا تنظیمات زمان اجرا مانند محدودیت‌های همزمان، CPU و حافظه، باید فایل apphosting.yaml را در فهرست اصلی برنامه خود ایجاد و ویرایش کنید. این فایل همچنین از ارجاع به اسرار مدیریت شده با Cloud Secret Manager پشتیبانی می کند و بررسی منبع را ایمن می کند.
برای ایجاد apphosting.yaml دستور زیر را اجرا کنید:
firebase init apphosting
این یک فایل شروع اولیه apphosting.yaml با پیکربندی نمونه (نظر داده شده) ایجاد می کند. پس از ویرایش، یک فایل apphosting.yaml معمولی ممکن است مانند شکل زیر باشد، با تنظیماتی برای سرویس Cloud Run backend، برخی از متغیرهای محیطی، و برخی ارجاعات به اسرار مدیریت شده توسط Cloud Secret Manager:
# Settings for Cloud Run
runConfig:
minInstances: 2
maxInstances: 100
concurrency: 100
cpu: 2
memoryMiB: 1024
# Environment variables and secrets
env:
- variable: STORAGE_BUCKET
value: mybucket.appspot.com
availability:
- BUILD
- RUNTIME
- variable: API_KEY
secret: myApiKeySecret
# Same as API_KEY above but with a pinned version.
- variable: PINNED_API_KEY
secret: myApiKeySecret@5
# Same as API_KEY above but with the long form secret reference as defined by Cloud Secret Manager.
- variable: VERBOSE_API_KEY
secret: projects/test-project/secrets/secretID
# Same as API_KEY above but with the long form secret reference with pinned version.
- variable: PINNED_VERBOSE_API_KEY
secret: projects/test-project/secrets/secretID/versions/5
بقیه این راهنما اطلاعات و زمینه بیشتری را برای این تنظیمات مثال ارائه می دهد.
تنظیمات سرویس Cloud Run پیکربندی کنید
با تنظیمات apphosting.yaml ، می توانید نحوه ارائه سرویس Cloud Run خود را پیکربندی کنید. تنظیمات موجود برای سرویس Cloud Run در شی runConfig ارائه شده است:
-
cpu- تعداد CPU های استفاده شده برای هر نمونه سرویس (پیش فرض 0). -
memoryMiB- مقدار حافظه اختصاص داده شده برای هر نمونه خدمت در MiB (پیش فرض 512) -
maxInstances- حداکثر تعداد کانتینرهایی که می‌توان در هر زمان اجرا کرد (پیش‌فرض 100 و مدیریت شده توسط سهمیه) -
minInstances- تعداد ظروف برای همیشه زنده نگه داشتن (پیش فرض 0). -
concurrency- حداکثر تعداد درخواست هایی که هر نمونه ارائه دهنده می تواند دریافت کند (پیش فرض 80).
به رابطه مهم بین cpu و memoryMiB توجه کنید. حافظه را می توان روی هر عدد صحیحی بین 128 تا 32768 تنظیم کرد، اما افزایش محدودیت حافظه ممکن است نیاز به افزایش محدودیت های CPU داشته باشد:
- بیش از 4 گیگابایت به حداقل 2 CPU نیاز دارد
- بیش از 8 گیگابایت به حداقل 4 CPU نیاز دارد
- بیش از 16 گیگابایت به حداقل 6 CPU نیاز دارد
- بیش از 24 گیگابایت حداقل به 8 CPU نیاز دارد
به طور مشابه، مقدار cpu بر تنظیمات همزمانی تأثیر می گذارد. اگر مقدار کمتر از 1 CPU را تنظیم کنید، باید همزمانی را روی 1 تنظیم کنید و CPU فقط در طول پردازش درخواست تخصیص داده می شود.
محیط ساخت را پیکربندی کنید
گاهی اوقات برای فرآیند ساخت خود به پیکربندی اضافی نیاز دارید، مانند کلیدهای API شخص ثالث یا تنظیمات قابل تنظیم. App Hosting پیکربندی محیطی را در apphosting.yaml برای ذخیره و بازیابی این نوع داده ها برای پروژه شما ارائه می دهد.
env:
- variable: STORAGE_BUCKET
value: mybucket.appspot.com
برای برنامه‌های Next.js، فایل‌های dotenv حاوی متغیرهای محیطی نیز با App Hosting کار می‌کنند. توصیه می کنیم از apphosting.yaml برای کنترل متغیر محیطی دانه بندی شده با هر فریم ورکی استفاده کنید.
در apphosting.yaml می توانید با استفاده از ویژگی availability مشخص کنید که کدام فرآیندها به متغیر محیطی شما دسترسی دارند. شما می توانید یک متغیر محیطی را محدود کنید تا فقط برای محیط ساخت و یا فقط برای محیط زمان اجرا در دسترس باشد. به طور پیش فرض، برای هر دو در دسترس است.
env:
- variable: STORAGE_BUCKET
value: mybucket.appspot.com
availability:
- BUILD
- RUNTIME
برای برنامه‌های Next.js، همچنین می‌توانید از پیشوند NEXT_PUBLIC_ به همان روشی که در فایل dotenv خود استفاده می‌کنید استفاده کنید تا یک متغیر در مرورگر قابل دسترسی باشد.
env:
- variable: NEXT_PUBLIC_STORAGE_BUCKET
value: mybucket.appspot.com
availability:
- BUILD
- RUNTIME
کلیدهای متغیر معتبر از نویسه‌های AZ یا زیرخط تشکیل شده‌اند. برخی از کلیدهای متغیر محیطی برای استفاده داخلی رزرو شده اند. از هیچ یک از این کلیدها در فایل های پیکربندی خود استفاده نکنید:
- هر متغیری که با
X_FIREBASE_شروع می شود -
PORT -
K_SERVICE -
K_REVISION -
K_CONFIGURATION
ذخیره و دسترسی به پارامترهای مخفی
اطلاعات حساس مانند کلیدهای API باید به عنوان راز ذخیره شوند. برای جلوگیری از بررسی اطلاعات حساس در کنترل منبع، می توانید اسرار را در apphosting.yaml ارجاع دهید.
پارامترهای نوع secret پارامترهای رشته ای را نشان می دهد که دارای مقدار ذخیره شده در Cloud Secret Manager هستند. به جای استخراج مستقیم مقدار، پارامترهای مخفی وجود را در Cloud Secret Manager بررسی می‌کنند و مقادیر را در حین عرضه بارگیری می‌کنند.
- variable: API_KEY
secret: myApiKeySecret
Secrets in Cloud Secret manager می تواند چندین نسخه داشته باشد. به‌طور پیش‌فرض، مقدار یک پارامتر مخفی موجود در باطن زنده شما به آخرین نسخه موجود مخفی در زمان ساخت backend پین می‌شود. اگر برای نسخه‌سازی و مدیریت چرخه حیات پارامترها نیاز دارید، می‌توانید با Cloud Secret Manager به نسخه‌های خاصی پین کنید. به عنوان مثال، برای پین کردن به نسخه 5:
- variable: PINNED_API_KEY
secret: myApiKeySecret@5
می توانید با دستور CLI firebase apphosting:secrets:set رازهایی ایجاد کنید و از شما خواسته می شود مجوزهای لازم را اضافه کنید. این جریان به شما این امکان را می دهد که به طور خودکار مرجع مخفی را به apphosting.yaml اضافه کنید.
برای استفاده از مجموعه کامل عملکرد Cloud Secret Manager، می توانید به جای آن از کنسول Cloud Secret Manager استفاده کنید. اگر این کار را انجام دهید، باید با دستور CLI firebase apphosting:secrets:grantaccess به باطن App Hosting خود مجوز بدهید.
همگام سازی وضعیت Firebase Auth
برنامه‌هایی که از Firebase Auth استفاده می‌کنند باید از Firebase Web SDK برای کمک به همگام نگه داشتن وضعیت احراز هویت بین مشتری و سرور استفاده کنند. این را می توان با پیاده سازی FirebaseServerApp با یک سرویس دهنده تسهیل کرد. جریان کار اصلی این است:
- یک سرویس‌کار را پیاده‌سازی کنید که هدرهای مناسب را برای برنامه شما در درخواست‌ها به سرور اضافه می‌کند.
- هدرها را از درخواست روی سرور دریافت کنید و با
FirebaseServerAppآن را به یک کاربر تأیید اعتبار تبدیل کنید.
مدیریت پشتیبان ها
دستورات مربوط به مدیریت پایه پشتیبان های App Hosting در Firebase CLI ارائه شده است. برخی از عملیات ها نیز در کنسول Firebase در دسترس هستند. در این بخش برخی از کارهای مدیریتی رایج‌تر، از جمله ایجاد و حذف Backendها توضیح داده می‌شود.
یک Backend ایجاد کنید
پشتیبان App Hosting مجموعه ای از منابع مدیریت شده است که App Hosting برای ساخت و اجرای برنامه وب شما ایجاد می کند. می‌توانید با استفاده از کنسول Firebase یا Firebase CLI، پشتیبان‌های App Hosting را ایجاد و فهرست کنید.
کنسول Firebase : از منوی Build ، App Hosting را انتخاب کنید و سپس شروع کنید .
CLI: (نسخه 13.15.4 یا بالاتر) برای ایجاد یک Backend، دستور زیر را از ریشه دایرکتوری پروژه محلی خود اجرا کنید و ID project و منطقه ترجیحی خود را به عنوان آرگومان ارائه کنید:
firebase apphosting:backends:create --project PROJECT_ID --location us-central1
برای هر دو کنسول یا CLI، دستورات را دنبال کنید تا یک نام به باطن خود اختصاص دهید، یک اتصال GitHub راه اندازی کنید، و این تنظیمات اولیه استقرار را پیکربندی کنید:
دایرکتوری ریشه برنامه خود را تنظیم کنید (به طور پیش فرض روی
/)این معمولاً جایی است که فایل
package.jsonشما قرار دارد.
شاخه زنده را تنظیم کنید
این شاخه ای از مخزن GitHub شما است که در URL زنده شما مستقر می شود. اغلب، این شاخه ای است که شاخه های ویژگی یا شاخه های توسعه در آن ادغام می شوند.
پذیرش یا رد عرضه خودکار
عرضه خودکار به طور پیش فرض فعال است. پس از اتمام ایجاد باطن، می توانید انتخاب کنید که برنامه شما بلافاصله در App Hosting مستقر شود.
یک باطن را حذف کنید
برای حذف کامل یک Backend، ابتدا از Firebase CLI استفاده کنید و سپس به صورت دستی دارایی‌های مرتبط را حذف کنید، و مراقب باشید منابعی را که ممکن است توسط سایر Backendها یا سایر جنبه‌های پروژه Firebase شما استفاده شود حذف نکنید.
دستور زیر را برای حذف App Hosting Backend اجرا کنید. با این کار همه دامنه‌ها برای باطن شما غیرفعال می‌شود و سرویس Cloud Run مربوطه حذف می‌شود:
firebase apphosting:backends:delete BACKEND_ID --project PROJECT_ID --location us-central1(اختیاری) در برگه Google Cloud Console برای Artifact Registry ، تصویر مربوط به باطن خود را در "firebaseapphosting-images" حذف کنید.
در Cloud Secret Manager ، هر گونه اسرار حاوی "apphosting" در نام مخفی را حذف کنید، و مراقب باشید که این اسرار توسط سایر Backendها یا سایر جنبه های پروژه Firebase شما استفاده نشود .