.NET Core on sisse lülitatud LinuxDevOps on tõusuteel

Arendasime DevOpsi nii hästi kui suutsime. Meid oli kaheksa ja Vasja oli neist kõige lahedam. WindowsÄkitselt lahkus Vasja ja mul oli ülesanne käivitada uus projekt, mis varustab Windows-arendus. Kui ma kogu virna lauale viskasin Windows-arengud, siis sain aru, et olukord on valus...

Nii see lugu algab Aleksandra Sinchinova edasi DevOpsConfKui juhtiv spetsialist ettevõttest lahkus Windows, Aleksander mõtles, mida nüüd teha. Mine aadressile LinuxMuidugi! Aleksander räägib teile, kuidas tal õnnestus pretsedent luua ja osa tõlkida Windows arengud Linux kasutades näitena 100 000 lõppkasutaja jaoks lõpetatud projekti.

Kuidas projekti TFS-i, Puppeti ja muude tööriistade abil RPM-ile lihtsalt ja vaevata edastada? Linux .NET Core? Kuidas hallata projekti andmebaasi versioonimist, kui arendaja kuuleb sõnu Postgres ja Flyway esimest korda ning tähtaeg on ülehomme? Kuidas integreerida Dockeriga? Kuidas motiveerida .NET arendajaid loobuma Windows ja smuutid Nukule ja LinuxKuidas lahendada ideoloogilisi konflikte, kui teenite Windows Kas sul pole energiat, soovi või ressursse tootmiskeskkonnaga alustamiseks? Alexanderi ettekanne käsitleb seda, aga ka veebi juurutamist, testimist, CI-d, TFS-i tavasid olemasolevates projektides ning loomulikult katkiseid ja toimivaid lahendusi.

Niisiis, Vasja lahkus, ülesanne oli minu ja arendajad ootasid kannatamatult kahvlitega. Kui ma lõpuks taipasin, et Vasja tagasi ei tule, asusin asja kallale. Esmalt hindasin meie masinapargi Win VM-ide protsenti. Šansid olid tema vastu. Windows.

Kuna me tegeleme aktiivselt DevOpsi arendamisega, mõistsin, et peame uute rakenduste juurutamise lähenemisviisis midagi muutma. Oli ainult üks lahendus: viia kõik võimaluse korral natiivsele tasemele. LinuxGoogle aitas mind – sel ajal oli .Net juba portitud Linux, ja ma sain aru, et see oligi lahendus!

Miks .NET tuum koos Linux?

Sellel oli mitu põhjust. Maksmise ja maksmata jätmise vahel valides valiks enamik inimesi viimase – nagu ka mina. MSDB litsents maksab umbes 1000 dollarit ja virtuaalsete masinate laevastiku haldamine Windows ulatub sadadesse dollaritesse. Suure ettevõtte jaoks on see märkimisväärne kulu. Seetõttu kokkuhoid - esimene põhjus. Mitte kõige olulisem, kuid üks olulisemaid.

Virtuaalsed masinad Windows tarbivad rohkem ressursse kui nende vennad Linux - nad on raskedArvestades suurettevõtte suurust, valisime Linux.

Süsteem on lihtsalt integreeritud olemasolevasse CI-ssePeame end progressiivseteks DevOpsi esindajateks, kasutame Bamboot, Jenkinsit ja GitLab CI-d, seega suurem osa meie tööst toimub Linux.

Viimane põhjus on mugav kaaslane. Me pidime langetama sisenemisbarjääri "hooldajatele" – neile, kes mõistavad tehnilist poolt, tagavad tööaja ja haldavad teenuseid teisest liinist alates. Nad olid juba süsteemiga tuttavad. Linux, seega on neil uue toote mõistmine, toetamine ja hooldamine palju lihtsam kui sarnaste tarkvarafunktsioonide mõistmiseks lisaressursse kulutada. Windows platvorm.

Nõuded

