Red Hat Ansible Engine 2.9 ที่กำลังจะเปิดตัวเร็วๆ นี้มาพร้อมกับการปรับปรุงที่น่าตื่นเต้น ซึ่งบางส่วนได้กล่าวถึงในบทความนี้ เช่นเคย เราได้พัฒนาการปรับปรุง Ansible Network อย่างเปิดเผยด้วยการสนับสนุนจากชุมชน เข้าร่วมกับเรา - ลองดูที่ และศึกษาแผนการพัฒนาสำหรับ ในหน้าวิกิสำหรับ .
ดังที่เราได้ประกาศไปเมื่อเร็วๆ นี้ ตอนนี้รวม Ansible Tower, Ansible Engine และเนื้อหา Ansible Network ทั้งหมด ในปัจจุบัน แพลตฟอร์มเครือข่ายที่ได้รับความนิยมส่วนใหญ่มีการใช้งานผ่านโมดูล Ansible ตัวอย่างเช่น:
- อริสต้า EOS
- ซิสโก้ ไอโอเอส
- ซิสโก้ IOS XR
- ซิสโก้ NX-OS
- จูนิเปอร์ จูโนส
- วีโอเอส
หากต้องการดูรายการแพลตฟอร์มทั้งหมดที่รองรับโดย Red Hat ผ่านการสมัครสมาชิก Ansible Automation .
เราได้เรียนรู้อะไรบ้าง
ในช่วงสี่ปีที่ผ่านมา เราได้เรียนรู้มากมายเกี่ยวกับการพัฒนาแพลตฟอร์มระบบเครือข่ายอัตโนมัติ เราก็ได้เรียนรู้เช่นกัน ในขณะที่ สิ่งประดิษฐ์ของแพลตฟอร์มถูกใช้ใน Playbooks และบทบาทของผู้ใช้ปลายทาง และนี่คือสิ่งที่เราค้นพบ:
- องค์กรต่างๆ กำลังดำเนินการอุปกรณ์อัตโนมัติจากผู้จำหน่ายหลายราย
- ระบบอัตโนมัติไม่ได้เป็นเพียงปรากฏการณ์ทางเทคนิคเท่านั้น แต่ยังเป็นปรากฏการณ์ทางวัฒนธรรมด้วย
- เครือข่ายอัตโนมัติในวงกว้างนั้นยากกว่าที่คิด เนื่องจากหลักการทางสถาปัตยกรรมพื้นฐานของการออกแบบระบบอัตโนมัติ
เมื่อเราหารือเกี่ยวกับแผนการเติบโตระยะยาวของเราเมื่อปีที่แล้ว ลูกค้าองค์กรของเราถามสิ่งต่อไปนี้:
- การรวบรวมข้อเท็จจริงต้องมีมาตรฐานที่ดีขึ้นและสอดคล้องกับขั้นตอนการทำงานอัตโนมัติในทุกอุปกรณ์
- การอัปเดตการกำหนดค่าบนอุปกรณ์ยังต้องมีมาตรฐานและสอดคล้องกัน เพื่อให้โมดูล Ansible จัดการครึ่งหลังของวงจรหลังจากรวบรวมข้อเท็จจริง
- เราต้องการวิธีการที่เข้มงวดและได้รับการสนับสนุนในการแปลงการกำหนดค่าอุปกรณ์ให้เป็นข้อมูลที่มีโครงสร้าง บนพื้นฐานนี้ แหล่งที่มาของความจริงสามารถย้ายจากอุปกรณ์เครือข่ายได้
การปรับปรุงข้อเท็จจริง
การรวบรวมข้อเท็จจริงจากอุปกรณ์เครือข่ายโดยใช้ Ansible มักจะเกิดขึ้นแบบสุ่ม แพลตฟอร์มบนเว็บมีความสามารถในการรวบรวมข้อเท็จจริงในระดับที่แตกต่างกัน แต่มีฟังก์ชันการทำงานเพียงเล็กน้อยหรือไม่มีเลยสำหรับการแยกวิเคราะห์และสร้างมาตรฐานการแสดงข้อมูลในคู่คีย์-ค่า อ่าน Ken Celenza พูดถึงความยากลำบากและความเจ็บปวดในการวิเคราะห์และสร้างมาตรฐานของข้อมูลข้อเท็จจริง
คุณอาจสังเกตเห็นว่าเรากำลังทำงานในบทบาท Ansible Network Engine โดยปกติแล้ว การดาวน์โหลด 24K ในภายหลัง บทบาท Network Engine ได้กลายเป็นหนึ่งในบทบาท Ansible ที่ได้รับความนิยมมากที่สุดใน Ansible Galaxy สำหรับสถานการณ์เครือข่ายอัตโนมัติอย่างรวดเร็ว ก่อนที่เราจะย้ายสิ่งเหล่านี้ไปไว้ใน Ansible 2.8 เพื่อเตรียมพร้อมสำหรับสิ่งที่จำเป็นใน Ansible 2.9 บทบาท Ansible นี้มอบชุดเครื่องมือชุดแรกเพื่อช่วยแยกวิเคราะห์คำสั่ง จัดการคำสั่ง และรวบรวมข้อมูลสำหรับอุปกรณ์เครือข่าย
หากคุณรู้วิธีใช้ Network Engine นี่เป็นวิธีที่มีประสิทธิภาพมากในการรวบรวม แยกวิเคราะห์ และสร้างมาตรฐานข้อมูลข้อเท็จจริงเพื่อใช้ใน Ansible ข้อเสียของบทบาทนี้คือคุณต้องสร้าง parsers ทั้งหมดสำหรับแต่ละแพลตฟอร์มและสำหรับกิจกรรมเครือข่ายทั้งหมด หากต้องการทำความเข้าใจว่าการสร้าง จัดส่ง และบำรุงรักษา parsers นั้นยากเพียงใด โปรดดูที่ จากทีมงานที่ Cisco
โดยสรุป การได้รับข้อเท็จจริงจากอุปกรณ์และการปรับให้เป็นคู่คีย์-ค่าให้เป็นมาตรฐานถือเป็นสิ่งสำคัญสำหรับระบบอัตโนมัติในวงกว้าง แต่การบรรลุเป้าหมายนี้เป็นเรื่องยากเมื่อคุณมีผู้จำหน่ายและแพลตฟอร์มเครือข่ายจำนวนมาก
โมดูลข้อเท็จจริงเครือข่ายแต่ละโมดูลใน Ansible 2.9 สามารถวิเคราะห์การกำหนดค่าของอุปกรณ์เครือข่ายและส่งคืนข้อมูลที่มีโครงสร้างได้โดยไม่ต้องมีไลบรารีเพิ่มเติม บทบาท Ansible หรือตัวแยกวิเคราะห์ที่กำหนดเอง
ตั้งแต่ Ansible 2.9 แต่ละครั้งที่มีการเผยแพร่โมดูลเครือข่ายที่อัปเดต โมดูลข้อเท็จจริงจะได้รับการปรับปรุงเพื่อให้ข้อมูลเกี่ยวกับการกำหนดค่าส่วนนี้ นั่นคือการพัฒนาข้อเท็จจริงและโมดูลต่างๆ เกิดขึ้นในเวลาเดียวกัน และจะมีโครงสร้างข้อมูลร่วมกันอยู่เสมอ
การกำหนดค่าทรัพยากรบนอุปกรณ์เครือข่ายสามารถดึงข้อมูลและแปลงเป็นข้อมูลที่มีโครงสร้างได้สองวิธี ในทั้งสองวิธี คุณสามารถรวบรวมและแปลงรายการทรัพยากรเฉพาะโดยใช้คำสำคัญใหม่ gather_network_resources. ชื่อทรัพยากรตรงกับชื่อโมดูล ซึ่งสะดวกมาก
ขณะรวบรวมข้อเท็จจริง:
การใช้คำสำคัญ gather_facts คุณสามารถเรียกข้อมูลการกำหนดค่าอุปกรณ์ปัจจุบันได้ที่ตอนต้นของ Playbook แล้วใช้ตลอด Playbook ทั้งหมด ระบุทรัพยากรแต่ละรายการที่จะดึงข้อมูลจากอุปกรณ์
- 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:
- interfacesPlaybook ส่งคืนข้อเท็จจริงต่อไปนี้เกี่ยวกับอินเทอร์เฟซ:
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 โดยไม่มีการประมวลผลหรือการแปลงเพิ่มเติม
โมดูลทรัพยากร
ดังนั้นเราจึงแยกข้อเท็จจริง ทำให้ข้อมูลเป็นมาตรฐาน นำมาใส่ลงในไดอะแกรมโครงสร้างข้อมูลภายในที่ได้มาตรฐาน และได้รับแหล่งที่มาของความจริงที่พร้อมใช้งาน ไชโย! แน่นอนว่านี่เป็นสิ่งที่ดี แต่เรายังคงต้องแปลงคู่คีย์-ค่ากลับไปเป็นการกำหนดค่าเฉพาะที่แพลตฟอร์มอุปกรณ์เฉพาะคาดหวัง ขณะนี้เราต้องการโมดูลเฉพาะแพลตฟอร์มเพื่อให้เป็นไปตามข้อกำหนดการรวบรวมข้อเท็จจริงและการปรับมาตรฐานใหม่เหล่านี้
โมดูลทรัพยากรคืออะไร? คุณสามารถนึกถึงส่วนการกำหนดค่าของอุปกรณ์ว่าเป็นทรัพยากรที่อุปกรณ์นั้นมอบให้ โมดูลทรัพยากรเครือข่ายถูกจำกัดไว้เพียงทรัพยากรเดียวโดยเจตนา และสามารถซ้อนกันได้เหมือนแบบเอกสารสำเร็จรูปเพื่อกำหนดค่าบริการเครือข่ายที่ซับซ้อน ด้วยเหตุนี้ ข้อกำหนดและข้อกำหนดสำหรับโมดูลทรัพยากรจึงง่ายขึ้นตามธรรมชาติ เนื่องจากโมดูลทรัพยากรสามารถอ่านได้ и กำหนดค่าบริการเครือข่ายเฉพาะบนอุปกรณ์เครือข่าย
เพื่ออธิบายว่าโมดูลทรัพยากรทำอะไร ลองดูตัวอย่าง Playbook ที่แสดงการดำเนินการ idempodent โดยใช้ข้อเท็จจริงและโมดูลทรัพยากรเครือข่ายใหม่ 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อย่างที่คุณเห็น ข้อมูลที่รวบรวมจากอุปกรณ์จะถูกถ่ายโอนโดยตรงไปยังโมดูลทรัพยากรที่เกี่ยวข้องโดยไม่มีการแปลง เมื่อเปิดตัว Playbook จะดึงค่าจากอุปกรณ์และเปรียบเทียบกับค่าที่คาดหวัง ในตัวอย่างนี้ ค่าที่ส่งคืนเป็นไปตามที่คาดไว้ (นั่นคือ จะตรวจสอบความเบี่ยงเบนของการกำหนดค่า) และรายงานว่าการกำหนดค่ามีการเปลี่ยนแปลงหรือไม่
วิธีที่เหมาะสมที่สุดในการตรวจจับการเบี่ยงเบนของการกำหนดค่าคือการจัดเก็บข้อเท็จจริงในตัวแปรที่จัดเก็บ Ansible และใช้ข้อมูลเหล่านี้เป็นระยะๆ กับโมดูลทรัพยากรในโหมดการตรวจสอบ นี่เป็นวิธีง่ายๆ ในการดูว่ามีคนเปลี่ยนค่าด้วยตนเองหรือไม่ ในกรณีส่วนใหญ่ องค์กรอนุญาตให้เปลี่ยนแปลงและกำหนดค่าได้ด้วยตนเอง แม้ว่าการดำเนินการหลายอย่างจะดำเนินการผ่าน Ansible Automation ก็ตาม
โมดูลทรัพยากรใหม่แตกต่างจากโมดูลก่อนหน้าอย่างไร
สำหรับวิศวกรระบบอัตโนมัติของเครือข่าย มีความแตกต่างหลัก 3 ประการระหว่างโมดูลทรัพยากรใน Ansible 2.9 และเวอร์ชันก่อนหน้า
1) สำหรับทรัพยากรเครือข่ายที่กำหนด (ซึ่งอาจถือเป็นส่วนการกำหนดค่า) โมดูลและข้อเท็จจริงจะมีการพัฒนาไปทั่วทั้งระบบปฏิบัติการเครือข่ายที่รองรับทั้งหมดพร้อมกัน เราคิดว่าหาก Ansible รองรับการกำหนดค่าทรัพยากรบนแพลตฟอร์มเครือข่ายเดียว เราควรรองรับทุกที่ สิ่งนี้ทำให้การใช้โมดูลทรัพยากรง่ายขึ้น เนื่องจากวิศวกรระบบเครือข่ายอัตโนมัติสามารถกำหนดค่าทรัพยากร (เช่น LLDP) บนระบบปฏิบัติการเครือข่ายทั้งหมดด้วยโมดูลดั้งเดิมและโมดูลที่รองรับ
2) โมดูลทรัพยากรตอนนี้มีค่าสถานะ
merged: การกำหนดค่าถูกรวมเข้ากับการกำหนดค่าที่ให้ไว้ (ค่าเริ่มต้น)replaced: การกำหนดค่าทรัพยากรจะถูกแทนที่ด้วยการกำหนดค่าที่ให้ไว้overridden: การกำหนดค่าทรัพยากรจะถูกแทนที่ด้วยการกำหนดค่าที่ให้ไว้ อินสแตนซ์ทรัพยากรที่ไม่จำเป็นจะถูกลบdeleted: การกำหนดค่าทรัพยากรจะถูกลบ/กู้คืนเป็นค่าเริ่มต้น
3) โมดูลทรัพยากรตอนนี้มีค่าส่งคืนที่เสถียร เมื่อโมดูลทรัพยากรเครือข่ายได้ทำ (หรือเสนอ) การเปลี่ยนแปลงที่จำเป็นกับอุปกรณ์เครือข่าย โมดูลจะส่งคืนคู่คีย์-ค่าเดียวกันไปยัง Playbook
before: การกำหนดค่าบนอุปกรณ์ในรูปแบบของข้อมูลที่มีโครงสร้างก่อนงานafter: หากอุปกรณ์มีการเปลี่ยนแปลง (หรืออาจเปลี่ยนแปลงหากใช้โหมดทดสอบ) การกำหนดค่าผลลัพธ์จะถูกส่งกลับเป็นข้อมูลที่มีโครงสร้างcommands: คำสั่งการกำหนดค่าใด ๆ ที่ทำงานบนอุปกรณ์เพื่อให้อยู่ในสถานะที่ต้องการ
ทั้งหมดนี้หมายความว่าอย่างไร? ทำไมมันถึงสำคัญ?
โพสต์นี้ครอบคลุมแนวคิดที่ซับซ้อนมากมาย แต่เราหวังว่าท้ายที่สุดแล้ว คุณจะมีความเข้าใจที่ดีขึ้นเกี่ยวกับสิ่งที่ลูกค้าองค์กรต้องการในการรวบรวมข้อเท็จจริง การทำให้ข้อมูลเป็นมาตรฐาน และการกำหนดค่าแบบวนซ้ำสำหรับแพลตฟอร์มอัตโนมัติ แต่ทำไมพวกเขาถึงต้องการการปรับปรุงเหล่านี้? ขณะนี้หลายองค์กรกำลังดำเนินการเปลี่ยนแปลงทางดิจิทัลเพื่อทำให้สภาพแวดล้อมด้านไอทีมีความคล่องตัวและแข่งขันได้มากขึ้น ไม่ว่าจะดีขึ้นหรือแย่ลง วิศวกรเครือข่ายจำนวนมากกลายเป็นนักพัฒนาเครือข่ายโดยไม่สนใจตนเองหรือตามคำสั่งของฝ่ายบริหาร
องค์กรต่างๆ ตระหนักดีว่าการทำให้เทมเพลตเครือข่ายแต่ละแบบเป็นแบบอัตโนมัติไม่สามารถแก้ปัญหาไซโลได้ แต่จะเพิ่มประสิทธิภาพได้ในระดับหนึ่งเท่านั้น แพลตฟอร์ม Red Hat Ansible Automation Platform นำเสนอโมเดลข้อมูลทรัพยากรเชิงบรรทัดฐานที่เข้มงวดและเข้มงวด เพื่อจัดการข้อมูลพื้นฐานบนอุปกรณ์เครือข่ายโดยทางโปรแกรม นั่นคือ ผู้ใช้จะค่อยๆ ละทิ้งวิธีการกำหนดค่าแต่ละวิธี หันไปใช้วิธีที่ทันสมัยกว่าโดยเน้นไปที่เทคโนโลยี (เช่น ที่อยู่ IP, VLAN, LLDP เป็นต้น) แทนที่จะใช้วิธีการใช้งานของผู้จำหน่ายรายใดรายหนึ่ง
นี่หมายความว่าจำนวนวันของโมดูลคำสั่งและการกำหนดค่าที่เชื่อถือได้และผ่านการพิสูจน์แล้วใช่หรือไม่ ไม่ว่าในกรณีใด โมดูลทรัพยากรเครือข่ายที่คาดหวังจะไม่สามารถใช้ได้ในทุกกรณีหรือสำหรับผู้จำหน่ายทุกราย ดังนั้นวิศวกรเครือข่ายยังคงต้องการโมดูลคำสั่งและการกำหนดค่าสำหรับการใช้งานบางอย่าง วัตถุประสงค์ของโมดูลทรัพยากรคือเพื่อลดความซับซ้อนของเทมเพลต Jinja ขนาดใหญ่ และปรับการกำหนดค่าอุปกรณ์ที่ไม่มีโครงสร้างให้เป็นมาตรฐานในรูปแบบ JSON ที่มีโครงสร้าง ด้วยโมดูลทรัพยากร เครือข่ายที่มีอยู่จะสามารถเปลี่ยนการกำหนดค่าให้เป็นคู่คีย์-ค่าที่มีโครงสร้างซึ่งแสดงถึงแหล่งที่มาของความจริงที่อ่านง่ายได้ง่ายขึ้น ด้วยการใช้คู่คีย์-ค่าที่มีโครงสร้าง คุณสามารถย้ายจากการกำหนดค่าที่ใช้งานบนอุปกรณ์แต่ละเครื่องไปเป็นการทำงานกับข้อมูลที่มีโครงสร้างอิสระ และนำเครือข่ายไปสู่แนวหน้าของแนวทางโครงสร้างพื้นฐานตามโค้ด
โมดูลทรัพยากรใดบ้างที่จะมาใน Ansible Engine 2.9
ก่อนที่เราจะบอกคุณโดยละเอียดว่าจะเกิดอะไรขึ้นใน Ansible 2.9 เรามาจำไว้ว่าเราแบ่งขอบเขตงานทั้งหมดอย่างไร
เราระบุ 7 หมวดหมู่และมอบหมายทรัพยากรเครือข่ายเฉพาะให้กับแต่ละหมวดหมู่:
หมายเหตุ: ทรัพยากรที่เป็นตัวหนาได้รับการวางแผนและนำไปใช้ใน Ansible 2.9
ตามคำติชมจากลูกค้าองค์กรและชุมชน อันดับแรกจึงควรจัดการกับโมดูลที่เกี่ยวข้องกับโปรโตคอลโทโพโลยีเครือข่าย การจำลองเสมือน และอินเทอร์เฟซ
โมดูลทรัพยากรต่อไปนี้ได้รับการพัฒนาโดยทีมงาน Ansible Network และสอดคล้องกับแพลตฟอร์มที่ Red Hat รองรับ:
โมดูลต่อไปนี้ได้รับการพัฒนาโดยชุมชน Ansible:
exos_lldp_global- จาก Extreme Networksnxos_bfd_interfaces- จากซิสโก้nxos_telemetry- จากซิสโก้
อย่างที่คุณเห็น แนวคิดของโมดูลทรัพยากรเหมาะสมกับกลยุทธ์ที่เน้นแพลตฟอร์มเป็นศูนย์กลางของเรา นั่นคือเราได้รวมความสามารถและฟังก์ชันที่จำเป็นไว้ใน Ansible เพื่อรองรับการกำหนดมาตรฐานในการพัฒนาโมดูลเครือข่าย และยังทำให้การทำงานของผู้ใช้ในระดับบทบาทและ Playbooks ของ Ansible ง่ายขึ้นอีกด้วย เพื่อขยายการพัฒนาโมดูลทรัพยากร ทีม Ansible ได้เปิดตัวเครื่องมือตัวสร้างโมดูล
แผนสำหรับ Ansible 2.10 ขึ้นไป
เมื่อ Ansible 2.9 เปิดตัว เราจะทำงานกับโมดูลทรัพยากรชุดถัดไปสำหรับ Ansible 2.10 ซึ่งสามารถใช้เพื่อกำหนดค่าโทโพโลยีเครือข่ายและนโยบายเพิ่มเติม เช่น . แผนการพัฒนายังคงสามารถปรับได้ ดังนั้น หากมีความคิดเห็นกรุณารายงานได้ที่ .
ทรัพยากรและการเริ่มต้น
ที่มา: will.com