.NET کور په لینوکس کې، DevOps په آس باندې

موږ DevOps لکه څنګه چې موږ کولی شو وده وکړه. زموږ څخه 8 تنه وو، او واسیا په وینډوز کې ترټولو ښه وه. ناڅاپه واسیا پریښوده، او ما د یوې نوې پروژې په لاره اچولو دنده درلوده چې د وینډوز پراختیا لخوا چمتو شوي. کله چې ما په میز کې د وینډوز بشپړ پراختیا سټیک ډوب کړ، ما پوهیده چې وضعیت یو درد و ...

په دې ډول کیسه پیل کیږي الکساندر سینچینووا په DevOpsConf. کله چې د وینډوز مخکښ متخصص شرکت پریښود، الکساندر حیران شو چې اوس څه وکړي. لینوکس ته لاړشئ، البته! الکساندر به تاسو ته ووایی چې څنګه یې د 100 پای کاروونکو لپاره د بشپړې شوې پروژې مثال په کارولو سره لینکس ته د وینډوز پراختیا یوه سابقه رامینځته کولو او لیږدولو اداره کړې.

.NET کور په لینوکس کې، DevOps په آس باندې

څنګه کولای شو چی د TFS، Puppet، Linux .NET کور په کارولو سره RPM ته یوه پروژه په اسانۍ او اسانۍ سره وړاندې کړو؟ د پروژې ډیټابیس نسخه کولو ملاتړ کولو څرنګوالی که چیرې پرمختیایی ټیم د لومړي ځل لپاره د پوسټګریس او فلای وی کلمې واوري ، او وروستۍ نیټه سبا بله ورځ وي؟ څنګه د ډاکر سره یوځای کول؟ څنګه د .NET پراختیا کونکي هڅوي چې د پوپټ او لینکس په ګټه وینډوز او سموټي پریږدي؟ د ایډیالوژیکي شخړو د حل کولو څرنګوالی که چیرې په تولید کې د وینډوز ساتلو لپاره نه ځواک، نه لیوالتیا، او نه سرچینې شتون ولري؟ د دې په اړه، په بیله بیا د ویب ځای پرځای کولو، ازموینې، CI په اړه، په موجوده پروژو کې د TFS کارولو تمرینونو په اړه، او البته، د مات شوي بیسایانو او کاري حلونو په اړه، د الکساندر د راپور په نقل کې.


نو ، واسیا پریښوده ، دنده زما په غاړه ده ، پراختیا کونکي د پچفورکس سره په بې صبرۍ سره انتظار کوي. کله چې زه په پای کې پوه شوم چې واسیا نشي کولی بیرته راستانه شي، زه سوداګرۍ ته ښکته شوم. د پیل کولو لپاره ، ما زموږ په بیړۍ کې د Win VMs سلنه ارزولې. نمره د وینډوز په ګټه نه وه.

.NET کور په لینوکس کې، DevOps په آس باندې

څرنګه چې موږ په فعاله توګه DevOps ته وده ورکوو، ما پوهیده چې یو څه باید د نوي غوښتنلیک وړاندې کولو په طریقه کې بدلون ومومي. یوازې یو حل شتون درلود - که امکان ولري، هرڅه لینکس ته انتقال کړئ. ګوګل زما سره مرسته وکړه - په هغه وخت کې .Net لا دمخه لینکس ته لیږدول شوی و، او ما پوهیده چې دا د حل لاره وه!

ولې .NET کور د لینکس سره په ګډه؟

د دې څو لاملونه وو. د "پیسو تادیه" او "نه تادیه" ترمنځ، اکثریت به دویمه غوره کړي - زما په څیر. د MSDB لپاره جواز شاوخوا $ 1 لګښت لري؛ د وینډوز مجازی ماشینونو بیړۍ ساتل په سلګونو ډالر لګښت لري. د لوی شرکت لپاره دا یو لوی لګښت دی. د همدې لپاره خوندي کول - لومړی دلیل. تر ټولو مهم نه، مګر یو له مهمو څخه.