Eelkõige - uue lahenduse mugavus arendajateleMitte kõik neist polnud muutusteks valmis, eriti pärast seda, kui sõna oli lausutud. LinuxArendajad tahavad oma lemmik Visual Studiot, TFS-i automatiseeritud ehitustestidega ja smoothies'eid. See, kuidas nad tootmiskeskkonda jõuavad, pole nende jaoks oluline. Seetõttu otsustasime tuttavat protsessi mitte muuta ja selle sinnapaika jätta. Windows- arengud jäävad samaks.

Vaja uus projekt integreerida olemasolevasse CI-sse. Rööpad olid juba olemas ja kogu töö tuli teha konfiguratsioonihaldussüsteemi parameetreid, aktsepteeritud tarnestandardeid ja seiresüsteeme arvestades.

Toetamise ja kasutamise lihtsus, mis on kõikide uute osalejate eri osakondadest ja tugiosakonnast minimaalse sisseastumisläve tingimuseks.

Tähtaeg - eile.

Võida arendusgrupp

Millega meeskond siis töötas? Windows?

Nüüd võin seda julgelt väita Identiteediserver4 on lahe tasuta alternatiiv sarnaste võimalustega ADFS-ile või mis Olemi raamistiku tuum - arendaja paradiis, kus ei pea vaeva nägema SQL skriptide kirjutamisega, vaid kirjeldama andmebaasis olevaid päringuid OOP terminites. Aga siis, tegevuskava arutamise ajal, vaatasin seda virna, nagu oleks see sumeri kiilkiri, tundes ära ainult PostgreSQL ja Git.

Sel ajal kasutasime aktiivselt Nukuteater konfiguratsioonihaldussüsteemina. Enamikus oma projektides kasutasime GitLab CI, Elastne, tasakaalustatud suure koormusega teenuseid kasutades HAProxy jälgis kõike Zabbix, sidemed grafana и Prometheus, Jaeger, ja see kõik keerles rauatükkide peal HP c ESXi edasi VMware. Kõik teavad seda – žanri klassika.

Vaatame ja proovime mõista, mis toimus enne kõigi nende sekkumiste alustamist.

Mis juhtus

TFS on üsna võimas süsteem, mis mitte ainult ei edasta koodi arendajalt lõplikule tootmismasinale, vaid omab ka komplekti väga paindlikuks integreerimiseks erinevate teenustega - CI pakkumiseks platvormidevahelisel tasemel.

Varem olid need kõik aknad. TFS kasutas mitut ehitusagenti, mis ehitasid mitu projekti. Igal agendil oli 3-4 töötajat ülesannete paralleelseks ja protsessi optimeerimiseks. Seejärel, vastavalt väljalaskeplaanidele, edastas TFS värskelt küpsetatud ehituse... Windows- rakendusserver.

Mida me saavutada tahtsime?

Kasutame TFS-i nii tarnimiseks kui ka arenduseks ning käivitame rakenduse Linux Rakendusserver ja nende vahel on mingi võlujõud. See Magic Box ja ees on töö sool. Enne lahti võtmist astun sammu kõrvale ja räägin mõne sõna rakenduse kohta.

Projekt

Rakendus pakub funktsioone ettemakstud kaartide käsitlemiseks.

klient

Kasutajaid oli kahte tüüpi. Esimene sai juurdepääsu SSL SHA-2 sertifikaadiga sisse logides. U teine oli juurdepääs sisselogimise ja parooliga.

HAProxy

Seejärel läks kliendi taotlus HAProxy-le, mis lahendas järgmised probleemid:

• esmane luba;
• SSL-i lõpetamine;
• HTTP päringute häälestamine;
• saatetaotlused.

Kliendi sertifikaati kontrolliti kogu ahela ulatuses. Meie - asutus ja me saame seda endale lubada, kuna me ise väljastame teenindusklientidele sertifikaate.

Pöörake tähelepanu kolmandale punktile, selle juurde naaseme veidi hiljem.

Taustaprogramm

