Wy hawwe DevOps sa goed mooglik ûntwikkele. D'r wiene 8 fan ús, en Vasya wie de coolste yn Windows. Ynienen gie Vasya fuort, en ik hie de taak om in nij projekt te lansearjen dat waard levere troch Windows-ûntwikkeling. Doe't ik de heule Windows-ûntwikkelingsstapel op 'e tafel dumpte, realisearre ik dat de situaasje in pine wie ...
Dit is hoe't it ferhaal begjint Alexandra Sinchinova op . Doe't de liedende Windows-spesjalist it bedriuw ferliet, frege Alexander him ôf wat no te dwaan. Wikselje nei Linux, fansels! Alexander sil jo fertelle hoe't hy it slagge om in presedint te meitsjen en in diel fan Windows-ûntwikkeling oer te bringen nei Linux mei it foarbyld fan in foltôge projekt foar 100 ein brûkers.
Hoe kinne jo in projekt maklik en sûnder muoite leverje oan RPM mei TFS, Puppet, Linux .NET-kearn? Hoe kinne jo ferzjeferzje fan in projektdatabase stypje as it ûntwikkelteam de wurden Postgres en Flyway foar it earst heart, en de deadline is oermorgen? Hoe yntegrearje mei Docker? Hoe .NET-ûntwikkelders te motivearjen om Windows en smoothies te ferlitten yn it foardiel fan Puppet en Linux? Hoe kinne ideologyske konflikten oplosse as d'r noch de krêft, noch de winsk, noch de middels is om Windows yn produksje te hâlden? Oer dit, lykas oer Web Deploy, testen, CI, oer de praktiken fan it brûken fan TFS yn besteande projekten, en, fansels, oer brutsen krukken en wurkoplossingen, yn 'e transkripsje fan Alexander's rapport.
Dus, Vasya ferliet, de taak is op my, de ûntwikkelders wachtsje ûngeduldich mei pitchforks. Doe't ik einliks realisearre dat Vasya net weromjûn wurde koe, kaam ik oan it wurk. Om te begjinnen haw ik it persintaazje Win VM's yn ús float beoardiele. De skoare wie net yn it foardiel fan Windows.
Sûnt wy aktyf ûntwikkelje DevOps, realisearre ik dat der wat feroare wurde moat yn 'e oanpak fan it leverjen fan in nije applikaasje. D'r wie mar ien oplossing - as it mooglik is, oerdrage alles nei Linux. Google holp my - op dat stuit wie .Net al porteare nei Linux, en ik realisearre dat dit de oplossing wie!
Wêrom .NET kearn yn gearhing mei Linux?
Dêr wiene ferskate redenen foar. Tusken "jild betelje" en "net betelje", sil de mearderheid de twadde kieze - lykas ik. In lisinsje foar MSDB kostet sawat $ 1; it ûnderhâlden fan in float fan Windows firtuele masines kostet hûnderten dollars. Foar in grut bedriuw is dit in grutte útjefte. Dêrom sparen - earste reden. Net de wichtichste, mar ien fan de wichtige.
Windows firtuele masines nimme mear boarnen yn as har Linux-bruorren - se binne swier. Sjoen de skaal fan it grutte bedriuw, hawwe wy keazen foar Linux.
It systeem is gewoan yntegrearre yn besteande CI. Wy beskôgje ússels as progressive DevOps, wy brûke Bamboo, Jenkins en GitLab CI, dus it measte fan ús wurk rint op Linux.
De lêste reden is handige begelieding. Wy moasten de barriêre foar yngong ferleegje foar "escorts" - de jonges dy't it technyske diel begripe, soargje foar ûnûnderbrutsen tsjinst en ûnderhâlde tsjinsten fan 'e twadde line. Se wiene al bekend mei de Linux-stapel, dus it is folle makliker foar har om in nij produkt te begripen, te stypjen en te ûnderhâlden dan ekstra boarnen te besteegjen om deselde funksjonaliteit fan software foar it Windows-platfoarm te begripen.
easken
Earst en foaral - gemak fan de nije oplossing foar ûntwikkelders. Net allegear wiene klear foar feroaring, foaral nei't it wurd Linux sprutsen waard. Untwikkelders wolle har favorite Visual Studio, TFS mei autotests foar assemblies en smoothies. Hoe't levering oan produksje bart, is foar har net wichtich. Dêrom besleaten wy it gewoane proses net te feroarjen en alles net te feroarjen foar Windows-ûntwikkeling.
Nij projekt nedich yntegrearje yn besteande CI. De rails wiene der al en al it wurk moast dien wurde mei rekkening mei de parameters fan it konfiguraasjebehearsysteem, akseptearre leveringsnormen en kontrôlesystemen.
Gemak fan stipe en operaasje, as betingst foar de minimale yntreedrompel foar alle nije dielnimmers út ferskate divyzjes en de stipe-ôfdieling.
Deadline - juster.
Win Development Group
Wêr wurke it Windows-team doe mei?
No kin ik dat mei fertrouwen sizze IdentityServer 4 is in koel fergees alternatyf foar ADFS mei ferlykbere mooglikheden, of wat Entity Framework Core - in paradys foar in ûntwikkelder, wêr't jo gjin muoite hawwe om SQL-skripts te skriuwen, mar fragen yn 'e databank beskriuwe yn OOP-termen. Mar doe, tidens de diskusje fan it aksjeplan, seach ik nei dizze stapel as wie it Sumearysk spykerskrift, erkende allinich PostgreSQL en Git.
Op dat stuit brûkten wy aktyf Poppe as in konfiguraasjebehearsysteem. Yn de measte fan ús projekten brûkten wy GitLab CI, elastysk, balansearre hege-load tsjinsten mei help HAProxy kontrolearre alles mei Zabbix, ligaminten grafana и Prometheus, Jager, en dit alles draaide op stikken izer HP c ESXi op Omrop. Elkenien wit it - in klassiker fan it sjenre.
Litte wy sjen en besykje te begripen wat der barde foardat wy al dizze yntervinsjes begûnen.
Wat is der bart
TFS is in frij krêftich systeem dat net allinich koade leveret fan 'e ûntwikkelder nei de definitive produksjemasine, mar hat ek in set foar heul fleksibele yntegraasje mei ferskate tsjinsten - om CI op in cross-platform nivo te leverjen.
Earder wiene dat fêste ruten. TFS brûkte ferskate Build-aginten, dy't waarden brûkt om in protte projekten te sammeljen. Elke agint hat 3-4 arbeiders om taken te parallelisearjen en it proses te optimalisearjen. Doe levere TFS, neffens releaseplannen, de nij bakte Build nei de Windows-applikaasjetsjinner.
Wat woene wy berikke?
Wy brûke TFS foar levering en ûntwikkeling, en rinne de applikaasje op in Linux Application tsjinner, en der is wat soarte fan magy tusken harren. Dit Magic Box en d'r is it sâlt fan it wurk foarút. Foardat ik it útinoar helje, doch ik in stapke oan de kant en sis ik in pear wurden oer de applikaasje.
It projekt
De applikaasje biedt funksjonaliteit foar it behanneljen fan prepaidkaarten.
Kliïnt
D'r wiene twa soarten brûkers. De earste tagong krigen troch oan te melden mei in SSL SHA-2-sertifikaat. U fan 'e twadde der wie tagong mei in oanmelding en wachtwurd.
HAProxy
Doe gie it klantfersyk nei HAProxy, dy't de folgjende problemen oploste:
- primêre autorisaasje;
- SSL-beëiniging;
- tuning HTTP-fersiken;
- útstjoering fersiken.
It klantsertifikaat waard ferifiearre lâns de ketting. wy - autoriteit en wy kinne dit betelje, om't wy sels sertifikaten útjaan oan tsjinstkliïnten.
Jou omtinken oan it tredde punt, wy komme der in bytsje letter op werom.
backend
Se planden om de backend op Linux te meitsjen. De backend ynteraksje mei de databank, laadt de nedige list fan privileezjes en dan, ôfhinklik fan hokker privileezjes de autorisearre brûker hat, jout tagong ta ûndertekenjen fan finansjele dokuminten en stjoer se foar útfiering, of generearje in soarte fan rapport.
Besparring mei HAProxy
Neist de twa konteksten dy't elke klant navigearre, wie d'r ek in identiteitskontekst. IdentityServer 4 lit jo gewoan ynlogge, dit is in fergese en krêftige analoog foar ADFS - Tsjinsten fan Active Directory Federaasje.
It identiteitsfersyk waard yn ferskate stappen ferwurke. Earste stap - klant kaam yn 'e efterkant, dy't kommunisearre mei dizze tsjinner en kontrolearre de oanwêzigens fan in token foar de kliïnt. As it net fûn waard, waard it fersyk weromjûn nei de kontekst dêr't it út kaam, mar mei in trochferwizing, en mei de trochferwizing gie it nei identiteit.
Twadde stap - it fersyk waard ûntfongen nei de autorisaasjeside yn IdentityServer, wêr't de klant registrearre, en dat langferwachte token ferskynde yn 'e IdentityServer-database.
Tredde stap - de klant waard omlaat werom nei de kontekst dêr't it út kaam.
IdentityServer4 hat in funksje: it jout it antwurd op it weromfersyk fia HTTP. Gjin saak hoefolle wy muoite mei it opsetten fan de tsjinner, gjin saak hoefolle wy ferljochte ússels mei de dokumintaasje, eltse kear wy krigen in earste klant fersyk mei in URL dy't kaam fia HTTPS, en IdentityServer werom deselde kontekst, mar mei HTTP. Wy wiene skrokken! En wy hawwe dit alles troch de identiteitskontekst oerbrocht nei HAProxy, en yn 'e kopteksten moasten wy it HTTP-protokol wizigje nei HTTPS.
Wat is de ferbettering en wêr hawwe jo bewarre?
Wy hawwe jild besparre troch in fergese oplossing te brûken foar it autorisearjen fan in groep brûkers, boarnen, om't wy IdentityServer4 net as in apart knooppunt yn in apart segmint pleatsten, mar it tegearre mei de backend op deselde tsjinner brûkten wêr't de efterkant fan 'e applikaasje rint .
Hoe moat it wurkje
Dus, lykas ik tasein - Magic Box. Wy begripe al dat wy garandearre binne om nei Linux te gean. Litte wy spesifike taken formulearje dy't oplossings nedich hawwe.
Puppet manifestearret. Om tsjinst- en applikaasjekonfiguraasje te leverjen en te behearjen, moasten koele resepten skreaun wurde. In potleadrol lit wolsprekend sjen hoe fluch en effisjint it dien is.
Levering metoade. De standert is RPM. Elkenien begrypt dat jo yn Linux net sûnder kinne dwaan, mar it projekt sels, nei gearstalling, wie in set fan útfierbere DLL-bestannen. Der wiene sa'n 150, it projekt wie frij lestich. De ienige harmonieuze oplossing is dit binêr yn te pakken yn RPM en de applikaasje dêrút yn te setten.
Ferzjefoarming. Wy moasten heul faak loslitte, en wy moasten beslute hoe't wy de pakketnamme foarmje. Dit is in fraach fan it nivo fan yntegraasje mei TFS. Wy hiene in build-agent op Linux. As TFS in taak stjoert nei in handler - arbeider - nei de Build-agint, jout it ek in boskje fariabelen troch dy't einigje yn 'e omjouwing fan it handlerproses. Dizze omjouwingsfariabelen befetsje de Build-namme, ferzjenamme en oare fariabelen. Lês mear oer dit yn 'e seksje "In RPM-pakket bouwe".
TFS ynstelle kaam del op it opsetten fan Pipeline. Earder sammele wy alle Windows-projekten op Windows-aginten, mar no ferskynt in Linux-agint - in Build-agint, dy't moat wurde opnommen yn 'e build-groep, ferrike mei guon artefakten, en ferteld hokker type projekten sille wurde boud op dizze Build-agint , en op ien of oare manier de Pipeline feroarje.
IdentityServer. ADFS is net ús manier, wy geane foar Open Source.
Lit ús gean troch de komponinten.
Magic Box
Bestiet út fjouwer dielen.
Linux Build agent. Linux, om't wy der foar bouwe - it is logysk. Dit diel waard dien yn trije stappen.
- Konfigurearje arbeiders en net allinnich, sûnt ferspraat wurk oan it projekt waard ferwachte.
- Ynstallearje .NET Core 1.x. Wêrom 1.x as 2.0 al beskikber is yn it standert repository? Want doe't wy begûn ûntwikkeling, de stabile ferzje wie 1.09, en it waard besletten om te meitsjen it projekt basearre op it.
- Git 2.x.
RPM-repository. RPM-pakketten moasten earne opslein wurde. It waard oannommen dat wy itselde bedriuwsrpm-repository soene brûke dat beskikber is foar alle Linux-hosts. Dat diene se. De repository-tsjinner is konfigureare web heak dy't it fereaske RPM-pakket downloade fan 'e opjûne lokaasje. De pakketferzje waard rapportearre oan de webhook troch de Build-agent.
GitLab. Oandacht! GitLab wurdt hjir net brûkt troch ûntwikkelders, mar troch de operaasjeôfdieling om applikaasjeferzjes, pakketferzjes te kontrolearjen, de status fan alle Linux-masines te kontrolearjen, en it bewarret it resept - alle Puppet-manifest.
Poppe - lost alle kontroversjele problemen op en leveret krekt de konfiguraasje dy't wy wolle fan Gitlab.
Wy begjinne te dûken. Hoe wurket DLL-levering nei RPM?
Levering DDL to RPM
Litte wy sizze dat wy in .NET-ûntwikkelingsrockstjer hawwe. It brûkt Visual Studio en makket in release branch. Dêrnei uploadt it it nei Git, en Git hjir is in TFS-entiteit, dat wol sizze, it is de applikaasje-repository wêrmei de ûntwikkelder wurket.
Dêrnei sjocht TFS dat der in nije commit oankaam is. Hokker app? Yn 'e TFS-ynstellingen is d'r in label dat oanjout hokker boarnen in bepaalde Build-agent hat. Yn dit gefal sjocht hy dat wy in .NET Core-projekt bouwe en selektearje in Linux Build-agint út it swimbad.
De Build-agint ûntfangt de boarnen en downloadt de nedige ôfhinklikens fan it .NET repository, npm, ensfh. en nei it bouwen fan de applikaasje sels en de folgjende ferpakking, stjoert it RPM-pakket nei it RPM-repository.
Oan 'e oare kant bart it folgjende. De yngenieur fan 'e operaasje ôfdieling is direkt belutsen by de útrol fan it projekt: hy feroaret de ferzjes fan pakketten yn Hiera yn de repository dêr't de applikaasje resept wurdt opslein, wêrnei't Puppet triggers yum, hellet it nije pakket út it repository, en de nije ferzje fan 'e applikaasje is klear om te brûken.
Alles is ienfâldich yn wurden, mar wat bart der binnen de Build-agint sels?
Ferpakking DLL RPM
Ûntfong projekt boarnen en bouwe taak fan TFS. Bouwe agent begjint it projekt sels út boarnen te bouwen. It gearstalde projekt is beskikber as in set DLL triemmen, dy't yn in zip-argyf binne ferpakt om de lading op it bestânsysteem te ferminderjen.
It ZIP-argyf wurdt fuortsmiten nei de RPM-pakket build map. Dêrnei initialisearret it Bash-skript de omjouwingsfariabelen, fynt de Build-ferzje, de projektferzje, it paad nei de build-map, en rint RPM-build. As de bou foltôge is, wurdt it pakket publisearre nei lokale repository, dat leit op de Build-agint.
Folgjende, fan 'e Build-agent nei de tsjinner yn' e RPM-repository JSON-fersyk wurdt ferstjoerd oanjout de namme fan de ferzje en build. Webhook, dêr't ik earder oer praat, downloadt dit heul pakket fan it lokale repository op 'e Build-agent en makket de nije gearkomste beskikber foar ynstallaasje.
Wêrom dit bepaalde pakketferlieningskema nei it RPM-repository? Wêrom kin ik it gearstalde pakket net direkt nei de repository stjoere? It feit is dat dit in betingst is foar it garandearjen fan feiligens. Dit senario beheint de mooglikheid fan net autorisearre minsken dy't RPM-pakketten uploade nei in server dy't tagonklik is foar alle Linux-masines.
Database ferzje
By in oerlis mei it ûntwikkelteam die bliken dat de jonges tichter by MS SQL stiene, mar yn de measte net-Windows-projekten brûkten wy PostgreSQL al mei alle macht. Om't wy al besletten hiene om alles betelle te ferlitten, begûnen wy hjir ek PostgreSQL te brûken.
Yn dit diel wol ik jo fertelle hoe't wy de databank ferzje hawwe en hoe't wy hawwe keazen tusken Flyway en Entity Framework Core. Litte wy nei har foar- en neidielen sjen.
Минусы
Flyway giet mar ien kant, wy wy kinne net rôlje werom - dit is in signifikant neidiel. Jo kinne it op oare manieren fergelykje mei Entity Framework Core - yn termen fan ûntwikkeldersgemak. Jo ûnthâlde dat wy dit op 'e foargrûn sette, en it wichtichste kritearium wie neat te feroarjen foar Windows-ûntwikkeling.
Foar Flyway us in soarte fan wrapper wie nedichsadat de jonges net skriuwe SQL-fragen. Se binne folle tichter by it operearjen yn OOP-termen. Wy hawwe ynstruksjes skreaun foar it wurkjen mei databankobjekten, in SQL-query generearre en it útfierd. De nije ferzje fan 'e databank is klear, hifke - alles is goed, alles wurket.
Entity Framework Core hat in minus - ûnder swiere loads it bout suboptimale SQL-fragen, en de drawdown yn 'e databank kin signifikant wêze. Mar om't wy gjin tsjinst mei hege lading hawwe, berekkenje wy de lading net yn hûnderten RPS, wy hawwe dizze risiko's akseptearre en it probleem delegearre oan ús takomst.
Плюсы
Entity Framework Core wurket út 'e doaze en is maklik te ûntwikkeljen, en Flyway Maklik yntegreart yn besteande CI. Mar wy meitsje it handich foar ûntwikkelders :)
Roll-up proseduere
Puppet sjocht dat der in feroaring yn pakketferzje komt, ynklusyf dejinge dy't ferantwurdlik is foar migraasje. Earst ynstalleart it in pakket dat migraasjeskripts en database-relatearre funksjonaliteit befettet. Hjirnei wurdt de applikaasje dy't wurket mei de databank opnij starte. Dêrnei komt de ynstallaasje fan 'e oerbleaune komponinten. De folchoarder wêryn pakketten wurde ynstalleare en applikaasjes wurde lansearre wurdt beskreaun yn it Puppet-manifest.
Applikaasjes brûke gefoelige gegevens, lykas tokens, database wachtwurden, dit alles wurdt lutsen yn 'e konfiguraasje fan Puppet master, wêr't se wurde opslein yn fersifere foarm.
TFS problemen
Nei't wy besletten hawwe en realisearre dat alles echt foar ús wurke, besleat ik om te sjen nei wat der bart mei de gearkomsten yn TFS as gehiel foar de Win-ûntwikkelingsôfdieling op oare projekten - oft wy gau bouwe / loslitte of net, en ûntduts wichtige problemen mei snelheid.
Ien fan 'e wichtichste projekten nimt 12-15 minuten om te sammeljen - dat is in lange tiid, jo kinne net sa libje. In flugge analyse toande in skriklike drawdown yn I / O, en dit wie op arrays.
Nei it analysearjen fan it komponint foar komponint, identifisearre ik trije foci. Earste - "Kaspersky antivirus", dy't boarnen scant op alle Windows Build-aginten. Twadde - Windows Indexer. It wie net útskeakele, en alles waard yn realtime yndeksearre op de Build-aginten tidens it ynsetproses.
Tredde - Npm ynstallearje. It die bliken dat wy yn de measte Pipelines dit krekte senario brûkten. Wêrom is er min? De Npm-ynstallaasjeproseduere wurdt útfierd as de ôfhinklikensbeam wurdt foarme yn package-lock.json, wêr't de ferzjes fan pakketten dy't brûkt wurde om it projekt te bouwen wurde opnommen. It neidiel is dat Npm-ynstallaasje elke kear de lêste ferzjes fan pakketten fan it ynternet oplûkt, en dit nimt in protte tiid yn it gefal fan in grut projekt.
Untwikkelders eksperimintearje soms op in lokale masine om te testen hoe't in bepaald diel of in heule projekt wurket. Soms die bliken dat alles wie cool lokaal, mar se gearstald it, rôle it út, en neat wurke. Wy begjinne út te finen wat it probleem is - ja, ferskate ferzjes fan pakketten mei ôfhinklikens.
beslút
- Boarnen yn AV útsûnderings.
- Yndeksearring útskeakelje.
- Gean nei npm ci.
De foardielen fan npm ci binne dat wy Wy sammelje de ôfhinklikensbeam ien kear, en wy krije de kâns om te foarsjen de ûntwikkelder aktuele list fan pakketten, dêr't er lokaal safolle mei eksperimintearje kin as er wol. Dit besparret tiid ûntwikkelers dy't skriuwe koade.
Konfiguraasje
No in bytsje oer de konfiguraasje fan 'e repository. Histoarysk brûke wy nexus foar it behearen fan repositories, ynklusyf Ynterne REPO. Dit ynterne repository befettet alle komponinten dy't wy brûke foar ynterne doelen, bygelyks selsskreaune tafersjoch.
Wy brûke ek NuGet, om't it bettere caching hat yn ferliking mei oare pakketbehearders.
resultaat
Neidat wy de Build Agents optimalisearre hawwe, waard de gemiddelde boutiid fermindere fan 12 minuten nei 7.
As wy telle alle masines dy't wy koenen hawwe brûkt foar Windows, mar oerstapt nei Linux yn dit projekt, wy besparre sa'n $ 10 000. En dat is gewoan op lisinsjes, en mear as wy rekken hâlde mei de ynhâld.
Plannen
Foar it folgjende kwartaal planden wy te wurkjen oan it optimalisearjen fan koadelevering.
Oerskeakelje nei in prebuild Docker-ôfbylding. TFS is in cool ding mei in protte plugins dy't jo kinne yntegrearje yn Pipeline, ynklusyf trigger-basearre gearstalling fan bygelyks in Docker-ôfbylding. Wy wolle dizze trigger meitsje foar deselde package-lock.json. As de gearstalling fan 'e komponinten dy't brûkt wurde om it projekt op ien of oare manier te bouwen feroaret, bouwe wy in nije Docker-ôfbylding. It wurdt letter brûkt om de kontener yn te setten mei de gearstalde applikaasje. Dit is no net it gefal, mar wy binne fan plan om te wikseljen nei in mikroservice-arsjitektuer yn Kubernetes, dy't aktyf ûntwikkelet yn ús bedriuw en hat produksjeoplossingen foar in lange tiid tsjinne.
Gearfetting
Ik moedigje elkenien oan om Windows fuort te smiten, mar it is net om't ik net wit hoe't ik it koekje. De reden is dat de measte Opensource-oplossingen binne Linux stack. giet it goed mei dy besparje op middels. Yn myn miening heart de takomst ta Open Source-oplossingen op Linux mei in krêftige mienskip.
Sprekker profyl fan Alexander Sinchinov .
is in konferinsje oer de yntegraasje fan ûntwikkeling, testen en operaasje prosessen foar professionals troch professionals. Dat is wêrom it projekt dat Alexander it oer? ymplemintearre en wurkjen, en op 'e dei fan' e foarstelling wiene d'r twa suksesfolle releases. Op Op 27 en 28 maaie komme der noch mear ferlykbere gefallen fan beoefeners. Jo kinne noch springe yn de lêste koets en of nim dyn tiid kaartsje. Moetsje ús yn Skolkovo!
Boarne: www.habr.com