תחילת העבודה עם Application Design Center‏ (ADC) ו-Firebase

גרסת טרום-השקה (Preview): זוהי גרסת טרום-השקה של תמיכת Firebase ב-Application Design Center. יכול להיות שקבוצת התכונות והכלים הזו תשתנה בדרכים שלא תואמות לדורות קודמים, והיא לא כפופה להסכם SLA או למדיניות הוצאה משימוש.

‫Firebase משתלב עם Application Design Center (ADC) מ-Google Cloud כדי לאפשר ללקוחות ארגוניים לעמוד בדרישות התקינה והפיקוח, וגם לאפשר למפתחי האפליקציות שלהם להשיק במהירות. בעזרת ADC אפשר לוודא שהתשתית עומדת בתקנים ובשיטות המומלצות של הארגון, באמצעות תבניות מוגדרות מראש שקובעות את גבולות הגזרה להקצאת משאבים, להענקת הרשאות IAM וכו'.

בדף הזה אנחנו מסבירים על:

• סקירה כללית של ADC ו-Firebase, כולל מוצרי Firebase נתמכים
• פרסונות עיקריות ותפקידי IAM שנדרשים לבקרת גישה
• תהליך עבודה כללי

סקירה כללית של ADC ו-Firebase

מומלץ לעיין במסמכי התיעוד של Google Cloud כדי לקבל סקירה כללית של ADC. במסמכי התיעוד של Google Cloud יש גם כמה מדריכים מפורטים ל-ADC, כולל מושגי מפתח ומדריך להגדרה ראשונית.

כשמשתמשים ב-ADC, "אפליקציה" מוגדרת כקבוצה לוגית של משאבים ושירותים שביחד מספקים פונקציה עסקית. למפתחים ב-Firebase, אפשר לחשוב על "אפליקציה" ב-ADC כמקבילה לפרויקט ב-Firebase, שבו כל האפליקציות הרשומות ל-iOS, ל-Android ולאינטרנט משתפות את אותם משאבים ושירותים בפרויקט ויש להן גישה אליהם.

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

שימו לב ש-ADC מגובה על ידי Terraform, כך שתמיד תהיה לכם גישה להגדרת הקוד של התשתית שמוגדרת באמצעות ADC.

מוצרי Firebase נתמכים

אלה מוצרי Firebase הראשונים שאפשר להשתמש בהם עם ADC:

• Firebase AI Logic
• Firebase Authentication
• Firebase App Check
• Cloud Firestore
• Firebase Security Rules

פרסונות עיקריות לשימוש ב-ADC

דרך נפוצה להבין את ADC ולהשתמש בו היא לחלק את המשימות שקשורות ל-ADC לפי שני תפקידים:

• מהנדס פלטפורמה: הפרסונה הזו מתכננת, מאמתת ומפרסמת תבניות ADC ניתנות לשימוש חוזר, עם מדיניות נאכפת, בקטלוג ADC.

• מפתח אפליקציות: משתמש בתבניות ADC שפורסמו (למשל, מהקטלוג של ADC של הצוות) כדי להגדיר ולפרוס תשתית. הם גם מפתחים את בסיס הקוד והתכונות של האפליקציה.

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

התפקידים שצריך ב-IAM כדי לשלוט בגישה

כשמקצים תפקידים ב-IAM, אפשר לקבוע אילו חברים בפרויקט (או חשבונות משתמשים) יכולים לבצע משימות ספציפיות.

לדוגמה, אתם יכולים להקצות את התפקיד אדמין ב-Application Design Center (roles/designcenter.admin) למהנדס הפלטפורמה שצריך ליצור ולהקצות מרחבים, לנהל קטלוגים ולעצב תבניות. עם זאת, סביר להניח שתקצו רק את התפקיד עריכת אפליקציות (roles/designcenter.applicationEditor) למפתח אפליקציות, כדי שהוא יוכל להשתמש בתבניות אבל לא ליצור תבניות.

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

בטבלה הבאה מתוארות משימות שקשורות ל-ADC, הפרסונה המיועדת שלהן והתפקידים הנדרשים:

