משתנים ומיפוי משתנים ב-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 מזהה הפרויקט שבו ייפרסו המשאבים של היחידה. אפשר להשתמש ב-project_id וב-project_number, או ב-tenant_id וב-tenant_project_number. השדה הזה נחוץ ליצירה ולניהול של משאבים בפרויקט הנכון Google Cloud .

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

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

    מספר הפרויקט מופיע לצד מזהה הפרויקט בכרטיס Project info, בקטע Cloud overview בדף Dashboard במסוף 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 משמש לאחזור משתני פלט מיחידת תלות ולמיפוי שלהם למשתני קלט של היחידה התלויה. כך יחידה תלויה יכולה לקבל מידע מהתלויות שלה, כמו נקודות קצה (endpoint) של חיבורים או מזהי משאבים.

    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.

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