هيلو سڀ! منهنجو نالو Pavel Agaletsky آهي. مان هڪ ٽيم ۾ هڪ ٽيم جي اڳواڻي طور ڪم ڪريان ٿو جيڪا لامودا پهچائڻ واري نظام کي ترقي ڪري ٿي. 2018 ۾، مون HighLoad ++ ڪانفرنس ۾ ڳالهايو، ۽ اڄ آئون پنهنجي رپورٽ جو نقل پيش ڪرڻ چاهيندس.

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

VM ڏانهن ايپليڪيشنن کي ترتيب ڏيڻ

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

اهو ڇا لاءِ هو؟

جڏهن اسان پنهنجي ايپليڪيشن جي نئين رليز کي ترتيب ڏني، اسان چاهيون ٿا ته هڪ بيحد رول آئوٽ کي يقيني بڻائي، اهو آهي، صارفين لاء قابل ذڪر نتيجن کان سواء. اهو حاصل ڪيو ويو ان حقيقت جي ڪري ته ايندڙ مرتب ڪيل رليز جوابي استعمال ڪندي دم تائين پهچايو ويو. اتي، جيڪي ماڻهو مقرري ۾ شامل هئا اهي چيڪ ڪري سگھن ٿا ۽ پڪ ڪري سگھن ٿا ته هر شي ٺيڪ آهي: سڀئي ميٽرڪ، سيڪشن ۽ ايپليڪيشنون ڪم ڪري رهيا هئا؛ ضروري اسڪرپٽ شروع ڪيا ويا آهن. صرف انهن کي يقين ڏياريو ويو ته سڀ ڪجهه ٺيڪ آهي، ٽرئفڪ کي تبديل ڪيو ويو. اهو سرور ڏانهن وڃڻ شروع ڪيو جيڪو اڳ ۾ دم هو. ۽ اهو جيڪو اڳي ئي سر هو صارف ٽرئفڪ کان سواءِ رهي ٿو، جڏهن ته اڃا تائين ان تي اسان جي ايپليڪيشن جو اڳوڻو نسخو آهي.

تنهنڪري اهو استعمال ڪندڙن لاء بيحد هو. ڇاڪاڻ ته سوئچنگ فوري آهي، ڇاڪاڻ ته اهو صرف بيلنس کي تبديل ڪري رهيو آهي. توھان تمام آساني سان واپس ڪري سگھوٿا پوئين ورزن ڏانھن صرف بيلنسر کي واپس سوئچ ڪندي. اسان پڻ تصديق ڪري سگھون ٿا ته ايپليڪيشن پيداوار جي قابل هئي ان کان اڳ جو اهو صارف ٽرئفڪ حاصل ڪري، جيڪو ڪافي آسان هو.

ان ۾ اسان کي ڪهڙا فائدا نظر آيا؟

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

پر اسان ان ۾ ڪيتريون ئي خاميون پڻ ڏٺيون:

1. پيداوار جي ماحول کان علاوه، ترقي جي ماحول، اتي ٻيا ماحول آهن. مثال طور، qa ۽ اڳڀرائي. ان وقت اسان وٽ ڪيترائي سرور هئا ۽ اٽڪل 60 خدمتون. ان لاءِ اهو ضروري هو هر خدمت لاءِ، ان لاءِ جديد نسخو برقرار رکو مجازي مشين. ان کان علاوه، جيڪڏهن توهان لائبريرين کي تازه ڪاري ڪرڻ يا نئين انحصار کي نصب ڪرڻ چاهيو ٿا، توهان کي اهو ڪرڻ جي ضرورت آهي سڀني ماحول ۾. توهان کي ان وقت کي هم وقت سازي ڪرڻ جي ضرورت آهي جڏهن توهان پنهنجي ايپليڪيشن جي ايندڙ نئين ورزن کي ان وقت سان ترتيب ڏيڻ وارا آهيو جڏهن ڊيوپس ضروري ماحول جي سيٽنگن کي انجام ڏئي ٿو. ان صورت ۾، اسان کي اهڙي صورتحال ۾ حاصل ڪرڻ آسان آهي جتي اسان جو ماحول هڪ ڀيرو سڀني ماحول ۾ ڪجهه مختلف هوندو. مثال طور، هڪ QA ماحول ۾ لائبريرين جا ڪجهه نسخا هوندا، ۽ پيداوار واري ماحول ۾ اتي مختلف هوندا، جيڪي مسئلا پيدا ڪندا.
2. انحصار کي اپڊيٽ ڪرڻ ۾ مشڪل توهان جي درخواست. اهو توهان تي نه، پر ٻي ٽيم تي منحصر آهي. يعني، ڊيوپس ٽيم مان جيڪو سرور کي برقرار رکي ٿو. توھان کي انھن کي ھڪڙو مناسب ڪم ۽ وضاحت ڏيڻ گھرجي جيڪو توھان ڪرڻ چاھيو ٿا.
3. ان وقت، اسان پڻ چاهيون ٿا ته اسان وٽ موجود وڏن وڏن مونولٿس کي الڳ الڳ ننڍن خدمتن ۾ ورهايو وڃي، ڇاڪاڻ ته اسان سمجهي رهيا هئاسين ته انهن مان وڌيڪ ۽ وڌيڪ هوندا. ان وقت، اسان وٽ اڳ ۾ ئي انهن مان 100 کان وڌيڪ هئا، هر نئين سروس لاء، هڪ الڳ نئين ورچوئل مشين ٺاهڻ ضروري هئي، جنهن کي پڻ برقرار رکڻ ۽ ترتيب ڏيڻ جي ضرورت هئي. ان کان سواء، توهان کي هڪ ڪار جي ضرورت ناهي، پر گهٽ ۾ گهٽ ٻه. انهي ۾ شامل ڪيو ويو آهي QA ماحول. اهو مسئلا پيدا ڪري ٿو ۽ توهان کي نئين سسٽم ٺاهڻ ۽ هلائڻ لاء وڌيڪ ڏکيو بڻائي ٿو. پيچيده، قيمتي ۽ ڊگهو عمل.

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

