NET Core در لینوکس، DevOps بر روی اسب

ما DevOps را به بهترین شکل ممکن توسعه دادیم. ما 8 نفر بودیم و واسیا باحال ترین در ویندوز بود. ناگهان واسیا رفت و من وظیفه داشتم پروژه جدیدی را راه اندازی کنم که توسط توسعه ویندوز عرضه شده بود. وقتی کل پشته توسعه ویندوز را روی میز ریختم، متوجه شدم که وضعیت دردناک است...

داستان اینگونه شروع می شود الکساندرا سینچینوا بر DevOpsConf. هنگامی که متخصص برجسته ویندوز شرکت را ترک کرد، الکساندر به این فکر کرد که اکنون چه باید بکند. البته به لینوکس سوئیچ کنید! الکساندر به شما خواهد گفت که چگونه توانسته با استفاده از نمونه پروژه تکمیل شده برای 100 کاربر نهایی، نمونه ای از توسعه ویندوز را ایجاد کند و بخشی از توسعه ویندوز را به لینوکس منتقل کند.

چگونه با استفاده از هسته TFS، Puppet، Linux .NET به راحتی و بدون زحمت پروژه را به RPM تحویل دهیم؟ اگر تیم توسعه برای اولین بار کلمات Postgres و Flyway را می شنود و مهلت آن پس فردا است، چگونه می توان از نسخه سازی یک پایگاه داده پروژه پشتیبانی کرد؟ چگونه با داکر یکپارچه شویم؟ چگونه می توان به توسعه دهندگان دات نت انگیزه داد تا ویندوز و اسموتی ها را به نفع Puppet و Linux کنار بگذارند؟ اگر نه قدرت، نه میل و نه منابع برای حفظ ویندوز در تولید وجود داشته باشد، چگونه می توان تضادهای ایدئولوژیک را حل کرد؟ در مورد این، و همچنین در مورد Web Deploy، تست، CI، در مورد شیوه های استفاده از TFS در پروژه های موجود، و، البته، در مورد عصا شکسته و راه حل های کاری، در رونوشت گزارش Alexander.

بنابراین ، واسیا رفت ، وظیفه بر عهده من است ، توسعه دهندگان بی صبرانه با چنگال ها منتظر هستند. وقتی بالاخره متوجه شدم که واسیا را نمی توان برگرداند، به کار مشغول شدم. برای شروع، من درصد Win VM ها را در ناوگان خود ارزیابی کردم. امتیاز به نفع ویندوز نبود.

از آنجایی که ما به طور فعال در حال توسعه DevOps هستیم، متوجه شدم که باید چیزی در رویکرد ارائه یک برنامه جدید تغییر کند. تنها یک راه حل وجود داشت - در صورت امکان، همه چیز را به لینوکس منتقل کنید. گوگل به من کمک کرد - در آن زمان .Net قبلاً به لینوکس منتقل شده بود و من متوجه شدم که این راه حل است!

چرا هسته دات نت در ارتباط با لینوکس؟

چندین دلیل برای این بود. بین "پرداخت پول" و "پرداخت نکردن"، اکثریت دومی را انتخاب می کنند - مثل من. یک مجوز برای MSDB حدود 1 دلار هزینه دارد؛ نگهداری ناوگان ماشین های مجازی ویندوز صدها دلار هزینه دارد. برای یک شرکت بزرگ این یک هزینه بزرگ است. از همین رو پس انداز - دلیل اول. نه مهم ترین، بلکه یکی از مهم ترین ها.

ماشین های مجازی ویندوز نسبت به برادران لینوکس خود منابع بیشتری را اشغال می کنند - آنها سنگین هستند. با توجه به مقیاس شرکت بزرگ، لینوکس را انتخاب کردیم.

این سیستم به سادگی با CI موجود یکپارچه شده است. ما خود را DevOps مترقی می دانیم، از Bamboo، Jenkins و GitLab CI استفاده می کنیم، بنابراین بیشتر کارهای ما روی لینوکس اجرا می شود.

