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

‫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. בשלב 1: בחירת הסוג, בוחרים באפשרות משתנה סביבה רגיל (לנתונים לא רגישים שגלויים לכל חברי הפרויקט) או באפשרות סוד (למפתחות API ולפרטי כניסה רגישים עם גישה מוגבלת), ואז לוחצים על הבא.
    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 במהלך ה-build, וכך מאפשר לכם גם להפעיל את ה-SDK של הלקוח בלי ארגומנטים.

במאמר הפעלה אוטומטית של SDK של Firebase לאדמינים ו-web 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

אפשר ליצור סודות באמצעות הפקודה firebase apphosting:secrets:set ב-CLI של Firebase, ותופיע בקשה להוסיף את ההרשאות הנדרשות. התהליך הזה מאפשר להוסיף באופן אוטומטי את ההפניה לסוד אל 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"

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

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

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