הגדרה וניהול של קצוות עורפי של אירוח אפליקציות

‫App Hosting תוכנן כך שיהיה קל להשתמש בו ולתחזק אותו, עם הגדרות ברירת מחדל שמתאימות לרוב תרחישי השימוש. במקביל, App Hosting מספק כלים לניהול ולהגדרה של קצוות עורפיים בהתאם לצרכים הספציפיים שלכם. במדריך הזה נתאר את הכלים והתהליכים האלה.

הגדרה ועדכון של משתני סביבה וסודות

ב-App Hosting אפשר להשתמש במשתני סביבה לערכי הגדרות לא רגישים, ובסודות לפרמטרים רגישים כמו מפתחות API, פרטי כניסה למסד נתונים ואסימוני שירות.

  • משתני סביבה רגילים: משמשים להגדרות לא רגישות של טקסט פשוט (כמו כתובות URL ציבוריות של API,‏ feature flags או יעדי build). כל חברי הפרויקט יכולים לראות את הערכים.
  • סודות: משמשים לפרמטרים רגישים (כמו סודות לקוח של OAuth, אסימוני API או סיסמאות למסדי נתונים). הסודות מגובים על ידי Cloud Secret Manager. ערכי הסודות מוגנים ואף פעם לא מוצגים כטקסט פשוט במסוף Firebase. במקום זאת, במסוף יש קישורי עומק שמאפשרים לראות ולנהל את ערכי הסודות ישירות ב-Cloud Secret Manager.

אפשר להגדיר ולנהל פרמטרים של סביבה בשתי גישות משלימות:

  • מסוף Firebase: אפשר להוסיף, לערוך ולצרף במהירות סודות או משתנים באופן דינמי במהלך היצירה הראשונית של הקצה העורפי, או אחרי הפריסה בהגדרות של הקצה העורפי.

  • קוד תחילה (apphosting.yaml): הצהרה על משתני סביבה והפניות לסודות בקובץ התצורה של המאגר לפריסות עם ניהול גרסאות, או שימוש ב-apphosting.<env>.yaml כדי להגדיר ערכים שונים לסביבות שונות.

מסוף Firebase

צילום מסך של תיבת הדו-שיח במסוף Firebase להוספת משתני סביבה

apphosting.yaml 

env:
  - variable: STORAGE_BUCKET
    value: mybucket.firebasestorage.app
  - variable: API_KEY
    secret: myApiKeySecret

ניהול משתנים וסודות במסוף Firebase

אתם יכולים להגדיר משתני סביבה וסודות במסוף Firebase כשאתם יוצרים קצה עורפי, או בכל שלב בהגדרות של הקצה העורפי. שינויים שנשמרו בלי פריסה ייכנסו לתוקף בהשקה הבאה ולא ישפיעו על ההשקה הנוכחית.

הגדרת משתנים וסודות במהלך יצירת הקצה העורפי

כשיוצרים קצה עורפי חדש של App Hosting במסוף Firebase, אפשר להגדיר משתני סביבה וסודות סטנדרטיים בשלב Configure your backend באשף ההגדרה:

  1. במסוף Firebase, נכנסים אל Hosting & Serverless > App Hosting ולוחצים על Create backend.
  2. משלימים את השלבים הראשוניים באשף כדי לבחור את האזור הראשי ואת מאגר המקורות של הקוד.
  3. בקטע Configure your backend, מאתרים את הכרטיסים הניתנים לכיווץ של Environment variables ו-Secrets, שבהם אפשר להוסיף משתני סביבה ולצרף סודות.
  4. מסיימים את אשף יצירת הקצה העורפי ולוחצים על Finish & deploy (סיום ופריסה).

ניהול משתנים וסודות בהגדרות של הקצה העורפי

