.NET ڪور لينڪس تي، DevOps گھوڙي تي

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

هن طرح ڪهاڻي شروع ٿئي ٿي اليگزينڊررا سنچينووا تي DevOpsConf. جڏهن ونڊوز جي معروف ماهر ڪمپني ڇڏي، اليگزينڊر حيران ٿي ويو ته هاڻي ڇا ڪجي. لينڪس ڏانهن وڃو، يقينا! اليگزينڊر توهان کي ٻڌائيندو ته هن ڪيئن هڪ مثال ٺاهي ۽ ونڊوز ڊولپمينٽ جو حصو لينڪس ڏانهن منتقل ڪيو، مثال طور 100 آخري صارفين لاءِ مڪمل ٿيل منصوبي جو مثال استعمال ڪندي.

.NET ڪور لينڪس تي، DevOps گھوڙي تي

TFS، Puppet، Linux .NET core استعمال ڪندي پروجيڪٽ کي RPM تائين آساني ۽ آسانيءَ سان ڪيئن پهچايو؟ پروجيڪٽ ڊيٽابيس جي ورزننگ کي ڪيئن سپورٽ ڪجي جيڪڏهن ڊولپمينٽ ٽيم پهريون ڀيرو Postgres ۽ Flyway لفظ ٻڌي ٿي، ۽ آخري تاريخ سڀاڻي کان پوءِ آهي؟ Docker سان ڪيئن ضم ٿي؟ ڪيئن .NET ڊولپرز کي حوصلا افزائي ڪرڻ لاء Windows ۽ smoothies کي پپٽ ۽ لينڪس جي حق ۾ ڇڏڻ لاء؟ جيڪڏهن پيداوار ۾ ونڊوز کي برقرار رکڻ لاءِ نه طاقت، نه خواهش، نه وسيلا آهن ته نظرياتي تڪرار ڪيئن حل ڪجي؟ ان بابت، گڏوگڏ ويب ڊيپلائي، ٽيسٽنگ، CI بابت، موجوده منصوبن ۾ TFS استعمال ڪرڻ جي طريقن جي باري ۾، ۽ يقينا، ٽوٽل ڪچين ۽ ڪم ڪندڙ حلن بابت، اليگزينڊر جي رپورٽ جي نقل ۾.


تنهن ڪري، واسيا ڇڏي، ڪم مون تي آهي، ڊولپرز بي صبري سان پچ فورڪ سان انتظار ڪري رهيا آهن. جڏهن مون آخرڪار محسوس ڪيو ته واسيا واپس نه ٿي سگهيا، مون کي ڪاروبار ڪرڻ لڳو. شروع ڪرڻ سان، مون اسان جي بيبي ۾ Win VMs جو سيڪڙو اندازو ڪيو. سکور ونڊوز جي حق ۾ نه هو.

.NET ڪور لينڪس تي، DevOps گھوڙي تي

جيئن ته اسان فعال طور تي ترقي ڪري رهيا آهيون DevOps، مون محسوس ڪيو ته نئين ايپليڪيشن پهچائڻ جي انداز ۾ ڪجهه تبديل ٿيڻ جي ضرورت آهي. هتي صرف هڪ حل هو - جيڪڏهن ممڪن هجي، هر شي کي لينڪس ڏانهن منتقل ڪريو. گوگل منهنجي مدد ڪئي - ان وقت .Net اڳ ۾ ئي لينڪس ڏانهن پورٽ ڪيو ويو هو، ۽ مون محسوس ڪيو ته اهو حل هو!

ڇو .NET ڪور لينڪس سان گڏ؟

ان جا ڪيترائي سبب هئا. وچ ۾ "پيسا ادا ڪريو" ۽ "ادا نه ڪريو"، اڪثريت ٻيو چونڊيندو - مون وانگر. MSDB لاءِ لائسنس جي قيمت اٽڪل $1 آهي؛ ونڊوز ورچوئل مشينن جي فليٽ کي برقرار رکڻ ۾ سوين ڊالر خرچ اچن ٿا. هڪ وڏي ڪمپني لاء اهو هڪ وڏو خرچ آهي. هن ڪري بچائڻ - پهريون سبب. سڀ کان اهم نه، پر هڪ اهم آهي.

ونڊوز ورچوئل مشينون پنهنجي لينڪس ڀائرن کان وڌيڪ وسيلا کڻنديون آهن. اهي ڳري آهن. وڏي ڪمپني جي پيماني تي، اسان چونڊيو لينڪس.

