مئی کے آخر میں اس موضوع پر ایک آن لائن میٹنگ منعقد کی۔ . ہم نے اصولی طور پر کنٹینرز، کبرنیٹس اور آرکیسٹریشن کے بارے میں بات کی، بنیادی ڈھانچے کے انتخاب کے لیے معیار اور بہت کچھ۔ شرکاء نے اپنی پریکٹس سے کیسز شیئر کیے۔
شرکاء:
- Evgeniy Potapov، ITSumma کے سی ای او. اس کے آدھے سے زیادہ گاہک یا تو پہلے ہی منتقل ہو رہے ہیں یا Kubernetes میں جانا چاہتے ہیں۔
- دمتری سٹولیاروف، سی ٹی او "فلانٹ". کنٹینر سسٹم کے ساتھ کام کرنے کا 10+ سال کا تجربہ ہے۔
- ڈینس ریمچوکوف (عرف ایرک اولڈمین)، COO argotech.io، سابق RAO UES. انہوں نے "خونی" انٹرپرائز میں مقدمات کے بارے میں بات کرنے کا وعدہ کیا.
- اینڈری فیڈوروفسکی، CTO "News360.com"کسی دوسرے کھلاڑی کے ذریعہ کمپنی خریدنے کے بعد، وہ متعدد ایم ایل اور اے آئی پروجیکٹس اور انفراسٹرکچر کے لیے ذمہ دار ہے۔
- ایوان کروگلوف، سسٹم انجینئر، سابق بکنگ ڈاٹ کام۔وہی شخص جس نے اپنے ہاتھوں سے Kubernetes کے ساتھ بہت کچھ کیا۔
موضوعات:
- کنٹینرز اور آرکیسٹریشن کے بارے میں شرکاء کی بصیرت (ڈوکر، کبرنیٹس، وغیرہ)؛ عملی طور پر کیا آزمایا گیا یا تجزیہ کیا گیا۔
- کیس: کمپنی برسوں سے بنیادی ڈھانچے کی ترقی کا منصوبہ بنا رہی ہے۔ یہ فیصلہ کیسے کیا جاتا ہے کہ کنٹینرز اور کوبیر میں انفراسٹرکچر بنانا (یا موجودہ کو منتقل کرنا) ہے یا نہیں؟
- کلاؤڈ-آبائی دنیا میں مسائل، کیا غائب ہے، آئیے تصور کریں کہ کل کیا ہوگا۔
ایک دلچسپ بحث کا آغاز ہوا، شرکاء کی رائے بہت مختلف تھی اور اتنے زیادہ تبصرے ہوئے کہ میں انہیں آپ کے ساتھ شیئر کرنا چاہتا ہوں۔ کھاؤ ، اور ذیل میں بحث کا خلاصہ ہے۔
کیا Kubernetes پہلے سے ہی ایک معیاری یا زبردست مارکیٹنگ ہے؟
"ہم اس کے پاس آئے (Kubernetes. - Ed.) جب کسی کو ابھی تک اس کے بارے میں معلوم نہیں تھا۔ ہم اس کے پاس اس وقت بھی آئے جب وہ وہاں نہیں تھا۔ ہم اسے پہلے ہی چاہتے تھے"- دمتری سٹولیاروف
Reddit.com سے تصویر
5-10 سال پہلے ٹولز کی ایک بڑی تعداد تھی، اور کوئی ایک معیار نہیں تھا. ہر چھ ماہ بعد ایک نئی پروڈکٹ ظاہر ہوتی ہے، یا اس سے بھی زیادہ۔ پہلے ویگرنٹ، پھر سالٹ، شیف، پپیٹ،... "اور آپ ہر چھ ماہ بعد اپنے انفراسٹرکچر کو دوبارہ بناتے ہیں۔ آپ کے پاس پانچ ایڈمنسٹریٹر ہیں جو ترتیب کو دوبارہ لکھنے میں مسلسل مصروف رہتے ہیں،‘‘ آندرے فیڈوروفسکی یاد کرتے ہیں۔ اس کا خیال ہے کہ ڈوکر اور کبرنیٹس نے باقی کو "ہجوم" کر دیا ہے۔ ڈوکر پچھلے پانچ سالوں میں ایک معیار بن گیا ہے، پچھلے دو سالوں میں کبرنیٹس۔ اور یہ صنعت کے لیے اچھا ہے۔.
دمتری سٹولیاروف اور ان کی ٹیم کوبر سے محبت کرتے ہیں۔ وہ ایسا آلہ چاہتے تھے کہ اس کے ظاہر ہونے سے پہلے، اور اس کے پاس آئے جب کسی کو اس کے بارے میں معلوم نہ تھا۔ فی الحال، سہولت کی وجہ سے، اگر وہ سمجھتے ہیں کہ وہ اس کے ساتھ Kubernetes کو لاگو نہیں کریں گے تو وہ کسی کلائنٹ کو نہیں لیتے۔ اسی وقت، دمتری کے مطابق، کمپنی کے پاس "خوفناک میراث کو دوبارہ بنانے کے بارے میں کامیابی کی بہت سی کہانیاں ہیں۔"
Kubernetes نہ صرف کنٹینر آرکیسٹریشن ہے، بلکہ یہ ایک ترقی یافتہ API، ایک نیٹ ورکنگ جزو، L3 بیلنسنگ اور Ingress کنٹرولرز کے ساتھ کنفیگریشن مینجمنٹ سسٹم ہے، جو انفراسٹرکچر کی نچلی پرتوں سے وسائل، پیمانے اور خلاصہ کا انتظام کرنا نسبتاً آسان بناتا ہے۔
بدقسمتی سے، ہماری زندگی میں ہمیں ہر چیز کی قیمت ادا کرنی پڑتی ہے۔ اور یہ ٹیکس بہت بڑا ہے، خاص طور پر اگر ہم ایک ترقی یافتہ انفراسٹرکچر والی کمپنی کے Kubernetes میں منتقلی کے بارے میں بات کریں، جیسا کہ Ivan Kruglov کا خیال ہے۔ وہ روایتی انفراسٹرکچر والی کمپنی اور کبر کے ساتھ آزادانہ طور پر کام کر سکتا تھا۔ اہم چیز کمپنی اور مارکیٹ کی خصوصیات کو سمجھنا ہے۔ لیکن، مثال کے طور پر، Evgeny Potapov کے لیے، جو Kubernetes کو کسی بھی کنٹینر آرکیسٹریشن ٹول پر عام کرے گا، ایسا سوال ہی پیدا نہیں ہوتا۔
Evgeniy نے 1990 کی دہائی کی صورت حال سے مشابہت پیدا کی، جب آبجیکٹ اورینٹڈ پروگرامنگ پیچیدہ ایپلی کیشنز کو پروگرامنگ کے طریقے کے طور پر ظاہر کیا۔ اس وقت، بحث جاری رہی اور OOP کی حمایت کرنے کے لیے نئے ٹولز نمودار ہوئے۔ پھر مائیکرو سروسز یک سنگی تصور سے دور جانے کے راستے کے طور پر ابھریں۔ اس کے نتیجے میں، کنٹینرز اور کنٹینر مینجمنٹ ٹولز کا ظہور ہوا۔ "میرا خیال ہے کہ ہم جلد ہی ایک ایسے وقت پر آئیں گے جب اس بارے میں کوئی سوال نہیں ہوگا کہ آیا یہ ایک چھوٹی مائیکرو سروس ایپلیکیشن لکھنے کے قابل ہے، اسے بطور ڈیفالٹ مائیکرو سروس لکھا جائے گا،" وہ یقین رکھتے ہیں۔ اسی طرح، Docker اور Kubernetes بالآخر انتخاب کی ضرورت کے بغیر معیاری حل بن جائیں گے۔
اسٹیٹ لیس میں ڈیٹا بیس کا مسئلہ
کی طرف سے تصویر
آج کل، Kubernetes میں ڈیٹا بیس چلانے کی بہت سی ترکیبیں ہیں۔ یہاں تک کہ اس حصے کو کیسے الگ کیا جائے جو I/O ڈسک کے ساتھ کام کرتا ہے، شرط کے ساتھ، ڈیٹا بیس کے ایپلیکیشن حصے سے۔ کیا یہ ممکن ہے کہ مستقبل میں ڈیٹا بیس اس قدر تبدیل ہو جائیں کہ انہیں ایک ڈبے میں پہنچایا جائے، جہاں ایک حصہ ڈوکر اور کبرنیٹس کے ذریعے ترتیب دیا جائے گا، اور انفراسٹرکچر کے دوسرے حصے میں علیحدہ سافٹ ویئر کے ذریعے، اسٹوریج کا حصہ فراہم کیا جائے گا۔ ? کیا اڈے بطور مصنوعہ بدلیں گے؟
آندرے کا خیال ہے کہ یہ تفصیل قطار کے انتظام سے ملتی جلتی ہے، لیکن روایتی ڈیٹا بیس میں معلومات کی وشوسنییتا اور ہم آہنگی کے تقاضے بہت زیادہ ہیں۔ عام ڈیٹا بیس میں کیش ہٹ کا تناسب 99% پر رہتا ہے۔ اگر کوئی کارکن نیچے چلا جاتا ہے، تو ایک نیا لانچ کیا جاتا ہے، اور کیشے شروع سے "گرم اپ" ہوتا ہے۔ جب تک کیشے کو گرم نہیں کیا جاتا ہے، کارکن آہستہ آہستہ کام کرتا ہے، جس کا مطلب ہے کہ اسے صارف کے بوجھ کے ساتھ لوڈ نہیں کیا جا سکتا۔ جبکہ صارف کا کوئی بوجھ نہیں ہے، کیشے گرم نہیں ہوتا ہے۔ یہ ایک شیطانی دائرہ ہے۔
دمتری بنیادی طور پر متفق نہیں ہے - کورم اور شارڈنگ مسئلہ حل کرتے ہیں۔ لیکن آندرے کا اصرار ہے کہ یہ حل ہر کسی کے لیے موزوں نہیں ہے۔ کچھ حالات میں، کورم موزوں ہوتا ہے، لیکن یہ نیٹ ورک پر اضافی بوجھ ڈالتا ہے۔ NoSQL ڈیٹا بیس تمام معاملات میں موزوں نہیں ہے۔
میٹنگ کے شرکاء کو دو کیمپوں میں تقسیم کیا گیا تھا۔
ڈینس اور اینڈری کا استدلال ہے کہ ہر وہ چیز جو ڈسک پر لکھی جاتی ہے - ڈیٹا بیس اور اسی طرح - موجودہ کوبر ماحولیاتی نظام میں کرنا ناممکن ہے۔ Kubernetes میں پیداواری ڈیٹا کی سالمیت اور مستقل مزاجی کو برقرار رکھنا ناممکن ہے۔ یہ ایک بنیادی خصوصیت ہے۔ حل: ہائبرڈ انفراسٹرکچر۔
یہاں تک کہ جدید کلاؤڈ مقامی ڈیٹا بیس جیسے MongoDB اور Cassandra، یا کافکا یا RabbitMQ جیسے پیغامات کی قطاروں کو بھی Kubernetes کے باہر مستقل ڈیٹا اسٹورز کی ضرورت ہوتی ہے۔
Evgeniy اعتراض کرتا ہے: "Kubera میں اڈے قریب قریب روسی، یا قریبی انٹرپرائز کی چوٹ ہیں، جو اس حقیقت سے وابستہ ہے کہ روس میں کوئی کلاؤڈ اپنانے نہیں ہے۔" مغرب میں چھوٹی یا درمیانے درجے کی کمپنیاں کلاؤڈ ہیں۔ ایمیزون آر ڈی ایس ڈیٹا بیس کا استعمال خود کوبرنیٹس کے ساتھ ٹنکرنگ کرنے سے زیادہ آسان ہے۔ روس میں جب وہ چڑیا گھر سے چھٹکارا حاصل کرنے کی کوشش کر رہے ہوتے ہیں تو وہ کوبیر کو "پریمائز" استعمال کرتے ہیں اور اس میں اڈے منتقل کرتے ہیں۔
دمتری نے اس بیان سے بھی اختلاف کیا کہ کوبرنیٹس میں کوئی ڈیٹا بیس نہیں رکھا جا سکتا: "بیس بیس سے مختلف ہے۔ اور اگر آپ ایک بڑے رشتہ دار ڈیٹا بیس کو آگے بڑھاتے ہیں، تو کسی بھی حالت میں نہیں۔ اگر آپ کسی چھوٹی اور بادل کی مقامی چیز کو آگے بڑھاتے ہیں، جو ذہنی طور پر نیم عارضی زندگی کے لیے تیار ہے، تو سب کچھ ٹھیک ہو جائے گا۔ دمتری نے یہ بھی بتایا کہ ڈیٹا بیس مینجمنٹ ٹولز ڈوکر یا کوبر کے لیے تیار نہیں ہیں، اس لیے بڑی مشکلات پیدا ہوتی ہیں۔
Ivan، بدلے میں، اس بات کا یقین ہے کہ یہاں تک کہ اگر ہم ریاستی اور بے وطن کے تصورات سے خلاصہ کرتے ہیں، Kubernetes میں انٹرپرائز حل کا ماحولیاتی نظام ابھی تک تیار نہیں ہے۔ کوبیر کے ساتھ، قانون سازی اور ریگولیٹری ضروریات کو برقرار رکھنا مشکل ہے۔ مثال کے طور پر، شناخت کی فراہمی کا حل بنانا ناممکن ہے جہاں سرور کی شناخت کی سخت ضمانتیں درکار ہوں، بالکل نیچے سرورز میں داخل کردہ ہارڈ ویئر تک۔ یہ علاقہ ترقی کر رہا ہے، لیکن ابھی تک کوئی حل نہیں ہے۔
شرکاء متفق ہونے سے قاصر تھے، اس لیے اس حصے میں کوئی نتیجہ اخذ نہیں کیا جائے گا۔ آئیے ایک دو عملی مثالیں دیتے ہیں۔
کیس 1. کوبیرا کے باہر اڈوں کے ساتھ "میگا ریگولیٹر" کی سائبرسیکیوریٹی
ایک ترقی یافتہ سائبر سیکیورٹی سسٹم کی صورت میں، کنٹینرز اور آرکیسٹریشن کا استعمال حملوں اور دخل اندازیوں سے لڑنا ممکن بناتا ہے۔ مثال کے طور پر، ایک میگا ریگولیٹر میں، ڈینس اور اس کی ٹیم نے ایک تربیت یافتہ SIEM سروس کے ساتھ آرکیسٹریٹر کا ایک مجموعہ نافذ کیا جو اصل وقت میں لاگز کا تجزیہ کرتا ہے اور حملے، ہیکنگ یا ناکامی کے عمل کا تعین کرتا ہے۔ حملے کی صورت میں، کسی چیز کو رکھنے کی کوشش، یا رینسم ویئر وائرس کے حملے کی صورت میں، یہ، آرکیسٹریٹر کے ذریعے، ایپلی کیشنز والے کنٹینرز کو اس سے زیادہ تیزی سے اٹھا لیتا ہے جتنا وہ متاثر ہوتا ہے، یا حملہ آور کے ان پر حملہ کرنے سے زیادہ تیزی سے۔
کیس 2. Booking.com ڈیٹا بیس کی جزوی منتقلی Kubernetes میں
Booking.com میں، مرکزی ڈیٹا بیس غیر مطابقت پذیر نقل کے ساتھ MySQL ہے - یہاں ایک ماسٹر اور غلاموں کا مکمل درجہ بندی ہے۔ جس وقت ایوان نے کمپنی چھوڑی، غلاموں کی منتقلی کے لیے ایک پروجیکٹ شروع کیا گیا تھا جسے کچھ خاص نقصان کے ساتھ "گولی ماری" جا سکتی تھی۔
مرکزی اڈے کے علاوہ، خود تحریری آرکیسٹریشن کے ساتھ کیسینڈرا کی تنصیب بھی ہے، جو کوبیر کے مرکزی دھارے میں آنے سے پہلے ہی لکھی گئی تھی۔ اس سلسلے میں کوئی مسئلہ نہیں ہے، لیکن یہ مقامی SSDs پر برقرار ہے۔ ریموٹ سٹوریج، حتیٰ کہ ایک ہی ڈیٹا سینٹر میں، زیادہ تاخیر کے مسئلے کی وجہ سے استعمال نہیں ہوتا ہے۔
ڈیٹا بیس کی تیسری کلاس Booking.com سرچ سروس ہے، جہاں ہر سروس نوڈ ایک ڈیٹا بیس ہوتا ہے۔ سرچ سروس کو کوبر میں منتقل کرنے کی کوششیں ناکام ہو گئیں، کیونکہ ہر نوڈ میں 60-80 GB مقامی اسٹوریج ہے، جسے "لفٹ" اور "وارم اپ" کرنا مشکل ہے۔
نتیجے کے طور پر، تلاش کے انجن کو Kubernetes میں منتقل نہیں کیا گیا تھا، اور آئیون نہیں سوچتا کہ مستقبل قریب میں نئی کوششیں ہوں گی. MySQL ڈیٹا بیس کو نصف میں منتقل کیا گیا تھا: صرف غلام، جو "گولی مارنے" سے نہیں ڈرتے ہیں۔ کیسینڈرا بالکل ٹھیک ٹھاک ہے۔
بنیادی ڈھانچے کا انتخاب عام حل کے بغیر ایک کام کے طور پر
کی طرف سے تصویر
ہم کہتے ہیں کہ ہمارے پاس ایک نئی کمپنی ہے، یا ایک کمپنی ہے جہاں بنیادی ڈھانچے کا کچھ حصہ پرانے طریقے سے بنایا گیا ہے۔ یہ برسوں سے بنیادی ڈھانچے کی ترقی کا منصوبہ بناتا ہے۔ کنٹینرز اور کبیر پر انفراسٹرکچر بنانے یا نہ کرنے کا فیصلہ کیسے ہوتا ہے؟
وہ کمپنیاں جو نینو سیکنڈ کے لیے لڑتی ہیں بحث سے باہر ہیں۔ صحت مند قدامت پسندی قابل اعتماد کے لحاظ سے ادا کرتی ہے، لیکن اب بھی ایسی کمپنیاں ہیں جنہیں نئے طریقوں پر غور کرنا چاہیے۔
ایوان: "میں یقینی طور پر اب کلاؤڈ پر ایک کمپنی شروع کروں گا، صرف اس لیے کہ یہ تیز تر ہے،" اگرچہ ضروری نہیں کہ سستا ہو۔ وینچر کیپیٹلزم کی ترقی کے ساتھ، سٹارٹ اپس کو پیسے کے ساتھ کوئی بڑا مسئلہ نہیں ہے، اور بنیادی کام مارکیٹ کو فتح کرنا ہے۔
ایوان کا خیال ہے کہ موجودہ بنیادی ڈھانچے کی ترقی انتخاب کا معیار ہے۔. اگر ماضی میں کوئی سنجیدہ سرمایہ کاری ہوئی تھی، اور یہ کام کرتی ہے، تو اسے دوبارہ کرنے کا کوئی فائدہ نہیں ہے۔ اگر بنیادی ڈھانچہ تیار نہیں ہے، اور آلات، سیکورٹی اور نگرانی کے ساتھ مسائل ہیں، تو یہ ایک تقسیم شدہ بنیادی ڈھانچے کو دیکھنے کے لئے معنی رکھتا ہے.
ٹیکس ہر صورت میں ادا کرنا پڑے گا، اور آئیون وہی ادا کرے گا جس نے اسے مستقبل میں کم ادا کرنے کی اجازت دی تھی۔ "کیونکہ صرف اس حقیقت کی وجہ سے کہ میں اس ٹرین پر سوار ہوں جس پر دوسرے چل رہے ہیں، میں اس سے کہیں زیادہ سفر کروں گا کہ میں دوسری ٹرین میں بیٹھوں گا، جس میں مجھے خود ایندھن ڈالنا ہے۔"ایوان کہتے ہیں. جب کمپنی نئی ہے، اور تاخیر کے تقاضے دسیوں ملی سیکنڈز کے ہوتے ہیں، تب Ivan ان "آپریٹرز" کی طرف دیکھے گا جس میں آج کل کلاسیکی ڈیٹا بیس "لپٹے ہوئے" ہیں۔ وہ ایک نقل کی زنجیر کو بڑھاتے ہیں، جو فیل اوور وغیرہ کی صورت میں خود کو بدل دیتی ہے۔
چند سرورز والی ایک چھوٹی کمپنی کے لیے، کوبیرا کا کوئی مطلب نہیں ہے،‘‘ آندرے کہتے ہیں۔ لیکن اگر یہ سیکڑوں یا اس سے زیادہ سرورز تک بڑھنے کا ارادہ رکھتا ہے، تو اسے آٹومیشن اور ریسورس مینجمنٹ سسٹم کی ضرورت ہے۔ 90% مقدمات لاگت کے قابل ہیں۔ مزید یہ کہ بوجھ اور وسائل کی سطح سے قطع نظر۔ سٹارٹ اپ سے لے کر لاکھوں سامعین والی بڑی کمپنیوں تک، آہستہ آہستہ کنٹینر آرکیسٹریشن پروڈکٹس کی طرف دیکھنا سب کے لیے معنی خیز ہے۔ "ہاں، یہ واقعی مستقبل ہے،" آندرے کو یقین ہے۔
ڈینس نے دو اہم معیارات بیان کیے - توسیع پذیری اور آپریشن کی استحکام. وہ ان ٹولز کا انتخاب کرے گا جو اس کام کے لیے بہترین موزوں ہوں۔ "یہ آپ کے گھٹنوں پر جمع کیا ہوا نام ہوسکتا ہے، اور اس پر Nutanix Community Edition ہے۔ یہ بیک اینڈ پر ڈیٹا بیس کے ساتھ کبیر پر ایپلی کیشن کی شکل میں دوسری لائن ہو سکتی ہے، جسے نقل کیا گیا ہے اور RTO اور RPO پیرامیٹرز کو متعین کیا گیا ہے" (بازیابی کا وقت/پوائنٹ مقاصد - تقریبا.).
Evgeni نے اہلکاروں کے ساتھ ایک ممکنہ مسئلہ کی نشاندہی کی۔ اس وقت، مارکیٹ میں بہت سے اعلیٰ تعلیم یافتہ ماہرین نہیں ہیں جو "ہمت" کو سمجھتے ہیں۔ درحقیقت، اگر منتخب کردہ ٹیکنالوجی پرانی ہے، تو ادھیڑ عمر کے لوگوں کے علاوہ کسی اور کو ملازمت دینا مشکل ہے جو زندگی سے بور اور تھکے ہوئے ہوں۔ اگرچہ دیگر شرکاء کا خیال ہے کہ یہ عملے کی تربیت کا معاملہ ہے۔
اگر ہم انتخاب کا سوال رکھیں: Amazon RDS میں ڈیٹا بیس کے ساتھ پبلک کلاؤڈ میں ایک چھوٹی کمپنی لانچ کرنے کے لیے یا Kubernetes میں ڈیٹا بیس کے ساتھ "آن پرائمیس"، تو کچھ کوتاہیوں کے باوجود، شرکاء کا انتخاب Amazon RDS تھا۔
چونکہ میٹنگ اپ سننے والوں کی اکثریت "خونی" انٹرپرائز سے نہیں ہے، پھر تقسیم شدہ حل وہ ہیں جن کے لیے ہمیں کوشش کرنی چاہیے۔ ڈیٹا اسٹوریج سسٹمز کو تقسیم کیا جانا چاہیے، قابل بھروسہ ہونا چاہیے، اور زیادہ سے زیادہ دسیوں ملی سیکنڈز کی اکائیوں میں ماپا جانے والا تاخیر پیدا کرنا چاہیے۔"، آندرے نے خلاصہ کیا۔
Kubernetes کے استعمال کا اندازہ لگانا
سننے والے انتون زہبانکوف نے کبرنیٹس کے معذرت خواہوں سے ایک ٹریپ سوال پوچھا: آپ نے فزیبلٹی اسٹڈی کا انتخاب اور انعقاد کیسے کیا؟ کیوں Kubernetes، کیوں نہیں ورچوئل مشینیں، مثال کے طور پر؟
کی طرف سے تصویر
دمتری اور ایوان نے اس کا جواب دیا۔ دونوں صورتوں میں، آزمائش اور غلطی کے ذریعے، فیصلوں کا ایک سلسلہ بنایا گیا، جس کے نتیجے میں دونوں شرکاء کوبرنیٹس پہنچے۔ اب کاروبار آزادانہ طور پر ایسا سافٹ ویئر تیار کرنا شروع کر رہے ہیں جو کوبیر کو منتقل کرنے کا مطلب ہے۔ ہم کلاسک تھرڈ پارٹی سسٹمز، جیسے 1C کے بارے میں بات نہیں کر رہے ہیں۔ Kubernetes اس وقت مدد کرتا ہے جب ڈویلپرز کو نان سٹاپ مسلسل بہتری کے ساتھ فوری طور پر ریلیز کرنے کی ضرورت ہوتی ہے۔
اینڈری کی ٹیم نے ورچوئل مشینوں پر مبنی ایک قابل توسیع کلسٹر بنانے کی کوشش کی۔ نوڈس ڈومینوز کی طرح گرے، جو کبھی کبھی کلسٹر کے خاتمے کا باعث بنے۔ "نظریاتی طور پر، آپ اسے ختم کر سکتے ہیں اور اپنے ہاتھوں سے اس کی حمایت کر سکتے ہیں، لیکن یہ تکلیف دہ ہے۔ اور اگر مارکیٹ میں کوئی ایسا حل موجود ہے جو آپ کو باکس سے باہر کام کرنے کی اجازت دیتا ہے، تو ہم اس کے لیے جانے میں خوش ہیں۔ اور ہم اس کے نتیجے میں بدل گئے، "آندرے کہتے ہیں۔
اس طرح کے تجزیے اور حساب کتاب کے لیے معیارات موجود ہیں، لیکن کوئی بھی یہ نہیں کہہ سکتا کہ وہ آپریشن میں حقیقی ہارڈ ویئر پر کتنے درست ہیں۔ حساب کتاب کے لیے ہر ٹول اور ایکو سسٹم کو سمجھنا بھی ضروری ہے، لیکن یہ ممکن نہیں ہے۔
ہمارا کیا انتظار ہے۔
کی طرف سے تصویر
جیسے جیسے ٹیکنالوجی تیار ہوتی ہے، زیادہ سے زیادہ مختلف ٹکڑے نمودار ہوتے ہیں، اور پھر ایک مرحلے کی منتقلی ہوتی ہے، ایک فروش ظاہر ہوتا ہے جس نے ایک ہی آلے میں ہر چیز کو اکٹھا کرنے کے لیے کافی آٹا مار ڈالا ہوتا ہے۔
کیا آپ کو لگتا ہے کہ ایک وقت آئے گا جب لینکس کی دنیا کے لیے اوبنٹو جیسا ٹول ہوگا؟ شاید ایک ہی کنٹینرائزیشن اور آرکیسٹریشن ٹول میں کبر شامل ہوگا۔ یہ آن پریمیس کلاؤڈز بنانا آسان بنائے گا۔
جواب آئیون کی طرف سے دیا گیا: "گوگل اب اینتھوس بنا رہا ہے - یہ ان کی پیکڈ پیشکش ہے جو کلاؤڈ کو تعینات کرتی ہے اور اس میں کوبیر، سروس میش، مانیٹرنگ شامل ہے - وہ تمام ہارڈ ویئر جو آن پریمیس مائیکرو سروسز کے لیے درکار ہیں۔" ہم تقریباً مستقبل میں ہیں۔"
ڈینس نے vRealize Suite پروڈکٹ کے ساتھ Nutanix اور VMWare کا بھی ذکر کیا، جو کنٹینرائزیشن کے بغیر اسی طرح کے کام سے نمٹ سکتے ہیں۔
دمتری نے اپنی رائے کا اظہار کیا کہ "درد" کو کم کرنا اور ٹیکسوں کو کم کرنا دو ایسے شعبے ہیں جہاں ہم بہتری کی توقع کر سکتے ہیں۔
بحث کا خلاصہ کرنے کے لیے، ہم جدید انفراسٹرکچر کے درج ذیل مسائل پر روشنی ڈالتے ہیں:
- تین شرکاء نے فوری طور پر اسٹیٹول کے ساتھ ایک مسئلہ کی نشاندہی کی۔
- سیکیورٹی سپورٹ کے مختلف مسائل، بشمول یہ امکان کہ ڈاکر ازگر کے متعدد ورژنز، ایپلیکیشن سرورز، اور اجزاء کے ساتھ ختم ہوجائے گا۔
زیادہ خرچ کرنا، جس پر ایک الگ میٹنگ میں بات کرنا بہتر ہے۔
آرکیسٹریشن کے طور پر سیکھنے کا چیلنج ایک پیچیدہ ماحولیاتی نظام ہے۔
صنعت میں ایک عام مسئلہ ٹولز کا غلط استعمال ہے۔باقی نتائج آپ پر منحصر ہیں۔ ابھی بھی ایک احساس ہے کہ Docker+Kubernetes کے امتزاج کے لیے سسٹم کا "مرکزی" حصہ بننا آسان نہیں ہے۔ مثال کے طور پر، آپریٹنگ سسٹم پہلے ہارڈ ویئر پر انسٹال ہوتے ہیں، جس کے بارے میں کنٹینرز اور آرکیسٹریشن کے بارے میں نہیں کہا جا سکتا۔ شاید مستقبل میں، آپریٹنگ سسٹم اور کنٹینرز کلاؤڈ مینجمنٹ سوفٹ ویئر کے ساتھ ضم ہو جائیں گے۔
کی طرف سے تصویرمیں اس موقع کو اپنی والدہ کو سلام کہنے اور آپ کو یاد دلانا چاہوں گا کہ ہمارا ایک فیس بک گروپ ہے۔ ، چینل مختلف ٹیک بلاگز کی دلچسپ اشاعتوں کے ساتھ۔ اور میرا چینل جہاں میں پروڈکٹ کمپنیوں میں ترقی کے انتظام کے بارے میں بات کرتا ہوں۔
ماخذ: www.habr.com