משימה	פרסונה	תפקיד ב-IAM‏ ^1
יצירה וניהול של תבניות
לנהל את מחזור החיים המלא של ADC (כולל ניהול מרחבים, קטלוגים, תבניות, הגדרה ופריסה של אפליקציות)	מהנדס פלטפורמה	אדמין של Application Design Center (roles/designcenter.admin) בפרויקט הניהול
יצירה וניהול של תבניות, וגם הגדרה ופריסה של אפליקציות	מהנדס פלטפורמה	משתמש ב-Application Design Center (roles/designcenter.user) בפרויקט הניהול
יצירת חשבון שירות לפריסת אפליקציות ב-ADC
יצירת חשבונות שירות	מהנדס פלטפורמה	יצירת חשבונות שירות (roles/iam.serviceAccountCreator) בפרויקט הניהול
מתן גישה לחשבון שירות לפרויקט שמשמש לפריסה של ADC	מהנדס פלטפורמה	אדמין IAM של פרויקט (roles/resourcemanager.projectIamAdmin) בפרויקט הפריסה
הגדרה ופריסה של אפליקציות ADC
שליטה במחזור החיים המלא של האפליקציה (כולל שילוב עם קוד מקור ומערכות CI/CD)	מפתח אפליקציות	אדמין של אפליקציות (roles/designcenter.applicationAdmin) בפרויקט הניהול
להגדיר ולפרוס אפליקציות על סמך תבניות וחיבורים קיימים שהוגדרו על ידי אדמין	מפתח אפליקציות	עריכת אפליקציות (roles/designcenter.applicationEditor) בפרויקט הניהול

^{1 צריך להגדיר כמה מהתפקידים האלה בפרויקט הניהול, שהוא משאב ברמה העליונה בהיררכיה של Google Cloud.}

תהליך עבודה כללי

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

1. שלב 1: הגדרה של ADC (מהנדס פלטפורמה)
2. שלב 2: יצירת תבנית (מהנדס פלטפורמה)
3. שלב 3: שימוש בתבנית (מפתח אפליקציות)
4. שלב 4: פיתוח האפליקציה בפועל (מפתח האפליקציה)

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

שלב 1: הגדרה של ADC (מהנדס פלטפורמה)

כדי להגדיר את ADC, צריך לבצע את המשימות הבאות בתפקיד מהנדס פלטפורמה (או תפקיד בכיר יותר). בדרך כלל צריך לבצע את המשימות האלה רק פעם אחת כדי להגדיר את כל מה שצריך כדי להשתמש ב-ADC.

1. הגדרה ראשונית של ADC.

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

   אחרי שתסיימו את ההגדרה, יהיה לכם מרחב משותף – אזור ייעודי שבו הצוות יכול לעבוד ביחד, ליצור תבניות ולפרוס אפליקציות. חשוב לוודא שהמרחב הזה (והתיקייה והקטלוג) משותפים עם כל מי שרוצים לעבוד איתו ADC.

2. מגדירים את הגישה והמשתמשים במרחב המשותף.

   פועלים לפי השלבים שמפורטים בקטע ניהול משתמשים במרחב משותף של ADC במסמכי התיעוד של Google Cloud. משתמשים בהנחיות שמתוארות למעלה בקטע תפקידי IAM שנדרשים לבקרת גישה.

3. הקצאה מראש של פרויקטים.

   יוצרים פרויקט אחד או יותר ב-Google Cloud בתיקייה. חשוב לוודא שקישרתם חשבון Cloud Billing לפרויקטים האלה. מפתחי האפליקציות ישתמשו בפרויקטים האלה כשהם יפרסו את התשתית שמוגדרת בתבנית.

4. הגדרת חשבון שירות לפריסה

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

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

שלב 2: יצירת תבנית (מהנדס פלטפורמה)

מהנדס הפלטפורמה משתמש בלוח העיצוב או אפילו ב-Gemini Cloud Assist כדי ליצור תבנית ADC חדשה.

