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

ہم فائنٹیک کمپنی Exness سے ہیں، جو B2B اور B2C کے لیے آن لائن ٹریڈنگ اور فنٹیک مصنوعات کے لیے خدمات تیار کرتی ہے۔ ہمارے R&D میں بہت سی مختلف ٹیمیں ہیں، ڈیولپمنٹ ڈیپارٹمنٹ میں 100+ ملازمین ہیں۔

ہم اس ٹیم کی نمائندگی کرتے ہیں جو کوڈ جمع کرنے اور چلانے کے لیے ہمارے ڈویلپرز کے پلیٹ فارم کی ذمہ دار ہے۔ خاص طور پر، ہم ایپلی کیشنز سے میٹرکس، لاگز اور ایونٹس کو جمع کرنے، اسٹور کرنے اور رپورٹ کرنے کے ذمہ دار ہیں۔ ہم فی الحال تقریباً تین ہزار Docker کنٹینرز کو پیداواری ماحول میں چلاتے ہیں، اپنے 50 TB بڑے ڈیٹا اسٹوریج کو برقرار رکھتے ہیں، اور تعمیراتی حل فراہم کرتے ہیں جو ہمارے بنیادی ڈھانچے کے ارد گرد بنائے گئے ہیں: Kubernetes، Rancher، اور مختلف عوامی کلاؤڈ فراہم کرنے والے۔ 

ہماری حوصلہ افزائی

کیا جل رہا ہے؟ کوئی جواب نہیں دے سکتا۔ چولہا کہاں ہے؟ یہ سمجھنا مشکل ہے۔ کب آگ لگی؟ آپ کو پتہ چل سکتا ہے، لیکن ابھی نہیں. 

کچھ کنٹینر کیوں کھڑے ہیں جبکہ کچھ گر گئے ہیں؟ کون سا کنٹینر قصوروار تھا؟ سب کے بعد، کنٹینرز کے باہر ایک جیسے ہیں، لیکن ہر ایک کے اندر اس کی اپنی Neo ہے.

ہمارے ڈویلپرز قابل لوگ ہیں۔ وہ اچھی خدمات انجام دیتے ہیں جو کمپنی کو منافع بخشتے ہیں۔ لیکن جب ایپلی کیشنز والے کنٹینرز گمراہ ہو جاتے ہیں تو ناکامیاں ہوتی ہیں۔ ایک کنٹینر بہت زیادہ CPU استعمال کرتا ہے، دوسرا نیٹ ورک کھاتا ہے، تیسرا I/O آپریشنز استعمال کرتا ہے، اور چوتھا مکمل طور پر واضح نہیں ہے کہ یہ ساکٹ کے ساتھ کیا کرتا ہے۔ یہ سب گر جاتا ہے اور جہاز ڈوب جاتا ہے۔ 

ایجنٹ۔

یہ سمجھنے کے لیے کہ اندر کیا ہو رہا ہے، ہم نے ایجنٹوں کو براہ راست کنٹینرز میں رکھنے کا فیصلہ کیا۔

یہ ایجنٹ ایسے پروگراموں کو روکتے ہیں جو کنٹینرز کو ایسی حالت میں رکھتے ہیں کہ وہ ایک دوسرے کو نہ توڑیں۔ ایجنٹوں کو معیاری بنایا جاتا ہے، اور یہ کنٹینرز کی خدمت کے لیے معیاری طریقہ کار کی اجازت دیتا ہے۔ 

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

ایجنٹوں کا مطلب آپریشن اور دیکھ بھال کے لیے ایسی افادیت بھی ہے جو مختلف آرکیسٹریشن سسٹمز میں کام کر سکتی ہیں جو مختلف امیجز (Debian، Alpine، Centos، وغیرہ) کو سپورٹ کرتے ہیں۔

آخر میں، ایجنٹوں کو سادہ CI/CD کو سپورٹ کرنا چاہیے جس میں Docker فائلیں شامل ہوں۔ دوسری صورت میں، جہاز الگ ہو جائے گا، کیونکہ کنٹینرز "ٹیڑھی" ریلوں کے ساتھ پہنچانا شروع ہو جائیں گے۔

