ڇا ڊيٽابيس ڪبرنيٽس ۾ رهن ٿا؟

ڪنهن به طرح، تاريخي طور تي، آئي ٽي صنعت ٻن مشروط ڪيمپن ۾ ورهايل آهي ڪنهن به سبب لاء: اهي جيڪي آهن "لاء" ۽ جيڪي آهن "خلاف". ان کان سواء، تڪرار جو موضوع مڪمل طور تي خودمختياري ٿي سگهي ٿو. ڪهڙو او ايس بهتر آهي: ون يا لينڪس؟ هڪ Android يا iOS اسمارٽ فون تي؟ ڇا توھان کي بادلن ۾ ھر شيء کي ذخيرو ڪرڻ گھرجي يا ان کي ٿڌي RAID اسٽوريج تي رکڻ گھرجي ۽ اسڪرو کي محفوظ ۾ رکڻ گھرجي؟ ڇا پي ايڇ پي وارن کي پروگرامر سڏجڻ جو حق آهي؟ اهي تڪرار، ڪڏهن ڪڏهن، فطرت ۾ خاص طور تي موجود آهن ۽ راندين جي دلچسپي کان سواء ٻيو ڪو به بنياد نه آهي.

بس ائين ئي ٿيو آهي ته ڪنٽينرز جي آمد سان ۽ هي تمام پيارو کاڌو ڊاکر ۽ مشروط k8s سان، بحث مباحثو "لاء" ۽ "مخالف" پس منظر جي مختلف علائقن ۾ نئين صلاحيتن جي استعمال شروع ٿي. (اچو ته اڳ ۾ هڪ رزرويشن ڪريون ته جيتوڻيڪ هن بحث ۾ ڪبرنيٽس اڪثر ڪري هڪ آرڪيسٽرٽر جي طور تي اشارو ڪيو ويندو، هن خاص اوزار جي چونڊ بنيادي اهميت جي ناهي. ان جي بدران، توهان ڪنهن ٻئي کي متبادل ڪري سگهو ٿا جيڪو توهان لاء تمام آسان ۽ واقف هجي. .)

۽، اهو لڳي ٿو، اهو ساڳيو سکين جي ٻن پاسن جي وچ ۾ هڪ سادي تڪرار هوندو. Win vs Linux جي وچ ۾ دائمي تصادم وانگر بي حس ۽ بي رحم، جنهن ۾ وچ ۾ ڪافي ماڻهو موجود آهن. پر ڪنٽينرائيزيشن جي صورت ۾، هر شيء بلڪل سادو ناهي. عام طور تي اهڙين تڪرارن ۾ ڪو به ساڄي طرف نه هوندو آهي، پر ڊيٽابيس کي ذخيرو ڪرڻ لاء "استعمال" يا "استعمال نه ڪريو" ڪنٽينرز جي صورت ۾، هر شيء الٽي ٿي ويندي آهي. ڇاڪاڻ ته هڪ خاص لحاظ کان ان روش جا حامي ۽ مخالف ٻئي حق تي آهن.

روشن طرف

لائيٽ سائڊ جو دليل مختصر طور تي ھڪڙي جملي ۾ بيان ڪري سگھجي ٿو: "ھيلو، 2k19 ونڊو کان ٻاھر آھي!" اهو آواز پاپولزم وانگر آهي، يقينا، پر جيڪڏهن توهان تفصيل سان صورتحال کي ڳوليندا آهيو، ان جا فائدا آهن. اچو ته انهن کي هاڻي ترتيب ڏيو.

اچو ته توهان وٽ هڪ وڏو ويب پروجيڪٽ آهي. اهو شروعاتي طور تي هڪ مائڪرو سروس جي طريقي جي بنياد تي تعمير ڪيو ويو هجي، يا ڪنهن نقطي تي اهو ارتقائي رستي ذريعي آيو هو - حقيقت ۾ اهو تمام ضروري ناهي. توهان اسان جي پروجيڪٽ کي جدا جدا microservices ۾ ورهايو، آرڪيسٽريشن قائم ڪريو، لوڊ بيلنسنگ، ۽ اسڪيلنگ. ۽ ھاڻي، ھڪ صاف ضمير سان، توھان ھيماڪ ۾ ھڪڙو موجيٽو sip ڪريو ھبرا اثرات دوران گريل سرور کي وڌائڻ بدران. پر سڀني عملن ۾ توهان کي مسلسل هجڻ گهرجي. گهڻو ڪري، صرف ايپليڪيشن پاڻ - ڪوڊ - ڪنٽينر ٿيل آهي. اسان وٽ ڪوڊ کان سواءِ ٻيو ڇا آهي؟

