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

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

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

כותרות

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

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

ansible-playbook מבצע את ספר המשחקים. ספר הפעלה הוא קובץ עם הסיומת yml/yaml, שבתוכו יש משהו כזה:

---
- hosts: group1
  roles:
    - role1

- hosts: group2,group3
  tasks:
    - debug:

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

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

אז, זכרו: Playbook היא רשימה המורכבת ממשחק ו import_playbook.
זה מחזה אחד:

- hosts: group1
  roles:
    - role1

וזה גם עוד מחזה:

- hosts: group2,group3
  tasks:
    - debug:

מה זה משחק? למה היא?

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

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

פשוט, נכון? איך יכול להיות אחרת?

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

דוגמה ארכיטיפית היא ניטור. ברצוני לקבל תפקיד ניטור שיגדיר ניטור. תפקיד הניטור מוקצה למארחים ניטור (לפי משחק). אבל מסתבר שבשביל ניטור אנחנו צריכים להעביר חבילות למארחים שאנחנו עוקבים אחריהם. למה לא להשתמש בנציג? אתה צריך גם להגדיר iptables. נָצִיג? עליך גם לכתוב/לתקן תצורה עבור ה-DBMS כדי לאפשר ניטור. נָצִיג! ואם חסרה יצירתיות, אז אתה יכול לעשות משלחת include_role בלולאה מקוננת באמצעות מסנן מסובך ברשימת קבוצות, ובפנים include_role אתה יכול לעשות יותר delegate_to שוב. ואנחנו הולכים...

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

היכן קרתה כאן הטעות? ברגע שגילית שכדי לבצע את המשימה "x" במארח X אתה צריך ללכת לארח Y ולעשות שם "y", היית צריך לעשות תרגיל פשוט: ללכת ולכתוב משחק, מה שבמארח Y עושה y. אל תוסיף משהו ל-"x", אלא תכתוב אותו מאפס. אפילו עם משתנים מקודדים.

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

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

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

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

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

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

הערה למצומצמים: התפקיד בהחלט יכול להשפיע על זרימת הבקרה. לאכול delegate_to ויש לו שימושים סבירים. לאכול meta: end host/play. אבל! זוכרים שאנחנו מלמדים את היסודות? לשכוח מ delegate_to. אנחנו מדברים על קוד Ansible הפשוט והיפה ביותר. שהוא קל לקריאה, קל לכתיבה, קל לניפוי באגים, קל לבדיקה וקל להשלים. אז, שוב:

לשחק ורק משחק מחליט על אילו מארחים מה מבוצע.

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

משימות ותפקידים

שקול לשחק:

- hosts: somegroup
  pre_tasks:
    - some_tasks1:
  roles:
     - role1
     - role2
  post_tasks:
     - some_task2:
     - some_task3:

נניח שאתה צריך לעשות פו. וזה נראה כמו foo: name=foobar state=present. איפה אני צריך לכתוב את זה? לפני? הודעה? ליצור תפקיד?

...ולאן נעלמו המשימות?

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

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

סדר הסעיפים שלהם עם משימות ותפקידים: pre_tasks, roles, tasks, post_tasks. מכיוון שמבחינה סמנטית סדר הביצוע הוא בין tasks и roles לא ברור, אז שיטות עבודה מומלצות אומרות שאנחנו מוסיפים קטע tasks, רק אם לא roles... אם יש roles, אז כל המשימות המצורפות ממוקמות בקטעים pre_tasks/post_tasks.

כל מה שנותר הוא שהכל ברור מבחינה סמנטית: ראשית pre_tasks, אם כך roles, אם כך post_tasks.

אבל עדיין לא ענינו על השאלה: איפה הקריאה למודול? foo לִכתוֹב? האם עלינו לכתוב תפקיד שלם עבור כל מודול? או שעדיף תפקיד עבה לכל דבר? ואם לא תפקיד, אז איפה כדאי לכתוב - לפני או בפוסט?

