🥇 سائبر پنک کے ساتھ ذائقہ دار کلاؤڈ سروس کی تخلیق کی تاریخ

جیسا کہ آپ IT میں کام کرتے ہیں، آپ کو معلوم ہونا شروع ہو جاتا ہے کہ سسٹمز کا اپنا کردار ہے۔ وہ لچکدار، خاموش، سنکی اور سخت ہو سکتے ہیں۔ وہ اپنی طرف متوجہ یا پیچھے ہٹا سکتے ہیں. کسی نہ کسی طریقے سے، آپ کو ان کے ساتھ "گفت و شنید" کرنی ہوگی، "نقصان" کے درمیان چال چلنی ہوگی اور ان کے تعامل کی زنجیریں بنانا ہوں گی۔

لہذا ہمیں کلاؤڈ پلیٹ فارم بنانے کا اعزاز حاصل ہوا، اور اس کے لیے ہمیں اپنے ساتھ کام کرنے کے لیے کچھ سب سسٹمز کو "قائل" کرنے کی ضرورت تھی۔ خوش قسمتی سے، ہمارے پاس "API زبان"، براہ راست ہاتھ اور بہت زیادہ جوش و خروش ہے۔

یہ مضمون تکنیکی طور پر سخت نہیں ہوگا، لیکن ان مسائل کو بیان کرے گا جن کا ہمیں کلاؤڈ بنانے کے دوران سامنا کرنا پڑا۔ میں نے اپنے راستے کو ہلکی تکنیکی فنتاسی کی شکل میں بیان کرنے کا فیصلہ کیا کہ ہم نے سسٹمز کے ساتھ ایک عام زبان کی تلاش کیسے کی اور اس سے کیا نکلا۔

بلی میں خوش آمدید۔

شروع سفر کا

کچھ عرصہ پہلے، ہماری ٹیم کو ہمارے کلائنٹس کے لیے کلاؤڈ پلیٹ فارم لانچ کرنے کا کام سونپا گیا تھا۔ سروس کے سافٹ ویئر حصے کو نافذ کرنے کے لیے ہمارے پاس مینجمنٹ سپورٹ، وسائل، ہارڈویئر اسٹیک اور ٹیکنالوجیز کے انتخاب میں آزادی تھی۔

کچھ تقاضے بھی تھے:

سروس کو ایک آسان ذاتی اکاؤنٹ کی ضرورت ہے؛
پلیٹ فارم کو موجودہ بلنگ سسٹم میں ضم کیا جانا چاہیے؛
سافٹ ویئر اور ہارڈ ویئر: OpenStack + Tungsten Fabric (Open Contrail)، جسے ہمارے انجینئرز نے بہت اچھی طرح سے "پکانا" سیکھا ہے۔

ہم آپ کو کسی اور وقت بتائیں گے کہ ٹیم کو کیسے اکٹھا کیا گیا، ذاتی اکاؤنٹ کا انٹرفیس تیار کیا گیا اور ڈیزائن کے فیصلے کیے گئے، اگر ہابرا کمیونٹی کی دلچسپی ہے۔
ہم نے جن ٹولز کو استعمال کرنے کا فیصلہ کیا ہے:

Python + Flask + Swagger + SQLAlchemy - ایک مکمل طور پر معیاری Python سیٹ؛
فرنٹ اینڈ کے لیے Vue.js؛
ہم نے AMQP پر Celery کا استعمال کرتے ہوئے اجزاء اور خدمات کے درمیان تعامل کرنے کا فیصلہ کیا۔

ازگر کو منتخب کرنے کے بارے میں سوالات کی توقع، میں وضاحت کروں گا۔ زبان کو ہماری کمپنی میں اپنا مقام مل گیا ہے اور اس کے ارد گرد ایک چھوٹی سی، لیکن پھر بھی ثقافت تیار ہوئی ہے۔ اس لیے اس پر سروس کی تعمیر شروع کرنے کا فیصلہ کیا گیا۔ مزید یہ کہ ایسے مسائل میں ترقی کی رفتار اکثر فیصلہ کن ہوتی ہے۔

تو آئیے اپنا تعارف شروع کرتے ہیں۔

خاموش بل - بلنگ

