🥇تاریخچه ایجاد یک سرویس ابری با طعم سایبرپانک

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

بنابراین ما افتخار ساختن یک پلتفرم ابری را داشتیم و برای این کار باید چند زیرسیستم را متقاعد کنیم که با ما کار کنند. خوشبختانه، ما یک "زبان API"، دست های مستقیم و اشتیاق زیادی داریم.

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

به گربه خوش آمدید

آغاز سفر

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

همچنین تعدادی الزام وجود داشت:

این سرویس به یک حساب شخصی مناسب نیاز دارد.
پلت فرم باید در سیستم صورتحساب موجود ادغام شود.
نرم‌افزار و سخت‌افزار: OpenStack + پارچه تنگستن (Open Contrail)، که مهندسان ما پختن آن را به خوبی آموخته‌اند.

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

Python + Flask + Swagger + SQLAlchemy - مجموعه کاملاً استاندارد پایتون.
Vue.js برای frontend.
ما تصمیم گرفتیم که تعامل بین مؤلفه‌ها و سرویس‌ها را با استفاده از Celery از طریق AMQP انجام دهیم.

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

بنابراین، بیایید آشنایی خود را آغاز کنیم.

بیل خاموش - صورتحساب

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

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

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

با توجه به توضیحات API نرم افزار، هنوز هم می توان این مشکل را حل کرد، اما ما زمان انجام مهندسی معکوس را نداشتیم، بنابراین منطق را خارج کردیم و یک صف کار در بالای RabbitMQ ترتیب دادیم. یک عملیات روی یک سرویس توسط مشتری از حساب شخصی او آغاز می شود، به یک "وظیفه" Celery در باطن تبدیل می شود و در سمت صورتحساب و OpenStack انجام می شود. کرفس مدیریت وظایف، سازماندهی تکرارها و نظارت بر وضعیت را بسیار راحت می کند. برای مثال می توانید در مورد "کرفس" بیشتر بخوانید، اینجا.

همچنین، صورتحساب پروژه ای را که پولش تمام شده بود متوقف نکرد. در ارتباط با توسعه دهندگان، متوجه شدیم که هنگام محاسبه آمار (و دقیقاً باید این نوع منطق را پیاده سازی کنیم)، یک رابطه متقابل پیچیده از قوانین توقف وجود دارد. اما این مدل ها با واقعیت های ما تناسب چندانی ندارند. ما همچنین آن را از طریق وظایف در Celery پیاده سازی کردیم و منطق مدیریت سرویس را به سمت باطن بردیم.

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

مشکل دیگر سکوت است.

بیلی در سکوت به برخی از درخواست‌های API پاسخ می‌دهد: Ok. به عنوان مثال، زمانی که ما پرداخت‌های وعده داده شده را در طول آزمایش انجام دادیم (در ادامه در مورد آن بیشتر خواهد شد) اینگونه بود. درخواست ها به درستی اجرا شد و هیچ خطایی مشاهده نکردیم.

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

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

بنابراین، به طور خلاصه، مشکلات اصلی که در مرحله تعامل با آن مواجه شدیم، مربوط به ویژگی های پیاده سازی یک سیستم خاص است:

«ویژگی‌های» غیرمستندی که به نوعی بر ما تأثیر گذاشته است.
منبع بسته (صورتحساب به زبان C++ نوشته شده است)، در نتیجه - حل مشکل 1 به هیچ وجه غیر از "آزمایش و خطا" غیرممکن است.

خوشبختانه، این محصول دارای یک API نسبتاً گسترده است و ما زیرسیستم های زیر را در حساب شخصی خود ادغام کرده ایم:

ماژول پشتیبانی فنی - درخواست‌های حساب شخصی شما به صورت شفاف برای مشتریان خدمات "پراکسی" شده است.
ماژول مالی - به شما امکان می دهد برای مشتریان فعلی صورتحساب صادر کنید، حذف کنید و اسناد پرداخت را ایجاد کنید.
ماژول کنترل سرویس - برای این ما مجبور شدیم کنترلر خود را پیاده سازی کنیم. توسعه پذیری سیستم به نفع ما بود و ما به بیلی نوع جدیدی از خدمات را "آموزش دادیم".
کمی دردسر بود، اما به هر حال، فکر می‌کنم من و بیلی با هم کنار می‌آییم.

قدم زدن در مزارع تنگستن - پارچه تنگستن

میدان‌های تنگستن با صدها سیم پر شده و هزاران بیت اطلاعات را از میان آنها عبور می‌دهند. اطلاعات به صورت "بسته‌ها" جمع‌آوری می‌شوند، تجزیه می‌شوند و مسیرهای پیچیده را می‌سازند، گویی با جادو.

این دامنه دومین سیستمی است که ما مجبور شدیم با آن دوست شویم - پارچه تنگستن (TF)، که قبلا OpenContrail بود. وظیفه آن مدیریت تجهیزات شبکه و ارائه یک انتزاع نرم افزاری برای ما به عنوان کاربران است. TF - SDN، منطق پیچیده کار با تجهیزات شبکه را در بر می گیرد. مقاله خوبی در مورد خود فناوری وجود دارد، به عنوان مثال، اینجا.

این سیستم از طریق پلاگین نوترون با OpenStack (در زیر بحث شده است) یکپارچه شده است.

تعامل خدمات OpenStack.

