סקירה כללית של App Lifecycle Manager

הכלי App Lifecycle Manager מאפשר לכם לאחסן, לארח, לנהל ולנטר אפליקציות של תוכנה כשירות (SaaS) ב- Google Cloud. הכלי App Lifecycle Manager מנהל פריסות של Terraform בהיקף נרחב, ומאפשר לכם לנהל גם את אפליקציית ה-SaaS וגם את התשתית שהיא פועלת עליה.

בעלי עניין שונים בצינור ה-SaaS יכולים להשתמש ב-App Lifecycle Manager בדרכים רבות. אם אתם מזהים את עצמכם באחד מהתפקידים האלה, כדאי לכם להשתמש בכלי לניהול מחזור החיים של אפליקציות:

  • אדמין בפלטפורמה
  • מפַתח אפליקציות
  • אדריכל
  • אדמין תאימות
  • מהנדס/ת פלטפורמה
  • פעולות פיננסיות

היתרונות של App Lifecycle Manager:

  • כדי לפשט את ניהול השירותים בהיקף גדול, אפשר להפוך לאוטומטיות משימות של ניהול שירותים (כמו פריסה, השקה וניהול של תכונות חדשות) בכל הדיירים של SaaS.
  • הרחיבו את יכולות הבקרה והמעקב שלכם על ידי כוונון מדויק של העדכונים וההפצות שלכם ביחידות שניתנות להגדרה, כדי לנהל את פתרון ה-SaaS שלכם בדיוק רב ובקנה מידה גדול.
  • כדי ליצור עקביות במערכת האקולוגית שלכם, אתם יכולים לנהל שירותים במגוון מוצרים של Google Cloud , כולל Google Distributed Cloud, חיוב, יכולת צפייה ומנהל המשאבים. Google Cloud Google Cloud
  • משתמשים בארכיטקטורה גמישה שניתנת ליצירת תבניות, ומקדמת עדכונים ופריסות של קבוצות שמבוססים על יחידות, כדי לשפר את היעילות ואת האפשרות לשימוש חוזר.

איך פועל App Lifecycle Manager

‫App Lifecycle Manager פורס ארטיפקטים שמגדירים את חבילת ה-SaaS שלכם. לפריטים האלה צריך להיות קובץ הגדרה של Terraform. הפריסה מאורגנת ביחידות נפרדות שאפשר לעדכן באמצעות גרסאות שמכילות שינויים במוצר שלכם, בתהליך השקה שניתן להגדרה.

מידע נוסף על המינוח של App Lifecycle Manager זמין במילון המונחים.

הכנת עומס העבודה ל-App Lifecycle Manager

לפני שמפיצים את פתרון ה-SaaS, מומלץ לקבוע את המיקום האידיאלי של פתרון ה-SaaS במערכת האקולוגית של App Lifecycle Manager.

כדאי לארגן חלקים של מוצר ה-SaaS שצריך לעדכן או לשנות יחד בתצורות נפרדות של Terraform. כשמתכננים את חבילת ה-SaaS, משתמשים בסוגי יחידות לכל קבוצה של חבילת ה-SaaS.

אחרי שתגדירו את המבנה האידיאלי של עומס העבודה ב-App Lifecycle Manager, תוכלו ליצור את מוצר ה-SaaS, את סוגי היחידות ואז לפרוס את היחידות באמצעות השקה.

דוגמה להגדרה של App Lifecycle Manager מופיעה במדריך למתחילים.

שימוש בתבניות מורכבות עם App Lifecycle Manager

אתם יכולים להשתמש בתבניות מורכבות דרך Application Design Center כדי להגדיר את התשתית של מוצרי האפליקציה של App Lifecycle Manager.

אחרי שמצרפים תבנית מורכבת למוצר ה-SaaS, App Lifecycle Manager מאכלס את סוגי היחידות שהוגדרו בתבנית. כך תוכלו לפרוס יחידות על סמך המבנה והמשאבים שמוגדרים בתבנית המורכבת.

אתם יכולים לערוך את התבניות המורכבות ב-App Design Center ולראות את השינויים שמתבצעים במוצרי ה-SaaS של App Lifecycle Manager.

מידע נוסף על תבניות מורכבות זמין במאמר תכנון תבניות מורכבות. מידע נוסף על צירוף תבניות מורכבות למוצרים של App Lifecycle Manager זמין במאמר יצירת מודלים של יחידות פריסה ואריזת יחידות פריסה.