سسٽم صرف موجوده CI ۾ ضم ٿي ويو آهي. اسان پاڻ کي ترقي پسند DevOps سمجهون ٿا، اسان بانس، جينڪنز ۽ GitLab CI استعمال ڪندا آهيون، تنهنڪري اسان جو گهڻو ڪم لينڪس تي هلندو آهي.

آخري سبب آهي آسان ساٿي. اسان کي ”اسڪارٽس“ جي داخلا ۾ رڪاوٽ کي گهٽائڻ جي ضرورت هئي - اهي ماڻهو جيڪي ٽيڪنيڪل حصي کي سمجهن ٿا، بي ترتيب سروس کي يقيني بڻائين ٿا، ۽ خدمتن کي سيڪنڊ لائين کان برقرار رکن ٿا. اهي پهريان ئي لينڪس اسٽيڪ کان واقف هئا، تنهنڪري انهن لاءِ نئين پراڊڪٽ کي سمجهڻ، سپورٽ ڪرڻ ۽ برقرار رکڻ تمام آسان آهي ونڊوز پليٽ فارم لاءِ سافٽ ويئر جي ساڳي ڪارڪردگي کي سمجهڻ لاءِ اضافي وسيلا خرچ ڪرڻ کان.

گه

پهريون ۽ اهم ترين - ڊولپرز لاء نئين حل جي سهولت. اهي سڀئي تبديليءَ لاءِ تيار نه هئا، خاص ڪري لفظ لينڪس ڳالهائڻ کان پوءِ. ڊولپرز پنهنجي پسنديده Visual Studio چاهيون ٿا، TFS آٽو ٽيسٽ سان گڏ اسيمبلين ۽ smoothies لاءِ. پيداوار تائين پهچائڻ ڪيئن انهن لاءِ اهم ناهي. تنهن ڪري، اسان فيصلو ڪيو ته معمولي عمل کي تبديل نه ڪيو وڃي ۽ ونڊوز ڊولپمينٽ لاءِ هر شيءِ کي تبديل نه ڪيو وڃي.

نئين منصوبي جي ضرورت آهي موجوده CI ۾ ضم. ريلون اڳ ۾ ئي موجود هيون ۽ سمورو ڪم ڪنفيگريشن مئنيجمينٽ سسٽم، قبول ٿيل ترسيل معيار ۽ مانيٽرنگ سسٽم جي اصولن کي مدنظر رکندي ڪيو وڃي.

سپورٽ ۽ آپريشن جو آسان، مختلف ڊويزنن ۽ سپورٽ ڊپارٽمينٽ مان سڀني نون شرڪت ڪندڙن لاءِ گھٽ ۾ گھٽ داخلا جي حد جي شرط جي طور تي.

آخري تاريخ - ڪالهه.

ون ڊولپمينٽ گروپ

ان وقت ونڊوز ٽيم ڇا ڪم ڪري رهي هئي؟

.NET ڪور لينڪس تي، DevOps گھوڙي تي

هاڻي مان يقين سان چئي سگهان ٿو سڃاڻپ سرور4 ADFS لاءِ هڪ بهترين مفت متبادل آهي ساڳين صلاحيتن سان، يا ڇا ادارو فريم ورڪ ڪور - هڪ ڊولپر لاءِ جنت، جتي توهان کي SQL اسڪرپٽ لکڻ جي تڪليف نه ڪرڻي آهي، پر ڊيٽابيس ۾ سوالن کي OOP اصطلاحن ۾ بيان ڪريو. پر پوءِ، ايڪشن پلان جي بحث دوران، مون هن اسٽيڪ کي ڏٺو ڄڻ ته اهو سميرين ڪينيفارم هو، صرف پوسٽ گري ايس ايس ايل ۽ گٽ کي سڃاڻي ٿو.

ان وقت اسان فعال طور تي استعمال ڪري رهيا هئاسين بيوقوف هڪ ترتيب جي انتظام جي نظام جي طور تي. اسان جي اڪثر منصوبن ۾ اسان استعمال ڪيو گٽ لاب سي, جڌهن, متوازن اعلي لوڊ خدمتون استعمال ڪندي HAProxy سان هر شيء جي نگراني ڪئي زيبڪس, ligaments گرافانا и Prometheus, جهانگر۽ اهو سڀ ڪجهه لوهه جي ٽڪرن تي ڦري رهيو هو HPاي ايس ايڪس آئي تي VMware. هرڪو اهو ڄاڻي ٿو - صنف جو هڪ کلاسک.

.NET ڪور لينڪس تي، DevOps گھوڙي تي

اچو ته ڏسون ۽ سمجهڻ جي ڪوشش ڪريون ته ڇا ٿي رهيو هو ان کان اڳ اسان انهن سڀني مداخلتن کي شروع ڪيو.

ڇا ٿيو

