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

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

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

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

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

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

איך פועל App Lifecycle Manager?

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

למידע נוסף על המינוח של App Lifecycle Manager, קראו את מילון המונחים.

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

לפני שפורסים את האפליקציה, מומלץ לקבוע את הסידור האידיאלי של האפליקציה בסביבה של App Lifecycle Manager.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

חשבון שירות של 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:

  • שם: 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.
  • אם אתם יוצרים מכונות של Cloud SQL באמצעות Terraform, לחשבון השירות צריכים להיות התפקידים המתאימים של Cloud SQL (לדוגמה, roles/cloudsql.admin).

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

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

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

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

יצירה ידנית של ארטיפקטים

אם אתם יוצרים ומעלים את פריטי המידע שנוצרו באופן ידני ב-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.
  • כל הרשאה אחרת שנדרשת לתהליך ה-build (לדוגמה, גישה למאגרים של קוד מקור).

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

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

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

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

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

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

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

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

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

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

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

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

התאמה לאזור של App Lifecycle Manager

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

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

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

  • האפליקציה (Saas)
  • סוג היחידה (UnitKind)
  • שחרור (Release)

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

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

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

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

ההשקות קוראות את רשימת האזורים הזמינים מהאפליקציה המשויכת.

שכפול משאבים

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

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

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

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

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

  • האזור של מאגר Artifact Registry ושל המכונה של Developer Connect יכול להיות כל אזור חוקי של Google Cloud . הם לא צריכים להיכלל באזורים שבהם האפליקציה זמינה.

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

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

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

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

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

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

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

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

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