اهو صحيح آهي، ڊيٽا. ڪنهن به منصوبي جي دل ان جي ڊيٽا آهي: اهو يا ته هڪ عام DBMS ٿي سگهي ٿو - MySQL، Postgre، MongoDB، يا ڳولها لاءِ استعمال ٿيل اسٽوريج (ElasticSearch)، ڪيشنگ لاءِ ڪي-ويل اسٽوريج - مثال طور، ريڊيس وغيره. في الحال اسان نه آهيون. اسان خراب پس منظر تي عمل درآمد جي اختيارن جي باري ۾ ڳالهائينداسين جڏهن ڊيٽابيس خراب طور تي لکيل سوالن جي ڪري خراب ٿئي ٿي، ۽ ان جي بدران اسان ڪلائنٽ لوڊ هيٺ هن ڊيٽابيس جي غلطي رواداري کي يقيني بڻائڻ بابت ڳالهائينداسين. آخرڪار، جڏهن اسان پنهنجي ايپليڪيشن کي ڪنٽرول ڪريون ٿا ۽ ان کي آزاديءَ سان ماپڻ جي اجازت ڏيون ٿا ته ڪنهن به ايندڙ درخواستن تي عمل ڪرڻ لاءِ، اهو قدرتي طور تي ڊيٽابيس تي لوڊ وڌائي ٿو.

حقيقت ۾، ڊيٽابيس تائين رسائي حاصل ڪرڻ لاء چينل ۽ سرور جنهن تي اهو هلندو آهي، اسان جي خوبصورت ڪنٽينر ٿيل پس منظر ۾ سوئي جي اک بڻجي وڃي ٿي. ساڳئي وقت، ڪنٽينر جي ورچوئلائيزيشن جو بنيادي مقصد ساخت جي متحرڪ ۽ لچڪ آهي، جيڪا اسان کي ممڪن طور تي ممڪن طور تي اسان وٽ موجود سموري انفراسٽرڪچر ۾ چوٽي جي لوڊ جي ورڇ کي منظم ڪرڻ جي اجازت ڏئي ٿي. اهو آهي، جيڪڏهن اسان ڪلستر ۾ سسٽم جي سڀني موجود عناصر کي ڪنٽرول ۽ رول نه ڪندا آهيون، اسان هڪ تمام سنگين غلطي ڪري رهيا آهيون.

اهو تمام گهڻو منطقي آهي ڪلستر ڪرڻ لاءِ نه رڳو ايپليڪيشن پاڻ، پر ڊيٽا کي محفوظ ڪرڻ لاءِ ذميوار خدمتون پڻ. ويب سرورز کي ڪلستر ڪرڻ ۽ ترتيب ڏيڻ سان جيڪي آزاد طور تي ڪم ڪن ٿا ۽ لوڊ پاڻ ۾ k8s ۾ تقسيم ڪن ٿا، اسان اڳ ۾ ئي ڊيٽا جي هم وقت سازي جو مسئلو حل ڪري رهيا آهيون - پوسٽن تي ساڳيا تبصرا، جيڪڏهن اسان مثال طور ڪجهه ميڊيا يا بلاگ پليٽ فارم وٺون ٿا. ڪنهن به صورت ۾، اسان وٽ هڪ اندروني ڪلستر آهي، جيتوڻيڪ مجازي، ڊيٽابيس جي نمائندگي هڪ ExternalService طور. سوال اهو آهي ته ڊيٽابيس پاڻ اڃا ڪلستر ٿيل نه آهي - ڪعب ۾ مقرر ڪيل ويب سرور اسان جي جامد جنگي ڊيٽابيس مان تبديلين بابت معلومات وٺن ٿا، جيڪو الڳ الڳ گھمندو آهي.