TFS هڪ انتهائي طاقتور سسٽم آهي جيڪو نه صرف ڊولپر کان فائنل پروڊڪشن مشين تائين ڪوڊ پهچائي ٿو، پر مختلف خدمتن سان تمام لچڪدار انضمام لاءِ هڪ سيٽ پڻ آهي - هڪ ڪراس پليٽ فارم سطح تي CI مهيا ڪرڻ لاءِ.

.NET ڪور لينڪس تي، DevOps گھوڙي تي
اڳي، اهي مضبوط ونڊوز هئا. TFS ڪيترائي بلڊ ايجنٽ استعمال ڪيا، جيڪي ڪيترن ئي منصوبن کي گڏ ڪرڻ لاء استعمال ڪيا ويا. هر ايجنٽ وٽ 3-4 ڪارڪن آهن ڪمن کي برابر ڪرڻ ۽ عمل کي بهتر ڪرڻ لاءِ. پوء، جاري ڪيل منصوبن جي مطابق، TFS تازو پڪل بلڊ کي ونڊوز ايپليڪيشن سرور تي پهچايو.

اسان ڇا حاصل ڪرڻ چاهيون ٿا؟

اسان ترسيل ۽ ترقي لاءِ TFS استعمال ڪريون ٿا، ۽ ايپليڪيشن کي لينڪس ايپليڪيشن سرور تي هلائيندا آهيون، ۽ انهن جي وچ ۾ ڪجهه قسم جو جادو آهي. هي جادو باڪس ۽ اڳيان ڪم جو لوڻ آهي. ان کان اڳ جو آئون ان کي ڌار ڪريان، مان هڪ قدم هڪ طرف وٺي ويندس ۽ ايپليڪيشن جي باري ۾ ڪجهه لفظ چوندس.

پروجيڪٽ

ائپليڪيشن پريپيڊ ڪارڊ کي سنڀالڻ لاءِ ڪارڪردگي مهيا ڪري ٿي.

.NET ڪور لينڪس تي، DevOps گھوڙي تي

مختاران مائي

صارفين جا ٻه قسم هئا. پهرين SSL SHA-2 سرٽيفڪيٽ استعمال ڪندي لاگ ان ٿيڻ سان رسائي حاصل ڪئي. يو سيڪنڊ جو لاگ ان ۽ پاسورڊ استعمال ڪندي رسائي هئي.

HAProxy

پوءِ ڪلائنٽ جي درخواست HAProxy ڏانهن وئي، جنهن هيٺ ڏنل مسئلا حل ڪيا:

  • ابتدائي اختيار؛
  • SSL ختم ڪرڻ؛
  • ٽيوننگ HTTP درخواستون؛
  • نشر ڪرڻ جون درخواستون.

ڪلائنٽ سرٽيفڪيٽ زنجير سان گڏ تصديق ڪئي وئي. اسان - دليل ۽ اسان هن کي برداشت ڪري سگهون ٿا، ڇو ته اسان پاڻ کي خدمت جي گراهڪن کي سرٽيفڪيٽ جاري ڪندا آهيون.

ٽئين نقطي تي ڌيان ڏيو، اسان ٿوري دير کان پوء واپس ڪنداسين.

Backend

انهن لينڪس تي پس منظر ٺاهڻ جو منصوبو ٺاهيو. پس منظر ڊيٽابيس سان رابطو ڪري ٿو، استحقاق جي ضروري لسٽ لوڊ ڪري ٿو ۽ پوءِ، ان تي منحصر ڪري ٿو ته بااختيار صارف کي ڪهڙا استحقاق آهن، مالي دستاويزن تي دستخط ڪرڻ ۽ انهن کي عمل لاءِ موڪلڻ جي رسائي فراهم ڪري ٿو، يا ڪنهن قسم جي رپورٽ ٺاهي ٿو.

HAProxy سان بچت

ٻن مقصدن کان علاوه جيڪي هر ڪلائنٽ نيويگيٽ ڪيو، اتي پڻ هڪ سڃاڻپ جي حوالي سان هو. سڃاڻپ سرور4 صرف توهان کي لاگ ان ڪرڻ جي اجازت ڏئي ٿي، هي هڪ مفت ۽ طاقتور اينالاگ لاء آهي ADFS - فعال ڊاريڪٽري فيڊريشن سروسز.

سڃاڻپ جي درخواست تي عمل ڪيو ويو ڪيترن ئي مرحلن ۾. پهريون قدم - گراهڪ پس منظر ۾ داخل ٿيو، جنهن هن سرور سان رابطو ڪيو ۽ ڪلائنٽ لاءِ ٽوڪن جي موجودگي جي جانچ ڪئي. جيڪڏهن اهو نه مليو، ته درخواست واپس ان حوالي سان واپس ڪئي وئي جنهن مان اهو آيو هو، پر هڪ ريڊائريڪٽ سان، ۽ ريڊائريڪٽ سان اهو سڃاڻپ ڏانهن ويو.