Tagaosa oli plaanis teha LinuxTagaserver suhtleb andmebaasiga, laadib vajaliku õiguste loendi ja seejärel, olenevalt volitatud kasutaja õigustest, annab juurdepääsu finantsdokumentide allkirjastamiseks ja täitmiseks saatmiseks või aruande genereerimiseks.

Säästud HAProxyga

Lisaks kahele kontekstile, milles iga klient navigeeris, oli olemas ka identiteedikontekst. Identiteediserver4 võimaldab lihtsalt sisse logida, see on tasuta ja võimas analoog ADFS - Active Directory föderatsiooni teenused.

Identiteeditaotlust töödeldi mitmes etapis. Esimene samm - klient sattus tagaprogrammi, mis suhtles selle serveriga ja kontrollis kliendi tokeni olemasolu. Kui seda ei leitud, tagastati päring tagasi konteksti, kust see pärines, kuid ümbersuunamisega ja koos ümbersuunamisega läks see identiteedile.

Teine samm – taotlus võeti vastu IdentityServeri autoriseerimislehele, kuhu klient registreerus, ja see kauaoodatud märk ilmus IdentityServeri andmebaasi.

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

IdentityServer4-l on funktsioon: see tagastab vastuse tagastamistaotlusele HTTP kaudu. Ükskõik kui palju me serveri seadistamisega vaeva nägime, kui palju me end dokumentatsiooniga valgustasime, saime iga kord esialgse kliendipäringu URL-iga, mis tuli HTTPS-i kaudu ja IdentityServer tagastas sama konteksti, kuid HTTP-ga. Olime šokeeritud! Ja me kandsime selle kõik läbi identiteedikonteksti HAProxy-sse ja päistes pidime muutma HTTP-protokolli HTTPS-iks.

Mis on paranemine ja kust säästsite?

Säästsime raha, kasutades tasuta lahendust kasutajate grupi, ressursside autoriseerimiseks, kuna me ei paigutanud IdentityServer4 eraldiseisvasse segmenti eraldi sõlmena, vaid kasutasime seda koos taustaprogrammiga samas serveris, kus rakenduse taustaprogramm töötab. .

Kuidas see peaks toimima

Niisiis, nagu ma lubasin – Magic Box. Me juba mõistame, et liigume kindlasti selles suunas LinuxSõnastagem konkreetsed ülesanded, mis vajasid lahendamist.

Nuku manifest. Teenuste ja rakenduste konfiguratsiooni tarnimiseks ja haldamiseks tuli kirjutada lahedaid retsepte. Pliiatsirull näitab kõnekalt, kui kiiresti ja tõhusalt see tehtud sai.

Kohaletoimetamise viis. Standard on RPM. Kõik saavad sellest aru. Linux Sellest polnud muud üle, aga projekt ise oli pärast ehitamist käivitatavate DLL-failide kogum. Neid oli umbes 150, mis tegi projekti üsna mahukaks. Ainus jätkusuutlik lahendus oli pakkida need binaarfailid RPM-i ja rakendus sealt juurutada.

Versioonide koostamine. Me kavatsesime väga tihti välja anda ja pidime otsustama, kuidas paketi nime moodustada. See oli TFS-iga integratsiooni taseme küsimus. Meil ​​oli peal ehitusagent LinuxKui TFS saadab Build agendi töötajale ülesande, edastab see talle ka hulga muutujaid, mis on salvestatud töötaja keskkonda. Need keskkonnamuutujad sisaldavad järgu nime, versiooni nime ja muid muutujaid. Lisateavet leiate jaotisest "RPM-paketi loomine".

TFS-i seadistamine Kõik taandus torujuhtme rajamisele. Varem ehitasime edasi Windows- kõik agendid Windows-projektid ja nüüd paistab see välja Linux-agent — ehitusagent, mis tuleb lisada ehitusgruppi, rikastada mõne artefaktiga, määrata, millist tüüpi projekte sellele ehitusagendile ehitatakse, ja muuta mingil moel torujuhet.

