هي تقرير جو نقل آهي и .
هي هڪ پروجيڪٽ جي ڪهاڻي آهي جنهن هڪ خود لکيل ترتيب واري انتظاماتي نظام کي استعمال ڪيو ۽ ڇو جوابي ڏانهن منتقل ٿيڻ ۾ 18 مهينا لڳي ويا.
ڏينهن نمبر - ХХХ: شروعات کان اڳ
شروعات ۾، انفراسٽرڪچر ڪيترن ئي جدا جدا ميزبانن تي مشتمل هو هائپر-وي هلائيندڙ. هڪ ورچوئل مشين ٺاهڻ لاءِ ڪيترن ئي قدمن جي ضرورت آهي: ڊسڪ کي صحيح جاءِ تي رکڻ ، DNS رجسٽر ڪرڻ ، DHCP محفوظ ڪرڻ ، وي ايم جي ترتيب کي گٽ مخزن ۾ رکڻ. اهو عمل جزوي طور تي ميزيڪل ڪيو ويو، پر مثال طور، VMs هٿ سان ميزبان جي وچ ۾ ورهايو ويو. پر، مثال طور، ڊولپرز گٽ ۾ VM ترتيب کي درست ڪري سگھن ٿا ۽ VM کي ريبوٽ ڪندي ان کي لاڳو ڪري سگھن ٿا.
ڪسٽم ترتيب واري انتظام جو حل
اصل خيال، مون کي شڪ آهي، IaC طور تصور ڪيو ويو هو: ڪيترائي بي رياست VM جيڪي ريبوٽ ٿيڻ تي پنهنجي رياست کي صفر تي ري سيٽ ڪن ٿا. VM ترتيب ڏيڻ جو انتظام ڇا هو؟ Schematically اهو سادو نظر اچي ٿو:
- هڪ جامد MAC وي ايم لاءِ بند ڪيو ويو.
- هڪ ISO سان CoreOS ۽ هڪ بوٽ ڊسڪ VM سان ڳنڍيل هئا.
- CoreOS ان جي IP جي بنياد تي WEB سرور تان ڊائون لوڊ ڪندي ڪسٽمائيزيشن اسڪرپٽ لانچ ڪري ٿو.
- اسڪرپٽ ڊائون لوڊ ڪري ٿو VM ترتيب SCP ذريعي IP پتي جي بنياد تي.
- سسٽمڊ يونٽ فائلن جو فوٽ ڪلوٿ ۽ بش اسڪرپٽ جو فوٽ ڪلوٿ شروع ڪيو ويو آهي.
هن حل ۾ ڪيترائي واضح مسئلا هئا:
- CoreOS ISO کي ختم ڪيو ويو آهي.
- ڪيترائي پيچيده خودڪار ڪارناما ۽ جادو جڏهن لڏپلاڻ / VMs ٺاهي رهيا آهن.
- تازه ڪاري ڪرڻ ۾ مشڪل ۽ جڏهن سافٽ ويئر جو هڪ خاص نسخو گهربل هجي. ڪنيل ماڊلز سان اڃا به وڌيڪ مزو.
- VMs ايتري قدر ڊيٽا کان سواء حاصل نه ڪيا ويا، يعني. VMs هڪ ڊسڪ سان گڏ اضافي صارف ڊيٽا سان گڏ ظاهر ٿيو.
- ڪو ماڻهو مسلسل سسٽمڊ يونٽ جي انحصار کي خراب ڪري رهيو هو ۽ ريبوٽ ڪرڻ وقت CoreOS منجمد ٿيندو. هن کي پڪڙڻ ڏکيو هو CoreOS ۾ موجود اوزار استعمال ڪندي.
- رازداري انتظام.
- ڪو به سي ايم نه هو. CoreOS لاءِ بيش ۽ YML ترتيبون هيون.
VM ٺاھ جوڙ کي لاڳو ڪرڻ لاء، توھان کي ان کي ريبوٽ ڪرڻ جي ضرورت آھي، پر اھو شايد ريبوٽ نه ٿي سگھي. اهو هڪ واضح مسئلو وانگر لڳي ٿو، پر اتي ڪا به مسلسل ڊسڪ نه آهي - لاگ محفوظ ڪرڻ لاء ڪٿي به ناهي. ٺيڪ آهي، اچو ته ڪوشش ڪريون شامل ڪرڻ جي ڪرنل لوڊنگ آپشن ته جيئن لاگ موڪليا وڃن. پر نه، اهو سڀ ڪجهه ڪيترو پيچيده آهي.
ڏينهن #0: مسئلو کي سڃاڻو
اها معمولي ترقي جي بنيادي ڍانچي هئي: جينڪنز، ٽيسٽ ماحول، نگراني، رجسٽري. CoreOS k8s ڪلستر جي ميزباني لاءِ ٺهيل هئي، يعني. مسئلو اهو هو ته CoreOS ڪيئن استعمال ڪيو ويو. پهريون قدم هڪ اسٽيڪ چونڊڻ هو. اسان تي آباد ٿيا:
- CentOS بنيادي تقسيم جي طور تي، ڇاڪاڻ ته هي پيداوار ماحول جي ويجھو تقسيم آهي.
- ناھي تشڪيل جي انتظام لاء، ڇاڪاڻ ته ان تي وسيع تحقيق ڪئي وئي.
- جينکن موجوده عملن کي خودڪار ڪرڻ لاء فريم ورڪ جي طور تي، ڇاڪاڻ ته اهو اڳ ۾ ئي فعال طور تي ترقي جي عملن لاء استعمال ڪيو ويو آهي
- هائپر-وي هڪ ورچوئلائيزيشن پليٽ فارم جي طور تي. اهڙا ڪيترائي سبب آهن جيڪي ڪهاڻي جي دائري کان ٻاهر آهن، پر مختصر ۾ - اسان بادل استعمال نٿا ڪري سگهون، اسان کي پنهنجو هارڊويئر استعمال ڪرڻ گهرجي.
ڏينهن نمبر 30: موجوده معاهدن کي درست ڪرڻ - ضابطن جي طور تي معاهدو
جڏهن اسٽيڪ صاف ٿي ويو، هلڻ جي تياري شروع ٿي. ڪوڊ جي صورت ۾ موجوده معاهدن کي درست ڪرڻ (ضابطن جي طور تي معاهدو!). منتقلي دستي ڪم -> مشيني ڪرڻ -> خودڪار.
1. VMs ترتيب ڏيو
جواب ڏيڻ وارو اهو هڪ وڏو ڪم ڪري ٿو. گھٽ ۾ گھٽ جسم جي تحريڪن سان توھان وٺي سگھوٿا VM ترتيبن جو ڪنٽرول:
- هڪ گٽ مخزن ٺاهيو.
- اسان فهرست ۾ VMs جي فهرست رکون ٿا، ترتيبن ۾ پلے بڪ ۽ ڪردار.
- اسان هڪ خاص جينڪن غلام قائم ڪري رهيا آهيون جنهن مان توهان جوابي هلائي سگهو ٿا.
- اسان هڪ نوڪري ٺاهي ۽ جينڪنز کي ترتيب ڏيو.
پهريون عمل تيار آهي. معاهدا طئي ٿيل آهن.
2. نئون VM ٺاهيو
هتي هر شيء بلڪل آسان نه هئي. لينڪس مان Hyper-V تي VMs ٺاهڻ بلڪل آسان ناهي. ھن عمل کي مشيني بڻائڻ جي ھڪڙي ڪوشش ھئي:
- Ansbile WinRM ذريعي ونڊوز ميزبان سان ڳنڍي ٿي.
- جوابي هڪ پاور شيل اسڪرپٽ هلائي ٿو.
- پاور شيل اسڪرپٽ هڪ نئون VM ٺاهي ٿو.
- Hyper-V/ScVMM استعمال ڪندي، مهمان OS ۾ VM ٺاهڻ وقت، ميزبان جو نالو ترتيب ڏنل آهي.
- DHCP ليز کي اپڊيٽ ڪرڻ وقت، VM موڪلي ٿو پنهنجو ميزبان نالو.
- ڊومين ڪنٽرولر پاسي تي معياري ddns ۽ dhcp انضمام DNS رڪارڊ کي ترتيب ڏئي ٿو.
- توھان شامل ڪري سگھوٿا VM پنھنجي انوینٽري ۾ ۽ ان کي ترتيب ڏيو جوابي سان.
3. VM ٽيمپليٽ ٺاهيو
انهن هتي ڪا به ايجاد نه ڪئي آهي - انهن هڪ پيڪر ورتو.
- پيڪر شامل ڪريو، kickstart config کي گٽ مخزن ۾.
- هائپر-وي ۽ پيڪر سان گڏ هڪ خاص جينڪن غلام کي ترتيب ڏيڻ.
- اسان هڪ نوڪري ٺاهي ۽ جينڪنز کي ترتيب ڏيو.
هي لنڪ ڪيئن ڪم ڪري ٿو:
- پيڪر هڪ خالي VM ٺاهي ٿو ۽ ISO کي کڻندو آهي.
- VM بوٽ، Packer اسان جي ڪڪ اسٽارٽ فائل کي فلاپي ڊسڪ يا http مان استعمال ڪرڻ لاءِ بوٽ لوڊر ۾ حڪم داخل ڪري ٿو.
- ايناڪونڊا اسان جي ترتيب سان شروع ڪئي وئي آهي، ۽ شروعاتي OS ترتيب ڏنل آهي.
- پيڪر انتظار ڪري ٿو VM دستياب ٿيڻ لاءِ.
- VM اندر پيڪر مقامي موڊ ۾ جوابي هلندو آهي.
- جواب ڏيڻ وارو ساڳيو ڪردار استعمال ڪري ٿو جيڪو اهو ڪم ڪري ٿو قدم # 1 ۾.
- پيڪر برآمد ڪري ٿو VM ٽيمپليٽ.
ڏينهن #75: معاهدي کي ٽوڙڻ کان سواءِ ريفيڪٽر = ٽيسٽ جوابي + ٽيسٽ ڪيچن
ڪوڊ ۾ ڪنوينشن کي پڪڙڻ ڪافي نه ٿي سگھي. آخرڪار، جيڪڏهن عمل جي اندر ۽ ٻاهران توهان ڪجهه تبديل ڪرڻ چاهيو ٿا، توهان ڪجهه ٽوڙي سگهو ٿا. تنهن ڪري، انفراسٹرڪچر جي صورت ۾، هن بنيادي زيربنا جي جانچ ظاهر ٿئي ٿي. ٽيم جي اندر علم کي هم وقت سازي ڪرڻ لاءِ، اسان جوابي ڪردار جي جاچ شروع ڪئي. مان اونهائي ۾ نه ويندس ڇاڪاڻ ته ... اتي ھڪڙو مضمون آھي جيڪو ان وقت جي واقعن کي بيان ڪري ٿو (اسپائلر اهو حتمي نسخو نه هو ۽ بعد ۾ سڀ ڪجهه وڌيڪ پيچيده ٿي ويو ).
ڏينهن # 130: ٿي سگهي ٿو CentOS + جواب ڏيڻ جي ضرورت ناهي؟ شايد اوپن شفٽ؟
اسان کي اهو سمجهڻ گهرجي ته انفراسٽرڪچر کي متعارف ڪرائڻ جو عمل صرف هڪ نه هو ۽ ضمني سب پروجيڪٽ هئا. مثال طور، اسان جي ايپليڪيشن کي اوپن شفٽ ۾ لانچ ڪرڻ لاءِ هڪ درخواست آئي ۽ ان جي نتيجي ۾ هڪ هفتي کان وڌيڪ تحقيق ٿي جيڪو حرڪت واري عمل کي سست ڪري ٿو. نتيجو اهو نڪتو ته اوپن شفٽ سڀني ضرورتن کي پورو نٿو ڪري؛ توهان کي حقيقي هارڊويئر جي ضرورت آهي، يا گهٽ ۾ گهٽ ڪنييل سان راند ڪرڻ جي صلاحيت.
ڏينهن #170: Openshift مناسب ناهي، اچو ته Windows Azure Pack سان هڪ موقعو وٺون؟
Hyper-V تمام دوستانه نه آهي، SCVMM ان کي وڌيڪ بهتر نٿو بڻائي. پر اتي ھڪڙي شيء آھي Windows Azure Pack، جيڪو ھڪڙو اضافو آھي SCVMM ۽ Azure کي نقل ڪري ٿو. پر حقيقت ۾، پراڊڪٽ ڇڏيل نظر اچي ٿو: دستاويز ٽوڙيا ويا آهن لنڪ ۽ تمام گهٽ آهن. پر اسان جي بادل جي زندگي کي آسان ڪرڻ لاء اختيارن جي مطالعي جي حصي جي طور تي، انهن کي پڻ ڏٺو.
ڏينهن #250: ونڊوز ايزور پيڪ تمام سٺو ناهي. اسان SCVMM تي رهون ٿا
Windows Azure Pack واعدو ڪندڙ نظر آيو، پر اھو فيصلو ڪيو ويو ته WAP کي پنھنجي پيچيدگين سان سسٽم ۾ نه آڻڻ لاءِ غير ضروري خصوصيتن جي ڪري ۽ SCVMM سان رھيو.
ڏينهن # 360: هاٿيءَ جو ٽڪر ٽڪر ٽڪر کائڻ
صرف هڪ سال بعد منتقل ڪرڻ لاء پليٽ فارم تيار ٿي ويو ۽ حرڪت وارو عمل شروع ٿي ويو. هن مقصد لاء، هڪ SMART ڪم مقرر ڪيو ويو. اسان سڀني VMs کي چڪاس ڪيو ۽ ھڪڙي ھڪڙي ترتيب کي ترتيب ڏيڻ شروع ڪيو، ان کي جواب ۾ بيان ڪيو، ۽ ان کي ٽيسٽ سان ڍڪيو.
ڏينهن #450: توهان ڪهڙي قسم جو نظام حاصل ڪيو؟
عمل پاڻ کي دلچسپ نه آهي. اهو معمول آهي، اهو نوٽ ڪري سگهجي ٿو ته گهڻيون ترتيبون نسبتاً سادو يا isomorphic هيون ۽ Pareto اصول جي مطابق، VM ترتيبن جو 80٪ 20٪ وقت جي ضرورت آهي. ساڳئي اصول موجب، وقت جو 80٪ هلڻ جي تياري ۾ خرچ ڪيو ويو ۽ صرف 20٪ پاڻ هلڻ تي.
ڏينهن #540: فائنل
18 مهينن ۾ ڇا ٿيو؟
- معاهدو هڪ ڪوڊ بڻجي ويو.
- دستي ڪم -> مشيني ڪرڻ -> خودڪار.
لنڪس
جو ذريعو: www.habr.com