ٻيو قدم - درخواست ملي وئي IdentityServer ۾ اجازت ڏيڻ واري صفحي ڏانهن، جتي ڪلائنٽ رجسٽر ٿيو، ۽ اھو ڊگھي انتظار جو ٽوڪن IdentityServer ڊيٽابيس ۾ ظاهر ٿيو.

ٽيون قدم - ڪلائنٽ کي واپس موڪليو ويو ان حوالي سان جنهن مان اهو آيو آهي.

.NET ڪور لينڪس تي، DevOps گھوڙي تي

IdentityServer4 هڪ خاصيت آهي: اهو واپسي جي درخواست جو جواب واپس ڏئي ٿو HTTP ذريعي. ڪو مسئلو ناهي ته اسان سرور کي ترتيب ڏيڻ سان ڪيترو به جدوجهد ڪئي، ڪابه پرواهه ناهي ته اسان پاڻ کي دستاويزن سان ڪيترو روشن ڪيو، هر ڀيري اسان کي URL سان گڏ هڪ ابتدائي ڪلائنٽ جي درخواست ملي ٿي جيڪا HTTPS ذريعي آئي، ۽ IdentityServer ساڳئي حوالي سان واپس آيو، پر HTTP سان. اسان حيران ٿي ويا هئاسين! ۽ اسان هي سڀ سڃاڻپ جي حوالي سان HAProxy ڏانهن منتقل ڪيو، ۽ هيڊرز ۾ اسان کي HTTP پروٽوڪول کي HTTPS ڏانهن تبديل ڪرڻو پوندو.

بهتري ڇا آهي ۽ توهان ڪٿي بچايو؟

اسان استعمال ڪندڙن، وسيلن جي هڪ گروپ کي اختيار ڏيڻ لاءِ مفت حل استعمال ڪندي پئسا بچايو، ڇاڪاڻ ته اسان IdentityServer4 کي الڳ نوڊ طور هڪ الڳ حصي ۾ نه رکيو آهي، پر ان کي ساڳئي سرور تي پس منظر سان گڏ استعمال ڪيو آهي جتي ايپليڪيشن جو پس منظر هلندو آهي. .

اهو ڪيئن ڪم ڪرڻ گهرجي

تنهن ڪري، جيئن مون واعدو ڪيو - جادو باڪس. اسان اڳ ۾ ئي سمجهون ٿا ته اسان کي لينڪس ڏانهن منتقل ڪرڻ جي ضمانت ڏني وئي آهي. اچو ته مخصوص ڪم ٺاھيون جن کي حل ڪرڻ جي ضرورت آھي.

.NET ڪور لينڪس تي، DevOps گھوڙي تي

پوپٽ ظاهر ٿئي ٿو. سروس ۽ ايپليڪيشن جي ترتيب کي پهچائڻ ۽ منظم ڪرڻ لاء، ٿڌي ترڪيبون لکڻيون پونديون هيون. پنسل جو هڪ رول فصاحت سان ڏيکاري ٿو ته اهو ڪيترو جلدي ۽ موثر طريقي سان ڪيو ويو.

پهچائڻ جو طريقو. معيار RPM آهي. هرڪو سمجهي ٿو ته لينڪس ۾ توهان ان کان سواء نٿا ڪري سگهو، پر اهو منصوبو پاڻ، اسيمبليء کان پوء، قابل عمل ڊي ايل ايل فائلن جو هڪ سيٽ هو. انهن مان اٽڪل 150 هئا، پراجيڪٽ ڪافي ڏکيو هو. صرف هم آهنگ حل اهو آهي ته هن بائنري کي RPM ۾ پيڪيج ڪيو وڃي ۽ ان مان ايپليڪيشن کي ترتيب ڏيو.

ورجن ڪرڻ. اسان کي گهڻو ڪري ڇڏڻو پوندو هو، ۽ اسان کي فيصلو ڪرڻو پوندو هو ته پيڪيج جو نالو ڪيئن ٺاهيو وڃي. هي TFS سان انضمام جي سطح جو سوال آهي. اسان وٽ لينڪس تي هڪ بلڊ ايجنٽ هو. جڏهن TFS هڪ هينڊلر - ورڪر - بلڊ ايجنٽ ڏانهن هڪ ٽاسڪ موڪلي ٿو، اهو پڻ ان کي منتقل ڪري ٿو متغير جو هڪ گروپ جيڪو هينڊلر جي عمل جي ماحول ۾ ختم ٿئي ٿو. انهن ماحوليات ۾ شامل آهن تعمير جو نالو، نسخي جو نالو، ۽ ٻيا متغير. ان بابت وڌيڪ پڙهو ”بلڊنگ اين آر پي ايم پيڪيج“ سيڪشن ۾.

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

