چگونه زیرساخت شبکه خود را کنترل کنیم فصل چهار. اتوماسیون. قالب ها

این مقاله ششمین مقاله از مجموعه «چگونه زیرساخت شبکه خود را کنترل کنیم» است. محتویات تمام مقالات این مجموعه و پیوندها را می توان یافت اینجا.

با پشت سر گذاشتن چندین موضوع، تصمیم گرفتم فصل جدیدی را شروع کنم.

کمی بعد به امنیت برمی گردم. در اینجا من می خواهم یک رویکرد ساده اما مؤثر را مورد بحث قرار دهم که مطمئن هستم، به هر شکلی، می تواند برای بسیاری مفید باشد. این بیشتر یک داستان کوتاه در مورد اینکه چگونه اتوماسیون می تواند زندگی یک مهندس را تغییر دهد است. ما در مورد استفاده از قالب ها صحبت خواهیم کرد. در انتها لیستی از پروژه های من وجود دارد که در آن می توانید نحوه عملکرد هر آنچه در اینجا توضیح داده شده است را مشاهده کنید.

DevOps برای شبکه

ایجاد یک پیکربندی با یک اسکریپت، استفاده از GIT برای کنترل تغییرات در زیرساخت فناوری اطلاعات، «آپلود» از راه دور - این ایده‌ها زمانی که به اجرای فنی رویکرد DevOps فکر می‌کنید، ابتدا مطرح می‌شوند. مزایا آشکار است. اما، متأسفانه، معایبی نیز وجود دارد.

زمانی که بیش از 5 سال پیش، توسعه دهندگان ما با این پیشنهادات به سراغ ما آمدند، نتورکرها، ما خوشحال نشدیم.

باید بگویم که ما یک شبکه نسبتاً متنوع متشکل از تجهیزات حدود 10 فروشنده مختلف را به ارث بردیم. پیکربندی برخی چیزها از طریق cli مورد علاقه ما راحت بود، اما در موارد دیگر ترجیح دادیم از رابط کاربری گرافیکی استفاده کنیم. علاوه بر این، کار طولانی بر روی تجهیزات "زنده" به ما یاد داده است که در زمان واقعی کنترل کنیم. به عنوان مثال، هنگام ایجاد تغییرات، من احساس راحتی بیشتری می کنم که مستقیماً از طریق cli کار کنم. به این ترتیب می توانم به سرعت متوجه شوم که مشکلی پیش آمده است و تغییرات را به عقب برگردانم. همه اینها تا حدودی با عقاید آنها در تناقض بود.

سوالات دیگری نیز مطرح می شود، به عنوان مثال، رابط کاربری ممکن است از نسخه ای به نسخه دیگر نرم افزار کمی تغییر کند. این در نهایت باعث می شود اسکریپت شما "پیکربندی" اشتباهی ایجاد کند. من نمی خواهم از تولید برای "دویدن در" استفاده کنم.

یا چگونه بفهمیم که دستورات پیکربندی به درستی اعمال شده اند و در صورت بروز خطا چه باید کرد؟

من نمی خواهم بگویم که همه این مسائل غیرقابل حل است. فقط گفتن "A" احتمالاً گفتن "B" نیز منطقی است، و اگر می خواهید از همان فرآیندهایی که در توسعه برای کنترل تغییر استفاده می شود، استفاده کنید، باید علاوه بر تولید، محیط های توسعه دهنده و مرحله بندی نیز داشته باشید. سپس این رویکرد کامل به نظر می رسد. اما هزینه آن چقدر خواهد بود؟

اما یک موقعیت وجود دارد که معایب عملاً از بین می روند و فقط مزایا باقی می مانند. من در مورد کار طراحی صحبت می کنم.

پروژه

در دو سال گذشته من در پروژه ای برای ساخت مرکز داده برای یک ارائه دهنده بزرگ شرکت کرده ام. من مسئول F5 و Palo Alto در این پروژه هستم. از دیدگاه سیسکو، این "تجهیزات شخص ثالث" است.

برای من شخصاً دو مرحله مجزا در این پروژه وجود دارد.

مرحله اول