د وینډوز مجازی ماشینونه د دوی د لینکس وروڼو په پرتله ډیرې سرچینې اخلي - دوی درانه دي. د لوی شرکت پیمانه په پام کې نیولو سره، موږ لینکس غوره کړ.

سیسټم په ساده ډول په موجوده CI کې مدغم شوی. موږ خپل ځان پرمختللی DevOps ګڼو، موږ بانس، جینکنز او GitLab CI کاروو، نو زموږ ډیری کار په لینکس کې پرمخ ځي.

وروستی دلیل یې دا دی مناسب ملګری. موږ اړتیا درلوده چې د "اسکارټس" لپاره د ننوتلو خنډ کم کړو - هغه هلکان چې په تخنیکي برخه پوهیږي، بې بنسټه خدمت تضمینوي، او د دویمې کرښې څخه خدمتونه ساتي. دوی دمخه د لینکس سټیک سره آشنا وو ، نو د دوی لپاره د نوي محصول پوهیدل ، ملاتړ کول او ساتل خورا اسانه دي د وینډوز پلیټ فارم لپاره د سافټویر ورته فعالیت پوهیدو لپاره اضافي سرچینې مصرف کولو په پرتله.

اړتیاو

لومړی او تر ټولو مهم - د پراختیا کونکو لپاره د نوي حل اسانتیا. دوی ټول د بدلون لپاره چمتو ندي، په ځانګړې توګه د لینکس کلمه وروسته. پراختیا کونکي د دوی غوره لید سټوډیو غواړي ، TFS د اسمبلۍ او سموټیز لپاره د آټوټیسټونو سره. د دوی لپاره مهمه نده چې تولید ته څنګه تحویلیږي. له همدې امله، موږ پریکړه وکړه چې عادي بهیر بدل نه کړو او د وینډوز پراختیا لپاره هرڅه بدل نه پریږدو.

نوې پروژې ته اړتیا ده په موجوده CI کې مدغم کول. ریلونه لا دمخه شتون درلود او ټول کار باید د تنظیم کولو مدیریت سیسټم پیرامیټرو په پام کې نیولو سره ترسره شي، د سپارلو منل شوي معیارونه او د څارنې سیسټمونه.

د ملاتړ او عملیاتو اسانتیاد مختلفو څانګو او د ملاتړ څانګې څخه د ټولو نوي ګډون کونکو لپاره د لږترلږه ننوتلو حد لپاره د شرط په توګه.

وروستۍ نیټه - پرون.

د پرمختیا ګروپ وګټئ

هغه مهال د وینډوز ټیم څه کار کاوه؟

.NET کور په لینوکس کې، DevOps په آس باندې

اوس زه کولی شم په ډاډ سره ووایم IdentityServer4 د ورته وړتیاو سره د ADFS لپاره یو ښه وړیا بدیل دی، یا څه د ادارې چوکاټ کور - د پراختیا کونکي لپاره جنت ، چیرې چې تاسو اړتیا نلرئ د SQL سکریپټونو لیکلو کې زحمت وکړئ ، مګر د OOP شرایطو کې ډیټابیس کې پوښتنې تشریح کړئ. مګر بیا ، د عمل پلان په اړه د بحث په جریان کې ، ما دې سټیک ته داسې وکتل لکه څنګه چې دا د سومریان کیونیفورم و ، یوازې د PostgreSQL او Git پیژني.

په هغه وخت کې موږ په فعاله توګه کار کاوه ګوډاګی د تنظیم کولو مدیریت سیسټم په توګه. زموږ په ډیری پروژو کې موږ کار کاوه ګیت لیب سی آی, Elasticد متوازن لوړ بار خدمتونه کارول HAProxy سره هرڅه څارل زبیبکس, ligaments ګرافانا и Prometheus, ښکار، او دا ټول د اوسپنې په ټوټو باندې تیریدل HPESXi په VMware. هرڅوک دا پوهیږي - د ژانر کلاسیک.

.NET کور په لینوکس کې، DevOps په آس باندې

راځئ وګورو او هڅه وکړو چې د دې ټولو مداخلو پیل کولو دمخه څه پیښ شوي.

څه پیښ شو