سڃاڻپ سرور. ADFS اسان جو طريقو ناهي، اسان اوپن سورس لاءِ وڃي رهيا آهيون.

اچو ته اجزاء ذريعي وڃو.

جادو باڪس

چئن حصن تي مشتمل آهي.

.NET ڪور لينڪس تي، DevOps گھوڙي تي

لينڪس بلڊ ايجنٽ. لينڪس، ڇاڪاڻ ته اسان ان لاء ٺاهي رهيا آهيون - اهو منطقي آهي. اهو حصو ٽن مرحلن ۾ ڪيو ويو.

  • ڪارڪنن کي ترتيب ڏيو ۽ اڪيلو نه، ڇو ته منصوبي تي ورهايل ڪم جي توقع ڪئي وئي هئي.
  • انسٽال ڪريو .NET ڪور 1.x. ڇو 1.x جڏهن 2.0 اڳ ۾ ئي معياري مخزن ۾ موجود آهي؟ ڇاڪاڻ ته جڏهن اسان ترقي شروع ڪيو، مستحڪم نسخو 1.09 هو، ۽ اهو فيصلو ڪيو ويو ته منصوبي کي ان جي بنياد تي ٺاهيو وڃي.
  • گٽ 2.x.

RPM- مخزن. RPM پيڪيجز کي ڪٿي رکڻ جي ضرورت آهي. اهو فرض ڪيو ويو هو ته اسان ساڳيو ڪارپوريٽ RPM مخزن استعمال ڪنداسين جيڪو سڀني لينڪس ميزبانن لاءِ موجود آهي. ائين ئي ڪيائون. مخزن سرور ترتيب ڏنو آهي ويب ڇِڪ جنهن مخصوص هنڌ تان گهربل RPM پيڪيج ڊائون لوڊ ڪيو. پيڪيج ورزن کي رپورٽ ڪيو ويو ويب هوڪ کي بلڊ ايجنٽ طرفان.

گٽ لاب. ڌيان! GitLab هتي ڊولپرز طرفان استعمال نه ڪيو ويو آهي، پر آپريشن ڊپارٽمينٽ پاران ايپليڪيشن ورزن، پيڪيج ورزن کي ڪنٽرول ڪرڻ، سڀني لينڪس مشينن جي صورتحال جي نگراني ڪرڻ لاء، ۽ اهو نسخو محفوظ ڪري ٿو - سڀ پپٽ ظاهر ڪري ٿو.

بيوقوف - سڀني تڪراري مسئلن کي حل ڪري ٿو ۽ بلڪل ترتيب ڏئي ٿو جيڪا اسان Gitlab کان چاهيون ٿا.

اسان ٻڏڻ شروع ڪريون ٿا. RPM ڏانهن DLL پهچائڻ ڪيئن ڪم ڪندو آهي؟

پهچائڻ DDL کي RPM

اچو ته اسان وٽ ھڪڙو .NET ڊولپمينٽ راڪ اسٽار آھي. اهو بصري اسٽوڊيو استعمال ڪري ٿو ۽ رليز برانچ ٺاهي ٿو. ان کان پوء، اهو ان کي Git تي اپ لوڊ ڪري ٿو، ۽ Git هتي هڪ TFS ادارو آهي، اهو آهي، اهو ايپليڪيشن مخزن آهي جنهن سان ڊولپر ڪم ڪري ٿو.

.NET ڪور لينڪس تي، DevOps گھوڙي تي

جنهن کان پوءِ TFS ڏسي ٿو ته هڪ نئون عهدو آيو آهي. ڪهڙي ائپ؟ TFS سيٽنگون ۾ ھڪڙو ليبل آھي جيڪو ظاھر ڪري ٿو ته ڪھڙا وسيلا ھڪڙي خاص بلڊ ايجنٽ وٽ آھن. انهي حالت ۾، هو ڏسي ٿو ته اسان هڪ .NET ڪور پروجيڪٽ ٺاهي رهيا آهيون ۽ پول مان هڪ لينڪس بلڊ ايجنٽ چونڊيو.

بلڊ ايجنٽ ذريعن کي وصول ڪري ٿو ۽ ضروري ڊائون لوڊ ڪري ٿو انحصار مان .NET مخزن، npm، وغيره. ۽ ايپليڪيشن ٺاهڻ کان پوءِ ۽ بعد ۾ پيڪنگنگ، RPM پيڪيج کي RPM مخزن ڏانهن موڪلي ٿو.

