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

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

מידע בסיסי

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

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

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

מבוא למניפסטים

בטרמינולוגיה של בובות לשרת הבובות מחוברים צמתים (צמתים). התצורה של הצמתים כתובה במניפסטים בשפת תכנות מיוחדת - Puppet DSL.

Puppet DSL היא שפה הצהרתית. הוא מתאר את המצב הרצוי של הצומת בצורה של הצהרות על משאבים בודדים, למשל:

• הקובץ קיים ויש לו תוכן ספציפי.
• החבילה מותקנת.
• השירות התחיל.

ניתן לקשר בין משאבים:

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

בנוסף, ל-Puppet DSL יש פונקציות ומשתנים, כמו גם הצהרות ובוררים מותנים. גם מנגנוני תבניות שונים נתמכים - EPP ו-ERB.

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

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

תחביר וסגנון קוד

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

• תחביר של מבני שפה שונים.
• תחביר משאבים.
• תחביר לתיאור צמתים.

הנה דוגמה איך נראה המניפסט:

# Комментарии пишутся, как и много где, после решётки.
#
# Описание конфигурации ноды начинается с ключевого слова node,
# за которым следует селектор ноды — хостнейм (с доменом или без)
# или регулярное выражение для хостнеймов, или ключевое слово default.
#
# После этого в фигурных скобках описывается собственно конфигурация ноды.
#
# Одна и та же нода может попасть под несколько селекторов. Про приоритет
# селекторов написано в статье про синтаксис описания нод.
node 'hostname', 'f.q.d.n', /regexp/ {
  # Конфигурация по сути является перечислением ресурсов и их параметров.
  #
  # У каждого ресурса есть тип и название.
  #
  # Внимание: не может быть двух ресурсов одного типа с одинаковыми названиями!
  #
  # Описание ресурса начинается с его типа. Тип пишется в нижнем регистре.
  # Про разные типы ресурсов написано ниже.
  #
  # После типа в фигурных скобках пишется название ресурса, потом двоеточие,
  # дальше идёт опциональное перечисление параметров ресурса и их значений.
  # Значения параметров указываются через т.н. hash rocket (=>).
  resource { 'title':
    param1 => value1,
    param2 => value2,
    param3 => value3,
  }
}

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

• כניסות שני רווחים, לא נעשה שימוש בטאבים.
• פלטה מתולתלת מופרדת על ידי רווח; נקודתיים אינם מופרדים על ידי רווח.
• פסיקים אחרי כל פרמטר, כולל האחרון. כל פרמטר נמצא בשורה נפרדת. נעשה חריג למקרה ללא פרמטרים ופרמטר אחד: ניתן לכתוב בשורה אחת וללא פסיק (כלומר. resource { 'title': } и resource { 'title': param => value }).
• החצים על הפרמטרים צריכים להיות באותה רמה.
• לפניהם נכתבים חיצים ליחסי משאבים.

מיקום הקבצים ב-pappetserver

להסבר נוסף, אציג את המושג "ספריית שורש". ספריית השורש היא הספרייה המכילה את תצורת Puppet עבור צומת ספציפי.

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

• בגרסה השלישית ("בובה הישנה") ספריית הבסיס הייתה /etc/puppet. השימוש בסביבות הוא אופציונלי - למשל, אנחנו לא משתמשים בהן עם Puppet הישן. אם נעשה שימוש בסביבות, הן מאוחסנות בדרך כלל ב /etc/puppet/environments, ספריית השורש תהיה ספריית הסביבה. אם לא נעשה שימוש בסביבות, ספריית הבסיס תהיה ספריית הבסיס.
• החל מהגרסה הרביעית ("בובה חדשה"), השימוש בסביבות הפך לחובה, וספריית הבסיס הועברה ל- /etc/puppetlabs/code. בהתאם לכך, סביבות מאוחסנות ב /etc/puppetlabs/code/environments, ספריית שורש היא ספריית הסביבה.

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

לקבצי מניפסט יש את הסיומת .pp.

כמה דוגמאות לחימה

תיאור הצומת והמשאב עליו

על הצומת server1.testdomain יש ליצור קובץ /etc/issue עם תוכן Debian GNU/Linux n l. הקובץ חייב להיות בבעלות משתמש וקבוצה root, זכויות גישה חייבות להיות 644.