TFS یو کافي ځواکمن سیسټم دی چې نه یوازې د پراختیا کونکي څخه وروستي تولید ماشین ته کوډ وړاندې کوي ، بلکه د مختلف خدماتو سره د خورا انعطاف وړ ادغام لپاره سیټ هم لري - ترڅو د کراس پلیټ فارم کچه کې CI چمتو کړي.

.NET کور په لینوکس کې، DevOps په آس باندې
پخوا، دا قوي کړکۍ وې. TFS ډیری جوړونکي اجنټان کاروي، کوم چې د ډیری پروژو راټولولو لپاره کارول شوي. هر اجنټ 3-4 کارګران لري ترڅو دندو موازي کولو او پروسې غوره کړي. بیا ، د خوشې کولو پلانونو سره سم ، TFS تازه پخه شوی جوړ د وینډوز غوښتنلیک سرور ته وسپارل.

موږ څه ترلاسه کول غوښتل؟

موږ د تحویل او پراختیا لپاره TFS کاروو ، او غوښتنلیک د لینکس غوښتنلیک سرور کې چلوو ، او د دوی ترمینځ یو ډول جادو شتون لري. دا جادو بکس او د کار مالګه په مخ کې ده. مخکې لدې چې زه دا جلا کړم ، زه به یو ګام یو طرف واخلم او د غوښتنلیک په اړه یو څو ټکي ووایم.

پروژه

غوښتنلیک د پری پیډ کارتونو اداره کولو لپاره فعالیت چمتو کوي.

.NET کور په لینوکس کې، DevOps په آس باندې

د مراجع

دوه ډوله کاروونکي وو. لومړی د SSL SHA-2 سند په کارولو سره د ننوتلو له لارې لاسرسی ترلاسه کړ. یو د دویمه برخه د ننوتلو او پټنوم په کارولو سره لاسرسی شتون درلود.

HAProxy

بیا د پیرودونکي غوښتنه HAProxy ته لاړه، کوم چې لاندې ستونزې حل کړې:

  • ابتدايي اجازه؛
  • د ایس ایس ایل ختمول؛
  • د HTTP غوښتنې تنظیم کول؛
  • د خپرونې غوښتنې.

د پیرودونکي سند د سلسلې په اوږدو کې تایید شوی. موږ - واک او موږ دا توان لرو، ځکه چې موږ پخپله د خدماتو پیرودونکو ته سندونه ورکوو.

دریم ټکي ته پام وکړئ، موږ به لږ وروسته بیرته راګرځو.

بډایډ

دوی پلان درلود چې په لینکس کې پس منظر جوړ کړي. بیک انډ د ډیټابیس سره اړیکه لري، د امتیازاتو اړین لیست باروي او بیا، د کوم امتیازاتو په اساس چې مجاز کاروونکي لري، د مالي اسنادو لاسلیک کولو ته السرسی چمتو کوي او د اجرا کولو لپاره یې لیږل، یا یو ډول راپور تولیدوي.

د HAProxy سره سپما

د دوه شرایطو سربیره چې هر پیرودونکي یې حرکت کړی، د پیژندنې شرایط هم شتون لري. IdentityServer4 یوازې تاسو ته د ننوتلو اجازه درکوي، دا یو وړیا او پیاوړی انلاګ دی ADFS - د فعالو لارښود فدراسیون خدمتونه.

د هویت غوښتنه په څو مرحلو کې پروسس شوې. لومړی ګام - پیرودونکی شاته ورننوتل، کوم چې د دې سرور سره اړیکه نیولې او د پیرودونکي لپاره یې د نښه شتون چیک کړی. که دا ونه موندل شي، غوښتنه بیرته هغه شرایطو ته راستانه شوه چې له کوم ځای څخه راغلی، مګر د ریډیر سره، او د لارښوونې سره دا پیژندنې ته لاړ.

دوهم ګام - غوښتنه ترلاسه شوه په IdentityServer کې د واک ورکولو پاڼې ته، چیرته چې پیرودونکي راجستر شوي، او دا د اوږدې مودې لپاره د IdentityServer ډیټابیس کې ښکاره شوی.

