איך להגדיר את Deployment Manager לשימוש נרחב

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

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

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

לפני שמתחילים

• אם רוצים להשתמש בדוגמאות לשורת הפקודה במדריך הזה, צריך להתקין את כלי שורת הפקודה`gcloud`.
• כדי להשתמש בדוגמאות ל-API במדריך הזה, צריך להגדיר גישה ל-API.

סביבות מרובות עם בסיס קוד יחיד

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

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

תבנית	הגדרה היררכית ללא יתירות	הגדרה יחידה עם יתירות
project_config.py	config = { 'ProjectId': 'qwerty123456', 'ProjectOwner': 'Bob', 'ProjectAbbrevation': 'SNP' }	לא רלוונטי
frontend_config.py	config = {'ServiceName': 'frontend'}	config = { 'ProjectId': 'qwerty123456', 'ProjectOwner': 'Bob', 'ProjectAbbrevation': 'SNP', 'ServiceName': 'frontend' }
backend_config.py	config = {'ServiceName': 'backend'}	config = { 'ProjectId': 'qwerty123456', 'ProjectOwner': 'Bob', 'ProjectAbbrevation': 'SNP', 'ServiceName': 'backend' }
db_config.py	config = {'ServiceName': 'db'}	config = { 'ProjectId': 'qwerty123456', 'ProjectOwner': 'Bob', 'ProjectAbbrevation': 'SNP', 'ServiceName': 'db' }

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

למבנה היררכי של הקוד יש כמה יתרונות:

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

הגדרת מבנה היררכי לבסיס הקוד

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

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

התייחסות לתשתית כמו לקוד אמיתי

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