אנחנו כותבים מניפסט:

node 'server1.testdomain' {   # блок конфигурации, относящийся к ноде server1.testdomain
    file { '/etc/issue':   # описываем файл /etc/issue
        ensure  => present,   # этот файл должен существовать
        content => 'Debian GNU/Linux n l',   # у него должно быть такое содержимое
        owner   => root,   # пользователь-владелец
        group   => root,   # группа-владелец
        mode    => '0644',   # права на файл. Они заданы в виде строки (в кавычках), потому что иначе число с 0 в начале будет воспринято как записанное в восьмеричной системе, и всё пойдёт не так, как задумано
    }
}

יחסים בין משאבים בצומת

על הצומת server2.testdomain nginx חייב לפעול, לעבוד עם תצורה שהוכנה קודם לכן.

בואו נפרק את הבעיה:

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

אנחנו כותבים מניפסט:

node 'server2.testdomain' {   # блок конфигурации, относящийся к ноде server2.testdomain
    package { 'nginx':   # описываем пакет nginx
        ensure => installed,   # он должен быть установлен
    }
  # Прямая стрелка (->) говорит о том, что ресурс ниже должен
  # создаваться после ресурса, описанного выше.
  # Такие зависимости транзитивны.
    -> file { '/etc/nginx':   # описываем файл /etc/nginx
        ensure  => directory,   # это должна быть директория
        source  => 'puppet:///modules/example/nginx-conf',   # её содержимое нужно брать с паппет-сервера по указанному адресу
        recurse => true,   # копировать файлы рекурсивно
        purge   => true,   # нужно удалять лишние файлы (те, которых нет в источнике)
        force   => true,   # удалять лишние директории
    }
  # Волнистая стрелка (~>) говорит о том, что ресурс ниже должен
  # подписаться на изменения ресурса, описанного выше.
  # Волнистая стрелка включает в себя прямую (->).
    ~> service { 'nginx':   # описываем сервис nginx
        ensure => running,   # он должен быть запущен
        enable => true,   # его нужно запускать автоматически при старте системы
    }
  # Когда ресурс типа service получает уведомление,
  # соответствующий сервис перезапускается.
}

כדי שזה יעבוד, אתה צריך בערך את מיקום הקובץ הבא בשרת הבובות:

/etc/puppetlabs/code/environments/production/ # (это для нового Паппета, для старого корневой директорией будет /etc/puppet)
├── manifests/
│   └── site.pp
└── modules/
    └── example/
        └── files/
            └── nginx-conf/
                ├── nginx.conf
                ├── mime.types
                └── conf.d/
                    └── some.conf

סוגי משאבים

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

פילה

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

פרמטרים:

• שם המשאב - נתיב לקובץ (אופציונלי)
• נתיב - נתיב לקובץ (אם הוא לא מצוין בשם)
• לְהַבטִיחַ - סוג קובץ:
  • absent - למחוק קובץ
  • present - חייב להיות קובץ מכל סוג (אם אין קובץ, ייווצר קובץ רגיל)
  • file - קובץ רגיל
  • directory - ספרייה
  • link - קישור סימלי
• תוכן - תוכן הקובץ (מתאים רק לקבצים רגילים, לא ניתן להשתמש יחד עם מָקוֹר או יעד)
• מָקוֹר - קישור לנתיב שממנו ברצונך להעתיק את תוכן הקובץ (לא ניתן להשתמש בו יחד עם תוכן או יעד). ניתן לציין כ-URI עם סכמה puppet: (ואז יעשה שימוש בקבצים משרת הבובות), ועם הסכמה http: (אני מקווה שברור מה יקרה במקרה הזה), ואפילו עם התרשים file: או כנתיב מוחלט ללא סכמה (ואז ישמש הקובץ מה-FS המקומי בצומת)
• יעד - היכן צריך להצביע ה-Symlink (לא ניתן להשתמש יחד עם תוכן או מָקוֹר)
• בעלים - המשתמש שאמור להיות הבעלים של הקובץ
• קבוצה - הקבוצה שאליה הקובץ אמור להשתייך
• מצב - הרשאות קובץ (כמחרוזת)
• להחזיר - מאפשר עיבוד ספריות רקורסיבי
• לטהר - מאפשר מחיקת קבצים שאינם מתוארים ב-Puppet
• כּוֹחַ - מאפשר מחיקת ספריות שאינן מתוארות ב-Puppet