سال اولی که بی‌پایان مشغول بودم، شب‌ها و آخر هفته‌ها کار می‌کردم. نمی توانستم سرم را بالا بیاورم. فشار مدیریت و مشتری قوی و مستمر بود. در یک روال ثابت، حتی نمی‌توانستم برای بهینه‌سازی فرآیند تلاش کنم. این نه تنها و نه آنقدر پیکربندی تجهیزات بلکه تهیه اسناد طراحی بود.

اولین آزمایش ها شروع شده است و من از اینکه چقدر اشتباهات کوچک و نادرستی انجام شده است شگفت زده خواهم شد. البته همه چیز کار می کرد، اما یک حرف در نام وجود داشت، یک خط در دستور وجود داشت... آزمایش ها ادامه داشت و من از قبل درگیر یک مبارزه دائمی و روزانه با خطاها، آزمایش ها و مستندات بودم. .

این یک سال ادامه داشت. تا آنجا که من متوجه شدم، این پروژه برای همه آسان نبود، اما به تدریج مشتری بیشتر و بیشتر راضی شد و این امکان استخدام مهندسان دیگری را فراهم کرد که بتوانند بخشی از این روال را خودشان به عهده بگیرند.

حالا می توانستیم کمی به اطراف نگاه کنیم.
و این شروع مرحله دوم بود.

مرحله دوم

تصمیم گرفتم فرآیند را خودکار کنم.

چیزی که در آن زمان از ارتباطم با توسعه دهندگان فهمیدم (و باید قدردانی کنیم، ما تیم قوی داشتیم) این است که قالب متن، اگرچه در نگاه اول چیزی از دنیای سیستم عامل DOS به نظر می رسد، اما دارای تعدادی است. از خواص ارزشمند .
بنابراین، برای مثال، اگر می‌خواهید از GIT و تمام مشتقات آن نهایت استفاده را ببرید، قالب متن مفید خواهد بود. و من می خواستم.

خوب، به نظر می رسد که می توانید به سادگی یک پیکربندی یا لیستی از دستورات را ذخیره کنید، اما ایجاد تغییرات بسیار ناخوشایند است. علاوه بر این، یک وظیفه مهم دیگر در طول طراحی وجود دارد. شما باید اسنادی داشته باشید که طرح خود را به عنوان یک کل (طراحی سطح پایین) و پیاده سازی خاص (طرح اجرای شبکه) توصیف کند. و در این مورد استفاده از قالب ها گزینه بسیار مناسبی به نظر می رسد.

بنابراین، هنگام استفاده از YAML و Jinja2، یک فایل YAML با پارامترهای پیکربندی مانند آدرس‌های IP، اعداد BGP AS، ... نقش NIP را کاملاً ایفا می‌کند، در حالی که قالب‌های Jinja2 شامل نحو متناظر با طراحی هستند، یعنی اساساً یک بازتاب LLD

یادگیری YAML و Jinja2 دو روز طول کشید. چند مثال خوب برای درک چگونگی کارکرد آن کافی است. سپس حدود دو هفته طول کشید تا همه الگوهایی را که با طراحی ما مطابقت داشتند ایجاد کنیم: یک هفته برای Palo Alto و یک هفته دیگر برای F5. همه اینها در githab شرکتی ارسال شده است.

حالا روند تغییر به این شکل بود:

• فایل YAML را تغییر داد
• ایجاد یک فایل پیکربندی با استفاده از یک الگو (Jinja2)
• در یک مخزن از راه دور ذخیره شده است
• پیکربندی ایجاد شده را روی تجهیزات آپلود کرد
• خطا دیدم
• فایل YAML یا قالب Jinja2 را تغییر داد
• ایجاد یک فایل پیکربندی با استفاده از یک الگو (Jinja2)
• ...

واضح است که در ابتدا زمان زیادی صرف ویرایش ها می شد، اما پس از یک یا دو هفته این امر بسیار نادر شد.