اسان ڪافي دير تائين سوچيو ته اسان کي ڪهڙو رستو وٺي سگهون ٿا. حقيقت اها آهي ته ان وقت باقاعده ورچوئل سرورز تي هي ڊيپلائيمينٽ اسٽيڪ ڪجهه پراڻو هو، ڇاڪاڻ ته انهن وٽ آپريٽنگ سسٽم جا جديد ورجن نه هئا. ڪجهه نقطي تي، اتي به FreeBSD هو، جيڪو سپورٽ ڪرڻ بلڪل آسان نه هو. اسان سمجھيو ته اسان کي جلد کان جلد ڊاکر ڏانھن لڏڻ جي ضرورت آھي. اسان جي ڊيوپس پنهنجي موجوده تجربي کي مختلف حلن سان ڏٺو ۽ چونڊيو هڪ نظام جهڙو Nomad.

تبديل ڪريو Nomad ۾

Nomad HashiCorp جي هڪ پيداوار آهي. اهي پڻ انهن جي ٻين حلن لاء مشهور آهن:

"قونصل" خدمت ڳولڻ لاء هڪ اوزار آهي.

"ٽرافارم" - سرورز کي منظم ڪرڻ لاءِ هڪ سسٽم جيڪو توهان کي انهن کي ترتيب ڏيڻ جي اجازت ڏئي ٿو ترتيب جي ذريعي، نام نهاد انفراسٽرڪچر-اي-ڪوڊ.

"گھمندڙ" توهان کي مجازي مشينن کي مقامي طور تي يا ڪلائوڊ ۾ مخصوص ڪنفيگريشن فائلن ذريعي ترتيب ڏيڻ جي اجازت ڏئي ٿي.

ان وقت Nomad هڪ بلڪل سادو حل وانگر لڳي ٿو جيڪو جلدي تبديل ٿي سگهي ٿو بغير مڪمل انفراسٽرڪچر کي تبديل ڪرڻ جي. ان کان سواء، اهو سکڻ بلڪل آسان آهي. ان ڪري اسان ان کي اسان جي ڪنٽينر لاءِ فلٽريشن سسٽم طور چونڊيو آهي.

توھان کي توھان جي سسٽم کي Nomad ڏانھن ترتيب ڏيڻ جي ضرورت آھي؟

1. سڀ کان پهرين توهان کي ضرورت آهي docker تصوير توهان جي درخواست. توھان کي ان کي تعمير ڪرڻ ۽ ان کي ڊاکر تصويري مخزن ۾ رکڻ جي ضرورت آھي. اسان جي حالت ۾، هي هڪ مصنوعي آهي - هڪ سسٽم جيڪو توهان کي اجازت ڏئي ٿو ته توهان کي مختلف قسمن جي مختلف نمونن کي ان ۾ ڌڪيو. اهو محفوظ ڪري سگھي ٿو آرڪائيو، ڊاکر تصويرون، ڪمپوزر پي ايڇ پي پيڪيجز، اين پي ايم پيڪيجز، وغيره.
2. پڻ گهربل configuration file، جيڪو Nomad کي ٻڌائيندو ته ڇا، ڪٿي ۽ ڪهڙي مقدار ۾ توهان کي لڳائڻ چاهيو ٿا.

جڏهن اسان Nomad جي باري ۾ ڳالهايون ٿا، اهو HCL ٻولي استعمال ڪري ٿو ان جي معلومات فائل فارميٽ جي طور تي، جيڪو بيٺو آهي HashiCorp ترتيب واري ٻولي. هي Yaml تي هڪ سپر سيٽ آهي جيڪو توهان کي اجازت ڏئي ٿو توهان جي خدمت کي بيان ڪرڻ لاءِ Nomad اصطلاحن ۾.

