Dejavno smo razvijali DevOps, kot smo mogli. Bilo nas je 8 in Vasja je bil najboljši specialist za Windows. Nenadoma je Vasja odšel in pred mano se je pojavila naloga, da uvedem nov projekt, ki vključuje Windows razvoj. Ko sem postavil na mizo celoten Windows razvojni sklad, sem razumel, da je situacija zelo slaba...
Tako se začne zgodba Aleksander Sinčinov na . Ko je iz podjetja odšel vodilni strokovnjak za Windows, se je Aleksander vprašal, kaj storiti zdaj. Preiti na Linux, seveda! Aleksander bo govoril o tem, kako mu je uspelo ustvariti precedens in prenesti del Windows razvoja na Linux na primeru izvedenega projekta za 100.000 končnih uporabnikov.
Kako enostavno in brez težav dostaviti projekt v RPM, ob uporabi TFS, Puppet, Linux .NET core? Kako vzdrževati verzioniranje baze podatkov projekta, če razvojna ekipa prvič sliši besede Postgres in Flyway, rok za dokončanje pa je jutri? Kako integrirati z Dockerjem? Kako motivirati .NET razvijalce, da se odrečejo Windows in smoothiejem v prid Puppet in Linuxu? Kako rešiti ideološke konflikte, ko za vzdrževanje Windows v produkciji ni več moči, volje ali sredstev? O tem, pa tudi o Web Deploy, testiranju, CI, praksah uporabe TFS v obstoječih projektih in seveda o pokvarjenih nastavitvah in delujočih rešitvah bo govoril Aleksander.
Torej, Vasja je odšel, naloga pa je z menoj, razvijalci čakajo z vilami. Ko sem dokončno spoznal, da Vasje ne morem vrniti, sem se lotil dela. Najprej sem ocenil odstotek Windows VM v našem parku. Številke niso bile v prid Windows.
Ker aktivno razvijamo DevOps, sem spoznal, da je treba spremeniti pristop k uvedbi nove aplikacije. Edina rešitev je bila, da vse možno prenesemo na Linux. Google mi je pomagal - v tistem trenutku je bil .Net že portiran na Linux in razumel sem, da je to rešitev!
Zakaj .NET core v povezavi z Linuxom?
Zanj je bilo več razlogov. Med „plačati denar“ in „ne plačati“ večina izbira drugo — tako kot jaz. Licenca za MSDB stane okoli 1.000 $, vzdrževanje parka Windows virtualnih strojev pa je merjeno v stotinah dolarjev. Za veliko podjetje so to veliki stroški. Zato prihranek — je prvi razlog. Ni najpomembnejši, je pa eden izmed tehtnih.
Windows virtualni stroji zavzamejo več virov kot njihovi Linux bratje — so težki. Glede na obseg velikega podjetja smo izbrali Linux.
Sistema se preprosto vključi v obstoječi CI. Še vedno se štejemo za napredne DevOps-e, uporabljamo Bamboo, Jenkins in GitLab CI, zato večina deluje na Linuxu.
Zadnji razlog je udobno vzdrževanje. Morali smo znižati prag vstopa za 'vzdrževalce' – fante, ki razumejo tehnične zadeve, zagotavljajo nemoteno delovanje in vzdržujejo storitve druge ravni. Ti so se že seznanili s tehnologijo Linux, zato jim je veliko lažje razumeti nov izdelek, ga podpirati in vzdrževati, kot pa trošiti dodatne vire za razumevanje primerljive funkcionalnosti programske opreme za Windows platformo.
Zahteve
Prvo in najpomembnejše je udobje nove rešitve za razvijalce. Ne všecim vsem je bilo lahko sprejeti spremembe, še posebej po izgovorjeni besedi Linux. Razvijalci želijo svojo priljubljeno Visual Studio, TFS z avtomatskimi testi po zgradbah in smoothie. Kako se izvaja dostava v produkcijo – zanje ni pomembno. Zato smo se odločili, da ne bomo spreminjali običajnega postopka in bomo pustili za Windows razvijalce vse nespremenjeno.
Nov projekt je treba vključiti v obstoječi CI. Tirnice so že obstajale in vso delo je bilo treba opraviti ob upoštevanju parametrov sistema upravljanja konfiguracij, sprejetih standardov dostave in sistemov monitoringa.
Enostavnost vzdrževanja in delovanja, kot pogoj za minimalni vhodni prag za vse nove udeležence iz različnih oddelkov in vzdrževalnega oddelka.
Rok je bil včeraj.
Skupina Win razvoja
S čim je torej delala ekipa Windows?
Zdaj lahko samozavestno povem, da IdentityServer4 — to je odlična brezplačna alternativa ADFS z enakimi možnostmi, ali pa Entity Framework Core — raj za razvijalca, kjer ni treba skrbeti za pisanje SQL skript, ampak opisovati poizvedbe v BDP v razumljivih OOP izrazih. Ampak takrat, na razpravi o akcijskem načrtu, sem na to tehnologijo gledal kot na šumerko klinopis in poznal le PostgreSQL in Git.
V tistem času smo aktivno uporabljali Puppet kot sistem upravljanja konfiguracije. V večini naših projektov smo uporabljali GitLab CI, Elastic, uravnotežili visoko obremenjene storitve s pomočjo HAProxy, vse spremljali s pomočjo Zabbix, povezave Grafana in Prometheus, Jaeger, in vse to se je vrtelo na strojni opremi HP c ESXi na VMware. Vsem je znano – klasika žanra.
Poglejmo in poskušajmo razumeti, kaj se je dogajalo, preden smo začeli vse te posege.
Kaj je bilo
TFS je precej zmogljiv sistem, ki ne le prenaša kodo od razvijalca do končne produkcijske naprave, ampak tudi ponuja niz možnosti za zelo fleksibilno integracijo z različnimi storitvami – za zagotavljanje CI na跨平台 raven.
Prej so bile to same odprtine. TFS je uporabljal več Build-agentov, na katerih je bilo zbranih več projektov. V vsakem agentu po 3-4 delavce, da so razdelili naloge in optimizirali proces. Nato je TFS, v skladu z načrti izdaje, dostavil sveže zgrajen Build na Windows strežnik aplikacij.
Kam smo želeli priti
Za dostavo in razvoj uporabljamo TFS, aplikacijo pa zagnamo na Linux strežniku aplikacij, med njima pa se odvija neka magija. Ta Magic Box je tista ključna komponenta prihodnjega dela. Preden ga razstavim na dele, bom naredil korak nazaj in povedal dve besedi o aplikaciji.
Projekt
Aplikacija ponuja funkcionalnost za upravljanje s predplačniškimi karticami.
Client
Obstajala sta dva tipa uporabnikov. Prvi je imel dostop, avtentificiral se je s certifikatom SSL SHA-2. Drugi je imel dostop s prijavno in geslom. Nato se je uporabniška zahteva poslala v HAProxy, ki je reševal naslednje naloge:
HAProxy
prvotna avtentifikacija;
- zaključevanje SSL;
- nastavljanje HTTP zahtev;
- pretvarjanje zahtev.
- Preverjanje uporabniškega certifikata je potekalo po verigi. Mi smo
authority in si lahko to privoščimo, saj sami izdamo certifikate strankam storitve. Pozorni bodite na tretjo točko, kmalu se bomo vanjo ponovno vrnili.
Načrtovali smo, da bo backend zasnovan na Linuxu. Backend komunicira z bazo podatkov, naloži potreben seznam privilegijev in nato, odvisno od privilegijev, ki jih ima avtentificirani uporabnik, omogoča dostop do podpisa finančnih dokumentov in njihovega pošiljanja v izvedbo ali generiranja nekega poročila.
Backend
Prihranek s HAProxy
Poleg dveh kontekstov, po katerih je hodil vsak izmed uporabnikov, je obstajal še kontekst identity.
ki omogoča avtentikacijo, je brezplačna in zmogljiva alternativa za IdentityServer4 ADFS Active Directory Federation Services — Zahteva v identity je bila obdelana v več korakih. Prvi korak –.
je prišel v backend stranko je bil obdelan., ki je izmenjeval podatke s tem strežnikom in preverjal prisotnost žetona za stranko. Če ga ni našel, se je zahteva vrnila nazaj v kontekst, iz katerega je prišla, vendar z redirekcijo, in redirekcija je šla na identity.
Drugi korak je bil, da je zahteva prispela na stran za avtorizacijo v IdentityServer, kjer se je stranka registrirala, v bazi podatkov IdentityServer pa se je pojavil tisti dolgo pričakovani žeton.
Tretji korak je, da se stranka redirekta nazaj v kontekst, iz katerega je prišla.
IdentityServer4 ima posebnost: odgovor na povratno zahtevo vrača preko HTTP. Kakorkoli smo se trudili s konfiguracijo strežnika, kakorkoli smo se izobraževali iz dokumentacije, smo vsakokrat prejeli prvotno zahtevo stranke z URL-jem, ki je prišel preko HTTPS, IdentityServer pa je vračal isti kontekst, vendar z HTTP. Bili smo v šoku! Vse to smo preusmerili preko konteksta identity na HAProxy, v glavi pa smo morali modificirati protokol HTTP na HTTPS.
Kakšna je torej izboljšava in kje smo prihranili?
Prihranili smo denar, ker smo uporabili brezplačno rešitev za avtorizacijo skupine uporabnikov, sredstva, saj nismo postavili IdentityServer4 kot ločeno nod v ločen segment, temveč smo ga uporabljali skupaj z backendom na istem strežniku, kjer deluje backend aplikacije.
Kako naj bi delovalo
Torej, kot sem obljubil – Čarobna Škatla. Že razumemo, da se usmerjamo k Linuxu. Dajte natančno opredeliti naloge, ki so zahtevale rešitev.
Puppet manifesti. Za dostavo in upravljanje konfiguracije storitve in aplikacije je bilo potrebno napisati odlične recepte. Rolica s svinčnikom glasno prikazuje, kako hitro in kakovostno je bilo to opravljeno.
Način dostave. Standarden je RPM. Vsi vedo, da brez njega v Linuxu ne gre, a sam projekt po sestavi predstavlja sklop izvršnih DLL-datotek. Bilo jih je okoli 150, projekt je dovolj težak. Edina harmonična rešitev je, da se to binarno snov zapakira v RPM in ga iz njega razpakiramo aplikacijo.
Različne verzije. Imeli smo potrebo po zelo pogostih izdajah in morali smo ugotoviti, kako oblikovati ime paketa. To je vprašanje na ravni integracije s TFS. Naš Build-agent je deloval na Linuxu. Ko TFS pošlje nalogo obdelovalniku - delavcu - na Build-agent, mu posreduje tudi množico spremenljivk, ki preidejo v okolje obdelovalnega procesa. V teh spremenljivkah okolja se prenaša ime Builda, ime različice in druge spremenljivke. Več o tem v razdelku 'sestavljanje RPM-paketa'.
Nastavitev TFS je bila osredotočena na nastavitev Pipeline. V preteklosti smo gradili vse Windows projekte na Windows agentih, zdaj pa se pojavi Linux-agent - Build-agent, ki ga je treba vključiti v skupino za sestavljanje, obogatiti z nekaterimi artefakti, povedati, katere vrste projektov bodo sestavljene na tem Build-agentu in na nek način modificirati Pipeline.
IdentityServer. ADFS ni naš cilj, podpiramo Open Source.
Poglejmo komponente.
Magic Box
Sestavljen je iz štirih delov.
Linux Build-agent. Linux, ker sestavljamo zanj - logično. Ta del je bil izveden v treh korakih.
- Nastavite delavce in ne enega, saj je bila predvidena razpršena obdelava projekta.
- Namestite .NET Core 1.x. Zakaj prav 1.x, ko je že na voljo 2.0 v standardnem repozitoriju? Ker je ob začetku razvoja stabilna različica bila 1.09 in smo se odločili, da projekt naredimo za to različico.
- Git 2.x.
RPM-repository. RPM-pakete je bilo treba nekje hraniti. Predvideno je bilo, da bomo uporabili isti korporativni RPM-repozitorij, ki je na voljo vsem Linux gostiteljem. Tako smo tudi ravnali. Na strežniku repozitorija je nastavljen webhook ki je prenašal potrebni RPM-paket iz navedene lokacije. Različico paketa je Build-agent sporočil webhooku.
GitLab. Pozor! GitLab tukaj uporabljajo ne razvijalci, temveč oddelek za obratovanje za nadzor različic aplikacije, različic paketov, kontrola stanja vseh Linux strojev in v njem se hrani receptura - vsi manifesti Puppet.
Puppet – rešuje vse sporne točke in dostavlja točno tisto konfiguracijo, ki jo želimo, iz Gitlaba.
Začnimo se potopiti. Kako poteka dostava DLL v RPM?
Dostava DLL v RPM
Recimo, da imamo zvezdo razvoja na .NET. Uporablja Visual Studio in ustvari različico. Po tem jo naloži v Git, in Git je tukaj - entiteta TFS, torej je to repozitorij aplikacije, s katero dela razvijalec.
Po tem TFS zazna, da je prišel nov commit. Katera aplikacija? V nastavitvah TFS je oznaka, katere vire ima določen Build-agent. V tem primeru vidi, da sestavljamo .NET Core projekt in izbere Linux Build-agent iz bazena.
Build-agent prejme izvorno kodo, prenese potrebne dependencies iz .NET repozitorija, npm itd. in po sestavi aplikacije in njenem pakiranju pošlje RPM paket v RPM repozitorij.
Na drugi strani se dogaja naslednje. Inženir oddelka za vzdrževanje se neposredno ukvarja z odvajanjem projekta: spreminja verzije paketov v Hiera v repozitoriju, kjer je shranjen recept aplikacije, nato Puppet sproži Yum, pobere nov paket iz repozitorija in nova različica aplikacije je pripravljena za uporabo.
Na papirju je vse preprosto, ampak kaj se dogaja znotraj samega Build-agenta?
Pakiranje DLL RPM
Prejeta je izvorna koda projekta in naloga za sestavo od TFS. Build-agent začne sestavo samega projekta iz izvorne kode.Sestavljen projekt je na voljo v obliki številnih DLL datotek, ki so pakirane v zip arhiv za zmanjšanje obremenitve na datotečnem sistemu.
ZIP arhiv se izda v direktorij za sestavo RPM paketa. Nato Bash skript inicializira okoljske spremenljivke, najde verzijo Build, verzijo projekta, pot do direktorija za sestavo in zažene RPM-build. Po zaključku sestave se paket objavi v lokalnem repozitoriju, ki se nahaja na Build-agentu.
Nato se iz Build-agenta na strežnik v RPM-repozitorij pošlje JSON zahtevek z navedbo imena verzije in buildu. Webhook, o katerem sem prej govoril, prenese ta paket iz lokalnega repozitorija na Build-agentu in naredi novo sestavo pripravljeno za namestitev.
Zakaj je takšna shema dostave paketa v RPM repozitorij? Zakaj ne moremo takoj poslati sestavljenega paketa v repozitorij? Gre za to, da je to pogoj za zagotavljanje varnosti. Takšen scenarij omejuje možnost nepooblaščenega nalaganja RPM paketov od nepooblaščenih oseb na strežnik, ki je dostopen vsem Linux napravam.
Različnost Baze podatkov
Na konziliju z razvojem se je izkazalo, da so fantje bližje MS SQL, vendar smo v večini non-Windows projektov že uporabili PostgreSQL. Ker smo se odločili, da se odpovemo vsem plačljivim rešitvam, smo začeli uporabljati PostgreSQL tudi tukaj.
V tem delu želim govoriti o tem, kako smo izvajali verzioniranje BDP in kako smo izbirali med Flyway in Entity Framework Core. Oglejmo si njune prednosti in slabosti.
Недостатки
Flyway deluje le v eno smer, mi ne moremo vrniti nazaj — to je pomembna pomanjkljivost. Splotiti ga je mogoče z Entity Framework Core po drugih kriterijih — z vidika udobja za razvijalce. Saj se spomnite, da smo to postavili na prvo mesto, in glavno merilo je bilo, da ne spremenimo nič za Windows-razvoj.
Za Flyway smo potrebovali nekakšno ovito, da fantje ne bi pisali SQL-poizvedbe. Zanje je veliko bližje delati v izrazih OOP. Napisali smo navodila za delo z objekti BDP, oblikoval se je SQL-poizvedba in izvedla. Nova različica BDP je pripravljena, testirana - vse je v redu, vse deluje.
Entiteta Framework Core ima pomanjkljivost - pri velikih obremenitvah gradi neoptimalne SQL-poizvedbe, kar lahko povzroči pomembne padce v BDP. Ampak ker naš servis ni pod velikimi obremenitvami, obremenitev ne merimo s stotinami RPS, smo sprejeli te tveganja in delegirali težave prihodnjim nam.
Prednosti
Entity Framework Core to deluje iz škatle in je udobno za razvoj, Flyway pa se enostavno integrira v obstoječ CI. Ampak končno delamo, da je ugodno za razvijalce :)
Postopek namestitve
Puppet vidi, da prihajajo spremembe različic paketov, med katerimi je tisti, ki odgovarja za migracijo. Najprej namesti paket, kjer so migracijski skripti in funkcionalnosti, povezane z BDP. Po tem se aplikacija, ki dela z BDP, ponovno zažene. Nato sledi namestitev preostalih komponent. Zaporedje namestitve paketov in zagon aplikacij je opisano v Puppet manifestu.
Aplikacije uporabljajo občutljive podatke, kot so žetoni, gesla do BDP, vse to se vleče v konfiguracijo s Puppet master, kjer so shranjeni v šifrirani obliki.
Težave TFS
Potem ko smo se odločili in spoznali, da nam v resnici vse deluje, sem se odločil preveriti, kaj se dogaja s sestavki v TFS na splošno za oddelek Win-razvoja za druge projekte - ali se hitro sestavljamo/izdajamo, in odkril sem pomembne težave s hitrostjo.
Eden od glavnih projektov se sestavlja 12-15 minut - to je dolgo, tako se ne da živeti. Hitri analiza je pokazala grozno upočasnitev po I/O, in to pri poljih.
Po analizi po komponentah sem izpostavil tri žarišča. Prvo - "Kaspersky antivirus", ki na vseh Windows Build-agentih skenira izvorne kode. Drugi - Windows Indexer. Ni bil onemogočen, in na Build-agentih se je v realnem času indeksiralo vse med procesom namestitve.
Tretji - Npm install. Izkazalo se je, da smo v večini Pipelines uporabljali prav ta scenarij. Kaj je narobe? Postopek Npm install se zažene pri oblikovanju drevesa odvisnosti v package-lock.json, kjer se zabeležijo različice paketov, ki se bodo uporabljale za sestavljanje projekta. Slabost je v tem, da Npm install vsakokrat potegne aktualne različice paketov iz interneta, kar vzame precej časa v primeru velikega projekta.
Razvijalci včasih eksperimentirajo na lokalnem računalniku, da preverijo delovanje posameznega dela ali projekta v celoti. Včasih se je izkazalo, da je vse super lokalno, vendar pri sestavljanju ni delovalo. Začnemo ugotavljati, v čem je težava - aha, različice paketov z odvisnostmi so različne.
Solution
- Izvorne kode v izjemah AV.
- Onemogočitev indeksacije.
- Prehod na npm ci.
Prednosti npm ci so, da drevni odvisnosti zgradimo enkrat, in dobimo možnost, da razvijalcu ponudimo aktualen seznam paketov, s katerim lahko neomejeno eksperimentira lokalno. To prihrani čas razvijalcem, ki pišejo kodo.
Конфигурация
Sedaj malo o konfiguraciji repozitorija. Zgodovinsko smo uporabljali Nexus za upravljanje repozitorijev, vključno z Internal REPO. V ta interni repozitorij se dostavljajo vse komponente, ki jih uporabljamo za interne namene, na primer, lastni monitoring.
Nadgrajujemo tudi NuGet, ker bolje predpomni v primerjavi z drugimi upravitelji paketov.
Результат.
Po tem, ko smo optimizirali Build-agente, se je povprečni čas sestavljanja skrajšal s 12 minut na 7.
Če upoštevamo vse računalnike, ki bi jih lahko uporabili za Windows, a smo jih prenesli na Linux v tem projektu, smo prihranili približno 10.000 $. In to je le za licence, če upoštevamo tudi vzdrževanje — še več.
Načrti
Za naslednje četrtletje smo načrtovali optimizacijo dostave kode.
Prehod na prebuild Docker-sliko. TFS je odlična stvar z mnogimi vtičniki, ki omogočajo integracijo v Pipeline, vključno s sestavljanjem po sprožilcu, recimo, Docker-slike. Ta sprožilec želimo narediti za tistega. package-lock.json. Če se na kakršen koli način spremeni sestava komponent, ki se uporabljajo za sestavljanje projekta, se ustvari nova Docker slika. Ta se nato uporablja za uvajanje kontejnerja s sestavljeno aplikacijo. Trenutno tega ni, a načrtujemo prehod na mikrostoritveno arhitekturo v Kubernetesu, ki se aktivno razvija v naši podjetju in že dolgo služi produkcijskim rešitvam.
Резюме
Vsem pozivam, naj zavržejo Windows, vendar to ni zato, ker je ne znam pripraviti. Razlog je, da je večina odprtokodnih rešitev - to je Linuxov sklad. Dober prihranite pri virih. Po mojem mnenju je prihodnost v odprtokodnih rešitvah na Linuxu z močnim skupnostim.
Profil govorca Aleksandra Sinčinova .
je konferenca o integraciji procesov razvoja, testiranja in delovanja za profesionalce od profesionalcev. Zato je projekt, o katerem je govoril Aleksander, realiziran in deluje, medtem ko sta bila na dan njegovega nastopa izvedena dva uspešna izdaja. Na 27. in 28. maja bo še več takšnih primerov od praktikov. Še vedno lahko skočite na zadnji vlak in ali brez hitenja vstopnico. Se vidimo v Skolkovu!
Izvor: habr.com