دریم ګام - پیرودونکي بیرته راستانه شوي هغه شرایطو ته چې له کوم ځای څخه راغلی.

.NET کور په لینوکس کې، DevOps په آس باندې

IdentityServer4 یو ځانګړتیا لري: دا د HTTP له لارې د بیرته راستنیدو غوښتنې ته ځواب ورکوي. مهمه نده چې موږ د سرور تنظیم کولو سره څومره مبارزه وکړه ، مهمه نده چې موږ څومره د اسنادو سره ځان روښانه کړو ، هرځله چې موږ د یو آر ایل سره د پیرودونکي لومړنۍ غوښتنه ترلاسه کړه چې د HTTPS له لارې راغلی ، او IdentityServer ورته شرایط بیرته راستانه کړل ، مګر د HTTP سره. موږ حیران وو! او موږ دا ټول د پیژندنې شرایطو له لارې HAProxy ته لیږدولي، او په سرلیکونو کې موږ باید HTTPS ته HTTP پروتوکول تعدیل کړو.

اصلاح څه شی دی او چیرته مو خوندي کړی؟

موږ د کاروونکو، سرچینو یوې ډلې ته د واک ورکولو لپاره د وړیا حل په کارولو سره پیسې خوندي کړې، ځکه چې موږ په جلا برخه کې IdentityServer4 د جلا نوډ په توګه نه دی ځای پرځای کړی، مګر دا په ورته سرور کې د بیک انډ سره یوځای کارول کیږي چیرې چې د غوښتنلیک بیک انډ چلیږي. .

دا باید څنګه کار وکړي

نو، لکه څنګه چې ما ژمنه کړې - د جادو بکس. موږ دمخه پوهیږو چې موږ د لینکس په لور د حرکت کولو تضمین یو. راځئ چې ځانګړي دندې رامینځته کړو چې حل ته اړتیا لري.

.NET کور په لینوکس کې، DevOps په آس باندې

ګوډاګی ښکاره کوي. د خدماتو او غوښتنلیک ترتیب وړاندې کولو او اداره کولو لپاره، ښایسته ترکیبونه باید لیکل شوي وای. د پنسل رول په فصاحت سره ښیي چې دا څومره په چټکۍ او اغیزمنه توګه ترسره شوی.

د سپارلو طریقه. معیار RPM دی. هرڅوک پوهیږي چې په لینکس کې تاسو پرته له دې نشئ کولی، مګر پخپله پروژه، د غونډې وروسته، د اجرا وړ DLL فایلونو سیټ و. د دوی شاوخوا 150 وو، پروژه خورا ستونزمنه وه. یوازینی همغږي حل دا دی چې دا بائنری په RPM کې بسته کړئ او له هغې څخه غوښتنلیک ځای په ځای کړئ.

نسخه کول. موږ باید ډیری وختونه خوشې کړو، او موږ باید پریکړه وکړو چې څنګه د کڅوړې نوم جوړ کړو. دا د TFS سره د ادغام د کچې پوښتنه ده. موږ په لینکس کې د جوړونکي اجنټ درلود. کله چې TFS یو هینډلر - کارګر - د جوړونکي اجنټ ته دنده لیږي ، دا د متغیرونو یوه ډله هم لیږدوي چې د هینډلر پروسې چاپیریال کې پای ته رسیږي. دا چاپیریال متغیرونه د جوړونې نوم، د نسخې نوم، او نور متغیرونه لري. د دې په اړه نور ولولئ "د RPM کڅوړې جوړول" برخه کې.

د TFS تنظیم کول د پایپ لاین د جوړولو لپاره راښکته شو. پخوا، موږ د وینډوز په ایجنټانو کې د وینډوز ټولې پروژې راټولولې، مګر اوس د لینوکس اجنټ ښکاري - د جوړونې اجنټ، چې اړتیا لري د جوړونې ګروپ کې شامل شي، د ځینې هنري اثارو سره بډایه شوي، او ویل شوي چې په دې جوړونکي اجنټ کې به کوم ډول پروژې جوړې شي. ، او په یو څه ډول پایپ لاین تعدیل کړئ.

IdentityServer. ADFS زموږ لاره نه ده، موږ د خلاصې سرچینې لپاره ځو.