اهو توهان کي اهو چوڻ جي اجازت ڏئي ٿو ته توهان ڪيترا ڪنٽينر لڳائڻ چاهيو ٿا، جن مان تصويرون انهن کي ترتيب ڏيڻ دوران مختلف پيٽرولن کي منتقل ڪرڻ لاء. اهڙيء طرح، توهان هن فائل کي Nomad ڏانهن فيڊ ڪيو، ۽ اهو ڪنٽينرز کي ان جي مطابق پيداوار ۾ شروع ڪري ٿو.

اسان جي حالت ۾، اسان محسوس ڪيو ته هر خدمت لاء بلڪل هڪجهڙائي واري HCL فائلون لکڻ تمام آسان نه هوندا، ڇاڪاڻ ته اتي تمام گهڻيون خدمتون آهن ۽ ڪڏهن ڪڏهن توهان انهن کي اپڊيٽ ڪرڻ چاهيو ٿا. اهو ٿئي ٿو ته هڪ خدمت هڪ مثال ۾ نه، پر مختلف قسم جي مختلف قسمن ۾ ترتيب ڏني وئي آهي. مثال طور، ھڪڙو سسٽم جيڪو اسان وٽ پيداوار ۾ آھي، پيداوار ۾ 100 کان وڌيڪ مثال آھي. اهي ساڳيا تصويرن مان هلن ٿا، پر ترتيب جي سيٽنگن ۽ ترتيب واري فائلن ۾ مختلف آهن.

تنهن ڪري، اسان فيصلو ڪيو ته اهو اسان لاء آسان هوندو ته اسان جي سڀني ترتيبن جي فائلن کي ذخيرو ڪرڻ لاء هڪ عام مخزن ۾. هن طريقي سان اهي نظر اچن ٿا: اهي برقرار رکڻ آسان هئا ۽ اسان ڏسي سگهون ٿا ته اسان وٽ ڪهڙو نظام آهي. جيڪڏهن ضروري هجي ته، اهو پڻ آسان آهي تازه ڪاري ڪرڻ يا ڪجهه تبديل ڪرڻ. نئين سسٽم کي شامل ڪرڻ پڻ ڏکيو نه آهي - توهان کي صرف نئين ڊاريڪٽري اندر هڪ ترتيب واري فائيل ٺاهڻ جي ضرورت آهي. ان جي اندر ھيٺيون فائلون آھن: service.hcl، جنھن ۾ اسان جي خدمت جي وضاحت آھي، ۽ ڪجھ اين اين فائلون جيڪي ھن خدمت جي اجازت ڏين ٿيون، پيداوار ۾ مقرر ڪيل، ترتيب ڏيڻ جي.

تنهن هوندي، اسان جا ڪجهه سسٽم پيداوار ۾ ترتيب ڏنل آهن هڪ ڪاپي ۾ نه، پر ڪيترن ئي ۾ هڪ ڀيرو. تنهن ڪري، اسان اهو فيصلو ڪيو ته اهو اسان لاءِ آسان هوندو ته ترتيبن کي انهن جي خالص شڪل ۾ نه، پر انهن جي ٺهيل شڪل ۾. ۽ اسان چونڊيو جنجا 2. هن فارميٽ ۾، اسان پاڻ کي خدمت جي ٻنهي ترتيبن ۽ ان لاءِ گهربل اينف فائلون ذخيرو ڪندا آهيون.

ان کان علاوه، اسان مخزن ۾ رکيا آهن هڪ مقرري اسڪرپٽ سڀني منصوبن لاءِ عام آهي، جيڪا توهان کي اجازت ڏئي ٿي ته توهان جي خدمت کي پيداوار ۾، گهربل ماحول ۾، گهربل ٽارگيٽ ۾ لانچ ۽ ترتيب ڏيو. ان صورت ۾ جڏهن اسان پنهنجي HCL config کي ٽيمپليٽ ۾ تبديل ڪيو، ته پوء HCL فائل، جيڪا اڳ ۾ باقاعده Nomad config هئي، ان صورت ۾ ٿورو مختلف ڏسڻ شروع ڪيو.

اهو آهي، اسان ڪجهه ترتيب واري هنڌ جي متغيرن کي داخل ٿيل متغيرن سان تبديل ڪيو آهي جيڪي env فائلن يا ٻين ذريعن کان ورتو وڃي ٿو. ان کان علاوه، اسان کي متحرڪ طور تي HCL فائلن کي گڏ ڪرڻ جو موقعو مليو، اھو آھي، اسان استعمال ڪري سگھون ٿا نه رڳو عام متغير داخل ڪرڻ. جيئن ته جنجا لوپس ۽ حالتن کي سپورٽ ڪري ٿو، توهان اتي پڻ ٺاهي سگهو ٿا ڪنفيگريشن فائلون، جيڪي تبديل ٿين ٿيون ان تي منحصر آهي جتي توهان پنهنجي ايپليڪيشنن کي ترتيب ڏيو ٿا.