ٻئي طرف، هيٺيان ٿئي ٿو. آپريشن ڊپارٽمينٽ انجنيئر سڌو سنئون منصوبي جي رول آئوٽ ۾ ملوث آهي: هو پيڪيجز جي ورزن کي تبديل ڪري ٿو هيرا مخزن ۾ جتي اپليڪيشن جي ترڪيب محفوظ ڪئي وئي آهي، جنهن کان پوء Puppet triggers Yum, repository مان نئون پيڪيج آڻيندو، ۽ ايپليڪيشن جو نئون نسخو استعمال ڪرڻ لاء تيار آهي.

.NET ڪور لينڪس تي، DevOps گھوڙي تي

لفظن ۾ سڀ ڪجھ سادو آهي، پر بلڊ ايجنٽ جي اندر ڇا ٿئي ٿو؟

پيڪيجنگ DLL RPM

حاصل ڪيل پروجيڪٽ جا ذريعا ۽ TFS کان ڪم تعمير ڪريو. ٺاھيندڙ ايجنٽ پروجيڪٽ پاڻ کي ذريعن کان تعمير ڪرڻ شروع ڪري ٿو. گڏ ڪيل پروجيڪٽ هڪ سيٽ جي طور تي دستياب آهي DLL فائلون، جيڪي فائل سسٽم تي لوڊ گهٽائڻ لاءِ زپ آرڪائيو ۾ پيڪ ٿيل آهن.

زپ آرڪائيو اڇلائي ڇڏيو آهي RPM پيڪيج بلڊ ڊاريڪٽري ڏانهن. اڳيون، بش اسڪرپٽ ماحول جي متغيرن کي شروع ڪري ٿو، تعمير جو نسخو ڳولي ٿو، پروجيڪٽ ورزن، تعمير ڊاريڪٽري جو رستو، ۽ RPM-build هلائي ٿو. هڪ دفعو تعمير مڪمل ٿئي ٿي، پيڪيج شايع ڪيو ويو آهي مقامي مخزن، جيڪو بلڊ ايجنٽ تي واقع آهي.

اڳيون، بلڊ ايجنٽ کان سرور تائين RPM مخزن ۾ JSON درخواست موڪلي وئي آهي نسخي جو نالو ۽ تعمير جو اشارو. ويب هوڪ، جنهن بابت مون اڳ ۾ ڳالهايو هو، اهو تمام گهڻو پيڪيج ڊائون لوڊ ڪري ٿو مقامي مخزن مان بلڊ ايجنٽ تي ۽ نئين اسيمبلي کي انسٽاليشن لاءِ دستياب بڻائي ٿو.

.NET ڪور لينڪس تي، DevOps گھوڙي تي

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

ڊيٽابيس ورزننگ

ڊولپمينٽ ٽيم سان صلاح مشوري تي، اهو ظاهر ٿيو ته ماڻهو MS SQL جي ويجھو هئا، پر اڪثر غير ونڊوز منصوبن ۾ اسان اڳ ۾ ئي پوسٽ گري ايس ايس ايل استعمال ڪري رهيا هئاسين انهن جي پوري طاقت سان. جيئن ته اسان پهريان ئي فيصلو ڪيو هو ته ادا ڪيل هر شي کي ڇڏي ڏيو، اسان هتي پڻ PostgreSQL استعمال ڪرڻ شروع ڪيو.

.NET ڪور لينڪس تي، DevOps گھوڙي تي

هن حصي ۾ مان توهان کي ٻڌائڻ چاهيان ٿو ته اسان ڊيٽابيس کي ڪيئن ورزن ڪيو ۽ اسان فلائي وي ۽ اينٽيٽي فريم ورڪ ڪور جي وچ ۾ ڪيئن چونڊيو. اچو ته انهن جي نفعو ۽ نقصان تي نظر.

Минусы

فلائي وي صرف هڪ طرفو وڃي ٿو، اسان اسان واپس نه ٿا ڪري سگهون - هي هڪ اهم نقصان آهي. توھان ان جو مقابلو ڪري سگھو ٿا Entity Framework Core سان ٻين طريقن سان - ڊولپر جي سهولت جي لحاظ کان. توهان کي ياد آهي ته اسان هن کي اڳيان رکون ٿا، ۽ بنيادي معيار ونڊوز ڊولپمينٽ لاءِ ڪجهه به تبديل نه ڪرڻ هو.

