.NET Core Linuxis, DevOps ratsutamisel

Me arendame DevOps'i, kuidas oskame. Meid oli 8 inimest ja Vassia oli Windowsi alal parim. Ühel päeval lahkus Vassia ja mul tekkis ülesanne käivitada uus projekt, mis pakub Windows arendust. Kui ma lauas kokku kogusin kogu Windowsi arendustehnoloogia, siis sain aru, et olukord on valus...

Nii algab lugu Aleksandr Sinčinov . Tundub, et DevOpsConf. Kui ettevõttest lahkus peamine Windowsi spetsialist, küsis Aleksandr endalt, mida nüüd teha. Loomulikult liikuda Linuxile! Aleksandr räägib, kuidas tal õnnestus luua pretsedent ja viia osa Windowsi arendusest Linuxile, kasutades näiteks projekti, millel on 100 000 lõppkasutajat.

Kuidas tellida projekti RPM-i, kasutades TFS-i, Puppetit, Linux .NET core'i? Kuidas hallata projekti andmebaasi versioone, kui arendajad kuulevad Postgresi ja Flywayi nimed esmakordselt ja tähtaeg on ülehomme? Kuidas integreerida Dockeriga? Kuidas motiveerida .NET arendajaid loobuma Windowsist ja smuutidest Puppet ja Linuxi kasuks? Kuidas lahendada ideoloogilisi konflikte, kui Windowsi tootmisressurss ei ole mitte ainult jõud, vaid ka soov ja ressursid? Sellest, samuti Web Deployst, testimisest, CI-st, TFS-i kasutamise praktikast olemasolevates projektides, ja muidugi rikutud tugede ja töötavate lahenduste kohta, räägib Aleksandri esitluse ülevaates.

Nii, Vassia lahkus, ülesanne on nüüd minu õlul, arendajad ootavad põnevusega. Kui ma lõpuks mõistsin, et Vassiat ei saa tagasi tuua—alustasin tööd. Esiteks hindasin meie Windowsi virtuaalmasinate protsenti. Numbrid ei olnud Windowsi kasuks.

Kuna me aktiivselt arendame DevOps'i, mõistsin, et uus rakenduse väljaandmine peab muutuma. Lahendus oli üheselt selge—kõik tuleb võimaluse korral viia Linuxile. Google aitas mind—tol hetkel oli .Net juba Linuxile portitud ja ma sain aru, et see on lahendus!

Miks .NET core koos Linuxiga?

Sellel oli mitu põhjust. Enamiku jaoks, kes peavad valima 'maksta raha' ja 'mitte maksta', valib enamik teise—nagu mina. MSDB litsents maksab umbes 1 000 dollarit, Windowsi virtuaalmasinate hooldus maksab sadu dollareid. Suurettevõtte jaoks on need suuremad kulud. Seega sääst — on esimene põhjus. Mitte kõige olulisem, aga üks tähtsamaid.

Windowsi virtuaalmasinad võtavad rohkem ressursse kui nende Linuxi vennad— nad on rasked. Arvestades suure ettevõtte mõõtmeid, valisime Linuxi.

Süsteem integreerub lihtsalt olemasolevasse CI-sse. Peame end progressiivseteks DevOps-ideks, kasutame Bamboo, Jenkinsit ja GitLab CI-d, seetõttu põhineb meil enamik Linuxil.

Viimane põhjus on mugav teenindamine. Oli vajalik vähendada sisenemise läve „teenindajatele“ - neile, kes mõistavad tehnilist poolt, tagavad teenuste tõrgeteta toimimise ja hooldavad teenuseid teise taseme abil. Nad olid juba tuttavad Linuxi tehnoloogiaga, seega on neil uus toode, selle toetamine ja hooldamine tunduvalt lihtsam, kui kulutada lisajõude Windowsi platvormide sarnaste funktsioonide mõistmiseks.

Nõuded