אתם יכולים לראות, להוסיף, לערוך או למחוק משתני סביבה וסודות של קצוות עורפיים פעילים ממרכז הבקרה של הגדרות הקצה העורפי:

  1. במסוף Firebase, בוחרים את הקצה העורפי של App Hosting ופותחים את Settings ‏ > Environment.
  2. בודקים את ההגדרות הקיימות בטבלה Environment variables:
    • משתנים רגילים: הערכים מוצגים כטקסט פשוט בבלוקים של קוד שאפשר להעתיק.
    • ‫Secrets: מוצג כקישור שאפשר ללחוץ עליו עם שם הסוד (שפותח את Cloud Secret Manager במסוף Google Cloud) לצד הגרסה המטורגטת (כמו latest או מספר גרסה ספציפי כמו 2).
  3. כדי להוסיף משתנה או סוד:
    1. לוחצים על הוספה.
    2. ב-Step 1: Select type, בוחרים באפשרות Standard environment variable (לנתונים לא רגישים שגלויים לכל חברי הפרויקט) או באפשרות Secret (למפתחות API ולפרטי כניסה רגישים עם גישה מוגבלת), ואז לוחצים על Next.
    3. בקטע Step 2: Configure settings, מזינים את שם המפתח (Key) ואת הערך (Value) בטקסט פשוט (למשתנים רגילים), או בוחרים את המזהה (Secret) והגרסה (Version) של הסוד (לסודות).
    4. שומרים את השינויים באחת מהדרכים הבאות:
      • שמירה ופריסה: עדכון מיידי של הגדרת הקצה העורפי והפעלה של גרסה חדשה והשקה.
      • Just save (מהחץ לתפריט הנפתח לצד Save and deploy): שמירת השינויים בהגדרות בלי להפעיל השקה מיידית. ההגדרות המעודכנות ייכנסו לתוקף בפריסה הבאה.
  4. כדי לערוך או למחוק רשומה קיימת, לוחצים על התפריט פעולות נוספות (...) בסוף השורה:
    • לוחצים על Edit כדי לשנות את המפתח, הערך, מיפוי הסוד או הגרסה, ואז לוחצים על Save and deploy או על Just save.
    • לוחצים על מחיקה ומאשרים את ההסרה בתיבת הדו-שיח.

העברת משתנים מקובצי dotenv

באפליקציות Next.js, קובצי dotenv שמכילים משתני סביבה פועלים עם App Hosting.

כשיוצרים או מעדכנים קצה עורפי, אפשר להעביר משתני סביבה מהקובץ dotenv למסוף Firebase. כדי לעשות את זה, מעתיקים את כל התוכן של הקובץ dotenv ומדביקים אותו בשדה Key הראשון בטופס Add new בקטע Settings ‏ > Environment.

כל משתני הסביבה שמועתקים בדרך הזו מעוצבים באופן אוטומטי בטופס, בלי שצריך להזין כל אחד מהם בנפרד, כל עוד הקלט משתמש בפורמט KEY=value סטנדרטי:

KEY1=value1
KEY2=value2
KEY3=value3

כדי לשלוט במשתני סביבה מורכבים או מפורטים בכל מסגרת, מומלץ להשתמש ב-apphosting.yaml.

ניהול משתנים וסודות ב-apphosting.yaml

בתהליכי עבודה שמתחילים בקוד, צריך להצהיר על משתני סביבה סטנדרטיים ועל הפניות לסודות במפתח env: בקובץ התצורה apphosting.yaml של מאגר הפרויקט (ראו יצירה ועריכה של apphosting.yaml).

env:
  # Standard environment variables
  - variable: PUBLIC_API_URL
    value: https://api.example.com
    availability:
      - BUILD
      - RUNTIME
  - variable: FEATURE_FLAG_NEW_UI
    value: "true"

  # Secret references backed by Cloud Secret Manager
  - variable: DATABASE_URL
    secret: projects/PROJECT_ID/secrets/db-connection-string/versions/latest
  - variable: GEMINI_API_KEY
    secret: myGeminiApiKeySecret@1

