שאלת ראיון לתפקיד DevNet: איך מעדכנים 80 התקני רשת עם NETCONF ו־Ansible בלי לאבד שליטה?

אתם בראיון לתפקיד Network Automation Engineer. המראיין לא מבקש להגדיר שכבה במודל OSI ולא שואל איזו ספרייה התקנתם ב־Python. הוא מציג משימה שהצוות שלו באמת עשוי לקבל: בארגון יש 80 נתבים וסוויצ׳ים, מכמה משפחות ציוד ובגרסאות שונות. צריך להוסיף שרת NTP חדש. חלק מההתקנים תומכים ב־NETCONF, ובחלקם עובדים עדיין דרך CLI. איך תבצעו את השינוי, ואיך תדעו שלא השארתם חצי רשת עם הגדרה אחרת?

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

מהו תפקיד DevNet בהקשר הזה?

DevNet הוא גם שמה של קהילת המפתחים והאוטומציה של Cisco. בשוק משתמשים במונח לפעמים כתיאור מקוצר לאיש רשתות עם יכולות תכנות. שמות משרה מדויקים יותר עשויים להיות Network Automation Engineer או Network Programmability Engineer. התפקיד משלב הבנה של ניתוב, מיתוג ואבטחת מידע עם APIs, קוד וניהול תצורה. זה לא אומר שכל משרה כזו זהה, או שנדרשת בה בהכרח הסמכה מסוימת.

בתרחיש שלנו, ידע ב־CCNA עוזר להבין מאיזו כתובת הציוד יוצא אל שרת הזמן, איזה VRF רלוונטי, והאם ACL או Firewall חוסמים את התעבורה. ידע ב־Python וב־Ansible עוזר להפוך את הבדיקה והתיקון לפעולה מסודרת שאפשר לחזור עליה. איש אוטומציה טוב צריך את שני הצדדים.

שלושה דברים שונים: NETCONF, YANG ו־Ansible

NETCONF הוא פרוטוקול לניהול התקני רשת, המוגדר ב־RFC 6241. הוא מעביר בקשות ותשובות מובנות ב־XML, לרוב מעל SSH בפורט 830. במקום לשלוח מחרוזת פקודות ולהסתמך על פלט מסך, הלקוח משתמש בפעולות כמו get-config ו־edit-config.

YANG היא שפת מידול נתונים. היא מתארת אילו שדות קיימים, איך הם מאורגנים ואילו ערכים מותר להזין. NETCONF הוא הפרוטוקול; YANG מתארת את הנתונים שהמערכת חושפת. XML הוא הייצוג שמשמש בהודעות NETCONF. קובץ YAML של Ansible הוא דבר אחר: הוא מתאר משימות וערכים עבור כלי האוטומציה.

Ansible מתזמר את העבודה: על אילו התקנים פועלים, באיזה סדר, עם אילו משתנים, ואיך מטפלים בתוצאה. הוא יכול לעבוד דרך חיבור ansible.netcommon.netconf או דרך ansible.netcommon.network_cli. הראשון משתמש ב־NETCONF; השני עובד מול ממשק הפקודות דרך SSH. Ansible אינו פרוטוקול מתחרה ל־NETCONF, והחלפת סוג החיבור לא הופכת משימת CLI למשימת NETCONF.

השלב הראשון אינו כתיבת Playbook

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

בונים Inventory שמפריד בין משפחות ציוד, גרסאות ותפקידים. לא מניחים שכל התקן Cisco חושף אותו מודל, או ששני יצרנים מייצגים שרת NTP באותו עץ XML. בודקים את המודל, ה־namespace והגרסה שלו. בפתיחת חיבור NETCONF מוחלפות הודעות hello עם capabilities: צריך לבדוק מה ההתקן באמת תומך בו, לא מה הופיע בדוגמה שמצאנו ברשת.

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

מה NETCONF נותן, ומה הוא לא מבטיח?