Esiteks ja kõige olulisem on uue lahenduse mugavus arendajatele. Mitte kõik neist ei olnud muudatusteks valmis, eriti pärast sõna Linuxi mainimist. Arendajad soovivad armastatud Visual Studio't, TFS-i koos automaatsete testidega build'ide jaoks ja smuutisid. Kuidas toimub kohaletoimetamine tootmisse - need ei hooli. Seetõttu otsustasime mitte muuta harjumuspärast protsessi ja jätta Windowsi arendamiseks kõik muutumatuks.

Uus projekt tuleb integreerida olemasolevasse CI-sse. Rööpad olid juba paigas ning kogu töö tuli teostada arvestades konfiguratsiooni haldamise süsteemi parameetreid, standardse kohaletoimetamise protseduuri ja jälgimissüsteemide nõudeid.

Toetamise ja kasutamise lihtsus, nagu tingimus, et kõik uued osalejad erinevatest osakondadest ja teenindusosakonnast saaksid madala sisenemise läve.

Tähtpäev oli eile.

Windowsi arendamise grupp

Millega töötas Windowsi meeskond?

Praegu võin kindlalt öelda, et IdentityServer4 on suurepärane tasuta alternatiiv ADFS-ile sarnaste võimalustega, või et Entity Framework Core on arendajate paradiis, kus ei pea muretsema SQL skriptide kirjutamise pärast, vaid saab kirjeldada andmebaasi päringuid OOP terminoloogiaga. Kuid siis, käimasoleval tegevuskava arutelul, vaatasin sellele tehnoloogiale nagu sumero-keelele, tunnen ainult PostgreSQL-i ja Gitit.

Sel ajal kasutasime aktiivselt Puppet konfiguratsiooni haldamiseks. Enamikus meie projektides kasutasime GitLab CI-d, Elastic, balanseerisime kõrge koormusega teenuseid HAProxy-ga, kõike jälgisime Zabbix, komplekti Grafana ja Prometheus, Jaeger, ja see kõik töötas riistvaral HP c ESXi . Tundub, et VMware. Kõigile tuttav - žanri klassika.

Vaatame ja proovime mõista, mis juhtus enne, kui me kõik need sekkumised ette võtsime.

Mis toimus

TFS on üsna võimas süsteem, mis mitte ainult ei toeta koodi edastamist arendajalt lõpplikku tootmismasinasse, vaid omab ka tugevat tööriistakomplekti, et toetada väga paindlikku integreerimist erinevate teenustega – CI tagamiseks ülepakkumise tasemel.

Varem olid need täiesti aknad. TFS kasutas mitmeid Build-agenete, millel koguti kokku palju projekte. Igas agendis oli 3-4 töötlijat, et töid paralleelselt jagada ja protsessi optimeerida. Edasi, vastavalt väljaande plaanidele, edastas TFS värskelt valmistatud Buildi Windowsi rakenduste serverisse.

Mille poole me tahtsime jõuda

Kasutame TFS-i edastamiseks ja arendamiseks, aga käivitame rakenduse Linuxi rakenduste serveris, ja nende vahele jääb mingi maagia. See Magic Box ongi eelseisva töö sool. Enne kui hakkame seda tükeldama, teen sammu kõrvale ja ütlen paar sõna rakendusest.

Projekt

Rakendus pakub funktsionaalsust ette makstud kaartide haldamiseks.

Klient

Oli olemas kaks tüüpi kasutajaid. Esimene saime ligipääsu, autentides SSL SHA-2 sertifikaadi kaudu. Teisel oli ligipääs sisselogimise ja parooli kaudu. HAProxy

Edasi läks kliendi päring HAProxy-sse, mis lahendas järgmised ülesanded:

esmane autentimine;

• SSL-i lõppemine;
• HTTP päringute kohandamine;
• päringute edastamine.
• Kliendi sertifikaadi kontrollimist tehti ahela kaudu. Me oleme

authority ja saame endale sellist lubada, kuna me ise väljastame teenuse klientidele sertifikaate. Pane tähele kolmandat punkti, tuleme sellele tagasi veidi hiljem.

