ارے حبر!
ہم Exness پلیٹ فارم ٹیم کی نمائندگی کرتے ہیں۔ اس سے پہلے، ہمارے ساتھیوں نے پہلے ہی ایک مضمون لکھا تھا . آج ہم Kubernetes پر منتقلی کی خدمات کے اپنے تجربے کا اشتراک کرنا چاہتے ہیں۔
شروع کرنے کے لیے، ہم آپ کو کچھ نمبر پیش کرتے ہیں تاکہ اس بات کو بہتر طور پر سمجھا جا سکے کہ کیا بات کی جائے گی:
- ہمارا ڈیولپمنٹ ڈیپارٹمنٹ 100+ لوگوں پر مشتمل ہے، بشمول 10 سے زیادہ مختلف ٹیمیں جن میں خود کفیل QA، DevOps اور Scrum پروسیس ہیں۔ ڈیولپمنٹ اسٹیک - ازگر، پی ایچ پی، سی++، جاوا اور گولانگ۔
- ٹیسٹ اور پیداوار کے ماحول کا سائز تقریباً 2000 کنٹینرز ہر ایک ہے۔ وہ اپنے ورچوئلائزیشن پر اور VMware کے تحت Rancher v1.6 چلا رہے ہیں۔
پریرتا
جیسا کہ وہ کہتے ہیں، کچھ بھی ہمیشہ کے لیے نہیں رہتا، اور رینچر نے ورژن 1.6 کے لیے حمایت ختم کرنے کا اعلان کافی عرصہ پہلے کیا تھا۔ جی ہاں، تین سال سے زیادہ عرصے میں ہم نے اسے تیار کرنے اور پیدا ہونے والے مسائل کو حل کرنے کا طریقہ سیکھ لیا ہے، لیکن زیادہ سے زیادہ ہمیں ایسے مسائل کا سامنا کرنا پڑتا ہے جو کبھی درست نہیں ہوں گے۔ Rancher 1.6 میں حقوق جاری کرنے کے لیے ایک ossified نظام بھی ہے، جہاں آپ یا تو تقریباً سب کچھ کر سکتے ہیں یا کچھ بھی نہیں۔
اگرچہ ملکیتی ورچوئلائزیشن نے ڈیٹا سٹوریج اور اس کی حفاظت پر زیادہ کنٹرول فراہم کیا، لیکن اس نے آپریٹنگ لاگتیں عائد کیں جنہیں کمپنی کی مسلسل ترقی، منصوبوں کی تعداد اور ان کے لیے ضروریات کے پیش نظر قبول کرنا مشکل تھا۔
ہم IaC معیارات کی پیروی کرنا چاہتے تھے اور، اگر ضروری ہو تو، کسی بھی جغرافیائی مقام پر اور وینڈر لاک کے بغیر، تیزی سے صلاحیت حاصل کرنا چاہتے تھے، اور اسے فوری طور پر ترک کرنے کے قابل بھی تھے۔
پہلا قدم
سب سے پہلے، ہم جدید ٹکنالوجیوں اور حلوں پر انحصار کرنا چاہتے تھے جو ٹیموں کو تیز تر ترقیاتی سائیکل حاصل کرنے اور طاقت فراہم کرنے والے پلیٹ فارم کے ساتھ تعامل کے لیے آپریشنل اخراجات کو کم کرنے کی اجازت دیتے ہیں۔
بلاشبہ، ہمارے ذہن میں سب سے پہلی چیز Kubernetes تھی، لیکن ہم پرجوش نہیں ہوئے اور یہ دیکھنے کے لیے تھوڑی تحقیق کی کہ آیا یہ صحیح انتخاب ہے۔ ہم نے صرف اوپن سورس حل کا جائزہ لیا، اور ایک غیر منصفانہ جنگ میں، Kubernetes غیر مشروط طور پر جیت گیا۔
اگلا سوال آیا کہ کلسٹرز بنانے کے لیے ایک ٹول کا انتخاب کیا جائے۔ ہم نے سب سے زیادہ مقبول حلوں کا موازنہ کیا: kops، kubespray، kubeadm.
شروع کرنے کے لیے، kubeadm ہمیں ایک "سائیکل" کے موجد کی طرح ایک راستہ بہت پیچیدہ لگتا تھا، اور kops کے پاس اتنی لچک نہیں تھی۔
اور فاتح تھا:
ہم نے اپنے اپنے ورچوئلائزیشن اور AWS کے ساتھ تجربہ کرنا شروع کیا، تقریباً اپنے پچھلے وسائل کے انتظام کے پیٹرن سے ملتا جلتا کچھ دوبارہ بنانے کی کوشش کی، جہاں سب نے ایک ہی "کلسٹر" کا اشتراک کیا۔ اور اب ہمارے پاس 10 چھوٹی ورچوئل مشینوں کا پہلا کلسٹر ہے، جن میں سے کچھ AWS میں واقع ہیں۔ ہم نے ٹیموں کو وہاں منتقل کرنے کی کوشش شروع کی، سب کچھ "اچھا" لگ رہا تھا، اور کہانی ختم ہو سکتی تھی، لیکن...
پہلے مسائل
جوابی بات وہ ہے جس پر kubespray بنایا گیا ہے، یہ ایسا ٹول نہیں ہے جو آپ کو IaC کی پیروی کرنے کی اجازت دیتا ہے: جب نوڈس کو کمیشن/ڈیکمیشن کرتے ہوئے، کچھ نہ کچھ مسلسل غلط ہوتا رہا اور کسی نہ کسی قسم کی مداخلت کی ضرورت پڑتی تھی، اور مختلف OS استعمال کرتے وقت، پلے بک کا برتاؤ مختلف تھا۔ . جیسے جیسے کلسٹر میں ٹیموں اور نوڈس کی تعداد بڑھتی گئی، ہم نے محسوس کرنا شروع کیا کہ پلے بک کو مکمل ہونے میں زیادہ وقت لگ رہا ہے، اور اس کے نتیجے میں ہمارا ریکارڈ 3,5 گھنٹے کا تھا، آپ کا کیا ہوگا؟ 🙂
اور ایسا لگتا ہے کہ kubespray صرف جواب دہ ہے، اور سب کچھ پہلی نظر میں واضح ہے، لیکن:
سفر کے آغاز میں، کام صرف AWS میں اور ورچوئلائزیشن پر صلاحیتوں کو لانچ کرنا تھا، لیکن پھر، جیسا کہ اکثر ہوتا ہے، ضروریات بدل جاتی ہیں۔
اس کی روشنی میں، یہ واضح ہو گیا کہ وسائل کو ایک آرکیسٹریشن سسٹم میں ملانے کا ہمارا پرانا نمونہ مناسب نہیں تھا - اس صورت میں جہاں کلسٹرز بہت دور دراز ہیں اور ان کا انتظام مختلف فراہم کنندگان کے ذریعے کیا جاتا ہے۔
مزید مزید۔ جب تمام ٹیمیں ایک ہی کلسٹر کے اندر کام کرتی ہیں، تو غلط طریقے سے انسٹال کردہ NodeSelectors کے ساتھ مختلف سروسز دوسری ٹیم کے "غیر ملکی" میزبان کے پاس پرواز کر سکتی ہیں اور وہاں کے وسائل کو استعمال کر سکتی ہیں، اور اگر داغدار ہو، تو مسلسل درخواستیں آتی تھیں کہ ایک یا دوسری سروس کام نہیں کر رہی، انسانی عنصر کی وجہ سے صحیح طریقے سے تقسیم نہیں کیا گیا ہے۔ ایک اور مسئلہ لاگت کا حساب لگانا تھا، خاص طور پر نوڈس میں خدمات کی تقسیم میں دشواریوں پر غور کرنا۔
ایک الگ کہانی ملازمین کے حقوق کا اجراء تھی: ہر ٹیم کلسٹر کے "سر پر" رہنا چاہتی تھی اور اسے مکمل طور پر منظم کرنا چاہتی تھی، جو مکمل طور پر تباہی کا سبب بن سکتی تھی، کیونکہ ٹیمیں بنیادی طور پر ایک دوسرے سے آزاد ہوتی ہیں۔
کیا کیا جائے؟
مندرجہ بالا اور ٹیموں کی زیادہ خود مختار ہونے کی خواہشات کو مدنظر رکھتے ہوئے، ہم نے ایک سادہ نتیجہ اخذ کیا: ایک ٹیم - ایک کلسٹر۔
تو ہمیں دوسرا ملا:
اور پھر تیسرا کلسٹر:
پھر ہم نے سوچنا شروع کیا: چلیں ایک سال میں ہماری ٹیموں کے پاس ایک سے زیادہ کلسٹر ہوں گے؟ مختلف جغرافیائی علاقوں میں، مثال کے طور پر، یا مختلف فراہم کنندگان کے کنٹرول میں؟ اور ان میں سے کچھ کچھ ٹیسٹوں کے لیے فوری طور پر ایک عارضی کلسٹر تعینات کرنے کے قابل ہونا چاہیں گے۔
مکمل Kubernetes آئے گا! یہ ملٹی کوبرنیٹس کی ایک قسم ہے، یہ پتہ چلتا ہے.
ایک ہی وقت میں، ہم سب کو کسی نہ کسی طرح ان تمام کلسٹرز کو برقرار رکھنے، ان تک آسانی سے رسائی کا انتظام کرنے کے ساتھ ساتھ نئے بنانے اور پرانے کو دستی مداخلت کے بغیر ختم کرنے کی ضرورت ہوگی۔
Kubernetes کی دنیا میں اپنے سفر کے آغاز میں کچھ وقت گزر چکا ہے، اور ہم نے دستیاب حلوں کا دوبارہ جائزہ لینے کا فیصلہ کیا۔ پتہ چلا کہ یہ مارکیٹ میں پہلے سے موجود ہے - Rancher 2.2.
ہماری تحقیق کے پہلے مرحلے پر، رینچر لیبز نے پہلے ہی ورژن 2 کی پہلی ریلیز کی تھی، لیکن اگرچہ اسے کچھ پیرامیٹرز کے ساتھ بیرونی انحصار کے بغیر کنٹینر لانچ کرکے یا سرکاری HELM چارٹ کا استعمال کرکے بہت تیزی سے اٹھایا جاسکتا تھا، لیکن یہ خام معلوم ہوتا تھا۔ ہمارے لیے، اور ہم نہیں جانتے تھے کہ آیا ہم اس فیصلے پر بھروسہ کر سکتے ہیں کہ آیا اسے تیار کیا جائے گا یا جلدی سے ترک کر دیا جائے گا۔ خود UI میں کلسٹر = کلکس کا نمونہ بھی ہمارے موافق نہیں تھا، اور ہم RKE سے منسلک نہیں ہونا چاہتے تھے، کیونکہ یہ ایک بہت ہی کم توجہ مرکوز کرنے والا ٹول ہے۔
ورژن رینچر 2.2 پہلے سے زیادہ قابل عمل شکل کا حامل تھا اور پچھلے ورژن کے ساتھ اس میں بہت ساری دلچسپ خصوصیات موجود تھیں، جیسے بہت سے بیرونی فراہم کنندگان کے ساتھ انضمام، حقوق کی تقسیم کا ایک نقطہ اور kubeconfig فائلز، ایک kubectl لانچ کرنا۔ UI میں آپ کے حقوق کے ساتھ تصویر، نیسٹڈ نیم اسپیس عرف پروجیکٹس۔
Rancher 2 کے ارد گرد پہلے سے ہی ایک کمیونٹی بھی بنی ہوئی تھی، اور اس کا انتظام کرنے کے لیے HashiCorp Terraform نامی ایک فراہم کنندہ بنایا گیا تھا، جس نے ہمیں سب کچھ ایک ساتھ رکھنے میں مدد کی۔
کیا ہوا
نتیجے کے طور پر، ہم نے Rancher چلانے والے ایک چھوٹے سے کلسٹر کے ساتھ اختتام کیا، جو دوسرے تمام کلسٹرز کے ساتھ ساتھ اس سے جڑے ہوئے بہت سے کلسٹرز کے لیے قابل رسائی ہے، جن میں سے کسی بھی تک رسائی صرف اسی طرح دی جا سکتی ہے جیسے کسی صارف کو ldap ڈائریکٹری میں شامل کرنا، قطع نظر اس کے۔ یہ کہاں واقع ہے اور یہ کون سے فراہم کنندہ کے وسائل استعمال کرتا ہے۔
gitlab-ci اور Terraform کا استعمال کرتے ہوئے، ایک ایسا نظام بنایا گیا تھا جو آپ کو کلاؤڈ پرووائیڈرز یا ہمارے اپنے انفراسٹرکچر میں کسی بھی کنفیگریشن کا کلسٹر بنانے اور انہیں Rancher سے جوڑنے کی اجازت دیتا ہے۔ یہ سب IaC سٹائل میں کیا جاتا ہے، جہاں ہر کلسٹر کو ایک ذخیرہ کے ذریعے بیان کیا جاتا ہے، اور اس کی حالت کو ورژن بنایا جاتا ہے۔ ایک ہی وقت میں، زیادہ تر ماڈیولز بیرونی ذخیروں سے جڑے ہوتے ہیں تاکہ جو کچھ باقی رہتا ہے وہ متغیرات کو منتقل کرنا یا مثالوں کے لیے آپ کی حسب ضرورت ترتیب کو بیان کرنا ہے، جس سے کوڈ کی تکرار کے فیصد کو کم کرنے میں مدد ملتی ہے۔
بلاشبہ، ہمارا سفر ابھی ختم نہیں ہوا اور ابھی بھی بہت سے دلچسپ کام باقی ہیں، جیسے کہ کسی بھی کلسٹر کے لاگ اور میٹرکس کے ساتھ کام کا ایک نقطہ، سروس میش، ملٹی کلسٹر میں بوجھ کے انتظام کے لیے گیٹپس اور بہت کچھ۔ ہم امید کرتے ہیں کہ آپ کو ہمارا تجربہ دلچسپ لگے گا!
مضمون A. Antipov، A. Ganush، پلیٹ فارم انجینئرز نے لکھا تھا۔
ماخذ: www.habr.com