مثال طور، توھان چاھيو ٿا پنھنجي خدمت کي اڳ-پيداوار ۽ پيداوار لاءِ. اچو ته چئو ته اڳ-پيداوار ۾ توهان ڪرن اسڪرپٽ کي هلائڻ نٿا چاهيو، پر صرف هڪ الڳ ڊومين تي خدمت ڏسڻ چاهيو ٿا ته اهو ڪم ڪري رهيو آهي. هر ڪنهن لاءِ جيڪو خدمت کي ترتيب ڏئي ٿو، اهو عمل تمام سادو ۽ شفاف نظر اچي ٿو. توهان کي صرف deploy.sh فائل کي عمل ڪرڻ جي ضرورت آهي، بيان ڪريو ته توهان ڪهڙي خدمت کي ترتيب ڏيڻ چاهيو ٿا ۽ ڪهڙي حد تائين. مثال طور، توهان روس، بيلاروس يا قزاقستان ۾ هڪ خاص سسٽم کي ترتيب ڏيڻ چاهيو ٿا. هن کي ڪرڻ لاء، صرف هڪ پيٽرولر کي تبديل ڪريو، ۽ توهان وٽ صحيح ترتيب واري فائل هوندي.

جڏهن Nomad سروس اڳ ۾ ئي توهان جي ڪلستر تي لڳايو ويو آهي، اهو هن وانگر ڏسڻ ۾ اچي ٿو.

پهرين، توهان کي ٻاهران ڪجهه قسم جي بيلنس جي ضرورت آهي، جيڪو سڀني صارفن جي ٽرئفڪ حاصل ڪندو. اهو قونصل سان گڏ ڪم ڪندو ۽ ان مان معلوم ڪندو ته ڪٿي، ڪهڙي نوڊ تي، ڪهڙي IP پتي تي هڪ مخصوص سروس موجود آهي جيڪا ڪنهن خاص ڊومين جي نالي سان لاڳاپيل آهي. قونصل ۾ خدمتون Nomad کان ئي اچن ٿيون. جيئن ته اهي ساڳيا ڪمپني جون شيون آهن، اهي هڪ ٻئي سان ڪافي لاڳاپيل آهن. اسان اهو چئي سگهون ٿا ته باڪس کان ٻاهر Nomad قونصل اندر اندر شروع ڪيل سڀني خدمتن کي رجسٽر ڪري سگھن ٿا.

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

انساني وسيلن جي لحاظ کان منتقلي اسان کي ڪيترو خرچ ڪيو؟

Nomad کي سڄي ڪمپني جي منتقلي لڳ ڀڳ 5-6 مهينا گذري ويا. اسان خدمت جي بنياد تي خدمت جي بنياد تي منتقل ڪيو، پر ڪافي تيز رفتار سان. هر ٽيم کي خدمتن لاءِ پنهنجا ڪنٽينر ٺاهڻ گهرجن.

اسان هڪ اهڙو رويو اختيار ڪيو آهي ته هر ٽيم پنهنجي نظام جي ڊاکر تصويرن جي آزاديءَ سان ذميوار آهي. DevOps ترتيب ڏيڻ لاءِ ضروري بنيادي ڍانچي مهيا ڪن ٿا، يعني ڪلسٽر لاءِ سپورٽ، CI سسٽم لاءِ سپورٽ، وغيره. ۽ ان وقت، اسان وٽ 60 کان وڌيڪ سسٽم Nomad ڏانهن منتقل ڪيا ويا هئا، جيڪي اٽڪل 2 هزار ڪنٽينر هئا.

ڊيوپس ڊيوٽي ۽ سرور سان لاڳاپيل هر شي جي عام زيربنا لاء ذميوار آهي. ۽ هر ڊولپمينٽ ٽيم، موڙ ۾، پنهنجي مخصوص سسٽم لاءِ ڪنٽينرز کي لاڳو ڪرڻ جو ذميوار آهي، ڇو ته اها ٽيم آهي جيڪا ڄاڻي ٿي ته ان کي عام طور تي ڪنهن خاص ڪنٽينر ۾ ڪهڙي ضرورت آهي.

Nomad ڇڏڻ جا سبب

Nomad ۽ docker، ٻين جي وچ ۾ استعمال ڪندي مقرري تي سوئچ ڪرڻ سان اسان کي ڪهڙا فائدا حاصل ٿيا؟