חשבונות שירות של App Lifecycle Manager

‫App Lifecycle Manager משתמש בשילוב של חשבונות שירות בניהול Google וחשבונות שירות בניהול המשתמש:

  • חשבון שירות של App Lifecycle Manager (בניהול Google): החשבון הזה נוצר באופן אוטומטי אחרי שיוצרים את משאב המוצר הראשון מסוג SaaS. הוא מנוהל על ידי Google. הוא מבצע פעולות בשמכם, כמו אינטראקציה עם שירותים אחרים של Google Cloud במהלך הקצאת יחידות.

  • חשבון שירות להפעלת תהליכים (בניהול המשתמש): אתם יוצרים ומנהלים את חשבון השירות הזה. הכלי App Lifecycle Manager (דרך Infrastructure Manager) משתמש בחשבון הזה כדי להריץ את ההגדרות של Terraform כשמקצים או מעדכנים יחידות. החשבון הזה משמש כזהות ליצירה ולניהול של המשאבים שמוגדרים ב-Terraform. ההרשאות של חשבון השירות להפעלת המשאבים קשורות ישירות למשאבים שמנוהלים על ידי ההגדרות של Terraform.

    יכולים להיות לכם כמה חשבונות שירות להפעלת המכשיר. מומלץ להגדיר חשבון שירות אחד להפעלת תהליכים לכל דייר.

  • אופציונלי: חשבון שירות ליצירת ארטיפקטים (בניהול המשתמש): חשבון השירות הזה משמש לבנייה ולהעלאה של חבילת Terraform לארטיפקטים של OCI. בדרך כלל זהו חשבון שירות של Cloud Build, אבל יכול להיות שזה חשבון שירות אחר עם הרשאות מתאימות למוצר ה-SaaS שלכם.

חשבון שירות של App Lifecycle Manager (בניהול Google)

חשבון השירות של App Lifecycle Manager הוא סוכן שירות שמנוהל על ידי Google ומשמש את App Lifecycle Manager לביצוע פעולות בפרויקט שלכם.

חשבון השירות הזה מוקצה באופן אוטומטי כשיוצרים את המשאב הראשון של App Lifecycle Manager. חשבון השירות של App Lifecycle Manager נוצר בפורמט הבא:

  service-PROJECT_NUMBER@gcp-sa-saasservicemgmt.iam.gserviceaccount.com

מחליפים את:

  • ‫PROJECT_NUMBER: מספר הפרויקט.

חשבון שירות להפעלת תכונות (בניהול המשתמש)

חשבון השירות להפעלת התהליך הוא חשבון שירות שמנוהל על ידי משתמש, ואתם צריכים ליצור אותו. ‫App Lifecycle Manager (באמצעות Infra Manager) משתמש בחשבון השירות הזה כדי להריץ את ההגדרות של Terraform. זוהי הזהות שיוצרת, משנה ומוחקת את המשאבים שמוגדרים ב-Terraform.

אתם אחראים ליצירת חשבון השירות הזה בפרויקט שלכם או בפרויקט הדייר.

משתני קלט של חשבון שירות להפעלת תהליכים

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

  • Name (שם): actuation_sa
  • סוג המשתנה: String

  • משתנה: כתובת האימייל בחשבון השירות של ההפעלה:

    my-actuation-sa@my-identifier.iam.gserviceaccount.com

ההרשאות הנדרשות

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

  • ‫roles/iam.serviceAccountTokenCreator: מאפשרת לחשבון השירות ליצור אסימונים לאימות.
  • ‫roles/config.admin: מעניק שליטה מלאה במשאבי Infra Manager.
  • ‫roles/storage.admin: מעניק שליטה מלאה ב-Cloud Storage.

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

לדוגמה:

  • אם Terraform יוצר אשכולות של Google Kubernetes Engine‏ (GKE), לחשבון השירות צריכים להיות תפקידים מתאימים ב-GKE (לדוגמה, roles/container.admin).
  • אם Terraform יוצרת מכונות של Compute Engine, לחשבון השירות צריך להיות מוקצה התפקיד roles/compute.admin.
  • אם Terraform יוצר מופעים של Cloud SQL, לחשבון השירות צריכים להיות התפקידים המתאימים ב-Cloud SQL (לדוגמה, roles/cloudsql.admin).