חבילה

מתקין ומסיר חבילות. מסוגל לטפל בהתראות - מתקין מחדש את החבילה אם הפרמטר צוין reinstall_on_refresh.

פרמטרים:

• שם המשאב - שם חבילה (אופציונלי)
• שם - שם החבילה (אם לא מצוין בשם)
• ספק - מנהל חבילות לשימוש
• לְהַבטִיחַ - המצב הרצוי של החבילה:
  • present, installed - כל גרסה מותקנת
  • latest - הגרסה האחרונה מותקנת
  • absent - נמחק (apt-get remove)
  • purged - נמחק יחד עם קבצי תצורה (apt-get purge)
  • held - גרסת החבילה נעולה (apt-mark hold)
  • любая другая строка - הגרסה שצוינה מותקנת
• reinstall_on_refresh - אם true, לאחר מכן עם קבלת ההודעה החבילה תותקן מחדש. שימושי עבור הפצות מבוססות מקור, שבהן ייתכן שיהיה צורך בבנייה מחדש של חבילות בעת שינוי פרמטרי בנייה. בְּרִירַת מֶחדָל false.

שרות

מנהל שירותים. מסוגל לעבד הודעות - מפעיל מחדש את השירות.

פרמטרים:

• שם המשאב - שירות לניהול (אופציונלי)
• שם - השירות שצריך לנהל (אם לא מצוין בשם)
• לְהַבטִיחַ - המצב הרצוי של השירות:
  • running - הושק
  • stopped - עצר
• לאפשר - שולט ביכולת להפעיל את השירות:
  • true - הפעלה אוטומטית מופעלת (systemctl enable)
  • mask - מחופש (systemctl mask)
  • false - הפעלה אוטומטית מושבתת (systemctl disable)
• הפעלה מחדש - פקודה כדי להפעיל מחדש את השירות
• מצב — פקודה לבדיקת מצב השירות
• יש הפעלה מחדש — ציין אם ה-initscript של השירות תומך בהפעלה מחדש. אם false והפרמטר מצוין הפעלה מחדש - הערך של פרמטר זה משמש. אם false ופרמטר הפעלה מחדש לא צוין - השירות נעצר ומתחיל להפעיל מחדש (אך systemd משתמש בפקודה systemctl restart).
• hasstatus — ציין אם ה-initscript של השירות תומך בפקודה status. אם false, אז נעשה שימוש בערך הפרמטר מצב. בְּרִירַת מֶחדָל true.

Exec

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

פרמטרים:

• שם המשאב - פקודה לביצוע (אופציונלי)
• הפקודה - הפקודה שיש לבצע (אם היא לא צוינה בשם)
• נתיב - נתיבים שבהם ניתן לחפש את קובץ ההפעלה
• רק אם - אם הפקודה המצוינת בפרמטר זה הושלמה עם קוד החזרה אפס, הפקודה הראשית תתבצע
• אלא אם כן - אם הפקודה המצוינת בפרמטר זה הושלמה עם קוד החזרה שאינו אפס, הפקודה הראשית תתבצע
• יוצר - אם הקובץ שצוין בפרמטר זה אינו קיים, הפקודה הראשית תתבצע
• באופן רענון - אם true, אז הפקודה תופעל רק כאשר המנהל הזה יקבל הודעה ממשאבים אחרים
• cwd - ספרייה שממנה תפעיל את הפקודה
• המשתמש - המשתמש שממנו להפעיל את הפקודה
• ספק - כיצד להפעיל את הפקודה:
  • פוסיקס - תהליך ילד פשוט נוצר, הקפד לציין נתיב
  • פָּגָז - הפקודה מופעלת במעטפת /bin/sh, לא ניתן לציין נתיב, אתה יכול להשתמש בגלובינג, צינורות ותכונות פגז אחרות. בדרך כלל מזוהה אוטומטית אם יש תווים מיוחדים (|, ;, &&, || וכו).

cron

שולט ב-cronjobs.

פרמטרים:

