Firebase משתלב עם Application Design Center (ADC) מ-Google Cloud כדי לאפשר ללקוחות ארגוניים לעמוד בדרישות של סטנדרטיזציה וממשל, וגם לתת למפתחי האפליקציות שלהם את האפשרות להשיק אפליקציות במהירות. השימוש ב-ADC מבטיח שהתשתית תעמוד בתקנים הארגוניים ובשיטות המומלצות באמצעות תבניות מוגדרות מראש, שמגדירות אמצעי הגנה להקצאת משאבים, למתן הרשאות IAM וכו'.
בדף הזה אנחנו מסבירים:
- סקירה כללית של ADC ו-Firebase, כולל מוצרי Firebase נתמכים
- דמויות מרכזיות ותפקידי IAM שנדרשים כדי לשלוט בגישה
- תהליך עבודה כללי
סקירה כללית על ADC ו-Firebase
מומלץ לעיין במסמכי התיעוד של Google Cloud כדי לקבל סקירה כללית של ADC. במסמכי התיעוד של Google Cloud יש גם כמה מדריכים מפורטים ל-ADC, כולל מושגי יסוד ומדריך להגדרה ראשונית.
כשמשתמשים ב-ADC, 'אפליקציה' מוגדרת כקיבוץ לוגי של משאבים ושירותים שביחד מספקים פונקציה עסקית. מבחינת מפתחים ב-Firebase, אפשר לחשוב על 'אפליקציה' כמקבילה ל'פרויקט Firebase', שבו האפליקציות הרשומות ל-iOS, ל-Android ולאינטרנט חולקות את כל המשאבים והשירותים של הפרויקט ויש להן גישה אליהם.ADC
כדי להתחיל, מומלץ לעבוד עם ADC באמצעות ממשק המשתמש הגרפי שלהם שנקרא לוח העיצוב, שזמין במסוף 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) כדי להגדיר ולפרוס תשתית. הם גם מפתחים את בסיס הקוד והתכונות של האפליקציה.
התפקידים שצריך ב-IAM כדי לשלוט בגישה
הקצאת תפקידים ב-IAM מאפשרת לכם לקבוע אילו חברים בפרויקט (או גורמים ראשיים) יכולים לבצע משימות ספציפיות.
לדוגמה, אפשר להקצות את התפקיד אדמין של מרכז עיצוב האפליקציות (roles/designcenter.admin) למהנדס הפלטפורמה שצריך ליצור ולהקצות מרחבים, לנהל קטלוגים ולעצב תבניות. עם זאת, סביר להניח שתקצו את התפקיד עורך אפליקציות (roles/designcenter.applicationEditor) רק למפתח אפליקציות, כדי שהוא יוכל להשתמש בתבניות אבל לא ליצור תבניות.
בטבלה הבאה מפורטות משימות שקשורות ל-ADC, הדמות שאליה הן מיועדות והתפקידים הנדרשים:
| משימה | קהל היעד | תפקיד IAM 1 |
|---|---|---|
| יצירה וניהול של תבניות | ||
|
ניהול ADCמחזור החיים המלא (כולל ניהול מרחבים, קטלוגים, תבניות, הגדרה ופריסה של אפליקציות) |
Platform Engineer |
אדמין של Application Design Center ( roles/designcenter.admin |
| ליצור ולנהל תבניות, וגם להגדיר ולפרוס אפליקציות | Platform Engineer |
משתמש ב-Application Design Center ( roles/designcenter.user |
| יצירת חשבון שירות לפריסה של אפליקציות ADC | ||
| יצירת חשבונות שירות | Platform Engineer |
יצירת חשבונות שירות ( roles/iam.serviceAccountCreator |
| הענקת גישה לחשבון שירות לפרויקט שמשמש לפריסה של ADC | Platform Engineer |
אדמין IAM בפרויקט ( roles/resourcemanager.projectIamAdmin |
| הגדרה ופריסה של אפליקציות ADC | ||
|
שליטה במחזור החיים המלא של האפליקציה (כולל שילוב עם קוד מקור ומערכות CI/CD) |
מפתחי אפליקציות |
אדמין של אפליקציות ( roles/designcenter.applicationAdmin |
| הגדרה ופריסה של אפליקציות על סמך תבניות וחיבורים קיימים שהוגדרו על ידי אדמין | מפתחי אפליקציות |
עריכת אפליקציות ( roles/designcenter.applicationEditor |
1 צריך להגדיר כמה מהתפקידים האלה בפרויקט הניהול, שהוא משאב ברמה העליונה בהיררכיית Google Cloud.
תהליך עבודה כללי
בקטע הזה מתואר תהליך עבודה כללי ליצירה של תבנית ADC ולשימוש בה. השלבים מתויגים בדמות שאותה בדרך כלל מבצעים את השלב.
- שלב 1: הגדרה של ADC (מהנדס פלטפורמה)
- שלב 2: יצירת תבנית (מהנדס פלטפורמה)
- שלב 3: שימוש בתבנית (מפתח אפליקציות)
- שלב 4: פיתוח האפליקציה בפועל (מפתח אפליקציות)
שלב 1: הגדרה של ADC (מהנדס פלטפורמה)
הדמות של מהנדס הפלטפורמה (או תפקיד גבוה יותר) משלימה את המשימות האלה כדי להגדיר את ADC. בדרך כלל צריך לבצע את המשימות האלה רק פעם אחת כדי להגדיר את הכול לשימוש ב-ADC.
הגדרה ADCראשונית.
פועלים לפי השלבים וההנחיות במדריך להגדרה הראשונית של ADC בתיעוד של Google Cloud. שימו לב: במדריך הזה אנחנו יוצאים מנקודת הנחה שתגדירו גבולות ברמת התיקייה.
אחרי שתשלימו את ההגדרה, אמור להיות לכם מרחב, שהוא אזור ייעודי שבו צוות יכול לשתף פעולה, ליצור תבניות ולפרוס אפליקציות. חשוב לוודא שהמרחב הזה (וגם התיקייה והקטלוג) משותף עם כל מי שרוצים לעבוד איתו ADC.
הגדרת הגישה והמשתמשים במרחב.
פועלים לפי השלבים במאמר ניהול משתמשים במרחבים בנושא ADC בתיעוד של Google Cloud. כדי לשלוט בגישה, פועלים לפי ההנחיות שמתוארות למעלה בדף בקטע תפקידי IAM שנדרשים לשליטה בגישה.
הקצאת פרויקטים מראש
יוצרים פרויקט חדש אחד או יותר בתיקייה Google Cloud. חשוב לוודא שמקשרים חשבון Cloud Billing לפרויקטים האלה. מפתח האפליקציה ישתמש בפרויקטים האלה כשהוא יפרוס את התשתית שמוגדרת בתבנית.
מגדירים חשבון שירות לפריסה.
ADC מנהל את הקצאת המשאבים האוטומטית באמצעות חשבון שירות עם היקף הרשאות מצומצם. כך מונעים ממפתח האפליקציה להשתמש בחשבון שלו כדי לפרוס תשתית.
ADC יכול ליצור בשמכם באופן אוטומטי חשבון שירות עם הרשאות מוגבלות, בזמן שאתם בודקים את הפריסה של התבניות שאתם יוצרים. יש לכם גם אפשרות להשתמש בחשבון שירות משלכם עם ההרשאות שאתם חושבים שמתאימות למפתחי אפליקציות.
שלב 2: יצירת תבנית (מהנדס פלטפורמה)
הפרסונה של מהנדס הפלטפורמה משתמשת בלוח העיצוב או אפילו ב-Gemini Cloud Assist כדי ליצור תבנית ADC חדשה.
הגדרת משאבים.
בשטח העיצוב, גוררים רכיבים לשטח ויוצרים ביניהם קשרים. הרכיבים האלה מאפשרים להגדיר באילו שירותי Firebase (ו-Google Cloud) רוצים שמפתחי אפליקציות ישתמשו.
לדוגמה, בתבנית אפשר להגדיר משאבים כמו אלה:
- מפתחי אפליקציות יכולים לפתח אפליקציות ל-iOS, ל-Android ולאינטרנט, שכולן משתמשות במשאבים.
- מפתחי אפליקציות יכולים להשתמש ב-Firebase AI Logic, ב-Firebase Authentication, ב-Cloud Firestore וב-Firebase Security Rules באפליקציה שלהם (רשימה של כל מוצרי Firebase שנתמכים ב-ADC).
- Firebase Security Rules מוגדרות בהתחלה לדחיית כל בקשות הגישה כברירת מחדל. לאחר מכן, כשהמפתח ישתמש בתבנית הזו לפריסה משלו, הוא יוכל לשנות את Security Rules כך שיתאימו למודל הגישה הנדרש שלו.
הגדרת כללי מדיניות
אם רוצים להגדיר מדיניות, כמו תפקידי IAM לתשתית שנפרסה או אזורים מותרים למשאבים, צריך להגדיר אותה בממשקים המתאימים. בשלב הזה, ADC לא תומך בהגדרת כללי מדיניות ברמת התבנית.
אתם יכולים להקצות תפקידים ספציפיים ב-Firebase IAM לחברי הפרויקט בהתאם לפעולות שאתם רוצים שהם יוכלו לבצע. לדוגמה, אם אתם רוצים שהם יוכלו רק לצפות במשאבים במסוף Firebase, אתם יכולים להקצות להם את התפקיד Firebase Viewer (
roles/firebase.viewer).אפשר להגדיר הגבלות אזוריות למשאבים ברמת התיקייה או הארגון.
מוסיפים את התבנית לקטלוג.
אחרי שבודקים את התבנית, מוסיפים אותה לקטלוג ADC של הצוות. צריך לשתף את הקטלוג הזה עם האנשים המתאימים, ובמיוחד עם מפתחי האפליקציות, כדי שהם יוכלו להשתמש בתבניות (ראו שלב 1: הגדרה ADC למעלה).
שלב 3: שימוש בתבנית (מפתח אפליקציות)
הדמות של מפתח האפליקציה בוחרת תבנית מוגדרת מראש, מגדירה אותה לתרחיש השימוש הספציפי שלה ואז פורסת את התשתית.
בוחרים תבנית ומגדירים אותה.
מהקטלוג ADC, בוחרים תבנית ומגדירים אותה כדי ליצור טיוטה של אפליקציה. ההגדרות הזמינות – כמו האזורים האפשריים למשאבים – מוגבלות לאלה שהוגדרו על ידי מהנדס הפלטפורמה כשהוא יצר את התבנית.
פורסים את התשתית.
אחרי שיוצרים את טיוטת האפליקציה, פורסים את האפליקציה ADC לאחד מהפרויקטים שהוקצו מראש שנוצרו לפריסת התשתית (ראו שלב 1: הגדרת ADC למעלה).
אתם יכולים להיכנס אל Firebase console ולראות את המשאבים שהוקצו ואת השירותים שהופעלו בפרויקט שלכם.
שלב 4: פיתוח האפליקציה בפועל (מפתח אפליקציות)
ADC עוזר להגדיר את Firebase וGoogle Cloud תשתית (למשל הקצאת משאבים והפעלת ממשקי API). עם זאת, הוא לא מקודד את האפליקציה בפועל שמשתמשת במשאבים ובממשקי ה-API האלה.
ריכזנו כאן כמה דברים חשובים שפיתוח אפליקציות צריך לעשות:
מקשרים את בסיס הקוד של האפליקציה ל-Firebase.
מקבלים את ההגדרה של Firebase ומוסיפים אותה לכל בסיס הקוד של האפליקציה.
לדוגמה, אם התבנית מאפשרת אפליקציית Android, צריך להוסיף את הקובץ
google-services.jsonלספרייה המתאימה בפרויקט Android.שומרים על התאמה בין הקוד למשאבים.
(אם משתמשים ב-Cloud Firestore) חשוב לעדכן ולפרסם את Firebase Security Rules כדי להתאים למודל הנתונים של האפליקציה Cloud Firestore.
מה עוד אפשר לעשות?
- מעקב אחרי ADC 'אפליקציות' שהופעלו, שנרשמות באופן אוטומטי ב-מרכז האפליקציות. כך אפשר לבצע מעקב מאוחד, לבדוק את העלויות ולפתור בעיות במשאבי Firebase בהקשר של פריסות Google Cloud רחבות יותר.