אם אין תשובה מנומקת לשאלות הללו, אז זה סימן לחוסר אינטואיציה, כלומר, אותם "יסודות רעועים". בוא נבין את זה. ראשית, שאלת אבטחה: אם יש למשחק pre_tasks и post_tasks (ואין משימות או תפקידים), אז משהו יכול להישבר אם אבצע את המשימה הראשונה מ post_tasks אני אעביר את זה עד הסוף pre_tasks?

כמובן שנוסח השאלה רומז שהיא תישבר. אבל מה בדיוק?

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

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

עכשיו בואו נחשוב שוב, למה אנחנו צריכים pre_tasks и post_tasks? למשל, על מנת להשלים את כל הדרוש (כולל מטפלים) לפני מילוי התפקיד. א post_tasks יאפשר לנו לעבוד עם תוצאות ביצוע תפקידים (כולל מטפלים).

מומחה Ansible נבון יגיד לנו מה זה. meta: flush_handlers, אבל למה אנחנו צריכים flush_handlers אם אנחנו יכולים להסתמך על סדר הביצוע של קטעים במשחק? יתר על כן, השימוש ב-meta: flush_handlers יכול לתת לנו דברים בלתי צפויים עם מטפלים כפולים, לתת לנו אזהרות מוזרות בעת שימוש when у block וכו ' ככל שאתה יודע טוב יותר את האפשרי, כך תוכל לתת יותר ניואנסים לפתרון "מסובך". ופתרון פשוט - שימוש בחלוקה טבעית בין קדם/תפקידים/פוסט - לא גורם לניואנסים.

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

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

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

משימות ותפקידים (חלק שני)

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

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

עכשיו, תשומת לב. מה אפשר לעשות מזה בתפקיד? את תמיד מוזמנת להתקשר לתופעות לוואי, זו המהות של כל Ansible - ליצור תופעות לוואי. האם יש סיבות לוואי? יְסוֹדִי. אבל עם "העבירו ערך והחזירו אותו" - שם זה לא עובד. ראשית, אתה לא יכול להעביר ערך לתפקיד. אתה יכול להגדיר משתנה גלובלי עם גודל משחק לכל החיים בקטע vars עבור התפקיד. אתה יכול להגדיר משתנה גלובלי עם חיים שלמים בתוך התפקיד. או אפילו עם כל החיים של ספרי משחק (set_fact/register). אבל אתה לא יכול לקבל "משתנים מקומיים". אתה לא יכול "לקחת ערך" ו"להחזיר אותו".

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

סך הכל: תפקיד אינו פונקציה.

מה טוב בתפקיד? ראשית, לתפקיד יש ערכי ברירת מחדל (/default/main.yaml), שנית, לתפקיד יש ספריות נוספות לאחסון קבצים.

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

מה עוד נהדר בתפקידים? כי יש להם קטלוגים משלהם. אלו הן ספריות למשתנים, הן קבועות (כלומר מחושבות עבור התפקיד) והן דינמיות (יש תבנית או אנטי תבנית - include_vars עם {{ ansible_distribution }}-{{ ansible_distribution_major_version }}.yml.). אלו המדריכים עבור files/, templates/. כמו כן, זה מאפשר לך לקבל מודולים ותוספים משלך (library/). אבל, בהשוואה למשימות בספר משחק (שיכול להיות גם כל זה), היתרון היחיד כאן הוא שהקבצים לא מושלכים לערימה אחת, אלא כמה ערימות נפרדות.

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

לפיכך, לתפקידים יש שתי תכונות חשובות: יש להם ברירות מחדל (תכונה ייחודית) והם מאפשרים לך לבנות את הקוד שלך.

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

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

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

מטפלים ומשימות

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

מכיוון שאנו זוכרים את היסודות, הנה דוגמה:

- hosts: group1
  tasks:
    - foo:
      notify: handler1
  handlers:
     - name: handler1
       bar:

המטפלים של התפקיד נמצאים ב-rolename/handlers/main.yaml. מטפלים מפשפשים בין כל משתתפי המחזה: משימות טרום/פוסט_יכולות למשוך מטפלים בתפקידים, ותפקיד יכול למשוך מטפלים מההצגה. עם זאת, קריאות "צולבות תפקידים" למטפלים גורמות להרבה יותר wtf מאשר חזרה על מטפל טריוויאלי. (אלמנט נוסף של שיטות עבודה מומלצות הוא לנסות לא לחזור על שמות מטפלים).

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