• שם המשאב - רק סוג של מזהה
• לְהַבטִיחַ - מצב כתר:
  • present - צור אם אינו קיים
  • absent - למחוק אם קיים
• הפקודה - איזו פקודה להפעיל
• סביבה - באיזו סביבה להפעיל את הפקודה (רשימת משתני סביבה והערכים שלהם באמצעות =)
• המשתמש - מאיזה משתמש להפעיל את הפקודה
• דקה, שעה, יום חול, חודש, יום חודש - מתי להפעיל cron. אם אחת מהתכונות הללו לא צוינה, הערך שלה ב-crontab יהיה *.

ב-Puppet 6.0 cron כאילו הוסר מהקופסה ב-puppetserver, כך שאין תיעוד באתר הכללי. אבל הוא נמצא בקופסה ב-puppet-agent, כך שאין צורך להתקין אותו בנפרד. אתה יכול לראות את התיעוד של זה בתיעוד לגרסה החמישית של Puppetאו ב-GitHub.

על משאבים באופן כללי

דרישות לייחודיות המשאב

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

לכן אכתוב שוב: מניפסטים עבור אותו צומת אינם צריכים להכיל משאבים מאותו סוג עם אותה כותרת!

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

package { 'ruby-mysql':
  ensure   => installed,
  name     => 'mysql',
  provider => 'gem',
}
package { 'python-mysql':
  ensure   => installed,
  name     => 'mysql',
  provider => 'pip',
}

לסוגי משאבים אחרים יש אפשרויות דומות כדי למנוע כפילות - name у שרות, command у Exec, וכולי.

מטא פרמטרים

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

רשימה מלאה של מטא פרמטרים בתיעוד Puppet.

רשימה קצרה:

• לדרוש - פרמטר זה מציין באילו משאבים תלוי משאב זה.
• לפני - פרמטר זה מציין אילו משאבים תלויים במשאב זה.
• הירשמו - פרמטר זה מציין מאילו משאבים משאב זה מקבל הודעות.
• תודיע — פרמטר זה מציין אילו משאבים מקבלים הודעות ממשאב זה.

כל המטא-פרמטרים המפורטים מקבלים קישור משאב בודד או מערך של קישורים בסוגריים מרובעים.

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

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

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

לדוגמה:

file { '/file1': ensure => present }
file { '/file2':
  ensure => directory,
  before => File['/file1'],
}
file { '/file3': ensure => absent }
File['/file1'] -> File['/file3']

תלות והתראות

תיעוד כאן.

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

בניגוד לתלות, הודעות אינן טרנזיטיביות. הכללים הבאים חלים על הודעות:

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

טיפול בפרמטרים לא מוגדרים

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

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

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

כדי לפתור בעיה זו יש עיצוב כזה כמו כיתה.

שיעורים

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

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

# Описание класса начинается с ключевого слова class и его названия.
# Дальше идёт тело класса в фигурных скобках.
class example_class {
    ...
}

לאחר מכן ניתן להשתמש בכיתה:

# первый вариант использования — в стиле ресурса с типом class
class { 'example_class': }
# второй вариант использования — с помощью функции include
include example_class
# про отличие этих двух вариантов будет рассказано дальше

דוגמה מהמשימה הקודמת - בואו נעביר את ההתקנה והתצורה של nginx למחלקה:

class nginx_example {
    package { 'nginx':
        ensure => installed,
    }
    -> file { '/etc/nginx':
        ensure => directory,
        source => 'puppet:///modules/example/nginx-conf',
        recure => true,
        purge  => true,
        force  => true,
    }
    ~> service { 'nginx':
        ensure => running,
        enable => true,
    }
}

node 'server2.testdomain' {
    include nginx_example
}

משתנים

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

אפשר לעשות את זה באמצעות משתנים.

שימו לב: משתנים ב-Puppet אינם ניתנים לשינוי!

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

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

# создание переменных
$variable = 'value'
$var2 = 1
$var3 = true
$var4 = undef
# использование переменных
$var5 = $var6
file { '/tmp/text': content => $variable }
# интерполяция переменных — раскрытие значения переменных в строках. Работает только в двойных кавычках!
$var6 = "Variable with name variable has value ${variable}"

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

דוגמאות למרחב שמות:

• גלובלי - משתנים מחוץ לתיאור המחלקה או הצומת הולכים לשם;
• מרחב השמות של הצומת בתיאור הצומת;
• מרחב השמות של המחלקה בתיאור המחלקה.

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

# переменная без пространства имён
$var
# переменная в глобальном пространстве имён
$::var
# переменная в пространстве имён класса
$classname::var
$::classname::var

בואו נסכים שהנתיב לתצורת nginx נמצא במשתנה $nginx_conf_source. ואז הכיתה תיראה כך:

class nginx_example {
    package { 'nginx':
        ensure => installed,
    }
    -> file { '/etc/nginx':
        ensure => directory,
        source => $nginx_conf_source,   # здесь используем переменную вместо фиксированной строки
        recure => true,
        purge  => true,
        force  => true,
    }
    ~> service { 'nginx':
        ensure => running,
        enable => true,
    }
}

node 'server2.testdomain' {
    $nginx_conf_source = 'puppet:///modules/example/nginx-conf'
    include nginx_example
}

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

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

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

בוא נבצע פרמטרים של המחלקה מהדוגמה למעלה ונוסיף שני פרמטרים: הראשון, הנדרש, הוא הנתיב לתצורה, והשני, אופציונלי, הוא שם החבילה עם nginx (בדביאן, למשל, יש חבילות nginx, nginx-light, nginx-full).

# переменные описываются сразу после имени класса в круглых скобках
class nginx_example (
  $conf_source,
  $package_name = 'nginx-light', # параметр со значением по умолчанию
) {
  package { $package_name:
    ensure => installed,
  }
  -> file { '/etc/nginx':
    ensure  => directory,
    source  => $conf_source,
    recurse => true,
    purge   => true,
    force   => true,
  }
  ~> service { 'nginx':
    ensure => running,
    enable => true,
  }
}

node 'server2.testdomain' {
  # если мы хотим задать параметры класса, функция include не подойдёт* — нужно использовать resource-style declaration
  # *на самом деле подойдёт, но про это расскажу в следующей серии. Ключевое слово "Hiera".
  class { 'nginx_example':
    conf_source => 'puppet:///modules/example/nginx-conf',   # задаём параметры класса точно так же, как параметры для других ресурсов
  }
}

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

הסוג נכתב מיד לפני שם הפרמטר:

class example (
  String $param1,
  Integer $param2,
  Array $param3,
  Hash $param4,
  Hash[String, String] $param5,
) {
  ...
}

מחלקות: כלול שם מחלקה לעומת מחלקה{'שם מחלקה':}

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

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

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

מגדיר

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

לדוגמה, על מנת להתקין את מודול ה-PHP, אנו עושים את הפעולות הבאות ב-Avito:

1. התקן את החבילה עם מודול זה.
2. בואו ניצור קובץ תצורה עבור מודול זה.
3. אנו יוצרים קישור סימול לתצורה עבור php-fpm.
4. אנו יוצרים קישור סימול ל-config עבור php cli.

במקרים כאלה, עיצוב כגון לְהַגדִיר (הגדר, סוג מוגדר, סוג משאב מוגדר). Define דומה למחלקה, אך ישנם הבדלים: ראשית, כל Define הוא סוג משאב, לא משאב; שנית, לכל הגדרה יש פרמטר מרומז $title, לאן הולך שם המשאב כאשר הוא מוצהר. בדיוק כמו במקרה של מחלקות, תחילה יש לתאר הגדרה, ולאחר מכן ניתן להשתמש בה.

דוגמה פשוטה עם מודול עבור PHP:

define php74::module (
  $php_module_name = $title,
  $php_package_name = "php7.4-${title}",
  $version = 'installed',
  $priority = '20',
  $data = "extension=${title}.son",
  $php_module_path = '/etc/php/7.4/mods-available',
) {
  package { $php_package_name:
    ensure          => $version,
    install_options => ['-o', 'DPkg::NoTriggers=true'],  # триггеры дебиановских php-пакетов сами создают симлинки и перезапускают сервис php-fpm - нам это не нужно, так как и симлинками, и сервисом мы управляем с помощью Puppet
  }
  -> file { "${php_module_path}/${php_module_name}.ini":
    ensure  => $ensure,
    content => $data,
  }
  file { "/etc/php/7.4/cli/conf.d/${priority}-${php_module_name}.ini":
    ensure  => link,
    target  => "${php_module_path}/${php_module_name}.ini",
  }
  file { "/etc/php/7.4/fpm/conf.d/${priority}-${php_module_name}.ini":
    ensure  => link,
    target  => "${php_module_path}/${php_module_name}.ini",
  }
}

