The Inside Playbook. פונקציות רשת ב-Ansible Engine 2.9 החדש

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

כפי שהכרזנו לאחרונה, פלטפורמת האוטומציה של Red Hat Ansible כולל כעת את Ansible Tower, Ansible Engine וכל התוכן ברשת Ansible. כיום, רוב פלטפורמות הרשת הפופולריות מיושמות באמצעות מודולי Ansible. לדוגמה:

• אריסטה EOS
• IOS של סיסקו
• Cisco IOS XR
• Cisco NX-OS
• ג'וניפר ג'ונוס
• VyOS

לרשימה מלאה של פלטפורמות הנתמכות באופן מלא על ידי Red Hat באמצעות מנוי Ansible Automation, פורסם כאן.

מה למדנו

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

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

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

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

שיפורים בעובדות

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

אולי שמתם לב שאנחנו עובדים על תפקיד Ansible Network Engine. באופן טבעי, הורדות 24K מאוחר יותר, תפקיד מנוע הרשת הפך במהירות לאחד מתפקידי Ansible הפופולריים ביותר ב-Ansible Galaxy עבור תרחישי אוטומציה של רשת. לפני שהעברנו חלק גדול מזה ל-Ansible 2.8 כדי להתכונן למה שיידרש ב-Ansible 2.9, תפקיד Ansible זה סיפק את קבוצת הכלים הראשונה כדי לסייע בניתוח פקודות, ניהול פקודות ואיסוף נתונים עבור התקני רשת.

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

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

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

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

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

תוך כדי איסוף עובדות:

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

- hosts: arista
  module_defaults:
    eos_facts:
      gather_subset: min
      gather_network_resources:
      - interfaces
  gather_facts: True

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

שימוש ישירות במודול עובדות הרשת:

- name: collect interface configuration facts
  eos_facts:
    gather_subset: min
    gather_network_resources:
    - interfaces

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

ansible_facts:
   ansible_network_resources:
      interfaces:
      - enabled: true
        name: Ethernet1
        mtu: '1476'
      - enabled: true
        name: Loopback0
      - enabled: true
        name: Loopback1
      - enabled: true
        mtu: '1476'
        name: Tunnel0
      - enabled: true
        name: Ethernet1
      - enabled: true
        name: Tunnel1
      - enabled: true
        name: Ethernet1

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

ניתן להוסיף עובדות ממשק למשתנים מאוחסנים של Ansible ולהשתמש בהם מיד או מאוחר יותר כקלט למודול משאבים eos_interfaces ללא עיבוד נוסף או המרה.

מודולי משאבים

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

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

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

- name: example of facts being pushed right back to device.
  hosts: arista
  gather_facts: false
  tasks:
  - name: grab arista eos facts
    eos_facts:
      gather_subset: min
      gather_network_resources: l3_interfaces

  - name: ensure that the IP address information is accurate
    eos_l3_interfaces:
      config: "{{ ansible_network_resources['l3_interfaces'] }}"
      register: result

  - name: ensure config did not change
    assert:
      that: not result.changed

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

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

במה שונים מודולי המשאבים החדשים מהקודמים?

עבור מהנדס אוטומציה ברשת, ישנם 3 הבדלים עיקריים בין מודולי משאבים ב-Ansible 2.9 ובגירסאות קודמות.

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

2) מודולי משאבים כוללים כעת ערך מצב.

• merged: התצורה מתמזגת עם התצורה שסופקה (ברירת מחדל);
• replaced: תצורת המשאב תוחלף בתצורה שסופקה;
• overridden: תצורת המשאב תוחלף בתצורה שסופקה; מופעי משאבים מיותרים יימחקו;
• deleted: תצורת המשאב תימחק/תשוחזר לברירת המחדל.

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

• before: תצורה במכשיר בצורה של נתונים מובנים לפני המשימה;
• after: אם ההתקן השתנה (או עשוי להשתנות אם נעשה שימוש במצב בדיקה), התצורה המתקבלת תוחזר כנתונים מובנים;
• commands: כל פקודות תצורה פועלות במכשיר כדי להביא אותו למצב הרצוי.

מה המשמעות של כל זה? למה זה חשוב?

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

ארגונים מבינים כי אוטומציה של תבניות רשת בודדות אינה פותרת את בעיית הממגורות ורק מגבירה את היעילות במידה מסוימת. Red Hat Ansible Automation Platform מספקת מודלים קפדניים ונורמטיביים של נתוני משאבים לניהול פרוגרמטי של הנתונים הבסיסיים בהתקן רשת. כלומר, המשתמשים נוטשים בהדרגה את שיטות התצורה הבודדות לטובת שיטות מודרניות יותר בדגש על טכנולוגיות (לדוגמה, כתובות IP, VLANs, LLDP וכו'), ולא על יישום ספק ספציפי.

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

אילו מודולי משאבים יגיעו ב-Ansible Engine 2.9?

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

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

הערה: משאבים מודגשים תוכננו ויושמו ב-Ansible 2.9.
בהתבסס על משוב מלקוחות ארגוניים ומהקהילה, זה היה הגיוני קודם כל להתמודד עם אותם מודולים הקשורים לפרוטוקולי טופולוגיית רשת, וירטואליזציה וממשקים.
מודולי המשאבים הבאים פותחו על ידי צוות Ansible Network והם מתאימים לפלטפורמות הנתמכות על ידי Red Hat:

המודולים הבאים פותחו על ידי קהילת Ansible:

• exos_lldp_global - מבית אקסטרים נטוורקס.
• nxos_bfd_interfaces - מסיסקו
• nxos_telemetry - מסיסקו

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

תוכניות עבור Ansible 2.10 ואילך

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

משאבים ותחילת העבודה

הודעה לעיתונות על Ansible Automation Platform
בלוג פלטפורמת אוטומציה של Ansible
העתיד של העברת תוכן ב-Ansible
הרהורים על שינוי מבנה פרויקט Ansible

מקור: www.habr.com