ہم اس آدمی کو کافی عرصے سے جانتے ہیں۔ وہ ہمیشہ میرے پاس بیٹھتا اور خاموشی سے کچھ شمار کرتا۔ کبھی کبھی اس نے صارف کی درخواستیں ہمارے پاس بھیجی، کلائنٹ کی رسیدیں جاری کیں، اور خدمات کا نظم کیا۔ ایک عام محنتی آدمی۔ سچ ہے، مشکلات تھیں۔ وہ خاموش ہے، کبھی سوچتا ہے اور اکثر اپنے دماغ پر۔

بلنگ پہلا سسٹم ہے جس سے ہم نے دوستی کرنے کی کوشش کی۔ اور پہلی مشکل جو ہمیں پیش آئی وہ تھی سروسز پر کارروائی کرتے وقت۔

مثال کے طور پر، تخلیق یا حذف ہونے پر، کوئی کام اندرونی بلنگ کی قطار میں چلا جاتا ہے۔ اس طرح، خدمات کے ساتھ متضاد کام کا ایک نظام لاگو کیا جاتا ہے. اپنی سروس کی اقسام پر کارروائی کرنے کے لیے، ہمیں اپنے کاموں کو اس قطار میں "ڈالنے" کی ضرورت ہے۔ اور یہاں ہم ایک پریشانی میں پڑ گئے: دستاویزات کی کمی۔

سافٹ ویئر API کی تفصیل کے مطابق، اس مسئلے کو حل کرنا اب بھی ممکن ہے، لیکن ہمارے پاس ریورس انجینئرنگ کرنے کا وقت نہیں تھا، اس لیے ہم نے منطق کو باہر نکالا اور RabbitMQ کے اوپر ایک ٹاسک کیو ترتیب دی۔ کسی سروس پر ایک آپریشن کلائنٹ اپنے ذاتی اکاؤنٹ سے شروع کرتا ہے، بیک اینڈ پر سیلری "ٹاسک" میں بدل جاتا ہے اور بلنگ اور اوپن اسٹیک سائیڈ پر انجام دیا جاتا ہے۔ اجوائن کاموں کو منظم کرنے، تکرار کو منظم کرنے اور حیثیت کی نگرانی کرنے میں کافی آسان بناتی ہے۔ آپ "اجوائن" کے بارے میں مزید پڑھ سکتے ہیں، مثال کے طور پر، یہاں.

اس کے علاوہ، بلنگ نے ایسے پروجیکٹ کو نہیں روکا جس کے پیسے ختم ہو گئے۔ ڈویلپرز کے ساتھ بات چیت کرتے ہوئے، ہمیں پتہ چلا کہ اعداد و شمار کا حساب لگاتے وقت (اور ہمیں بالکل اسی قسم کی منطق کو لاگو کرنے کی ضرورت ہے)، روکنے کے قوانین کا ایک پیچیدہ باہمی تعلق ہے۔ لیکن یہ ماڈل ہماری حقیقتوں کے ساتھ بالکل فٹ نہیں بیٹھتے ہیں۔ ہم نے اسے سیلری کے کاموں کے ذریعے بھی لاگو کیا، سروس مینجمنٹ کی منطق کو بیک اینڈ سائیڈ پر لے جایا۔

مذکورہ بالا دونوں مسائل کی وجہ سے کوڈ تھوڑا سا پھولا ہوا ہے اور مستقبل میں ہمیں کاموں کے ساتھ کام کرنے کی منطق کو الگ سروس میں منتقل کرنے کے لیے ری ایکٹر کرنا پڑے گا۔ اس منطق کو سپورٹ کرنے کے لیے ہمیں اپنے ٹیبلز میں صارفین اور ان کی خدمات کے بارے میں کچھ معلومات ذخیرہ کرنے کی بھی ضرورت ہے۔

ایک اور مسئلہ خاموشی ہے۔

بلی خاموشی سے کچھ API درخواستوں کا "ٹھیک ہے" کا جواب دیتا ہے۔ یہ معاملہ تھا، مثال کے طور پر، جب ہم نے ٹیسٹ کے دوران وعدہ شدہ ادائیگیوں کی ادائیگی کی (اس کے بارے میں مزید بعد میں)۔ درخواستوں پر صحیح طریقے سے عمل کیا گیا اور ہمیں کوئی خرابی نظر نہیں آئی۔

