توقع میں وٹالی خبرروف انٹرویو کیا دمتری سٹولیاروف ()، تکنیکی ڈائریکٹر اور فلانٹ کمپنی کے شریک بانی۔ وٹالی نے دمتری سے پوچھا کہ فلانٹ کیا کرتا ہے، کبرنیٹس، ماحولیاتی نظام کی ترقی، سپورٹ کے بارے میں۔ ہم نے بحث کی کہ کبرنیٹس کی ضرورت کیوں ہے اور کیا اس کی بالکل بھی ضرورت ہے۔ اور مائیکرو سروسز کے بارے میں، Amazon AWS، DevOps کے لیے "میں خوش قسمت ہوں" کا نقطہ نظر، خود Kubernetes کا مستقبل، کیوں، کب اور کیسے یہ دنیا کو اپنی لپیٹ میں لے گا، DevOps کے امکانات اور انجینئرز کو کن چیزوں کے لیے تیاری کرنی چاہیے۔ آسان اور عصبی نیٹ ورکس کے ساتھ روشن اور مستقبل قریب۔
DevOps Deflop پر ایک پوڈ کاسٹ کے طور پر سنیں - DevOps کے بارے میں ایک روسی زبان کا پوڈ کاسٹ، اور نیچے متنی ورژن ہے۔
یہاں اور نیچے وہ سوالات پوچھتا ہے۔ ایکسپریس 42 سے انجینئر۔
"Flant" کے بارے میں
- ہیلو دیما۔ آپ ٹیکنیکل ڈائریکٹر ہیں"اور اس کا بانی بھی۔ براہ کرم ہمیں بتائیں کہ کمپنی کیا کرتی ہے اور آپ اس میں کیا ہیں؟
دیمیتری: باہر سے ایسا لگتا ہے کہ ہم وہ لوگ ہیں جو ہر ایک کے لیے Kubernetes انسٹال کرتے ہیں اور اس کے ساتھ کچھ کرتے ہیں۔ لیکن یہ سچ نہیں ہے۔ ہم نے ایک کمپنی کے طور پر شروعات کی جو لینکس کے ساتھ کام کرتی ہے، لیکن ایک طویل عرصے سے ہماری اہم سرگرمی پروڈکشن اور زیادہ بوجھ والے ٹرنکی پروجیکٹس کی خدمت کر رہی ہے۔ عام طور پر ہم شروع سے پورے انفراسٹرکچر کی تعمیر کرتے ہیں اور پھر طویل عرصے تک اس کے ذمہ دار ہوتے ہیں۔ لہذا، اہم کام جو "Flant" کرتا ہے، جس کے لیے اسے رقم ملتی ہے۔ ذمہ داری لینا اور ٹرنکی پروڈکشن کو نافذ کرنا.
میں، تکنیکی ڈائریکٹر اور کمپنی کے بانیوں میں سے ایک کے طور پر، سارا دن اور رات یہ جاننے کی کوشش میں صرف کرتا ہوں کہ کس طرح پیداوار کی رسائی کو بڑھایا جائے، اس کے کام کو آسان بنایا جائے، منتظمین کی زندگی کو آسان بنایا جائے، اور ڈویلپرز کی زندگی کو مزید خوشگوار بنایا جائے۔ .
Kubernetes کے بارے میں
- حال ہی میں میں فلانٹ اور سے بہت ساری رپورٹس دیکھ رہا ہوں۔ Kubernetes کے بارے میں آپ اس تک کیسے پہنچے؟
دیمیتری: میں اس کے بارے میں پہلے بھی کئی بار بات کر چکا ہوں، لیکن مجھے اسے دہرانے میں کوئی اعتراض نہیں ہے۔ میرے خیال میں اس موضوع کو دہرانا درست ہے کیونکہ وجہ اور اثر میں الجھن ہے۔
ہمیں واقعی ایک ٹول کی ضرورت تھی۔ ہم نے بہت سے مسائل کا سامنا کیا، جدوجہد کی، مختلف بیساکھیوں سے ان پر قابو پایا اور ایک آلے کی ضرورت محسوس کی۔ ہم نے بہت سے مختلف اختیارات سے گزرے، اپنی بائک بنائی، اور تجربہ حاصل کیا۔ آہستہ آہستہ ہم اس مقام پر پہنچ گئے جہاں ہم نے ڈوکر کے ظاہر ہوتے ہی اسے استعمال کرنا شروع کر دیا - 2013 کے آس پاس۔ اس کے ظہور کے وقت، ہمیں پہلے سے ہی کنٹینرز کا کافی تجربہ تھا، ہم نے پہلے ہی "Docker" کا ایک اینالاگ لکھا تھا - Python میں ہماری اپنی بیساکھیوں میں سے کچھ۔ ڈوکر کی آمد کے ساتھ، بیساکھیوں کو پھینکنا اور ایک قابل اعتماد اور کمیونٹی کے تعاون سے چلنے والا حل استعمال کرنا ممکن ہو گیا۔
Kubernetes کے ساتھ کہانی اسی طرح کی ہے. جب تک اس نے رفتار پکڑنا شروع کی - ہمارے لئے یہ ورژن 1.2 ہے - ہمارے پاس پہلے سے ہی شیل اور شیف دونوں پر بیساکھیوں کا ایک گروپ تھا، جسے ہم نے کسی نہ کسی طرح ڈوکر کے ساتھ آرکیسٹریٹ کرنے کی کوشش کی۔ ہم سنجیدگی سے Rancher اور دیگر مختلف حلوں کی طرف دیکھ رہے تھے، لیکن پھر Kubernetes نمودار ہوئے، جس میں ہر چیز کو بالکل اسی طرح نافذ کیا جاتا ہے جیسا کہ ہم نے کیا ہوتا یا اس سے بھی بہتر۔ شکایت کرنے کی کوئی بات نہیں ہے۔
ہاں، یہاں کسی قسم کی خامی ہے، وہاں کسی قسم کی خامی ہے - بہت ساری خامیاں ہیں، اور 1.2 عام طور پر خوفناک ہے، لیکن... Kubernetes ایک زیر تعمیر عمارت کی طرح ہے - آپ پروجیکٹ کو دیکھیں اور سمجھیں کہ یہ ٹھنڈا ہو جائے گا. اگر عمارت میں اب ایک بنیاد اور دو منزلیں ہیں، تو آپ سمجھیں گے کہ ابھی اندر نہ جانا ہی بہتر ہے، لیکن سافٹ ویئر کے ساتھ ایسی کوئی پریشانی نہیں ہے - آپ اسے پہلے ہی استعمال کر سکتے ہیں۔
ہمارے پاس کوئی لمحہ نہیں تھا جہاں ہم نے کبرنیٹس کو استعمال کرنے یا نہ کرنے کے بارے میں سوچا تھا۔ ہم اس کے ظاہر ہونے سے بہت پہلے اس کا انتظار کر رہے تھے، اور خود ہی ینالاگ بنانے کی کوشش کی۔
Kubernetes کے بارے میں
- کیا آپ خود کوبرنیٹس کی ترقی میں براہ راست ملوث ہیں؟
دیمیتری: معمولی۔ بلکہ ہم ماحولیاتی نظام کی ترقی میں حصہ لیتے ہیں۔ ہم پل کی درخواستوں کی ایک خاص تعداد بھیجتے ہیں: پرومیتھیس کو، مختلف آپریٹرز کو، ہیلم کو - ماحولیاتی نظام کو۔ بدقسمتی سے، میں ہر اس کام کا ٹریک رکھنے کے قابل نہیں ہوں جو ہم کرتے ہیں اور میں غلط بھی ہو سکتا ہوں، لیکن ہمارے اندر سے ایک بھی پول نہیں ہے۔
- ایک ہی وقت میں، کیا آپ Kubernetes کے ارد گرد اپنے بہت سے ٹولز تیار کرتے ہیں؟
دیمیتری: حکمت عملی یہ ہے: ہم جاتے ہیں اور ہر اس چیز کی درخواستیں کھینچتے ہیں جو پہلے سے موجود ہے۔ اگر پل کی درخواستیں وہاں قبول نہیں کی جاتی ہیں، تو ہم انہیں خود ہی کانٹے دیتے ہیں اور اس وقت تک زندہ رہتے ہیں جب تک کہ وہ ہماری تعمیرات کے ساتھ قبول نہیں ہو جاتے۔ پھر، جب یہ اپ اسٹریم تک پہنچتا ہے، تو ہم اپ اسٹریم ورژن پر واپس چلے جاتے ہیں۔
مثال کے طور پر، ہمارے پاس ایک پرومیتھیس آپریٹر ہے، جس کے ساتھ ہم نے اپنی اسمبلی کے اوپری حصے میں شاید 5 بار پہلے ہی سوئچ کیا ہے۔ ہمیں کسی قسم کی خصوصیت کی ضرورت ہے، ہم نے پل کی درخواست بھیجی ہے، ہمیں اسے کل رول آؤٹ کرنے کی ضرورت ہے، لیکن ہم اس کے اپ اسٹریم کے جاری ہونے کا انتظار نہیں کرنا چاہتے۔ اس کے مطابق، ہم اپنے لیے جمع کرتے ہیں، اپنی خصوصیت کے ساتھ اپنی اسمبلی کو رول آؤٹ کرتے ہیں، جس کی ہمیں کسی وجہ سے ضرورت ہوتی ہے، اپنے تمام کلسٹرز میں۔ پھر، مثال کے طور پر، وہ اسے ان الفاظ کے ساتھ اپ اسٹریم میں ہمارے حوالے کر دیتے ہیں: "یار، آئیے اسے زیادہ عام کیس کے لیے کرتے ہیں،" ہم، یا کوئی اور، اسے ختم کر دیتے ہیں، اور وقت کے ساتھ ساتھ یہ دوبارہ ضم ہو جاتا ہے۔
ہم ہر وہ چیز تیار کرنے کی کوشش کرتے ہیں جو موجود ہے۔. بہت سے عناصر جو ابھی تک موجود نہیں ہیں، ابھی تک ایجاد نہیں ہوئے، یا ایجاد ہوئے ہیں، لیکن ان پر عمل درآمد کا وقت نہیں ہے - ہم یہ کر رہے ہیں۔ اور اس لیے نہیں کہ ہم ایک صنعت کے طور پر عمل یا سائیکل کی تعمیر کو پسند کرتے ہیں، بلکہ صرف اس لیے کہ ہمیں اس ٹول کی ضرورت ہے۔ یہ سوال اکثر پوچھا جاتا ہے کہ ہم نے یہ یا وہ کام کیوں کیا؟ جواب آسان ہے - ہاں، کیونکہ ہمیں آگے جانا تھا، کچھ عملی مسئلہ حل کرنا تھا، اور ہم نے اسے اس ٹولہ سے حل کیا۔
راستہ ہمیشہ ایسا ہی ہوتا ہے: ہم بہت احتیاط سے تلاش کرتے ہیں اور، اگر ہمیں روٹی کے ایک ٹکڑے سے ٹرالی بس بنانے کا کوئی حل نہیں ملتا، تو ہم اپنی روٹی اور اپنی ٹرالی بس خود بناتے ہیں۔
فلانٹا کے اوزار
— میں جانتا ہوں کہ فلانٹ کے پاس اب ایڈون آپریٹرز، شیل آپریٹرز، اور ڈیپ/ورف ٹولز ہیں۔ جیسا کہ میں سمجھتا ہوں، یہ مختلف اوتاروں میں ایک ہی آلہ ہے۔ میں یہ بھی سمجھتا ہوں کہ Flaunt کے اندر بہت سے مختلف ٹولز موجود ہیں۔ یہ حقیقت ہے؟
دیمیتری: ہمارے پاس GitHub پر بہت کچھ ہے۔ مجھے اب جو یاد ہے اس سے، ہمارے پاس ایک اسٹیٹس میپ ہے - گرافانا کے لیے ایک پینل جسے سب نے دیکھا ہے۔ میڈیم پر Kubernetes کی نگرانی کے بارے میں تقریباً ہر دوسرے مضمون میں اس کا تذکرہ ہوتا ہے۔ اسٹیٹس میپ کیا ہے اس کی مختصراً وضاحت کرنا ناممکن ہے - اس کے لیے ایک الگ مضمون کی ضرورت ہے، لیکن وقت کے ساتھ اسٹیٹس کی نگرانی کے لیے یہ ایک بہت مفید چیز ہے، کیونکہ کبرنیٹس میں ہمیں اکثر وقت کے ساتھ اسٹیٹس دکھانے کی ضرورت ہوتی ہے۔ ہمارے پاس لاگ ہاؤس بھی ہے - یہ کلک ہاؤس پر مبنی چیز ہے اور کوبرنیٹس میں لاگز جمع کرنے کے لیے کالا جادو ہے۔
بہت ساری افادیت! اور اس سے بھی زیادہ ہو جائے گا، کیونکہ اس سال متعدد داخلی حل جاری کیے جائیں گے۔ ایڈون آپریٹر پر مبنی بہت بڑے میں سے، Kubernetes کے لیے ایڈونز کا ایک گروپ ہے، ala کس طرح صحیح طریقے سے sert Manager کو انسٹال کرنا ہے - سرٹیفکیٹس کے انتظام کے لیے ایک ٹول، Prometheus کو صحیح طریقے سے کیسے انسٹال کیا جائے اور لوازمات کے ایک گروپ کے ساتھ - یہ تقریباً بیس مختلف ہیں۔ بائنریز جو ڈیٹا ایکسپورٹ کرتی ہیں اور کچھ اکٹھا کرتی ہیں، اس میں پرومیتھیس کے پاس انتہائی حیرت انگیز گرافکس اور الرٹس ہیں۔ یہ سب کچھ Kubernetes کے ایڈونز کا صرف ایک گروپ ہے، جو ایک کلسٹر میں نصب ہیں، اور یہ سادہ سے ٹھنڈا، نفیس، خودکار ہو جاتا ہے، جس میں بہت سے مسائل پہلے ہی حل ہو چکے ہیں۔ ہاں، ہم بہت کچھ کرتے ہیں۔
ماحولیاتی نظام کی ترقی
"مجھے لگتا ہے کہ یہ اس آلے اور اس کے استعمال کے طریقوں کی ترقی میں ایک بہت بڑا تعاون ہے۔" کیا آپ اندازاً اندازہ لگا سکتے ہیں کہ ماحولیاتی نظام کی ترقی میں اور کون ایسا ہی حصہ ڈالے گا؟
دیمیتری: روس میں، ہماری مارکیٹ میں کام کرنے والی کمپنیوں میں سے، کوئی بھی قریب نہیں ہے۔. بلاشبہ، یہ ایک بلند بیان ہے، کیونکہ میل اور Yandex جیسے بڑے کھلاڑی ہیں - وہ بھی Kubernetes کے ساتھ کچھ کر رہے ہیں، لیکن یہاں تک کہ وہ پوری دنیا میں ان کمپنیوں کے تعاون کے قریب نہیں آتے جو ہم سے کہیں زیادہ کرتی ہیں۔ فلانٹ کا موازنہ کرنا مشکل ہے، جس کا عملہ 80 افراد پر مشتمل ہے، اور Red Hat، جس میں فی Kubernetes 300 انجینئرز ہیں، اگر میں غلط نہیں ہوں۔ اس کا موازنہ کرنا مشکل ہے۔ ہمارے پاس RnD ڈپارٹمنٹ میں 6 لوگ ہیں، جن میں مجھ سمیت، جنہوں نے ہمارے تمام اوزار کاٹ دیے۔ 6 افراد بمقابلہ 300 Red Hat انجینئرز - اس کا موازنہ کرنا کسی حد تک مشکل ہے۔
- تاہم، جب یہ 6 لوگ بھی واقعی مفید اور اجنبی کچھ کر سکتے ہیں، جب انہیں کسی عملی مسئلے کا سامنا کرنا پڑتا ہے اور وہ کمیونٹی کو حل دیتے ہیں - ایک دلچسپ معاملہ۔ میں سمجھتا ہوں کہ بڑی ٹیکنالوجی کمپنیوں میں، جہاں ان کی اپنی Kubernetes ڈویلپمنٹ اور سپورٹ ٹیم ہے، اصولی طور پر، وہی ٹولز تیار کیے جا سکتے ہیں۔ یہ ان کے لیے ایک مثال ہے کہ کمیونٹی کو کیا ترقی اور دی جا سکتی ہے، جس سے پوری کمیونٹی کو حوصلہ ملتا ہے جو Kubernetes استعمال کرتی ہے۔
دیمیتری: یہ شاید انٹیگریٹر کی ایک خصوصیت ہے، اس کی خاصیت۔ ہمارے پاس بہت سے منصوبے ہیں اور ہم بہت سے مختلف حالات دیکھتے ہیں۔ ہمارے لیے، اضافی قدر پیدا کرنے کا بنیادی طریقہ یہ ہے کہ ہم ان معاملات کا تجزیہ کریں، مشترکات تلاش کریں اور انہیں ہمارے لیے ہر ممکن حد تک سستا بنائیں۔ ہم اس پر سرگرمی سے کام کر رہے ہیں۔ میرے لیے روس اور دنیا کے بارے میں بات کرنا مشکل ہے، لیکن ہمارے پاس کمپنی میں تقریباً 40 DevOps انجینئرز ہیں جو Kubernetes پر کام کرتے ہیں۔ مجھے نہیں لگتا کہ روس میں ایسی بہت سی کمپنیاں ہیں جن کے ماہرین کی ایک نسبتاً تعداد ہے جو Kubernetes کو سمجھتے ہیں، اگر کوئی ہے تو۔
میں جاب ٹائٹل DevOps انجینئر کے بارے میں سب کچھ سمجھتا ہوں، ہر کوئی سب کچھ سمجھتا ہے اور DevOps انجینئرز کو DevOps انجینئر کہنے کا عادی ہے، ہم اس پر بات نہیں کریں گے۔ یہ تمام 40 حیرت انگیز DevOps انجینئرز ہر روز مسائل کا سامنا کرتے ہیں اور ان کو حل کرتے ہیں، ہم صرف اس تجربے کا تجزیہ کرتے ہیں اور عام کرنے کی کوشش کرتے ہیں۔ ہم سمجھتے ہیں کہ اگر یہ ہمارے اندر رہا تو ایک یا دو سال میں یہ آلہ بے کار ہو جائے گا، کیونکہ معاشرے میں کہیں نہ کہیں ایک ریڈی میڈ ٹولا نظر آئے گا۔ اس تجربے کو اندرونی طور پر جمع کرنے کا کوئی فائدہ نہیں ہے - یہ صرف توانائی اور وقت کو dev/null میں ضائع کر رہا ہے۔ اور ہمیں اس پر بالکل بھی افسوس نہیں ہوتا۔ ہم ہر چیز کو بہت خوشی کے ساتھ شائع کرتے ہیں اور سمجھتے ہیں کہ اسے شائع کرنے، تیار کرنے، فروغ دینے، فروغ دینے کی ضرورت ہے، تاکہ لوگ اسے استعمال کریں اور اپنے تجربے کو شامل کریں - پھر سب کچھ بڑھتا ہے اور زندہ رہتا ہے۔ پھر دو سال بعد یہ ساز ردی کی ٹوکری میں نہیں جاتا۔ طاقت میں اضافہ جاری رکھنا افسوسناک نہیں ہے، کیونکہ یہ واضح ہے کہ کوئی آپ کے آلے کو استعمال کر رہا ہے، اور دو سال کے بعد ہر کوئی اسے استعمال کر رہا ہے۔
یہ ڈیپ/ورف کے ساتھ ہماری بڑی حکمت عملی کا حصہ ہے۔. مجھے یاد نہیں کہ ہم نے اسے کب بنانا شروع کیا، ایسا لگتا ہے کہ 3 سال پہلے۔ ابتدائی طور پر، یہ عام طور پر شیل پر تھا. یہ تصور کا ایک بہترین ثبوت تھا، ہم نے اپنے کچھ خاص مسائل حل کیے - اس نے کام کیا! لیکن شیل کے ساتھ مسائل ہیں، اسے مزید پھیلانا ناممکن ہے، شیل پر پروگرامنگ ایک اور کام ہے۔ ہمیں روبی میں لکھنے کی عادت تھی، اس کے مطابق، ہم نے روبی میں کچھ دوبارہ بنایا، تیار کیا، ترقی کی، ترقی کی، اور اس حقیقت میں دوڑ پڑے کہ کمیونٹی، وہ ہجوم جو یہ نہیں کہتا کہ “ہمیں یہ چاہیے یا ہمیں یہ نہیں چاہیے، ” روبی کی طرف ناک اوپر کرتی ہے، یہ کتنا مضحکہ خیز ہے؟ ہم نے محسوس کیا کہ چیک لسٹ کے پہلے پوائنٹ کو پورا کرنے کے لیے ہمیں Go میں یہ ساری چیزیں لکھنی چاہئیں: DevOps ٹول ایک جامد بائنری ہونا چاہیے۔. گو ہونا یا نہ ہونا اتنا اہم نہیں ہے، لیکن گو میں لکھی ہوئی ایک جامد بائنری بہتر ہے۔
ہم نے اپنی توانائی صرف کی، گو میں ڈیپ کو دوبارہ لکھا اور اسے ورف کہا۔ ڈیپ اب مزید تعاون یافتہ نہیں ہے، تیار نہیں ہے، کچھ تازہ ترین ورژن میں چل رہا ہے، لیکن اوپر تک اپ گریڈ کرنے کا ایک مکمل راستہ ہے، اور آپ اس پر عمل کر سکتے ہیں۔
ڈیپ کیوں بنایا گیا؟
— کیا آپ ہمیں مختصراً بتا سکتے ہیں کہ ڈیپ کیوں بنایا گیا، اس سے کن مسائل حل ہوتے ہیں؟
دیمیتری: پہلی وجہ اسمبلی میں ہے۔ ابتدائی طور پر، ہمیں تعمیر کے ساتھ سنگین مسائل کا سامنا کرنا پڑا جب ڈوکر کے پاس ملٹی اسٹیج کی صلاحیتیں نہیں تھیں، اس لیے ہم نے خود ہی ملٹی اسٹیج بنایا۔ پھر ہمارے پاس امیج کو صاف کرنے میں بہت زیادہ مسائل تھے۔ ہر وہ شخص جو CI/CD کرتا ہے، اسے جلد از جلد اس مسئلے کا سامنا کرنا پڑتا ہے کہ جمع شدہ تصاویر کا ایک گروپ موجود ہے، آپ کو کسی نہ کسی طرح ان چیزوں کو صاف کرنے کی ضرورت ہے جس کی ضرورت نہیں ہے اور جو ضرورت ہے اسے چھوڑ دیں۔
دوسری وجہ تعیناتی ہے۔ ہاں، ہیلم ہے، لیکن یہ صرف کچھ مسائل کو حل کرتا ہے۔ مضحکہ خیز طور پر، یہ لکھا ہے کہ "Helm Kubernetes کے لیے پیکیج مینیجر ہے۔" بالکل کیا "دی"۔ "پیکیج مینیجر" کے الفاظ بھی ہیں - ایک پیکیج مینیجر سے معمول کی توقع کیا ہے؟ ہم کہتے ہیں: "پیکیج مینیجر - پیکج انسٹال کریں!" اور ہم توقع کرتے ہیں کہ وہ ہمیں بتائے گا: "پیکیج پہنچا دیا گیا ہے۔"
یہ دلچسپ ہے کہ ہم کہتے ہیں: "ہیلم، پیکج انسٹال کریں،" اور جب وہ جواب دیتا ہے کہ اس نے اسے انسٹال کیا ہے، تو پتہ چلتا ہے کہ اس نے ابھی انسٹالیشن شروع کی ہے - اس نے کبرنیٹس کو اشارہ کیا: "اس چیز کو لانچ کرو!"، اور آیا یہ شروع ہوا یا نہیں چاہے یہ کام کرے یا نہ کرے، ہیلم اس مسئلے کو بالکل حل نہیں کرتا۔
یہ پتہ چلتا ہے کہ ہیلم صرف ایک ٹیکسٹ پری پروسیسر ہے جو ڈیٹا کو کوبرنیٹس میں لوڈ کرتا ہے۔
لیکن کسی بھی تعیناتی کے حصے کے طور پر، ہم یہ جاننا چاہتے ہیں کہ کیا درخواست کو پروڈکشن کے لیے جاری کیا گیا ہے یا نہیں؟ پروڈ میں رول آؤٹ کا مطلب ہے کہ ایپلیکیشن وہاں منتقل ہو گئی ہے، نیا ورژن تعینات کر دیا گیا ہے، اور کم از کم یہ وہاں کریش نہیں ہوتا ہے اور صحیح جواب دیتا ہے۔ ہیلم اس مسئلے کو کسی بھی طرح حل نہیں کرتا۔ اسے حل کرنے کے لیے، آپ کو کافی محنت کرنے کی ضرورت ہے، کیونکہ آپ کو کوبرنیٹس کو رول آؤٹ کرنے اور وہاں کیا ہو رہا ہے اس کی نگرانی کرنے کی کمانڈ دینے کی ضرورت ہے - چاہے اسے تعینات کیا گیا ہو یا رول آؤٹ۔ اور تعیناتی، صفائی ستھرائی اور اسمبلی سے متعلق بہت سارے کام بھی ہیں۔
منصوبے
اس سال ہم مقامی ترقی کا آغاز کریں گے۔ ہم وہی حاصل کرنا چاہتے ہیں جو پہلے Vagrant میں تھا - ہم نے "vagrant up" ٹائپ کیا اور ہم نے ورچوئل مشینیں تعینات کیں۔ ہم اس مقام تک پہنچنا چاہتے ہیں جہاں گٹ میں ایک پروجیکٹ ہے، ہم وہاں "werf up" لکھتے ہیں، اور یہ اس پروجیکٹ کی ایک مقامی کاپی لاتا ہے، جو ایک مقامی منی Kub میں تعینات ہے، جس میں ترقی کے لیے آسان تمام ڈائریکٹریز منسلک ہیں۔ . ترقی کی زبان پر منحصر ہے، یہ مختلف طریقے سے کیا جاتا ہے، لیکن اس کے باوجود، تاکہ مقامی ترقی کو آسانی سے نصب فائلوں کے تحت انجام دیا جاسکے۔
ہمارے لیے اگلا مرحلہ ہے۔ ڈویلپرز کی سہولت میں سرمایہ کاری کریں۔. ایک ٹول کے ساتھ مقامی طور پر کسی پروجیکٹ کو تیزی سے تعینات کرنے کے لیے، اسے تیار کریں، اسے گٹ میں دھکیلیں، اور یہ پائپ لائنوں کے لحاظ سے اسٹیج یا ٹیسٹ کے لیے بھی رول آؤٹ کرے گا، اور پھر پروڈکشن میں جانے کے لیے اسی ٹول کا استعمال کریں۔ یہ اتحاد، یکجہتی، مقامی ماحول سے فروخت تک بنیادی ڈھانچے کی تولیدی صلاحیت ہمارے لیے بہت اہم نکتہ ہے۔ لیکن یہ ابھی تک کام میں نہیں ہے - ہم صرف اسے کرنے کی منصوبہ بندی کر رہے ہیں۔
لیکن dapp/werf کا راستہ ہمیشہ وہی رہا ہے جیسا کہ شروع میں Kubernetes کے ساتھ تھا۔ ہمیں مسائل کا سامنا کرنا پڑا، انہیں کام کے ساتھ حل کیا - ہم شیل پر، کسی بھی چیز پر اپنے لیے کچھ حل لے کر آئے۔ پھر انہوں نے کسی نہ کسی طرح ان کاموں کو سیدھا کرنے کی کوشش کی، اس معاملے میں انہیں بائنریز میں عام کرنے اور مضبوط کرنے کی کوشش کی، جسے ہم صرف بانٹتے ہیں۔
اس پوری کہانی کو تشبیہات کے ساتھ دیکھنے کا ایک اور طریقہ بھی ہے۔
Kubernetes ایک انجن کے ساتھ ایک کار فریم ہے. یہاں کوئی دروازے، شیشہ، ریڈیو، کرسمس ٹری نہیں - کچھ بھی نہیں۔ صرف فریم اور انجن۔ اور ہیلم ہے - یہ اسٹیئرنگ وہیل ہے۔ ٹھنڈا - ایک اسٹیئرنگ وہیل ہے، لیکن آپ کو اسٹیئرنگ پن، اسٹیئرنگ ریک، گیئر باکس اور پہیے کی بھی ضرورت ہے، اور آپ ان کے بغیر نہیں کر سکتے۔
werf کے معاملے میں، یہ Kubernetes کا ایک اور جزو ہے۔ صرف اب werf کے الفا ورژن میں، مثال کے طور پر، Helm کو werf کے اندر مرتب کیا گیا ہے، کیونکہ ہم اسے خود کرتے کرتے تھک چکے ہیں۔ ایسا کرنے کی بہت سی وجوہات ہیں، میں آپ کو اس بارے میں تفصیل سے بتاؤں گا کہ ہم نے پورے ہیلم کو ٹیلر کے اندر werf کے ساتھ کیوں مرتب کیا۔ .
اب werf ایک زیادہ مربوط جزو ہے۔ ہمیں ایک تیار شدہ اسٹیئرنگ وہیل، ایک اسٹیئرنگ پن ملتا ہے - میں کاروں میں بہت اچھا نہیں ہوں، لیکن یہ ایک بڑا بلاک ہے جو پہلے ہی کافی وسیع مسائل کو حل کرتا ہے۔ ہمیں خود کیٹلاگ سے گزرنے کی ضرورت نہیں ہے، ایک حصے کو دوسرے کے لیے منتخب کریں، اس بارے میں سوچیں کہ ان کو کیسے اکٹھا کیا جائے۔ ہمیں ایک ریڈی میڈ کمبائن ملتا ہے جو ایک ساتھ بہت سے مسائل حل کرتا ہے۔ لیکن اس کے اندر ایک ہی اوپن سورس اجزاء سے بنایا گیا ہے، یہ اب بھی اسمبلی کے لیے Docker، کچھ فعالیت کے لیے Helm، اور کئی دیگر لائبریریاں ہیں۔ یہ ٹھنڈا CI/CD باکس سے جلدی اور آسانی سے حاصل کرنے کا ایک مربوط ٹول ہے۔
کیا Kubernetes کو برقرار رکھنا مشکل ہے؟
— آپ اس تجربے کے بارے میں بات کرتے ہیں جو آپ نے Kubernetes استعمال کرنا شروع کیا ہے، یہ آپ کے لیے ایک فریم ہے، ایک انجن، اور یہ کہ آپ اس پر بہت سی مختلف چیزیں لٹکا سکتے ہیں: ایک باڈی، ایک اسٹیئرنگ وہیل، پیڈل پر اسکرو، سیٹیں۔ سوال پیدا ہوتا ہے - آپ کے لیے Kubernetes کی حمایت کتنی مشکل ہے؟ آپ کے پاس کافی تجربہ ہے، آپ کوبرنیٹس کو ہر چیز سے الگ تھلگ کرنے میں کتنا وقت اور وسائل صرف کرتے ہیں؟
دیمیتری: یہ ایک بہت مشکل سوال ہے اور اس کا جواب دینے کے لیے ہمیں یہ سمجھنا ہوگا کہ سپورٹ کیا ہے اور ہم Kubernetes سے کیا چاہتے ہیں۔ شاید آپ کو ظاہر کر سکتے ہیں؟
جہاں تک میں جانتا ہوں اور جیسا کہ میں دیکھ رہا ہوں، اب بہت سی ٹیمیں Kubernetes کو آزمانا چاہتی ہیں۔ ہر کوئی اپنے آپ کو اس کا استعمال کرتا ہے، اسے اپنے گھٹنوں پر رکھتا ہے. مجھے یہ احساس ہے کہ لوگ ہمیشہ اس نظام کی پیچیدگی کو نہیں سمجھتے۔
دیمیتری: ایسا ہی ہے۔
- کبرنیٹس کو شروع سے لینا اور انسٹال کرنا کتنا مشکل ہے تاکہ یہ پروڈکشن کے لیے تیار ہو؟
دیمیتری: آپ کے خیال میں دل کی پیوند کاری کرنا کتنا مشکل ہے؟ میں سمجھتا ہوں کہ یہ ایک سمجھوتہ کرنے والا سوال ہے۔ اسکیلپل کا استعمال کرنا اور غلطی نہ کرنا اتنا مشکل نہیں ہے۔ اگر وہ آپ کو بتاتے ہیں کہ کہاں کاٹنا ہے اور کہاں سلائی کرنا ہے، تو طریقہ کار خود پیچیدہ نہیں ہے۔ وقت کے بعد اس بات کی ضمانت دینا مشکل ہے کہ سب کچھ ٹھیک ہو جائے گا۔
Kubernetes کو انسٹال کرنا اور اسے کام پر لانا آسان ہے: لڑکی! - انسٹال ہوا، انسٹالیشن کے بہت سارے طریقے ہیں۔ لیکن جب مسائل پیدا ہوتے ہیں تو کیا ہوتا ہے؟
سوالات ہمیشہ اٹھتے ہیں - ہم نے ابھی تک کس چیز کو مدنظر نہیں رکھا؟ ہم نے ابھی تک کیا نہیں کیا؟ کون سے لینکس کرنل پیرامیٹرز کو غلط طریقے سے بیان کیا گیا تھا؟ رب، کیا ہم نے ان کا ذکر بھی کیا؟! کوبرنیٹس کے کون سے اجزاء ہم نے ڈیلیور کیے ہیں اور کون سے نہیں؟ ہزاروں سوال اٹھتے ہیں، اور ان کے جواب کے لیے آپ کو اس صنعت میں 15-20 سال گزارنے ہوں گے۔
میرے پاس اس موضوع پر ایک حالیہ مثال ہے جو اس مسئلے کے معنی کو ظاہر کر سکتی ہے "کیا Kubernetes کو برقرار رکھنا مشکل ہے؟" کچھ عرصہ پہلے ہم نے سنجیدگی سے غور کیا کہ آیا ہمیں کبرنیٹس میں ایک نیٹ ورک کے طور پر Cilium کو لاگو کرنے کی کوشش کرنی چاہیے۔
مجھے بتانے دو کہ Cilium کیا ہے؟ Kubernetes میں نیٹ ورکنگ سب سسٹم کے بہت سے مختلف نفاذ ہیں، اور ان میں سے ایک بہت اچھا ہے - Cilium. اس کا کیا مطلب ہے؟ دانا میں، کچھ عرصہ پہلے کرنل کے لیے ہکس لکھنا ممکن ہوا، جو کسی نہ کسی طریقے سے نیٹ ورک کے سب سسٹم اور دیگر مختلف سب سسٹمز پر حملہ آور ہوتے ہیں، اور آپ کو دانا میں بڑے ٹکڑوں کو نظرانداز کرنے کی اجازت دیتے ہیں۔
لینکس کرنل میں تاریخی طور پر ایک آئی پی روٹ، ایک اوور فلٹر، پل اور بہت سے مختلف پرانے اجزاء ہیں جو 15، 20، 30 سال پرانے ہیں۔ عام طور پر، وہ کام کرتے ہیں، سب کچھ بہت اچھا ہے، لیکن اب انہوں نے کنٹینرز کا ڈھیر لگا دیا ہے، اور یہ ایک دوسرے کے اوپر 15 اینٹوں کے ٹاور کی طرح لگتا ہے، اور آپ اس پر ایک ٹانگ پر کھڑے ہیں - ایک عجیب احساس. یہ نظام تاریخی طور پر بہت سی باریکیوں کے ساتھ تیار ہوا ہے، جیسے جسم میں اپینڈکس۔ کچھ حالات میں کارکردگی کے مسائل ہیں، مثال کے طور پر۔
ایک شاندار بی پی ایف اور دانا کے لیے ہکس لکھنے کی صلاحیت ہے - لڑکوں نے دانا کے لیے اپنے ہکس لکھے۔ پیکیج لینکس کے کرنل میں آتا ہے، وہ اسے ان پٹ پر ہی باہر لے جاتے ہیں، خود اس پر عمل کرتے ہیں جیسا کہ اسے بغیر پلوں کے، بغیر ٹی سی پی کے، بغیر آئی پی اسٹیک کے ہونا چاہیے - مختصراً، لینکس کرنل میں لکھی ہوئی ہر چیز کو نظرانداز کرتے ہوئے، اور پھر تھوک دیتے ہیں۔ اسے کنٹینر میں ڈالیں.
کیا ہوا؟ بہت عمدہ کارکردگی، ٹھنڈی خصوصیات - بالکل ٹھنڈا! لیکن ہم اس کو دیکھتے ہیں اور دیکھتے ہیں کہ ہر مشین پر ایک پروگرام ہوتا ہے جو Kubernetes API سے جڑتا ہے اور اس API سے حاصل ہونے والے ڈیٹا کی بنیاد پر C کوڈ تیار کرتا ہے اور بائنریز کو مرتب کرتا ہے جسے یہ کرنل میں لوڈ کرتا ہے تاکہ یہ ہکس کام کریں۔ دانا کی جگہ میں
اگر کچھ غلط ہو جائے تو کیا ہوتا ہے؟ ہم نہیں جانتے. اسے سمجھنے کے لیے، آپ کو یہ تمام کوڈ پڑھنا ہوگا، تمام منطق کو سمجھنا ہوگا، اور یہ حیرت انگیز ہے کہ یہ کتنا مشکل ہے۔ لیکن، دوسری طرف، یہ پل، نیٹ فلٹرز، آئی پی روٹ ہیں - میں نے ان کا سورس کوڈ نہیں پڑھا ہے، اور نہ ہی ہماری کمپنی میں کام کرنے والے 40 انجینئرز ہیں۔ ہو سکتا ہے صرف چند ہی کچھ حصوں کو سمجھتے ہوں۔
اور کیا فرق ہے؟ یہ پتہ چلتا ہے کہ آئی پی روٹ ہے، لینکس کرنل، اور ایک نیا ٹول ہے - اس سے کیا فرق پڑتا ہے، ہم ایک یا دوسرے کو نہیں سمجھتے۔ لیکن ہم کچھ نیا استعمال کرنے سے ڈرتے ہیں - کیوں؟ کیونکہ اگر ٹول 30 سال پرانا ہے، تو 30 سالوں میں تمام کیڑے مل گئے ہیں، تمام غلطیاں دور ہو چکی ہیں اور آپ کو ہر چیز کے بارے میں جاننے کی ضرورت نہیں ہے - یہ ایک بلیک باکس کی طرح کام کرتا ہے اور ہمیشہ کام کرتا ہے۔ ہر کوئی جانتا ہے کہ کون سا ڈائیگنوسٹک سکریو ڈرایور کس جگہ چپکنا ہے، کون سا tcpdump کس لمحے چلنا ہے۔ ہر کوئی تشخیصی افادیت کو اچھی طرح جانتا ہے اور یہ سمجھتا ہے کہ اجزاء کا یہ سیٹ لینکس کرنل میں کیسے کام کرتا ہے - یہ نہیں کہ یہ کیسے کام کرتا ہے، بلکہ اسے کیسے استعمال کیا جائے۔
اور حیرت انگیز طور پر ٹھنڈا Cilium 30 سال کا نہیں ہے، یہ ابھی بوڑھا نہیں ہوا ہے۔ Kubernetes ایک ہی مسئلہ ہے، کاپی. وہ Cilium بالکل انسٹال ہے، کہ Kubernetes بالکل انسٹال ہے، لیکن جب پیداوار میں کچھ غلط ہو جاتا ہے، تو کیا آپ ایک نازک صورتحال میں جلدی سمجھ سکتے ہیں کہ کیا غلط ہوا؟
جب ہم کہتے ہیں کہ کیا کوبرنیٹس کو برقرار رکھنا مشکل ہے - نہیں، یہ بہت آسان ہے، اور ہاں، یہ ناقابل یقین حد تک مشکل ہے۔ Kubernetes اپنے طور پر بہت اچھا کام کرتا ہے، لیکن ایک ارب باریکیوں کے ساتھ۔
"میں خوش قسمت رہوں گا" کے نقطہ نظر کے بارے میں
- کیا ایسی کمپنیاں ہیں جہاں ان باریکیوں کے ظاہر ہونے کی تقریباً ضمانت ہے؟ فرض کریں کہ Yandex اچانک تمام خدمات Kubernetes کو منتقل کر دیتا ہے، وہاں بہت زیادہ بوجھ پڑے گا۔
دیمیتری: نہیں، یہ بوجھ کے بارے میں بات چیت نہیں ہے، بلکہ آسان ترین چیزوں کے بارے میں ہے۔ مثال کے طور پر، ہمارے پاس Kubernetes ہے، ہم نے وہاں ایپلیکیشن کو تعینات کیا۔ آپ کیسے جانتے ہیں کہ یہ کام کر رہا ہے؟ یہ سمجھنے کے لیے کوئی ریڈی میڈ ٹول نہیں ہے کہ ایپلیکیشن کریش نہیں ہو رہی ہے۔ انتباہات بھیجنے والا کوئی ریڈی میڈ سسٹم نہیں ہے؛ آپ کو ان الرٹس اور ہر شیڈول کو ترتیب دینے کی ضرورت ہے۔ اور ہم Kubernetes کو اپ ڈیٹ کر رہے ہیں۔
میرے پاس اوبنٹو 16.04 ہے۔ آپ کہہ سکتے ہیں کہ یہ پرانا ورژن ہے، لیکن ہم اب بھی اس پر ہیں کیونکہ یہ LTS ہے۔ سسٹمڈ ہے، جس کی اہمیت یہ ہے کہ یہ سی گروپس کو صاف نہیں کرتا ہے۔ Kubernetes پوڈز لانچ کرتا ہے، سی گروپ بناتا ہے، پھر پوڈز کو ڈیلیٹ کرتا ہے، اور کسی نہ کسی طرح یہ پتہ چلتا ہے - مجھے تفصیلات یاد نہیں ہیں، معذرت - وہ سسٹمڈ سلائسز باقی ہیں۔ یہ اس حقیقت کی طرف جاتا ہے کہ وقت گزرنے کے ساتھ، کسی بھی گاڑی کو سختی سے سست کرنا شروع ہوتا ہے. یہ ہائی لوڈ کے بارے میں بھی سوال نہیں ہے۔ اگر مستقل پوڈز لانچ کیے جاتے ہیں، مثال کے طور پر، اگر کوئی کرون جاب ہے جو مسلسل پوڈز تیار کرتا ہے، تو اوبنٹو 16.04 والی مشین ایک ہفتے کے بعد سست ہونا شروع کر دے گی۔ اس حقیقت کی وجہ سے کہ سی گروپس کا ایک گروپ بنا دیا گیا ہے اس کی وجہ سے لوڈ کی اوسط مسلسل زیادہ ہوگی۔ یہ وہ مسئلہ ہے جس کا سامنا کوئی بھی شخص جو صرف Ubuntu 16 اور Kubernetes کو سب سے اوپر انسٹال کرتا ہے۔
ہم کہتے ہیں کہ وہ کسی نہ کسی طرح سسٹمڈ یا کچھ اور اپ ڈیٹ کرتا ہے، لیکن لینکس کے کرنل میں 4.16 تک یہ اور بھی مضحکہ خیز ہے - جب آپ سی گروپس کو حذف کرتے ہیں، تو وہ کرنل میں لیک ہو جاتے ہیں اور حقیقت میں حذف نہیں ہوتے ہیں۔ اس لیے اس مشین پر ایک ماہ کام کرنے کے بعد چولہے کی یادداشت کے اعدادوشمار کو دیکھنا ناممکن ہو جائے گا۔ ہم ایک فائل نکالتے ہیں، اسے پروگرام میں رول کرتے ہیں، اور ایک فائل 15 سیکنڈ کے لیے رول کرتی ہے، کیونکہ کرنل اپنے اندر موجود دس لاکھ سی گروپس کو گننے میں بہت زیادہ وقت لیتا ہے، جو بظاہر حذف ہو چکے ہیں، لیکن نہیں - وہ لیک ہو رہے ہیں۔ .
ایسی بہت سی چھوٹی چھوٹی چیزیں اب بھی یہاں اور وہاں موجود ہیں۔ یہ کوئی ایسا مسئلہ نہیں ہے جس کا سامنا بڑی کمپنیوں کو کبھی کبھی بہت زیادہ بوجھ کے نیچے کرنا پڑ سکتا ہے - نہیں، یہ روزمرہ کا معاملہ ہے۔ لوگ مہینوں تک اس طرح زندہ رہ سکتے ہیں - انہوں نے Kubernetes انسٹال کیا، ایپلی کیشن کو تعینات کیا - ایسا لگتا ہے کہ یہ کام کرتا ہے۔ بہت سے لوگوں کے لیے یہ معمول ہے۔ انہیں یہ بھی معلوم نہیں ہوگا کہ یہ ایپلیکیشن کسی وجہ سے کریش ہو جائے گی، انہیں کوئی الرٹ نہیں ملے گا، لیکن ان کے لیے یہ معمول ہے۔ پہلے، ہم بغیر نگرانی کے ورچوئل مشینوں پر رہتے تھے، اب ہم Kubernetes میں چلے گئے، وہ بھی بغیر نگرانی کے - کیا فرق ہے؟
سوال یہ ہے کہ جب ہم برف پر چلتے ہیں تو ہمیں اس کی موٹائی کا کبھی پتہ نہیں چلتا جب تک کہ ہم اسے پہلے سے ناپ لیں۔ بہت سے لوگ چلتے ہیں اور فکر نہ کریں، کیونکہ وہ پہلے بھی چل چکے ہیں۔
میرے نقطہ نظر سے، کسی بھی نظام کو چلانے کی نزاکت اور پیچیدگی اس بات کو یقینی بنانا ہے کہ برف کی موٹائی ہمارے مسائل کو حل کرنے کے لیے بالکل کافی ہے۔ یہ وہی ہے جس کے بارے میں ہم بات کر رہے ہیں۔
IT میں، مجھے ایسا لگتا ہے، "میں خوش قسمت ہوں گا" کے بہت سارے طریقے ہیں۔ بہت سے لوگ سافٹ ویئر انسٹال کرتے ہیں اور سافٹ ویئر لائبریریوں کو اس امید پر استعمال کرتے ہیں کہ وہ خوش قسمت ہوں گے۔ عام طور پر، بہت سے لوگ خوش قسمت ہیں. شاید یہی وجہ ہے کہ یہ کام کرتا ہے۔
— میری مایوسی کی تشخیص سے، یہ اس طرح لگتا ہے: جب خطرات زیادہ ہوں، اور درخواست کو کام کرنا چاہیے، تو Flaunt سے، شاید Red Hat سے مدد کی ضرورت ہے، یا آپ کو اپنی اندرونی ٹیم کی ضرورت ہے جو خاص طور پر Kubernetes کے لیے وقف ہے، جو تیار ہے۔ اسے کھینچنے کے لیے۔
دیمیتری: معروضی طور پر، ایسا ہی ہے۔ اپنے طور پر ایک چھوٹی ٹیم کے لیے Kubernetes کی کہانی میں داخل ہونے میں بہت سے خطرات شامل ہیں۔
کیا ہمیں کنٹینرز کی ضرورت ہے؟
— کیا آپ ہمیں بتا سکتے ہیں کہ روس میں کبرنیٹس کس حد تک پھیلے ہوئے ہیں؟
دیمیتری: میرے پاس یہ ڈیٹا نہیں ہے، اور مجھے یقین نہیں ہے کہ یہ کسی اور کے پاس ہے۔ ہم کہتے ہیں: "Kubernetes، Kubernetes،" لیکن اس مسئلے کو دیکھنے کا ایک اور طریقہ ہے۔ میں یہ بھی نہیں جانتا کہ کنٹینرز کتنے وسیع ہیں، لیکن میں انٹرنیٹ پر آنے والی رپورٹوں سے ایک اعداد و شمار جانتا ہوں کہ 70% کنٹینرز کوبرنیٹس کے ذریعے ترتیب دیے گئے ہیں۔ یہ دنیا بھر میں کافی بڑے نمونے کے لیے ایک قابل اعتماد ذریعہ تھا۔
پھر ایک اور سوال - کیا ہمیں کنٹینرز کی ضرورت ہے؟ میرا ذاتی احساس اور فلانٹ کمپنی کی مجموعی پوزیشن یہ ہے کہ Kubernetes ایک حقیقی معیار ہے۔
کوبرنیٹس کے علاوہ کچھ نہیں ہوگا۔
یہ بنیادی ڈھانچے کے انتظام کے میدان میں ایک مکمل گیم چینجر ہے۔ بس مطلق - بس، اب کوئی جوابدہ نہیں، شیف، ورچوئل مشینیں، ٹیرافارم۔ میں پرانے اجتماعی فارم کے طریقوں کے بارے میں بات نہیں کر رہا ہوں۔ Kubernetes ایک مطلق تبدیلی ہے۔، اور اب یہ صرف اس طرح ہوگا۔
یہ واضح ہے کہ کچھ لوگوں کے لیے اس کا ادراک کرنے میں چند سال اور دوسروں کے لیے چند دہائیاں لگتی ہیں۔ مجھے اس میں کوئی شک نہیں ہے کہ کوبرنیٹس اور اس نئی شکل کے علاوہ کچھ نہیں ہوگا: ہم آپریٹنگ سسٹم کو مزید نقصان نہیں پہنچاتے، بلکہ استعمال کرتے ہیں۔ بنیادی ڈھانچہ بطور کوڈ، صرف کوڈ کے ساتھ نہیں، بلکہ yml کے ساتھ - ایک واضح طور پر بیان کردہ بنیادی ڈھانچہ۔ مجھے احساس ہے کہ یہ ہمیشہ ایسا ہی رہے گا۔
— یعنی، وہ کمپنیاں جنہوں نے ابھی تک Kubernetes میں تبدیل نہیں کیا ہے وہ یقینی طور پر اس کی طرف جائیں گی یا بھول جائیں گی۔ میں نے آپ کو صحیح سمجھا؟
دیمیتری: یہ بھی مکمل طور پر درست نہیں ہے۔ مثال کے طور پر، اگر ہمارے پاس DNS سرور چلانے کا کام ہے، تو اسے FreeBSD 4.10 پر چلایا جا سکتا ہے اور یہ 20 سال تک بالکل کام کر سکتا ہے۔ بس کام کرو اور بس۔ شاید 20 سالوں میں کسی چیز کو ایک بار اپ ڈیٹ کرنے کی ضرورت ہوگی۔ اگر ہم اس فارمیٹ میں سافٹ ویئر کے بارے میں بات کر رہے ہیں جسے ہم نے لانچ کیا ہے اور یہ حقیقت میں کئی سالوں تک بغیر کسی اپ ڈیٹ کے، تبدیلیاں کیے بغیر کام کرتا ہے، تو یقیناً کوئی کوبرنیٹس نہیں ہوگا۔ اس کی وہاں ضرورت نہیں ہے۔
CI/CD سے متعلق ہر چیز - جہاں بھی مسلسل ڈیلیوری کی ضرورت ہو، جہاں آپ کو ورژن کو اپ ڈیٹ کرنے کی ضرورت ہو، فعال تبدیلیاں کرنے کی ضرورت ہو، جہاں بھی آپ کو غلطی برداشت کرنے کی ضرورت ہو - صرف Kubernetes۔
مائیکرو سروسز کے بارے میں
- یہاں مجھے تھوڑا سا اختلاف ہے۔ Kubernetes کے ساتھ کام کرنے کے لیے، آپ کو بیرونی یا اندرونی مدد کی ضرورت ہے - یہ پہلا نکتہ ہے۔ دوم، جب ہم ابھی ترقی شروع کر رہے ہیں، ہم ایک چھوٹا سا آغاز ہیں، ہمارے پاس ابھی تک کچھ نہیں ہے، عام طور پر Kubernetes یا مائیکرو سروس فن تعمیر کے لیے ترقی پیچیدہ ہو سکتی ہے اور ہمیشہ معاشی طور پر جائز نہیں ہوتی۔ میں آپ کی رائے میں دلچسپی رکھتا ہوں - کیا اسٹارٹ اپس کو فوری طور پر شروع سے ہی Kubernetes کے لیے لکھنا شروع کرنے کی ضرورت ہے، یا کیا وہ اب بھی ایک یک سنگی لکھ سکتے ہیں، اور پھر صرف Kubernetes پر آتے ہیں؟
دیمیتری: ٹھنڈا سوال۔ مائیکرو سروسز کے بارے میں میری بات ہے۔ کئی بار میں نے ایسے لوگوں کا سامنا کیا ہے جو ایک خوردبین سے ناخن مارنے کی کوشش کر رہے ہیں۔ نقطہ نظر خود درست ہے؛ ہم خود اپنے اندرونی سافٹ ویئر کو اس طرح ڈیزائن کرتے ہیں۔ لیکن جب آپ ایسا کرتے ہیں، تو آپ کو واضح طور پر سمجھنا ہوگا کہ آپ کیا کر رہے ہیں۔ مائیکرو سروسز کے بارے میں جس لفظ سے مجھے سب سے زیادہ نفرت ہے وہ ہے "مائیکرو۔" تاریخی طور پر، یہ لفظ وہیں پیدا ہوا، اور کچھ وجوہات کی بنا پر لوگوں کا خیال ہے کہ مائیکرو بہت چھوٹا ہے، ایک ملی میٹر سے بھی کم، مائیکرو میٹر کی طرح۔ یہ غلط ہے.
مثال کے طور پر، ایک یک سنگی ہے جسے 300 لوگوں نے لکھا ہے، اور ہر ایک جس نے ترقی میں حصہ لیا ہے وہ سمجھتا ہے کہ وہاں مسائل ہیں، اور اسے مائیکرو ٹکڑوں میں تقسیم کیا جانا چاہیے - تقریباً 10 ٹکڑوں، جن میں سے ہر ایک 30 لوگوں نے لکھا ہے۔ کم از کم ورژن میں۔ یہ ضروری، ضروری اور ٹھنڈا ہے۔ لیکن جب ایک سٹارٹ اپ ہمارے پاس آتا ہے، جہاں 3 بہت اچھے اور باصلاحیت لڑکوں نے اپنے گھٹنوں پر 60 مائیکرو سروسز لکھی ہیں، جب بھی میں Corvalol کو تلاش کرتا ہوں۔
مجھے ایسا لگتا ہے کہ اس کے بارے میں پہلے ہی ہزاروں بار بات کی جا چکی ہے - ہمیں کسی نہ کسی شکل میں تقسیم شدہ یک سنگی ملا۔ یہ اقتصادی طور پر جائز نہیں ہے، یہ عام طور پر ہر چیز میں بہت مشکل ہے. میں نے اسے ابھی کئی بار دیکھا ہے کہ یہ واقعی مجھے تکلیف دیتا ہے، لہذا میں اس کے بارے میں بات کرنا جاری رکھتا ہوں۔
ابتدائی سوال میں، اس حقیقت کے درمیان تنازعہ ہے کہ، ایک طرف، Kubernetes استعمال کرنے میں خوفناک ہے، کیونکہ یہ واضح نہیں ہے کہ وہاں کیا ٹوٹ سکتا ہے یا کام نہیں کرے گا، دوسری طرف، یہ واضح ہے کہ سب کچھ وہاں جاتا ہے۔ اور کوبرنیٹس کے علاوہ کچھ بھی موجود نہیں ہوگا۔ جواب - حاصل ہونے والے فائدے کی مقدار، کاموں کی مقدار جو آپ حل کر سکتے ہیں۔. یہ پیمانے کے ایک طرف ہے۔ دوسری طرف، ڈاون ٹائم یا رسپانس ٹائم میں کمی، دستیابی کی سطح - کارکردگی کے اشاریوں میں کمی کے ساتھ منسلک خطرات ہیں۔
یہاں یہ ہے - یا تو ہم تیزی سے حرکت کرتے ہیں، اور Kubernetes ہمیں بہت سی چیزیں بہت تیز اور بہتر کرنے کی اجازت دیتا ہے، یا ہم قابل اعتماد، وقت کے مطابق حل استعمال کرتے ہیں، لیکن بہت زیادہ آہستہ حرکت کرتے ہیں۔ یہ ایک انتخاب ہے جو ہر کمپنی کو کرنا چاہئے۔ آپ اسے جنگل کے راستے کے طور پر سوچ سکتے ہیں - جب آپ پہلی بار چلتے ہیں، تو آپ سانپ، شیر یا پاگل بیجر سے مل سکتے ہیں، اور جب آپ 10 بار چل چکے ہیں، تو آپ راستے کو روند چکے ہیں، ہٹا دیا گیا ہے۔ شاخیں اور آسانی سے چلنا. ہر بار راستہ وسیع ہوتا جاتا ہے۔ پھر یہ ایک اسفالٹ سڑک ہے، اور بعد میں ایک خوبصورت بلیوارڈ ہے۔
Kubernetes خاموش نہیں کھڑا ہے. ایک بار پھر سوال: کبرنیٹس، ایک طرف، 4-5 بائنریز ہے، دوسری طرف، یہ پورا ماحولیاتی نظام ہے۔ یہ وہ آپریٹنگ سسٹم ہے جو ہمارے پاس ہماری مشینوں پر ہے۔ یہ کیا ہے؟ Ubuntu یا Curios؟ یہ لینکس کرنل ہے، اضافی اجزاء کا ایک گروپ۔ یہ سب چیزیں یہاں ایک زہریلے سانپ کو سڑک سے باہر پھینک دیا گیا، وہاں باڑ لگائی گئی۔ Kubernetes بہت تیزی سے اور متحرک طور پر ترقی کر رہا ہے، اور خطرات کا حجم، نامعلوم کا حجم ہر ماہ کم ہو رہا ہے اور، اس کے مطابق، یہ ترازو دوبارہ متوازن ہو رہے ہیں۔
اس سوال کا جواب دیتے ہوئے کہ اسٹارٹ اپ کو کیا کرنا چاہیے، میں کہوں گا - فلاؤنٹ پر آئیں، 150 ہزار روبل ادا کریں اور ٹرنکی ڈی او اوپس کی آسان سروس حاصل کریں۔ اگر آپ چند ڈویلپرز کے ساتھ ایک چھوٹا اسٹارٹ اپ ہیں، تو یہ کام کرتا ہے۔ اپنے DevOps کی خدمات حاصل کرنے کے بجائے، جنہیں آپ کے مسائل کو حل کرنے اور اس وقت تنخواہ ادا کرنے کا طریقہ سیکھنے کی ضرورت ہوگی، آپ کو تمام مسائل کا ٹرنکی حل ملے گا۔ ہاں، کچھ نقصانات ہیں۔ ہم، ایک آؤٹ سورس کے طور پر، اس میں شامل نہیں ہو سکتے اور تبدیلیوں کا فوری جواب نہیں دے سکتے۔ لیکن ہمارے پاس بہت زیادہ مہارت اور تیار شدہ مشقیں ہیں۔ ہم اس بات کی ضمانت دیتے ہیں کہ کسی بھی صورت حال میں ہم یقینی طور پر اس کا جلد پتہ لگائیں گے اور کسی بھی Kubernetes کو مردوں میں سے زندہ کر دیں گے۔
میں اسٹارٹ اپس اور قائم کردہ کاروباروں کو آؤٹ سورس کرنے کی پرزور سفارش کرتا ہوں جہاں آپ 10 افراد کی ٹیم کو آپریشنز کے لیے وقف کر سکتے ہیں، کیونکہ بصورت دیگر کوئی فائدہ نہیں ہے۔ اس کو آؤٹ سورس کرنا یقینی طور پر سمجھ میں آتا ہے۔
ایمیزون اور گوگل کے بارے میں
- کیا ایمیزون یا گوگل کے حل سے کسی میزبان کو آؤٹ سورس سمجھا جا سکتا ہے؟
دیمیتری: ہاں، یقیناً، اس سے کئی مسائل حل ہو جاتے ہیں۔ لیکن پھر باریکیاں ہیں۔ آپ کو ابھی بھی اسے استعمال کرنے کا طریقہ سمجھنے کی ضرورت ہے۔ مثال کے طور پر، Amazon AWS کے کام میں ایک ہزار چھوٹی چیزیں ہیں: لوڈ بیلنسر کو گرم کرنے کی ضرورت ہے یا ایک درخواست پہلے سے لکھی جانی چاہیے کہ "یار، ہمیں ٹریفک ملے گا، ہمارے لیے لوڈ بیلنسر کو گرم کریں!" آپ کو ان باریکیوں کو جاننے کی ضرورت ہے۔
جب آپ ان لوگوں سے رجوع کرتے ہیں جو اس میں مہارت رکھتے ہیں، تو آپ کو تقریباً تمام عام چیزیں بند ہو جاتی ہیں۔ اب ہمارے پاس 40 انجینئرز ہیں، سال کے آخر تک شاید 60 ہو جائیں گے - ہمیں ان تمام چیزوں کا سامنا ضرور ہوا ہے۔ یہاں تک کہ اگر ہمیں کسی پروجیکٹ پر دوبارہ اس مسئلے کا سامنا کرنا پڑتا ہے، تو ہم جلدی سے ایک دوسرے سے پوچھتے ہیں اور اسے حل کرنے کا طریقہ جانتے ہیں۔
شاید اس کا جواب ہے - یقینا، ایک میزبان کہانی کچھ حصہ آسان بناتی ہے۔ سوال یہ ہے کہ کیا آپ ان میزبانوں پر بھروسہ کرنے کے لیے تیار ہیں اور کیا وہ آپ کے مسائل حل کریں گے۔ ایمیزون اور گوگل نے اچھا کام کیا ہے۔ ہمارے تمام معاملات کے لیے - بالکل۔ ہمارے پاس مزید کوئی مثبت تجربہ نہیں ہے۔ دوسرے تمام بادل جن کے ساتھ ہم نے کام کرنے کی کوشش کی وہ بہت سارے مسائل پیدا کرتے ہیں - Ager، اور ہر وہ چیز جو روس میں ہے، اور ہر طرح کے OpenStack مختلف نفاذ میں: Headster، Overage - جو بھی آپ چاہتے ہیں۔ یہ سب ایسے مسائل پیدا کرتے ہیں جنہیں آپ حل نہیں کرنا چاہتے۔
لہذا، جواب ہاں میں ہے، لیکن، حقیقت میں، بہت زیادہ بالغ میزبان حل نہیں ہیں.
کس کو کبرنیٹس کی ضرورت ہے؟
- اور پھر بھی، کس کو کبرنیٹس کی ضرورت ہے؟ کس کو پہلے سے ہی Kubernetes میں تبدیل ہونا چاہئے، کون عام فلاونٹ کلائنٹ ہے جو خاص طور پر Kubernetes کے لیے آتا ہے؟
دیمیتری: یہ ایک دلچسپ سوال ہے، کیونکہ ابھی، کبرنیٹس کے تناظر میں، بہت سے لوگ ہمارے پاس آتے ہیں: "دوستوں، ہم جانتے ہیں کہ آپ کبرنیٹس کر رہے ہیں، یہ ہمارے لیے کریں!" ہم انہیں جواب دیتے ہیں: "حضرات، ہم کوبرنیٹس نہیں کرتے، ہم پروڈکشن اور اس سے جڑی ہر چیز کرتے ہیں۔" کیونکہ فی الحال تمام CI/CD اور اس پوری کہانی کے بغیر پروڈکٹ بنانا ناممکن ہے۔ ہر کوئی اس تقسیم سے دور ہو گیا ہے کہ ہمارے ہاں ترقی سے ترقی ہے اور پھر استحصال سے استحصال۔
ہمارے مؤکل مختلف چیزوں کی توقع کرتے ہیں، لیکن ہر کوئی کسی اچھے معجزے کا انتظار کر رہا ہے کہ انہیں کچھ مسائل ہیں، اور اب - ہاپ! - کبرنیٹس ان کو حل کریں گے۔ لوگ معجزات پر یقین رکھتے ہیں۔ ان کے دماغ میں وہ سمجھتے ہیں کہ کوئی معجزہ نہیں ہوگا، لیکن ان کی روحوں میں وہ امید رکھتے ہیں - کیا ہوگا اگر یہ کبرنیٹ اب ہمارے لئے سب کچھ حل کردے گا، وہ اس کے بارے میں اتنی باتیں کرتے ہیں! اچانک وہ اب - چھینک! - اور ایک چاندی کی گولی، چھینک! - اور ہمارے پاس 100% اپ ٹائم ہے، تمام ڈویلپرز جو کچھ بھی پروڈکشن میں آتا ہے اسے 50 بار جاری کر سکتے ہیں، اور یہ کریش نہیں ہوتا ہے۔ عام طور پر، ایک معجزہ!
جب ایسے لوگ ہمارے پاس آتے ہیں تو ہم کہتے ہیں: "معذرت، لیکن معجزہ نام کی کوئی چیز نہیں ہے۔" صحت مند رہنے کے لیے آپ کو اچھی غذا اور ورزش کرنے کی ضرورت ہے۔ قابل اعتماد پروڈکٹ حاصل کرنے کے لیے اسے قابل اعتماد طریقے سے بنانے کی ضرورت ہے۔ ایک آسان CI/CD رکھنے کے لیے، آپ کو اسے اس طرح بنانا ہوگا۔ یہ بہت کام ہے جو کرنے کی ضرورت ہے۔
اس سوال کا جواب دیتے ہوئے کہ کس کو کبرنیٹس کی ضرورت ہے - کسی کو بھی کوبرنیٹس کی ضرورت نہیں ہے۔
کچھ لوگوں کو یہ غلط فہمی ہے کہ انہیں Kubernetes کی ضرورت ہے۔ لوگوں کو ضرورت ہے، انہیں سوچنے، مطالعہ کرنے، اور بنیادی ڈھانچے کے تمام مسائل اور ان کی ایپلی کیشنز کو چلانے کے مسائل میں دلچسپی لینے کو روکنے کی شدید ضرورت ہے۔ وہ چاہتے ہیں کہ ایپلی کیشنز صرف کام کریں اور صرف تعینات کریں۔ ان کے لیے، Kubernetes امید ہے کہ وہ یہ کہانی سننا بند کر دیں گے کہ "ہم وہاں پڑے تھے،" یا "ہم رول آؤٹ نہیں کر سکتے،" یا کچھ اور۔
ٹیکنیکل ڈائریکٹر عام طور پر ہمارے پاس آتا ہے۔ وہ اس سے دو چیزیں پوچھتے ہیں: ایک طرف، ہمیں خصوصیات دیں، دوسری طرف، استحکام۔ ہمارا مشورہ ہے کہ آپ اسے اپنے اوپر لے لیں اور اسے کریں۔ چاندی کی گولی، یا چاندی کی چڑھائی، یہ ہے کہ آپ ان مسائل کے بارے میں سوچنا اور وقت ضائع کرنا چھوڑ دیں گے۔ آپ کے پاس خاص لوگ ہوں گے جو اس مسئلے کو بند کر دیں گے۔
یہ الفاظ کہ ہمیں یا کسی اور کو Kubernetes کی ضرورت ہے غلط ہے۔
منتظمین کو واقعی Kubernetes کی ضرورت ہے، کیونکہ یہ ایک بہت ہی دلچسپ کھلونا ہے جس کے ساتھ آپ کھیل سکتے ہیں اور ٹنکر بھی سکتے ہیں۔ آئیے ایماندار بنیں - ہر کوئی کھلونے سے محبت کرتا ہے۔ ہم سب کہیں کے بچے ہیں، اور جب ہم کوئی نیا دیکھتے ہیں، تو ہم اسے کھیلنا چاہتے ہیں۔ کچھ لوگوں کے لیے، اس کی حوصلہ شکنی کی گئی ہے، مثال کے طور پر، انتظامیہ میں، کیونکہ وہ پہلے ہی کافی کھیل چکے ہیں اور پہلے ہی اس حد تک تھک چکے ہیں کہ وہ بس نہیں کرنا چاہتے۔ لیکن یہ مکمل طور پر کسی سے محروم نہیں ہے۔ مثال کے طور پر، اگر میں کافی عرصے سے سسٹم ایڈمنسٹریشن اور DevOps کے میدان میں کھلونوں سے تنگ ہوں، تب بھی مجھے کھلونے پسند ہیں، میں اب بھی کچھ نئے خریدتا ہوں۔ تمام لوگ، کسی نہ کسی طرح، اب بھی کسی نہ کسی قسم کے کھلونے چاہتے ہیں۔
پیداوار کے ساتھ کھیلنے کی ضرورت نہیں ہے۔ جو کچھ بھی میں واضح طور پر نہ کرنے کی سفارش کرتا ہوں اور جو میں اب بڑے پیمانے پر دیکھ رہا ہوں: "اوہ، ایک نیا کھلونا!" - وہ اسے خریدنے کے لیے بھاگے، اسے خرید لیا اور: "آئیے اسے ابھی اسکول لے جائیں اور اپنے تمام دوستوں کو دکھائیں۔" ایسا مت کرو۔ میں معذرت خواہ ہوں، میرے بچے ابھی بڑے ہو رہے ہیں، میں بچوں میں مسلسل کچھ دیکھتا ہوں، اسے اپنے اندر محسوس کرتا ہوں، اور پھر اسے دوسروں کے لیے عام کرتا ہوں۔
حتمی جواب ہے: آپ کو کوبرنیٹس کی ضرورت نہیں ہے۔ آپ کو اپنے مسائل حل کرنے کی ضرورت ہے۔
آپ کیا حاصل کر سکتے ہیں:
- پیداوار نہیں گرتی ہے۔
- یہاں تک کہ اگر وہ گرنے کی کوشش کرتا ہے، ہم اس کے بارے میں پہلے سے جانتے ہیں، اور ہم اس میں کچھ ڈال سکتے ہیں؛
- ہم اسے اس رفتار سے تبدیل کر سکتے ہیں جس سے ہمارے کاروبار کو اس کی ضرورت ہوتی ہے، اور ہم اسے آسانی سے کر سکتے ہیں؛ اس سے ہمیں کوئی پریشانی نہیں ہوتی۔
دو حقیقی ضروریات ہیں: وشوسنییتا اور متحرکیت/رول آؤٹ کی لچک۔ ہر وہ شخص جو اس وقت کسی نہ کسی قسم کے آئی ٹی پروجیکٹس کر رہا ہے، چاہے وہ کس قسم کے کاروبار میں ہو - دنیا کو آسان بنانے کے لیے نرم، اور جو اس بات کو سمجھتا ہے، اسے ان ضروریات کو حل کرنے کی ضرورت ہے۔ Kubernetes صحیح نقطہ نظر کے ساتھ، صحیح سمجھ بوجھ کے ساتھ اور کافی تجربے کے ساتھ آپ کو ان کو حل کرنے کی اجازت دیتا ہے۔
سرور لیس کے بارے میں
- اگر آپ مستقبل میں تھوڑا سا آگے دیکھیں، تو بنیادی ڈھانچے کے ساتھ سر درد کی عدم موجودگی کے مسئلے کو حل کرنے کی کوشش کریں، رول آؤٹ کی رفتار اور ایپلی کیشن کی تبدیلیوں کی رفتار کے ساتھ، نئے حل نظر آتے ہیں، مثال کے طور پر، سرور کے بغیر۔ کیا آپ اس سمت میں کوئی امکان محسوس کرتے ہیں اور، آئیے کہتے ہیں، Kubernetes اور اسی طرح کے حل کے لیے خطرہ ہے؟
دیمیتری: یہاں ہمیں ایک بار پھر یہ تبصرہ کرنے کی ضرورت ہے کہ میں کوئی دیکھنے والا نہیں ہوں جو آگے دیکھ کر کہے - ایسا ہی ہوگا! اگرچہ میں نے صرف ایک ہی کام کیا۔ میں اپنے پیروں کو دیکھتا ہوں اور وہاں مسائل کا ایک گروپ دیکھتا ہوں، مثال کے طور پر، کمپیوٹر میں ٹرانسسٹر کیسے کام کرتے ہیں۔ یہ مضحکہ خیز ہے، ٹھیک ہے؟ ہم سی پی یو میں کچھ کیڑے کا سامنا کر رہے ہیں۔
ایکو سسٹم کے تمام مسائل کو حل کرتے ہوئے سرور لیس کو کافی قابل اعتماد، سستا، موثر اور آسان بنائیں۔ یہاں میں ایلون مسک سے اتفاق کرتا ہوں کہ انسانیت کے لیے غلطی برداشت کرنے کے لیے دوسرے سیارے کی ضرورت ہے۔ اگرچہ میں نہیں جانتا کہ وہ کیا کہہ رہا ہے، لیکن میں سمجھتا ہوں کہ میں خود مریخ پر جانے کے لیے تیار نہیں ہوں اور یہ کل نہیں ہوگا۔
سرور لیس کے ساتھ یہ واضح طور پر واضح ہے کہ یہ ایک نظریاتی طور پر درست چیز ہے، جیسے انسانیت کے لیے غلطی برداشت - دو سیاروں کا ہونا ایک سے بہتر ہے۔ لیکن اب کیسے کریں؟ اگر آپ اپنی کوششوں کو اس پر مرکوز کرتے ہیں تو ایک مہم کو بھیجنا کوئی مسئلہ نہیں ہے۔ میرے خیال میں کئی مہمات بھیجنا اور کئی ہزار لوگوں کو وہاں بسانا بھی حقیقت پسندانہ ہے۔ لیکن اسے مکمل طور پر غلطی سے روادار بنانا تاکہ آدھی انسانیت وہاں رہتی ہو، یہ اب مجھے ناممکن لگتا ہے، اس پر غور نہیں کیا جا رہا ہے۔
سرور لیس ون آن ون کے ساتھ: بات اچھی ہے، لیکن یہ 2019 کے مسائل سے بہت دور ہے۔ 2030 کے قریب - آئیے اسے دیکھنے کے لیے جیتے ہیں۔ مجھے اس میں کوئی شک نہیں کہ ہم زندہ رہیں گے، ہم ضرور زندہ رہیں گے (سونے سے پہلے دہرائیں)، لیکن اب ہمیں دوسرے مسائل کو حل کرنے کی ضرورت ہے۔ یہ پریوں کی کہانی ٹٹو رینبو پر یقین کرنے جیسا ہے۔ ہاں، چند فیصد معاملات حل ہو جاتے ہیں، اور وہ مکمل طور پر حل ہو جاتے ہیں، لیکن موضوعی طور پر، سرور لیس ایک قوس قزح ہے... میرے لیے، یہ موضوع بہت دور اور ناقابلِ فہم ہے۔ میں بات کرنے کو تیار نہیں ہوں۔ 2019 میں، آپ سرور لیس کے ساتھ ایک بھی درخواست نہیں لکھ سکتے۔
کبرنیٹس کیسے تیار ہوں گے۔
- جیسا کہ ہم اس ممکنہ طور پر شاندار دور مستقبل کی طرف بڑھ رہے ہیں، آپ کے خیال میں کبرنیٹس اور اس کے ارد گرد کا ماحولیاتی نظام کیسے ترقی کرے گا؟
دیمیتری: میں نے اس کے بارے میں بہت سوچا ہے اور میرے پاس واضح جواب ہے۔ پہلا سٹیٹ فل ہے - بہر حال، بے وطن کرنا آسان ہے۔ کبرنیٹس نے ابتدائی طور پر اس میں زیادہ سرمایہ کاری کی، یہ سب اس کے ساتھ شروع ہوا۔ کوبرنیٹس میں اسٹیٹ لیس تقریباً مکمل طور پر کام کرتا ہے، شکایت کرنے کے لیے کچھ نہیں ہے۔ ابھی بھی بہت سارے مسائل ہیں، یا بلکہ، باریکیاں ہیں۔ وہاں موجود ہر چیز پہلے ہی ہمارے لیے بہت اچھا کام کر رہی ہے، لیکن یہ ہم ہیں۔ اسے سب کے لیے کام کرنے میں کم از کم ایک دو سال اور لگیں گے۔ یہ کوئی حسابی اشارے نہیں بلکہ میرے سر سے میرا احساس ہے۔
مختصراً، سٹیٹ فل کو بہت مضبوطی سے ترقی کرنی چاہیے - اور ہوگی، کیونکہ ہماری تمام ایپلیکیشنز اسٹیٹس کو اسٹور کرتی ہیں؛ کوئی بھی اسٹیٹ لیس ایپلی کیشنز نہیں ہیں۔ یہ ایک وہم ہے؛ آپ کو ہمیشہ کسی نہ کسی قسم کے ڈیٹا بیس اور کچھ اور کی ضرورت ہوتی ہے۔ Statefull ہر ممکن چیز کو سیدھا کرنے، تمام کیڑے ٹھیک کرنے، ان تمام مسائل کو بہتر بنانے کے بارے میں ہے جن کا اس وقت سامنا ہے - آئیے اسے اپنانا کہتے ہیں۔
نامعلوم کی سطح، حل نہ ہونے والے مسائل کی سطح، کسی چیز کا سامنا کرنے کے امکان کی سطح میں نمایاں کمی آئے گی۔ یہ ایک اہم کہانی ہے۔ اور آپریٹرز - آسان سروس حاصل کرنے کے لیے ایڈمنسٹریشن لاجک، کنٹرول لاجک کے ضابطہ بندی سے متعلق ہر چیز: MySQL آسان سروس، RabbitMQ آسان سروس، Memcache آسان سروس - عام طور پر، یہ تمام اجزاء جن کے کام کرنے کے لیے ہمیں ضمانت کی ضرورت ہے۔ ڈبہ. یہ صرف اس تکلیف کو حل کرتا ہے کہ ہم ایک ڈیٹا بیس چاہتے ہیں، لیکن ہم اس کا انتظام نہیں کرنا چاہتے، یا ہم Kubernetes چاہتے ہیں، لیکن ہم اس کا انتظام نہیں کرنا چاہتے۔
آپریٹر کی ترقی کی یہ کہانی کسی نہ کسی شکل میں اگلے چند سالوں میں اہم ہوگی۔
میرے خیال میں استعمال میں آسانی بہت بڑھنی چاہیے - باکس زیادہ سے زیادہ سیاہ، زیادہ سے زیادہ قابل اعتماد، زیادہ سے زیادہ آسان نوبس کے ساتھ ہوتا جائے گا۔
میں نے ایک بار سنیچر نائٹ لائیو پر یوٹیوب پر 80 کی دہائی سے اسحاق عاصموف کا ایک پرانا انٹرویو سنا تھا - ایک پروگرام جیسے ارگنٹ، صرف دلچسپ۔ انہوں نے اس سے کمپیوٹر کے مستقبل کے بارے میں پوچھا۔ انہوں نے کہا کہ مستقبل ریڈیو کی طرح سادگی میں ہے۔ ریڈیو ریسیور اصل میں ایک پیچیدہ چیز تھی۔ لہر کو پکڑنے کے لیے، آپ کو 15 منٹ کے لیے نوبس کو موڑنا پڑتا ہے، سیخوں کو موڑنا پڑتا ہے اور عام طور پر جاننا پڑتا ہے کہ سب کچھ کیسے کام کرتا ہے، ریڈیو ویو ٹرانسمیشن کی فزکس کو سمجھیں۔ نتیجتاً ریڈیو میں صرف ایک ہی دستک رہ گئی۔
اب 2019 میں کون سا ریڈیو؟ کار میں، ریڈیو ریسیور تمام لہروں اور اسٹیشنوں کے نام تلاش کرتا ہے. عمل کی طبیعیات 100 سالوں میں نہیں بدلی ہے، لیکن استعمال میں آسانی ہے۔ اب، اور نہ صرف اب، پہلے سے ہی 1980 میں، جب عظیموف کے ساتھ ایک انٹرویو تھا، سب نے ریڈیو کا استعمال کیا اور کسی نے یہ نہیں سوچا کہ یہ کیسے کام کرتا ہے. یہ ہمیشہ کام کرتا ہے - یہ ایک دیا ہے۔
عظیموف نے پھر کہا کہ کمپیوٹر کے ساتھ بھی ایسا ہی ہوگا۔ استعمال میں آسانی بڑھ جائے گی۔. جب کہ 1980 میں آپ کو کمپیوٹر پر بٹن دبانے کی تربیت دینی پڑتی تھی، مستقبل میں ایسا نہیں ہوگا۔
مجھے یہ احساس ہے کہ Kubernetes اور انفراسٹرکچر کے ساتھ استعمال میں آسانی میں بھی بہت زیادہ اضافہ ہوگا۔ یہ، میری رائے میں، واضح ہے - یہ سطح پر ہے.
انجینئرز کے ساتھ کیا کرنا ہے؟
— پھر انجینئرز اور سسٹم ایڈمنسٹریٹرز کا کیا ہوگا جو کوبرنیٹس کی حمایت کرتے ہیں؟
دیمیتری: 1C کی آمد کے بعد اکاؤنٹنٹ کا کیا ہوا؟ اسی کے بارے میں۔ اس سے پہلے، وہ کاغذ پر شمار کرتے ہیں - اب پروگرام میں. محنت کی پیداواری صلاحیت میں اضافہ ہوا ہے، لیکن خود محنت ختم نہیں ہوئی ہے۔ اگر پہلے ایک لائٹ بلب میں اسکرو کرنے میں 10 انجینئر لگتے تھے تو اب ایک ہی کافی ہوگا۔
سافٹ ویئر کی مقدار اور کاموں کی تعداد، مجھے ایسا لگتا ہے، اب نئے DevOps کے نمودار ہونے کی نسبت تیزی سے بڑھ رہی ہے اور کارکردگی بڑھ رہی ہے۔ اس وقت مارکیٹ میں ایک مخصوص کمی ہے اور یہ طویل عرصے تک رہے گی۔ بعد میں، سب کچھ معمول پر آجائے گا، جس میں کام کی کارکردگی بڑھے گی، زیادہ سے زیادہ سرور لیس ہو جائے گا، Kubernetes کے ساتھ ایک نیوران منسلک ہو گا، جو تمام وسائل کو بالکل ضرورت کے مطابق منتخب کرے گا، اور عام طور پر سب کچھ خود کریں، جیسا کہ اسے ہونا چاہیے - وہ شخص بس دور ہو جائے اور مداخلت نہ کرے۔
لیکن کسی کو ابھی بھی فیصلے کرنے کی ضرورت ہوگی۔ یہ واضح ہے کہ اس شخص کی قابلیت اور تخصص کی سطح زیادہ ہے۔ آج کل، اکاؤنٹنگ ڈیپارٹمنٹ میں، آپ کو کتابیں رکھنے کے لئے 10 ملازمین کی ضرورت نہیں ہے تاکہ ان کے ہاتھ نہ تھکیں. یہ صرف ضروری نہیں ہے۔ الیکٹرانک دستاویز کے انتظام کے نظام کے ذریعہ بہت سے دستاویزات خود بخود اسکین اور پہچانے جاتے ہیں۔ ایک ہوشیار چیف اکاؤنٹنٹ کافی ہے، پہلے سے ہی بہت زیادہ مہارتوں کے ساتھ، اچھی سمجھ بوجھ کے ساتھ۔
عام طور پر، یہ تمام صنعتوں میں جانے کا طریقہ ہے۔ یہ کاروں کے ساتھ بھی ایسا ہی ہے: پہلے، ایک کار مکینک اور تین ڈرائیوروں کے ساتھ آتی تھی۔ آج کل، کار چلانا ایک سادہ عمل ہے جس میں ہم سب روزانہ حصہ لیتے ہیں۔ کوئی بھی نہیں سوچتا کہ کار کوئی پیچیدہ چیز ہے۔
DevOps یا سسٹم انجینئرنگ ختم نہیں ہوگی - اعلیٰ سطحی کام اور کارکردگی میں اضافہ ہوگا۔
- میں نے ایک دلچسپ خیال بھی سنا کہ کام اصل میں بڑھے گا۔
دیمیتری: بالکل، سو فیصد! کیونکہ ہم جو سافٹ ویئر لکھتے ہیں اس کی مقدار مسلسل بڑھ رہی ہے۔ ان مسائل کی تعداد جو ہم سافٹ ویئر کے ساتھ حل کرتے ہیں مسلسل بڑھ رہی ہے۔ کام کی مقدار بڑھ رہی ہے۔ اب DevOps مارکیٹ بہت زیادہ گرم ہے۔ یہ تنخواہ کی توقعات میں دیکھا جا سکتا ہے. اچھے طریقے سے، تفصیلات میں جانے کے بغیر، ایسے جونیئرز ہونے چاہئیں جو X چاہتے ہیں، مڈل جو 1,5X چاہتے ہیں، اور بزرگ جو 2X چاہتے ہیں۔ اور اب، اگر آپ Moscow DevOps سیلری مارکیٹ کو دیکھیں تو ایک جونیئر X سے 3X تک اور ایک سینئر X سے 3X تک چاہتا ہے۔
کوئی نہیں جانتا کہ اس کی قیمت کتنی ہے۔ تنخواہ کی سطح آپ کے اعتماد سے ماپا جاتا ہے - ایک مکمل پاگل خانہ، سچ پوچھیں تو، ایک بہت زیادہ گرم بازار۔
یقینا، یہ صورت حال بہت جلد بدل جائے گی - کچھ سنترپتی ہونا چاہئے. سافٹ ویئر ڈویلپمنٹ کا معاملہ ایسا نہیں ہے - اس حقیقت کے باوجود کہ ہر کسی کو ڈویلپرز کی ضرورت ہوتی ہے، اور ہر ایک کو اچھے ڈویلپرز کی ضرورت ہوتی ہے، مارکیٹ سمجھتی ہے کہ کون کس کے قابل ہے - انڈسٹری آباد ہو گئی ہے۔ ان دنوں DevOps کے ساتھ ایسا نہیں ہے۔
- جو کچھ میں نے سنا اس سے میں نے یہ نتیجہ اخذ کیا کہ موجودہ سسٹم ایڈمنسٹریٹر کو زیادہ فکر نہیں کرنی چاہیے، لیکن یہ وقت ہے کہ وہ اپنی صلاحیتوں کو اپ گریڈ کریں اور اس حقیقت کے لیے تیاری کریں کہ کل مزید کام ہو گا، لیکن یہ زیادہ قابلیت والا ہوگا۔
دیمیتری: سو فیصد. عام طور پر، ہم 2019 میں رہتے ہیں اور زندگی کا اصول یہ ہے: زندگی بھر سیکھنا - ہم اپنی زندگی بھر سیکھتے ہیں۔. مجھے ایسا لگتا ہے کہ اب ہر کوئی اسے جانتا اور محسوس کرتا ہے، لیکن یہ جاننا کافی نہیں ہے - آپ کو یہ کرنا ہوگا۔ ہر روز ہمیں بدلنا چاہیے۔ اگر ہم نے ایسا نہیں کیا تو جلد یا بدیر ہم پیشے سے ہی محروم ہو جائیں گے۔
تیز 180 ڈگری موڑ کے لیے تیار رہیں۔ میں ایسی صورتحال کو مسترد نہیں کرتا جہاں کوئی چیز یکسر بدل جاتی ہے، کچھ نیا ایجاد ہوتا ہے - ایسا ہوتا ہے۔ ہاپ! - اور اب ہم مختلف طریقے سے کام کرتے ہیں۔ اس کے لیے تیار رہنا ضروری ہے اور پریشان ہونے کی ضرورت نہیں۔ ایسا ہو سکتا ہے کہ کل میں جو کچھ بھی کروں وہ غیر ضروری ہو جائے گا - کچھ نہیں، میں نے ساری زندگی پڑھی ہے اور کچھ اور سیکھنے کے لیے تیار ہوں۔ یہ کوئی مسئلہ نہیں ہے. ملازمت کے تحفظ سے ڈرنے کی ضرورت نہیں ہے، لیکن آپ کو مسلسل کچھ نیا سیکھنے کے لیے تیار رہنے کی ضرورت ہے۔
خواہشات اور اشتہار کا ایک منٹ
- کیا آپ کی کوئی خواہش ہے؟
دیمیتری: ہاں، میری کئی خواہشات ہیں۔
سب سے پہلے اور تجارتی - سبسکرائب کریں . پیارے قارئین، یوٹیوب پر جائیں اور ہمارے چینل کو سبسکرائب کریں۔ تقریباً ایک ماہ میں ہم ویڈیو سروس پر فعال توسیع شروع کر دیں گے۔ ہمارے پاس کبرنیٹس کے بارے میں بہت زیادہ تعلیمی مواد ہوگا، کھلا اور متنوع: عملی چیزوں سے لے کر لیبارٹریوں تک، گہری بنیادی نظریاتی چیزوں تک اور کبرنیٹس کو استعمال کرنے کا طریقہ۔ اصولوں اور نمونوں کی سطح۔
دوسری تجارتی خواہش - جاؤ اور ستارے لگاتے ہیں کیونکہ ہم ان پر کھانا کھاتے ہیں۔ اگر آپ ہمیں ستارے نہیں دیتے تو ہمارے پاس کھانے کو کچھ نہیں ہوگا۔ یہ کمپیوٹر گیم میں مانا کی طرح ہے۔ ہم کچھ کرتے ہیں، ہم کرتے ہیں، ہم کوشش کرتے ہیں، کوئی کہتا ہے کہ یہ خوفناک سائیکلیں ہیں، کوئی کہتا ہے کہ سب کچھ بالکل غلط ہے، لیکن ہم جاری رکھتے ہیں اور پوری ایمانداری سے کام کرتے ہیں۔ ہم ایک مسئلہ دیکھتے ہیں، اسے حل کرتے ہیں اور اپنا تجربہ شیئر کرتے ہیں۔ لہذا، ہمیں ایک ستارہ دو، یہ آپ سے دور نہیں ہوگا، لیکن یہ ہمارے پاس آئے گا، کیونکہ ہم انہیں کھاتے ہیں.
تیسرا، اہم، اور اب تجارتی خواہش نہیں - پریوں کی کہانیوں پر یقین کرنا چھوڑ دو. آپ پیشہ ور ہیں۔ DevOps ایک بہت سنجیدہ اور ذمہ دار پیشہ ہے۔ کام کی جگہ پر کھیلنا بند کریں۔ اسے آپ کے لیے کلک کرنے دیں اور آپ اسے سمجھ جائیں گے۔ تصور کریں کہ آپ ہسپتال آتے ہیں، اور وہاں ڈاکٹر آپ پر تجربہ کر رہا ہے۔ میں سمجھتا ہوں کہ یہ کسی کے لیے ناگوار ہو سکتا ہے، لیکن، غالباً، یہ آپ کے بارے میں نہیں، بلکہ کسی اور کے بارے میں ہے۔ دوسروں کو بھی رکنے کو کہیں۔ یہ واقعی ہم سب کی زندگی کو برباد کر دیتا ہے - بہت سے لوگ آپریشنز، ایڈمنز اور ڈی او اوپس کو ایسے دوست ماننا شروع کر دیتے ہیں جنہوں نے دوبارہ کچھ توڑا ہے۔ یہ اکثر اس حقیقت کی وجہ سے "ٹوٹا" تھا کہ ہم کھیلنے گئے تھے، اور ٹھنڈے ہوش سے نہیں دیکھا کہ یہ ایسا ہے، اور ایسا ہی ہے۔
اس کا مطلب یہ نہیں ہے کہ آپ کو تجربہ نہیں کرنا چاہئے۔ ہمیں تجربہ کرنے کی ضرورت ہے، ہم خود کرتے ہیں۔ سچ پوچھیں تو، ہم خود کبھی کبھی گیم کھیلتے ہیں - یہ، یقینا، بہت برا ہے، لیکن کچھ بھی انسان ہمارے لئے اجنبی نہیں ہے. آئیے 2019 کو سنجیدہ، سوچے سمجھے تجربات کا سال قرار دیں، نہ کہ پروڈکشن پر گیمز۔ شاید ایسا ہی ہو۔
- بہت بہت شکریہ!
دیمیتری: آپ کا شکریہ، Vitaly، وقت اور انٹرویو کے لیے۔ پیارے قارئین، اگر آپ اچانک اس مقام پر پہنچ گئے ہیں تو آپ کا بہت شکریہ۔ مجھے امید ہے کہ ہم آپ کے لیے کم از کم ایک دو خیالات لائے ہیں۔
انٹرویو میں، دمتری نے werf کے مسئلے کو چھوا. اب یہ ایک عالمگیر سوئس چاقو ہے جو تقریباً تمام مسائل کو حل کرتا ہے۔ لیکن ہمیشہ ایسا نہیں تھا۔ پر تہوار میں دمتری Stolyarov آپ کو اس آلے کے بارے میں تفصیل سے بتائیں گے۔ رپورٹ میں وہاں سب کچھ ہوگا: Kubernetes کے مسائل اور پوشیدہ باریکیاں، ان مشکلات کو حل کرنے کے اختیارات اور تفصیل سے werf کا موجودہ نفاذ۔ 27 اور 28 مئی کو ہمارے ساتھ شامل ہوں، ہم بہترین ٹولز بنائیں گے۔
ماخذ: www.habr.com