כל רשומה ב-env: תומכת בשדות הבאים:

  • ‫variable: השם של משתנה הסביבה שחשוף לתהליך של האפליקציה.
  • ‫value: ערך המחרוזת של הטקסט הפשוט (למשתני סביבה רגילים).
  • ‫secret: ההפניה לסוד ב-Cloud Secret Manager (לסודות). אפשר להשתמש בשם הקצר של הסוד (כמו myGeminiApiKeySecret או myGeminiApiKeySecret@1 המוצמד) או בנתיב המלא של המשאב (projects/PROJECT_ID/secrets/SECRET_ID/versions/VERSION). פרטים נוספים זמינים במאמר אחסון פרמטרים סודיים וגישה אליהם.
  • ‫availability: קובע אם המשתנה או הסוד נגישים במהלך השלב BUILD, ב-RUNTIME או בשניהם.

הגדרת זמינות משתנה

משתני סביבה וסודות שמוגדרים במסוף Firebase זמינים גם בזמן ה-build וגם בזמן הריצה. זו גם פעולת ברירת המחדל של רשומות שמוגדרות ב-apphosting.yaml, אלא אם מצמצמים את ההיקף באמצעות המאפיין availability. ב-apphosting.yaml (אבל לא במסוף), אתם יכולים להגביל משתנה או סוד רק לסביבת ה-build‏ (BUILD) או רק לסביבת זמן הריצה (RUNTIME).

גישה למשתנים ולסודות בקוד האפליקציה

לא משנה אם הגדרתם את משתני הסביבה והסודות במסוף Firebase או ב-apphosting.yaml, הם נחשפים לסביבת זמן הריצה של האפליקציה כמשתני סביבה רגילים (לדוגמה, process.env ב-Node.js).

// Accessing a standard environment variable
const apiUrl = process.env.PUBLIC_API_URL;

// Accessing a secret
const apiKey = process.env.GEMINI_API_KEY;

export async function fetchData() {
  const response = await fetch(`${apiUrl}/data`, {
    headers: {
      'Authorization': `Bearer ${apiKey}`
    }
  });
  return response.json();
}
  • גישה בצד השרת: כל משתני הסביבה והסודות נגישים בצורה מאובטחת בהקשרים של הפעלה בצד השרת (כמו רכיבי שרת של Next.js, נתיבי API או handler לקצה העורפי של Node.js).

  • חשיפה בצד הלקוח: כדי לחשוף משתני סביבה סטנדרטיים לדפדפן ב-frameworks כמו Next.js, צריך לוודא שמפתח המשתנה תואם למוסכמות של ה-framework (לדוגמה, עם הקידומת NEXT_PUBLIC_).

    env:
  - variable: NEXT_PUBLIC_STORAGE_BUCKET
    value: mybucket.firebasestorage.app
    availability:
      - BUILD
      - RUNTIME

היררכיית משתנים

ב-Firebase App Hosting, משתני הסביבה והסודות מופעלים לפי סדר קדימויות שמבוסס על המקור שלהם. הגדרות שנקבעו במסוף Firebase תמיד מבטלות את הפרמטרים שהוצהרו בקבצים apphosting.yaml ו-dotenv. אם משתנה סביבה או מפתח סודי עם אותו שם קיימים גם ב-apphosting.yaml וגם במסוף Firebase, הערך של המסוף מקבל עדיפות במהלך ההרצה בזמן ה-build ובזמן הריצה.

זהו סדר הקדימויות המלא:

  1. מסוף Firebase ← משתנים וסודות שמוגדרים במסוף
  2. ‫apphosting.<env>.yaml ← משתנים וסודות שצוינו בקובץ YAML ספציפי לסביבה, כמו apphosting.staging.yaml (ראו פריסה של כמה סביבות)
  3. ‫apphosting.yaml ← משתנים וסודות שצוינו בקובץ apphosting.yaml
  4. מערכת Firebase ← משתנים שמוגדרים על ידי Firebase ומכילים ערכים של FIREBASE_CONFIG או FIREBASE_WEBAPP_CONFIG, וגם משתני סביבה שמגדירים את שמות המארחים והיציאות של אפליקציות SSR (מוגדרים על ידי מתאמי App Hosting ב-bundle.yaml)

משתני סביבה שמאוכלסים באופן אוטומטי