ڇا توهان هڪ پڪڙي محسوس ڪيو؟ اسان لوڊ کي ورهائڻ ۽ مکيه ويب سرور کي تباهه ڪرڻ کان بچڻ لاءِ k8s يا Swarm استعمال ڪندا آهيون، پر اسان اهو ڊيٽابيس لاءِ نه ڪندا آهيون. پر جيڪڏهن ڊيٽابيس حادثو ٿئي ٿي، ته پوء اسان جو سڄو ڪلستر ٿيل انفراسٽرڪچر ڪو احساس نه ٿو ڪري - ڇا سٺو آهن خالي ويب صفحا جيڪي ڊيٽابيس جي رسائي جي غلطي کي واپس ڪن ٿا؟

انهي ڪري اهو ضروري آهي ته نه رڳو ويب سرورز کي ڪلستر ڪرڻ، جيئن عام طور تي ڪيو ويندو آهي، پر ڊيٽابيس جي انفراسٽرڪچر کي پڻ. صرف هن طريقي سان اسان هڪ اهڙي جوڙجڪ کي يقيني بڻائي سگهون ٿا جيڪو مڪمل طور تي هڪ ٽيم ۾ ڪم ڪري ٿو، پر ساڳئي وقت هڪ ٻئي کان آزاد. ان کان علاوه، جيتوڻيڪ اسان جي پسمنظر جو اڌ حصو "گرجي" لوڊ هيٺ، باقي بچندو، ۽ ڪلستر جي اندر ڊيٽابيس کي هڪ ٻئي سان هم وقت سازي ڪرڻ جو نظام ۽ نئين ڪلستر کي ختم ڪرڻ ۽ ترتيب ڏيڻ جي صلاحيت جلدي گهربل گنجائش تائين پهچڻ ۾ مدد ڪندي. جيڪڏهن صرف ڊيٽا سينٽر ۾ ريڪ هئا.

ان کان علاوه، ڪلسٽرز ۾ ورهايل ڊيٽابيس جو ماڊل توهان کي اجازت ڏئي ٿو ته هي تمام ڊيٽابيس وٺي وڃي جتي اها ضرورت هجي؛ جيڪڏهن اسان هڪ گلوبل سروس جي باري ۾ ڳالهائي رهيا آهيون، ته اهو بلڪل غير منطقي آهي ويب ڪلستر کي ڪنهن هنڌ سان فرانسسڪو جي علائقي ۾ گھمڻ ۽ ساڳئي وقت ماسڪو علائقي ۽ پوئتي ۾ ڊيٽابيس تائين رسائي ڪرڻ دوران پيڪيٽ موڪليندا.

انهي سان گڏ، ڊيٽابيس جي ڪنٽينرائيزيشن توهان کي سسٽم جي سڀني عناصر کي تعمير ڪرڻ جي اجازت ڏئي ٿي ساڳئي سطح تي تجريد. جيڪو، موڙ ۾، اهو ممڪن بڻائي ٿو ته هن سسٽم کي سڌو سنئون ڪوڊ مان، ڊولپرز طرفان، منتظمين جي فعال شموليت کان سواء. ڊولپر سوچيو ته نئين سب پروجيڪٽ لاءِ الڳ DBMS جي ضرورت هئي - آسان! هڪ yaml فائل لکيو، ان کي ڪلستر تي اپ لوڊ ڪيو ۽ توهان ڪيو آهي.

۽ يقينا، اندروني آپريشن تمام آسان آهي. مون کي ٻڌايو، توهان ڪيترا ڀيرا پنهنجون اکيون بند ڪيون آهن جڏهن هڪ نئين ٽيم ميمبر ڪم لاء جنگي ڊيٽابيس ۾ پنهنجا هٿ رکيا آهن؟ جيڪو، حقيقت ۾، صرف هڪ ئي آهي جيڪو توهان وٽ آهي ۽ في الحال گھمائي رهيو آهي؟ يقينن، اسان سڀ هتي بالغ آهيون، ۽ ڪٿي اسان وٽ هڪ تازو بيڪ اپ آهي، ۽ اڃا به پري - دادي جي ڪڪڙين ۽ پراڻي اسڪيز سان گڏ شيلف جي پويان - هڪ ٻيو بيڪ اپ، شايد شايد کولڊ اسٽوريج ۾، ڇو ته توهان جي آفيس اڳ ۾ ئي هڪ ڀيرو باهه ٿي چڪي هئي. پر اهو سڀ ڪجهه، نئين ٽيم جي ميمبر جو هر تعارف جنگي بنيادي ڍانچي تائين رسائي سان ۽ يقيناً، جنگي ڊيٽابيس تائين هر ڪنهن لاءِ صحيح جي بالٽ آهي. چڱو، هن کي ڪير ڄاڻي ٿو، هڪ نئون، ٿي سگهي ٿو ته هو پار هٿ آهي؟ اهو خوفناڪ آهي، توهان متفق آهيو.