دلیل آخر این است همراهی راحت ما نیاز داشتیم که مانع ورود "اسکورت" را کاهش دهیم - بچه هایی که بخش فنی را درک می کنند، خدمات بدون وقفه را تضمین می کنند و خدمات را از خط دوم حفظ می کنند. آنها قبلاً با پشته لینوکس آشنا بودند، بنابراین درک، پشتیبانی و نگهداری یک محصول جدید برای آنها بسیار ساده تر از صرف منابع اضافی برای درک عملکرد یکسان نرم افزار برای پلت فرم ویندوز است.

مقررات

اول از همه - راحتی راه حل جدید برای توسعه دهندگان. همه آنها برای تغییر آماده نبودند، به خصوص پس از بیان کلمه لینوکس. توسعه دهندگان ویژوال استودیو مورد علاقه خود، TFS را با تست های خودکار برای اسموتی ها و اسموتی ها می خواهند. نحوه تحویل به تولید برای آنها مهم نیست. بنابراین، تصمیم گرفتیم روند معمول را تغییر ندهیم و همه چیز را برای توسعه ویندوز بدون تغییر بگذاریم.

پروژه جدید مورد نیاز است در CI موجود ادغام شود. ریل ها قبلاً آنجا بودند و تمام کارها باید با در نظر گرفتن پارامترهای سیستم مدیریت پیکربندی، استانداردهای تحویل پذیرفته شده و سیستم های نظارت انجام می شد.

سهولت پشتیبانی و عملیات، به عنوان شرط حداقل آستانه ورود برای همه شرکت کنندگان جدید از بخش های مختلف و بخش پشتیبانی.

مهلت - دیروز.

گروه توسعه برنده

در آن زمان تیم ویندوز با چه چیزی کار می کرد؟

حالا می توانم با اطمینان این را بگویم IdentityServer4 یک جایگزین رایگان عالی برای ADFS با قابلیت های مشابه است هسته چارچوب نهاد - بهشتی برای یک توسعه‌دهنده، که در آن لازم نیست برای نوشتن اسکریپت‌های SQL زحمت بکشید، اما پرس‌و‌جوها را در پایگاه داده با اصطلاحات OOP توصیف کنید. اما پس از آن، در طول بحث در مورد برنامه عمل، من به این پشته نگاه کردم که گویی خط میخی سومری است و فقط PostgreSQL و Git را تشخیص می دهد.

در آن زمان ما به طور فعال استفاده می کردیم عروسک خیمه شب بازی به عنوان یک سیستم مدیریت پیکربندی در اکثر پروژه هایمان استفاده کردیم GitLab CI, کشسان، متعادل خدمات بار بالا با استفاده از HAProxy همه چیز را با Zabbix، رباط ها گرافانا и تیتان فرزند پاپتوس, شکارچیو همه اینها روی تکه های آهن می چرخید HP c ESXi بر آموزش VMware. همه آن را می دانند - کلاسیک این ژانر.

بیایید نگاه کنیم و سعی کنیم بفهمیم قبل از شروع همه این مداخلات چه اتفاقی افتاده است.

چی شد

TFS یک سیستم نسبتاً قدرتمند است که نه تنها کد را از توسعه‌دهنده به دستگاه تولید نهایی تحویل می‌دهد، بلکه مجموعه‌ای برای ادغام بسیار انعطاف‌پذیر با سرویس‌های مختلف دارد - برای ارائه CI در سطح بین پلتفرم.

قبلاً اینها پنجره های جامد بودند. TFS از چندین عامل Build استفاده می کرد که برای مونتاژ بسیاری از پروژه ها استفاده می شد. هر عامل دارای 3-4 کارگر برای موازی سازی وظایف و بهینه سازی فرآیند است. سپس، طبق برنامه های انتشار، TFS بیلد تازه پخته شده را به سرور برنامه ویندوز تحویل داد.

می خواستیم به چه چیزی برسیم؟