יש משתני סביבה שמאוכלסים באופן אוטומטי על ידי App Hosting. הם כוללים את אלה שמאוכלסים על ידי Google Cloud, וגם משתני סביבה ספציפיים ל-Firebase כש-appId מוגדר בקצה העורפי במהלך ההגדרה:

  • ‫FIREBASE_CONFIG: (זמין בסביבות ה-build וה-runtime) מספק את פרטי ההגדרה הבאים של פרויקט Firebase:

    {
  "databaseURL": "https://DATABASE_NAME.firebaseio.com",
  "storageBucket": "PROJECT_ID.firebasestorage.app",
  "projectId": "PROJECT_ID"
}

    ההגדרה הזו מופעלת באופן אוטומטי כשמפעילים את ה-SDK של Firebase לאדמינים בלי ארגומנטים.

  • ‫FIREBASE_WEBAPP_CONFIG: (זמין רק בסביבת ה-build) מספק את פרטי ההגדרה הבאים של פרויקט Firebase:

    {
  "apiKey": "API_KEY",
  "appId": "APP_ID",
  "authDomain": "AUTH_DOMAIN.firebaseapp.com",
  "databaseURL": "https://DATABASE_NAME.firebaseio.com",
  "messagingSenderId": "PROJECT_NUMBER",
  "projectId": "PROJECT_ID",
  "storageBucket": "PROJECT_ID.firebasestorage.app"
}</span>

    ‫Firebase JS SDK בודק באופן אוטומטי את משתנה הסביבה הזה בFIREBASE_WEBAPP_CONFIG postinstall script במהלך ה-build, וכך מאפשר לכם גם להפעיל את ה-SDK של הלקוח בלי ארגומנטים.

במאמר הפעלה אוטומטית של SDK של Firebase לאדמינים ושל ערכות SDK לאינטרנט מוסבר איך להשתמש במשתני הסביבה האלה כדי להפעיל את ערכות ה-SDK.

שימו לב שהערכים בתצורה של Firebase בפועל יתאימו למשאבים הספציפיים שהקציתם בפרויקט.

היררכיית משתנים

ב-Firebase App Hosting, המשתנים מוחלים לפי סדר קדימויות שמבוסס על המקור שלהם. לדוגמה, ערכים שמוגדרים במסוף Firebase תמיד מבטלים ערכים שמוגדרים בקובצי apphosting.yaml ו-dotenv, או מקבלים קדימות על פניהם.

זהו סדר הקדימויות המלא:

  1. מסוף Firebase ← משתנים שמוגדרים במסוף
  2. ‫apphosting.<env>.yaml ← משתנים שצוינו בקובץ YAML ספציפי לסביבה, כמו apphosting.staging.yaml (ראו פריסה של כמה סביבות)
  3. ‫apphosting.yaml ← משתנים שצוינו בקובץ apphosting.yaml
  4. מערכת Firebase ← משתנים שמוגדרים על ידי Firebase ומכילים ערכים של firebase_config json או firebase_webapp_config, וגם משתני סביבה שמגדירים את שמות המארחים והיציאות של אפליקציות SSR (מוגדרים על ידי מתאמי App Hosting ב-bundle.yaml)

שמות שמורים ומגבלות

משתני הסביבה שמוגדרים בחוזה זמן הריצה של קונטיינר Cloud Run שמורים ואי אפשר להגדיר אותם.

משתני סביבה שסופקו על ידי הסביבה, מלבד אלה שמוגדרים באופן אוטומטי, עשויים להשתנות בגרסאות עתידיות של סביבת זמן הריצה. כשיטה מומלצת, מומלץ לא להסתמך על משתני סביבה שלא הגדרתם באופן מפורש, ולא לשנות אותם. כדאי להוסיף קידומת לכל משתני הסביבה עם מפתח ייחודי כדי למנוע התנגשויות.