Identiteediserver. ADFS ei ole meie tee, me kasutame avatud lähtekoodi.

Vaatame komponente läbi.

Magic Box

Koosneb neljast osast.

Linux Ehitusagent. Linux, sest me kompileerime selle jaoks – see on loogiline. See osa valmis kolmes etapis.

• Konfigureerige töötajaid ja mitte üksi, sest projektiga loodeti jagada tööd.
• Installige .NET Core 1.x. Miks 1.x, kui 2.0 on standardhoidlas juba saadaval? Sest kui arendamisega alustasime, oli stabiilne versioon 1.09 ja selle põhjal otsustatigi projekt teha.
• Git 2.x.

RPM-hoidla. RPM-paketid pidid kuskil olema. Me pidime kasutama sama ettevõtte RPM-hoidlat, mis oli kõigile ligipääsetav. Linux hostid. Seda me tegimegi. Hoidla server on konfigureeritud veebikonks mis laadis määratud asukohast alla vajaliku RPM-paketi. Paketi versioonist teatas veebihaagile ehitusagent.

GitLab. Pane tähele: GitLabi ei kasuta siin arendajad, vaid operatsioonide osakond rakenduste versioonide, pakettide versioonide ja kõigi oleku haldamiseks. Linux-masinad ja see salvestab retsepti - kõik nukute manifestid.

Nukuteater — lahendab kõik vastuolulised probleemid ja pakub Gitlabilt täpselt sellise konfiguratsiooni, mida me tahame.

Hakkame sukelduma. Kuidas DLL-i edastamine RPM-ile töötab?

Tarne DDL kuni RPM

Oletame, et meil on .NET-i arenduse rokkstaar. See kasutab Visual Studio ja loob väljalaskeharu. Pärast seda laadib see selle Giti üles ja Git on siin TFS-üksus, st see on rakenduste hoidla, millega arendaja töötab.

Pärast seda näeb TFS, et uus commit on saabunud. Milline rakendus? TFS-i sätted näitavad, millised ressursid igal ehitusagendil on. Sel juhul näeb see, et me ehitame .NET Core'i projekti ja valib Linux Loo agent basseinist.

Ehitusagent saab allikad ja laadib need alla sõltuvused .NET-i hoidlast, npm-st jne. ja pärast rakenduse enda koostamist ja sellele järgnevat pakkimist saadab RPM-i paketi RPM-i hoidlasse.

Teisest küljest juhtub järgmine. Operatsiooniosakonna insener on projekti juurutamisega otseselt seotud: ta muudab sisse pakettide versioone Hiera hoidlas, kus on salvestatud rakenduse retsept, mille järel vallandub Nukk Yum, toob hoidlast uue paketi ja rakenduse uus versioon on kasutamiseks valmis.

Sõnades on kõik lihtne, aga mis toimub Buildi agendi enda sees?

Pakkimine DLL RPM

Sai projekti allikad ja ehitusülesande TFS-ist. Ehitusagent hakkab projekti ise allikatest üles ehitama. Kokkupandud projekt on saadaval komplektina DLL-failid, mis on failisüsteemi koormuse vähendamiseks pakitud ZIP-arhiivi.

ZIP-arhiiv visatakse minema RPM-paketi ehituskataloogi. Järgmisena lähtestab Bashi skript keskkonnamuutujad, otsib ülesehituse versiooni, projekti versiooni, tee ehituskataloogi ja käivitab RPM-ehituse. Kui ehitamine on lõpetatud, avaldatakse pakett aadressil kohalik hoidla, mis asub ehitusagendil.

Järgmiseks ehitusagendilt serverisse RPM-i hoidlas JSON-i päring on saadetud märkides versiooni ja järgu nime. Webhook, millest ma varem rääkisin, laadib just selle paketi Build agendi kohalikust hoidlast alla ja teeb uue koostu installimiseks kättesaadavaks.