عمل اور ہدف تصویر آلہ کی تعمیر

ہر چیز کو معیاری اور قابل انتظام رکھنے کے لیے، کسی قسم کے معیاری تعمیراتی عمل کی پیروی کرنے کی ضرورت ہے۔ لہذا، ہم نے کنٹینرز کے ذریعہ کنٹینرز کو جمع کرنے کا فیصلہ کیا - یہ تکرار ہے.

یہاں کنٹینرز کو ٹھوس خاکہ کے ذریعہ دکھایا گیا ہے۔ اسی وقت، انہوں نے ان میں ڈسٹری بیوشن کٹس ڈالنے کا فیصلہ کیا تاکہ "زندگی رسبریوں کی طرح نہ لگے۔" ایسا کیوں کیا گیا، ہم ذیل میں بیان کریں گے۔
 
نتیجہ ایک بلڈ ٹول ہے - ایک ورژن کے ساتھ مخصوص کنٹینر جو مخصوص تقسیمی ورژن اور مخصوص اسکرپٹ ورژن کا حوالہ دیتا ہے۔

ہم اسے کیسے استعمال کرتے ہیں؟ ہمارے پاس ایک Docker Hub ہے جس میں ایک کنٹینر ہوتا ہے۔ بیرونی انحصار سے چھٹکارا حاصل کرنے کے لیے ہم اسے اپنے سسٹم کے اندر آئینہ دیتے ہیں۔ نتیجہ پیلے رنگ میں نشان زد ایک کنٹینر ہے. ہم کنٹینر میں درکار تمام ڈسٹری بیوشنز اور اسکرپٹس کو انسٹال کرنے کے لیے ایک ٹیمپلیٹ بناتے ہیں۔ اس کے بعد، ہم استعمال کے لیے تیار تصویر جمع کرتے ہیں: ڈویلپرز اس میں کوڈ اور اپنی کچھ خاص انحصاریاں ڈالتے ہیں۔ 

اس نقطہ نظر کے بارے میں کیا اچھا ہے؟ 

• سب سے پہلے، بلڈ ٹولز کا مکمل ورژن کنٹرول - کنٹینر، اسکرپٹ اور ڈسٹری بیوشن ورژن کی تعمیر۔ 
• دوم، ہم نے معیاری کاری حاصل کر لی ہے: ہم اسی طرح ٹیمپلیٹس، انٹرمیڈیٹ اور استعمال کے لیے تیار تصویر بناتے ہیں۔ 
• تیسرا، کنٹینرز ہمیں پورٹیبلٹی دیتے ہیں۔ آج ہم Gitlab استعمال کرتے ہیں، اور کل ہم TeamCity یا Jenkins پر جائیں گے اور ہم اپنے کنٹینرز کو اسی طرح چلا سکیں گے۔ 
• چوتھا، انحصار کو کم سے کم کرنا۔ یہ کوئی اتفاقی بات نہیں تھی کہ ہم نے ڈسٹری بیوشن کٹس کو کنٹینر میں ڈال دیا، کیونکہ یہ ہمیں ہر بار انٹرنیٹ سے ڈاؤن لوڈ کرنے سے بچنے کی اجازت دیتا ہے۔ 
• پانچویں، تعمیر کی رفتار میں اضافہ ہوا ہے - تصاویر کی مقامی کاپیوں کی موجودگی آپ کو ڈاؤن لوڈ کرنے میں وقت ضائع کرنے سے بچنے کی اجازت دیتی ہے، کیونکہ ایک مقامی تصویر موجود ہے۔ 

دوسرے الفاظ میں، ہم نے ایک کنٹرول شدہ اور لچکدار اسمبلی عمل حاصل کر لیا ہے۔ ہم کسی بھی مکمل ورژن والے کنٹینرز کو بنانے کے لیے وہی ٹولز استعمال کرتے ہیں۔ 

ہمارا تعمیراتی طریقہ کار کیسے کام کرتا ہے۔