ڪنٽينرائيزيشن ۽، حقيقت ۾، توهان جي پروجيڪٽ جي ڊيٽابيس جي ورهايل فزيڪل ٽوپولوجي اهڙي صحيح لمحن کان بچڻ ۾ مدد ڪري ٿي. هڪ نئون ماڻهو تي اعتبار نه ڪريو؟ ٺيڪ آهي! اچو ته هن کي پنهنجو ڪلسٽر ڏيون ڪم ڪرڻ لاءِ ۽ ڊيٽابيس کي ٻين ڪلسٽرن کان ڌار ڪرڻ لاءِ - هم وقت سازي صرف دستي پش ۽ هم وقت سازي جي گردش ذريعي ٻن ڪنجين جي (هڪ ٽيم جي اڳواڻي لاءِ، ٻيو منتظم لاءِ). ۽ هرڪو خوش آهي.

۽ هاڻي اهو وقت آهي ڊيٽابيس ڪلسترنگ جي مخالفن ۾ تبديل ڪرڻ.

اونداھون رخ

بحث ڪرڻ ڇو ته اهو قابل ناهي ته ڊيٽابيس کي ڪنٽينر ڪرڻ ۽ ان کي هڪ مرڪزي سرور تي هلائڻ جاري رکڻ، اسان قدامت پسندن جي بيانن ۽ بيانن تي نه جهڪنداسين جهڙوڪ "دادا هارڊ ويئر تي ڊيٽابيس هلائيندا هئا، ۽ ائين ئي ڪنداسين!" ان جي بدران، اچو ته هڪ اهڙي صورتحال سان گڏ اچڻ جي ڪوشش ڪريو جنهن ۾ ڪنٽينرائيزيشن اصل ۾ قابل منافعو ادا ڪندي.

اتفاق ڪريو، اهي منصوبا جن کي واقعي هڪ ڪنٽينر ۾ بنيادي ضرورت آهي، هڪ هٿ جي آڱرين تي ڳڻپ ڪري سگهجي ٿو نه بهترين ملنگ مشين آپريٽر طرفان. گهڻو ڪري، جيتوڻيڪ k8s يا Docker Swarm جو استعمال به بيڪار آهي - اڪثر ڪري اهي اوزار استعمال ڪيا ويندا آهن ٽيڪنالاجي جي عام هائيپ جي ڪري ۽ صنف جي فرد ۾ ”الله تعاليٰ“ جي رويي جي ڪري هر شيءِ کي دٻائڻ لاءِ. بادل ۽ ڪنٽينر. خير، ڇاڪاڻ ته هاڻي اهو فيشن آهي ۽ هرڪو اهو ڪندو آهي.

گھٽ ۾ گھٽ اڌ ڪيسن ۾، ڪبرنيٽس يا صرف ڊاڪر استعمال ڪندي ھڪڙي منصوبي تي بيڪار آھي. مسئلو اهو آهي ته ڪلائنٽ جي انفراسٽرڪچر کي برقرار رکڻ لاءِ رکيل سڀئي ٽيمون يا آئوٽ سورسنگ ڪمپنيون هن کان واقف آهن. اهو وڌيڪ خراب آهي جڏهن ڪنٽينر لاڳو ڪيا ويا آهن، ڇاڪاڻ ته اهو ڪلائنٽ لاء هڪ خاص رقم سکن جي قيمت آهي.