راځئ چې د اجزاوو له لارې لاړ شو.

جادو بکس

له څلورو برخو څخه جوړه ده.

.NET کور په لینوکس کې، DevOps په آس باندې

د لینکس جوړونکي اجنټ. لینکس، ځکه چې موږ د دې لپاره جوړوو - دا منطقي دی. دا برخه په دریو مرحلو کې ترسره شوه.

  • کارګران تنظیم کړئ او یوازې نه، ځکه چې د پروژې ویشل شوي کار تمه کیده.
  • د .NET کور 1.x نصب کړئ. ولې 1.x کله چې 2.0 دمخه په معیاري ذخیره کې شتون لري؟ ځکه چې کله موږ پراختیا پیل کړه، مستحکم نسخه 1.09 وه، او پریکړه وشوه چې پروژه د هغې پر بنسټ جوړه کړو.
  • Git 2.x.

RPM-مخزن. د RPM کڅوړې باید چیرته زیرمه شي. داسې انګیرل کیده چې موږ به ورته کارپوریټ RPM ذخیره وکاروو چې د لینکس ټولو کوربه ګانو لپاره شتون لري. دا هغه څه دي چې دوی یې وکړل. د ذخیره کولو سرور ترتیب شوی ویب هک کوم چې د ټاکل شوي ځای څخه د اړتیا وړ RPM کڅوړه ډاونلوډ کړې. د کڅوړې نسخه د جوړونکي اجنټ لخوا ویب هک ته راپور شوې.

ګیت لیب. پاملرنه! GitLab دلته د پراختیا کونکو لخوا نه کارول کیږي ، مګر د عملیاتو ډیپارټمنټ لخوا د غوښتنلیک نسخې کنټرولولو لپاره ، د بسته بندۍ نسخې ، د ټولو لینکس ماشینونو وضعیت څارنه کوي ، او دا ترکیب ذخیره کوي - ټول پوپټ څرګندونه.

ګوډاګی - ټولې جنجالي مسلې حل کوي او دقیقا هغه ترتیب وړاندې کوي چې موږ یې له ګیتلاب څخه غواړو.

موږ ډوب پیل کوو. RPM ته د DLL تحویل څنګه کار کوي؟

RPM ته DDL سپارل

راځئ چې ووایو موږ د .NET پرمختیا راک سټار لرو. دا د لید سټوډیو کاروي او د خوشې کولو څانګه رامینځته کوي. له هغې وروسته، دا دا Git ته اپلوډ کوي، او Git دلته د TFS اداره ده، دا د غوښتنلیک ذخیره ده چې پراختیا کونکي ورسره کار کوي.

.NET کور په لینوکس کې، DevOps په آس باندې

له هغه وروسته چې TFS ګوري چې یو نوی ژمنه رارسیدلی. کوم اپلیکیشن؟ د TFS په ترتیباتو کې یو لیبل شتون لري چې دا په ګوته کوي چې د ځانګړي جوړونکي اجنټ کومې سرچینې لري. پدې حالت کې، هغه ګوري چې موږ د .NET کور پروژه جوړوو او د حوض څخه د لینکس جوړونکي اجنټ غوره کوو.

د جوړونکي اجنټ سرچینې ترلاسه کوي او اړین ډاونلوډ کوي انحصار د .NET ذخیره، npm، او نور څخه. او د غوښتنلیک د جوړولو او وروسته بسته کولو وروسته، د RPM کڅوړه د RPM ذخیره ته لیږي.

له بلې خوا، لاندې واقع کیږي. د عملیاتو ډیپارټمنټ انجینر په مستقیم ډول د پروژې په رول کې ښکیل دی: هغه د کڅوړو نسخه بدلوي هیره په ذخیره کې چیرې چې د غوښتنلیک ترکیب زیرمه شوی ، وروسته لدې چې ګوډاګی حرکت کوي Yum، د ذخیره کولو څخه نوې کڅوړه راوړي، او د غوښتنلیک نوې نسخه د کارولو لپاره چمتو ده.

.NET کور په لینوکس کې، DevOps په آس باندې