یک آزمون و فرصت خوب برای اشکال زدایی همه چیز، تمایل مشتری برای تغییر قرارداد نامگذاری بود. کسانی که با F5 کار می کردند، وضعیت را درک می کنند. اما برای من همه چیز بسیار ساده بود. نام‌های فایل YAML را تغییر دادم، کل پیکربندی را از تجهیزات حذف کردم، یک مورد جدید ایجاد کردم و آن را آپلود کردم. همه چیز، از جمله رفع اشکال، 4 روز طول کشید: دو روز برای هر فناوری. بعد از آن برای مرحله بعدی یعنی ایجاد مراکز داده DEV و Staging آماده شدم.

توسعه دهنده و مرحله بندی

صحنه سازی در واقع تولید را به طور کامل تکرار می کند. Dev یک نسخه کاملاً حذف شده است که عمدتاً بر روی سخت افزار مجازی ساخته شده است. یک موقعیت ایده آل برای یک رویکرد جدید. اگر زمانی را که صرف کردم از روند کلی جدا کنم، فکر می کنم کار بیش از 2 هفته طول نکشید. زمان اصلی انتظار طرف مقابل و جستجوی مشکلات با هم است. اجرای 3rd party تقریباً مورد توجه دیگران قرار نگرفت. حتی زمان برای یادگیری چیزی و نوشتن چند مقاله در Habré وجود داشت :)

به طور خلاصه

بنابراین، من در خط پایانی چه چیزی دارم؟

• تنها کاری که برای تغییر پیکربندی باید انجام دهم این است که یک فایل YAML ساده و ساختار یافته با پارامترهای پیکربندی را تغییر دهم. من هرگز اسکریپت پایتون را تغییر نمی دهم و به ندرت (فقط در صورت وجود خطایی) گرمای Jinja2 را تغییر می دهم.
• از نقطه نظر مستندسازی، این یک وضعیت تقریبا ایده آل است. شما اسناد را تغییر می دهید (فایل های YAML به عنوان NIP خدمت می کنند) و این پیکربندی را در تجهیزات آپلود می کنید. به این ترتیب اسناد شما همیشه به روز هستند

همه اینها به این واقعیت منجر شد که

• نرخ خطا تقریباً به 0 کاهش یافته است
• 90 درصد روتین از بین رفته است
• سرعت اجرا به میزان قابل توجهی افزایش یافته است

PAY، F5Y، ACY

گفتم چند مثال کافیست تا بفهمیم چطور کار می کند.
در اینجا یک نسخه کوتاه (و البته اصلاح شده) از آنچه در طول کار من ایجاد شده است.

پرداخت = استقرار Pآلو Aاز Yaml = پالو آلتو از یامل
F5Y = استقرار F5 از جانب Yaml = F5 از جانب Yaml (به زودی)
ACY = استقرار ACمن از Yaml = F5 از جانب Yامل

من چند کلمه در مورد ACY اضافه می کنم (با ACI اشتباه نشود).

کسانی که با ACI کار کرده‌اند می‌دانند که این معجزه (و از لحاظ خوب) قطعا توسط نتورکرها ساخته نشده است :). همه چیزهایی را که در مورد شبکه می دانستید فراموش کنید - برای شما مفید نخواهد بود!
کمی اغراق آمیز است، اما تقریباً احساسی را منتقل می کند که من در 3 سال گذشته دائماً با ACI کار کرده ام.

و در این مورد، ACY نه تنها فرصتی برای ایجاد یک فرآیند کنترل تغییر است (که در مورد ACI بسیار مهم است، زیرا قرار است مرکزی و حیاتی ترین بخش مرکز داده شما باشد)، بلکه به شما نیز می دهد. یک رابط کاربر پسند برای ایجاد پیکربندی.

مهندسان این پروژه از Excel برای پیکربندی ACI به جای YAML برای اهداف مشابه استفاده می کنند. البته استفاده از اکسل مزایایی دارد:

• NIP شما در یک فایل
• نشانه های زیبایی که دیدن آنها برای مشتری دلپذیر است
• می توانید از برخی ابزارهای اکسل استفاده کنید

اما یک منهای وجود دارد و به نظر من بیشتر از جوانب مثبت است. کنترل تغییرات و هماهنگی کار تیمی بسیار دشوارتر می شود.

ACY در واقع یک برنامه کاربردی از همان رویکردهایی است که من برای شخص ثالث برای پیکربندی ACI استفاده کردم.

منبع: www.habr.com