بچه های بخش عملیات ما را با این سیستم آشنا کردند. ما از API سیستم برای مدیریت پشته شبکه خدمات خود استفاده می کنیم. هنوز هیچ مشکل یا ناراحتی جدی برای ما ایجاد نکرده است (من نمی توانم به جای بچه های OE صحبت کنم)، اما برخی از موارد عجیب و غریب در تعامل وجود داشته است.

اولین مورد به این شکل بود: دستورهایی که هنگام اتصال از طریق SSH نیاز به خروجی مقدار زیادی داده به کنسول نمونه داشتند، به سادگی اتصال را "قطع" می کردند، در حالی که از طریق VNC همه چیز به درستی کار می کرد.

برای کسانی که با این مشکل آشنا نیستند، کاملاً خنده دار به نظر می رسد: ls /root به درستی کار می کند، در حالی که، برای مثال، بالا کاملاً "فریز" می شود. خوشبختانه قبلا با مشکلات مشابهی مواجه شده بودیم. با تنظیم MTU در مسیر از گره های محاسباتی به روترها تصمیم گرفته شد. در ضمن، این مشکل TF نیست.

مشکل بعدی همین نزدیکی بود. در یک لحظه "زیبا"، جادوی مسیریابی ناپدید شد، درست مثل آن. TF مدیریت مسیریابی روی تجهیزات را متوقف کرده است.

ما با Openstack از سطح مدیریت کار کردیم و پس از آن به سطح کاربری مورد نیاز منتقل شدیم. به نظر می رسد SDN محدوده کاربری را که اقدامات توسط او انجام می شود، «ربایش» می کند. واقعیت این است که از همان حساب مدیریت برای اتصال TF و OpenStack استفاده می شود. در مرحله تغییر به کاربر، "جادو" ناپدید شد. تصمیم گرفته شد یک حساب کاربری جداگانه برای کار با سیستم ایجاد شود. این به ما امکان داد بدون شکستن عملکرد ادغام کار کنیم.

Silicon Lifeforms - OpenStack

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

OpenStack هسته پلتفرم ما است.

OpenStack چندین زیرسیستم دارد که ما در حال حاضر از Nova، Glance و Cinder بیشتر استفاده می کنیم. هر کدام از آنها API مخصوص به خود را دارند. Nova مسئول منابع محاسباتی و ایجاد نمونه‌ها است، Cinder مسئول مدیریت حجم‌ها و عکس‌های فوری آن‌ها است، Glance یک سرویس تصویری است که قالب‌های سیستم‌عامل و اطلاعات فرا اطلاعاتی را روی آن‌ها مدیریت می‌کند.

هر سرویس در یک کانتینر اجرا می شود و واسطه پیام "خرگوش سفید" - RabbitMQ است.

این سیستم غیرمنتظره ترین دردسر را به ما داد.

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

تصمیم گرفتیم یک مسیر انحرافی داشته باشیم و همین اقدام را از Nova API درخواست کردیم. نتیجه این است که دستگاه به درستی متصل می شود و در سرور قابل دسترسی است. به نظر می رسد که مشکل زمانی رخ می دهد که ذخیره سازی بلوک به Cinder پاسخ نمی دهد.

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

باز هم، خود OpenStack "قسم می خورد" که اتصال را از بین برده است و اکنون می توانید به طور جداگانه با حجم کار کنید. اما API قاطعانه مایل به انجام عملیات روی دیسک نبود.

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

OpenStack مجموعه ای نسبتاً پیچیده از سیستم ها با منطق تعامل خاص خود و API مزین است. مستندات نسبتاً دقیق و البته آزمون و خطا به ما کمک می کند (بدون آن کجا بودیم).

اجرای آزمایشی

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

خود آزمون البته بدون لحظات خنده‌دار نبود، زیرا ماجراجویی‌های ما از اینجا شروع می‌شود.

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

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

ما تصمیم گرفتیم از JWT برای سازماندهی دسترسی به حساب شخصی خود استفاده کنیم تا با جلسات کار نکنیم. از آنجایی که سیستم‌ها متنوع و به طور گسترده پراکنده هستند، ما رمز خود را مدیریت می‌کنیم که در آن جلسات را از صورت‌حساب و یک توکن از OpenStack را می‌پیچانیم. هنگامی که رمز عبور تغییر می کند، نشانه، البته، "بد می رود"، زیرا داده های کاربر دیگر معتبر نیستند و باید دوباره منتشر شوند.

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

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

ادامه

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

البته، هم از نظر کد و هم در رابط های یکپارچه سازی سیستم، باید روی آن کار کرد. این پروژه کاملاً جوان است، اما ما پر از جاه طلبی هستیم تا آن را به یک سرویس قابل اعتماد و راحت تبدیل کنیم.

ما قبلاً توانسته ایم سیستم ها را متقاعد کنیم. بیل در کمد خود به شمارش، صورت‌حساب و درخواست‌های کاربر رسیدگی می‌کند. "جادو" میدان های تنگستن ارتباط پایداری را برای ما فراهم می کند. و فقط OpenStack گاهی اوقات دمدمی مزاج می شود و چیزی مانند "WSREP هنوز گره ای را برای استفاده برنامه آماده نکرده است" فریاد می زند. اما این یک داستان کاملا متفاوت است ...

ما اخیراً این سرویس را راه اندازی کردیم.
شما می توانید تمام جزئیات را در ما پیدا کنید کاربران آنلاین حاضر در سایت ".

تیم توسعه CLO

لینک های مفید

OpenStack

پارچه تنگستن

منبع: www.habr.com

تاریخچه ایجاد یک سرویس ابری با چاشنی سایبرپانک