Flyway اسان لاء ڪنهن قسم جي چادر جي ضرورت هئيته جيئن ماڻهو نه لکن SQL سوال. اهي OOP جي اصطلاحن ۾ ڪم ڪرڻ جي تمام ويجهو آهن. اسان ڊيٽابيس جي شين سان ڪم ڪرڻ لاءِ هدايتون لکيون، هڪ SQL سوال پيدا ڪيو ۽ ان تي عمل ڪيو. ڊيٽابيس جو نئون نسخو تيار آهي، آزمائشي - سڀ ڪجھ ٺيڪ آهي، سڀ ڪجهه ڪم ڪري ٿو.

انٽيٽي فريم ورڪ ڪور ۾ هڪ مائنس آهي - ان کي ڳري بار هيٺ suboptimal SQL سوالن کي ٺاهي ٿو، ۽ ڊيٽابيس ۾ گھٽتائي اهم ٿي سگھي ٿي. پر جيئن ته اسان وٽ هڪ اعلي لوڊ سروس نه آهي، اسان سوين آر پي ايس ۾ لوڊ جو حساب نه ٿا ڪريون، اسان انهن خطرن کي قبول ڪيو ۽ مستقبل جي مسئلي کي اسان جي حوالي ڪيو.

Плюсы

ادارو فريم ورڪ ڪور دٻي کان ٻاهر ڪم ڪري ٿو ۽ ترقي ڪرڻ آسان آهي، ۽ فلائي وي آساني سان موجوده CI ۾ ضم ٿي. پر اسان ان کي ڊولپرز لاءِ آسان بڻايون ٿا :)

رول اپ عمل

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

ايپليڪيشنون حساس ڊيٽا استعمال ڪن ٿيون، جهڙوڪ ٽوڪن، ڊيٽابيس پاسورڊ، اهو سڀ ڪجهه پپٽ ماسٽر کان ترتيب ۾ کڄي ويو آهي، جتي اهي انڪرپٽ فارم ۾ محفوظ ٿيل آهن.

TFS مسئلا

بعد ۾ اسان فيصلو ڪيو ۽ محسوس ڪيو ته سڀ ڪجهه واقعي اسان لاءِ ڪم ڪري رهيو آهي، مون اهو ڏسڻ جو فيصلو ڪيو ته TFS ۾ اسيمبلين سان ڇا ٿي رهيو آهي مجموعي طور تي Win ڊويلپمينٽ ڊپارٽمينٽ لاءِ ٻين منصوبن تي - ڇا اسان جلدي تعمير ڪري رهيا هئاسين يا نه، ۽ رفتار سان اهم مسئلا دريافت ڪيا.

مکيه منصوبن مان هڪ کي گڏ ڪرڻ ۾ 12-15 منٽ لڳن ٿا - اهو هڪ ڊگهو وقت آهي، توهان ائين نٿا رهي سگهو. هڪ تڪڙو تجزيو I/O ۾ خوفناڪ ڇڪتاڻ ڏيکاريو، ۽ اهو صفن تي هو.

جزو جي لحاظ کان ان جي تجزيي کان پوء، مون ٽن عنصر جي نشاندهي ڪئي. پهريون - "Kaspersky اينٽي وائرس"، جيڪو سڀني ونڊوز بلڊ ايجنٽن تي ذريعن کي اسڪين ڪري ٿو. ٻيون - ونڊوز انڊيڪس ڪندڙ. اهو غير فعال نه هو، ۽ هر شي کي ترتيب ڏيڻ واري عمل دوران بلڊ ايجنٽ تي حقيقي وقت ۾ ترتيب ڏني وئي هئي.

ٽيون - اين پي ايم انسٽال ڪريو. اهو ظاهر ٿيو ته اڪثر پائپ لائنن ۾ اسان هن صحيح منظر کي استعمال ڪيو. هو خراب ڇو آهي؟ اين پي ايم جي انسٽاليشن جي طريقيڪار کي هلايو ويندو آهي جڏهن انحصار جو وڻ ٺاهيو ويندو آهي package-lock.json، جتي پيڪيجز جا نسخا جيڪي پروجيڪٽ جي تعمير لاءِ استعمال ڪيا ويندا رڪارڊ ٿيل آهن. نقصان اهو آهي ته اين پي ايم انسٽال هر ڀيري انٽرنيٽ تان پيڪيجز جا جديد ورجن ڪڍندو آهي، ۽ اهو وڏي پروجيڪٽ جي صورت ۾ گهڻو وقت وٺندو آهي.

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

فيصلو

  • AV استثنا ۾ ذريعن.
  • انڊيڪسنگ کي بند ڪريو.
  • کي منتقلي npm ci.