node server3.testdomain {
  php74::module { 'sqlite3': }
  php74::module { 'amqp': php_package_name => 'php-amqp' }
  php74::module { 'msgpack': priority => '10' }
}

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

קל להגן על עצמך מפני זה: לכל המשאבים בתוך ההגדרה צריך להיות שם בהתאם $title. חלופה היא הוספת משאבים אימפוטנטית; במקרה הפשוט ביותר, מספיק להעביר את המשאבים המשותפים לכל מופעי ההגדרה למחלקה נפרדת ולכלול את המחלקה הזו בהגדרה - function include אימפוטנטי.

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

תלות והודעות לשיעורים והגדרות

מחלקות והגדרות מוסיפים את הכללים הבאים לטיפול בתלות ובהודעות:

• תלות ב-class/define מוסיפה תלות בכל המשאבים של ה-class/define;
• תלות class/define מוסיפה תלות לכל משאבי class/define;
• הודעה class/define מודיעה לכל המשאבים של class/define;
• מנוי class/define נרשם לכל המשאבים של class/define.

הצהרות ובוררים מותנים

תיעוד כאן.

if

הכל פשוט כאן:

if ВЫРАЖЕНИЕ1 {
  ...
} elsif ВЫРАЖЕНИЕ2 {
  ...
} else {
  ...
}

אלא אם כן

אלא אם הוא הפוך: גוש הקוד יבוצע אם הביטוי הוא false.

unless ВЫРАЖЕНИЕ {
  ...
}

מקרה

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

case ВЫРАЖЕНИЕ {
  ЗНАЧЕНИЕ1: { ... }
  ЗНАЧЕНИЕ2, ЗНАЧЕНИЕ3: { ... }
  default: { ... }
}

בוררים

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

$var = $othervar ? { 'val1' => 1, 'val2' => 2, default => 3 }

מודולים

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

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

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

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

בשרת הבובות, המודולים ממוקמים בספריית המשנה של המודולים של ספריית הבסיס. בתוך כל מודול יש סכימת ספריות סטנדרטית - מניפסטים, קבצים, תבניות, lib וכו'.

מבנה קובץ במודול

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

• manifests - הוא מכיל מניפסטים
• files - הוא מכיל קבצים
• templates - הוא מכיל תבניות
• lib - הוא מכיל קוד רובי

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

שמות משאבים ושמות קבצים במודול

תיעוד כאן.

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

הכללים פשוטים:

• כל המשאבים במודול חייבים להיות במרחב השמות של המודול. אם המודול נקרא foo, אז יש לתת שם לכל המשאבים שבו foo::<anything>, או רק foo.
• המשאב עם שם המודול חייב להיות בקובץ init.pp.
• עבור משאבים אחרים, ערכת שמות הקבצים היא כדלקמן:
  • הקידומת עם שם המודול נמחקת
  • כל המעיים הכפולים, אם יש, מוחלפים באלכסונים
  • הרחבה מתווספת .pp

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

• כיתה nginx המתואר במניפסט init.pp;
• כיתה nginx::service המתואר במניפסט service.pp;
• לְהַגדִיר nginx::server המתואר במניפסט server.pp;
• לְהַגדִיר nginx::server::location המתואר במניפסט server/location.pp.

תבניות

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

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