هرڅه په کلمو کې ساده دي ، مګر پخپله د جوړونکي اجنټ دننه څه پیښیږي؟

د DLL RPM بسته کول

د پروژې سرچینې ترلاسه کول او د TFS څخه کار جوړول. ایجنټ جوړ کړئ د پروژې جوړول پخپله د سرچینو څخه پیل کوي. راټول شوی پروژه د سیټ په توګه شتون لري د DLL فایلونه، کوم چې په زپ آرشیف کې بسته شوي ترڅو د فایل سیسټم بار کم کړي.

د زپ آرشیف لرې شوی د RPM بسته جوړونې لارښود ته. بیا، د باش سکریپټ د چاپیریال تغیرات پیل کوي، د جوړونې نسخه، د پروژې نسخه، د جوړونې لارښود ته لاره پیدا کوي، او RPM-build پرمخ وړي. یوځل چې جوړونه بشپړه شي ، کڅوړه به خپره شي ځایی ذخیره، کوم چې د جوړونکي ایجنټ کې موقعیت لري.

بیا، د جوړونکي اجنټ څخه سرور ته د RPM ذخیره کې د JSON غوښتنه لیږل کیږي د نسخې نوم او جوړونه په ګوته کوي. ویب هوک ، کوم چې ما دمخه په اړه خبرې وکړې ، دا خورا کڅوړه د بلډ ایجنټ له ځایی ذخیره څخه ډاونلوډ کوي او نوې مجلس د نصب لپاره چمتو کوي.

.NET کور په لینوکس کې، DevOps په آس باندې

ولې د RPM ذخیره ته د دې ځانګړي کڅوړې تحویلي سکیم؟ ولې زه نشم کولی سمدلاسه راټول شوي کڅوړه ذخیره ته ولیږم؟ حقیقت دا دی چې دا د خوندیتوب لپاره یو شرط دی. دا سناریو د غیر مجاز خلکو احتمال محدودوي چې RPM کڅوړې سرور ته اپلوډ کړي چې ټولو لینکس ماشینونو ته د لاسرسي وړ وي.

د ډیټابیس نسخه کول

د پرمختیایي ټیم سره په مشوره کې، دا معلومه شوه چې هلکان MS SQL ته نږدې وو، مګر په ډیری غیر وینډوز پروژو کې موږ دمخه د خپل ټول ځواک سره PostgreSQL کاروو. څنګه چې موږ دمخه پریکړه کړې وه چې هرڅه تادیه پریږدو ، موږ دلته هم د PostgreSQL کارول پیل کړل.

.NET کور په لینوکس کې، DevOps په آس باندې

پدې برخه کې زه غواړم تاسو ته ووایم چې موږ څنګه ډیټابیس نسخه کړی او څنګه مو د Flyway او Entity Framework Core ترمنځ انتخاب کړی. راځئ چې د دوی ګټې او زیانونه وګورو.

Минусы

الوتنه یوازې یوه لاره ځي، موږ موږ نشو کولی بیرته راوګرځو - دا یو مهم زیان دی. تاسو کولی شئ دا د ادارې چوکاټ کور سره په نورو لارو پرتله کړئ - د پراختیا کونکي اسانتیا په شرایطو کې. تاسو په یاد ولرئ چې موږ دا په لومړي سر کې ایښودو، او اصلي معیار د وینډوز پراختیا لپاره هیڅ شی نه بدلول.

د Flyway زموږ لپاره یو ډول ریپر ته اړتیا وهترڅو هلکان ونه لیکي د SQL پوښتنې. دوی د OOP شرایطو کې کار کولو ته خورا نږدې دي. موږ د ډیټابیس شیانو سره د کار کولو لپاره لارښوونې لیکلي، د SQL پوښتنه مو جوړه کړه او اجرا یې کړه. د ډیټابیس نوې نسخه چمتو ده، ازموینه شوې - هرڅه سم دي، هرڅه کار کوي.