1. הגדרת משאבים.

   ב-design canvas, גוררים ומשחררים רכיבים ל-canvas ויוצרים ביניהם קשרים. הרכיבים האלה מאפשרים לכם להגדיר באילו שירותי Firebase (ו-Google Cloud) אתם רוצים שמפתחי האפליקציות ישתמשו.

   לדוגמה, התבנית יכולה להגדיר משאבים כמו:

   • מפתחי אפליקציות יכולים לפתח אפליקציות ל-iOS, ל-Android ואפליקציות אינטרנט שכולן משתמשות במשאבים.
   • מפתחי אפליקציות יכולים להשתמש ב-Firebase AI Logic, ב-Firebase Authentication, ב-Cloud Firestore וב-Firebase Security Rules באפליקציה שלהם (רשימה של כל מוצרי Firebase שנתמכים ב-ADC).
   • כברירת מחדל, Firebase Security Rules מוגדרים בהתחלה לדחות את כל בקשות הגישה. כך, כשמפתחי האפליקציות ישתמשו בתבנית הזו לפריסה שלהם, הם יוכלו לשנות את ה-Security Rules האלה בהתאם למודל הגישה הנדרש.

2. הגדרת כללי מדיניות.

   אם אתם רוצים להגדיר כללי מדיניות, כמו תפקידי IAM לתשתית שנפרסה או אזורים מותרים למשאבים, אתם צריכים להגדיר אותם בממשקים המתאימים לכללי המדיניות האלה. בשלב הזה, ב-ADC אין תמיכה בהגדרת כללי מדיניות ברמת התבנית.

   אתם יכולים להקצות תפקידי Firebase IAM ספציפיים לחברי הפרויקט, בהתאם לפעולות שאתם רוצים שהם יבצעו. לדוגמה, אם הם צריכים רק לצפות במשאבים במסוף Firebase, הקצו להם את התפקיד צפייה ב-Firebase (roles/firebase.viewer).

   אפשר להגדיר מגבלות אזוריות למשאבים ברמת התיקייה או הארגון.

3. מוסיפים את התבנית לקטלוג.

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

שלב 3: שימוש בתבנית (מפתח אפליקציות)

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

1. בוחרים תבנית ומגדירים אותה.

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

2. פורסים את התשתית.

   אחרי שיוצרים את טיוטת האפליקציה, פורסים את אפליקציית ADC באחד מהפרויקטים שהוקצו מראש שנוצרו לפריסת התשתית (ראו שלב 1: הגדרת ADC למעלה).

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

   הערה: נכון לעכשיו, אי אפשר לראות פרויקטים של Firebase שנפרסו באמצעות ADC ברשימות של פרויקטים במסוף Firebase או ב-CLI של Firebase. עם זאת, אם יש לכם את מזהה הפרויקט, אתם יכולים לפתוח ישירות פרויקט Firebase שנפרס ב-ADC באמצעות כתובת ה-URL של מסוף Firebase: https://console.firebase.google.com/project/PROJECT_ID/overview

שלב 4: פיתוח האפליקציה בפועל (מפתח האפליקציה)

‫ADC עוזר להגדיר את Firebase ואת התשתית של Google Cloud (למשל, הקצאת משאבים והפעלת ממשקי API). עם זאת, היא לא כותבת את הקוד של האפליקציה שמשתמשת במשאבים ובממשקי ה-API האלה.

הנה כמה דברים חשובים שמפתחי אפליקציות צריכים לעשות:

1. מקשרים את בסיס הקוד של האפליקציה ל-Firebase.

   מקבלים את הגדרות התצורה של Firebase ומוסיפים אותן לבסיס הקוד של כל אפליקציה.

   לדוגמה, אם התבנית מאפשרת אפליקציה ל-Android, צריך להוסיף את הקובץ google-services.json לספרייה המתאימה בפרויקט Android.

2. התאמה בין הקוד למשאבים.

   (אם משתמשים ב-Cloud Firestore) חשוב לעדכן ולפרסם את Firebase Security Rules בהתאם למודל הנתונים של Cloud Firestore באפליקציה.

מה עוד אפשר לעשות?

• מעקב אחרי ADC "אפליקציות" שנפרסו, שנרשמות באופן אוטומטי ב-App Hub. כך אפשר לעקוב אחרי משאבי Firebase, לבחון את העלויות שלהם ולפתור בהם בעיות, כחלק מפריסות רחבות יותר של Google Cloud.