1. Мы برابر شرطون ڏنيون سڀني ماحول لاء. ترقي ۾، QA ماحول، اڳ-پيداوار، پيداوار، ساڳئي ڪنٽينر تصويرون استعمال ٿيل آهن، ساڳئي انحصار سان. ان جي مطابق، توهان وٽ عملي طور تي ڪو به موقعو نه آهي ته پيداوار ۾ ڇا ختم ٿيندو اهو نه آهي جيڪو توهان اڳ ۾ مقامي طور تي يا توهان جي آزمائشي ماحول ۾ آزمايو آهي.
2. اسان کي پڻ معلوم ٿيو ته اهو ڪافي آهي نئين خدمت شامل ڪرڻ آسان. ترتيب ڏيڻ واري نقطي نظر کان، ڪنهن به نئين سسٽم کي تمام آسانيء سان شروع ڪيو ويو آهي. بس ان مخزن ڏانھن وڃو جيڪو ذخيرو ڪري ٿو configs، اتي توھان جي سسٽم لاءِ ٻيو ٺاھ ٺاھيو، ۽ توھان مڪمل طور تي تيار آھيو. توهان پنهنجي سسٽم کي ڊيوپس کان بغير ڪنهن اضافي ڪوشش جي پيداوار تي ترتيب ڏئي سگهو ٿا.
3. سڀ configuration فائلون هڪ عام ذخيرو ۾ جو جائزو ورتو ويو. ان وقت جڏهن اسان پنهنجي سسٽم کي ورچوئل سرور استعمال ڪندي ترتيب ڏنو، اسان Ansible استعمال ڪيو، جنهن ۾ ترتيبون ساڳئي مخزن ۾ هيون. بهرحال، اڪثر ڊولپرز لاءِ اهو ڪم ڪرڻ ۾ ٿورو وڌيڪ ڏکيو هو. هتي ترتيبن ۽ ڪوڊ جو مقدار جيڪو توهان کي خدمت کي ترتيب ڏيڻ لاءِ شامل ڪرڻ جي ضرورت آهي تمام ننڍو ٿي چڪو آهي. ان سان گڏ، ڊيوپس لاء ان کي درست ڪرڻ يا تبديل ڪرڻ تمام آسان آهي. منتقلي جي صورت ۾، مثال طور، Nomad جي نئين ورزن ڏانهن، اهي وٺي سگهن ٿا ۽ بلڪ اپڊيٽ ڪري سگهن ٿا سڀني آپريٽنگ فائلن کي ساڳئي جڳهه تي واقع.

پر اسان پڻ ڪيترن ئي نقصانن جو سامنا ڪيو:

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

اسان کي ڪجهه مليا ڪيڙا. سڀ کان اهم بگ اهو آهي ته Nomad هڪ وڏي ڪلستر کي چڱي طرح نه سنڀاليندو آهي جيڪڏهن توهان وٽ ڪيترائي سسٽم ۽ ڪنٽينر آهن. جڏھن توھان چاھيو ٿا ھڪڙو سرور ڪڍڻ لاءِ جيڪو Nomad ڪلستر ۾ شامل آھي سار سنڀال لاءِ، اتي تمام گھڻو امڪان آھي ته ڪلستر تمام سٺو محسوس نه ٿيندو ۽ ڌار ٿي ويندو. ڪجھ ڪنٽينر ٿي سگھي ٿو، مثال طور، زوال ۽ اڀرڻ نه - اھو توھان کي تمام گھڻو خرچ ڪندو بعد ۾ جيڪڏھن توھان جا سڀئي پروڊڪشن سسٽم ھڪڙي ڪلستر ۾ واقع آھن جيڪي Nomad پاران منظم ڪيل آھن.

تنهنڪري اسان اهو سوچڻ جو فيصلو ڪيو ته اسان کي اڳتي ڪٿي وڃڻ گهرجي. انهي نقطي تي، اسان گهڻو وڌيڪ واقف ٿي چڪا آهيون جيڪو اسان حاصل ڪرڻ چاهيون ٿا. يعني: اسان reliability چاهيون ٿا، Nomad مهيا ڪرڻ کان ٿورو وڌيڪ ڪم، ۽ هڪ وڌيڪ پختو، وڌيڪ مستحڪم نظام.

ان سلسلي ۾، اسان جي پسند Kubernetes تي ٿي وئي جيئن ڪلسٽرز کي لانچ ڪرڻ لاء سڀ کان وڌيڪ مشهور پليٽ فارم. خاص طور تي ڏنو ويو ته اسان جي ڪنٽينرز جي سائيز ۽ تعداد ڪافي وڏي هئي. اهڙين مقصدن لاء، ڪبرنيٽس سڀ کان وڌيڪ مناسب سسٽم لڳي ٿو جيڪو اسان ڏسي سگهون ٿا.

Kubernetes ڏانهن منتقلي

مان توهان کي ٿورڙو ٻڌايان ٿو ڪبرنيٽس جي بنيادي تصورن بابت ۽ اهي ڪيئن مختلف آهن Nomad کان.

سڀ کان پهريان، ڪبرنيٽس ۾ سڀ کان وڌيڪ بنيادي تصور پوڊ جو تصور آهي. پوڊ ھڪڙي يا وڌيڪ ڪنٽينرز جو ھڪڙو گروپ آھي جيڪو ھميشه گڏ ھلندو آھي. ۽ اهي هميشه ڪم ڪندا آهن ڄڻ ته اهي هميشه ساڳئي مجازي مشين تي سختي سان هئا. اهي مختلف بندرگاهن تي IP 127.0.0.1 ذريعي هڪ ٻئي تائين رسائي لائق آهن.