Miks RPM-repositooriumi jaoks just see konkreetne edastusskeem? Miks ei saa loodud paketti kohe repositooriumisse saata? See on turvanõue. See stsenaarium piirab võimalust, et volitamata isikud laadivad RPM-pakette üles avalikult ligipääsetavale serverile. Linux-autod.

Andmebaasi versioonide loomine

Arenduskonsultatsioonil selgus, et tüübid on MS SQL-ile lähemal, aga enamasti mitte-Windows Kasutasime PostgreSQL-i juba ulatuslikult mitme projekti jaoks. Kuna olime juba otsustanud tasulisest tarkvarast loobuda, hakkasime ka siin PostgreSQL-i kasutama.

Selles osas tahan teile rääkida, kuidas me andmebaasi versiooni tegime ja kuidas valisime Flyway ja Entity Framework Core'i vahel. Vaatame nende plusse ja miinuseid.

Miinused

Flyway läheb ainult ühte suunda, meie me ei saa tagasi pöörata — see on märkimisväärne puudus. Seda saab Entity Framework Core'iga võrrelda ka muul viisil – arendaja mugavuse seisukohast. Mäletate, et seadsime selle esmatähtsaks ja peamine kriteerium oli mitte midagi muuta Windows-arengud.

Meie jaoks Flyway mingit ümbrist oli vajaet poisid ei kirjutaks SQL päringud. Nad on OOP-i mõistes tegutsemisele palju lähemal. Kirjutasime juhised andmebaasiobjektidega töötamiseks, genereerisime SQL-päringu ja käivitasime selle. Andmebaasi uus versioon on valmis, testitud - kõik on korras, kõik töötab.

Entity Framework Core'il on miinus – suure koormuse korral see loob suboptimaalseid SQL päringuid, ja andmebaasi vähenemine võib olla märkimisväärne. Aga kuna meil pole suure koormusega teenust, siis me ei arvuta koormust sadades RPS-ides, võtsime need riskid vastu ja delegeerisime probleemi enda kanda.

Plusse

Olemi raamistiku tuum töötab karbist välja ja seda on lihtne arendadaja Flyway Lihtne integreerida olemasolevasse CI-sse. Aga teeme selle arendajatele mugavaks :)

Roll-up protseduur

Puppet näeb, et tulemas on muudatus paketi versioonis, sealhulgas selles, mis vastutab migratsiooni eest. Esiteks installib see paketi, mis sisaldab migratsiooniskripte ja andmebaasiga seotud funktsioone. Pärast seda taaskäivitatakse andmebaasiga töötav rakendus. Järgmine on ülejäänud komponentide paigaldamine. Pakettide installimise ja rakenduste käivitamise järjekorda kirjeldatakse Puppeti manifestis.

Rakendused kasutavad tundlikke andmeid, nagu märgid, andmebaasi paroolid, kõik see tõmmatakse Puppet masterist konfiguratsiooni, kus need salvestatakse krüpteeritud kujul.

TFS-i probleemid

Pärast seda, kui olime otsustanud ja mõistnud, et meie jaoks kõik tõesti töötab, otsustasin vaadata, mis toimub Win arendusosakonna TFS-i koostudega tervikuna teiste projektide puhul – kas ehitasime/väljastame kiiresti või mitte, ja avastas olulisi probleeme kiirusega.

Ühe põhiprojekti kokkupanekuks kulub 12-15 minutit – see on pikk aeg, nii ei saa elada. Kiire analüüs näitas sisend-väljundis kohutavat tõrget ja see oli massiividel.

Pärast selle komponentide kaupa analüüsimist tuvastasin kolm koldet. Esiteks - "Kaspersky viirusetõrje", mis kehtib kõigile Windows Ehitusagendid skannivad lähtekoodi. Teine on Windows Indekseerija. Seda ei keelatud ja kõik indekseeriti juurutusprotsessi ajal ehitusagentides reaalajas.