Planeerisime tausta teha Linuxil. Taust interakteerub andmebaasiga, laadib vajalikud privileegide loendid ja seejärel, olenevalt sellest, milliste privileegidega autentitud kasutaja on, annab juurdepääsu finantsdokumentide allkirjastamiseks ja nende täitmiseks või mõne raporti genereerimiseks.

Backend

Kokkuhoid HAProxy-st

Lisaks kahe konteksti olemasolule, mille kaudu igasugused kliendid liikuda, oli veel konteksti identity.

mis just võimaldab autentimist, see on tasuta ja võimas analoog IdentityServer4 ADFS Active Directory Federation Services — Päring identity-le töödeldi mitmes etapis. Esimene etapp –.

klient sattus tausta sattus tagasiside, mis vahetas andmeid selle serveriga ja kontrollis kliendi tokeni olemasolu. Kui seda ei leitud, naasis päring tagasi konteksti, kust see tuli, kuid juba koos ümbersuunamisega, ja ümbersuunamine läks identiteedi suunas.

Teine samm - päring jõudis autentimislehele IdentityServeris, kus klient registreerus ja IdentityServeri andmebaasi ilmnes kauaoodatud token.

Kolmas samm - klient suunati tagasi konteksti, kust ta tuli.

IdentityServer4-l on eripära: vastus tagasipäringule antakse tagasi HTTP. Kuigi me pingutasime serveri seadistamise nimel, uurides dokumentatsiooni, saime iga kord kliendi algse päringu, mille URL tuli HTTPS-i kaudu, kuid IdentityServer tagastas sama konteksti HTTP-as. Olime šokis! Ja suunasime selle kõik identiteedi konteksti kaudu HAProxy, muutes protokolli HTTP HTTPS-iks päistes.

Kus on siis parendused ja kust me kokkuhoidu saime?

Kokkuhoid oli rahas, kasutades tasuta lahendust kasutajagrupi autentimiseks, ressurssidest, kuna me ei tõstnud IdentityServer4 eraldi sõlmena eraldi segmenti, vaid kasutasime seda koos backendiga samas serveris, kus rakenduse backend töötas.

Kuidas see peaks toimima

Nii nagu ma lubasin - Magic Box. Me saame juba aru, et liigume kindlalt suunas Linux. Vaatame konkreetsed ülesanded, mis vajasid lahendamist.

Puppet'i manifestid. Teenuse ja rakenduse konfigureerimise edastamiseks ja haldamiseks tuli kirjutada toredaid retsepte. Paberirull ja pliiats näitavad arusaadavalt, kui kiiresti ja kvaliteetselt see tehti.

Edastamise meetod. Standard on RPM. Kõik mõistavad, et Linuxis ei saa teisiti, kuid ise projekt pärast ehitamist kujutas endast teatud käivitatavate DLL-failide komplekti. Need olid umbes 150, projekt oli piisavalt mahukas. Ainus harmooniline lahendus oli see binaar RPM-ks pakkida ja sealt rakendust arendada.

Versioonimine. Meil tuli tihti releasida ja oli vaja otsustada, kuidas paketi nime vormistada. See on TFS-iga integreerumise tase. Meie Build-agent oli Linuxis. Kui TFS saadab ülesande töötlejale - worker - Build-agentile, edastab ta talle ka muutuja grupi, mis siseneb töötleva protsessi keskkonda. Nendes keskkonnaparameetrites edastatakse Build'i nimi, versiooni nimi ja teised muutujad. Täiendavate detailide jaoks vaadake jaotist 'RPM-paketi koostamine'.

TFS-i seadistamine koondus Pipeline'i seadistamisele. Varem kogusime kõik Windowsi projektid Windows-agente peal, kuid nüüd tuleb lisada Linux-agent - Build-agent, mis tuleb lisada koostamisrühma, rikastada mingite artefaktidega, määrata, milliseid projekte selles Build-agendis kokku pannakse, ja kuidagi modifitseerida Pipeline'i.

