Biz DevOps-ni iloji boricha ishlab chiqdik. Biz 8 kishi edik va Vasya Windowsda eng zo'r edi. To'satdan Vasya ketdi va men Windows ishlanmasi tomonidan taqdim etilgan yangi loyihani ishga tushirish vazifasini oldim. Men Windows-ning barcha ishlab chiqish to'plamini stolga tashlaganimda, vaziyat og'riqli ekanligini angladim ...
Hikoya shunday boshlanadi Aleksandra Sinchinova haqida . Windows-ning yetakchi mutaxassisi kompaniyani tark etgach, Aleksandr endi nima qilishni hayron qoldi. Albatta, Linuxga o'ting! Aleksandr sizga 100 000 oxirgi foydalanuvchi uchun tugallangan loyiha misolidan foydalanib, qanday qilib pretsedent yaratishga va Windows rivojlanishining bir qismini Linuxga o'tkazishga muvaffaq bo'lganini aytib beradi.
TFS, Puppet, Linux .NET yadrosi yordamida loyihani RPM ga qanday qilib oson va oson yetkazib berish mumkin? Agar ishlab chiqish guruhi Postgres va Flyway so'zlarini birinchi marta eshitsa va oxirgi muddat ertangi kun bo'lsa, loyiha ma'lumotlar bazasi versiyasini qanday qo'llab-quvvatlash kerak? Docker bilan qanday integratsiya qilish mumkin? .NET ishlab chiquvchilarini Windows va smoyulardan voz kechib, Puppet va Linux foydasiga qanday undash mumkin? Windows-ni ishlab chiqarishda saqlash uchun na kuch, na xohish va na resurslar bo'lmasa, mafkuraviy mojarolarni qanday hal qilish mumkin? Bu haqida, shuningdek, Web Deploy, test, CI, mavjud loyihalarda TFS-dan foydalanish amaliyotlari va, albatta, Aleksandr hisobotining stenogrammasida singan tayoqchalar va ishchi echimlar haqida.
Shunday qilib, Vasya ketdi, vazifa menda, ishlab chiquvchilar sabrsizlik bilan vilkalar bilan kutishmoqda. Nihoyat, Vasyani qaytarib bo'lmasligini tushunganimda, men ishga kirishdim. Boshlash uchun men parkimizdagi Win VM-larining foizini baholadim. Hisob Windows foydasiga emas edi.
Biz DevOps-ni faol ravishda ishlab chiqayotganimiz sababli, men yangi dasturni taqdim etishda nimanidir o'zgartirish kerakligini angladim. Faqat bitta yechim bor edi - iloji bo'lsa, hamma narsani Linuxga o'tkazing. Google menga yordam berdi - o'sha paytda .Net allaqachon Linuxga ko'chirilgan edi va men bu yechim ekanligini tushundim!
Nima uchun .NET yadrosi Linux bilan birgalikda?
Buning bir qancha sabablari bor edi. "Pul to'lash" va "to'lamaslik" o'rtasida ko'pchilik ikkinchisini tanlaydi - men kabi. MSDB litsenziyasi taxminan 1 dollar turadi; Windows virtual mashinalari parkini saqlash yuzlab dollarga tushadi. Katta kompaniya uchun bu katta xarajat. Shunung uchun jamg'armalar - birinchi sabab. Eng muhimi emas, balki eng muhimlaridan biri.
Windows virtual mashinalari Linux birodarlariga qaraganda ko'proq resurslarni egallaydi - ular og'ir. Katta kompaniyaning ko'lamini hisobga olib, biz Linuxni tanladik.
Tizim oddiygina mavjud CI bilan birlashtirilgan. Biz o'zimizni progressiv DevOps deb hisoblaymiz, biz Bamboo, Jenkins va GitLab CI dan foydalanamiz, shuning uchun ishimizning aksariyati Linuxda ishlaydi.
Oxirgi sabab qulay hamrohlik. Biz texnik qismni tushunadigan, uzluksiz xizmat ko'rsatishni ta'minlaydigan va ikkinchi qatordan xizmat ko'rsatadigan "eskortlar" uchun kirish to'siqlarini kamaytirishimiz kerak edi. Ular Linux stekini allaqachon bilishgan, shuning uchun ular uchun Windows platformasi uchun dasturiy ta'minotning bir xil funksionalligini tushunish uchun qo'shimcha resurslarni sarflashdan ko'ra, yangi mahsulotni tushunish, qo'llab-quvvatlash va saqlash ancha osondir.
talablar
Birinchi navbatda - ishlab chiquvchilar uchun yangi yechimning qulayligi. Ularning hammasi ham o'zgarishga tayyor emas edi, ayniqsa Linux so'zi aytilgandan keyin. Ishlab chiquvchilar o'zlarining sevimli Visual Studio TFS-ni yig'ilishlar va smetalar uchun avtotestlarga ega bo'lishni xohlashadi. Ishlab chiqarishga qanday etkazib berish ular uchun muhim emas. Shuning uchun biz odatiy jarayonni o'zgartirmaslikka qaror qildik va Windows rivojlanishi uchun hamma narsani o'zgarishsiz qoldirdik.
Yangi loyiha kerak mavjud CI ga integratsiya qilish. Reylar allaqachon mavjud edi va barcha ishlarni konfiguratsiyani boshqarish tizimining parametrlarini, qabul qilingan etkazib berish standartlarini va monitoring tizimlarini hisobga olgan holda bajarish kerak edi.
Qo'llab-quvvatlash va ishlash qulayligi, turli bo'linmalar va qo'llab-quvvatlash bo'limidan barcha yangi ishtirokchilar uchun minimal kirish chegarasi uchun shart sifatida.
Muddati - kecha.
Win Development Group
O'sha paytda Windows jamoasi nima bilan ishlagan?
Endi men buni ishonch bilan ayta olaman IdentityServer4 shunga o'xshash imkoniyatlarga ega ADFS uchun ajoyib bepul muqobil yoki nima Entity Framework Core - ishlab chiquvchi uchun jannat, bu yerda siz SQL skriptlarini yozish bilan ovora bo'lishingiz shart emas, balki ma'lumotlar bazasidagi so'rovlarni OOP shartlarida tasvirlab bering. Ammo keyin, harakatlar rejasini muhokama qilish paytida, men bu stekga xuddi shumer mixxat yozuvi kabi qaradim, faqat PostgreSQL va Gitni taniyman.
O'sha paytda biz faol foydalanardik Qo'g'irchoq konfiguratsiyani boshqarish tizimi sifatida. Ko'pgina loyihalarimizda biz foydalandik GitLab CI, elastik, foydalanish muvozanatli yuqori yuk xizmatlari HAProxy bilan hammasini kuzatib bordi Zabbix, ligamentlar grafana и Prometheus, Jaeger, va bularning hammasi temir parchalari ustida aylanardi HP c ESXi haqida VMware. Buni hamma biladi - bu janrning klassikasi.
Keling, ushbu aralashuvlarni boshlashdan oldin nima bo'lganini ko'rib chiqaylik va tushunishga harakat qilaylik.
Nima bo'ldi
TFS - bu juda kuchli tizim bo'lib, u nafaqat ishlab chiquvchidan kodni yakuniy ishlab chiqarish mashinasiga etkazib beradi, balki turli xizmatlar bilan juda moslashuvchan integratsiya uchun to'plamga ega - o'zaro faoliyat platformalar darajasida CI bilan ta'minlash.
Ilgari bu qattiq derazalar edi. TFS bir nechta Build agentlaridan foydalangan, ular ko'plab loyihalarni yig'ish uchun ishlatilgan. Har bir agentda vazifalarni parallellashtirish va jarayonni optimallashtirish uchun 3-4 ishchi mavjud. Keyin, reliz rejalariga ko'ra, TFS yangi pishirilgan Buildni Windows dastur serveriga yetkazib berdi.
Biz nimaga erishmoqchi edik?
Biz yetkazib berish va ishlab chiqish uchun TFS dan foydalanamiz va dasturni Linux Application serverida ishga tushiramiz va ular orasida qandaydir sehr bor. Bu Sehrli quti va oldinda ishning tuzi bor. Uni ajratishdan oldin, men bir qadam chetga olib, dastur haqida bir necha so'z aytaman.
Loyiha
Ilova oldindan to'langan kartalar bilan ishlash funksiyasini taqdim etadi.
mijoz
Foydalanuvchilarning ikki turi mavjud edi. birinchi SSL SHA-2 sertifikati yordamida tizimga kirish orqali ruxsat oldi. U ikkinchisi login va parol yordamida kirish mavjud edi.
HAProksi
Keyin mijoz so'rovi HAProxy-ga o'tdi, u quyidagi muammolarni hal qildi:
- birlamchi ruxsatnoma;
- SSLni tugatish;
- HTTP so'rovlarini sozlash;
- translyatsiya so'rovlari.
Mijoz sertifikati zanjir bo'ylab tekshirildi. Biz - hokimiyat va biz bunga qodirmiz, chunki biz o'zimiz xizmat ko'rsatuvchi mijozlarga sertifikatlar beramiz.
Uchinchi nuqtaga e'tibor bering, biz unga birozdan keyin qaytamiz.
Orqa tomon
Ular Linuxda backend qilishni rejalashtirishgan. Backend ma'lumotlar bazasi bilan o'zaro ta'sir qiladi, kerakli imtiyozlar ro'yxatini yuklaydi va keyin vakolatli foydalanuvchi qanday imtiyozlarga ega ekanligiga qarab, moliyaviy hujjatlarni imzolash va ularni bajarish uchun jo'natish yoki qandaydir hisobot yaratish imkonini beradi.
HAProxy bilan tejash
Har bir mijoz navigatsiya qilgan ikkita kontekstdan tashqari, identifikatsiya konteksti ham mavjud edi. IdentityServer4 faqat tizimga kirishga imkon beradi, bu bepul va kuchli analog ADFS - Active Directory federatsiyasi xizmatlari.
Shaxsni aniqlash so‘rovi bir necha bosqichda ko‘rib chiqildi. Birinchi qadam - mijozlar orqa qismga kirdi, bu server bilan bog'langan va mijoz uchun token mavjudligini tekshirgan. Agar u topilmasa, so'rov u kelgan kontekstga qaytarildi, lekin qayta yo'naltirish bilan va qayta yo'naltirish bilan u identifikatsiyaga o'tdi.
Ikkinchi bosqich - so'rov qabul qilindi IdentityServer-dagi avtorizatsiya sahifasiga, mijoz ro'yxatdan o'tgan joyda va bu uzoq kutilgan token IdentityServer ma'lumotlar bazasida paydo bo'ldi.
Uchinchi qadam - mijoz orqaga yo'naltirildi kelib chiqqan kontekstga.
IdentityServer4 quyidagi xususiyatga ega: u HTTP orqali qaytarish so'roviga javobni qaytaradi. Serverni o'rnatishda qanchalik qiynalganimizdan qat'iy nazar, biz hujjatlar bilan o'zimizni qanchalik yoritgan bo'lishimizdan qat'iy nazar, har safar HTTPS orqali kelgan URL bilan mijozning dastlabki so'rovini oldik va IdentityServer xuddi shu kontekstni qaytardi, lekin HTTP bilan. Biz hayratda qoldik! Va biz bularning barchasini identifikatsiya konteksti orqali HAProxy-ga o'tkazdik va sarlavhalarda HTTP protokolini HTTPS-ga o'zgartirishimiz kerak edi.
Yaxshilanish nima va qayerda saqladingiz?
Biz foydalanuvchilar guruhini, resurslarni avtorizatsiya qilish uchun bepul yechimdan foydalangan holda pulni tejadik, chunki biz IdentityServer4-ni alohida segmentda alohida tugun sifatida joylashtirmadik, lekin uni dasturning backend ishlaydigan serverida backend bilan birga ishlatdik. .
Qanday ishlashi kerak
Shunday qilib, men va'da qilganimdek - Sehrli quti. Biz allaqachon Linuxga o'tishimiz kafolatlanganligini tushunamiz. Keling, yechimlarni talab qiladigan aniq vazifalarni tuzamiz.
Qo'g'irchoq namoyon bo'ladi. Xizmat va dastur konfiguratsiyasini yetkazib berish va boshqarish uchun ajoyib retseptlar yozilishi kerak edi. Bir rulonli qalam bu qanchalik tez va samarali bajarilganligini aniq ko'rsatadi.
Yetkazib berish usuli. Standart - RPM. Linuxda siz usiz qilolmasligingizni hamma tushunadi, lekin loyihaning o'zi yig'ilgandan so'ng bajariladigan DLL fayllari to'plami edi. Ularning 150 ga yaqini bor edi, loyiha juda qiyin edi. Yagona uyg'un yechim bu ikkilik faylni RPM ga to'plash va undan dasturni joylashtirishdir.
Versiyalash. Biz juda tez-tez chiqarishimiz kerak edi va biz paket nomini qanday shakllantirishni hal qilishimiz kerak edi. Bu TFS bilan integratsiya darajasi haqida savol. Bizda Linuxda qurish agenti bor edi. TFS ishlov beruvchiga - ishchiga - Build agentiga topshiriq yuborganda, u ishlov berish jarayoni muhitida tugaydigan bir qator o'zgaruvchilarni ham uzatadi. Ushbu muhit o'zgaruvchilari Build nomini, versiya nomini va boshqa o'zgaruvchilarni o'z ichiga oladi. Bu haqda ko'proq "RPM paketini yaratish" bo'limida o'qing.
TFSni sozlash Quvur liniyasini o'rnatishga tushdi. Ilgari biz barcha Windows loyihalarini Windows agentlarida to'plagan edik, ammo hozir Linux agenti paydo bo'ladi - Build agenti, uni qurish guruhiga kiritish kerak, ba'zi artefaktlar bilan boyitilgan va ushbu Build agentida qanday turdagi loyihalar qurilishi haqida ma'lumot beradi. , va qandaydir tarzda quvur liniyasini o'zgartiring.
IdentityServer. ADFS bizning usulimiz emas, biz Ochiq manbaga boramiz.
Keling, komponentlarni ko'rib chiqaylik.
Sehrli quti
To'rt qismdan iborat.
Linux Build agenti. Linux, chunki biz buning uchun quramiz - bu mantiqiy. Ushbu qism uch bosqichda amalga oshirildi.
- Ishchilarni sozlash va yolg'iz emas, chunki loyiha bo'yicha taqsimlangan ish kutilgan edi.
- .NET Core 1.x ni oʻrnating. Nega 1.x standart omborda 2.0 mavjud bo'lsa? Chunki biz ishlab chiqishni boshlaganimizda, barqaror versiya 1.09 edi va loyihani uning asosida yaratishga qaror qilindi.
- Git 2.x.
RPM ombori. RPM paketlarini biror joyda saqlash kerak edi. Biz barcha Linux xostlari uchun mavjud bo'lgan bir xil korporativ RPM omboridan foydalanamiz deb taxmin qilingan edi. Ular shunday qilishdi. Ombor serveri sozlangan veb -kanca belgilangan joydan kerakli RPM paketini yuklab olgan. Paket versiyasi haqida Build agenti vebhukga xabar berdi.
GitLab. Diqqat! GitLab bu erda ishlab chiquvchilar tomonidan emas, balki operatsion bo'lim tomonidan dastur versiyalarini, paket versiyalarini boshqarish, barcha Linux mashinalarining holatini kuzatish uchun ishlatiladi va u retseptni saqlaydi - barcha Qo'g'irchoq manifestlari.
Qo'g'irchoq — barcha bahsli masalalarni hal qiladi va Gitlab-dan biz xohlagan konfiguratsiyani taqdim etadi.
Biz sho'ng'ishni boshlaymiz. RPM ga DLL yetkazib berish qanday ishlaydi?
DDLni RPMgacha yetkazib berish
Aytaylik, bizda .NET rivojlanishining rok yulduzi bor. U Visual Studio dan foydalanadi va reliz filialini yaratadi. Shundan so'ng, u uni Git-ga yuklaydi va Git bu erda TFS ob'ekti, ya'ni ishlab chiquvchi ishlaydigan ilovalar ombori.
Shundan so'ng TFS yangi majburiyat kelganligini ko'radi. Qaysi ilova? TFS sozlamalarida ma'lum bir Build agenti qanday resurslarga ega ekanligini ko'rsatadigan yorliq mavjud. Bunday holda, u biz .NET Core loyihasini qurayotganimizni ko'radi va hovuzdan Linux Build agentini tanlaydi.
Qurilish agenti manbalarni oladi va kerakli narsalarni yuklab oladi bog'liqliklar .NET omboridan, npm va boshqalar. va dasturni o'zi va keyingi qadoqlashdan so'ng RPM paketini RPM omboriga yuboradi.
Boshqa tomondan, quyidagilar sodir bo'ladi. Operatsion bo'limi muhandisi loyihani amalga oshirishda bevosita ishtirok etadi: u paketlarning versiyalarini o'zgartiradi Hiera dastur retsepti saqlanadigan omborda, shundan so'ng Qo'g'irchoq ishga tushadi Yum, yangi paketni ombordan oladi va ilovaning yangi versiyasi foydalanishga tayyor.
Hammasi so'z bilan sodda, ammo Build agentining o'zida nima sodir bo'ladi?
Qadoqlash DLL RPM
TFS dan loyiha manbalari va qurilish topshirig'i olindi. Qurilish agenti manbalardan loyihani o'zi qurishni boshlaydi. Yig'ilgan loyiha to'plam sifatida mavjud DLL fayllari, ular fayl tizimidagi yukni kamaytirish uchun zip arxiviga joylashtirilgan.
ZIP arxivi tashlanadi RPM paketini yaratish katalogiga. Keyinchalik, Bash skripti muhit o'zgaruvchilarini ishga tushiradi, Build versiyasini, loyiha versiyasini, qurish katalogiga yo'lni topadi va RPM-build-ni ishga tushiradi. Qurilish tugallangach, paket e'lon qilinadi mahalliy ombor, Build agentida joylashgan.
Keyinchalik, Build agentidan RPM omboridagi serverga JSON so'rovi yuborildi versiya va qurish nomini ko'rsatadi. Yuqorida aytib o'tgan Webhook ushbu paketni Build agentidagi mahalliy ombordan yuklab oladi va yangi yig'ilishni o'rnatish uchun mavjud qiladi.
Nima uchun ushbu paketni RPM omboriga etkazib berish sxemasi? Nega yig'ilgan paketni darhol omborga yubora olmayman? Gap shundaki, bu xavfsizlikni ta'minlashning shartidir. Ushbu stsenariy ruxsatsiz odamlarning RPM paketlarini barcha Linux mashinalari uchun ochiq bo'lgan serverga yuklash imkoniyatini cheklaydi.
Ma'lumotlar bazasi versiyalarini yaratish
Ishlab chiquvchilar guruhi bilan maslahatlashganda, yigitlar MS SQL-ga yaqinroq ekanligi ma'lum bo'ldi, ammo Windows bo'lmagan loyihalarning ko'pchiligida biz PostgreSQL-dan bor kuchlari bilan foydalanayotgan edik. Biz allaqachon to'langan hamma narsadan voz kechishga qaror qilganimiz sababli, bu erda ham PostgreSQL-dan foydalanishni boshladik.
Ushbu qismda men sizga ma'lumotlar bazasini qanday versiyalashtirganimizni va Flyway va Entity Framework Core o'rtasida qanday tanlov qilganimizni aytib bermoqchiman. Keling, ularning ijobiy va salbiy tomonlarini ko'rib chiqaylik.
Minusy
Flyway faqat bir tomonga boradi, biz orqaga qaytolmaymiz - bu sezilarli kamchilik. Siz uni Entity Framework Core bilan boshqa yo'llar bilan solishtirishingiz mumkin - ishlab chiquvchiga qulaylik nuqtai nazaridan. Esingizdami, biz buni birinchi o'ringa qo'yganmiz va asosiy mezon Windows rivojlanishi uchun hech narsani o'zgartirmaslik edi.
Flyway biz uchun qandaydir o'rash kerak ediYigitlar yozmasin deb SQL so'rovlari. Ular OOP shartlarida ishlashga ancha yaqinroq. Biz ma'lumotlar bazasi ob'ektlari bilan ishlash bo'yicha ko'rsatmalar yozdik, SQL so'rovini yaratdik va uni bajardik. Ma'lumotlar bazasining yangi versiyasi tayyor, sinovdan o'tgan - hamma narsa yaxshi, hamma narsa ishlaydi.
Entity Framework Core-ning minuslari bor - og'ir yuklarda suboptimal SQL so'rovlarini yaratadi, va ma'lumotlar bazasida qisqartirish muhim bo'lishi mumkin. Ammo bizda yuqori yuklangan xizmat yo'qligi sababli, biz yuzlab RPSda yukni hisoblamaymiz, biz bu xavflarni qabul qildik va muammoni kelajakka topshirdik.
Plyusy
Entity Framework Core qutidan tashqarida ishlaydi va ishlab chiqish oson, va Flyway Mavjud CI ga osongina integratsiyalashgan. Lekin biz buni ishlab chiquvchilar uchun qulay qilamiz :)
Roll-up protsedurasi
Qo'g'irchoq paket versiyasida, jumladan, migratsiya uchun mas'ul bo'lgan versiyada o'zgarish kelayotganini ko'radi. Birinchidan, u migratsiya skriptlari va ma'lumotlar bazasi bilan bog'liq funksiyalarni o'z ichiga olgan paketni o'rnatadi. Shundan so'ng, ma'lumotlar bazasi bilan ishlaydigan dastur qayta ishga tushiriladi. Keyinchalik, qolgan qismlarni o'rnatish boshlanadi. Paketlarni o'rnatish va ilovalarni ishga tushirish tartibi Qo'g'irchoq manifestida tasvirlangan.
Ilovalar tokenlar, ma'lumotlar bazasi parollari kabi nozik ma'lumotlardan foydalanadi, bularning barchasi Qo'g'irchoq ustasidan konfiguratsiyaga olinadi, ular shifrlangan shaklda saqlanadi.
TFS bilan bog'liq muammolar
Biz qaror qilib, hamma narsa biz uchun ishlayotganini tushunganimizdan so'ng, men TFS-dagi yig'ilishlar bilan nima sodir bo'layotganini ko'rib chiqishga qaror qildim, ya'ni Win-ni ishlab chiqish bo'limi boshqa loyihalarda - biz tezda qurmoqdamizmi yoki yo'qmi, va tezlik bilan bog'liq jiddiy muammolarni aniqladi.
Asosiy loyihalardan birini yig'ish uchun 12-15 daqiqa vaqt ketadi - bu uzoq vaqt, siz bunday yashay olmaysiz. Tez tahlil kiritish-chiqarishda dahshatli pasayish ko'rsatdi va bu massivlarda edi.
Uni komponent bo'yicha tahlil qilgandan so'ng, men uchta o'choqni aniqladim. Birinchi - "Kasperskiy antivirusi", u barcha Windows Build agentlaridagi manbalarni skanerlaydi. Ikkinchi - Windows Indekslovchi. U o'chirilmagan va joylashtirish jarayonida hamma narsa real vaqtda Build agentlarida indekslangan.
Uchinchi - Npm o'rnatish. Ma'lum bo'lishicha, ko'pgina quvurlarda biz aynan shu stsenariydan foydalanganmiz. Nega u yomon? Npm o'rnatish protsedurasi qaramlik daraxti yaratilganda ishga tushadi package-lock.json, bu erda loyihani yaratish uchun foydalaniladigan paketlarning versiyalari qayd etiladi. Salbiy tomoni shundaki, Npm install har safar paketlarning eng so'nggi versiyalarini Internetdan tortib oladi va bu katta loyihada ko'p vaqtni oladi.
Ishlab chiquvchilar ba'zan ma'lum bir qism yoki butun loyiha qanday ishlashini sinab ko'rish uchun mahalliy mashinada tajriba o'tkazadilar. Ba'zida hamma narsa mahalliy darajada salqin ekanligi ayon bo'ldi, lekin ular uni yig'ishdi, o'rashdi va hech narsa ishlamadi. Muammo nima ekanligini aniqlashni boshlaymiz - ha, bog'liqliklari bo'lgan paketlarning turli versiyalari.
qaror
- AV istisnolarida manbalar.
- Indekslashni o'chirib qo'ying.
- Ga o'ting npm ci.
Npm ci ning afzalliklari shundaki, biz Biz qaramlik daraxtini bir marta yig'amiz, va biz ishlab chiquvchini taqdim etish imkoniyatiga ega bo'lamiz paketlarning joriy ro'yxati, bu bilan u o'zi xohlagancha mahalliy darajada tajriba o'tkazishi mumkin. Bu vaqtni tejaydi kod yozadigan dasturchilar.
Konfiguratsiya
Endi ombor konfiguratsiyasi haqida bir oz. Tarixiy jihatdan biz foydalanamiz Nexus omborlarni boshqarish uchun, shu jumladan Ichki REPO. Ushbu ichki ombor biz ichki maqsadlarda foydalanadigan barcha komponentlarni o'z ichiga oladi, masalan, o'z-o'zidan yozilgan monitoring.
Biz ham foydalanamiz NuGet, chunki u boshqa paket menejerlariga qaraganda yaxshiroq keshlash xususiyatiga ega.
natija
Qurilish agentlarini optimallashtirganimizdan so'ng, o'rtacha qurish vaqti 12 daqiqadan 7 daqiqagacha qisqartirildi.
Agar biz Windows uchun ishlatishimiz mumkin bo'lgan, lekin ushbu loyihada Linuxga o'tgan barcha mashinalarni hisoblasak, biz taxminan 10 000 dollarni tejab qoldik.Va bu faqat litsenziyalarda va agar kontentni hisobga olsak, yana ham ko'p.
rejalari
Keyingi chorakda biz kod yetkazib berishni optimallashtirish ustida ishlashni rejalashtirgan edik.
Oldindan yaratilgan Docker tasviriga o'tish. TFS - bu sizga Pipeline-ga integratsiyalashish imkonini beruvchi ko'plab plaginlarga ega ajoyib narsa, jumladan, masalan, Docker tasvirini triggerga asoslangan yig'ish. Biz bu triggerni xuddi shu uchun qilmoqchimiz package-lock.json. Agar loyihani yaratishda foydalanilgan komponentlarning tarkibi qandaydir tarzda o'zgarsa, biz yangi Docker tasvirini yaratamiz. Keyinchalik u yig'ilgan dastur bilan konteynerni joylashtirish uchun ishlatiladi. Hozir bunday emas, lekin biz Kubernetesda kompaniyamizda faol rivojlanayotgan va uzoq vaqt davomida ishlab chiqarish yechimlariga xizmat ko‘rsatib kelayotgan mikroservis arxitekturasiga o‘tishni rejalashtirmoqdamiz.
Xulosa
Men hammani Windowsni tashlab yuborishni tavsiya qilaman, lekin bu uni qanday pishirishni bilmasligim uchun emas. Buning sababi shundaki, ko'pchilik Opensource echimlari Linux to'plami. yaxshimisan resurslarni tejash. Menimcha, kelajak kuchli hamjamiyatga ega Linuxdagi Open Source yechimlariga tegishli.
Aleksandr Sinchinovning spiker profili .
professionallar tomonidan mutaxassislar uchun ishlab chiqish, sinov va ekspluatatsiya jarayonlarini integratsiyalash bo'yicha konferentsiya. Shuning uchun Aleksandr gapirgan loyiha? amalga oshirildi va ishladi va spektakl kuni ikkita muvaffaqiyatli relizlar bo'ldi. Yoniq 27 va 28 may kunlari amaliyotchilar tomonidan shunga o'xshash holatlar yanada ko'proq bo'ladi. Siz hali ham oxirgi aravaga o'tishingiz mumkin va yoki vaqtingizni oling chipta. Bizni Skolkovoda kutib oling!
Manba: www.habr.com