نسخه آتی Red Hat Ansible Engine 2.9 پیشرفت های هیجان انگیزی را به همراه دارد که برخی از آنها در این مقاله مورد بحث قرار گرفته اند. مثل همیشه، ما در حال توسعه بهبودهای شبکه Ansible به صورت آشکار و با پشتیبانی جامعه بوده‌ایم. به ما بپیوندید - نگاهی به و مطالعه طرح توسعه برای در صفحه ویکی برای .
همانطور که اخیرا اعلام کردیم، اکنون شامل Ansible Tower، Ansible Engine و تمام محتوای Ansible Network است. امروزه اکثر پلتفرم های شبکه محبوب از طریق ماژول های Ansible پیاده سازی می شوند. مثلا:
- Arista EOS
- COS IOS
- سیسکو IOS XR
- Cisco NX-OS
- جونیپر جونوس
- VyOS
برای یک لیست کامل از پلتفرم هایی که به طور کامل توسط Red Hat از طریق اشتراک Ansible Automation پشتیبانی می شوند، .
چه آموخته ایم
در طول چهار سال گذشته، ما چیزهای زیادی در مورد توسعه یک پلت فرم اتوماسیون شبکه یاد گرفته ایم. ما هم یاد گرفتیم که مانند مصنوعات پلت فرم در کتاب های بازی و نقش های Ansible توسط کاربران نهایی استفاده می شود. و این چیزی است که ما متوجه شدیم:
- سازمان‌ها دستگاه‌ها را نه تنها از یک، بلکه از بسیاری از فروشندگان خودکار می‌کنند.
- اتوماسیون نه تنها یک پدیده فنی، بلکه یک پدیده فرهنگی است.
- اتوماسیون شبکه ها در مقیاس به دلیل اصول اساسی معماری طراحی اتوماسیون دشوارتر از آن چیزی است که به نظر می رسد.
هنگامی که بیش از یک سال پیش در مورد برنامه های رشد بلندمدت خود صحبت کردیم، مشتریان شرکتی ما موارد زیر را درخواست کردند:
- جمع آوری اطلاعات باید بهتر استاندارد شود و با گردش کار اتوماسیون در همه دستگاه ها هماهنگ شود.
- به‌روزرسانی پیکربندی‌های دستگاه نیز باید استاندارد و سازگار باشد تا ماژول‌های Ansible نیمه دوم چرخه را پس از جمع‌آوری اطلاعات انجام دهند.
- برای تبدیل پیکربندی دستگاه به داده های ساخت یافته به روش های دقیق و پشتیبانی شده نیاز داریم. بر این اساس می توان منبع حقیقت را از دستگاه شبکه منتقل کرد.
بهبود واقعیت
جمع آوری حقایق از دستگاه های شبکه با استفاده از Ansible اغلب به صورت تصادفی اتفاق می افتد. پلتفرم‌های مبتنی بر وب درجات مختلفی از قابلیت‌های جمع‌آوری حقایق را دارند، اما عملکرد کمی برای تجزیه و استاندارد کردن نمایش داده‌ها در جفت‌های کلید-مقدار ندارند. خواندن کن سلنزا در مورد اینکه چقدر تجزیه و تحلیل و استانداردسازی داده های واقعی می تواند دشوار و دردناک باشد.
ممکن است متوجه شده باشید که ما روی نقش Ansible Network Engine کار می کنیم. طبیعتاً بعداً با 24K بارگیری، نقش 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:
- 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 بدون پردازش یا تبدیل اضافی.
ماژول های منابع
بنابراین، ما حقایق را استخراج کردیم، داده ها را نرمال کردیم، آنها را در یک نمودار ساختار داده داخلی استاندارد قرار دادیم و یک منبع آماده از حقیقت دریافت کردیم. هورا! البته این عالی است، اما هنوز باید به نحوی جفت‌های کلید-مقدار را به پیکربندی خاصی که پلتفرم دستگاه خاص انتظار دارد، تبدیل کنیم. ما اکنون به ماژول‌های مخصوص پلتفرم نیاز داریم تا این الزامات جدید جمع‌آوری اطلاعات و عادی‌سازی را برآورده کنیم.
ماژول منبع چیست؟ می‌توانید بخش‌های پیکربندی یک دستگاه را به‌عنوان منابع ارائه‌شده توسط آن دستگاه در نظر بگیرید. ماژول‌های منبع شبکه عمداً به یک منبع محدود می‌شوند و می‌توانند مانند بلوک‌های ساختمانی برای پیکربندی سرویس‌های شبکه پیچیده روی هم قرار گیرند. در نتیجه، الزامات و مشخصات یک ماژول منبع به طور طبیعی ساده شده است، زیرا ماژول منبع می تواند بخواند. и یک سرویس شبکه خاص را روی یک دستگاه شبکه پیکربندی کنید.
برای توضیح اینکه یک ماژول منبع چه کاری انجام می دهد، اجازه دهید به یک کتاب بازی مثال نگاه کنیم که یک عملیات ایده آل را با استفاده از حقایق و ماژول منابع شبکه جدید نشان می دهد. 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: هر دستور پیکربندی روی دستگاه اجرا می شود تا آن را به حالت دلخواه برساند.
همه اینها به چه معناست؟ چرا مهم است؟
این پست مفاهیم پیچیده زیادی را پوشش می‌دهد، اما امیدواریم که در پایان درک بهتری از آنچه مشتریان سازمانی در واقع جمع‌آوری، عادی‌سازی داده‌ها و پیکربندی حلقه برای یک پلتفرم اتوماسیون درخواست می‌کنند، داشته باشید. اما چرا آنها به این پیشرفت ها نیاز دارند؟ بسیاری از سازمان‌ها در حال حاضر به دنبال تحول دیجیتال هستند تا محیط IT خود را چابک‌تر و رقابتی‌تر کنند. خوب یا بد، بسیاری از مهندسان شبکه یا به خاطر منافع شخصی یا به دستور مدیریت، توسعه دهندگان شبکه می شوند.
سازمان‌ها متوجه شده‌اند که خودکارسازی قالب‌های شبکه منفرد مشکل سیلوها را حل نمی‌کند و فقط کارایی را تا حدی افزایش می‌دهد. پلتفرم Red Hat Ansible Automation مدل‌های داده منابع دقیق و هنجاری را برای مدیریت برنامه‌ریزی داده‌های اساسی در یک دستگاه شبکه فراهم می‌کند. به این معنا که کاربران به‌تدریج روش‌های پیکربندی فردی را کنار می‌گذارند و به جای پیاده‌سازی فروشنده‌ای خاص، به نفع روش‌های مدرن‌تر با تأکید بر فناوری‌ها (مثلاً آدرس‌های 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 Networks.nxos_bfd_interfaces- از سیسکوnxos_telemetry- از سیسکو
همانطور که می بینید، مفهوم ماژول های منبع در استراتژی پلت فرم محور ما قرار می گیرد. یعنی قابلیت ها و کارکردهای لازم را در خود Ansible برای پشتیبانی از استانداردسازی در توسعه ماژول های شبکه و همچنین ساده سازی کار کاربران در سطح نقش ها و کتاب های بازی Ansible گنجانده ایم. برای گسترش توسعه ماژول های منابع، تیم Ansible ابزار Module Builder را منتشر کرد.
برنامه هایی برای Ansible 2.10 و بالاتر
پس از انتشار Ansible 2.9، ما روی مجموعه بعدی ماژول های منبع برای Ansible 2.10 کار خواهیم کرد، که می تواند برای پیکربندی بیشتر توپولوژی و خط مشی شبکه، به عنوان مثال، استفاده شود. . طرح توسعه همچنان قابل تنظیم است، بنابراین اگر نظری دارید، لطفاً آن را به آن گزارش دهید .
منابع و شروع کار
منبع: www.habr.com