IdentityServer. ADFS ei ole meie tee, toetame Open Source'i.

Käime komponentidest läbi.

Magic Box

Koosneb neljast osast.

Linux Build-agent. Linux, sest me kogume selle jaoks - loogiline. See osa viidi ellu kolme sammu kaudu.

• Seada worker'id ja mitte ainult üks, kuna projektiga olnuks plaanis tegeleda jagatult.
• Installida .NET Core 1.x. Miks just 1.x, kui 2.0 on juba olemas tavalisest repost? Sest kui me arendamist alustasime, oli stabiilne versioon 1.09 ja projekti otsustati teha selle põhjal.
• Git 2.x.

RPM-repositorium. RPM-pakette oli vaja kuskil hoida. Eeldati, et me kasutame sama ettevõtte RPM-repositoriumi, mis on kergesti kättesaadav kõigile Linuxi hostidele. Nii me ka tegime. Repositoriumi serveris on seadistatud webhook mis allalaadib nõutud RPM-paketi määratud kohast. Versiooni paketist edastas Build-agent webhook'ile.

GitLab. Tähtis! GitLab'i kasutavad siin mitte arendajad, vaid haldustöötajad rakenduse versioonide, pakettide versioonide, kõigi Linuxi masinate seisundi jälgimiseks ning seal hoitakse retseptuurit - kõiki Puppet'i manifeste.

Puppet — lahendab kõik vaidlusalused küsimused ja toob täpselt selle konfiguratsiooni, mida me soovime, Gitlab'ist.

Alustame süvenemist. Kuidas toimub DLL-i ülekanne RPM-isse?

DLL-i ülekanne RPM-isse

Oletame, et meil on rockstar arendamiseks .NET-is. Ta kasutab Visual Studio't ja loob vabanemis haru. Pärast seda laadib ta selle Git'i, ja Git on siin TFS-i subjekt, st see on rakenduse reponeering, millega arendaja töötab.

Pärast seda TFS näeb, et saabus uus commit. Milline rakendus? TFS-i seadetes on silt, milliseid ressursse omab teatud Build-agent. Antud juhul näeb ta, et kogume .NET Core projekti ja valib Linux Build-agendi basseinist.

Build-agent saab lähtekoodid, laadib alla vajalikud sõltuvused näiteks .NET hoidlast, npm jne ning pärast rakenduse kokkupanekut ja järgnevat pakkimist saatab RPM-paketi RPM-hoidlasse.

Teiselt poolt toimub järgmine. Operatsioonide insener tegeleb projekti väljaandmisega: muudab pakettide versioone Hieras hoidlas, kus hoitakse rakenduse retsepti, mille järel Puppet käivitab Yumi, tõmbab uue paketi hoidlast ja uus rakenduse versioon on kasutamiseks valmis.

Kuidas me räägime, tundub kõik lihtne, kuid mis tegelikult toimub Build-agendi sees?

DLL-i RPM pakkimine

Lähtekoodid on saadud ja TFS-ilt on saadud kogumise ülesanne. Build-agent käivitab projekti kokkupaneku lähtekoodidest.Kogutud projekt on saadaval mitmesugustes DLL-failides, mis on pakitud zip-arhiivi, et vähendada koormust failisüsteemile.

ZIP-arhiiv visatakse RPM-paketi kogumise katalooge. Edasi Bash skript initsialiseerib keskkonnamuutujad, leiab Buildi versiooni, projekti versiooni, tee kogumise kataloogi ja käivitab RPM-buildi. Pärast kokkupanekut avaldatakse pakett kohalikus hoidlas, mis on Build-agendi peal.

Edasi saadetakse Build-agentilt serverisse JSON-päring versiooni nime ja buildi määramisega. Webhook, millest ma varem rääkisin, tõmbab selle paketi kohalikust hoidlast Build-agendis ja teeb uue kogumise paigaldamiseks kättesaadavaks. Miks on just selline pakettide edastusskeem RPM-hoidlasse? Miks ei saa kohe kokkupandud paketti hoidlasse saata? Asi on selles, et see on tingimus turvalisuse tagamiseks. Selline stsenaarium piirab volitamata isikute võimalust laadida serverisse, mis on avatud kõigile Linuxi masinatele, RPM-pakette.