اچو ته فرض ڪريو ته توهان وٽ هڪ PHP ايپليڪيشن آهي جيڪا nginx ۽ php-fpm تي مشتمل آهي - کلاسک اسڪيم. گهڻو ڪري، توهان ٻنهي نينڪسڪس ۽ php-fpm ڪنٽينرز کي هر وقت گڏ رکڻ چاهيندا. ڪبرنيٽس توهان کي اهو حاصل ڪرڻ جي اجازت ڏئي ٿو انهن کي بيان ڪندي هڪ عام پوڊ. اهو ئي آهي جيڪو اسان Nomad سان حاصل نه ڪري سگهيا آهيون.

ٻيو تصور آهي نوڪريون. حقيقت اها آهي ته پوڊ پاڻ هڪ عارضي شيء آهي؛ اهو شروع ٿئي ٿو ۽ غائب ٿي وڃي ٿو. ڇا توھان چاھيو ٿا تہ پھريائين پنھنجي مڙني پوئين ڪنٽينر کي مارڻ، ۽ پوءِ ھڪ ئي وقت نوان ورجن لانچ ڪرڻ چاھيو ٿا، يا انھن کي بتدريج رول آئوٽ ڪرڻ چاھيو ٿا؟ اھو اھو عمل آھي جنھن لاءِ ڊپلائيمينٽ جو تصور ذميوار آھي. اهو بيان ڪري ٿو ته توهان پنهنجي پوڊ کي ڪيئن لڳايو، ڪهڙي مقدار ۾ ۽ انهن کي ڪيئن تازه ڪاري ڪجي.

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

۽ چوٿون بنيادي تصور آهي اندر اچڻ. هي هڪ خدمت آهي جيڪو ڪبرنيٽس ڪلستر تي هلندو آهي. اهو هڪ خارجي لوڊ بيلنس جي طور تي ڪم ڪري ٿو جيڪو سڀني درخواستن تي قبضو ڪري ٿو. ڪبرنيٽس API استعمال ڪندي، Ingress اهو طئي ڪري سگهي ٿو ته اهي درخواستون ڪٿي موڪلڻ گهرجن. ان کان سواء، هو اهو تمام لچڪدار طريقي سان ڪري ٿو. توهان اهو چئي سگهو ٿا ته هن ميزبان ڏانهن سڀئي درخواستون ۽ اهڙيون ۽ اهڙيون URL هن خدمت ڏانهن موڪليا ويا آهن. ۽ اهي درخواستون هن ميزبان ۽ ٻئي URL ڏانهن اچڻ واريون آهن ٻي خدمت ڏانهن.

ڪنهن ماڻهو جي نقطي نظر کان بهترين شيء جيڪو هڪ ايپليڪيشن ٺاهي ٿو اهو آهي ته توهان ان کي منظم ڪرڻ جي قابل آهيو. Ingress config کي ترتيب ڏيڻ سان، توھان موڪلي سگھو ٿا سمورو ٽريفڪ ايندڙ ايندڙ اهڙي ۽ اهڙي API ڏانهن الڳ ڪنٽينرز ڏانهن لکجي، مثال طور، Go ۾. پر هي ٽريفڪ، ساڳئي ڊومين تي اچڻ، پر هڪ مختلف URL ڏانهن، PHP ۾ لکيل ڪنٽينرز ڏانهن موڪليو وڃي، جتي تمام گهڻو منطق آهي، پر اهي تمام تيز نه آهن.

جيڪڏهن اسان انهن سڀني تصورن جو موازنہ Nomad سان ڪريون ٿا ته اسان چئي سگهون ٿا ته پهريان ٽي تصور سڀ گڏ آهن خدمت. ۽ آخري تصور خود Nomad ۾ غائب آهي. اسان هڪ خارجي بيلنس استعمال ڪيو جيئن ته: اهو ٿي سگهي ٿو هاپروڪس، نينڪس، نينڪس +، وغيره. ڪعبي جي صورت ۾، توهان کي هن اضافي تصور کي الڳ الڳ متعارف ڪرائڻ جي ضرورت ناهي. بهرحال، جيڪڏهن توهان اندروني طور تي Ingress تي نظر رکون ٿا، اهو يا ته نينڪس، هاپروڪس، يا ٽرافيڪ آهي، پر ڪبرنيٽس ۾ ٺهيل آهي.

سڀئي تصور جيڪي مون بيان ڪيا آهن، حقيقت ۾، وسيلا آهن جيڪي ڪبرنيٽس ڪلستر جي اندر موجود آهن. انھن کي ڪعبي ۾ بيان ڪرڻ لاء، ھڪڙو yml فارميٽ استعمال ڪيو ويندو آھي، جيڪو وڌيڪ پڙھڻ وارو ۽ واقف آھي HCL فائلن جي ڀيٽ ۾ Nomad جي صورت ۾. پر ڍانچي طور اهي ساڳيا شيءِ جي صورت ۾ بيان ڪن ٿا، مثال طور، پوڊ. چون ٿا ته، مان چاهيان ٿو ته اتي اهڙيون پوڊون، اهڙيون ۽ اهڙيون تصويرون، اهڙيون ۽ اهڙيون مقدار ۾.