مجھے UI کے ذریعے سسٹم کے ساتھ کام کرتے ہوئے لاگز کا مطالعہ کرنا پڑا۔ یہ پتہ چلا کہ بلنگ خود بھی اسی طرح کی درخواستیں انجام دیتی ہے، دائرہ کار کو کسی مخصوص صارف کے لیے تبدیل کرتی ہے، مثال کے طور پر، منتظم، اسے su پیرامیٹر میں پاس کرنا۔

عام طور پر، دستاویزات میں فرق اور API کی معمولی خامیوں کے باوجود، سب کچھ بہت اچھا رہا۔ لاگز کو بھاری بوجھ کے باوجود بھی پڑھا جا سکتا ہے اگر آپ سمجھتے ہیں کہ ان کی ساخت کیسے ہے اور کیا تلاش کرنا ہے۔ ڈیٹا بیس کا ڈھانچہ آرائشی ہے، لیکن کافی منطقی اور کچھ طریقوں سے پرکشش بھی ہے۔

لہذا، خلاصہ کرنے کے لیے، بات چیت کے مرحلے پر ہمیں جن اہم مسائل کا سامنا کرنا پڑا، وہ ایک مخصوص نظام کے نفاذ کی خصوصیات سے متعلق ہیں:

غیر دستاویزی "خصوصیات" جنہوں نے ہمیں کسی نہ کسی طریقے سے متاثر کیا؛
کلوزڈ سورس (بلنگ C++ میں لکھی جاتی ہے)، نتیجے کے طور پر - مسئلہ 1 کو "آزمائشی اور غلطی" کے علاوہ کسی اور طریقے سے حل کرنا ناممکن ہے۔

خوش قسمتی سے، پروڈکٹ کا کافی وسیع API ہے اور ہم نے اپنے ذاتی اکاؤنٹ میں درج ذیل سب سسٹمز کو ضم کر دیا ہے:

تکنیکی معاونت کا ماڈیول - آپ کے ذاتی اکاؤنٹ سے درخواستیں سروس کلائنٹس کے لیے شفاف طریقے سے بلنگ کے لیے "پراکسیڈ" ہیں؛
مالیاتی ماڈیول - آپ کو موجودہ کلائنٹس کو انوائس جاری کرنے، رائٹ آف کرنے اور ادائیگی کے دستاویزات بنانے کی اجازت دیتا ہے۔
سروس کنٹرول ماڈیول - اس کے لیے ہمیں اپنے ہینڈلر کو لاگو کرنا پڑا۔ نظام کی وسعت ہمارے ہاتھوں میں چلی گئی اور ہم نے بلی کو ایک نئی قسم کی خدمت "سکھائی"۔
یہ ایک پریشانی کا تھوڑا سا تھا، لیکن ایک یا دوسرا راستہ، مجھے لگتا ہے کہ بلی اور میں ساتھ ملیں گے.

ٹنگسٹن کے کھیتوں سے گزرنا - ٹنگسٹن فیبرک

ٹنگسٹن کے کھیت سیکڑوں تاروں سے بنے ہوئے ہیں، جو ان کے ذریعے معلومات کے ہزاروں بٹس گزرتے ہیں۔ معلومات کو "پیکٹوں" میں جمع کیا جاتا ہے، تجزیہ کیا جاتا ہے، پیچیدہ راستے تعمیر کیے جاتے ہیں، گویا جادو کے ذریعے۔

یہ دوسرے سسٹم کا ڈومین ہے جس کے ساتھ ہمیں دوست بنانا تھا - Tungsten Fabric (TF)، جو پہلے OpenContrail تھا۔ اس کا کام نیٹ ورک کے سامان کا انتظام کرنا ہے، جو ہمیں بطور صارف ایک سافٹ ویئر خلاصہ فراہم کرتا ہے۔ TF - SDN، نیٹ ورک آلات کے ساتھ کام کرنے کی پیچیدہ منطق کو سمیٹتا ہے۔ خود ٹیکنالوجی کے بارے میں ایک اچھا مضمون ہے، مثال کے طور پر، یہاں.

سسٹم نیوٹران پلگ ان کے ذریعے OpenStack (ذیل میں زیر بحث) کے ساتھ مربوط ہے۔

اوپن اسٹیک خدمات کا تعامل۔