כדי לדעת אילו הרשאות נדרשות, צריך לעיין בתיעוד של כל משאב Google Cloud שמשתמשים בו ב-Terraform. צריך להעניק את ההרשאות המינימליות שנדרשות כדי שהאפליקציה תפעל.

חשבון שירות ליצירת ארטיפקטים (בניהול המשתמש)

חשבון השירות ליצירת ארטיפקטים הוא חשבון שירות בניהול המשתמשים שאתם יוצרים כדי להשתמש במערכת build (כמו Cloud Build) לאריזה ולהעלאה של ארטיפקטים של Terraform אל Artifact Registry.

חשבון השירות הזה נפרד מחשבונות השירות של App Lifecycle Manager ושל שירות ההפעלה. הוא יוצר את קוד Terraform ושולח את הארטיפקט שנוצר אל Artifact Registry. לרוב, זהו חשבון השירות של Cloud Build.

יצירה ידנית של פריטים מידע שנוצרו בתהליך פיתוח (Artifact)

אם אתם יוצרים ומעלים את ארטיפקטים של Terraform באופן ידני (למשל, באמצעות Docker build ו-Docker push ישירות), אתם לא צריכים חשבון שירות נפרד ליצירת ארטיפקטים.

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

ההרשאות הנדרשות

אם אתם משתמשים ב-Cloud Build, חשבון השירות של Cloud Build בדרך כלל צריך את התפקידים הבאים:

  • ‫roles/artifactregistry.writer: כדי לשלוח פריטי מידע שנוצרו בתהליך פיתוח (Artifact) אל Artifact Registry.
  • ‫roles/artifactregistry.repoAdmin: כדי לנהל את מאגר Artifact Registry.
  • ‫roles/storage.admin: כדי לנהל את הקטגוריות של Cloud Storage.
  • ‫roles/developerconnect.admin: הרשאות לשימוש ב-Developer Connect.
  • ‫roles/developerconnect.readTokenAccessor: הרשאות לקבלת אסימון קריאה של Developer Connect.
  • ‫roles/logging.logWriter: הרשאות לכתיבת יומנים.
  • אם אתם פורסים את ההגדרות של Terraform באמצעות Developer Connect: ‫roles/cloudbuild.builds.builder: להפעלת בנייה.
  • כל הרשאה אחרת שנדרשת בתהליך build (למשל, גישה למאגרי קוד מקור).

אסטרטגיות השקה

App Lifecycle Manager משתמש בכמה אסטרטגיות השקה כדי לנהל את אופן העדכון של יחידות במוצר ה-SaaS שלכם. אסטרטגיות ההשקה האלה פועלות לפי הגישה שלGoogle Cloudלשינויים, ומיישמות גישות עקביות לפריסת שינויים במוצר ה-SaaS.

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

  • מיקום אחד בכל פעם (פשוט): מיקום אחד מושק בכל פעם, ללא המתנה בין המיקומים. היחידות נבחרות באופן שרירותי בתוך מיקום, עם עד 5% מהיחידות במיקום שעודכנו בזמן נתון.

    האסטרטגיה הזו מומלצת לסביבות פיתוח ולתרחישי חירום.

  • הפצה בבת אחת (פשוטה): ההפצה מתחילה בכל המיקומים בו-זמנית.

    האסטרטגיה הזו מומלצת לסביבות פיתוח ולתרחישי חירום.

  • הדרגתי: בכל מיקום, הפריסה מתבצעת בקבוצות סטטיות שמבוססות על אחוזים (לדוגמה, 1%, ‏ 10%, ‏ 20%, ‏ 30%, ‏ 40% בערך) עם תקופות הרצה בין קבוצות. ההשקה מתקדמת במיקומים שונים עם עלייה אקספוננציאלית במספר המיקומים בו-זמנית (לדוגמה, מיקום אחד, אחר כך שניים, אחר כך ארבעה) עם תקופות הרצה (לדוגמה, 18 שעות) בין גלי ההשקה. היחידות במיקום נבחרות באופן אקראי.

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

  • הדרגתי (מיקום יחיד): היחידות מתעדכנות בקבוצות סטטיות שמבוססות על אחוזים (לדוגמה, 1%,‏ 10%,‏ 20%,‏ 30%,‏ 40% בערך) עם תקופות הרצה ארוכות יותר (לדוגמה, 18 שעות) בין קבוצות, כדי לאפשר מספיק זמן לזיהוי בעיות ולהגביל את ההשפעה השלילית של שינויים בהשקה.

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