عام طور تي، اتي هڪ راء آهي ته ڊاکر / ڪيوب مافيا بيوقوف طور تي گراهڪن کي کچلڻ وارا آهن جيڪي انهن انفراسٽرڪچر جي مسئلن کي آئوٽ سورس ڪن ٿا. سڀ کان پوء، ڪلستر سان ڪم ڪرڻ لاء، اسان کي انجنيئرن جي ضرورت آهي جيڪي هن جي قابل آهن ۽ عام طور تي لاڳو ٿيل حل جي فن تعمير کي سمجھندا آهن. اسان هڪ ڀيرو اڳ ۾ ئي بيان ڪيو آهي اسان جو ڪيس ريپبلڪ پبليڪيشن سان - اتي اسان ڪلائنٽ جي ٽيم کي تربيت ڏني ته ڪبرنيٽس جي حقيقتن ۾ ڪم ڪري، ۽ هرڪو مطمئن هو. ۽ اهو مهذب هو. گهڻو ڪري، k8s "تطبيق ڪندڙ" ڪلائنٽ جي انفراسٽرڪچر کي يرغمال بڻائيندا آهن - ڇاڪاڻ ته هاڻي صرف اهي سمجهن ٿا ته هر شي اتي ڪيئن ڪم ڪري ٿي؛ ڪلائنٽ جي پاسي تي ڪو به ماهر ناهي.

هاڻي تصور ڪريو ته هن طريقي سان اسان نه رڳو ويب سرور جو حصو، پر ڊيٽابيس جي سار سنڀال پڻ. اسان چيو ته BD دل آهي، ۽ دل جو نقصان ڪنهن به جاندار لاء موتمار آهي. مختصر ۾، امڪان بهترين نه آهن. تنهن ڪري، hype Kubernetis جي بدران، ڪيترن ئي منصوبن کي صرف AWS لاء عام ٽريف سان پريشان نه ڪرڻ گهرجي، جيڪو انهن جي سائيٽ / پروجيڪٽ تي لوڊ سان سڀني مسئلن کي حل ڪندو. پر AWS هاڻي فيشن وارو ناهي، ۽ شو آف پئسن کان وڌيڪ قيمتي آهن - بدقسمتي سان، آئي ٽي ماحول ۾ پڻ.

ٺيڪ. شايد پراجيڪٽ کي واقعي ڪلسٽرنگ جي ضرورت آهي، پر جيڪڏهن بي رياست ايپليڪيشنن سان سڀ ڪجهه واضح آهي، ته پوءِ اسان ڪلسٽر ٿيل ڊيٽابيس لاءِ مهذب نيٽ ورڪ ڪنيڪشن کي ڪيئن منظم ڪري سگهون ٿا؟

جيڪڏهن اسان هڪ بيحد انجنيئرنگ حل جي باري ۾ ڳالهائي رهيا آهيون، جيڪو k8s ڏانهن منتقلي آهي، پوء اسان جو بنيادي سر درد آهي ڊيٽا جي نقل هڪ ڪلستر ٿيل ڊيٽابيس ۾. ڪجھ DBMSs شروعاتي طور تي پنھنجي انفرادي مثالن جي وچ ۾ ڊيٽا جي ورڇ لاء ڪافي وفادار آھن. ٻيا به ڪيترا نه خوش آمديد آهن. ۽ اڪثر ڪري اسان جي پروجيڪٽ لاءِ ڊي بي ايم ايس چونڊڻ ۾ بنيادي دليل گهٽ ۾ گهٽ وسيلن ۽ انجنيئرنگ جي خرچن سان نقل ڪرڻ جي صلاحيت ناهي. خاص طور تي جيڪڏهن منصوبي جي شروعات ۾ هڪ microservice جي طور تي رٿابندي نه ڪئي وئي هئي، پر صرف هن هدايت ۾ ترقي ڪئي.

اسان سوچيو ته نيٽ ورڪ ڊرائيو جي رفتار بابت ڳالهائڻ جي ڪا ضرورت ناهي - اهي سست آهن. اهي. اسان وٽ اڃا تائين حقيقي موقعو نه آهي، جيڪڏهن ڪجهه ٿئي ٿي، هڪ DBMS مثال کي ٻيهر شروع ڪرڻ لاء ڪٿي ڪٿي وڌيڪ آهي، مثال طور، پروسيسر پاور يا مفت رام. اسان تمام جلدي ورچوئلائزڊ ڊسڪ سبسسٽم جي ڪارڪردگي ۾ هلنداسين. ان جي مطابق، ڊي بي ايم ايس کي ويجهڙائي ۾ واقع مشينن جي پنهنجي ذاتي سيٽ تي بند ڪيو وڃي. يا اهو ضروري آهي ته ڪنهن به طرح الڳ الڳ ٿڌو ڪرڻ لاء ڪافي تيز ڊيٽا هم وقت سازي جي ذخيري لاء.