آپریشن ڈیپارٹمنٹ کے لڑکوں نے ہمیں اس سسٹم سے متعارف کرایا۔ ہم اپنی سروسز کے نیٹ ورک اسٹیک کو منظم کرنے کے لیے سسٹم کا API استعمال کرتے ہیں۔ اس سے ہمیں ابھی تک کوئی سنگین پریشانی یا تکلیف نہیں ہوئی ہے (میں OE کے لڑکوں کے لیے بات نہیں کر سکتا)، لیکن بات چیت میں کچھ عجیب و غریب چیزیں ہیں۔

سب سے پہلے اس طرح نظر آتے تھے: وہ کمانڈ جو SSH کے ذریعے منسلک ہوتے وقت مثال کے کنسول میں ڈیٹا کی ایک بڑی مقدار کو آؤٹ پٹ کرنے کی ضرورت ہوتی ہے، کنکشن کو صرف "ہینگ اپ" کرتا ہے، جبکہ VNC کے ذریعے سب کچھ صحیح طریقے سے کام کرتا ہے۔

ان لوگوں کے لیے جو اس مسئلے سے واقف نہیں ہیں، یہ کافی مضحکہ خیز لگتا ہے: ls/root صحیح طریقے سے کام کرتا ہے، جب کہ، مثال کے طور پر، اوپر سے "منجمد" مکمل طور پر۔ خوش قسمتی سے، ہمیں پہلے بھی اسی طرح کے مسائل کا سامنا کرنا پڑا ہے۔ کمپیوٹ نوڈس سے راؤٹرز تک کے روٹ پر MTU کو ٹیوننگ کرکے فیصلہ کیا گیا تھا۔ ویسے یہ TF کا مسئلہ نہیں ہے۔

اگلا مسئلہ بالکل کونے کے آس پاس تھا۔ ایک "خوبصورت" لمحے میں، روٹنگ کا جادو غائب ہو گیا، بالکل اسی طرح۔ TF نے آلات پر روٹنگ کا انتظام بند کر دیا ہے۔

ہم نے ایڈمن کی سطح سے اوپن اسٹیک کے ساتھ کام کیا اور اس کے بعد مطلوبہ صارف کی سطح پر چلے گئے۔ ایسا لگتا ہے کہ SDN اس صارف کے دائرہ کار کو "ہائی جیک" کرتا ہے جس کے ذریعے کارروائیاں کی جاتی ہیں۔ حقیقت یہ ہے کہ ایک ہی ایڈمن اکاؤنٹ TF اور OpenStack کو جوڑنے کے لیے استعمال کیا جاتا ہے۔ صارف پر سوئچ کرنے کے مرحلے پر، "جادو" غائب ہو گیا. سسٹم کے ساتھ کام کرنے کے لیے الگ اکاؤنٹ بنانے کا فیصلہ کیا گیا۔ اس نے ہمیں انضمام کی فعالیت کو توڑے بغیر کام کرنے کی اجازت دی۔

سیلیکون لائففارمز - اوپن اسٹیک

ٹنگسٹن کے کھیتوں کے قریب ایک عجیب و غریب شکل والی سلیکون مخلوق رہتی ہے۔ سب سے زیادہ، یہ ایک بڑے بچے کی طرح لگتا ہے جو ہمیں ایک جھولی سے کچل سکتا ہے، لیکن اس کی طرف سے کوئی واضح جارحیت نہیں آرہی ہے۔ یہ خوف کا باعث نہیں ہے، لیکن اس کا سائز خوف کو متاثر کرتا ہے۔ جیسا کہ ارد گرد کیا ہو رہا ہے کی پیچیدگی کرتا ہے.

OpenStack ہمارے پلیٹ فارم کا مرکز ہے۔

OpenStack کے کئی ذیلی نظام ہیں، جن میں سے ہم فی الحال نووا، Glance اور Cinder کو سب سے زیادہ فعال طور پر استعمال کرتے ہیں۔ ان میں سے ہر ایک کا اپنا API ہے۔ Nova کمپیوٹ وسائل اور مثالوں کی تخلیق کے لیے ذمہ دار ہے، سنڈر حجم اور ان کے اسنیپ شاٹس کے انتظام کے لیے ذمہ دار ہے، Glance ایک تصویری خدمت ہے جو OS ٹیمپلیٹس اور ان پر میٹینفارمیشن کا انتظام کرتی ہے۔

