Ons het DevOps ontwikkel so goed ons kon. Daar was 8 van ons, en Vasya was die coolste in Windows. Skielik het Vasya vertrek, en ek het die taak gehad om 'n nuwe projek te begin wat deur Windows-ontwikkeling verskaf is. Toe ek die hele Windows-ontwikkelingstapel op die tafel gooi, het ek besef dat die situasie 'n pyn was ...
Dit is hoe die storie begin Alexandra Sinchinova op . Toe die voorste Windows-spesialis die maatskappy verlaat, het Alexander gewonder wat om nou te doen. Skakel natuurlik oor na Linux! Alexander sal jou vertel hoe hy daarin geslaag het om 'n presedent te skep en 'n deel van Windows-ontwikkeling na Linux oor te dra deur die voorbeeld van 'n voltooide projek vir 100 000 eindgebruikers te gebruik.
Hoe om 'n projek maklik en moeiteloos aan RPM te lewer met behulp van TFS, Puppet, Linux .NET-kern? Hoe om weergawe van 'n projekdatabasis te ondersteun as die ontwikkelingspan die woorde Postgres en Flyway vir die eerste keer hoor, en die sperdatum is oormôre? Hoe om met Docker te integreer? Hoe om .NET-ontwikkelaars te motiveer om Windows en smoothies te laat vaar ten gunste van Puppet en Linux? Hoe om ideologiese konflikte op te los as daar nie die krag, nóg die begeerte of die hulpbronne is om Windows in produksie te handhaaf nie? Hieroor, sowel as oor Web Deploy, toetsing, CI, oor die praktyke van die gebruik van TFS in bestaande projekte, en natuurlik oor stukkende krukke en werkende oplossings, in die transkripsie van Alexander se verslag.
So, Vasya het vertrek, die taak is op my, die ontwikkelaars wag ongeduldig met pikvurke. Toe ek uiteindelik besef dat Vasya nie teruggegee kan word nie, het ek aan die gang gekom. Om mee te begin, het ek die persentasie Win VM's in ons vloot beoordeel. Die telling was nie ten gunste van Windows nie.
Aangesien ons aktief besig is om DevOps te ontwikkel, het ek besef dat iets verander moet word in die benadering tot die lewering van 'n nuwe toepassing. Daar was net een oplossing - indien moontlik, dra alles oor na Linux. Google het my gehelp - op daardie tydstip was .Net reeds oorgedra na Linux, en ek het besef dat dit die oplossing is!
Hoekom .NET kern in samewerking met Linux?
Daar was verskeie redes hiervoor. Tussen “betaal geld” en “nie betaal nie”, sal die meerderheid die tweede kies – soos ek. 'n Lisensie vir MSDB kos ongeveer $1 000; die instandhouding van 'n vloot virtuele Windows-masjiene kos honderde dollars. Vir 'n groot maatskappy is dit 'n groot uitgawe. Dis hoekom besparing - eerste rede. Nie die belangrikste nie, maar een van die beduidende.
Virtuele Windows-masjiene neem meer hulpbronne op as hul Linux-broers - hulle is swaar. Gegewe die omvang van die groot maatskappy, het ons Linux gekies.
Die stelsel is eenvoudig geïntegreer in bestaande CI. Ons beskou onsself as progressiewe DevOps, ons gebruik Bamboo, Jenkins en GitLab CI, so die meeste van ons werk loop op Linux.
Die laaste rede is gerieflike begeleiding. Ons moes die versperring tot toegang verlaag vir "begeleidings" - die ouens wat die tegniese deel verstaan, ononderbroke diens verseker en dienste vanaf die tweede lyn onderhou. Hulle was reeds vertroud met die Linux-stapel, so dit is vir hulle baie makliker om 'n nuwe produk te verstaan, te ondersteun en in stand te hou as om bykomende hulpbronne te spandeer om dieselfde funksionaliteit van sagteware vir die Windows-platform te verstaan.
Vereistes
Eerstens - gerief van die nuwe oplossing vir ontwikkelaars. Nie almal van hulle was gereed vir verandering nie, veral nadat die woord Linux uitgespreek is. Ontwikkelaars wil hul gunsteling Visual Studio, TFS hê met outotoetse vir samestellings en smoothies. Hoe aflewering na produksie plaasvind, is nie vir hulle belangrik nie. Daarom het ons besluit om nie die gewone proses te verander nie en alles onveranderd te laat vir Windows-ontwikkeling.
Nuwe projek benodig integreer in bestaande CI. Die relings was reeds daar en al die werk moes gedoen word met inagneming van die parameters van die konfigurasiebestuurstelsel, aanvaarde afleweringstandaarde en moniteringstelsels.
Gemak van ondersteuning en werking, as voorwaarde vir die minimum toegangsdrempel vir alle nuwe deelnemers van verskillende afdelings en die ondersteuningsafdeling.
Sperdatum - gister.
Wen Ontwikkelingsgroep
Waarmee het die Windows-span toe gewerk?
Nou kan ek dit met selfvertroue sê IdentityServer4 is 'n koel gratis alternatief vir ADFS met soortgelyke vermoëns, of wat Entiteitsraamwerkkern - 'n paradys vir 'n ontwikkelaar, waar jy nie die moeite hoef te doen om SQL-skrifte te skryf nie, maar navrae in die databasis in OOP-terme beskryf. Maar toe, tydens die bespreking van die aksieplan, het ek na hierdie stapel gekyk asof dit Sumeriese spykerskrif is, en net PostgreSQL en Git herken.
Op daardie tydstip het ons aktief gebruik Puppet as 'n konfigurasiebestuurstelsel. In die meeste van ons projekte het ons gebruik GitLab CI, Rek, gebalanseerde hoë-lading dienste gebruik HAProxy alles gemonitor met Zabbix, ligamente grafana и Prometheus, Jaeger, en dit alles het op stukke yster gedraai HP c ESXi op VMware. Almal weet dit - 'n klassieke van die genre.
Kom ons kyk en probeer verstaan wat gebeur het voordat ons al hierdie ingrypings begin het.
Wat het gebeur
TFS is 'n redelik kragtige stelsel wat nie net kode van die ontwikkelaar na die finale produksiemasjien lewer nie, maar ook 'n stel het vir baie buigsame integrasie met verskeie dienste - om CI op 'n kruisplatformvlak te verskaf.
Voorheen was dit soliede vensters. TFS het verskeie Bou-agente gebruik, wat gebruik is om baie projekte saam te stel. Elke agent het 3-4 werkers om take te paralleliseer en die proses te optimaliseer. Toe, volgens vrystellingsplanne, het TFS die varsgebakte Build aan die Windows-toepassingsbediener afgelewer.
Wat wou ons bereik?
Ons gebruik TFS vir aflewering en ontwikkeling, en loop die toepassing op 'n Linux-toepassingsbediener, en daar is 'n soort magie tussen hulle. Hierdie Toorkas en daar is die sout van die werk wat voorlê. Voordat ek dit uitmekaar haal, sal ek 'n tree opsy gee en 'n paar woorde oor die toepassing sê.
Project
Die toepassing bied funksionaliteit vir die hantering van voorafbetaalde kaarte.
Kliënt
Daar was twee tipes gebruikers. Eerste toegang verkry deur aan te meld met 'n SSL SHA-2-sertifikaat. U die tweede daar was toegang deur 'n login en wagwoord te gebruik.
HAProxy
Toe gaan die kliëntversoek na HAProxy, wat die volgende probleme opgelos het:
- primêre magtiging;
- SSL beëindiging;
- instel van HTTP-versoeke;
- uitsaaiversoeke.
Die kliëntsertifikaat is langs die ketting geverifieer. Ons - gesag en ons kan dit bekostig, aangesien ons self sertifikate aan dienskliënte uitreik.
Gee aandag aan die derde punt, ons sal 'n bietjie later terugkom.
Backend
Hulle het beplan om die backend op Linux te maak. Die backend is in wisselwerking met die databasis, laai die nodige lys van voorregte en dan, afhangende van watter voorregte die gemagtigde gebruiker het, bied toegang om finansiële dokumente te onderteken en vir uitvoering te stuur, of om 'n soort verslag te genereer.
Spaar met HAProxy
Benewens die twee kontekste wat elke kliënt navigeer, was daar ook 'n identiteitskonteks. IdentityServer4 laat jou net toe om aan te meld, dit is 'n gratis en kragtige analoog vir ADFS - Active Directory Federasie Dienste.
Die identiteitsversoek is in verskeie stappe verwerk. Eerste stap - kliënt in die agterkant gekom, wat met hierdie bediener gekommunikeer het en die teenwoordigheid van 'n teken vir die kliënt nagegaan het. As dit nie gevind is nie, is die versoek teruggestuur na die konteks waaruit dit kom, maar met 'n herleiding, en met die herleiding het dit na identiteit gegaan.
Tweede stap - die versoek is ontvang na die magtigingsbladsy in IdentityServer, waar die kliënt geregistreer het, en daardie langverwagte teken verskyn in die IdentityServer-databasis.
Derde stap - die kliënt is terug herlei na die konteks waaruit dit gekom het.
IdentityServer4 het 'n kenmerk: dit gee die antwoord op die terugkeerversoek via HTTP terug. Maak nie saak hoeveel ons gesukkel het met die opstel van die bediener nie, maak nie saak hoeveel ons onsself met die dokumentasie verlig het nie, elke keer het ons 'n aanvanklike kliëntversoek ontvang met 'n URL wat via HTTPS gekom het, en IdentityServer het dieselfde konteks teruggestuur, maar met HTTP. Ons was geskok! En ons het dit alles deur die identiteitskonteks na HAProxy oorgedra, en in die opskrifte moes ons die HTTP-protokol na HTTPS verander.
Wat is die verbetering en waar het jy gespaar?
Ons het geld gespaar deur 'n gratis oplossing te gebruik vir die magtiging van 'n groep gebruikers, hulpbronne, aangesien ons nie IdentityServer4 as 'n aparte nodus in 'n aparte segment geplaas het nie, maar dit saam met die backend op dieselfde bediener gebruik het waar die agterkant van die toepassing loop .
Hoe dit moet werk
So, soos ek belowe het - Magic Box. Ons verstaan reeds dat ons gewaarborg is om na Linux te beweeg. Kom ons formuleer spesifieke take wat oplossings vereis het.
Poppie manifesteer. Om diens- en toepassingkonfigurasie te lewer en te bestuur, moes koel resepte geskryf word. ’n Rol potlood wys welsprekend hoe vinnig en doeltreffend dit gedoen is.
Aflewerings metode. Die standaard is RPM. Almal verstaan dat jy in Linux nie daarsonder kan klaarkom nie, maar die projek self, na samestelling, was 'n stel uitvoerbare DLL-lêers. Daar was omtrent 150 van hulle, die projek was nogal moeilik. Die enigste harmonieuse oplossing is om hierdie binêre in RPM te verpak en die toepassing daaruit te ontplooi.
Weergawe. Ons moes baie gereeld vrystel, en ons moes besluit hoe om die pakketnaam te vorm. Dit is 'n kwessie van die vlak van integrasie met TFS. Ons het 'n bou-agent op Linux gehad. Wanneer TFS 'n taak na 'n hanteerder - werker - na die Bou-agent stuur, gee dit ook 'n klomp veranderlikes aan wat in die omgewing van die hanteerderproses beland. Hierdie omgewingsveranderlikes bevat die Bou-naam, weergawenaam en ander veranderlikes. Lees meer hieroor in die afdeling "Bou 'n RPM-pakket".
Die opstel van TFS neergekom op die opstel van Pyplyn. Voorheen het ons alle Windows-projekte op Windows-agente versamel, maar nou verskyn 'n Linux-agent - 'n Bou-agent, wat by die bougroep ingesluit moet word, verryk moet word met sommige artefakte, en vertel watter tipe projekte op hierdie Bou-agent gebou sal word , en op een of ander manier die Pyplyn verander.
IdentityServer. ADFS is nie ons manier nie, ons gaan vir Open Source.
Kom ons gaan deur die komponente.
Toorkas
Bestaan uit vier dele.
Linux Build-agent. Linux, want ons bou daarvoor - dit is logies. Hierdie deel is in drie stappe gedoen.
- Stel werkers op en nie alleen nie, aangesien verspreide werk aan die projek verwag is.
- Installeer .NET Core 1.x. Waarom 1.x wanneer 2.0 reeds in die standaardbewaarplek beskikbaar is? Want toe ons begin ontwikkel het, was die stabiele weergawe 1.09, en daar is besluit om die projek op grond daarvan te maak.
- Git 2.x.
RPM-bewaarplek. RPM-pakkette moes iewers gestoor word. Daar is aanvaar dat ons dieselfde korporatiewe RPM-bewaarplek sal gebruik wat vir alle Linux-gashere beskikbaar is. Dit is wat hulle gedoen het. Die bewaarplekbediener is gekonfigureer webhaak wat die vereiste RPM-pakket vanaf die gespesifiseerde plek afgelaai het. Die pakketweergawe is deur die Build-agent aan die webhook gerapporteer.
gitlab. Aandag! GitLab hier word nie deur ontwikkelaars gebruik nie, maar deur die bedryfsafdeling om toepassingsweergawes, pakketweergawes te beheer, die status van alle Linux-masjiene te monitor, en dit stoor die resep - alle Puppet-manifeste.
Puppet - los alle kontroversiële kwessies op en lewer presies die konfigurasie wat ons van Gitlab wil hê.
Ons begin duik. Hoe werk DLL-aflewering na RPM?
Lewering DDL na RPM
Kom ons sê ons het 'n .NET-ontwikkelingsrockster. Dit gebruik Visual Studio en skep 'n vrystellingtak. Daarna laai dit dit op na Git, en Git hier is 'n TFS-entiteit, dit wil sê dit is die toepassingsbewaarplek waarmee die ontwikkelaar werk.
Waarna TFS sien dat 'n nuwe commit aangebreek het. Watter toepassing? In die TFS-instellings is daar 'n etiket wat aandui watter hulpbronne 'n spesifieke Bou-agent het. In hierdie geval sien hy dat ons 'n .NET Core-projek bou en kies 'n Linux Build-agent uit die swembad.
Die Bou-agent ontvang die bronne en laai die nodige af dependencies vanaf die .NET-bewaarplek, npm, ens. en na die bou van die toepassing self en die daaropvolgende verpakking, stuur die RPM-pakket na die RPM-bewaarplek.
Aan die ander kant gebeur die volgende. Die bedryfsafdeling se ingenieur is direk betrokke by die ontplooiing van die projek: hy verander die weergawes van pakkette in Hiera in die bewaarplek waar die toepassingsresep gestoor word, waarna Puppet snellers yum, haal die nuwe pakket uit die bewaarplek, en die nuwe weergawe van die toepassing is gereed om te gebruik.
Alles is eenvoudig in woorde, maar wat gebeur binne die Build-agent self?
Verpakking DLL RPM
Projekbronne en boutaak van TFS ontvang. Bou agent begin om die projek self uit bronne te bou. Die saamgestelde projek is as 'n stel beskikbaar DLL-lêers, wat in 'n zip-argief verpak is om die las op die lêerstelsel te verminder.
Die zip-argief word weggegooi na die RPM-pakketbougids. Vervolgens inisialiseer die Bash-skrip die omgewingsveranderlikes, vind die Build-weergawe, die projekweergawe, die pad na die build-gids en laat RPM-build loop. Sodra die bou voltooi is, word die pakket gepubliseer na plaaslike bewaarplek, wat op die Build-agent geleë is.
Volgende, van die Bou-agent na die bediener in die RPM-bewaarplek JSON-versoek is gestuur wat die naam van die weergawe en bou aandui. Webhook, waaroor ek vroeër gepraat het, laai hierdie einste pakket van die plaaslike bewaarplek op die Build-agent af en maak die nuwe samestelling beskikbaar vir installasie.
Waarom hierdie spesifieke pakketafleweringskema na die RPM-bewaarplek? Hoekom kan ek nie dadelik die saamgestelde pakket na die bewaarplek stuur nie? Die feit is dat dit 'n voorwaarde is om veiligheid te verseker. Hierdie scenario beperk die moontlikheid dat ongemagtigde mense RPM-pakkette oplaai na 'n bediener wat toeganklik is vir alle Linux-masjiene.
Databasis weergawe
By 'n konsultasie met die ontwikkelingspan het dit geblyk dat die ouens nader aan MS SQL was, maar in die meeste nie-Windows-projekte het ons reeds PostgreSQL met alle mag gebruik. Aangesien ons reeds besluit het om alles wat betaal is, te laat vaar, het ons PostgreSQL ook hier begin gebruik.
In hierdie deel wil ek jou vertel hoe ons die databasis weergawe het en hoe ons tussen Flyway en Entity Framework Core gekies het. Kom ons kyk na hul voor- en nadele.
Nadele
Vliegpad gaan net een kant toe, ons ons kan nie terugrol nie - dit is 'n beduidende nadeel. U kan dit op ander maniere met Entity Framework Core vergelyk - in terme van ontwikkelaargerief. U onthou dat ons dit op die voorgrond gestel het, en die hoofkriterium was om niks vir Windows-ontwikkeling te verander nie.
Vir Flyway ons 'n soort omhulsel was nodigsodat die ouens nie skryf nie SQL-navrae. Hulle is baie nader daaraan om in OOP-terme te werk. Ons het instruksies geskryf om met databasisobjekte te werk, 'n SQL-navraag gegenereer en dit uitgevoer. Die nuwe weergawe van die databasis is gereed, getoets - alles is reg, alles werk.
Entity Framework Core het 'n minus - onder swaar vragte dit bou suboptimale SQL-navrae, en die onttrekking in die databasis kan beduidend wees. Maar aangesien ons nie 'n hoëladingdiens het nie, bereken ons nie die vrag in honderde RPS nie, ons het hierdie risiko's aanvaar en die probleem aan toekomstige ons gedelegeer.
Pros
Entiteitsraamwerkkern werk uit die boks en is maklik om te ontwikkel, en Flyway Integreer maklik in bestaande CI. Maar ons maak dit gerieflik vir ontwikkelaars :)
Oprolprosedure
Puppet sien dat 'n verandering in pakketweergawe kom, insluitend die een wat vir migrasie verantwoordelik is. Eerstens installeer dit 'n pakket wat migrasieskrifte en databasisverwante funksionaliteit bevat. Hierna word die toepassing wat met die databasis werk, herbegin. Volgende kom die installering van die oorblywende komponente. Die volgorde waarin pakkette geïnstalleer en toepassings geloods word, word in die Puppet-manifes beskryf.
Toepassings gebruik sensitiewe data, soos tekens, databasiswagwoorde, dit alles word in die konfigurasie van Puppet master ingetrek, waar dit in geënkripteerde vorm gestoor word.
TFS probleme
Nadat ons besluit en besef het dat alles regtig vir ons werk, het ek besluit om te kyk wat aangaan met die samestellings in TFS as geheel vir die Win-ontwikkelingsafdeling op ander projekte - of ons nou vinnig bou/vrylaat of nie, en beduidende probleme met spoed ontdek het.
Een van die hoofprojekte neem 12-15 minute om te monteer - dit is 'n lang tyd, jy kan nie so lewe nie. 'n Vinnige ontleding het 'n verskriklike afname in I/O getoon, en dit was op skikkings.
Nadat ek dit komponent vir komponent ontleed het, het ek drie brandpunte geïdentifiseer. Eerstens - "Kaspersky antivirus", wat bronne op alle Windows Build-agente skandeer. Tweede - Windows Indekseerder. Dit was nie gedeaktiveer nie, en alles is intyds op die Build-agente geïndekseer tydens die ontplooiingsproses.
Derde - Npm installeer. Dit het geblyk dat ons in die meeste Pyplyne hierdie presiese scenario gebruik het. Hoekom is hy sleg? Die Npm-installasieprosedure word uitgevoer wanneer die afhanklikheidsboom in gevorm word pakket-lock.json, waar die weergawes van pakkette wat gebruik sal word om die projek te bou, aangeteken word. Die nadeel is dat Npm-installasie elke keer die nuutste weergawes van pakkette van die internet af haal, en dit neem baie tyd in die geval van 'n groot projek.
Ontwikkelaars eksperimenteer soms op 'n plaaslike masjien om te toets hoe 'n spesifieke deel of hele projek werk. Soms het dit geblyk dat alles plaaslik cool was, maar hulle het dit aanmekaar gesit, uitgerol, en niks het gewerk nie. Ons begin uitvind wat die probleem is - ja, verskillende weergawes van pakkette met afhanklikhede.
besluit
- Bronne in AV-uitsonderings.
- Deaktiveer indeksering.
- Gaan na npm ci.
Die voordele van npm ci is dat ons Ons versamel die afhanklikheidsboom een keer, en ons kry die geleentheid om die ontwikkelaar te voorsien huidige lys van pakkette, waarmee hy plaaslik kan eksperimenteer soveel hy wil. Hierdie tyd bespaar ontwikkelaars wat kode skryf.
opset
Nou 'n bietjie oor die bewaarplekkonfigurasie. Histories gebruik ons Nexus vir die bestuur van bewaarplekke, insluitend Interne REPO. Hierdie interne bewaarplek bevat al die komponente wat ons vir interne doeleindes gebruik, byvoorbeeld selfgeskrewe monitering.
Ons gebruik ook NuGet, aangesien dit beter caching het in vergelyking met ander pakketbestuurders.
Gevolg
Nadat ons die Bou-agente geoptimaliseer het, is die gemiddelde boutyd van 12 minute tot 7 verminder.
As ons al die masjiene tel wat ons vir Windows kon gebruik het, maar in hierdie projek na Linux oorgeskakel het, het ons sowat $10 000 bespaar.En dit is net op lisensies, en meer as ons die inhoud in ag neem.
Planne
Vir die volgende kwartaal het ons beplan om te werk aan die optimalisering van kode-aflewering.
Skakel oor na 'n voorafgeboude Docker-beeld. TFS is 'n oulike ding met baie inproppe wat jou in staat stel om in Pipeline te integreer, insluitend sneller-gebaseerde samestelling van, sê, 'n Docker-beeld. Ons wil hierdie sneller vir dieselfde een maak pakket-lock.json. As die samestelling van die komponente wat gebruik word om die projek te bou op een of ander manier verander, bou ons 'n nuwe Docker-beeld. Dit word later gebruik om die houer met die saamgestelde toepassing te ontplooi. Dit is nie nou die geval nie, maar ons beplan om oor te skakel na 'n mikrodiensargitektuur in Kubernetes, wat aktief in ons maatskappy ontwikkel en al lank produksie-oplossings bedien.
Opsomming
Ek moedig almal aan om Windows weg te gooi, maar dit is nie omdat ek nie weet hoe om dit gaar te maak nie. Die rede is dat die meeste Opensource-oplossings is Linux stapel. is jy OK bespaar op hulpbronne. Na my mening behoort die toekoms aan Open Source oplossings op Linux met 'n kragtige gemeenskap.
Sprekerprofiel van Alexander Sinchinov .
is 'n konferensie oor die integrasie van ontwikkelings-, toets- en bedryfsprosesse vir professionele persone deur professionele persone. Dis hoekom die projek waaroor Alexander gepraat het? geïmplementeer en werk, en op die dag van die uitvoering was daar twee suksesvolle vrystellings. Aan Op 27 en 28 Mei sal daar selfs meer soortgelyke gevalle van praktisyns wees. Jy kan nog in die laaste koets spring en of neem jou tyd kaartjie. Ontmoet ons in Skolkovo!
Bron: will.com