ما از TFS برای تحویل و توسعه استفاده می کنیم و برنامه را روی سرور لینوکس Application اجرا می کنیم و نوعی جادو بین آنها وجود دارد. این جعبه سحر و جادو و نمک کار در پیش است. قبل از اینکه آن را جدا کنم، یک قدم کنار می‌روم و چند کلمه در مورد برنامه می‌گویم.

پروژه

این برنامه عملکردی را برای رسیدگی به کارت های پیش پرداخت ارائه می دهد.

مشتری

دو نوع کاربر وجود داشت. اول با ورود به سیستم با استفاده از گواهینامه SSL SHA-2 دسترسی پیدا کرد. U دوم دسترسی با استفاده از ورود و رمز عبور وجود دارد.

HAProxy

سپس درخواست مشتری به HAProxy رفت که مشکلات زیر را حل کرد:

• مجوز اولیه؛
• خاتمه SSL؛
• تنظیم درخواست های HTTP؛
• درخواست های پخش

گواهی مشتری در طول زنجیره تأیید شد. ما - قدرت و ما می توانیم این کار را بپردازیم، زیرا خودمان برای مشتریان خدمات گواهی صادر می کنیم.

به نکته سوم توجه کنید، کمی بعد به آن باز خواهیم گشت.

بخش مدیریت

آنها برنامه ریزی کردند که باطن را روی لینوکس بسازند. Backend با پایگاه داده تعامل می کند، لیست لازم از امتیازات را بارگیری می کند و سپس بسته به اینکه کاربر مجاز چه امتیازاتی دارد، امکان دسترسی به امضای اسناد مالی و ارسال آنها برای اجرا یا ایجاد نوعی گزارش را فراهم می کند.

صرفه جویی با HAProxy

علاوه بر دو زمینه ای که هر مشتری پیمایش می کرد، یک زمینه هویتی نیز وجود داشت. IdentityServer4 فقط به شما امکان می دهد وارد شوید، این یک آنالوگ رایگان و قدرتمند برای است ADFS - خدمات فدراسیون Active Directory.

درخواست هویت در چند مرحله پردازش شد. گام اول - مشتری وارد باطن شد، که با این سرور ارتباط برقرار می کرد و وجود توکن را برای مشتری بررسی می کرد. اگر پیدا نشد، درخواست به متنی که از آن آمده بازگردانده می‌شود، اما با تغییر مسیر، و با تغییر مسیر به هویت می‌رود.

مرحله دوم - درخواست دریافت شد به صفحه مجوز در IdentityServer، جایی که مشتری ثبت نام کرد، و آن توکن مورد انتظار در پایگاه داده IdentityServer ظاهر شد.

مرحله سوم - مشتری به عقب هدایت شد به زمینه ای که از آن آمده است.

IdentityServer4 یک ویژگی دارد: پاسخ به درخواست بازگشت را از طریق HTTP برمی گرداند. مهم نیست که چقدر با راه اندازی سرور مشکل داشتیم، مهم نیست که چقدر خودمان را با مستندات روشن می کردیم، هر بار یک درخواست مشتری اولیه با یک URL که از طریق HTTPS آمده بود دریافت می کردیم، و IdentityServer همان زمینه را باز می گرداند، اما با HTTP. ما شوکه شدیم! و همه اینها را از طریق زمینه هویت به HAProxy منتقل کردیم و در هدرها باید پروتکل HTTP را به HTTPS تغییر می دادیم.

بهبود چیست و کجا پس انداز کردید؟

ما با استفاده از یک راه حل رایگان برای مجوز دادن به گروهی از کاربران، منابع، پول پس انداز کردیم، زیرا IdentityServer4 را به عنوان یک گره جداگانه در یک بخش جداگانه قرار ندادیم، بلکه از آن به همراه باطن در همان سروری که باطن برنامه اجرا می شود استفاده کردیم. .

چگونه باید کار کند

بنابراین، همانطور که قول داده بودم - جعبه جادویی. ما قبلاً درک می کنیم که تضمین شده است که به سمت لینوکس حرکت کنیم. بیایید وظایف خاصی را که نیاز به راه حل دارند، تدوین کنیم.

