גישת מערכת למשתנים ב-Ansible

ansible devops codestyle

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

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

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

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

משתנים בתפקידים

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

קח, למשל, את התפקיד api, המתקין אפליקציית Java בשרת. אילו משתנים יש לו?

ניתן לחלק משתני תפקידים ל-2 סוגים לפי סוג:

1. Свойства
    a) независимые от среды
    б) зависимые от среды
2. Связи
    a) слушатели 
    б) запросы внутри системы
    в) запросы в среду

מאפיינים משתנים הם משתנים המגדירים את ההתנהגות של תפקיד.

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

מאזינים משתנים הם משתנים שהערך שלהם משמש ליצירת משתני שאילתה.

מצד שני, 1a, 2a, 2b הם משתנים שאינם תלויים בסביבה (ברזל, משאבים חיצוניים וכו') וניתן למלא אותם בערכי ברירת מחדל בתפקיד ברירת המחדל. עם זאת, לא ניתן למלא משתנים כמו 1.b ו-2.c בערכים מלבד 'דוגמה', מכיוון שהם ישתנו ממעמד לעמוד בהתאם לסביבה.

סגנון קוד

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

• הימנע משימוש במילונים למשתנים. Ansible לא מאפשר לך לעקוף בנוחות ערכים בודדים במילון.

  דוגמה למשתנה רע:

  myrole_user:
      login: admin
      password: admin

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

  myrole_user_login: admin
  myrole_user_password: admin

משתנים בספרי הפריסה

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

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

mydeploy                        # Каталог деплоя
├── deploy.yml                  # Плейбук деплоя
├── group_vars                  # Каталог переменных плейбука
│   ├── all.yml                 # Файл для переменных связи всей системы
│   └── myapi.yml               # Файл переменных свойств группы myapi
└── inventories                 #
    └── prod                    # Каталог окружения prod
        ├── prod.ini            # Инвентори файл
        └── group_vars          # Каталог для переменных инвентори
            └── myapi           #
                ├── vars.yml    # Средозависимые переменные группы myapi
                └── vault.yml   # Секреты (всегда средозависимы) *

* - משתנים וקמרונות

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

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

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

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

משתני נכס לקבוצות

בואו נרחיב את המודל שלנו באיור 1 על ידי הוספת 2 קבוצות של שרתים עם יישום Java שונה, אך עם הגדרות שונות.

תארו לעצמכם איך יראה ספר המשחקים במקרה זה:

- hosts: myapi
  roles:
    - api

- hosts: bbauth
  roles:
    - auth

- hosts: ghauth
  roles:
    - auth

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

קוד סגנון

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

משתני קישור

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

בהתחלה היה רעיון השתמש במבנה מפלצתי של הצורה:
hostvars[groups['bbauth'][0]]['auth_bind_port'], אבל זה ננטש מיד
כי יש לו פגמים. ראשית, הנפח. שנית, תלות במארח ספציפי בקבוצה. שלישית, יש צורך לאסוף עובדות מכל המארחים לפני תחילת הפריסה, אם אנחנו לא רוצים לקבל שגיאת משתנה לא מוגדרת.

כתוצאה מכך הוחלט להשתמש במשתני קישור.

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

משתני קישור מאוכלסים במשתני מערכת כלליים group_vars/all/vars והם נוצרים על ידי הסרת כל משתני המאזין מכל קבוצה, והוספת שם הקבוצה ממנה הוסר המאזין לתחילת המשתנה.

כך מובטחת האחידות ואי הצטלבות השמות.

בואו ננסה לאגד משתנים מהדוגמה למעלה:

תארו לעצמכם שיש לנו משתנים התלויים זה בזה:

# roles/api/defaults:
# Переменная запроса
api_auth1_address: "http://example.com:80"
api_auth2_address: "http://example2.com:80"

# roles/auth/defaults:
# Переменная слушатель
auth_bind_port: "20000"

בואו נשים את זה במשתנים נפוצים group_vars/all/vars כל המאזינים, והוסיפו את שם הקבוצה לשם:

# group_vars/all/vars
bbauth_auth_bind_port: "20000"
ghauth_auth_bind_port: "30000"

# group_vars/bbauth/vars
auth_bind_port: "{{ bbauth_auth_bind_port }}"

# group_vars/ghauth/vars
auth_bind_port: "{{ ghauth_auth_bind_port }}"

# group_vars/myapi/vars
api_auth1_address: "http://{{ bbauth_auth_service_name }}:{{ bbauth_auth_bind_port }}"
api_auth2_address: "http://{{ ghauth_auth_service_name }}:{{ ghauth_auth_bind_port }}"

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

קוד סגנון

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

קבצי סביבה

תפקידים יכולים להשתמש בקבצים שונים מסביבה לסביבה.

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

לדוגמה, אנו משתמשים במשתנה api_ssl_key_file: "/path/to/file".

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

הדרך הנוחה ביותר במקרה זה היא לשים את קובץ המפתח במאגר ספרי המשחק לאורך הנתיב
files/prod/certs/myapi.key, אז הערך של המשתנה יהיה:
api_ssl_key_file: "prod/certs/myapi.key". הנוחות טמונה בעובדה שלאנשים האחראים על פריסת המערכת על מעמד מסוים יש גם מקום ייעודי משלהם במאגר לאחסון הקבצים שלהם. יחד עם זאת, נותרת אפשרות לציין את הנתיב המוחלט לאישור בשרת, במקרה שהתעודות מסופקות על ידי מערכת אחרת.

מעמדים מרובים בסביבה אחת

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

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

מבנה הספריות הסופי עבור פרויקט הפריסה:

mydeploy                        # Каталог деплоя
├── deploy.yml                  # Плейбук деплоя
├── files                       # Каталог для файлов деплоя
│   ├── prod                    # Католог для средозависимых файлов стенда prod
│   │   └── certs               # 
│   │       └── myapi.key       #
│   └── test1                   # Каталог для средозависимых файлов стенда test1
├── group_vars                  # Каталог переменных плейбука
│   ├── all.yml                 # Файл для переменных связи всей системы
│   ├── myapi.yml               # Файл переменных свойств группы myapi
│   ├── bbauth.yml              # 
│   └── ghauth.yml              #
└── inventories                 #
    ├── prod                    # Каталог окружения prod
    │   ├── group_vars          # Каталог для переменных инвентори
    │   │   ├── myapi           #
    │   │   │   ├── vars.yml    # Средозависимые переменные группы myapi
    │   │   │   └── vault.yml   # Секреты (всегда средозависимы)
    │   │   ├── bbauth          # 
    │   │   │   ├── vars.yml    #
    │   │   │   └── vault.yml   #
    │   │   └── ghauth          #
    │   │       ├── vars.yml    #
    │   │       └── vault.yml   #
    │   └── prod.ini            # Инвентори стенда prod
    └── test                    # Каталог окружения test
        ├── group_vars          #
        │   ├── myapi           #
        │   │   ├── vars.yml    #
        │   │   └── vault.yml   #
        │   ├── bbauth          #
        │   │   ├── vars.yml    #
        │   │   └── vault.yml   #
        │   └── ghauth          #
        │       ├── vars.yml    #
        │       └── vault.yml   #
        ├── test1.ini           # Инвентори стенда test1 в среде test
        └── test2.ini           # Инвентори стенда test2 в среде test

סיכום

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

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

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

ספרות

1. רשומות

מחבר

קלוז'ני דניס אלכסנדרוביץ'

מקור: www.habr.com