ان کان علاوه، اسان اهو محسوس ڪيو ته اسان هر هڪ انفرادي وسيلن کي هٿ سان ٺاهڻ نٿا چاهيون: تعیناتي، خدمتون، داخلا، وغيره. ان جي بدران، اسان ڊيپلائيشن دوران ڪبرنيٽس جي لحاظ کان اسان جي هر سسٽم کي بيان ڪرڻ چاهيون ٿا، انهي ڪري ته اسان کي دستي طور تي صحيح ترتيب ۾ سڀني ضروري وسيلن جي انحصار کي ٻيهر ٺاهڻ جي ضرورت نه پوندي. هيلم کي سسٽم طور چونڊيو ويو جيڪو اسان کي ڪرڻ جي اجازت ڏني.

هيلم ۾ بنيادي تصورات

هيلم آهي پيڪيج مينيجر Kubernetes لاء. اهو بلڪل ساڳيو آهي ته ڪيئن پروگرامنگ ٻولين ۾ پيڪيج مينيجر ڪم ڪن ٿا. اهي توهان کي هڪ خدمت کي ذخيرو ڪرڻ جي اجازت ڏين ٿا، مثال طور، ترتيب ڏيڻ nginx، deployment php-fpm، config for Ingress، configmaps (هي هڪ ادارو آهي جيڪو توهان کي توهان جي سسٽم لاءِ env ۽ ٻيا پيرا ميٽر سيٽ ڪرڻ جي اجازت ڏئي ٿو) جي صورت ۾. چارٽ سڏيو ويندو آهي. ساڳئي وقت هيلم Kubernetes جي چوٽي تي هلندو آهي. اهو آهي، هي ڪنهن قسم جو سسٽم نه آهي جيڪو هڪ طرف بيٺو آهي، پر صرف هڪ ٻي خدمت ڪعب جي اندر شروع ڪئي وئي آهي. توهان ان سان رابطو ڪريو ان جي API ذريعي ڪنسول ڪمانڊ ذريعي. ان جي سهوليت ۽ خوبي اها آهي ته هيلم ٽوڙي يا ان کي ڪلسٽر مان هٽائي به توهان جون خدمتون غائب نه ٿينديون، ڇو ته هيلم بنيادي طور تي صرف سسٽم کي شروع ڪرڻ جو ڪم ڪندو آهي. Kubernetes خود وري ڪارڪردگي ۽ خدمتن جي حالت لاء ذميوار آهي.

اسان به اهو محسوس ڪيو ٽيمپليٽائيزيشن، جيڪو اسان اڳ ۾ ئي مجبور ٿي ويا هئاسين ته اسان جي ترتيبن ۾ جنجا متعارف ڪرايو، هيلم جي مکيه خاصيتن مان هڪ آهي. اهي سڀئي ترتيبون جيڪي توهان پنهنجي سسٽم لاءِ ٺاهيون آهن اهي ٽيمپليٽس جي صورت ۾ هيلم ۾ ذخيرو ٿيل آهن، جنجا سان ٿورو ملندڙ جلندڙ، پر حقيقت ۾، گو ٻولي جي ٽيمپليٽنگ کي استعمال ڪندي، جنهن ۾ هيلم لکيو ويو آهي، جهڙوڪ ڪبرنيٽس.

هيلم اسان لاءِ ڪجھ وڌيڪ تصور شامل ڪري ٿو.

چارٽ - هي توهان جي خدمت جي وضاحت آهي. ٻين پئڪيج مينيجرز ۾ ان کي سڏيو ويندو هڪ پيڪيج، بنڊل يا ڪجهه ساڳيو. هتي اهو چارٽ سڏيو ويندو آهي.

قدر اھي متغير آھن جيڪي توھان استعمال ڪرڻ چاھيو ٿا پنھنجي ترتيب کي ٽيمپليٽ مان ٺاھيو.

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

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

عملي طور تي، اسان ڪم ڪرڻ جو فيصلو ڪيو آهي ٿورو مختلف انداز سان جيڪو اسان Nomad سان ڪيو هو. جيڪڏهن Nomad ۾ ٻئي ترتيب ڏيڻ واريون ترتيبون ۽ n-variables جيڪي اسان جي خدمت کي ترتيب ڏيڻ لاءِ گهربل هئا هڪ مخزن ۾ ذخيرو ٿيل هئا، هتي اسان انهن کي ٻن الڳ مخزن ۾ ورهائڻ جو فيصلو ڪيو. "تعينيل" مخزن اسٽورن کي صرف n-متغيرن کي ترتيب ڏيڻ جي ضرورت آهي، ۽ "هيلم" مخزن اسٽورن کي ترتيب يا چارٽ.