מידע נוסף על יצירת סוגי השקה זמין במאמר יצירת סוג השקה.

אזורים שבהם זמין App Lifecycle Manager

משאבי המוצר SaaS מגדירים איפה יכולות להיות יחידות App Lifecycle Manager ואיך מתבצע ניהול ההשקות. כשיוצרים מוצר SaaS, האזורים שבוחרים משמשים כמקור אמת יחיד לאזורים הנתמכים של מוצר ה-SaaS. האזורים שאתם בוחרים הם האזורים הזמינים שהגדרתם למוצר ה-SaaS שלכם.

כשמשתמשים ב-App Lifecycle Manager דרך מסוף Google Cloud , הוא מבצע אוטומטית שכפול של המשאבים שמוגדרים במוצר ה-SaaS באזורים שונים. כך מובטחת עקביות וזמינות של משאבי App Lifecycle Manager בכל האזורים הזמינים שהגדרתם במוצר ה-SaaS שלכם.

הכלי App Lifecycle Manager משכפל את המשאבים הבאים:

  • מוצר SaaS (Saas)
  • סוג היחידה (UnitKind)
  • גרסה (Release)

שימוש ב-global כאזור

בדרך כלל לא מומלץ לכלול את global כאזור במוצר ה-SaaS שלכם כיעד פריסה. ‫App Lifecycle Manager משתמש באזור global כדי להפיץ השקות אזוריות. אי אפשר להפעיל השקות אזוריות באזור global.

השקה לפי אזורים

המיקומים הנתמכים להשקות נקבעים לפי האזורים ברמה העליונה שמוגדרים באזורים הזמינים של מוצר ה-SaaS שלכם.

במהלך ההשקה, המערכת קוראת את רשימת האזורים הזמינים מהצעת ה-SaaS המשויכת.

שכפול משאבים

הכלי App Lifecycle Manager מטפל ביצירה ובעדכונים של משאבים בכל האזורים שבהם מוצע פתרון ה-SaaS שלכם.

כשמעדכנים את האזורים הזמינים של מוצר ה-SaaS, ה-App Lifecycle Manager מטפל בשכפול:

  • מיקומים נוספים: המשאבים משוכפלים למיקומים החדשים שנוספו.
  • מיקומים עם עותקים ישנים: התוכן עודכן.

מיקומים של Artifact Registry ו-Developer Connect

יש דרישות ספציפיות לגבי המיקומים של מאגר Artifact Registry ומופע Developer Connect:

  • האזור של מאגר Artifact Registry ומופע Developer Connect יכול להיות כל אזור תקף Google Cloud . אין צורך לכלול אותם באזורים הזמינים של מוצר ה-SaaS שלכם.

  • האזור של מאגר Artifact Registry חייב להיות זהה לאזור של מופע Developer Connect.

    לכן, צריך שיהיו משאבים מסוג SaaS offering, ‏ release ו-unit kind בכל האזורים שמוגדרים ב-SaaS offering, גם אם Artifact Registry ו-Developer Connect נמצאים באזור אחד (שיכול להיות שונה).

  • אפשר ליצור יחידות רק באזורים שצוינו בחבילת ה-SaaS שלכם.

דוגמה להגדרת אזורים ב-App Lifecycle Manager

הדוגמה הזו נועדה להדגים איך אזוריזציה פועלת כשמשתמשים ב-App Lifecycle Manager עם שכפול מנוהל של משאבים.

לדוגמה, אם רוצים לפרוס את פתרון ה-SaaS ב-us-central1 וב-europe-west4, ולארח את מאגר Artifact Registry ואת מופע Developer Connect ב-us-east1, התשתית של אזורי App Lifecycle Manager תיראה כך:

  • אזורים שבהם אפשר להשתמש בפתרון SaaS: ['us-central1', 'europe-west4']
  • האזור של Artifact Registry repository: us-east1
  • האזור של מופע Developer Connect: us-east1
  • משאבים מסוג יחידה וגרסה: App Lifecycle Manager מנהל את היצירה והעדכונים של המשאבים האלה באזורים global, us-central1 ו-europe-west4
  • יחידות: אפשר ליצור יחידות ב-us-central1 או ב-europe-west4

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

המאמרים הבאים