חלק מהמפתחות של משתני הסביבה שמורים לשימוש פנימי. אל תשתמשו במפתחות האלה בקובצי התצורה:

  • מחרוזות ריקות ("")
  • מפתחות שמכילים את התו "="
  • מפתחות שמתחילים ב-X_FIREBASE_, ב-X_GOOGLE_ או ב-CLOUD_RUN_
  • PORT
  • K_SERVICE
  • K_REVISION
  • K_CONFIGURATION
  • מפתחות כפולים

יצירה ועריכה של apphosting.yaml

כדי להגדיר הגדרות מתקדמות כמו סודות או הגדרות זמן ריצה כמו בו-זמניות, מעבד (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.firebasestorage.app
    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, ל-memoryMiB ול-concurrency יש מגבלות שתלויות זו בזו (לדוגמה, הגדרות זיכרון גבוהות יותר דורשות מגבלות מינימליות גבוהות יותר של מעבד (CPU), ומעבדים חלקיים דורשים בו-זמניות של 1). עיינו במסמכי התיעוד של Cloud Run בנושא מגבלות מעבד (CPU) ומגבלות זיכרון כדי לראות את הטווחים התקינים והשילובים הנדרשים.

שינוי סקריפטים של build והרצה

‫App Hosting מסיק את פקודת ה-build וההפעלה של האפליקציה על סמך ה-framework שזוהה. אם רוצים להשתמש בפקודת build או start בהתאמה אישית, אפשר לשנות את הגדרות ברירת המחדל של App Hosting ב-apphosting.yaml.

scripts:
  buildCommand: next build --no-lint
  runCommand: node dist/index.js

הפקודה הזו מבטלת את כל פקודות ה-build האחרות, מבטלת את ההצטרפות של האפליקציה למתאמי המסגרת ומשביתה את כל האופטימיזציות הספציפיות למסגרת ש-App Hosting מספק. כדאי להשתמש בו כשהמתאמים לא תומכים היטב בתכונות של האפליקציה. אם אתם רוצים לשנות את פקודת ה-build אבל עדיין להשתמש במתאמים שסופקו, הגדירו את סקריפט ה-build ב-package.json במקום זאת, כפי שמתואר בקטע מתאמי מסגרת של App Hosting.

אם אתם רוצים להשתמש בפקודה ספציפית כדי להפעיל את האפליקציה, ששונה מהפקודה שנובעת מ-App Hosting, אתם יכולים להשתמש בשינוי של פקודת ההפעלה.

הגדרת פלט ה-build

כברירת מחדל, App Hosting מבצע אופטימיזציה של פריסות האפליקציה על ידי מחיקת קובצי פלט שלא בשימוש, כפי שצוין על ידי ה-framework. אם רוצים לבצע אופטימיזציה נוספת של גודל הפריסה של האפליקציה או להתעלם מהאופטימיזציות שמוגדרות כברירת מחדל, אפשר לשנות את ההגדרות האלה ב-apphosting.yaml.

outputFiles:
  serverApp:
    include: [dist, server.js]

הפרמטר include מקבל רשימה של ספריות וקבצים שקשורים לתיקיית השורש של האפליקציה, שנדרשים לפריסת האפליקציה. אם אתם רוצים לוודא שכל הקבצים נשמרים, הגדירו את include ל-[.] וכל הקבצים ייפרסו.

אחסון פרמטרים סודיים וגישה אליהם

מידע רגיש כמו מפתחות API צריך להיות מאוחסן כסודות. אתם יכולים לצרף סודות לקצה העורפי שלכם במסוף Firebase או להפנות אליהם ב-apphosting.yaml כדי להימנע מהעברת מידע רגיש לבקרת המקור.

פרמטרים מסוג secret מייצגים פרמטרים של מחרוזות שהערך שלהם מאוחסן ב-Cloud Secret Manager. במקום להפיק את הערך ישירות, הפרמטרים של הסודות בודקים אם הם קיימים ב-Cloud Secret Manager וטוענים את הערכים במהלך ההשקה.

env:
  - variable: API_KEY
    secret: myApiKeySecret

לסודות ב-Cloud Secret Manager יכולות להיות כמה גרסאות. כברירת מחדל, הערך של פרמטר סודי שזמין לקצה העורפי הפעיל מוצמד לגרסה האחרונה הזמינה של הסוד בזמן שהקצה העורפי נוצר. אם יש לכם דרישות לניהול גרסאות ומחזור חיים של פרמטרים, אתם יכולים להצמיד גרסאות ספציפיות במסוף Firebase או ב-apphosting.yaml. לדוגמה, כדי להצמיד לגרסה 5 ב-apphosting.yaml:

env:
  - variable: PINNED_API_KEY
    secret: myApiKeySecret@5

אפשר ליצור סודות באמצעות פקודת ה-CLI‏ Firebase firebase apphosting:secrets:set, ותתבקשו להוסיף את ההרשאות הנדרשות. בתהליך הזה יש אפשרות להוסיף באופן אוטומטי את ההפניה לסוד ל-apphosting.yaml.

מתן גישה ל-Cloud Secret Manager

כדי ש-App Hosting יוכל לאחזר ערכים סודיים במהלך השקות של גרסאות build וזמן ריצה, לחשבון השירות לקצה העורפי של App Hosting צריכה להיות הרשאת גישה ל-Cloud Secret Manager.

אם אתם יוצרים סודות באמצעות מסוף Cloud Secret Manager או ה-CLI של gcloud במקום firebase apphosting:secrets:set, אתם צריכים לתת גישה לקצה העורפי באמצעות ה-CLI של Firebase:

firebase apphosting:secrets:grantaccess SECRET_NAME

לחלופין, אתם יכולים להקצות את התפקיד Secret Manager Secret Accessor (roles/secretmanager.secretAccessor) לסוכן השירות של App Hosting (service-PROJECT_NUMBER@gcp-sa-apphosting.iam.gserviceaccount.com) או לחשבון השירות של זמן הריצה של הקצה העורפי, באמצעות ה-CLI של gcloud:

gcloud secrets add-iam-policy-binding SECRET_NAME \
    --member="serviceAccount:service-PROJECT_NUMBER@gcp-sa-apphosting.iam.gserviceaccount.com" \
    --role="roles/secretmanager.secretAccessor"

גישה ל-Console והרשאות שמבוססות על תפקידים

מסוף Firebase מגביל באופן דינמי את התכונות של ניהול הסביבה והסודות, בהתאם להרשאות IAM של המשתמשים:

  • תפקיד צפייה: משתמשים עם הרשאות קריאה בלבד ברמת הפרויקט יכולים לראות את הגדרות התצורה הקיימות, אבל לא יכולים לבצע שינויים.
    • בזמן יצירת הקצה העורפי, הלחצן Create backend מושבת.
    • ב-backend, בקטע Settings > Environment, הלחצן Add new מושבת והתפריטים של השורות More actions (...) מוסתרים.
  • חסרות הרשאות ל-Secret Manager: משתמשים שאין להם הרשאות IAM לאינטראקציה עם Cloud Secret Manager רואים הודעת אזהרה במסוף (צריך לבקש מבעלי הפרויקט הרשאה להוסיף סודות):
    • במהלך יצירת הקצה העורפי, הכרטיס Secrets מושבת.
    • בקטע Settings > Environment של ה-backend, האפשרות Secret מושבתת כשלוחצים על Add new, וחלק מהאפשרויות בתפריט השורה More actions (...) מוסתרות ברשומות סודיות קיימות.

הגדרת הגישה ל-VPC

ה-backend של App Hosting יכול להתחבר לרשת ענן וירטואלי פרטי (VPC). למידע נוסף ולדוגמה, קראו את המאמר חיבור של Firebase App Hosting לרשת VPC.

כדי להגדיר את הגישה, משתמשים במיפוי vpcAccess בקובץ apphosting.yaml. צריך להשתמש בשם מלא של רשת או מחבר, או במזהה. השימוש במזהים מאפשר ניידות בין סביבות Staging וסביבות ייצור עם מחברים או רשתות שונים.

הגדרת תעבורת נתונים יוצאת (egress) ב-Direct VPC‏ (apphosting.yaml):

runConfig:
  vpcAccess:
    egress: PRIVATE_RANGES_ONLY # Default value
    networkInterfaces:
      # Specify at least one of network and/or subnetwork
      - network: my-network-id
        subnetwork: my-subnetwork-id

הגדרת מחבר ללא שרת (serverless) (apphosting.yaml):

runConfig:
  vpcAccess:
    egress: ALL_TRAFFIC
    connector: connector-id

ניהול קצוות עורפיים

פקודות לניהול בסיסי של קצוות עורפיים של App Hosting מופיעות במסוף Firebase וב-CLI של Firebase. בקטע הזה מתוארות כמה ממשימות הניהול הנפוצות יותר, כולל יצירה ומחיקה של קצוות עורפיים.

יצירת בק-אנד

קצה עורפי של App Hosting הוא אוסף המשאבים המנוהלים שנוצרים על ידי App Hosting כדי ליצור ולהפעיל את אפליקציית האינטרנט.

מסוף Firebase: עוברים אל Hosting & Serverless‏ > App Hosting, ואז לוחצים על Create backend (אם זה הקצה העורפי הראשון בפרויקט ב-Firebase, לוחצים על Get started).

‫Firebase CLI: (גרסה 13.15.4 ואילך) כדי ליצור קצה עורפי, מריצים את הפקודה הבאה מהשורש של ספריית הפרויקט המקומית, ומספקים את מזהה הפרויקט כארגומנט:

firebase apphosting:backends:create --project PROJECT_ID

במסוף או ב-CLI, פועלים לפי ההנחיות כדי לבחור אזור, להגדיר חיבור ל-GitHub ולקבוע את הגדרות הפריסה הבסיסיות הבאות:

  • מגדירים את תיקיית השורש של האפליקציה (ברירת המחדל היא /)

    בדרך כלל זה המקום שבו נמצא קובץ package.json.

  • הגדרת הענף הפעיל

    זו ההסתעפות של המאגר ב-GitHub שנפרסת בכתובת ה-URL הפעילה. לרוב, זהו הענף שאליו מתמזגים ענפי התכונות או ענפי הפיתוח.

  • לאשר או לדחות השקות אוטומטיות

    ההשקות האוטומטיות מופעלות כברירת מחדל. בסיום היצירה של הקצה העורפי, אתם יכולים לבחור לפרוס את האפליקציה ב-App Hosting באופן מיידי.

  • נותנים שם לקצה העורפי.

  • בוחרים את סביבת זמן הריצה. כברירת מחדל, הגרסה המומלצת החדשה ביותר של Node.js נבחרת בשבילכם.

מחיקת קצה עורפי

כדי להסיר לגמרי קצה עורפי, קודם צריך למחוק אותו באמצעות מסוף Firebase או ה-CLI של Firebase, ואז להסיר ידנית נכסים קשורים. חשוב לשים לב לא למחוק משאבים שיכול להיות שמשמשים קצוות עורפיים אחרים או היבטים אחרים של הפרויקט ב-Firebase.

מסוף Firebase: בתפריט Settings, בוחרים באפשרות Delete backend.

Firebase CLI: (גרסה 13.15.4 ואילך)

  1. מריצים את הפקודה הבאה כדי למחוק את הקצה העורפי של App Hosting. הפעולה הזו משביתה את כל הדומיינים של הקצה העורפי ומוחקת את שירות Cloud Run המשויך:

    firebase apphosting:backends:delete BACKEND_ID --project PROJECT_ID

  2. (אופציונלי) בכרטיסייה של מסוף Google Cloud של Artifact Registry, מוחקים את קובץ האימג' של הקצה העורפי ב-firebaseapphosting-images.

  3. ב-Cloud Secret Manager, מחקו את כל הסודות שכוללים את המילה apphosting בשם הסוד. חשוב לוודא שהסודות האלה לא נמצאים בשימוש על ידי קצוות עורפיים אחרים או היבטים אחרים של הפרויקט ב-Firebase.