نمایش عروسکی برای ارائه و مدیریت سرویس و پیکربندی برنامه، دستور العمل های جالبی باید نوشته می شد. یک رول مداد به خوبی نشان می دهد که چقدر سریع و کارآمد انجام شده است.

روش تحویل. استاندارد RPM است. همه می دانند که در لینوکس نمی توانید بدون آن کار کنید، اما خود پروژه، پس از مونتاژ، مجموعه ای از فایل های DLL قابل اجرا بود. حدود 150 نفر بودند، پروژه بسیار دشوار بود. تنها راه حل هماهنگ، بسته بندی این باینری در RPM و استقرار برنامه از آن است.

نسخه سازی. ما مجبور بودیم اغلب منتشر کنیم، و باید تصمیم می‌گرفتیم که چگونه نام بسته را تشکیل دهیم. این یک سوال در مورد سطح ادغام با TFS است. ما یک build agent در لینوکس داشتیم. هنگامی که TFS وظیفه ای را برای یک handler - worker - به Build agent می فرستد، مجموعه ای از متغیرها را نیز به آن ارسال می کند که در نهایت به محیط پردازش handler ختم می شود. این متغیرهای محیطی شامل نام ساخت، نام نسخه و سایر متغیرها هستند. اطلاعات بیشتر در مورد این را در بخش "ساخت بسته RPM" بخوانید.

راه اندازی TFS به راه اندازی خط لوله رسید. قبلاً همه پروژه‌های ویندوز را روی عامل‌های ویندوز جمع‌آوری می‌کردیم، اما اکنون یک عامل لینوکس ظاهر می‌شود - یک عامل Build، که باید در گروه ساخت گنجانده شود، با برخی از مصنوعات غنی شود و به شما بگوید که چه نوع پروژه‌هایی روی این عامل بیلد ساخته خواهد شد. ، و به نوعی Pipeline را اصلاح کنید.

IdentityServer. ADFS راه ما نیست، ما به سمت منبع باز می رویم.

بیایید اجزا را مرور کنیم.

جعبه سحر و جادو

از چهار قسمت تشکیل شده است.

عامل لینوکس بیلد. لینوکس، زیرا ما برای آن می سازیم - منطقی است. این قسمت در سه مرحله انجام شد.

• کارگران را پیکربندی کنید و نه به تنهایی، زیرا کار توزیع شده روی پروژه انتظار می رفت.
• NET Core 1.x را نصب کنید. چرا 1.x زمانی که نسخه 2.0 از قبل در مخزن استاندارد موجود است؟ چون زمانی که توسعه را شروع کردیم، نسخه پایدار آن 1.09 بود و قرار شد پروژه بر اساس آن ساخته شود.
• Git 2.x.

RPM-repository. بسته های RPM باید در جایی ذخیره شوند. فرض بر این بود که ما از همان مخزن RPM شرکتی استفاده می کنیم که برای همه هاست های لینوکس در دسترس است. همین کار را کردند. سرور مخزن پیکربندی شده است قلاب وب که بسته RPM مورد نیاز را از محل مشخص شده دانلود کرده است. نسخه بسته توسط عامل Build به webhook گزارش شد.

GitLab توجه! GitLab در اینجا نه توسط توسعه دهندگان، بلکه توسط بخش عملیات برای کنترل نسخه های برنامه، نسخه های بسته، نظارت بر وضعیت تمام ماشین های لینوکس استفاده می شود، و دستور العمل را ذخیره می کند - همه نمایش های عروسکی.

عروسک خیمه شب بازی - تمام مسائل بحث برانگیز را حل می کند و دقیقاً پیکربندی مورد نظر ما از Gitlab را ارائه می دهد.

ما شروع به شیرجه می کنیم. تحویل DLL به RPM چگونه کار می کند؟

تحویل DDL به RPM

فرض کنید یک ستاره راک توسعه دات نت داریم. از ویژوال استودیو استفاده می کند و یک شاخه انتشار ایجاد می کند. پس از آن، آن را در Git آپلود می کند، و Git اینجا یک موجودیت TFS است، یعنی مخزن برنامه ای است که توسعه دهنده با آن کار می کند.