د ادارې چوکاټ کور یو منفي لري - د درنو بارونو لاندې suboptimal SQL پوښتنې جوړوي، او په ډیټابیس کې کمیدل د پام وړ کیدی شي. مګر څنګه چې موږ د لوړ بار خدمت نلرو، موږ په سلګونو RPS کې بار نه محاسبه کوو، موږ دا خطرونه ومنل او ستونزه مو راتلونکي ته وسپارله.

Плюсы

د ادارې چوکاټ کور د بکس څخه بهر کار کوي او وده کول اسانه دي، او Flyway په اسانۍ سره په موجوده CI کې مدغم کیږي. مګر موږ دا د پراختیا کونکو لپاره اسانه کوو :)

د رول اپ طرزالعمل

ګوډاګی ګوري چې د بسته بندۍ نسخه کې بدلون راځي، په شمول هغه چې د مهاجرت مسولیت لري. لومړی، دا یو بسته نصبوي چې د مهاجرت سکریپټ او ډیټابیس پورې اړوند فعالیت لري. له دې وروسته، هغه غوښتنلیک چې د ډیټابیس سره کار کوي بیا پیل کیږي. بیا د پاتې برخو نصب کول راځي. هغه ترتیب په کوم کې چې کڅوړې نصب شوي او غوښتنلیکونه په لاره اچول شوي د Puppet manifest کې تشریح شوي.

غوښتنلیکونه حساس معلومات کاروي، لکه ټوکنونه، د ډیټابیس پاسورډونه، دا ټول د Puppet Master څخه ترتیب ته ایستل شوي، چیرته چې دوی په کوډ شوي بڼه کې زیرمه شوي.

د TFS ستونزې

وروسته له دې چې موږ پریکړه وکړه او پوه شو چې هرڅه زموږ لپاره واقعیا کار کوي، ما پریکړه وکړه چې وګورم چې په TFS کې د نورو پروژو په اړه د Win پراختیایي څانګې لپاره په ټولیزه توګه د مجلسونو سره څه روان دي - ایا موږ ژر تر ژره جوړول / خوشې کول یا نه، او د سرعت سره د پام وړ ستونزې وموندل.

یو له اصلي پروژو څخه د راټولولو لپاره 12-15 دقیقې وخت نیسي - دا ډیر وخت دی، تاسو نشئ کولی داسې ژوند وکړئ. یو چټک تحلیل په I/O کې یو ناوړه کمښت ښودلی، او دا په صفونو کې و.

د اجزاو په واسطه د دې برخې تحلیل کولو وروسته، ما درې فوکسونه په ګوته کړل. لومړی - "کاسپرسکي انټي ویروس"، کوم چې په ټولو وینډوز جوړو اجنټانو کې سرچینې سکین کوي. دوهم - Windows Indexer. دا غیر فعال نه و، او هر څه په ریښتیني وخت کې د ګمارنې پروسې په جریان کې د جوړو اجنټانو کې لیست شوي.

دریم - د Npm نصب کول. دا معلومه شوه چې په ډیری پایپ لاینونو کې موږ دا دقیق سناریو کارولې. هغه ولې بد دی؟ د Npm نصب کولو کړنلاره هغه وخت پرمخ ځي کله چې د انحصار ونه په کې جوړه شي package-lock.json، چیرې چې د کڅوړو نسخې چې د پروژې جوړولو لپاره کارول کیږي ثبت شوي. نیمګړتیا دا ده چې د Npm انسټالول هر وخت له انټرنیټ څخه د کڅوړو وروستي نسخې راوباسي، او دا د یوې لویې پروژې په صورت کې ډیر وخت نیسي.

پراختیا کونکي ځینې وختونه په محلي ماشین کې تجربه کوي ترڅو ازموینه وکړي چې یوه ځانګړې برخه یا ټوله پروژه څنګه کار کوي. ځینې ​​​​وختونه دا معلومه شوه چې هر څه په محلي توګه ښه وو، مګر دوی یې راټول کړل، دا یې وګرځول، او هیڅ شی یې کار نه کاوه. موږ د دې معلومولو پیل کوو چې ستونزه څه ده - هو ، د انحصار سره د کڅوړو مختلف نسخې.

پریکړه

  • په AV استثناء کې سرچینې.
  • د لیست کولو بندول.
  • ورتګ npm ci.

