سیستم ISP، ببخش و خداحافظ! چرا و چگونه کنترل پنل سرور خود را نوشتیم

سلام! ما "فناوری های میزبانی" هستیم و 5 سال پیش راه اندازی شدیم VDSina - اولین میزبانی vds که به طور خاص برای توسعه دهندگان ایجاد شده است. ما در تلاش هستیم تا آن را مانند DigitalOcean راحت کنیم، اما با پشتیبانی روسیه، روش‌های پرداخت و سرورها در روسیه. اما DigitalOcean نه تنها قابل اطمینان و قیمت است، بلکه یک سرویس نیز هست.

نرم افزار ISPsystem طنابی بود که دستان ما را در راه رسیدن به یک سرویس جالب گره زد. سه سال پیش، ما از Billmanager billing و کنترل پنل سرور VMmanager استفاده کردیم و به سرعت متوجه شدیم که ارائه یک سرویس خوب بدون کنترل پنل خودمان تقریبا غیرممکن است.

چگونه سیستم ISP راحتی را از بین برد

اشکالات

ما خودمان نتوانستیم این اشکال را برطرف کنیم - هر بار مجبور بودیم به پشتیبانی شخص دیگری بنویسیم و منتظر بمانیم. حل هر مشکلی نیازمند پاسخ یک شرکت شخص ثالث بود.

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

تهدید از کار افتادن

به‌روزرسانی‌ها می‌توانند خرابی‌های غیرقابل پیش‌بینی ایجاد کنند که خطاهای جدیدی را برانگیزد.

هر به‌روزرسانی یک قرعه‌کشی بود: باید صورت‌حساب‌ها را می‌پوشاندم و برای خدایان به‌روزرسانی‌ها قربانی می‌کردم - چند بار این به‌روزرسانی باعث توقف 10 تا 15 دقیقه‌ای می‌شد. ادمین‌های ما در این زمان روی چشمان خود نشسته بودند - ما هرگز نمی‌دانستیم که خرابی چقدر طول می‌کشد و نمی‌توانستیم پیش‌بینی کنیم که سیستم ISP چه زمانی تصمیم به انتشار به‌روزرسانی جدید می‌گیرد.

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

رابط پنل نامناسب

همه چیز به پانل های مختلف تقسیم شده بود و از مکان های مختلف کنترل می شد. به عنوان مثال، مشتریان از طریق Billmanager پرداخت می‌کردند و مجبور بودند VDS را در VMManager راه‌اندازی مجدد یا مجدداً نصب کنند. کارکنان ما همچنین مجبور بودند بین ویندوزها جابجا شوند تا به مشتری کمک کنند، بار روی سرور او را بررسی کنند یا ببینند از چه سیستم‌عاملی استفاده می‌کند.

چنین رابطی به زمان نیاز دارد - هم برای ما و هم برای مشتریان ما. در چنین شرایطی هیچ گونه راحتی مانند DigitalOcean وجود ندارد.

چرخه عمر کوتاه با به روز رسانی های مکرر API

ما افزونه های خودمان را نوشتیم - به عنوان مثال، یک افزونه با روش های پرداخت اضافی که در VMManager نیستند.

در سال‌های اخیر، VMManager چرخه عمر نسبتاً کوتاهی داشت و در نسخه‌های جدید، نام متغیرها یا توابع در API می‌توانست خودسرانه تغییر کند - این باعث شکست پلاگین‌های ما شد. پشتیبانی از نسخه های قدیمی به سرعت حذف شد و باید به روز می شد.

قابل اصلاح نیست

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

بنابراین تصمیم گرفته شد که پانل خودم را بنویسم. ما اهدافی را تعیین کرده ایم:

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

و توسعه را شروع کردیم.

معماری پانل جدید

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

مرحله 1: عامل سرور

عامل سرور یک وب سرور پایتون است که کتابخانه را مدیریت می کند کتابخانه، که به نوبه خود حاکم است هایپروایزر Qemu-kvm.

عامل تمام خدمات روی سرور را مدیریت می کند: ایجاد، توقف، حذف vds، نصب سیستم عامل، تغییر پارامترها و غیره از طریق کتابخانه libvirt. در زمان انتشار مقاله، اینها بیش از چهل کارکرد مختلف هستند که بسته به وظیفه و نیاز مشتری، آنها را تکمیل می کنیم.

در تئوری، libvirt را می‌توان مستقیماً از طریق صورت‌حساب کنترل کرد، اما این نیاز به کد اضافی زیادی داشت و ما تصمیم گرفتیم این توابع را بین نماینده و صورت‌حساب جدا کنیم - صورت‌حساب به سادگی از طریق JSON API به نماینده درخواست می‌کند.

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

چیزی که عامل سرور به ما داد: لایه ای ظاهر شده است که زندگی را برای همه ساده می کند - صورتحساب نیازی به ارسال یک دسته کامل از دستورات ندارد، بلکه فقط یک درخواست ارسال می کند. و عامل هر کاری را که لازم است انجام می دهد: به عنوان مثال، فضای دیسک و RAM را اختصاص می دهد.

مرحله 2. صورتحساب

برای الکس توسعه‌دهنده ما، این اولین کنترل پنل نبود - الکس مدت زیادی است که میزبانی می‌کند، بنابراین او به طور کلی درک می‌کند که مشتری به چه چیزی نیاز دارد و میزبان چه چیزی نیاز دارد.