Kolmas - Npm installimine. Selgus, et enamiku torujuhtmete puhul kasutasime täpselt seda stsenaariumi. Miks ta halb on? Npm installiprotseduur käivitatakse, kui sõltuvuspuu moodustatakse pakett-lukk.json, kus salvestatakse projekti koostamiseks kasutatavate pakettide versioonid. Negatiivne külg on see, et Npm install tõmbab iga kord Internetist uusimad pakettide versioonid ja see võtab suure projekti puhul palju aega.

Arendajad katsetavad mõnikord kohaliku masinaga, et testida, kuidas konkreetne osa või kogu projekt töötab. Mõnikord selgus, et kohapeal oli kõik lahe, aga panid kokku, rullisid lahti ja miski ei töötanud. Hakkame aru saama, milles probleem on – jah, erinevad sõltuvustega pakettide versioonid.

otsus

• Allikad AV erandites.
• Keela indekseerimine.
• Üleminek npm ci.

Npm ci eelised seisnevad selles, et meie Kogume sõltuvuspuu üks kordja saame võimaluse pakkuda arendajale praegune pakettide nimekiri, millega ta saab kohapeal katsetada nii palju kui tahab. See säästab aega arendajad, kes kirjutavad koodi.

Konfiguratsioon

Nüüd natuke hoidla konfiguratsioonist. Ajalooliselt kasutame Nexus hoidlate haldamiseks, sealhulgas Sisemine REPO. See sisemine repositoorium sisaldab kõiki komponente, mida kasutame sisemistel eesmärkidel, näiteks enda kirjutatud jälgimiseks.

Kasutame ka NuGet, kuna sellel on teiste paketihalduritega võrreldes parem vahemälu.

Tulemus

Pärast ehitusagentide optimeerimist vähenes keskmine ehitusaeg 12 minutilt 7-le.

Kui loeme kokku kõik masinad, mida saaksime kasutada Windows, aga tõlgituna keelde Linux Selle projektiga säästsime umbes 10 000 dollarit. Ja see on ainult litsentside pealt; kui arvestada ka sisu, on see veelgi suurem.

Plaanid

Järgmises kvartalis plaanisime töötada koodi edastamise optimeerimisega.

Lülitumine eelkoostatud Dockeri pildile. TFS on lahe asi paljude pistikprogrammidega, mis võimaldavad teil Pipeline'i integreerida, sealhulgas näiteks Dockeri kujutise päästikupõhine kokkupanek. Tahame selle käivitada samale pakett-lukk.json. Kui projekti koostamiseks kasutatud komponentide koostis kuidagi muutub, ehitame uue Dockeri pildi. Seda kasutatakse hiljem konteineri juurutamiseks koos kokkupandud rakendusega. Praegu see nii ei ole, kuid meie ettevõttes aktiivselt arenevas ja juba pikemat aega tootmislahendusi teenindavas Kubernetes plaanime üle minna mikroteenuste arhitektuurile.

Kokkuvõte

Ma kutsun kõiki üles see minema viskama Windows, aga see pole sellepärast, et ma ei teaks, kuidas seda valmistada. Põhjus on selles, et enamik avatud lähtekoodiga lahendusi on Linux-virn. kas sul on kõik korras säästa ressursseMinu arvates on tulevik avatud lähtekoodiga lahenduste päralt. Linux võimsa kogukonnaga.

Aleksandr Sintšinovi kõneleja profiil GitHubis.

DevOps Conf on konverents arendus-, testimis- ja tööprotsesside integreerimisest professionaalidele professionaalide poolt. Sellepärast see projekt, millest Aleksander rääkis? rakendatud ja töökorras ning esinemispäeval ilmus kaks edukat väljaannet. Peal DevOps Conf aadressil RIT++ 27. ja 28. mail on sarnaseid juhtumeid praktikutelt veelgi rohkem. Viimasesse vankrisse saab veel hüpata ja esitada aruanne või võta aega broneerima pilet. Kohtume Skolkovos!

Allikas: www.habr.com