هن اسان کي ڇا ڏنو؟

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

جيئن ته اسان وٽ نه رڳو پيداوار آهي، پر ٻيا ماحول پڻ آهن، انهي علحدگيءَ جي مهرباني، اسان پنهنجي هيلم چارٽس کي ٻيهر استعمال ڪري سگهون ٿا خدمتن کي نه رڳو پيداوار ۾، پر مثال طور، هڪ QA ماحول ڏانهن. جيتوڻيڪ انهن کي مقامي طور تي استعمال ڪرڻ لاء منيڪيوب - ھي آھي ھڪڙي شيءِ آھي ڪبرنيٽس کي مقامي طور تي هلائڻ لاءِ.

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

اسان هڪ ڊيپلائيمينٽ اسڪرپٽ ڇڏيو آهي - deploy.sh، جيڪو هيلم استعمال ڪندي ڊيپلائيمينٽ لاءِ لانچ کي آسان ۽ معياري بڻائي ٿو. تنهن ڪري، هر ڪنهن لاءِ جيڪو لڳائڻ چاهي ٿو، ڊيپلائيمينٽ انٽرفيس بلڪل ائين ئي نظر اچي ٿو جيئن اهو ڪيو ويو جڏهن Nomad ذريعي ترتيب ڏيڻ. ساڳيو deploy.sh، توهان جي خدمت جو نالو، ۽ جتي توهان ان کي لڳائڻ چاهيو ٿا. هي هيلم کي اندروني طور تي شروع ڪرڻ جو سبب بڻائيندو آهي. اهو، موڙ ۾، ٽيمپليٽس مان ترتيبن کي گڏ ڪري ٿو، انهن ۾ ضروري قدر فائلون داخل ڪري ٿو، پوء انهن کي ترتيب ڏئي ٿو، انهن کي ڪبرنيٽس ۾ لانچ ڪري ٿو.

پهچڻ

Kubernetes سروس Nomad کان وڌيڪ پيچيده لڳي ٿي.

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

جيئن اسان منتقلي ڪئي، اسان ڏٺو ته ڪبرنيٽس وٽ Nomad جون سڀئي صلاحيتون هيون، جيڪي اسان اڳ ۾ استعمال ڪيون هيون، ۽ ان سان گڏ ڪيتريون ئي نيون شيون شامل ڪيون هيون. اهو پلگ ان ذريعي وڌايو وڃي ٿو، ۽ حقيقت ۾ ڪسٽم وسيلن جي قسمن جي ذريعي. اهو آهي، توهان وٽ اهو موقعو آهي ته نه صرف ڪجهه استعمال ڪرڻ جو جيڪو ڪبرنيٽس سان گڏ اچي ٿو دٻي مان، پر پنهنجو پنهنجو وسيلو ۽ خدمت ٺاهڻ جو جيڪو توهان جي وسيلن کي پڙهي سگهندو. هي توهان کي اضافي اختيار ڏئي ٿو توهان جي سسٽم کي وڌائڻ لاءِ بغير ڪبرنيٽس کي ٻيهر انسٽال ڪرڻ ۽ بغير ڪنهن ترميم جي.

اهڙي استعمال جو هڪ مثال Prometheus آهي، جيڪو اسان جي ڪبرنيٽس ڪلستر جي اندر هلندو آهي. ڪنهن خاص خدمت مان ميٽرڪ گڏ ڪرڻ شروع ڪرڻ لاءِ، اسان کي ضرورت آهي هڪ اضافي قسم جو وسيلو، جنهن کي خدمت مانيٽر سڏيو وڃي ٿو، خدمت جي وضاحت ۾. Prometheus، حقيقت اها آهي ته اهو پڙهي سگهي ٿو هڪ ڪسٽم وسيلن جو قسم جڏهن شروع ڪيو ويو Kubernetes ۾، خودڪار طريقي سان نئين سسٽم مان ميٽرڪ گڏ ڪرڻ شروع ڪري ٿو. اهو ڪافي آسان آهي.

پهرين تعیناتي جيڪا اسان ڪبرنيٽس تي ڪئي هئي مارچ 2018 ۾. ۽ هن عرصي دوران اسان ڪڏهن به ان سان ڪنهن به پريشاني جو تجربو نه ڪيو. اهو ڪافي مستحڪم ڪم ڪري ٿو بغير ڪنهن اهم ڪيڙن جي. ان کان علاوه، اسان ان کي اڳتي وڌائي سگھون ٿا. اڄ اسان وٽ ڪافي صلاحيتون آهن، ۽ اسان واقعي پسند ڪندا آهيون ڪبرنيٽس جي ترقي جي رفتار. في الحال، 3000 کان وڌيڪ ڪنٽينرز Kubernetes ۾ آهن. ڪلستر ڪيترن ئي نوڊس تي قبضو ڪري ٿو. ساڳئي وقت، اهو قابل خدمت، مستحڪم ۽ تمام ڪنٽرول آهي.

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