סקירה כללית של 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 Design Center, והשינויים יופיעו בהצעות לאפליקציות ב-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.

מחליפים את:

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

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

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

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

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

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

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

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

    my-actuation-sa@my-identifier.

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

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

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