اسمبلی کو ایک کمانڈ کے ساتھ شروع کیا گیا ہے، عمل کو تصویر میں (سرخ رنگ میں نمایاں کیا گیا ہے) میں عمل میں لایا گیا ہے۔ ڈویلپر کے پاس ایک Docker فائل ہے (پیلے رنگ میں نمایاں کیا گیا ہے)، ہم اسے رینڈر کرتے ہیں، متغیر کو قدروں سے بدل دیتے ہیں۔ اور راستے میں ہم ہیڈر اور فوٹر شامل کرتے ہیں - یہ ہمارے ایجنٹ ہیں۔ 

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

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

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

 

اسی کنٹینر کے لیے ہمیں Docker اور Kubernetes میں مختلف پروسیس ٹری ملتے ہیں:

پے لوڈ S6 کی نگرانی میں انجام دیا جاتا ہے۔ کلکٹر اور واقعات پر توجہ دیں - یہ ہمارے ایجنٹ ہیں جو لاگ اور میٹرکس کے ذمہ دار ہیں۔ کبرنیٹس کے پاس وہ نہیں ہے، لیکن ڈوکر کے پاس ہے۔ کیوں؟ 

اگر ہم "پوڈ" کی تصریحات کو دیکھیں (اس کے بعد - Kubernetes pod)، ہم دیکھیں گے کہ واقعات کا کنٹینر ایک پوڈ میں انجام دیا جاتا ہے، جس میں ایک الگ کلکٹر کنٹینر ہوتا ہے جو میٹرکس اور لاگز کو جمع کرنے کا کام انجام دیتا ہے۔ ہم Kubernetes کی صلاحیتوں کو استعمال کر سکتے ہیں: کنٹینرز کو ایک پوڈ میں چلانا، ایک ہی عمل میں اور/یا نیٹ ورک کی جگہ۔ دراصل اپنے ایجنٹوں کو متعارف کروائیں اور کچھ کام انجام دیں۔ اور اگر وہی کنٹینر ڈوکر میں لانچ کیا جاتا ہے، تو اسے آؤٹ پٹ جیسی تمام صلاحیتیں حاصل ہوں گی، یعنی یہ لاگ اور میٹرکس فراہم کرنے کے قابل ہو جائے گا، کیونکہ ایجنٹوں کو اندرونی طور پر لانچ کیا جائے گا۔ 

میٹرکس اور لاگز

میٹرکس اور لاگ کی فراہمی ایک پیچیدہ کام ہے۔ اس کے فیصلے کے کئی پہلو ہیں۔
بنیادی ڈھانچہ پے لوڈ کے نفاذ کے لیے بنایا گیا ہے، نہ کہ لاگز کی بڑے پیمانے پر ترسیل کے لیے۔ یعنی، یہ عمل کم سے کم کنٹینر وسائل کی ضروریات کے ساتھ انجام دیا جانا چاہیے۔ ہم اپنے ڈویلپرز کی مدد کرنے کی کوشش کرتے ہیں: "ایک Docker Hub کنٹینر حاصل کریں، اسے چلائیں، اور ہم لاگ ڈیلیور کر سکتے ہیں۔" 

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

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

اور آخری پہلو وسائل کی کھپت کو کم سے کم کرنا ہے۔

ہم نے ٹیلی گراف نامی اوپن سورس گو حل کا انتخاب کیا۔ یہ ایک یونیورسل کنیکٹر ہے جو 140 سے زیادہ قسم کے ان پٹ چینلز (ان پٹ پلگ ان) اور 30 ​​قسم کے آؤٹ پٹ چینلز (آؤٹ پٹ پلگ ان) کو سپورٹ کرتا ہے۔ ہم نے اسے حتمی شکل دے دی ہے اور اب ہم آپ کو بتائیں گے کہ بطور مثال Kubernetes کا استعمال کرتے ہوئے ہم اسے کیسے استعمال کرتے ہیں۔ 

فرض کریں کہ ایک ڈویلپر کام کا بوجھ لگاتا ہے اور Kubernetes کو پوڈ بنانے کی درخواست موصول ہوتی ہے۔ اس مقام پر، کلکٹر نامی ایک کنٹینر ہر پوڈ کے لیے خود بخود بن جاتا ہے (ہم میوٹیشن ویب ہک استعمال کرتے ہیں)۔ کلکٹر ہمارا ایجنٹ ہے۔ شروع میں، یہ کنٹینر پرومیتھیس اور لاگ جمع کرنے کے نظام کے ساتھ کام کرنے کے لیے خود کو ترتیب دیتا ہے۔