ورچوئل فائل سسٽم جي موضوع کي جاري رکڻ: ڊاکر حجم، بدقسمتي سان، مسئلا آزاد نه آهن. عام طور تي، اهڙي معاملي ۾ ڊگهي مدت جي قابل اعتماد ڊيٽا اسٽوريج، مان چاهيان ٿو ته سڀ کان وڌيڪ ٽيڪنالاجي سادي اسڪيمن سان. ۽ ڪنٽينر جي FS کان والدين ميزبان جي FS ۾ نئين تجريدي پرت شامل ڪرڻ پاڻ ۾ هڪ خطرو آهي. پر جڏهن ڪنٽينرائيزيشن سپورٽ سسٽم جو آپريشن به انهن پرتن جي وچ ۾ ڊيٽا کي منتقل ڪرڻ ۾ مشڪلاتن کي منهن ڏئي ٿو، پوء اهو واقعي هڪ آفت آهي. هن وقت، ترقي پسند انسانيت جا اڪثر مسئلا ختم ٿي چڪا آهن. پر توهان سمجھو ٿا، وڌيڪ پيچيده ميڪانيزم، اهو آسانيء سان ڀڃي ٿو.

انهن سڀني ”ايڊونچرز“ جي روشنيءَ ۾، ڊيٽابيس کي هڪ جاءِ تي رکڻ تمام گهڻو فائديمند ۽ آسان آهي، ۽ جيتوڻيڪ جيڪڏهن توهان کي ايپليڪيشن کي ڪنٽينر ڪرڻ جي ضرورت آهي، ته ان کي پاڻ هلائڻ ڏيو ۽ ڊسٽريبيوشن گيٽ وي ذريعي هڪ ئي وقت رابطو حاصل ڪري. ڊيٽابيس، جيڪو صرف هڪ ڀيرو ۽ هڪ جڳهه تي پڙهي ۽ لکيو ويندو. اهو طريقو گهٽ ۾ گهٽ غلطين جي امڪان کي گھٽائي ٿو ۽ غير مطابقت پذير ڪرڻ.

اسان ڪهڙي طرف وڃي رهيا آهيون؟ ان کان علاوه، ڊيٽابيس ڪنٽينرائزيشن مناسب آهي جتي ان جي حقيقي ضرورت آهي. توهان نه ٿا ڪري سگهو هڪ مڪمل-ايپ ڊيٽابيس ۽ ان کي گھمايو ڄڻ ته توهان وٽ ٻه درجن مائڪرو سروسز آهن - اهو انهي طريقي سان ڪم نٿو ڪري. ۽ اهو واضح طور تي سمجهڻ گهرجي.

پيداوار بدران بدران

جيڪڏھن توھان انتظار ڪري رھيا آھيو واضح نتيجي لاءِ ”ڊيٽابيس کي ورچوئل ڪرڻ يا نه،“ ته پوءِ اسان توھان کي مايوس ڪنداسين: اھو ھتي نه ھوندو. ڇاڪاڻ ته جڏهن ڪو به بنيادي ڍانچو حل ٺاهيو وڃي ته، ڪنهن کي فيشن ۽ ترقيءَ جي طرف نه، پر، سڀ کان پهرين، عام فهم جي رهنمائي ڪرڻ گهرجي.

اهڙا منصوبا آهن جن لاءِ اصول ۽ اوزار جيڪي ڪبرنيٽس سان گڏ ايندا آهن بلڪل مناسب آهن، ۽ اهڙن منصوبن ۾ گهٽ ۾ گهٽ پسمانده علائقي ۾ امن آهي. ۽ اهڙا منصوبا آهن جن کي ڪنٽينرائيزيشن جي ضرورت ناهي، پر هڪ عام سرور انفراسٽرڪچر، ڇاڪاڻ ته اهي بنيادي طور تي مائڪرو سروس ڪلستر ماڊل کي ٻيهر نه ٿا ڪري سگهن، ڇاڪاڻ ته اهي گر ٿيندا.

جو ذريعو: www.habr.com