npm ci جا فائدا هي آهن ته اسان اسان هڪ ڀيرو انحصار جي وڻ کي گڏ ڪندا آهيون، ۽ اسان کي ڊولپر مهيا ڪرڻ جو موقعو مليو پيڪيجز جي موجوده فهرستجنهن سان هو مقامي طور تي جيترو به چاهي تجربو ڪري سگهي ٿو. هي وقت بچائي ٿو ڊولپر جيڪي ڪوڊ لکندا آهن.

ڪنفگريشن

ھاڻي ٿورڙو مخزن جي ٺاھ جوڙ بابت. تاريخي طور تي اسان استعمال ڪندا آهيون رشتو مخزن جي انتظام لاءِ، بشمول اندروني REPO. ھن اندروني مخزن ۾ اھي سڀئي حصا شامل آھن جيڪي اسان اندروني مقصدن لاءِ استعمال ڪندا آھيون، مثال طور، خود لکيل مانيٽرنگ.

.NET ڪور لينڪس تي، DevOps گھوڙي تي

اسان پڻ استعمال ڪندا آهيون نياگٽجيئن ته ٻين پيڪيج مينيجرز جي مقابلي ۾ ان ۾ بهتر ڪيشنگ آهي.

نتيجي ۾

اسان کان پوءِ بلڊ ايجنٽن کي بهتر ڪيو، اوسط تعمير وقت 12 منٽ کان 7 تائين گھٽجي ويو.

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

منصوبو

ايندڙ ٽه ماهي لاءِ، اسان ڪم ڪرڻ جي رٿابندي ڪئي ڪوڊ ترسيل کي بهتر ڪرڻ تي.

پري بلڊ ڊاڪر تصوير ڏانهن تبديل ٿي رهيو آهي. TFS ڪيترن ئي پلگ ان سان گڏ هڪ سٺي شيءِ آهي جيڪا توهان کي پائيپ لائين ۾ ضم ڪرڻ جي اجازت ڏئي ٿي، بشمول ٽرگر تي ٻڌل اسمبلي، چئو، هڪ ڊڪر تصوير. اسان چاهيون ٿا ته هي محرڪ هڪ ئي لاءِ package-lock.json. جيڪڏهن پراجيڪٽ جي تعمير لاءِ استعمال ٿيل اجزاء جو ٺهيل ڪنهن به طرح تبديل ٿئي ٿو، اسان هڪ نئين ڊاکر تصوير ٺاهيندا آهيون. اهو بعد ۾ گڏ ٿيل ايپليڪيشن سان گڏ ڪنٽينر کي ترتيب ڏيڻ لاء استعمال ڪيو ويندو آهي. اهو معاملو هاڻي ناهي، پر اسان Kubernetes ۾ هڪ microservice فن تعمير کي تبديل ڪرڻ جي منصوبابندي ڪري رهيا آهيون، جيڪو اسان جي ڪمپني ۾ فعال طور تي ترقي ڪري رهيو آهي ۽ هڪ ڊگهي وقت تائين پيداوار جي حل جي خدمت ڪري رهيو آهي.

خلاصو

مان سڀني کي حوصلا افزائي ڪريان ٿو ته ونڊوز کي اڇلائي، پر اهو نه آهي ڇو ته مون کي خبر ناهي ته ان کي ڪيئن ٺاهيو. ان جو سبب اهو آهي ته اڪثر اوپن سورس حل آهن لينڪس اسٽيڪ. ڇا توهان ٺيڪ آهيو وسيلن تي بچاء. منهنجي خيال ۾، مستقبل جو تعلق هڪ طاقتور ڪميونٽي سان لينڪس تي اوپن سورس حل سان آهي.

اليگزينڊر سنچينوف جي اسپيڪر پروفائل GitHub تي.

DevOps Conf هڪ ڪانفرنس آهي ترقي جي انضمام تي، ٽيسٽ ۽ آپريشن جي عملن لاءِ پروفيشنلز پاران. اهو ئي سبب آهي ته اليگزينڊر جنهن منصوبي بابت ڳالهايو هو؟ لاڳو ۽ ڪم ڪري رهيو آهي، ۽ ڪارڪردگي جي ڏينهن تي ٻه ڪامياب رليز هئا. تي RIT++ تي DevOps Conf 27 ۽ 28 مئي تي عملي کان به وڌيڪ اهڙا ڪيس هوندا. توهان اڃا تائين آخري گاڏي ۾ ٽپو ڏيئي سگهو ٿا ۽ رپورٽ پيش ڪريو يا پنهنجو وقت وٺو بڪ ڪرڻ ٽڪيٽ. اسان سان ملو Skolkovo ۾!

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

تبصرو شامل ڪريو