כדי ליצור בסיס קוד קל יותר עם קובצי תצורה קטנים ומינימום כפילויות, כדאי להשתמש בהנחיות האלה כדי לבנות את התצורות לפי העיקרון DRY (Don't Repeat Yourself).

ארגונים, מחלקות, סביבות ומודולים

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

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

ברשימה הבאה, המספרים מייצגים את סדר הדריסות:

1. מאפיינים ארגוניים

   זו הרמה הכי גבוהה במבנה. ברמה הזו אפשר לאחסן מאפייני תצורה כמו organization_name ו-organization_abbreviation, שבהם אתם משתמשים במוסכמת השמות שלכם, ופונקציות עזר שאתם רוצים לשתף ולאכוף בכל הצוותים.

2. מאפייני מחלקה

   בארגונים יש מחלקות, אם יש מחלקות במבנה שלכם. בכל קובץ תצורה של מחלקה, משתפים נכסים שלא נמצאים בשימוש של מחלקות אחרות, למשל department_name או cost_center.

3. מאפייני מערכת (פרויקט)

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

   ברמת המערכת, לצוות שלכם יש הרבה יותר אוטונומיה מאשר ברמות שמעליו. כאן אפשר להגדיר פונקציות עזר (כמו project_name_generator(),‏ instance_name_generator() או instance_label_generator()) לפרמטרים ברמת הצוות והמערכת (לדוגמה, system_name,‏ default_instance_size או naming_prefix).

4. מאפייני סביבה

   במערכת שלכם כנראה יש כמה סביבות, כמו Dev, Test או Prod (ואולי גם QA ו-Staging), שדי דומות זו לזו. מומלץ להשתמש באותו codebase, וההבדלים ביניהם יהיו רק ברמת ההגדרה. ברמת הסביבה, אפשר לשנות מאפיינים כמו default_instance_size עבור ההגדרות Prod ו-QA.

5. מאפייני מודולים

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

6. מאפייני מודול ספציפיים לסביבה

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

מחלקת עזר למיזוג הגדרות

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

כדי להשתמש בכיתה config_merger, צריך לספק את הפרטים הבאים:

• שם המודול.
• ההקשר הגלובלי, שמכיל את שם הסביבה.

קריאה לפונקציה הסטטית ConfigContext מחזירה את מילון ההגדרות הממוזג.

בדוגמה הבאה אפשר לראות איך משתמשים במחלקה הזו:

• התג module = "frontend" מציין את ההקשר שאליו נטענים קובצי המאפיינים.
• הסביבה נבחרת אוטומטית מתוך context.properties["envName"].

• ההגדרה הגלובלית.

  cc = config_merger.ConfigContext(context.properties, module)
  
  print cc.configs['ServiceName']
  

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

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

בבסיס הקוד לדוגמה יש שלושה קובצי הגדרות עם קידוד קשיח:

• org_config.py
• department_config.py
• system_config.py

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

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

• envs/[environment name].py
• [environment name]/[module name].py
• modules/[module name].py

קובץ תצורה

‫Deployment Manager משתמש בקובץ תצורה אחד, שהוא קובץ יחיד לפריסה ספציפית. אי אפשר לשתף אותו בין פריסות.

כשמשתמשים במחלקה config-merger, מאפייני ההגדרה מנותקים לחלוטין מקובץ ההגדרה הזה כי לא משתמשים בו. במקום זאת, משתמשים באוסף של קובצי Python, שמאפשר גמישות רבה יותר בפריסה. אפשר גם לשתף את הקבצים האלה בין פריסות.

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

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

config = {
    'Zip_code': '1234'
    'Count': '3'
    'project_module': {
        'admin': 'Joe',
    }
}

config = {
    'Zip_code': '5555'
    'Count': '5'
    'project_module_prod': {
        'admin': 'Steve',
    }
}

מחלקות עזר ומוסכמות למתן שמות

מוסכמות למתן שמות הן הדרך הטובה ביותר לשמור על שליטה בתשתית שלכם ב-Deployment Manager. לא כדאי להשתמש בשמות כלליים או לא ברורים, כמו my project או test instance.

הדוגמה הבאה היא מוסכמת מתן שמות למופעים ברמת הארגון:

def getInstanceName(self, name):
  return '-'.join(self.configs['Org_level_configs']['Org_Short_Name'],
                  self.configs['Department_level_configs']['Department_Short_Name'],
                  self.configs['System_short_name'],
                  name,
                  self.configs["envName"])

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

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

מבנה התיקיות של בסיס הקוד לדוגמה

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

├── global
│   ├── configs
│   └── helper
└── systems
    └── my_ecom_system
        ├── configs
        │   ├── dev
        │   ├── envs
        │   ├── modules
        │   ├── prod
        │   └── test
        ├── helper
        └── templates
    

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

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

├── configs
│   ├── Department_Data_config.py
│   ├── Department_Finance_config.py
│   ├── Department_RandD_config.py
│   └── org_config.py
└── helper
    ├── config_merger.py
    └── naming_helper.py

תיקיית המערכות מכילה מערכת אחת או יותר. המערכות מופרדות זו מזו, והן לא משתפות הגדרות.

├── configs
│   ├── dev
│   ├── envs
│   ├── modules
│   ├── prod
│   └── test
├── helper
└── templates

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

├── department_config.py -> ../../../global/configs/Department_Data_config.py
├── org_config.py -> ../../../global/configs/org_config.py
├── system_config.py
├── dev
│   ├── frontend.py
│   └── project.py
├── prod
│   ├── frontend.py
│   └── project.py
├── test
│   ├── frontend.py
│   └── project.py
├── envs
│   ├── dev.py
│   ├── prod.py
│   └── test.py
└── modules
    ├── frontend.py
    └── project.py

Org_config.py:

config = {
  'Org_level_configs': {
    'Org_Name': 'Sample Inc.',
    'Org_Short_Name': 'sampl',
    'HQ_Address': {
      'City': 'London',
      'Country': 'UK'
    }
  }
}

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

├── config_merger.py -> ../../../global/helper/config_merger.py
└── naming_helper.py -> ../../../global/helper/naming_helper.py

בתיקיית התבניות אפשר לאחסן תבניות של Deployment Manager או להפנות אליהן. גם קישורים סמליים פועלים כאן.

├── project_creation -> ../../../../../../examples/v2/project_creation
└── simple_frontend.py

שיטות מומלצות

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

קובצי סכימה

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

• מחלקות עזר:

- path: helper/*.py

• קובצי הגדרות:

- path: configs/*.py
- path: configs/*/*.py

• ייבוא בכמות גדולה (בסגנון glob)

gcloud config set deployment_manager/glob_imports True

פריסות מרובות

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

קישורים סימבוליים

קישורים סמליים נתמכים בפקודות gcloud deployment-manager, וקבצים מקושרים נטענים בצורה תקינה. עם זאת, לא כל מערכות ההפעלה תומכות בקישורים סמליים.

היררכיית ההגדרות

בתרשים הבא מוצג סקירה כללית של הרמות השונות והקשרים ביניהן. כל מלבן מייצג קובץ מאפיינים, כפי שמצוין בשם הקובץ באדום.

סדר מיזוג מבוסס הקשר

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

בתרשים הבא, המספרים מייצגים את סדר הדריסה בהיררכיה:

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

• דוגמאות נוספות לפריסות זמינות במאגר GitHub של Deployment Manager.
• מידע נוסף על תבניות ועל פריסות