Vi utvecklade DevOps sÄ gott vi kunde. Vi var Ätta personer, och Vasja var den mest kompetenta nÀr det kom till Windows. Plötsligt lÀmnade Vasja, och jag fick i uppdrag att driva ett nytt projekt som levererar Windows-utveckling. NÀr jag la ut hela Windows-utvecklingsstacken pÄ bordet insÄg jag att situationen var problematisk...
SÄ hÀr börjar historien Alexandra Sinchinova till . NÀr den ledande Windows-specialisten lÀmnade företaget stÀllde Alexandra sig frÄgan vad hon skulle göra nu. SjÀlvklart skulle hon byta till Linux! Alexandra kommer att berÀtta hur hon lyckades skapa ett prejudikat och flytta en del av Windows-utvecklingen till Linux med exemplet av ett genomfört projekt med 100 000 slutanvÀndare.
Hur kan man enkelt och smidigt leverera ett projekt i RPM med TFS, Puppet och Linux .NET core? Hur upprÀtthÄller man versionering av projektets databas om utvecklarna hör för första gÄngen ord som Postgres och Flyway, och deadline Àr om tvÄ dagar? Hur integrerar man med Docker? Hur motiverar man .NET-utvecklare att avstÄ frÄn Windows och smoothies till förmÄn för Puppet och Linux? Hur löser man ideologiska konflikter nÀr man inte har varken kraft, vilja eller resurser att stödja Windows i produktion? Om detta, liksom Web Deploy, testning, CI, praktiker för att anvÀnda TFS i befintliga projekt och sjÀlvklart om brutna kryckor och fungerande lösningar, i Alexandra's presentation.
SÄ, Vasja hade lÀmnat, uppgiften lÄg pÄ mig, utvecklarna vÀntade otÄligt med gafflar. NÀr jag till slut insÄg att jag inte kunde fÄ tillbaka Vasja, satte jag igÄng med arbetet. Först bedömde jag andelen Win VM i vÄr park. Resultatet var inte till Windows fördel.
Eftersom vi aktivt utvecklar DevOps insĂ„g jag att nĂ„got mĂ„ste förĂ€ndras i tillvĂ€gagĂ„ngssĂ€ttet för att flytta det nya programmet. Lösningen var att sĂ„ mycket som möjligt överföra allt till Linux. Google hjĂ€lpte mig â vid den tidpunkten fanns redan .Net porterat till Linux, och jag insĂ„g att det var lösningen!
Varför .NET core i kombination med Linux?
Det fanns flera anledningar. Mellan "att betala pengar" och "inte betala" vĂ€ljer de flesta det andra â precis som jag. Licensen för MSDB kostar cirka 1 000 $, och underhĂ„llet av mĂ€ngden Windows virtuella maskiner kostar hundratals dollar. För ett stort företag Ă€r det stora utgifter. SĂ„ dĂ€rför besparing â Ă€r den första anledningen. Det Ă€r inte den viktigaste, men en av de betydande.
Windows virtuell maskiner krĂ€ver mer resurser Ă€n deras Linux-syskon â de Ă€r tunga. Med tanke pĂ„ storleken pĂ„ ett stort företag valde vi Linux.
Systemet integreras enkelt i den befintliga CI. Vi ser oss sjÀlva som progressiva DevOps:are, anvÀnder Bamboo, Jenkins och GitLab CI, sÄ dÀrför körs det mesta av oss pÄ Linux.
Den sista anledningen Àr bekvÀm support. Vi behövde sÀnka tröskeln för "supportarna" - de som förstÄr den tekniska delen, sÀkerstÀller drift och underhÄller tjÀnster med andra linjen. De var redan bekanta med Linux-stacken, sÄ det var mycket lÀttare för dem att förstÄ den nya produkten, stödja och underhÄlla den, Àn att spendera extra resurser pÄ att förstÄ motsvarande funktionalitet av en programvara för Windows-plattformen.
Krav
Första och frÀmsta Àr bekvÀmligheten med den nya lösningen för utvecklarna. Inte alla av dem var redo för förÀndringar, sÀrskilt efter att ha hört ordet Linux. Utvecklare vill ha sin Àlskade Visual Studio, TFS med automatiserade tester för byggen och smoothies. Hur leveransen gÄr till produktion bryr de sig inte om. DÀrför beslutade vi att inte Àndra den vanliga processen och behÄlla allt oförÀndrat för Windows-utvecklingen.
Nytt projekt mÄste integreras i den befintliga CI. Rails fanns redan och allt arbete mÄste genomföras med hÀnsyn till konfigurationshanteringssystemets parametrar, antagna leveransstandarder och övervakningssystem.
Enkelhet i support och drift, som ett villkor för en minimal ingÄngströskel för alla nya deltagare frÄn olika avdelningar och supportavdelningen.
Deadline â igĂ„r.
Windows-utvecklingsgruppen
Vad arbetade dÄ Windows-teamet med?
Nu kan jag sĂ€kert sĂ€ga att IdentityServer4 â det Ă€r ett fantastiskt gratis alternativ till ADFS med liknande möjligheter, eller att Entity Framework Core â Ă€r en dröm för utvecklare, dĂ€r man kan slippa skriva SQL-skript och istĂ€llet beskriva frĂ„gor i databasen i termer av OOP. Men dĂ„, under diskussionen om handlingsplanen, sĂ„g jag pĂ„ den hĂ€r stacken som pĂ„ sumerisk kilskrift och kĂ€nde bara igen PostgreSQL och Git.
Vid den tiden anvĂ€nde vi aktivt Puppet som konfigurationshanteringssystem. I de flesta av vĂ„ra projekt anvĂ€nde vi GitLab CI, Elastic, balanserade högbelastade tjĂ€nster med hjĂ€lp av HAProxy, höll koll pĂ„ allt med hjĂ€lp av Zabbix, kombinationen Grafana och Prometheus, Jaeger, och allt detta kördes pĂ„ maskiner HP c ESXi till VMware. Vem kĂ€nner inte till â klassikern.
LÄt oss titta pÄ och försöka förstÄ vad som hÀnde innan vi pÄbörjade alla dessa ingrepp.
Vad hÀnde
TFS Àr ett ganska kraftfullt system som inte bara levererar kod frÄn utvecklaren till den slutliga produktionsmaskinen, utan Àven har en uppsÀttning för mycket flexibel integration med olika tjÀnster för att sÀkerstÀlla CI pÄ plattformsövergripande nivÄ.
Tidigare var det bara fönster. TFS anvÀnde flera byggagenter dÀr mÄnga projekt samlades. I varje agent fanns det 3-4 arbetare för att parallellisera uppgifter och optimera processen. DÀrefter, enligt releaseplanerna, levererade TFS den nybakade bygget till Windows-applikationsservern.
Vad ville vi uppnÄ
För leverans och utveckling anvÀnder vi TFS, och vi kör applikationen pÄ Linux-applikationsserver, och mellan dem finns nÄgon slags magi. Den Magic Box Àr sjÀlva kÀrnan i det kommande arbetet. Innan vi gÄr in i detaljerna, lÄt mig ta ett steg Ät sidan och sÀga nÄgra ord om applikationen.
Projektet
Applikationen tillhandahÄller funktionalitet för att hantera förbetalda kort.
Client
Det fanns tvÄ typer av anvÀndare. Första fick tillgÄng genom att autentisera med ett SSL-certifikat SHA-2. Han den andra hade tillgÄng med inloggning och lösenord.
HAProxy
Sedan skickades klientens begÀran till HAProxy, som löste följande uppgifter:
- primÀr autentisering;
- terminering av SSL;
- justering av HTTP-begÀrningar;
- översÀttning av begÀrningar.
Kontroll av klientens certifikat skedde genom en kedja. Vi Àr authority och vi kan tillÄta oss detta, eftersom vi sjÀlva utfÀrdar certifikat till tjÀnsteanvÀndarna.
Var uppmÀrksam pÄ den tredje punkten, vi Äterkommer till den senare.
Backend
Backend var planerat att göras pÄ Linux. Backend interagerar med databasen, laddar den nödvÀndiga listan med behörigheter och sedan, beroende pÄ vilka behörigheter den autentiserade anvÀndaren har, erbjuder tillgÄng för att signera finansiella dokument och skicka dem till utförande, eller för att generera nÄgon form av rapport.
Besparingar med HAProxy
Förutom de tvĂ„ kontexter som varje klient passerade genom, fanns det ocksĂ„ en kontext för identitet. IdentityServer4 som just möjliggör autentisering, detta Ă€r ett gratis och starkt alternativ till ADFS â Active Directory Federation Services.
BegÀran i identiteten bearbetades i flera steg. Första steget - klient hamnade i backend, som utbytte data med denna server och kontrollerade förekomsten av en token för kunden. Om den inte hittades - förfrÄgan skickades tillbaka till den kontext frÄn vilken den kom, men redan med en omdirigering, och med omdirigeringen gick till identity.
Andra steget - förfrÄgan kom till inloggningssidan i IdentityServer, dÀr kunden registrerade sig, och i databasen för IdentityServer dök den efterlÀngtade token upp.
Tredje steget - kunden omdirigerades tillbaka till den kontext som han kom ifrÄn.
IdentityServer4 har en egenskap: svaret pÄ den omvÀnda förfrÄgan returneras via HTTP. Oavsett hur vi kÀmpade med serverinstÀllningen, oavsett hur mycket vi lÀste dokumentationen, sÄ fick vi varje gÄng den ursprungliga förfrÄgan frÄn kunden med en URL som kom via HTTPS, medan IdentityServer returnerade samma kontext, men med HTTP. Vi var i chock! Och vi översatte allt detta genom identity-kontexten pÄ HAProxy, och i headers mÄste vi modifiera protokollet frÄn HTTP till HTTPS.
Vad Àr förbÀttringen och var sparade vi?
Vi sparade pengar genom att anvÀnda en gratis lösning för autentisering av gruppanvÀndare, resurser, eftersom vi inte flyttade IdentityServer4 som en separat nod till ett separat segment, utan anvÀnde det tillsammans med backend pÄ samma server dÀr applikationens backend körs.
Hur det borde fungera
SÄ, som jag lovade - Magic Box. Vi förstÄr redan att vi garanterat rör oss mot Linux. LÄt oss formulera specifika uppgifter som krÀvde lösning.
Puppet-manifest. För att leverera och hantera konfigurationen av tjÀnsten och applikationen behövde vi skriva fantastiska recept. En rullande med en penna visar tydligt hur snabbt och kvalitativt detta gjordes.
Leveransmetod. Standarden Àr RPM. Alla förstÄr att utan den kan man inte hantera Linux, men sjÀlva projektet efter bygget bestod av ett antal körbara DLL-filer. Det var omkring 150, projektet Àr ganska tungt. Den enda harmoniska lösningen Àr att paketera denna binÀrfil i RPM och redan frÄn den distribuera applikationen.
Versionshantering. Vi skulle göra utgĂ„vor vĂ€ldigt ofta, och vi behövde bestĂ€mma hur vi skulle skapa paketnamnet. Detta Ă€r en frĂ„ga pĂ„ integrationsnivĂ„ med TFS. Byggagenten kördes pĂ„ Linux. NĂ€r TFS skickar en uppgift till behandlaren â worker â pĂ„ byggagenten, vidarebefordrar den ocksĂ„ en samling variabler som hamnar i processens miljö. I dessa miljövariabler skickas namn pĂ„ bygget, versionsnamn och andra variabler. Mer om detta i avsnittet "bygga RPM-paket".
TFS-instĂ€llning bestod av att konfigurera Pipeline. Tidigare samlade vi alla Windows-projekt pĂ„ Windows-agenter, men nu lĂ€ggs en Linux-agent â byggagenten â till i bygggruppen, vilket mĂ„ste berikas med vissa artefakter, sĂ€ga vilken typ av projekt som ska byggas pĂ„ denna byggagent och pĂ„ nĂ„got sĂ€tt modifiera Pipeline.
IdentityServer. ADFS Àr inte vÄr vÀg, vi satsar pÄ Open Source.
LÄt oss titta pÄ komponenterna.
Magic Box
Den bestÄr av fyra delar.
Linux byggagent. Linux, eftersom vi bygger för det â det Ă€r logiskt. Denna del utfördes i tre steg.
- Konfigurera workers och inte bara en, eftersom distribuerat arbete antogs för projektet.
- Installera .NET Core 1.x. Varför just 1.x, nÀr 2.0 redan Àr tillgÀnglig i standardrepositoryt? Eftersom nÀr vi började utvecklingen var den stabila versionen 1.09, och projektet beslutades att göras för den.
- Git 2.x.
RPM-repository. RPM-paketen behövde lagras nÄgonstans. Det antogs att vi skulle anvÀnda samma företags RPM-repository som Àr tillgÀngligt för alla Linux-vÀrdar. SÄ gjordes det. PÄ servern för repositoryt Àr det konfigurerat webhook som laddade ner det nödvÀndiga RPM-paketet frÄn den angivna platsen. Byggagent meddelade versionen av paketet till webhook.
GitLab. Observera! GitLab anvĂ€nds hĂ€r inte av utvecklarna, utan av driftavdelningen för versionskontroll av applikationen, versionskontroll av paketen, övervakning av alla Linux-maskinvaror och i den lagras receptet â alla Puppet-manifest.
Puppet â löser alla tvistiga frĂ„gor och levererar just den konfiguration vi vill ha, frĂ„n Gitlab.
Vi börjar dyka in. Hur sker leveransen av DLL till RPM?
Leveransen av DLL till RPM
Anta att vi har en rockstjÀrna inom utveckling pÄ .NET. Han anvÀnder Visual Studio och skapar en release-gren. Efter det laddar han upp den till Git, och Git hÀr Àr en TFS-entitet, det vill sÀga detta Àr applikationens repository som utvecklaren arbetar med.
Efter vilket TFS ser att en ny commit har kommit. Vilket program? I TFS-instÀllningarna finns en mÀrkning av vilka resurser varje Build-agent har. I det hÀr fallet ser den att vi bygger ett .NET Core-projekt och vÀljer en Linux Build-agent frÄn poolen.
Build-agenten hÀmtar kÀllkoden, laddar ner nödvÀndiga dependencies frÄn .NET-repositoriet, npm, etc. och efter byggandet av sjÀlva applikationen och den efterföljande paketeringen skickar den RPM-paketet till RPM-repositoriet.
à andra sidan hÀnder följande. Ingenjören pÄ driftsavdelningen hanterar direkt distributionen av projektet: Àndrar versionsnummer pÄ paketen i Hiera i förrÄdet dÀr receptet för applikationen förvaras, varefter Puppet triggar Yum, hÀmtar det nya paketet frÄn förrÄdet, och den nya versionen av applikationen Àr redo att anvÀndas.
Det lÄter enkelt, men vad hÀnder inuti sjÀlva Build-agenten?
Paketering av DLL RPM
KÀllkoden för projektet har mottagits och en bygguppgift frÄn TFS. Build-agenten startar byggandet av sjÀlva projektet frÄn kÀllkoden.Det byggda projektet Àr tillgÀngligt i form av ett antal DLL-filer, som paketeras i ett zip-arkiv för att minska belastningen pÄ filsystemet.
ZIP-arkivet lÀggs i katalogen för byggandet av RPM-paketet. DÀrefter initierar ett Bash-skript miljövariabler, hittar versionen av Build, versionen av projektet, sökvÀgen till byggkatalogen och startar RPM-build. NÀr byggandet Àr klart publiceras paketet i det lokala förrÄdet, som finns pÄ Build-agenten.
DÀrefter skickas en JSON-förfrÄgan frÄn Build-agenten till servern i RPM-repositoriet med angivande av versionsnamn och build. Webhooken som jag nÀmnde tidigare hÀmtar detta paket frÄn det lokala förrÄdet pÄ Build-agenten och gör den nya byggnaden tillgÀnglig för installation. Varför Àr just denna leveransmetod av paketet till RPM-repositoriet? Varför kan man inte skicka den byggda paketet direkt till förrÄdet? Anledningen Àr att detta Àr ett villkor för att sÀkerstÀlla sÀkerheten. Detta scenarion begrÀnsar möjligheten till obehörig uppladdning av RPM-paket av utomstÄende pÄ servern, som Àr tillgÀnglig för alla Linux-maskiner.
Versionering av databasen
Vid en konsil med utvecklarna framgick det att teamet föredrog MS SQL, men i de flesta non-Windows-projekten hade vi redan anvÀnt PostgreSQL. Eftersom vi redan hade beslutat att avstÄ frÄn allt som Àr betalt, började vi anvÀnda PostgreSQL Àven hÀr.
ĐĐ°Â ĐșĐŸĐœŃОлОŃĐŒĐ” Ń ŃĐ°Đ·ŃĐ°Đ±ĐŸŃĐșĐŸĐč ĐČŃŃŃĐœĐžĐ»ĐŸŃŃ, ŃŃĐŸ ŃДбŃŃĐ°ĐŒ блОжД MS SQL, ĐœĐŸÂ ĐČÂ Đ±ĐŸĐ»ŃŃĐžĐœŃŃĐČĐ” non-Windows ĐżŃĐŸĐ”ĐșŃĐŸĐČ ĐŒŃ ŃжД ĐČĐŸĐČŃŃ ĐžŃĐżĐŸĐ»ŃĐ·ĐŸĐČалО PostgreSQL. йаĐș ĐșĐ°Đș ĐŒŃ ŃжД ŃĐ”ŃОлО ĐŸŃĐșĐ°Đ·Đ°ŃŃŃŃ ĐŸŃ ĐČŃĐ”ĐłĐŸ плаŃĐœĐŸĐłĐŸ, ŃĐŸ ŃŃалО ĐžŃĐżĐŸĐ»ŃĐ·ĐŸĐČĐ°ŃŃ PostgreSQL Đž Đ·ĐŽĐ”ŃŃ.
I denna del vill jag berÀtta hur vi genomförde versionering av databasen och hur vi valde mellan Flyway och Entity Framework Core. LÄt oss titta pÄ deras fördelar och nackdelar.
Nackdelar
Flyway gĂ„r bara i en riktning, vi kan inte gĂ„ tillbaka â det Ă€r en betydande nackdel. Att jĂ€mföra med Entity Framework Core kan göras utifrĂ„n andra parametrar â ur utvecklarens bekvĂ€mlighetssynpunkt. Ni minns vĂ€l att vi satte detta i fokus, och det största kriteriet var att inte Ă€ndra nĂ„got för Windows-utvecklingen.
För Flyway behövde vi nĂ„gon form av omslag, sĂ„ att killarna inte skrev SQL-frĂ„gor. Det Ă€r mycket nĂ€rmare för dem att arbeta i OOP-termer. Vi skrev instruktioner för att arbeta med databasobjekt, en SQL-frĂ„ga formades och kördes. Den nya databasen Ă€r klar, den har testats â allt Ă€r bra, allt fungerar.
Entity Framework Core har en nackdel â vid hög belastning skapar den icke-optimala SQL-frĂ„gor, och belastningen pĂ„ databasen kan bli betydande. Men eftersom vĂ„r tjĂ€nst inte Ă€r högbelastad, rĂ€knar vi inte belastningen i hundratals RPS, accepterade vi dessa risker och delegerade problemet till framtida oss.
Fördelar
Entity Framework Core fungerar ur lÄdan och Àr bekvÀm för utveckling, medan Flyway lÀtt integreras i befintlig CI.Men vi vill ju göra det bekvÀmt för utvecklarna :)
Proceduren för distribueringsuppdateringen
Puppet ser att det kommer en versionÀndring i paketen, dÀribland det som ansvarar för migrering. Först installerar den paketet som innehÄller migreringsskripten och funktionaliteten kopplad till databasen. Efter detta startar applikationen om som arbetar med databasen. DÀrefter installeras de ÄterstÄende komponenterna. Installationsordningen av paketen och körningen av applikationerna beskrivs i Puppet-manifestet.
Applikationerna anvÀnder kÀnsliga uppgifter, sÄsom tokens, databaspassord, och allt detta dras in i konfigurationen frÄn Puppet master, dÀr de lagras i krypterad form.
TFS-problem
Efter att vi hade klargjort och insett att allt verkligen fungerade, bestĂ€mde jag mig för att se vad som hĂ€nder med byggena i TFS generellt för avdelningen för Windows-utveckling av andra projekt â om vi bygger/releases snabbt eller inte, och upptĂ€ckte betydande problem med hastigheten.
Ett av de viktigaste projekten tar 12-15 minuter att bygga â det Ă€r lĂ€nge, sĂ„ kan vi inte leva. En snabb analys visade en fruktansvĂ€rd nedgĂ„ng i I/O, och det pĂ„ matriser.
Genom att analysera komponent för komponent identifierade jag tre fokusomrĂ„den. Det första â «Kaspersky antivirus», som skannar kĂ€llkoden pĂ„ alla Windows Build-agenter. Den andra - Windows Indexer. Den var inte avstĂ€ngd, och allt indexerades i realtid pĂ„ Build-agenterna under distributionsprocessen.
Den tredje - Npm install. Det visade sig att vi i de flesta Pipelines anvÀnde just det hÀr scenariot. Vad Àr nackdelen? Proceduren Npm install körs nÀr beroendetrÀdet skapas i package-lock.json, dÀr versionerna av paketen som ska anvÀndas för att bygga projektet registreras. Nackdelen Àr att Npm install varje gÄng hÀmtar aktuella versioner av paketen frÄn internet, vilket tar tid i fallet med ett stort projekt.
Utvecklare experimenterar ibland pÄ den lokala maskinen för att kontrollera funktionen hos en specifik del eller hela projektet. Ibland visade det sig att allt fungerade bra lokalt, men vid sammanstÀllning och distribution fungerade inget. Vi börjar undersöka problemet - aha, olika versioner av beroendepaketen.
Lösning
- KĂ€llorna i undantag AV.
- StÀng av indexeringen.
- ĂvergĂ„ng till npm ci.
Fördelarna med npm ci Àr att vi skapar beroendetrÀdet en gÄng, och fÄr möjlighet att ge utvecklaren en aktuell lista över paket, som han kan experimentera med lokalt utan begrÀnsningar. Det sparar tid för utvecklarna som skriver kod.
Konfiguration
Nu lite om konfigurationen av repositoriet. Historiskt har vi anvÀnt Nexus för att hantera repositorier, inklusive Internal REPO. I detta interna repository levereras alla komponenter som vi anvÀnder för interna ÀndamÄl, till exempel egna övervakningar.
Vi anvÀnder ocksÄ NuGet, eftersom det cachelagrar bÀttre jÀmfört med andra paketförvaltare.
Resultat
Efter att vi har optimerat Build-agenterna har den genomsnittliga byggtiden minskat frÄn 12 minuter till 7.
Om vi rÀknar alla de maskiner som vi skulle ha kunnat anvÀnda för Windows, men som vi istÀllet har överfört till Linux i detta projekt, har vi sparat cirka $10 000. Och det hÀr Àr bara för licenser, och om man rÀknar med driftkostnader - mer.
Planer
För nÀsta kvartal har vi planerat arbete med att optimera kodleveransen.
ĂvergĂ„ng till en förbyggd Docker-image. TFS Ă€r en bra grej med mĂ„nga plugins som möjliggör integration i Pipeline, inklusive byggen utlösta av triggers, till exempel Docker-image. Denna trigger vill vi skapa pĂ„ just det. package-lock.json. Om sammansĂ€ttningen av komponenter som anvĂ€nds för att bygga projektet pĂ„ nĂ„got sĂ€tt Ă€ndras, sĂ„ skapas en ny Docker-image. Den anvĂ€nds senare för att distribuera en container med den sammanstĂ€llda applikationen. För nĂ€rvarande har vi inte detta, men vi planerar att gĂ„ över till mikrotjĂ€nstarkitektur i Kubernetes, som aktivt utvecklas inom vĂ„rt företag och lĂ€nge har drivit produktionslösningar.
Sammanfattning
Jag uppmanar alla att överge Windows, men det beror inte pÄ att jag inte kan hantera det. Anledningen Àr att största delen av Open Source-lösningar Àr Linux-stack. Du kommer att spara mycket pÄ resurser. Enligt min Äsikt ligger framtiden hos Open Source-lösningar pÄ Linux med ett starkt community.
Profilen för talare Alexander Sinchinov .
 Àr en konferens om integrationen av utvecklings-, test- och driftsprocesser för professionella av professionella. DÀrför Àr projektet som Alexander berÀttade om genomfört och fungerar, och pÄ dagen för presentationen genomfördes tvÄ framgÄngsrika releaser. PÄ den 27 och 28 maj blir det Ànnu fler sÄdana fall frÄn praktiker. Man kan fortfarande hoppa pÄ sista tÄget och eller ta sin tid och ett biljett. Vi ses i Skolkovo!
KĂ€lla: habr.com
