الداخل Playbook. ميزات الشبكة في محرك Ansible الجديد 2.9

الإصدار القادم من Red Hat Ansible Engine 2.9 في انتظارك مع تحسينات رائعة ، بعضها موصوف في هذه المقالة. كالعادة ، قمنا بتطوير تحسينات Ansible Network بشكل مفتوح ، بدعم من المجتمع. انضم - ألق نظرة على لوحة المهام على جيثب ودراسة خطة التطوير لإصدار Red Hat Ansible Engine 2.9 على صفحة wiki لشبكة Ansible Network .

كما أعلنا مؤخرًا ، تضم منصة Red Hat Ansible Automation Platform الآن Ansible Tower و Ansible Engine وجميع محتويات Ansible Network. الآن ، يتم تطبيق منصات الشبكة الأكثر شعبية من خلال وحدات Ansible. على سبيل المثال:

• أريستا eos
• سيسكو IOS
• Cisco IOS XR
• Cisco NX-OS
• جونيبر جونوس
• VyOS

تتوفر هنا قائمة كاملة بالمنصات التي تدعمها Red Hat بالكامل من خلال Ansible Automation.

ماذا تعلمنا

خلال السنوات الأربع الماضية ، تعلمنا الكثير عن تطوير منصة لأتمتة الشبكة. لقد تعلمنا أيضًا كيف يلعب المستخدمون النهائيون الأعمال الفنية للنظام الأساسي في كتب وأدوار Ansible. وهنا ما اكتشفناه:

• تقوم المؤسسات بأتمتة الأجهزة ليس فقط واحدة ، ولكن أيضًا العديد من البائعين.
• الأتمتة ليست مجرد ظاهرة فنية ، ولكنها أيضًا ظاهرة ثقافية.
• تعد أتمتة الشبكات على نطاق واسع أكثر تعقيدًا مما يبدو ، نظرًا للمبادئ المعمارية الأساسية لتصميم الأتمتة.

عندما ناقشنا خطط التطوير طويلة الأجل الخاصة بنا منذ أكثر من عام ، طلب عملاؤنا من الشركات ما يلي:

• يحتاج جمع الحقائق إلى توحيد ومواءمة أفضل مع سير عمل الأتمتة لأي جهاز.
• يحتاج تحديث التكوينات على الجهاز أيضًا إلى توحيد وتنسيق بحيث تعالج وحدات Ansible النصف الثاني من الدورة بعد جمع الحقائق.
• نحتاج إلى طرق صارمة ومدعومة لتحويل تكوين الجهاز إلى بيانات منظمة. على هذا الأساس ، يمكن نقل مصدر الحقيقة من جهاز الشبكة.

تعزيزات الحقيقة

جمع الحقائق من أجهزة الشبكة باستخدام Ansible يكون غالبًا عشوائيًا. تم تجهيز منصات الشبكة بدرجات متفاوتة مع القدرة على جمع الحقائق ، لكن ليس لديها أي وظائف تقريبًا - أو حتى لا شيء على الإطلاق - لتحليل وتوحيد عرض البيانات في أزواج القيمة الرئيسية. اقرأ مقالة كين سيلينزا حول مدى صعوبة وألم تحليل البيانات الواقعية وتوحيدها.

ربما لاحظت كيف عملنا في دور Ansible Network Engine. وبطبيعة الحال ، بعد 24000 عملية تنزيل ، أصبح دور Network Engine بسرعة أحد أدوار Ansible الأكثر شهرة في Ansible Galaxy لسيناريوهات أتمتة الشبكة. قبل نقلنا الكثير من هذا إلى Ansible 2.8 ، من أجل التحضير لما يحتاجه Ansible 2.9 ، قدم هذا الدور Ansible المجموعة الأولى من الأدوات للمساعدة في تحليل الأوامر وإدارة الأوامر وجمع البيانات لأجهزة الشبكة.

إذا كنت جيدًا في استخدام Network Engine ، فهذه طريقة فعالة للغاية لجمع بيانات الحقائق وتحليلها وتوحيدها لاستخدامها مع Ansible. عيب هذا الدور هو أنك تحتاج إلى إنشاء مجموعة كاملة من المحللون لكل منصة ولكل نشاط الشبكة. لفهم مدى صعوبة إنشاء المحللون وشحنه وصيانته ، انظر إلى أكثر من 1200 محلل من اللاعبين في Cisco.