پس از آن TFS می بیند که یک commit جدید وارد شده است. کدام اپلیکیشن؟ در تنظیمات TFS برچسبی وجود دارد که نشان می دهد یک عامل Build خاص چه منابعی دارد. در این حالت، او می بیند که ما در حال ساخت یک پروژه NET Core هستیم و یک عامل Linux Build را از استخر انتخاب می کند.

عامل Build منابع را دریافت و موارد لازم را دانلود می کند وابستگی از مخزن دات نت، npm و غیره. و پس از ساخت خود برنامه و بسته بندی های بعدی، بسته RPM را به مخزن RPM ارسال می کند.

از طرفی موارد زیر اتفاق می افتد. مهندس بخش عملیات مستقیماً در اجرای پروژه مشارکت دارد: او نسخه‌های بسته‌ها را تغییر می‌دهد هیرا در مخزنی که دستور برنامه در آن ذخیره می شود، پس از آن Puppet فعال می شود یام، بسته جدید را از مخزن واکشی می کند و نسخه جدید برنامه آماده استفاده است.

همه چیز در کلمات ساده است، اما در داخل خود عامل بیلد چه اتفاقی می افتد؟

بسته بندی DLL RPM

منابع پروژه و کار ساخت را از TFS دریافت کرد. عامل ساخت شروع به ساخت پروژه خود از منابع می کند. پروژه مونتاژ شده به صورت مجموعه موجود است فایل های DLL، که در یک آرشیو فشرده برای کاهش بار روی فایل سیستم بسته بندی شده اند.

آرشیو ZIP دور ریخته می شود به دایرکتوری ساخت بسته RPM. در مرحله بعد، اسکریپت Bash متغیرهای محیطی را مقداردهی اولیه می کند، نسخه Build، نسخه پروژه، مسیر دایرکتوری ساخت را پیدا می کند و RPM-build را اجرا می کند. پس از تکمیل ساخت، بسته به منتشر می شود مخزن محلیکه در عامل Build قرار دارد.

سپس، از عامل Build به سرور در مخزن RPM درخواست JSON ارسال شد با ذکر نام نسخه و ساخت. Webhook که قبلاً در مورد آن صحبت کردم، این بسته را از مخزن محلی در عامل Build دانلود می کند و اسمبلی جدید را برای نصب در دسترس قرار می دهد.

چرا این طرح تحویل بسته خاص به مخزن RPM؟ چرا نمی توانم بلافاصله بسته مونتاژ شده را به مخزن ارسال کنم؟ واقعیت این است که این یک شرط برای اطمینان از ایمنی است. این سناریو امکان آپلود بسته‌های RPM توسط افراد غیرمجاز را در سروری که برای همه ماشین‌های لینوکس قابل دسترسی است، محدود می‌کند.

نسخه سازی پایگاه داده

در مشاوره با تیم توسعه، معلوم شد که بچه ها به MS SQL نزدیک تر بودند، اما در اکثر پروژه های غیر ویندوزی ما قبلاً با تمام توان از PostgreSQL استفاده می کردیم. از آنجایی که قبلاً تصمیم گرفته بودیم همه چیز را که پرداخت می‌شود کنار بگذاریم، در اینجا نیز شروع به استفاده از PostgreSQL کردیم.

در این قسمت می‌خواهم به شما بگویم که چگونه پایگاه داده را نسخه‌سازی کردیم و چگونه بین Flyway و Entity Framework Core را انتخاب کردیم. بیایید به مزایا و معایب آنها نگاه کنیم.

منفی

Flyway فقط یک طرف می رود، ما ما نمی توانیم به عقب برگردیم - این یک نقطه ضعف قابل توجه است. می‌توانید آن را با Entity Framework Core به روش‌های دیگری مقایسه کنید - از نظر راحتی توسعه‌دهنده. یادتان هست که ما این را سرلوحه قرار دادیم و معیار اصلی تغییر نکردن چیزی برای توسعه ویندوز بود.

