Sukūrėme „DevOps“ taip, kaip galėjome. Mūsų buvo 8, o Vasya buvo šauniausia sistemoje „Windows“. Staiga Vasya išėjo, ir aš turėjau užduotį pradėti naują projektą, kurį tiekė „Windows“ plėtra. Kai numečiau visą „Windows“ kūrimo krūvą ant stalo, supratau, kad situacija buvo skaudi...
Taip prasideda istorija Aleksandra Sinčinova apie . Kai pagrindinis Windows specialistas paliko įmonę, Aleksandras susimąstė, ką dabar daryti. Žinoma, pereikite prie Linux! Aleksandras jums pasakys, kaip jam pavyko sukurti precedentą ir perkelti dalį „Windows“ kūrimo į „Linux“, naudodamas užbaigto projekto, skirto 100 000 galutinių vartotojų, pavyzdį.
Kaip lengvai ir be pastangų pateikti projektą RPM naudojant TFS, Puppet, Linux .NET branduolį? Kaip palaikyti projekto duomenų bazės versijų kūrimą, jei kūrimo komanda pirmą kartą išgirsta žodžius Postgres ir Flyway, o terminas yra poryt? Kaip integruoti su Docker? Kaip paskatinti .NET kūrėjus atsisakyti Windows ir kokteilių, o ne Puppet ir Linux? Kaip išspręsti ideologinius konfliktus, jei nėra nei jėgų, nei noro, nei resursų išlaikyti Windows gamyboje? Apie tai, taip pat apie žiniatinklio diegimą, testavimą, CI, apie TFS naudojimo praktiką esamuose projektuose ir, žinoma, apie sugedusius ramentus ir veikiančius sprendimus – Aleksandro pranešimo nuoraše.
Taigi, Vasya išėjo, užduotis yra man, kūrėjai nekantriai laukia su šakėmis. Kai pagaliau supratau, kad Vasios grąžinti negalima, ėmiausi verslo. Pirmiausia įvertinau Win VM procentą mūsų parke. Rezultatas nebuvo „Windows“ naudai.
Kadangi aktyviai kuriame DevOps, supratau, kad naujos programos pristatymo požiūriu reikia kažką pakeisti. Buvo tik vienas sprendimas – jei įmanoma, viską perkelti į Linux. Google man padėjo – tuo metu .Net jau buvo perkeltas į Linux, ir aš supratau, kad tai buvo sprendimas!
Kodėl .NET branduolys kartu su Linux?
Tam buvo keletas priežasčių. Tarp „mokėti pinigus“ ir „nemokėti“ dauguma pasirinks antrąjį - kaip aš. MSDB licencija kainuoja apie 1 USD; „Windows“ virtualių mašinų parko išlaikymas kainuoja šimtus dolerių. Didelei įmonei tai didelės išlaidos. Štai kodėl santaupos - pirmoji priežastis. Ne pats svarbiausias, bet vienas reikšmingiausių.
„Windows“ virtualios mašinos užima daugiau išteklių nei jų „Linux“ broliai - jie sunkūs. Atsižvelgdami į didelės įmonės mastą, pasirinkome Linux.
Sistema tiesiog integruota į esamą KI. Mes laikome save progresyviais „DevOps“, naudojame „Bamboo“, „Jenkins“ ir „GitLab CI“, todėl didžioji dalis mūsų darbų vykdoma „Linux“.
Paskutinė priežastis yra patogus palydėjimas. Reikėjo sumažinti „palydos“ įėjimo barjerą – vaikinams, kurie supranta techninę dalį, užtikrina nenutrūkstamą aptarnavimą ir prižiūri paslaugas iš antros linijos. Jie jau buvo susipažinę su „Linux“ stacku, todėl jiems daug lengviau suprasti, palaikyti ir prižiūrėti naują produktą, nei išleisti papildomų išteklių, kad suprastų tas pačias „Windows“ platformai skirtos programinės įrangos funkcijas.
Reikalavimai
Pirmiausia ir svarbiausia - naujojo sprendimo patogumas kūrėjams. Ne visi jie buvo pasirengę pokyčiams, ypač po to, kai buvo ištartas žodis „Linux“. Kūrėjai nori savo mėgstamos „Visual Studio“, TFS su automatiniais rinkinių ir kokteilių testais. Jiems nesvarbu, kaip vyksta pristatymas į gamybą. Todėl nusprendėme nekeisti įprasto proceso ir palikti viską nepakeistą Windows kūrimui.
Reikalingas naujas projektas integruoti į esamą KI. Bėgiai jau buvo ir visi darbai turėjo būti atlikti atsižvelgiant į konfigūracijos valdymo sistemos parametrus, priimtus pristatymo standartus ir stebėjimo sistemas.
Lengva palaikyti ir valdyti, kaip sąlyga minimaliam visų naujų dalyvių iš skirtingų padalinių ir paramos skyriaus slenksčiui.
Terminas – vakar.
Laimėk plėtros grupę
Su kuo tada dirbo „Windows“ komanda?
Dabar galiu drąsiai tai pasakyti IdentityServer4 yra šauni nemokama alternatyva ADFS su panašiomis galimybėmis, ar ką Entity Framework Core - kūrėjo rojus, kuriame nereikia vargti rašant SQL scenarijus, o aprašinėti duomenų bazėje esančias užklausas OOP terminais. Bet tada, aptardamas veiksmų planą, pažvelgiau į šį krūvą taip, lyg tai būtų šumerų dantraštis, atpažinęs tik PostgreSQL ir Git.
Tuo metu mes aktyviai naudojome Marionetė kaip konfigūracijos valdymo sistema. Daugumoje savo projektų naudojome „GitLab CI“, Elastingas, subalansuotas didelės apkrovos paslaugas naudojant HAProxy viską stebėjo Zabbix, raiščiai grafana и Prometėjas, Jaeger, ir visa tai sukosi ant geležies gabalų HP c ESXi apie "VMware". Visi tai žino – žanro klasika.
Pažiūrėkime ir pabandykime suprasti, kas vyko prieš pradedant visas šias intervencijas.
Что было
TFS yra gana galinga sistema, kuri ne tik pristato kodą iš kūrėjo į galutinę gamybos mašiną, bet ir turi rinkinį labai lanksčiam integravimui su įvairiomis paslaugomis – teikti CI tarpplatforminiu lygiu.
Anksčiau tai buvo tvirti langai. TFS naudojo keletą „Build“ agentų, kurie buvo naudojami daugeliui projektų surinkti. Kiekvienas agentas turi 3–4 darbuotojus, kurie lygiagrečiai atlieka užduotis ir optimizuoja procesą. Tada, pagal išleidimo planus, TFS pristatė ką tik iškeptą „Build“ į „Windows“ programų serverį.
Ką mes norėjome pasiekti?
Mes naudojame TFS pristatymui ir plėtrai, paleidžiame programą „Linux Application“ serveryje, ir tarp jų yra tam tikra magija. Tai Magic Box ir laukia darbo druska. Prieš išardydamas, pasitrauksiu į šoną ir pasakysiu keletą žodžių apie programą.
Projektas
Programa suteikia išankstinio mokėjimo kortelių tvarkymo funkcionalumą.
klientas
Buvo dviejų tipų vartotojai. Pirmas prieigą gavo prisijungęs naudojant SSL SHA-2 sertifikatą. U antrasis buvo prieiga naudojant prisijungimo vardą ir slaptažodį.
HAProxy
Tada kliento užklausa nuėjo į HAProxy, kuri išsprendė šias problemas:
- pirminis leidimas;
- SSL nutraukimas;
- HTTP užklausų derinimas;
- transliacijos užklausos.
Kliento sertifikatas buvo patikrintas grandinėje. Mes - valdžia ir galime sau tai leisti, nes patys išduodame sertifikatus paslaugų klientams.
Atkreipkite dėmesį į trečią punktą, prie jo grįšime šiek tiek vėliau.
Vidinis
Jie planavo sukurti pagrindinę sistemą „Linux“. Užpakalinė programa sąveikauja su duomenų baze, įkelia reikiamą privilegijų sąrašą ir tada, priklausomai nuo to, kokias teises turi įgaliotas vartotojas, suteikia prieigą pasirašyti finansinius dokumentus ir siųsti juos vykdyti arba sugeneruoti kokią nors ataskaitą.
Taupymas naudojant HAProxy
Be dviejų kontekstų, kuriuos naršė kiekvienas klientas, buvo ir tapatybės kontekstas. IdentityServer4 tiesiog leidžia prisijungti, tai nemokamas ir galingas analogas ADT - „Active Directory“ federacijos paslaugos.
Tapatybės užklausa buvo apdorota keliais etapais. Pirmas žingsnis - klientas pateko į užpakalinę dalį, kuri susisiekė su šiuo serveriu ir patikrino, ar kliento prieigos raktas yra. Jei jis nebuvo rastas, užklausa buvo grąžinta į kontekstą, iš kurio ji buvo, bet su peradresavimu, o su peradresavimu ji buvo nukreipta į tapatybę.
Antras žingsnis – prašymas gautas į autorizacijos puslapį „IdentityServer“, kur klientas užsiregistravo, ir tas ilgai lauktas prieigos raktas atsirado IdentityServer duomenų bazėje.
Trečias žingsnis - klientas buvo nukreiptas atgal į kontekstą, iš kurio jis kilo.
„IdentityServer4“ turi funkciją: jis grąžina atsakymą į grąžinimo užklausą per HTTP. Nesvarbu, kiek vargome nustatydami serverį, kad ir kiek apšviesdavome save su dokumentacija, kiekvieną kartą gaudavome pradinį kliento užklausą su URL, gautu per HTTPS, o „IdentityServer“ grąžindavo tą patį kontekstą, bet su HTTP. Buvome šokiruoti! Ir visa tai per tapatybės kontekstą perkėlėme į HAProxy, o antraštėse turėjome pakeisti HTTP protokolą į HTTPS.
Koks patobulinimas ir kur sutaupėte?
Sutaupėme pinigų naudodami nemokamą vartotojų grupės autorizavimo sprendimą, išteklius, nes „IdentityServer4“ nepadėjome kaip atskiro mazgo atskirame segmente, o panaudojome jį kartu su užpakaline programa tame pačiame serveryje, kuriame veikia programos užpakalinė dalis. .
Kaip tai turėtų veikti
Taigi, kaip ir žadėjau – Magic Box. Jau suprantame, kad garantuotai judėsime link Linux. Suformuluokime konkrečias užduotis, kurioms reikėjo sprendimų.
Lėlių manifestas. Norint teikti ir valdyti paslaugų ir programų konfigūraciją, reikėjo parašyti puikius receptus. Pieštuko ritinėlis iškalbingai parodo, kaip greitai ir efektyviai tai buvo padaryta.
Pristatymo būdas. Standartas yra RPM. Visi supranta, kad „Linux“ be jo neapsieisite, tačiau pats projektas po surinkimo buvo vykdomųjų DLL failų rinkinys. Jų buvo apie 150, projektas buvo gana sunkus. Vienintelis harmoningas sprendimas yra supakuoti šį dvejetainį failą į RPM ir iš jo įdiegti programą.
Versijų kūrimas. Turėjome išleisti labai dažnai ir turėjome nuspręsti, kaip suformuoti paketo pavadinimą. Tai yra integracijos su TFS lygio klausimas. Turėjome Linux kūrimo agentą. Kai TFS siunčia užduotį tvarkytojui – darbuotojui – kūrimo agentui, ji taip pat perduoda jai daugybę kintamųjų, kurie patenka į tvarkyklės proceso aplinką. Šiuose aplinkos kintamuosiuose yra versijos pavadinimas, versijos pavadinimas ir kiti kintamieji. Daugiau apie tai skaitykite skiltyje „RPM paketo kūrimas“.
TFS nustatymas ėmėsi dujotiekio įrengimo. Anksčiau rinkdavome visus „Windows“ projektus „Windows“ agentuose, bet dabar atsiranda „Linux“ agentas - „Build“ agentas, kurį reikia įtraukti į kūrimo grupę, papildyti kai kuriais artefaktais ir pasakyti, kokio tipo projektai bus kuriami naudojant šį „Build“ agentą. , ir kaip nors modifikuoti vamzdyną.
IdentityServer. ADFS nėra mūsų kelias, mes pasirenkame atvirąjį kodą.
Peržiūrėkime komponentus.
Magic Box
Susideda iš keturių dalių.
„Linux Build“ agentas. „Linux“, nes mes jai kuriame – tai logiška. Ši dalis buvo atlikta trimis etapais.
- Konfigūruoti darbuotojus ir ne vienas, nes buvo tikimasi paskirstytų darbų projekte.
- Įdiekite .NET Core 1.x. Kodėl 1.x, kai 2.0 jau yra standartinėje saugykloje? Nes kai pradėjome kurti, stabili versija buvo 1.09, pagal ją buvo nuspręsta daryti projektą.
- Git 2.x.
RPM saugykla. RPM paketus reikėjo kažkur saugoti. Buvo manoma, kad naudosime tą pačią įmonės RPM saugyklą, kuri yra prieinama visiems Linux pagrindiniams kompiuteriams. Taip jie ir padarė. Saugyklos serveris sukonfigūruotas interneto kabliukas kuris atsisiuntė reikalingą RPM paketą iš nurodytos vietos. Build agentas apie paketo versiją pranešė žiniatinklio kabliui.
„GitLab“. Dėmesio! „GitLab“ čia naudoja ne kūrėjai, o operacijų skyrius, kad galėtų valdyti programų versijas, paketų versijas, stebėti visų Linux mašinų būseną ir išsaugo receptą – visus „Puppet“ manifestus.
Marionetė – išsprendžia visas ginčytinas problemas ir pateikia tiksliai tokią konfigūraciją, kokios norime iš „Gitlab“.
Pradedame nardyti. Kaip veikia DLL pristatymas į RPM?
Pristatymas DDL į RPM
Tarkime, kad turime .NET kūrimo roko žvaigždę. Jis naudoja „Visual Studio“ ir sukuria leidimo šaką. Po to jis įkelia jį į „Git“, o „Git“ čia yra TFS subjektas, tai yra, tai yra programų saugykla, su kuria kūrėjas dirba.
Po to TFS mato, kad atėjo naujas įsipareigojimas. Kokia programa? TFS nustatymuose yra etiketė, nurodanti, kokius išteklius turi konkretus kūrimo agentas. Šiuo atveju jis mato, kad kuriame .NET Core projektą ir pasirenka Linux Build agentą iš telkinio.
Build agentas gauna šaltinius ir atsisiunčia būtinus priklausomybių iš .NET saugyklos, npm ir kt. ir sukūręs pačią programą bei vėlesnę supakavimą, siunčia RPM paketą į RPM saugyklą.
Kita vertus, atsitinka taip. Operacijų skyriaus inžinierius tiesiogiai dalyvauja diegiant projektą: keičia paketų versijas Hiera saugykloje, kurioje saugomas programos receptas, po kurio suveikia lėlė yum, paima naują paketą iš saugyklos ir nauja programos versija yra paruošta naudoti.
Viskas paprasta žodžiais, bet kas vyksta pačiame Build agente?
Pakuotės DLL RPM
Gauti projekto šaltiniai ir kūrimo užduotis iš TFS. Sukurti agentą pradeda statyti patį projektą iš šaltinių. Surinktą projektą galima įsigyti kaip komplektą DLL failus, kurie yra supakuoti į ZIP archyvą, siekiant sumažinti failų sistemos apkrovą.
ZIP archyvas išmetamas į RPM paketo kūrimo katalogą. Tada „Bash“ scenarijus inicijuoja aplinkos kintamuosius, suranda „Build“ versiją, projekto versiją, kelią į kūrimo katalogą ir paleidžia „RPM-build“. Kai kūrimas bus baigtas, paketas paskelbiamas vietinė saugykla, kuris yra Build agente.
Tada iš Build agento į serverį RPM saugykloje JSON užklausa išsiųsta nurodant versijos ir versijos pavadinimą. „Webhook“, apie kurį kalbėjau anksčiau, atsisiunčia šį paketą iš vietinės „Build“ agento saugyklos ir leidžia įdiegti naują rinkinį.
Kodėl ši konkreti paketo pristatymo į RPM saugyklą schema? Kodėl negaliu iš karto išsiųsti surinkto paketo į saugyklą? Faktas yra tas, kad tai yra saugumo užtikrinimo sąlyga. Šis scenarijus apriboja galimybę neteisėtiems žmonėms įkelti RPM paketus į serverį, kuris pasiekiamas visoms Linux mašinoms.
Duomenų bazės versijų kūrimas
Konsultuojantis su kūrėjų komanda paaiškėjo, kad vaikinai buvo arčiau MS SQL, tačiau daugumoje ne Windows projektų jau iš visų jėgų naudojome PostgreSQL. Kadangi jau buvome nusprendę atsisakyti visko, kas mokama, pradėjome naudoti PostgreSQL ir čia.
Šioje dalyje noriu papasakoti, kaip sukūrėme duomenų bazės versijas ir kaip pasirinkome „Flyway“ ir „Entity Framework Core“. Pažvelkime į jų privalumus ir trūkumus.
Trūkumai
Flyway eina tik į vieną pusę, mes mes negalime atsukti atgal – tai reikšmingas trūkumas. Galite palyginti jį su Entity Framework Core kitais būdais – kalbant apie kūrėjo patogumą. Prisimenate, kad mes tai iškėlėme į priekį, o pagrindinis kriterijus buvo nieko nekeisti kuriant „Windows“.
„Flyway“ mums reikėjo kažkokio vyniotiniokad vaikinai nerašytų SQL užklausos. Jie yra daug arčiau veiklos OOP sąlygomis. Surašėme darbo su duomenų bazės objektais instrukcijas, sugeneravome SQL užklausą ir ją įvykdėme. Nauja duomenų bazės versija paruošta, išbandyta – viskas gerai, viskas veikia.
„Entity Framework Core“ turi minusą – esant didelėms apkrovoms kuria neoptimalias SQL užklausas, o duomenų bazės sumažėjimas gali būti reikšmingas. Bet kadangi neturime didelės apkrovos paslaugos, apkrovos neskaičiuojame šimtais RPS, prisiėmėme šią riziką ir perdavėme problemą mums ateityje.
Argumentai "už"
Entity Framework Core veikia iš dėžutės ir yra lengvai tobulinamasir Flyway Lengvai integruojamas į esamą CI. Bet mes darome tai patogų kūrėjams :)
Roll-up procedūra
Lėlė mato, kad ateina paketo versijos pakeitimas, įskaitant tą, kuri yra atsakinga už perkėlimą. Pirma, jis įdiegia paketą, kuriame yra perkėlimo scenarijai ir su duomenų baze susijusios funkcijos. Po to programa, kuri veikia su duomenų baze, paleidžiama iš naujo. Toliau reikia įdiegti likusius komponentus. Paketų diegimo ir programų paleidimo tvarka aprašyta lėlių apraše.
Programos naudoja jautrius duomenis, tokius kaip žetonai, duomenų bazės slaptažodžiai, visa tai į konfigūraciją ištraukiama iš Puppet master, kur saugoma šifruota forma.
TFS problemos
Po to, kai nusprendėme ir supratome, kad mums viskas iš tikrųjų veikia, nusprendžiau pažiūrėti, kas vyksta su TFS surinkimais kaip visuma Win plėtros skyriui kituose projektuose – nesvarbu, ar greitai statome / išleidžiame, ar ne, ir aptiko didelių greičio problemų.
Vieno iš pagrindinių projektų surinkimas užtrunka 12–15 minučių – tai ilgas laikas, tu negali taip gyventi. Greita analizė parodė siaubingą įvesties / išvesties trūkumą, ir tai buvo masyvuose.
Išanalizavęs jį pagal komponentą, nustatiau tris židinius. Pirmas - "Kaspersky antivirus", kuri nuskaito šaltinius visose „Windows Build“ priemonėse. Antra - Windows Indeksuotojas. Jis nebuvo išjungtas, o diegimo proceso metu viskas buvo indeksuojama „Build“ agentuose realiuoju laiku.
Trečias - Npm įdiegimas. Paaiškėjo, kad daugumoje vamzdynų naudojome būtent šį scenarijų. Kodėl jis blogas? Npm diegimo procedūra vykdoma, kai formuojamas priklausomybės medis package-lock.json, kur įrašomos paketų versijos, kurios bus naudojamos kuriant projektą. Neigiama yra tai, kad „Npm install“ kiekvieną kartą iš interneto ištraukia naujausias paketų versijas, o tai užima daug laiko didelio projekto atveju.
Kūrėjai kartais eksperimentuoja vietiniame kompiuteryje, kad patikrintų, kaip veikia konkreti dalis ar visas projektas. Kartais pasirodydavo, kad vietoje viskas šaunu, bet sumontavo, išvyniojo ir nieko nepavyko. Pradedame išsiaiškinti, kokia yra problema – taip, skirtingos paketų versijos su priklausomybėmis.
sprendimas
- Šaltiniai AV išimtyse.
- Išjungti indeksavimą.
- Eiti į npm ci.
Npm ci pranašumai yra tai, kad mes Priklausomybės medį renkame vieną kartą, ir mes gauname galimybę suteikti kūrėjui dabartinis paketų sąrašas, su kuria jis gali eksperimentuoti vietoje tiek, kiek nori. Tai taupo laiką kūrėjai, kurie rašo kodą.
Konfigūravimas
Dabar šiek tiek apie saugyklos konfigūraciją. Istoriškai mes naudojame "Nexus saugyklų valdymui, įskaitant Vidinis REPO. Šioje vidinėje saugykloje yra visi komponentai, kuriuos naudojame vidiniams tikslams, pavyzdžiui, savarankiškai parašytam stebėjimui.
Mes taip pat naudojame „NuGet“, nes ji turi geresnę talpyklą, palyginti su kitomis paketų tvarkyklėmis.
Rezultatas
Kai optimizavome kūrimo agentus, vidutinis kūrimo laikas sumažėjo nuo 12 minučių iki 7.
Jei suskaičiuotume visas mašinas, kurias galėjome naudoti „Windows“, bet šiame projekte perėjome prie „Linux“, sutaupėme apie 10 000 USD. Ir tai tik dėl licencijų, ir dar daugiau, jei atsižvelgsime į turinį.
Planai
Kitą ketvirtį planavome optimizuoti kodo pateikimą.
Perjungiama į iš anksto sukurtą „Docker“ vaizdą. TFS yra puikus dalykas su daugybe įskiepių, leidžiančių integruotis į „Pupeline“, įskaitant, pavyzdžiui, „Docker“ vaizdo sujungimą, pagrįstą trigeriais. Mes norime, kad šis paleidiklis būtų skirtas tam pačiam package-lock.json. Jei projekto kūrimui naudotų komponentų sudėtis kažkaip pasikeičia, sukuriame naują „Docker“ vaizdą. Vėliau jis naudojamas konteineriui su surinkta programa dislokuoti. Dabar taip nėra, tačiau planuojame perėjimą prie mikro paslaugų architektūros Kubernetes, kuri aktyviai vystosi mūsų įmonėje ir jau seniai aptarnauja gamybinius sprendimus.
Santrauka
Raginu visus išmesti „Windows“, bet ne todėl, kad nemoku jos gaminti. Priežastis ta, kad dauguma atvirojo kodo sprendimų yra Linux kamino. ar tau viskas gerai taupyti išteklius. Mano nuomone, ateitis priklauso atvirojo kodo sprendimams Linux sistemoje su galinga bendruomene.
Aleksandro Sinčinovo pranešėjas .
yra konferencija apie profesionalų kūrimo, testavimo ir eksploatavimo procesų integravimą profesionalams. Tai kodėl projektas, apie kurį kalbėjo Aleksandras? įdiegtas ir veikiantis, o pasirodymo dieną buvo du sėkmingi leidimai. Įjungta Gegužės 27 ir 28 dienomis bus dar daugiau panašių atvejų iš praktikų. Dar galite įšokti į paskutinį vežimą ir arba neskubėkite bilietas. Susitikime Skolkovo mieste!
Šaltinis: www.habr.com