باختصار ، من المهم جدًا لتلقي الحقائق من الأجهزة وتفعيلها في أزواج ذات قيمة أساسية ، من أجل التشغيل الآلي على نطاق واسع ، ولكن من الصعب تحقيق ذلك عندما يكون لديك العديد من البائعين ومنصات الشبكة.

يمكن الآن لكل وحدة نمطية لحقيقة الشبكة في Ansible 2.9 تحليل تكوين جهاز الشبكة وإرجاع البيانات المنظمة - بدون مكتبات إضافية أو أدوار Ansible أو موزعيها المخصصين.

بدءًا من Ansible 2.9 ، مع كل إصدار من وحدة الشبكة المحدّثة ، تم تحسين وحدة الحقائق لتوفير معلومات حول قسم التكوين هذا. أي أن تطور الحقائق والوحدات النمطية يحدث الآن بنفس السرعة ، وسيكون لديهم دائمًا بنية بيانات مشتركة.

يمكن استخراج تكوين المورد على جهاز الشبكة وتحويله إلى بيانات منظمة بطريقتين. في كلا الاتجاهين ، يمكنك ترجمة وتحويل قائمة محددة من الموارد باستخدام gather_network_resources الجديدة 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: - interfaces 

يعرض playbook الحقائق التالية حول الواجهة:

 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_interfaces دون معالجة إضافية أو تحويل.

وحدات الموارد

لذلك ، قمنا باستخراج الحقائق ، وتطبيع البيانات ، وإدخالها في مخطط داخلي موحد لهيكل البيانات ، وحصلنا على مصدر حقيقي للحقيقة. الصيحة! هذا أمر رائع بالطبع ، لكننا ما زلنا بحاجة إلى تحويل أزواج قيمة المفتاح بطريقة ما إلى التكوين المحدد الذي تتوقعه منصة جهاز معينة. نحتاج الآن إلى وحدات لأنظمة تشغيل محددة لتلبية متطلبات جمع الحقائق الجديدة وتطبيعها.

ما هي وحدة الموارد؟ يمكن اعتبار أقسام تكوين الجهاز بمثابة الموارد التي يوفرها هذا الجهاز. تقتصر وحدات موارد الشبكة عن قصد على مورد واحد ، ويمكن تكديسها مثل الطوب لتكوين خدمات الشبكة المعقدة. نتيجة لذلك ، يتم تبسيط متطلبات وحدة الموارد ومواصفاتها بشكل طبيعي ، لأن وحدة الموارد يمكنها قراءة وتكوين خدمة شبكة محددة على جهاز شبكة.

لشرح ما تقوم به وحدة الموارد ، دعونا ننظر إلى مثال للكتاب الذي يعرض عملية idempoent باستخدام حقائق جديدة من مورد شبكة 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) تتضمن وحدات الموارد الآن قيم الإرجاع المستقرة. عندما تقوم وحدة موارد الشبكة (أو تقترح) بإجراء التغييرات اللازمة على جهاز الشبكة ، فإنها تقوم بإرجاع أزواج قيمة المفتاح نفسها إلى playbook.

• before : التكوين على الجهاز في شكل بيانات منظمة قبل المهمة ؛
• after : إذا كان الجهاز قد تغير (أو قد يتغير إذا تم استخدام وضع التحقق) ، فسيتم إرجاع التكوين الناتج في شكل بيانات منظمة ؛
• commands : أي أوامر تكوين تعمل على الجهاز لإحضارها إلى الحالة المطلوبة.

ماذا يعني كل هذا؟ لماذا هذا مهم؟

يصف هذا المنشور الكثير من المفاهيم المعقدة ، لكننا نأمل في النهاية أن تفهم بشكل أفضل أن عملاء الشركات يطلبون الحقائق وتطبيع البيانات وتهيئة الحلقة لمنصة التشغيل الآلي. ولكن لماذا يحتاجون إلى هذه التحسينات؟ تشارك العديد من المؤسسات الآن في التحول الرقمي لجعل بيئات تكنولوجيا المعلومات لديها أكثر مرونة وتنافسية. للأفضل أو الأسوأ ، أصبح العديد من مهندسي الشبكات من مطوري الشبكات ، إما لمصلحتهم الخاصة أو بناءً على طلب من المديرين.