ہر سروس ایک کنٹینر میں چلتی ہے، اور میسج بروکر "سفید خرگوش" ہے - RabbitMQ۔

اس نظام نے ہمیں سب سے زیادہ غیر متوقع مصیبت دی۔

اور پہلا مسئلہ آنے میں زیادہ دیر نہیں تھی جب ہم نے سرور سے اضافی والیوم کو جوڑنے کی کوشش کی۔ سنڈر API نے اس کام کو انجام دینے سے صاف انکار کردیا۔ مزید واضح طور پر، اگر آپ خود OpenStack پر یقین رکھتے ہیں، تو کنکشن قائم ہو جاتا ہے، لیکن ورچوئل سرور کے اندر کوئی ڈسک ڈیوائس نہیں ہے۔

ہم نے ایک چکر لگانے کا فیصلہ کیا اور نووا API سے اسی کارروائی کی درخواست کی۔ نتیجہ یہ ہے کہ آلہ صحیح طریقے سے جڑتا ہے اور سرور کے اندر قابل رسائی ہے۔ ایسا لگتا ہے کہ مسئلہ اس وقت ہوتا ہے جب بلاک اسٹوریج سنڈر کو جواب نہیں دیتا ہے۔

ڈسک کے ساتھ کام کرتے وقت ہمیں ایک اور مشکل کا انتظار تھا۔ سسٹم والیوم کو سرور سے منقطع نہیں کیا جا سکا۔

ایک بار پھر، OpenStack خود "قسم کھاتا ہے" کہ اس نے کنکشن کو تباہ کر دیا ہے اور اب آپ صحیح طریقے سے حجم کے ساتھ الگ سے کام کر سکتے ہیں۔ لیکن API واضح طور پر ڈسک پر آپریشن نہیں کرنا چاہتا تھا۔

یہاں ہم نے خاص طور پر لڑنے کا نہیں بلکہ سروس کی منطق کے بارے میں اپنے نقطہ نظر کو تبدیل کرنے کا فیصلہ کیا۔ اگر کوئی مثال ہے تو، سسٹم والیوم بھی ہونا چاہیے۔ لہذا، صارف ابھی تک "سرور" کو حذف کیے بغیر سسٹم "ڈسک" کو ہٹا یا غیر فعال نہیں کرسکتا ہے۔

اوپن اسٹیک سسٹمز کا ایک پیچیدہ سیٹ ہے جس کی اپنی تعامل منطق اور آرنیٹ API ہے۔ ہمیں کافی تفصیلی دستاویزات سے مدد ملتی ہے اور یقیناً، آزمائش اور غلطی (اس کے بغیر ہم کہاں ہوں گے)۔

آزمائشی تجربہ

ہم نے گزشتہ سال دسمبر میں ایک ٹیسٹ لانچ کیا تھا۔ بنیادی کام ہمارے پروجیکٹ کو تکنیکی اور UX کی طرف سے جنگی موڈ میں جانچنا تھا۔ سامعین کو منتخب طور پر مدعو کیا گیا تھا اور ٹیسٹنگ بند کر دی گئی تھی۔ تاہم، ہم نے اپنی ویب سائٹ پر جانچ تک رسائی کی درخواست کرنے کا اختیار بھی چھوڑ دیا ہے۔

ٹیسٹ خود، یقینا، اس کے مضحکہ خیز لمحات کے بغیر نہیں تھا، کیونکہ یہ وہ جگہ ہے جہاں ہماری مہم جوئی ابھی شروع ہو رہی ہے۔

سب سے پہلے، ہم نے کسی حد تک غلط طریقے سے پروجیکٹ میں دلچسپی کا اندازہ لگایا اور ٹیسٹ کے دوران فوری طور پر کمپیوٹ نوڈس کو شامل کرنا پڑا۔ کلسٹر کے لیے ایک عام معاملہ، لیکن یہاں بھی کچھ باریکیاں تھیں۔ TF کے مخصوص ورژن کے لیے دستاویزات کرنل کے مخصوص ورژن کی نشاندہی کرتی ہیں جس پر vRouter کے ساتھ کام کا تجربہ کیا گیا تھا۔ ہم نے مزید حالیہ دانا کے ساتھ نوڈس لانچ کرنے کا فیصلہ کیا۔ نتیجے کے طور پر، TF کو نوڈس سے راستے موصول نہیں ہوئے۔ مجھے فوری طور پر دانا کو واپس کرنا پڑا۔