לא ניתן לפתור את המצב עם התצורה (ליתר דיוק, אתה יכול להמציא לעצמך פרוטוקול ריסטרט מיוחד עם דגלי קבצים וכו', אבל זה כבר לא 'אפשרי בסיסי' בשום צורה). אבל יש עוד סיפור משותף: התקנו את האפליקציה, הקלטנו אותה .service-קובץ, ועכשיו אנחנו רוצים אותו daemon_reload и state=started. ונראה שהמקום הטבעי לכך הוא המטפל. אבל אם אתה הופך את זה לא למטפל אלא למשימה בסוף רשימת משימות או תפקיד, אז זה יבוצע באופן אימפוטנטי בכל פעם. גם אם ספר המשחקים נשבר באמצע. זה לא פותר את בעיית ההפעלה מחדש בכלל (אינך יכול לבצע משימה עם התכונה restarted, כי האידמפוטנציה אובדת), אבל בהחלט שווה לעשות state=started, היציבות הכוללת של Playbooks עולה, כי מספר החיבורים והמצב הדינמי יורד.

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

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

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

הקורא המאכל בצדק מציין שלא דנו listenשמטפל יכול להתקשר ל-notify עבור מטפל אחר, שמטפל יכול לכלול import_tasks (שיכול לעשות include_role עם with_items), שמערכת המטפל ב-Ansible היא Turing-complete, שמטפלים מ-include_role מצטלבים בצורה סקרנית עם מטפלים מהמשחק, וכו' .ד. - ברור שכל זה אינו ה"יסודות").

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

בנפרד, אני רוצה לומר כמה מילים על תפקידים לשימוש חוזר. לפני שהאוספים הופיעו, היה רעיון שאתה יכול לעשות תפקידים אוניברסליים שיכולים להיות ansible-galaxy install והלך. עובד על כל מערכת ההפעלה של כל הגרסאות בכל המצבים. אז דעתי: זה לא עובד. כל תפקיד עם מסה include_vars, התומך ב-100500 מקרים, נידון לתהום של באגים של מארזים פינתיים. אפשר לכסות אותם בבדיקות מאסיביות, אבל כמו בכל בדיקה, או שיש לך תוצר קרטזיאני של ערכי קלט ופונקציה כוללת, או שיש לך "תרחישים בודדים מכוסים". דעתי היא שהרבה יותר טוב אם התפקיד הוא ליניארי (מורכבות ציקלומטית 1).

כמה שפחות אם (מפורש או הצהרתי - בטופס when או טופס include_vars לפי קבוצת משתנים), כך התפקיד טוב יותר. לפעמים צריך לעשות ענפים, אבל, אני חוזר, ככל שיש פחות, כך ייטב. אז זה נראה כמו תפקיד טוב עם גלקסי (זה עובד!) עם חבורה של when עשוי להיות פחות עדיף מתפקיד "של עצמו" מחמש משימות. הרגע שבו התפקיד עם גלקסיה טוב יותר הוא כשאתה מתחיל לכתוב משהו. הרגע שבו זה מחמיר הוא כשמשהו נשבר ויש לך חשד שזה בגלל "התפקיד עם הגלקסיה". אתה פותח אותו, ויש חמישה תכלילים, שמונה דפי משימה וערימה when'או... ואנחנו צריכים להבין את זה. במקום 5 משימות, רשימה ליניארית שבה אין מה לשבור.

בחלקים הבאים

• קצת על מלאי, משתני קבוצה, תוסף host_group_vars, hostvars. איך לקשור קשר גורדי עם ספגטי. משתני היקף וקדימות, מודל זיכרון Ansible. "אז איפה אנחנו מאחסנים את שם המשתמש של מסד הנתונים?"
• jinja: {{ jinja }} - nosql notype nosense פלסטלינה רכה. זה נמצא בכל מקום, אפילו איפה שאתה לא מצפה לזה. קצת על !!unsafe וימל טעים.

מקור: www.habr.com