تدرك المؤسسات أن أتمتة قوالب الشبكات الفردية لا يحل مشكلة التجزئة ولا يؤدي إلا إلى زيادة الكفاءة إلى حد معين. يوفر Red Hat Ansible Automation Platform نماذج بيانات موارد دقيقة ومعيارية لإدارة البيانات الأساسية على جهاز شبكة برمجياً. وهذا يعني أن المستخدمين يتخلون تدريجياً عن أساليب التكوين الفردية لصالح الأساليب الأكثر حداثة مع التركيز على التقنيات (على سبيل المثال ، عناوين IP ، VLAN ، LLDP ، وما إلى ذلك) ، وليس على تنفيذ بائع معين.

هل هذا يعني أن أيام وحدات التكوينات الموثوقة والمثبتة يتم ترقيمها؟ لا مفر لن تكون وحدات موارد الشبكة المتوقعة قابلة للتطبيق في جميع الحالات وليس لكل مورد ، لذلك سيظل مهندسو الشبكة بحاجة إلى وحدات القيادة والتهيئة لتنفيذات معينة. الغرض من وحدات الموارد هو تبسيط قوالب Jinja الكبيرة وتهيئة تكوينات الأجهزة غير المهيكلة في تنسيق JSON منظم. باستخدام وحدات الموارد ، سيكون من الأسهل على الشبكات الحالية تحويل تكوينها إلى أزواج محددة القيمة ذات قيمة مفتاح والتي ستكون مصدرًا للحقيقة يسهل قراءته. إذا كنت تستخدم أزواج مفاتيح ذات قيمة مهيكلة ، فيمكنك التبديل من تشغيل التكوينات على كل جهاز إلى العمل باستخدام بيانات منظمة مستقلة وإحضار الشبكات إلى المقدمة باستخدام نهج "البنية التحتية كرمز".

ما هي وحدات الموارد التي ستظهر في محرك Ansible 2.9؟

قبل أن نوضح بالتفصيل ما سيحدث في Ansible 2.9 ، دعنا نتذكر كيف قسمنا حجم العمل بأكمله.

لقد حددنا 7 فئات وكل موارد شبكة محددة مخصصة:

ملاحظة: تم تخطيط وتنفيذ موارد جريئة في Ansible 2.9.
استنادًا إلى تعليقات العملاء من الشركات والمجتمع ، كان من المنطقي أولاً التعامل مع الوحدات النمطية المرتبطة ببروتوكولات طوبولوجيا الشبكة والمحاكاة الافتراضية والواجهات.
تم تطوير وحدات الموارد التالية بواسطة فريق Ansible Network وتتوافق مع الأنظمة الأساسية التي يدعمها Red Hat:

تم تطوير الوحدات التالية بواسطة مجتمع Ansible:

• exos_lldp_global - من الشبكات المتطرفة.
• nxos_bfd_interfaces - من Cisco
• nxos_telemetry - من سيسكو

كما ترون ، يتوافق مفهوم وحدات الموارد مع إستراتيجية توجيه المنصة. أي أننا ندرج الميزات والوظائف الضرورية في Ansible نفسها ، لدعم التقييس في تطوير وحدات الشبكة ، وكذلك لتبسيط عمل المستخدمين على مستوى أدوار Ansible وكتب اللعب. لتوسيع تطوير وحدات الموارد ، أصدر فريق Ansible أداة منشئ الوحدة النمطية.

خطط Ansible 2.10 وما بعده

بعد إصدار Ansible 2.9 ، سنتعامل مع المجموعة التالية من وحدات الموارد لـ Ansible 2.10 ، والتي يمكن استخدامها لزيادة تكوين طوبولوجيا وسياسة الشبكة ، مثل ACL و OSPF و BGP . لا يزال من الممكن تعديل خطة التطوير ، لذلك إذا كانت لديك تعليقات ، فأبلغ عنها إلى مجتمع شبكة Ansible .

الموارد والبدء

Ansible أتمتة منصة بيان صحفي
Ansible أتمتة منصة مدونة
مستقبل تسليم المحتوى في Ansible
تأملات في تغيير هيكل مشروع Ansible