ה־running datastore מייצג את ההגדרה הפעילה. אם ההתקן תומך ב־candidate, אפשר להכין שינוי בטיוטה ולהפעיל אותו באמצעות commit. יכולת validate מאפשרת בדיקות של הקונפיגורציה לפני ההפעלה, בהתאם לתמיכת הציוד. lock מסייע למנוע התנגשות עם סשן אחר על אותו datastore, אבל אינו נועל את כל הרשת ואינו מנגנון אבטחת מידע בפני עצמו.

בציוד שתומך ב־confirmed-commit אפשר לבצע שינוי שיבוטל אם לא יתקבל אישור בזמן. זה שימושי במיוחד כשהשינוי עלול לנתק את ערוץ הניהול. עם זאת, זו יכולת אופציונלית. צריך לוודא שגם ההתקן וגם הכלי שבו בחרנו מאפשרים את זרימת העבודה הרצויה; מודול netconf_config אינו הבטחה ל־confirmed-commit אוטומטי.

איך בונים פריסה עם Ansible שאפשר לסמוך עליה?

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

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

כאשר המודול והפלטפורמה תומכים בכך, משתמשים ב־check mode וב־diff כדי לבחון מה צפוי להשתנות. לא מציגים אותם כתחליף לבדיקה אמיתית: התמיכה משתנה בין מודולים, ובדיקת תחביר אינה מגלה שכל שרת זמן חסום ב־Firewall. במודול netconf_config האפשרות backup שומרת את ה־running לפני השינוי כשמפעילים אותה במפורש; היא אינה מבצעת שחזור אוטומטי.

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

הדוגמה הבאה שולפת את ה־running באמצעות ansible.netcommon.netconf_get ושומרת עותק מקומי, בלי לשנות הגדרות בציוד. היא מניחה Inventory וקבוצת netconf_devices שהוגדרו מראש, חיבור NETCONF והרשאות קריאה מתאימות. נדרשים אוסף ansible.netcommon והספרייה ncclient בסביבת הבקרה, בהתאם לתיעוד הגרסה.

---
- name: Read running configuration
  hosts: netconf_devices
  gather_facts: false
  serial: 5
  any_errors_fatal: true
  vars:
    ansible_connection: ansible.netcommon.netconf
  tasks:
    - name: Retrieve running datastore
      ansible.netcommon.netconf_get:
        source: running
      register: running_reply
      no_log: true

    - name: Save configuration on the controller
      ansible.builtin.copy:
        content: "{{ running_reply.stdout }}"
        dest: "./backups/{{ inventory_hostname }}.xml"
        mode: "0600"
      delegate_to: localhost
      no_log: true

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

איפה Python נכנס אם כבר יש Ansible?

Python מתאים כשצריך לוגיקה או אינטגרציה מותאמת: למשוך רשימת התקנים ממערכת מלאי, לקרוא מידע מ־API, להשוות תוצאה למקור אמת או לייצר דוח חריגים. עם ncclient אפשר לעבוד מול NETCONF; עם ספריות אחרות אפשר לעבוד מול APIs או CLI. אין חובה לכתוב מחדש ב־Python משהו שמודול Ansible נתמך כבר מבצע היטב.

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

המשימה הצליחה. האם NTP באמת עובד?

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

show running-config | include ntp
show ntp associations
show ntp status
show ip route 192.0.2.10

שאלת ההמשך: מה אם 37 התקנים עודכנו וההתקן הבא נכשל?

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

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

מה כדאי ללמוד כדי לענות מתוך הבנה, ולא מתוך שינון?

מי שמגיע מעולם הרשתות לא צריך להפוך ביום אחד למפתח תוכנה. כדאי להתחיל ממבני נתונים, פונקציות, קבצים וטיפול בשגיאות ב־Python, ולצד זה לחזק הבנה של VLAN, ניתוב, ACL, NAT ו־VPN. אחרי שהבסיס קיים, אפשר לקרוא תיעוד של NETCONF, לעבוד עם YANG ולהוסיף Playbooks שמבצעים משימה מוגדרת במעבדה.

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

מקורות מקצועיים להעמקה