ایک اور تجسس آپ کے ذاتی اکاؤنٹ میں "پاس ورڈ تبدیل کریں" کے بٹن کی فعالیت سے متعلق ہے۔

ہم نے اپنے ذاتی اکاؤنٹ تک رسائی کو منظم کرنے کے لیے JWT استعمال کرنے کا فیصلہ کیا تاکہ سیشنز کے ساتھ کام نہ کیا جائے۔ چونکہ نظام متنوع اور وسیع پیمانے پر بکھرے ہوئے ہیں، اس لیے ہم اپنے ٹوکن کا انتظام کرتے ہیں، جس میں ہم بلنگ سے سیشنز کو "لپیٹ" کرتے ہیں اور OpenStack سے ایک ٹوکن۔ جب پاس ورڈ تبدیل کیا جاتا ہے، تو ٹوکن، یقیناً "خراب ہو جاتا ہے"، کیونکہ صارف کا ڈیٹا اب درست نہیں رہتا ہے اور اسے دوبارہ جاری کرنے کی ضرورت ہے۔

ہم نے اس نقطہ نظر کو کھو دیا، اور اس ٹکڑے کو جلدی ختم کرنے کے لیے کافی وسائل نہیں تھے۔ ٹیسٹ شروع کرنے سے پہلے ہمیں فعالیت کو ختم کرنا پڑا۔
فی الحال ہم صارف کو لاگ آؤٹ کرتے ہیں اگر پاس ورڈ تبدیل کر دیا گیا ہو۔

ان باریکیوں کے باوجود، جانچ اچھی رہی۔ چند ہفتوں میں، تقریباً 300 لوگ رک گئے۔ ہم صارفین کی نظروں سے پروڈکٹ کو دیکھنے، اسے عملی طور پر جانچنے اور اعلیٰ معیار کے تاثرات جمع کرنے کے قابل تھے۔

جاری رکھنا

ہم میں سے بہت سے لوگوں کے لیے یہ اس پیمانے کا پہلا منصوبہ ہے۔ ہم نے ایک ٹیم کے طور پر کام کرنے اور تعمیراتی اور ڈیزائن کے فیصلے کرنے کے بارے میں بہت سے قیمتی اسباق سیکھے۔ پیچیدہ نظاموں کو کم وسائل کے ساتھ کیسے مربوط کیا جائے اور انہیں پیداوار میں شامل کیا جائے۔

بلاشبہ، کوڈ کے لحاظ سے اور سسٹم انضمام کے انٹرفیس دونوں پر کام کرنے کے لیے کچھ ہے۔ یہ منصوبہ کافی کم عمر ہے، لیکن ہم اسے ایک قابل اعتماد اور آسان سروس کے طور پر بڑھانے کے عزائم سے بھرپور ہیں۔

ہم پہلے ہی سسٹمز کو قائل کرنے میں کامیاب ہو چکے ہیں۔ بل اپنی الماری میں گنتی، بلنگ اور صارف کی درخواستوں کو فرض شناسی سے ہینڈل کرتا ہے۔ ٹنگسٹن فیلڈز کا "جادو" ہمیں مستحکم مواصلت فراہم کرتا ہے۔ اور صرف OpenStack کبھی کبھی دلفریب ہو جاتا ہے، کچھ ایسا چیختا ہے کہ "'WSREP نے ابھی تک ایپلیکیشن کے استعمال کے لیے نوڈ تیار نہیں کیا ہے۔" لیکن یہ بالکل مختلف کہانی ہے...

ہم نے حال ہی میں سروس شروع کی ہے۔
آپ ہماری تمام تفصیلات جان سکتے ہیں۔ ڈاؤن لوڈ، اتارنا.

CLO ترقیاتی ٹیم

کارآمد ویب سائٹس

OpenStack

ٹنگسٹن فیبرک

ماخذ: www.habr.com

سائبر پنک سے ذائقہ دار کلاؤڈ سروس کی تخلیق کی تاریخ