Andmebaasi versioonimine

Konsiiliumil arendusega selgus, et poisid eelistavad MS SQL-i, kuid enamikul non-Windows projektidest oleme juba ulatuslikult kasutanud PostgreSQL-i. Kuna olime otsustanud loobuda kõikidest tasulistest lahendustest, hakkasime ka siin kasutama PostgreSQL-i.

Konsiiliumis arendamisega selgus, et noorte seas on eelistatum MS SQL, kuid enamikus non-Windows projektides oleme juba PostgreSQL-i laialdaselt kasutanud. Kuna oleme juba otsustanud loobuda kõikidest tasulistest lahendustest, hakkasime ka siin PostgreSQL-i kasutama.

Selles osas tahan rääkida sellest, kuidas me andmebaasi versioone haldasime ja kuidas valisime Flyway ja Entity Framework Core vahel. Vaatame nende plusse ja miinuseid.

Miinused

Flyway töötab ainult ühes suunas, me ei saa tagasi tagasi minna — see on oluline miinus. Entity Framework Core'i saab võrrelda teiste parameetrite järgi — arendaja mugavuse seisukohalt. Te ju mäletate, et me panime selle prioriteediks ja peamine kriteerium oli mitte muuta midagi Windows-arenduse jaoks.

Flyway jaoks vajasime mingit mähist, et arendajad ei kirjutaks SQL-päringuid. Neil on palju mugavam töötada OOP mõistete järgi. Kirjutasime juhised andmebaasi objektidega töötamiseks, SQL-päring moodustus ja täideti. Uus andmebaasi versioon on valmis, testitud — kõik töötab hästi.

Entity Framework Core'il on miinus — suurte koormuste korral loob ta mitteoptimaalseid SQL-päringuid, ja andmebaasi koormus võib olla märkimisväärne. Aga kuna meie teenus ei ole väga koormatud, me ei mõõda koormust sadade RPS-idega, võtsime need riskid ja delegaarisime probleemi tulevikule.

Plussid

Entity Framework Core töötavad karbist välja ja on arendajale mugavad, samas Flyway lihtsalt integreerub olemasolevasse CI-süsteemi.Aga me ju teeme arendajatele mugavate lahendusi :)

Puppet näeb, et versioonide muutmise paketid, sealhulgas migratsioonide vastuolev paket, on saabumas. Esmalt installib see paketi, mis sisaldab migratsiooniskeeme ja andmebaasile seotud funktsionaalsust. Seejärel taaskäivitab rakenduse, mis töötab andmebaasiga. Edasi toimub ülejäänud komponentide installimine. Pakettide installimise ja rakenduste käivitamise järjestus on kirjeldatud Puppet manifestis.

Rakendused kasutavad tundlikke andmeid, nagu tokenid, andmebaasi paroolid, kõik see tõmmatakse Puppet master'i konfiguraatorisse, kus nad on krüptitud kujul talletatud.

TFS-i probleemid

Pärast seda, kui me olime ära otsustanud ja mõistsime, et meil tõepoolest kõik töötab, otsustasin vaadata, mis TFS-is toimub Win-arenduste jaoks teiste projektide osas — kiiresti või mitte, ja avastasin tõsised probleemid kiirusest.

Üks peamisi projekte koostatakse 12-15 minutiga — see on kaua, nii ei saa elada. Kiire analüüs näitas tohutut madalseisu I/O poolest, ja see on massiivide peal.

Komponentide kaupa analüüsides eristasin kolm probleemi allikat. Esimene —

«Kaspersky antivirus» «Kaspersky viirusetõrje», mis skaneerib lähtekoodi kõigil Windows Build-agentidel. Teine - Windows Indekseerija. See ei olnud välja lülitatud ja Build-agentidel indekseeriti reaalajas kõik deploimise protsessis.