• ایسا کرنے کے لیے، یہ پوڈ تشریحات کا استعمال کرتا ہے، اور اس کے مواد کی بنیاد پر، ایک Prometheus end-point تخلیق کرتا ہے۔ 
• پوڈ کی تفصیلات اور مخصوص کنٹینر کی ترتیبات کی بنیاد پر، یہ فیصلہ کرتا ہے کہ لاگز کیسے ڈیلیور کیے جائیں۔

ہم Docker API کے ذریعے لاگز جمع کرتے ہیں: ڈویلپرز کو صرف انہیں stdout یا stderr میں ڈالنے کی ضرورت ہے، اور کلکٹر اسے ترتیب دے گا۔ لاگز کو کچھ تاخیر کے ساتھ ٹکڑوں میں جمع کیا جاتا ہے تاکہ ممکنہ میزبان اوورلوڈ کو روکا جا سکے۔ 

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

• لاگز Graylog میں دستیاب ہیں (بصری تجزیہ کے لیے)؛
• لاگز، میٹرکس، ایونٹس کلک ہاؤس کو طویل مدتی اسٹوریج کے لیے بھیجے جاتے ہیں۔

AWS میں سب کچھ بالکل ویسا ہی کام کرتا ہے، صرف ہم Graylog کو Kafka سے Cloudwatch سے بدل دیتے ہیں۔ ہم وہاں لاگ بھیجتے ہیں، اور سب کچھ بہت آسان ہوتا ہے: یہ فوری طور پر واضح ہو جاتا ہے کہ وہ کس کلسٹر اور کنٹینر سے تعلق رکھتے ہیں۔ Google Stackdriver کے لیے بھی یہی بات ہے۔ یعنی ہماری اسکیم کافکا کے ساتھ اور کلاؤڈ میں دونوں طرح سے کام کرتی ہے۔ 

اگر ہمارے پاس پوڈ کے ساتھ Kubernetes نہیں ہے، تو اسکیم کچھ زیادہ پیچیدہ ہے، لیکن یہ انہی اصولوں پر کام کرتی ہے۔

اسی عمل کو کنٹینر کے اندر انجام دیا جاتا ہے، وہ S6 کا استعمال کرتے ہوئے ترتیب دیے جاتے ہیں۔ تمام ایک جیسے عمل ایک ہی کنٹینر کے اندر چل رہے ہیں۔

اس کے نتیجے کے طور پر،

ہم نے تصاویر بنانے اور لانچ کرنے کے لیے ایک مکمل حل بنایا ہے، جس میں لاگ اور میٹرکس کو جمع کرنے اور پہنچانے کے اختیارات ہیں:

• ہم نے تصاویر کو جمع کرنے کے لیے ایک معیاری نقطہ نظر تیار کیا، اور اس کی بنیاد پر ہم نے CI ٹیمپلیٹس تیار کیے۔
• ڈیٹا اکٹھا کرنے والے ایجنٹ ہمارے ٹیلی گراف ایکسٹینشن ہیں۔ ہم نے انہیں پیداوار میں اچھی طرح آزمایا۔
• ہم پھلیوں میں ایجنٹوں کے ساتھ کنٹینرز کو لاگو کرنے کے لیے میوٹیشن ویب ہک کا استعمال کرتے ہیں۔ 
• Kubernetes/Rancher ماحولیاتی نظام میں مربوط؛
• ہم ایک ہی کنٹینرز کو مختلف آرکیسٹریشن سسٹم میں چلا سکتے ہیں اور نتیجہ حاصل کر سکتے ہیں جس کی ہم توقع کرتے ہیں۔
• مکمل طور پر متحرک کنٹینر مینجمنٹ کنفیگریشن بنائی۔ 

شریک مصنف: الیا پروڈنکوف

ماخذ: www.habr.com