برای Flyway us نوعی لفاف مورد نیاز بودتا بچه ها ننویسند پرس و جوهای SQL. آنها به فعالیت در شرایط OOP بسیار نزدیکتر هستند. ما دستورالعمل هایی را برای کار با اشیاء پایگاه داده نوشتیم، یک پرس و جوی SQL ایجاد کردیم و آن را اجرا کردیم. نسخه جدید پایگاه داده آماده است، آزمایش شده است - همه چیز خوب است، همه چیز کار می کند.

Entity Framework Core یک منهای دارد - تحت بارهای سنگین آن پرس و جوهای SQL کمتر از حد مطلوب را ایجاد می کند، و کاهش در پایگاه داده می تواند قابل توجه باشد. اما از آنجایی که ما سرویس پربار نداریم، بار را در صدها RPS محاسبه نمی کنیم، این خطرات را پذیرفتیم و مشکل را به آینده خود واگذار کردیم.

مزایا

هسته چارچوب نهاد خارج از جعبه کار می کند و توسعه آن آسان است، و فلای وی به راحتی با CI موجود ادغام می شود. اما ما آن را برای توسعه دهندگان راحت می کنیم :)

روال جمع آوری

Puppet می بیند که یک تغییر در نسخه بسته در راه است، از جمله نسخه ای که مسئول مهاجرت است. ابتدا، بسته ای را نصب می کند که حاوی اسکریپت های مهاجرت و عملکردهای مرتبط با پایگاه داده است. پس از این، برنامه ای که با پایگاه داده کار می کند دوباره راه اندازی می شود. سپس نصب اجزای باقیمانده می آید. ترتیب نصب بسته ها و راه اندازی برنامه ها در مانیفست عروسکی توضیح داده شده است.

برنامه‌ها از داده‌های حساس مانند نشانه‌ها، رمزهای عبور پایگاه داده استفاده می‌کنند، همه اینها از Puppet Master به پیکربندی کشیده می‌شوند، جایی که به شکل رمزگذاری شده ذخیره می‌شوند.

مشکلات TFS

بعد از اینکه تصمیم گرفتیم و متوجه شدیم که همه چیز واقعاً برای ما کار می کند، تصمیم گرفتم به اتفاقاتی که در مورد اسمبلی ها در TFS به طور کلی برای بخش توسعه Win در پروژه های دیگر می گذرد - ببینم که آیا ما به سرعت می سازیم/انتشار می کنیم یا نه، و مشکلات قابل توجهی در سرعت کشف کرد.

جمع آوری یکی از پروژه های اصلی 12 تا 15 دقیقه طول می کشد - این مدت زمان زیادی است، شما نمی توانید اینطور زندگی کنید. تجزیه و تحلیل سریع کاهش وحشتناکی در I/O را نشان داد و این در آرایه ها بود.

پس از تجزیه و تحلیل آن جزء به جزء، سه کانون را شناسایی کردم. اولین - آنتی ویروس کسپرسکی، که منابع را در تمام عوامل ساخت ویندوز اسکن می کند. دومین - ویندوز نمایه ساز. غیرفعال نشد و همه چیز به صورت بلادرنگ در عوامل بیلد در طول فرآیند استقرار نمایه شد.

سوم - Npm نصب کنید. معلوم شد که در بیشتر خطوط لوله ما دقیقاً از این سناریو استفاده کردیم. چرا او بد است؟ رویه نصب Npm زمانی اجرا می شود که درخت وابستگی در آن تشکیل شود pack-lock.json، که در آن نسخه های بسته هایی که برای ساخت پروژه استفاده خواهند شد، ثبت می شوند. نکته منفی این است که نصب Npm هر بار آخرین نسخه بسته ها را از اینترنت بیرون می کشد و این در مورد یک پروژه بزرگ زمان زیادی را می گیرد.