Kolmas - npm install. Selgus, et enamikus Pipelines kasutasime just seda stsenaariumi. Miks see halb on? Npm install protseduur käivitub sõltuvuste puu moodustamise ajal package-lock.json, kus fikseeritakse pakettide versioonid, mida projektile kogumisel kasutatakse. Miinuseks on, et npm install toob iga kord värsked pakettide versioonid internetist, mis võtab palju aega suure projekti puhul.

Arendajad katsetavad vahel kohalikul masinal, et kontrollida eraldi osa või projekti toimivust. Mõnikord juhtus, et kohapeal oli kõik suurepärane, kuid kui kogudes ja deployides, ei töötanud midagi. Alustame probleemi uurimist - aha, erinevad pakettide versioonid sõltuvustes.

Lahendus

• Lähtekoodid AV erandite jaoks.
• Indekseerimise väljalülitamine.
• Üleminek npm ci.

npm ci eelised on, et me kogume sõltuvuste puu vaid üks kord, ja saame arendajale pakkuda relevantsete paketide nimekirja, millega ta võib kohapeal katsetada. See kasutab aega arendajate jaoks, kes koodi kirjutavad.

Konfiguratsioon

Nüüd natuke konfigureerimisest. Ajalooliselt oleme kasutanud Nexus repository haldamiseks, sealhulgas Internal REPO. Sellesse sisemisse reposse tarnitakse kõik komponendid, mida me kasutame sisetööde jaoks, näiteks kohandatud monitooringud.

Kasutame ka NuGet, kuna see vahetab paremini kui teised paketihaldurid.

Tulemus

Pärast Build-agentide optimeerimist vähenes keskmine kogumise aeg 12 minutilt 7 minutile.

Kui arvestada kõiki masinaid, mida me oleksime võinud Windowsi jaoks kasutada, kuid mille oleme selles projektis Linuxile üle viinud, säästsime umbes 10 000 dollarit. Ja see on ainult litsentside pealt, aga kui arvestada hooldust - rohkem.

Plaane

Oleme järgmisse kvartalisse planeerinud koodi kohaletoimetamise optimeerimise.

Üleminek eelkoostatud Docker-pildile. TFS on suurepärane asi paljude pluginatega, mis võimaldavad integreerida Pipeline'i, sealhulgas ka kogumist triggered, näiteks Docker-pildi kogumist. Soovime, et see trigger töötab just seda. package-lock.json. Kui projektis kasutatavad koostisosad mingil juhul muutuvad, siis koostame uue Docker-pildi. Tulevikus kasutatakse seda kokku pandud rakenduse konteineri juurutamiseks. Praegu seda ei ole, kuid plaanime üle minna mikroteenuste arhitektuurile Kuberneteses, mis meie firmas aktiivselt areneb ja pikka aega tootmislahendusi teenindab.

Elulookirjeldus

Kutsun kõiki välja viskama Windowsi, kuid see ei ole sellepärast, et ma ei oska seda kasutada. Põhjus on see, et suur osa avatud lähtekoodiga lahendustest on Linuxi tehnoloogia. Te saate hästi ressursside pealt kokku hoida. Minu arvates on tulevik avatud lähtekoodiga lahendustes Linuxil koos tugeva kogukonnaga.

Esineja profiil Aleksandr Sinčvin GitHub'il.

DevOps Conf on arendamise, testimise ja haldamise protsesside integreerimise konverents professionaalide jaoks professionaalide poolt. Just seetõttu on projekt, millest Aleksandr rääkis, realiseeritud ja töötab, ning esinemise päeva jooksul viidi läbi kaks edukat väljalaset. DevOps Conf RIT++-l 27. ja 28. mail on veelgi rohkem sarnaseid juhtumeid praktikutelt. Veel on võimalik hüpata viimasesse vagunisse ja esitama ettekannet või rahulikult broneerima piletit. Kohtume Skolkoves!

Allikas: habr.com