د npm ci ګټې دا دي چې موږ موږ یو ځل د انحصار ونې راټولوو، او موږ د پراختیا کونکي چمتو کولو فرصت ترلاسه کوو د کڅوړو اوسنی لیست، د کوم سره چې هغه کولی شي په محلي توګه څومره چې هغه خوښوي تجربه کړي. دا وخت خوندي کوي پراختیا کونکي چې کوډ لیکي.

شکل بندي

اوس د ذخیره کولو ترتیب په اړه لږ څه. په تاریخي توګه موږ کاروو اړیکي د ذخیره کولو اداره کولو لپاره، په شمول داخلي REPO. دا داخلي ذخیره ټول هغه برخې لري چې موږ یې د داخلي موخو لپاره کاروو، د بیلګې په توګه، پخپله لیکل شوی څارنه.

.NET کور په لینوکس کې، DevOps په آس باندې

موږ هم کاروو نیوګیټ، لکه څنګه چې دا د نورو بسته بندۍ مدیرانو په پرتله ښه کیشینګ لري.

نتيجه

وروسته له دې چې موږ د جوړونې اجنټان اصلاح کړل، د جوړولو منځنۍ وخت له 12 دقیقو څخه 7 ته راټیټ شو.

که موږ ټول هغه ماشینونه وشمېرو چې موږ یې د وینډوز لپاره کارولی و، مګر په دې پروژه کې لینکس ته لاړ، موږ شاوخوا 10 ډالر خوندي کړل. او دا یوازې په جوازونو کې دي، او نور که موږ محتوا په پام کې ونیسو.

پلانونه

د راتلونکي ربع لپاره ، موږ پلان درلود چې د کوډ تحویلي اصلاح کولو باندې کار وکړو.

د مخکې جوړ شوي ډاکر عکس ته لیږدول. TFS د ډیری پلگ انونو سره یو ښه شی دی چې تاسو ته اجازه درکوي په پایپ لاین کې مدغم شئ ، پشمول د ډاکر عکس د ټریګر پراساس مجلس. موږ غواړو دا محرک د ورته لپاره جوړ کړو package-lock.json. که چیرې د پروژې جوړولو لپاره کارول شوي اجزاو ترکیب یو څه بدل شي ، موږ یو نوی ډاکر عکس رامینځته کوو. دا وروسته د راټول شوي غوښتنلیک سره کانټینر ځای په ځای کولو لپاره کارول کیږي. دا اوس قضیه نده ، مګر موږ پلان لرو چې په کبرنیټس کې د مایکرو سرویس معمارۍ ته لاړ شو ، کوم چې زموږ په شرکت کې په فعاله توګه وده کوي او د اوږدې مودې لپاره د تولید حلونه وړاندې کوي.

لنډیز

زه هرڅوک هڅوم چې وینډوز غورځوي، مګر دا ځکه چې زه نه پوهیږم چې دا څنګه پخلی کړم. دلیل یې دا دی چې ډیری خلاصې سرچینې حلونه دي د لینکس سټیک. ایا تاسو روغ یاست سرچینې خوندي کړئ. زما په اند، راتلونکې د یوې پیاوړې ټولنې سره په لینکس کې د خلاصې سرچینې حلونو پورې اړه لري.

د سپیکر پروفایل د الکساندر سینچینوف په GitHub کې.

DevOps Conf د مسلکیانو لخوا د مسلکیانو لپاره د پراختیا، ازموینې او عملیاتي پروسو ادغام په اړه کنفرانس دی. له همدې امله هغه پروژه چې الکساندر یې په اړه خبرې وکړې؟ پلي شوي او کار کوي، او د فعالیت په ورځ دوه بریالي خوشې شوي. پر په RIT++ کې DevOps Conf د می په 27 او 28 کې به د ډاکټرانو لخوا ورته ورته قضیې شتون ولري. تاسو لاهم کولی شئ په وروستي موټر کې کود شئ او راپور وړاندې کړئ یا خپل وخت واخلئ کتاب کول ټکټ موږ سره په Skolkovo کې ووینئ!

سرچینه: www.habr.com

Add a comment