توسعه دهندگان گاهی اوقات روی یک ماشین محلی آزمایش می کنند تا نحوه عملکرد یک بخش خاص یا کل پروژه را آزمایش کنند. گاهی اوقات معلوم می شد که همه چیز به صورت محلی خنک است، اما آنها آن را مونتاژ کردند، آن را رول کردند و هیچ چیز کار نکرد. ما شروع به کشف مشکل می کنیم - بله، نسخه های مختلف بسته های دارای وابستگی.

تصمیم

• منابع در استثناهای AV.
• غیرفعال کردن نمایه سازی
• قابل اعتماد و متخصص npm ci.

مزایای npm ci این است که ما درخت وابستگی را یک بار جمع می کنیم، و ما این فرصت را داریم که به توسعه دهنده ارائه دهیم لیست فعلی بسته ها، که می تواند هر چقدر که دوست دارد به صورت محلی با آن آزمایش کند. این باعث صرفه جویی در زمان می شود توسعه دهندگانی که کد می نویسند.

پیکربندی

حالا کمی در مورد پیکربندی مخزن. ما از لحاظ تاریخی استفاده می کنیم رابطه برای مدیریت مخازن، از جمله REPO داخلی. این مخزن داخلی شامل تمام مؤلفه هایی است که ما برای مقاصد داخلی از آنها استفاده می کنیم، به عنوان مثال، نظارت خودنوشته.

ما نیز استفاده می کنیم NuGet، زیرا در مقایسه با سایر پکیج منیجرها، کش بهتری دارد.

نتیجه

پس از بهینه سازی Build Agents، میانگین زمان ساخت از 12 دقیقه به 7 کاهش یافت.

اگر تمام ماشین‌هایی را که می‌توانستیم برای ویندوز استفاده کنیم، اما در این پروژه به لینوکس تغییر دادیم، حساب کنیم، حدود 10 دلار صرفه‌جویی کرده‌ایم.

طرح

برای سه ماهه آینده، ما برنامه ریزی کردیم که روی بهینه سازی تحویل کد کار کنیم.

جابجایی به یک تصویر از پیش ساخته Docker. TFS یک چیز جالب با افزونه های بسیاری است که به شما امکان می دهد در Pipeline ادغام شوید، از جمله مونتاژ مبتنی بر ماشه، مثلاً، یک تصویر Docker. ما می خواهیم این ماشه را برای همان یکی ایجاد کنیم pack-lock.json. اگر ترکیب اجزای مورد استفاده برای ساخت پروژه به نحوی تغییر کند، یک تصویر Docker جدید می سازیم. بعداً برای استقرار کانتینر با برنامه مونتاژ شده استفاده می شود. اکنون اینطور نیست، اما ما در حال برنامه ریزی برای تغییر معماری میکروسرویس در Kubernetes هستیم که به طور فعال در شرکت ما در حال توسعه است و برای مدت طولانی به راه حل های تولیدی ارائه می دهد.

خلاصه

من همه را تشویق می کنم که ویندوز را دور بریزند، اما دلیلش این نیست که من نمی دانم چگونه آن را بپزم. دلیل آن این است که اکثر راه حل های منبع باز هستند پشته لینوکس. حالت خوبه صرفه جویی در منابع. به نظر من، آینده متعلق به راه حل های منبع باز در لینوکس با یک جامعه قدرتمند است.

مشخصات سخنران الکساندر سینچینوف در GitHub.

DevOps Conf کنفرانسی در مورد ادغام فرآیندهای توسعه، آزمایش و عملیات برای متخصصان توسط متخصصان است. به همین دلیل پروژه ای که الکساندر در مورد آن صحبت کرد؟ اجرا شده و کار می کند و در روز اجرا دو نسخه موفق منتشر شد. بر DevOps Conf در RIT++ در 27 و 28 می موارد مشابه بیشتری از سوی تمرین‌کنندگان وجود خواهد داشت. هنوز می توانید به آخرین کالسکه بپرید و ارسال گزارش یا وقت خود را صرف کنید رزرو کردن بلیط. ما را در Skolkovo ملاقات کنید!

منبع: www.habr.com