ما صورتحساب بین خود را "پانل کنترل" می نامیم: این صورتحساب نه تنها شامل پول و خدمات، بلکه مدیریت آنها، پشتیبانی مشتری و موارد دیگر است.

برای جابجایی از نرم‌افزار ISPSystem، لازم بود عملکرد قبلی برای مشتریان کاملاً حفظ شود، کلیه اقدامات مالی کاربران از صورت‌حساب قبلی به جدید و همچنین کلیه خدمات و ارتباطات بین آنها منتقل شود. ما آنچه در محصول فعلی وجود دارد، سپس راه حل های رقبا، عمدتا DO و Vultr را مطالعه کردیم. ما به معایب و مزایا نگاه کردیم، بازخوردهایی را از افرادی که با محصولات قدیمی ISPsystem کار می کردند جمع آوری کردیم.

صورت‌حساب جدید از دو پشته استفاده می‌کرد: PHP کلاسیک، MySQL (و در آینده قرار است به PostgreSQL سوئیچ شود)، Yii2 به‌عنوان یک چارچوب در باطن و VueJS در جلو. پشته ها مستقل از یکدیگر کار می کنند، توسط افراد مختلف توسعه می یابند و با استفاده از JSON API ارتباط برقرار می کنند. برای توسعه در آن زمان و اکنون استفاده می کنیم PHPSstorm и طوفان وب از JetBrains و آنها را صمیمانه دوست دارم (هی بچه ها!)

این پنل بر اساس ماژولار طراحی شده است: ماژول های سیستم پرداخت، ماژول ثبت دامنه یا، به عنوان مثال، ماژول گواهی SSL. شما به راحتی می توانید یک ویژگی جدید اضافه کنید یا یک ویژگی قدیمی را حذف کنید. زمینه برای گسترش از نظر معماری، از جمله در جهت مخالف، "به سمت سخت افزار" گذاشته شده است.

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

مرحله 3 رابط

رابط زاییده فکر تیم ما است.

ابتدا، بررسی کردیم که اگر افزونه‌ای را از طریق ISPsystem API بدون تغییر اساسی چیزی در رابط ایجاد کنیم، چه اتفاقی می‌افتد. این طور شد و ما تصمیم گرفتیم همه چیز را از ابتدا انجام دهیم.

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

طراحی صفحه صورتحساب اولین موردی بود که ظاهر شد، زیرا ما قبلاً افزونه های پرداخت را برای ISPsystem ساخته ایم.

Frontend

آنها تصمیم گرفتند که پنل را به یک برنامه SPA تبدیل کنند - بدون نیاز به منابع و با بارگذاری سریع داده ها. آرتیش پیشرو ما تصمیم گرفت آن را در Vue بنویسد - در آن زمان Vue تازه ظاهر شده بود. ما فرض کردیم که چارچوب به صورت پویا مانند React توسعه می یابد، پس از مدتی جامعه Vue رشد می کند و دریایی از کتابخانه ها ظاهر می شود. ما روی Vue شرط بندی کردیم و پشیمان نشدیم - اکنون اضافه کردن عملکردهای جدید به قسمت جلو که قبلاً در قسمت پشتی برنامه ریزی شده اند زمان کمی می برد. در مقاله ای جداگانه در مورد پنل جلویی بیشتر به شما خواهیم گفت.

اتصال جلویی به باطن

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

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

مرحله 4. آزمایش و طرح مهاجرت

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

سپس یک اسکریپت ساده نوشتیم که پایگاه داده را از صورتحساب قبلی به جدید منتقل می کند.

من مجبور شدم به معنای واقعی کلمه همه چیز را آزمایش و دوباره بررسی کنم، زیرا داده ها در یک پایگاه داده جدید از سه پایگاه قدیمی ادغام شدند: Billmanager، VMmanager و IPmanager مدیر. شاید مهاجرت های آزمایشی سخت ترین چیزی باشد که در فرآیند توسعه یک پنل جدید با آن مواجه شدیم.

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

سپس نامه هایی با آدرس پنل جدید و صورتحساب به مشتریان ارسال کردیم و تغییر مسیر دادیم.

به طور خلاصه: زنده است!

پایان خوش

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

اولین بررسی بعد از راه اندازی پنل جدید

ما فرآیند انتقال را در دسامبر، در آستانه سال نو 2017، زمانی که کمترین بار بود، راه‌اندازی کردیم تا انتقال را برای مشتریان آسان‌تر کنیم - تقریباً هیچ‌کس در آستانه تعطیلات کار نمی‌کند.

نکته اصلی که ما هنگام تغییر به سیستم خود (به غیر از قابلیت اطمینان و راحتی عمومی) به دست آوردیم، توانایی اضافه کردن سریع عملکرد برای مشتریان کلیدی است - چهره آنها باشد، نه الاغ آنها.

گام بعدی چیست؟

ما در حال رشد هستیم، حجم داده ها، مشتریان، داده های مشتری در حال رشد است. من مجبور شدم یک سرور Memcached و دو مدیر صف با وظایف مختلف را به باطن اضافه کنم. فرانت اند دارای کش و صف های خاص خود است.

البته، همچنان که محصول توسعه یافته و پیچیده تر شد، ماجراجویی هایی داشتیم، به عنوان مثال زمانی که HighLoad را اضافه کردیم.

در مقاله بعدی نحوه راه اندازی تعرفه Hi-CPU را به شما خواهیم گفت: در مورد سخت افزار، نرم افزار، چه کارهایی را حل کردیم و چه کارهایی انجام دادیم.

منبع: www.habr.com