משתנים ומיפוי משתנים ב-App Lifecycle Manager

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

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

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

יחידות ומשתנים

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

משתנים שחובה להזין כדי להקצות יחידות

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

המשתנים שחובה לציין הם:

  • ‫project_id ו-project_number (או tenant_project_id ו-tenant_project_number): המשתנה הזה מציין את Google Cloud מזהה הפרויקט Google Cloud שבו ייפרסו המשאבים של היחידה. אפשר להשתמש ב-project_id וב-project_number, או ב-tenant_id וב-tenant_project_number. השדה הזה נחוץ ליצירה ולניהול של משאבים בפרויקט הנכון Google Cloud .

    מזהה הפרויקט מופיע במסוף Google Cloud בדף Dashboard. מחפשים את השדה מזהה הפרויקט בכרטיס פרטי הפרויקט בקטע סקירה כללית של Cloud.

  • ‫project_number או tenant_project_number: משתנה דומה ל-project_id, שמייצג את מספר הפרויקט Google Cloud . אפשר להשתמש ב-project_number או ב-tenant_project_number לסירוגין.

    מספר הפרויקט מופיע לצד מזהה הפרויקט בכרטיס Project info בקטע Cloud overview ב Google Cloud לוח הבקרהבמסוף.

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

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

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

היררכיית משתני יחידה

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

סדר העדיפות הוא כדלקמן (מהנמוך ביותר לגבוה ביותר):

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

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

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

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

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

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

יחסי תלות בין יחידות

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

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

הגדרת תלות בסוג היחידה

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

  message UnitKind {
    // ... other fields ...

    // List of other unit kinds that this release will depend on.
    repeated Dependency dependencies = 4
        [(.google.api.field_behavior) = OPTIONAL];
    // ...
  }

  message Dependency {
    // The unit kind of the dependency.
    string unit_kind = 1 [
      (.google.api.field_behavior) = REQUIRED,
      (.google.api.field_behavior) = IMMUTABLE,
      (.google.api.resource_reference) = {
        type: "saasservicemgmt.googleapis.com/UnitKind"
      }
    ];

    // An alias for the dependency. Used for input variable mapping.
    string alias = 2 [(.google.api.field_behavior) = REQUIRED];
  }

הקצאת הרשאות אוטומטית לתלות

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

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

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

מיפוי משתנים

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

מיפוי המשתנים מוגדר בסוג היחידה התלויה ומשתמש ב-FromMapping וב-ToMapping:

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

    message VariableMapping {
  // ...
  oneof mapping_type {
    // Output variables which will get their values from dependencies
    FromMapping from = 2 [(.google.api.field_behavior) = OPTIONAL];
    // ...
  }
}

message FromMapping {
  // Alias of the dependency that the outputVariable will pass its value to
  string dependency = 1 [(.google.api.field_behavior) = REQUIRED];

  // Name of the outputVariable on the dependency
  string output_variable = 2 [(.google.api.field_behavior) = REQUIRED];
}

    בדוגמה של ה-Codelab שצוינה למעלה, ל-App UnitKind יש FromMapping כדי לאחזר את משתנה הפלט cluster_endpoint מהתלות Cluster UnitKind. כך האפליקציה יכולה להתחבר לאשכול Kubernetes החדש שהוקצה.

  • ‫ToMapping: ToMapping משמש להעברת משתני קלט מיחידה תלויה למשתני הקלט של יחידת תלות. כך תוכלו להגדיר יחידות תלויות על סמך פרמטרים שסופקו ליחידה התלויה.

    message VariableMapping {
  // ...
  oneof mapping_type {
    // ...
    // Input variables whose values will be passed on to dependencies.
    ToMapping to = 3 [(.google.api.field_behavior) = OPTIONAL];
  }
}

message ToMapping {
  // Alias of the dependency that the inputVariable will pass its value to
  string dependency = 1 [(.google.api.field_behavior) = REQUIRED];

  // Name of the inputVariable on the dependency
  string input_variable = 2 [(.google.api.field_behavior) = REQUIRED];

  // Tells EasySaaS if this mapping should be used during lookup or not
  bool ignore_for_lookup = 3 [(.google.api.field_behavior) = OPTIONAL];
}

    ב-codelab, ‏ App UnitKind משתמש ב-ToMapping כדי להעביר את משתני הקלט tenant_project_id ו-tenant_project_number לתלות Cluster UnitKind. כך מוודאים שאשכול Kubernetes נוצר בפרויקט הנכון.

  • ‫ignore_for_lookup ב-ToMapping: השדה ignore_for_lookup ב-ToMapping שולט בהתנהגות של חיפוש תלות. זהו ערך בוליאני:

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

דוגמה: אשכול Kubernetes משותף

אם רוצים לעשות שימוש חוזר באותו אשכול Kubernetes לכמה יחידות אפליקציה באותו פרויקט, צריך להשתמש ב-ToMapping עם ignore_for_lookup שמוגדר ל-false ולמפות משתנים כמו tenant_project_id ו-region לסוג יחידת האשכול. יחידות באותו פרויקט ובאותו אזור ישתמשו באותו אשכול.

דוגמה: אשכול Kubernetes ייעודי לכל אפליקציה

אם אתם צריכים אשכול Kubernetes ייעודי לכל יחידת אפליקציה, אתם יכולים להשתמש ב-ToMapping עם ignore_for_lookup שמוגדר ל-true, או להימנע לחלוטין משימוש במשתני חיפוש של ToMapping. כל יחידת אפליקציה תפעיל הקצאה של אשכול Kubernetes חדש ומבודד.

ניהול סודות

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

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

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