يقدم الإصدار القادم من Red Hat Ansible Engine 2.9 تحسينات مثيرة، سيتم تناول بعضها في هذه المقالة. كما هو الحال دائمًا، قمنا بتطوير تحسينات Ansible Network بشكل مفتوح، بدعم من المجتمع. انضم إلينا – ألق نظرة ودراسة الخطة التطويرية لها على صفحة الويكي ل .
كما أعلنا مؤخرا، يتضمن الآن Ansible Tower وAnsible Engine وجميع محتويات Ansible Network. في الوقت الحاضر، يتم تنفيذ منصات الشبكات الأكثر شيوعًا من خلال وحدات Ansible. على سبيل المثال:
- أريستا إيوس
- سيسكو IOS
- سيسكو IOS XR
- نظام Cisco NX-OS
- جونيبر جونوس
- فيوس
للحصول على قائمة كاملة بالمنصات التي تدعمها Red Hat بالكامل من خلال اشتراك Ansible Automation، .
ماذا تعلمنا
على مدى السنوات الأربع الماضية، تعلمنا الكثير حول تطوير منصة التشغيل الآلي للشبكة. لقد تعلمنا ذلك أيضًا كيف يتم استخدام عناصر النظام الأساسي في قواعد اللعب والأدوار الخاصة بـ Ansible بواسطة المستخدمين النهائيين. وهذا ما اكتشفناه:
- تقوم المؤسسات بأتمتة الأجهزة ليس من مورد واحد فقط، بل من العديد من البائعين.
- إن الأتمتة ليست مجرد ظاهرة تقنية، ولكنها ظاهرة ثقافية أيضًا.
- تعد أتمتة الشبكات على نطاق واسع أكثر صعوبة مما تبدو عليه بسبب المبادئ المعمارية الأساسية لتصميم الأتمتة.
عندما ناقشنا خطط النمو طويلة المدى لدينا منذ أكثر من عام، طلب عملاؤنا من الشركات ما يلي:
- يجب أن تكون عملية جمع الحقائق موحدة ومتوافقة بشكل أفضل مع سير عمل الأتمتة عبر جميع الأجهزة.
- يجب أيضًا أن يكون تحديث التكوينات على الجهاز موحدًا ومتسقًا حتى تتمكن وحدات Ansible من التعامل مع النصف الثاني من الدورة بعد جمع الحقائق.
- نحن بحاجة إلى أساليب صارمة ومدعومة لتحويل تكوين الجهاز إلى بيانات منظمة. وعلى هذا الأساس يمكن نقل مصدر الحقيقة من جهاز الشبكة.
تحسينات الواقع
غالبًا ما يتم جمع الحقائق من أجهزة الشبكة باستخدام Ansible بشكل عشوائي. تتمتع المنصات المستندة إلى الويب بدرجات متفاوتة من قدرات جمع الحقائق، ولكن لديها وظائف قليلة أو معدومة لتحليل وتوحيد تمثيل البيانات في أزواج القيمة الرئيسية. يقرأ كين سيلينزا يتحدث عن مدى صعوبة وألم تحليل البيانات الواقعية وتوحيدها.
ربما لاحظت أننا نعمل على دور Ansible Network Engine. وبطبيعة الحال، بعد تنزيلات تبلغ 24 ألفًا لاحقًا، أصبح دور Network Engine سريعًا واحدًا من أكثر أدوار Ansible شيوعًا في Ansible Galaxy لسيناريوهات أتمتة الشبكة. قبل أن ننقل الكثير من هذا إلى Ansible 2.8 للتحضير لما هو مطلوب في Ansible 2.9، قدم دور Ansible هذا المجموعة الأولى من الأدوات للمساعدة في تحليل الأوامر، وإدارة الأوامر، وجمع البيانات لأجهزة الشبكة.
إذا كنت تعرف كيفية استخدام Network Engine، فهذه طريقة فعالة جدًا لجمع بيانات الحقيقة وتحليلها وتوحيدها لاستخدامها في Ansible. عيب هذا الدور هو أنك تحتاج إلى إنشاء مجموعة كاملة من المحللين لكل نظام أساسي ولجميع أنشطة الشبكة. لفهم مدى صعوبة إنشاء الموزعين وإرسالهم وصيانتهم، قم بإلقاء نظرة على من الرجال في سيسكو.
باختصار، يعد الحصول على الحقائق من الأجهزة وتطبيعها في أزواج ذات قيمة أساسية أمرًا ضروريًا للأتمتة على نطاق واسع، ولكن تحقيق ذلك أمر صعب عندما يكون لديك العديد من البائعين ومنصات الشبكة.
يمكن الآن لكل وحدة حقيقة شبكة في 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: يتم تشغيل أي أوامر تكوين على الجهاز لإعادته إلى الحالة المطلوبة.
ماذا يعني كل هذا؟ لماذا هو مهم؟
يغطي هذا المنشور الكثير من المفاهيم المعقدة، ولكننا نأمل أن يكون لديك في النهاية فهم أفضل لما يطلبه عملاء المؤسسة في الواقع من جمع البيانات وتطبيعها وتكوين الحلقة لمنصة التشغيل الآلي. لكن لماذا يحتاجون إلى هذه التحسينات؟ تسعى العديد من المؤسسات الآن إلى التحول الرقمي لجعل بيئات تكنولوجيا المعلومات الخاصة بها أكثر مرونة وتنافسية. للأفضل أو للأسوأ، يصبح العديد من مهندسي الشبكات مطوري شبكات إما من باب المصلحة الذاتية أو بناءً على طلب الإدارة.
تدرك المؤسسات أن أتمتة قوالب الشبكات الفردية لا تحل مشكلة الصوامع وتزيد فقط من الكفاءة إلى حد معين. يوفر 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- من شبكات المتطرفة.nxos_bfd_interfaces- من سيسكوnxos_telemetry- من سيسكو
كما ترون، فإن مفهوم وحدات الموارد يتناسب مع إستراتيجيتنا التي تركز على النظام الأساسي. أي أننا نقوم بتضمين القدرات والوظائف اللازمة في Ansible نفسها لدعم التقييس في تطوير وحدات الشبكة، وكذلك لتبسيط عمل المستخدمين على مستوى أدوار Ansible وقواعد اللعبة. لتوسيع تطوير وحدات الموارد، أصدر فريق Ansible أداة Module Builder.
خطط لـ Ansible 2.10 وما بعده
بمجرد إصدار Ansible 2.9، سنعمل على المجموعة التالية من وحدات الموارد لـ Ansible 2.10، والتي يمكن استخدامها لتكوين طوبولوجيا الشبكة وسياستها بشكل أكبر، على سبيل المثال. . لا يزال من الممكن تعديل خطة التطوير، لذا إذا كانت لديك تعليقات، فيرجى الإبلاغ عنها .
الموارد والبدء
المصدر: www.habr.com