file { '/tmp/example': content => template('modulename/templatename.erb')

צפה בנתיב <modulename>/<filename> מרמז על קובץ <rootdir>/modules/<modulename>/templates/<filename>.

בנוסף, יש פונקציה inline_template - הוא מקבל את טקסט התבנית כקלט, לא את שם הקובץ.

בתוך תבניות, אתה יכול להשתמש בכל משתני Puppet בהיקף הנוכחי.

Puppet תומך בתבניות בפורמט ERB ו-EPP:

• תיעוד EPP.
• תיעוד ERB.

בקצרה על ERB

מבני בקרה:

• <%= ВЫРАЖЕНИЕ %> - הכנס את הערך של הביטוי
• <% ВЫРАЖЕНИЕ %> - לחשב את הערך של ביטוי (מבלי להכניס אותו). הצהרות מותנות (אם) ולולאות (כל אחת) בדרך כלל נכנסות לכאן.
• <%# КОММЕНТАРИЙ %>

ביטויים ב-ERB נכתבים ברובי (ERB הוא למעשה Embedded Ruby).

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

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

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

class zookeeper::configure (
  Array[String] $nodes,
  Integer $port_client,
  Integer $port_quorum,
  Integer $port_leader,
  Hash[String, Any] $properties,
  String $datadir,
) {
  file { '/etc/zookeeper/conf/zoo.cfg':
    ensure  => present,
    content => template('zookeeper/zoo.cfg.erb'),
  }
}

והתבנית המתאימה zoo.cfg.erb - כך:

<% if @nodes.length > 0 -%>
<% @nodes.each do |node, id| -%>
server.<%= id %>=<%= node %>:<%= @port_leader %>:<%= @port_quorum %>;<%= @port_client %>
<% end -%>
<% end -%>

dataDir=<%= @datadir %>

<% @properties.each do |k, v| -%>
<%= k %>=<%= v %>
<% end -%>

עובדות ומשתנים מובנים

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

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

דוגמה לעבודה עם עובדות:

notify { "Running OS ${facts['os']['name']} version ${facts['os']['release']['full']}": }
# ресурс типа notify просто выводит сообщение в лог

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

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

עובדות בצורה של קבצי הפעלה

עובדות כאלה ממוקמות במודולים בספרייה facts.d. כמובן שהקבצים חייבים להיות ניתנים להפעלה. בעת הפעלה, עליהם להפיק מידע לפלט סטנדרטי בפורמט YAML או key=value.

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

#!/bin/sh
echo "testfact=success"

#!/bin/sh
echo '{"testyamlfact":"success"}'

עובדות רובי

עובדות כאלה ממוקמות במודולים בספרייה lib/facter.

# всё начинается с вызова функции Facter.add с именем факта и блоком кода
Facter.add('ladvd') do
# в блоках confine описываются условия применимости факта — код внутри блока должен вернуть true, иначе значение факта не вычисляется и не возвращается
  confine do
    Facter::Core::Execution.which('ladvdc') # проверим, что в PATH есть такой исполняемый файл
  end
  confine do
    File.socket?('/var/run/ladvd.sock') # проверим, что есть такой UNIX-domain socket
  end
# в блоке setcode происходит собственно вычисление значения факта
  setcode do
    hash = {}
    if (out = Facter::Core::Execution.execute('ladvdc -b'))
      out.split.each do |l|
        line = l.split('=')
        next if line.length != 2
        name, value = line
        hash[name.strip.downcase.tr(' ', '_')] = value.strip.chomp(''').reverse.chomp(''').reverse
      end
    end
    hash  # значение последнего выражения в блоке setcode является значением факта
  end
end

עובדות טקסט

עובדות כאלה ממוקמות על צמתים בספרייה /etc/facter/facts.d ב-Puppet הישן או /etc/puppetlabs/facts.d ב-Puppet החדש.

examplefact=examplevalue

---
examplefact2: examplevalue2
anotherfact: anothervalue

הגעה לעובדות

יש שתי דרכים לגשת לעובדות:

• דרך המילון $facts: $facts['fqdn'];
• שימוש בשם העובדה כשם המשתנה: $fqdn.

עדיף להשתמש במילון $facts, או אפילו טוב יותר, לציין את מרחב השמות הגלובלי ($::facts).

להלן החלק הרלוונטי בתיעוד.

משתנים מובנים

מלבד העובדות, יש גם כמה משתנים, זמין במרחב השמות הגלובלי.

• עובדות מהימנות - משתנים שנלקחים מהאישור של הלקוח (מאחר שהתעודה מונפקת בדרך כלל בשרת poppet, הסוכן לא יכול פשוט לקחת ולשנות את האישור שלו, ולכן המשתנים "מהימנים"): שם התעודה, שם ה- מארח ודומיין, הרחבות מהאישור.
• עובדות שרת - משתנים הקשורים למידע על השרת - גרסה, שם, כתובת IP של השרת, סביבה.
• עובדות סוכן - משתנים שנוספו ישירות על ידי סוכן בובה, ולא על ידי עובדה - שם תעודה, גירסת סוכן, גירסת בובה.
• משתני מאסטר - משתני Pappetmaster (sic!). זה בערך כמו ב עובדות שרת, בנוסף ערכי פרמטרי תצורה זמינים.
• משתני מהדר - משתני מהדר הנבדלים בכל היקף: שם המודול הנוכחי ושם המודול שבו הגישה לאובייקט הנוכחי. ניתן להשתמש בהם, למשל, כדי לבדוק שהשיעורים הפרטיים שלך אינם בשימוש ישירות ממודולים אחרים.

תוספת 1: איך להריץ ולנקות באגים בכל זה?

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

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

הסוכן

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

במקרה הפשוט ביותר, כדי להשתמש בתצורת הבובות, מספיק להפעיל את הסוכן במצב ללא שרת: בתנאי שקוד הבובה מועתק לצומת, הפעל puppet apply <путь к манифесту>:

atikhonov@atikhonov ~/puppet-test $ cat helloworld.pp 
node default {
    notify { 'Hello world!': }
}
atikhonov@atikhonov ~/puppet-test $ puppet apply helloworld.pp 
Notice: Compiled catalog for atikhonov.localdomain in environment production in 0.01 seconds
Notice: Hello world!
Notice: /Stage[main]/Main/Node[default]/Notify[Hello world!]/message: defined 'message' as 'Hello world!'
Notice: Applied catalog in 0.01 seconds

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

אתה יכול לחקות את מודל הדחיפה של העבודה - עבור לצומת שאתה מעוניין בו והתחל sudo puppet agent -t. מַפְתֵחַ -t (--test) למעשה כולל מספר אפשרויות שניתן להפעיל בנפרד. אפשרויות אלה כוללות את הדברים הבאים:

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

לסוכן יש מצב פעולה ללא שינויים - ניתן להשתמש בו כאשר אינכם בטוחים שכתבתם את התצורה הנכונה ורוצים לבדוק מה בדיוק הסוכן ישנה במהלך הפעולה. מצב זה מופעל על ידי הפרמטר --noop בשורת הפקודה: sudo puppet agent -t --noop.

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

שרת

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

פריסת קוד - אם אתה צריך את זה במהירות ובקלות, אז תסתכל (ב-r10k)[https://github.com/puppetlabs/r10k], עבור התקנות קטנות זה אמור להספיק למדי.

תוספת 2: הנחיות קידוד

1. שים את כל ההיגיון במחלקות ובהגדרות.
2. שמור מחלקות והגדרות במודולים, לא במניפסטים המתארים צמתים.
3. השתמש בעובדות.
4. אל תעשה אם על סמך שמות מארחים.
5. אתם מוזמנים להוסיף פרמטרים למחלקות והגדרות - זה עדיף על לוגיקה מרומזת החבויה בגוף המחלקה/הגדרה.

אני אסביר מדוע אני ממליץ לעשות זאת במאמר הבא.

מסקנה

נסיים עם ההקדמה. במאמר הבא אספר לכם על Hiera, ENC ו-PuppetDB.

רק משתמשים רשומים יכולים להשתתף בסקר. להתחברבבקשה.

למעשה, יש הרבה יותר חומר - אני יכול לכתוב מאמרים בנושאים הבאים, להצביע על מה שתהיה מעוניין לקרוא עליו:

• 59,1%בניית בובות מתקדמת - קצת חרא ברמה הבאה: לולאות, מיפוי וביטויי למבדה אחרים, אוספי משאבים, משאבים מיוצאים ותקשורת בין מארחים באמצעות Puppet, תגים, ספקים, סוגי נתונים מופשטים.13
• 31,8%"אני המנהלת של אמא שלי" או איך באביטו התיידדנו עם כמה שרתי פופטים בגרסאות שונות, ובאופן עקרוני, החלק של ניהול שרת הפופט.7
• 81,8%איך אנחנו כותבים קוד בובות: מכשור, תיעוד, בדיקות, CI/CD.18

22 משתמשים הצביעו. 9 משתמשים נמנעו.

מקור: www.habr.com