.NET Core na LinuxDevOps je u porastu

Razvili smo DevOps najbolje što smo mogli. Bilo nas je 8, a Vasya je bio najkul. WindowsOdjednom je Vasja otišao, a ja sam imao zadatak pokrenuti novi projekt koji opskrbljuje Windows-razvoj. Kad sam cijelu hrpu istresao na stol Windows-razvoj događaja, onda sam shvatio da je situacija bolna...

Ovako priča počinje Aleksandra Sinčinova na DevOpsConfKada je vodeći stručnjak napustio tvrtku Windows, Aleksandar se pitao što sad učiniti. Idi na LinuxNaravno! Aleksandar će vam reći kako je uspio postaviti presedan i prevesti dio Windows događanja na Linux koristeći primjer završenog projekta za 100 000 krajnjih korisnika.

.NET Core na LinuxDevOps je u porastu

Kako lako i bez napora isporučiti projekt RPM-u koristeći TFS, Puppet, Linux .NET Core? Kako održavati verzioniranje baze podataka projekta ako programer prvi put čuje riječi Postgres i Flyway, a rok je prekosutra? Kako se integrirati s Dockerom? Kako motivirati .NET programere da napuste Windows i smoothieje za lutku i LinuxKako riješiti ideološke sukobe ako služite Windows Nemate energije, želje ili resursa za početak produkcije? Alexanderova prezentacija raspravlja o tome, kao i o web implementaciji, testiranju, CI, TFS praksama u postojećim projektima i, naravno, neispravnim zaobilaznim rješenjima i radnim rješenjima.

Reproduciraj videozapis

Dakle, Vasya je otišao, zadatak je bio moj, a programeri su nestrpljivo čekali s vilama. Kad sam konačno shvatio da se Vasya neće vratiti, bacio sam se na posao. Prvo sam procijenio postotak Win VM-a u našoj floti. Izgledi su bili protiv njega. Windows.

.NET Core na LinuxDevOps je u porastu

Budući da aktivno razvijamo DevOps, shvatio sam da moramo nešto promijeniti u pristupu implementaciji novih aplikacija. Postojalo je samo jedno rješenje: prebaciti sve na nativnu verziju, ako je moguće. LinuxGoogle mi je pomogao - u to vrijeme .Net je već bio portiran na Linux, i shvatio sam da je to rješenje!

Zašto .NET core u kombinaciji s Linux?

Za to je bilo nekoliko razloga. Kad bi se moglo birati između plaćanja i neplaćanja, većina ljudi bi odabrala ovo drugo - kao i ja. Licenca za MSDB košta oko 1000 dolara, a održavanje flote virtualnih strojeva... Windows iznosi stotine dolara. Za veliku tvrtku to je značajan trošak. Stoga, štednja - prvi razlog. Ne najvažniji, ali jedan od najznačajnijih.

Virtualni strojevi Windows troše više resursa nego njihova braća Linux - teški suS obzirom na veličinu velike tvrtke, odabrali smo Linux.

Sustav se jednostavno integrira u postojeći CISmatramo se progresivnim DevOpsima, koristimo Bamboo, Jenkins i GitLab CI, tako da većinu našeg rada obavljamo na Linux.

Posljednji razlog je zgodna pratnja. Morali smo sniziti ulaznu barijeru za "održavatelje" - one koji razumiju tehničku stranu, osiguravaju vrijeme rada i održavaju usluge iz druge linije. Oni su već bili upoznati sa sustavom. Linux, pa im je puno lakše razumjeti, podržavati i održavati novi proizvod nego trošiti dodatne resurse kako bi razumjeli slične funkcionalnosti softvera za Windows platforma.

Zahtjevi

Prva i najvažnija stvar je praktičnost novog rješenja za programereNisu svi bili spremni za promjenu, posebno nakon što je riječ izgovorena LinuxRazvojni programeri žele svoj omiljeni Visual Studio, TFS s automatiziranim testovima izgradnje i smoothiejima. Način na koji isporučuju u produkciju im nije važan. Zato smo odlučili ne mijenjati poznati proces i ostaviti ga za… Windows- razvoj događaja ostaje nepromijenjen.

Potreban novi projekt integrirati u postojeće CI. Tračnice su već bile tu i sav posao je trebalo obaviti uzimajući u obzir parametre sustava upravljanja konfiguracijom, prihvaćene standarde isporuke i sustave nadzora.

Jednostavnost podrške i rada, kao uvjet za minimalni ulazni prag za sve nove sudionike iz različitih odjela i odjela podrške.

Rok - jučer.

Win Development Group

S čime je tim tada radio? Windows?

.NET Core na LinuxDevOps je u porastu

Sada to mogu pouzdano reći IdentityServer4 je cool besplatna alternativa ADFS-u sa sličnim mogućnostima, ili što? Entity Framework Core — raj za programere, gdje se ne morate zamarati pisanjem SQL skripti, već upite u bazi podataka opisujete OOP terminima. Ali onda, tijekom rasprave o akcijskom planu, pogledao sam ovaj hrp kao da je sumersko klinasto pismo, prepoznajući samo PostgreSQL i Git.

U to smo vrijeme aktivno koristili Lutka kao sustav upravljanja konfiguracijom. U većini naših projekata koristili smo GitLab CI, Elastičan, uravnotežene usluge visokog opterećenja uz pomoć HAProxy pratio sve uz pomoć Zabbix, ligamenti grafana и Prometej, Strijelac, a sve se to vrtjelo na komadima hardvera HPESXi na VMware. Svi su upoznati s klasicima žanra.

.NET Core na LinuxDevOps je u porastu

Pogledajmo i pokušajmo razumjeti što se dogodilo prije nego što smo započeli sve ove intervencije.

Što se dogodilo

TFS je prilično moćan sustav koji ne samo da isporučuje kod od razvojnog programera do konačnog proizvodnog stroja, već ima i set za vrlo fleksibilnu integraciju s raznim uslugama - za pružanje CI na razini više platformi.

.NET Core na LinuxDevOps je u porastu
Prije su to bili samo Windowsi. TFS je koristio nekoliko Build agenata koji su gradili više projekata. Svaki agent imao je 3-4 radnika za paralelizaciju zadataka i optimizaciju procesa. Zatim je, prema planovima izdanja, TFS isporučio svježe pečenu Build verziju... Windows- aplikacijski poslužitelj.

Ono što smo htjeli postići

Za isporuku i razvoj koristimo TFS, a aplikaciju pokrećemo na Linux Aplikacijski poslužitelj, i postoji neka magija između njih. Ovo Čarobna kutija a tu je i sol posla. Prije nego što ga rastavim, napravit ću korak u stranu i reći nekoliko riječi o aplikaciji.

Projekt

Aplikacija pruža funkcionalnost za rukovanje prepaid karticama.

.NET Core na LinuxDevOps je u porastu

Klijent

Postojale su dvije vrste korisnika. Prvi stekao pristup prijavom pomoću SSL SHA-2 certifikata. U drugi postojao je pristup pomoću prijave i lozinke.

HAProxy

Zatim je zahtjev klijenta otišao HAProxyju, koji je riješio sljedeće probleme:

  • primarno ovlaštenje;
  • SSL završetak;
  • podešavanje HTTP zahtjeva;
  • zahtjevi za emitiranje.

Certifikat klijenta je verificiran duž lanca. mi - vlast a to si možemo priuštiti, budući da sami izdajemo certifikate klijentima usluga.

Obratite pozornost na treću točku, vratit ćemo se na nju malo kasnije.

Backend

Planirano je da se backend napravi na LinuxBackend komunicira s bazom podataka, učitava potreban popis privilegija, a zatim, ovisno o privilegijama ovlaštenog korisnika, odobrava pristup za potpisivanje financijskih dokumenata i slanje istih na izvršenje ili generiranje izvješća.

Štedite uz HAProxy

Osim dva konteksta kroz koja je svaki klijent prošao, postojao je i kontekst identiteta. IdentityServer4 samo vam omogućuje da se prijavite, ovo je besplatan i moćan analog za ADFS - Usluge federacije Active Directory.

Zahtjev za identitetom obrađen je u nekoliko koraka. Prvi korak - klijent ušao u backend, koji je komunicirao s ovim poslužiteljem i provjeravao prisutnost tokena za klijenta. Ako nije pronađen, zahtjev se vraćao natrag u kontekst iz kojeg je došao, ali s preusmjeravanjem, a s preusmjeravanjem je išao na identitet.

Drugi korak – zahtjev je primljen na stranicu za autorizaciju u IdentityServeru, gdje se klijent registrirao, a taj dugo očekivani token pojavio se u IdentityServer bazi.

Treći korak je klijent je preusmjeren natrag na kontekst iz kojeg je došao.

.NET Core na LinuxDevOps je u porastu

IdentityServer4 ima značajku: vraća odgovor na povratni zahtjev putem HTTP-a. Koliko god se mučili s postavljanjem servera, koliko god se prosvjetljivali s dokumentacijom, svaki put smo dobili inicijalni klijentski zahtjev s URL-om koji je došao preko HTTPS-a, a IdentityServer je vratio isti kontekst, ali s HTTP-om. Ostali smo šokirani! I sve smo to prenijeli kroz kontekst identiteta u HAProxy, au zaglavljima smo morali modificirati HTTP protokol u HTTPS.

U čemu je napredak i gdje ste uštedjeli?

Uštedjeli smo novac korištenjem besplatnog rješenja za autorizaciju grupe korisnika, resursa, budući da IdentityServer4 nismo smjestili kao poseban čvor u zasebnom segmentu, već smo ga koristili zajedno s backendom na istom poslužitelju na kojem se pokreće backend aplikacije. .

Kako bi trebalo raditi

Dakle, kao što sam obećao – Magična kutija. Već razumijemo da se definitivno krećemo u smjeru LinuxFormulirajmo konkretne zadatke koje je trebalo riješiti.

.NET Core na LinuxDevOps je u porastu

Lutkarski manifesti. Za isporuku i upravljanje konfiguracijom usluge i aplikacije morali smo napisati cool recepte. Kolut olovke rječito pokazuje koliko je to brzo i učinkovito učinjeno.

Način dostave. Standard je RPM. Svi to razumiju Linux Nije bilo načina da se to zaobiđe, ali sam projekt, nakon što je izgrađen, bio je zbirka izvršnih DLL datoteka. Bilo ih je oko 150, što je projekt činilo prilično teškim. Jedino održivo rješenje bilo je pakirati te binarne datoteke u RPM i od tamo implementirati aplikaciju.

Verziranje. Planirali smo vrlo često objavljivati ​​i morali smo odlučiti kako oblikovati naziv paketa. To je bilo pitanje razine integracije s TFS-om. Imali smo agenta za izgradnju. LinuxKada TFS šalje zadatak radniku na agentu za izgradnju, također mu prosljeđuje niz varijabli koje su pohranjene u okruženju radnika. Ove varijable okruženja sadrže naziv izgradnje, naziv verzije i druge varijable. Više detalja dostupno je u odjeljku "Izgradnja RPM paketa".

Postavljanje TFS-a Sve se svelo na postavljanje plinovoda. Prije smo gradili na Windows-svi agenti Windows-projekti, a sada se čini Linux-agent — Build agent koji treba biti uključen u grupu za izgradnju, obogaćen nekim artefaktima, specificiran koji će se tip projekata graditi na ovom Build agentu i modificiran na neki način Pipeline.

IdentityServer. ADFS nije naš način, mi smo za Open Source.

Prođimo kroz komponente.

Čarobna kutija

Sastoji se od četiri dijela.

.NET Core na LinuxDevOps je u porastu

Linux Agent za izgradnju. Linux, jer kompajliramo za to—ima smisla. Ovaj dio je dovršen u tri koraka.

  • Konfigurirajte radnike i to ne sama, jer se očekivao raspodijeljeni rad na projektu.
  • Instalirajte .NET Core 1.x. Zašto 1.x kada je 2.0 već dostupan u standardnom repozitoriju? Jer kada smo krenuli s razvojem, stabilna verzija je bila 1.09 i odlučeno je da se projekt napravi na temelju nje.
  • Git 2.x.

RPM-repozitorij. RPM pakete je trebalo negdje pohraniti. Trebali smo koristiti isti korporativni RPM repozitorij koji je bio dostupan svima. Linux hosts. To smo i učinili. Poslužitelj repozitorija je konfiguriran web kuka koji je preuzeo traženi RPM paket s navedenog mjesta. Verziju paketa prijavio je web-dojavniku agent za izgradnju.

GitLab. Napomena: GitLab ovdje ne koriste programeri, već operativni odjel za kontrolu verzija aplikacija, verzija paketa i statusa svih Linux-strojevi i pohranjuje recept - sve Puppet manifeste.

Lutka — rješava sve kontroverzne probleme i isporučuje točno onu konfiguraciju koju želimo od Gitlaba.

Počinjemo roniti. Kako isporuka DLL-a radi u RPM-u?

Isporuka DDL u RPM

Recimo da imamo rock zvijezdu razvoja .NET-a. Koristi Visual Studio i stvara granu izdanja. Nakon toga ga postavlja u Git, a Git je ovdje TFS entitet, odnosno repozitorij aplikacije s kojim programer radi.

.NET Core na LinuxDevOps je u porastu

Nakon toga, TFS vidi da je stigao novi commit. Koja aplikacija? TFS postavke pokazuju koje resurse ima svaki Build Agent. U ovom slučaju, vidi da gradimo .NET Core projekt i odabire Linux Izgradite agenta iz bazena.

Agent za izgradnju prima izvore i preuzima potrebne ovisnosti c .NET spremišta, npm, itd. i nakon izgradnje same aplikacije i naknadnog pakiranja, šalje RPM paket u RPM repozitorij.

S druge strane, događa se sljedeće. Inženjer odjela operacija izravno je uključen u uvođenje projekta: on mijenja verzije paketa Hiera u repozitorij gdje je pohranjen recept aplikacije, nakon čega se aktivira Puppet Yum, dohvaća novi paket iz repozitorija i nova verzija aplikacije je spremna za korištenje.

.NET Core na LinuxDevOps je u porastu

Riječima je sve jednostavno, ali što se događa unutar samog Build agenta?

DLL RPM pakiranje

Od TFS-a smo dobili izvore projekta i zadatak montaže. Agent za izgradnju počinje graditi sam projekt iz izvora. Sastavljeni projekt dostupan je kao set DLL datoteke, koji su pakirani u zip arhivu kako bi se smanjilo opterećenje datotečnog sustava.

ZIP arhiva se baca u direktorij za izradu RPM paketa. Zatim, Bash skripta inicijalizira varijable okruženja, pronalazi verziju Build-a, verziju projekta, put do direktorija za izgradnju i pokreće RPM-build. Kada je izgradnja dovršena, paket se objavljuje na lokalno spremište, koji se nalazi na Build Agentu.

Zatim, od Build agenta do poslužitelja u RPM repozitoriju JSON zahtjev je poslan označavajući naziv verzije i međugradnje. Webhook, o kojem sam ranije govorio, preuzima upravo ovaj paket iz lokalnog repozitorija na Build agentu i novi sklop čini dostupnim za instalaciju.

.NET Core na LinuxDevOps je u porastu

Zašto baš ova shema isporuke za RPM repozitorij? Zašto se izgrađeni paket ne može odmah poslati u repozitorij? To je sigurnosni zahtjev. Ovaj scenarij ograničava mogućnost neovlaštenih osoba da prenose RPM pakete na javno dostupan poslužitelj. Linux-automobili.

Verzija baze podataka

Na konzultacijama o razvoju ispostavilo se da su dečki bliži MS SQL-u, ali u većini slučajeva ne-Windows Već smo intenzivno koristili PostgreSQL za nekoliko projekata. Budući da smo već odlučili napustiti plaćeni softver, počeli smo koristiti PostgreSQL i ovdje.

.NET Core na LinuxDevOps je u porastu

U ovom dijelu želim vam reći kako smo verzionirali bazu podataka i kako smo birali između Flywaya i Entity Framework Core. Pogledajmo njihove prednosti i mane.

Cons

Flyway ide samo u jednom smjeru, mi ne možemo se vratiti — ovo je značajan nedostatak. Može se usporediti s Entity Framework Coreom na druge načine — s gledišta praktičnosti programera. Sjećate se da smo ovo postavili kao glavni prioritet, a glavni kriterij bio je da se ništa ne mijenja za Windows-razvoja.

Za Flyway nas bio je potreban nekakav omottako da dečki ne pišu SQL upiti. Njima je puno bliže poslovati u OOP uvjetima. Napisali smo upute za rad s objektima baze podataka, generirali SQL upit i izvršili ga. Nova verzija baze podataka je spremna, testirana je - sve je u redu, sve radi.

Entity Framework Core ima minus - pod velikim opterećenjem gradi sub-optimalne SQL upite, a pad u bazi podataka može biti značajan. Ali budući da nemamo uslugu visokog opterećenja, ne izračunavamo opterećenje u stotinama RPS-a, prihvatili smo te rizike i delegirali problem budućnosti nama.

Prozodija

Entity Framework Core radi izvan okvira i lako se razvijai Flyway Lako se integrira u postojeći CI. Ali mi to činimo prikladnim za programere :)

Roll-up postupak

Puppet vidi da dolazi promjena u verziji paketa, uključujući i onu koja je odgovorna za migraciju. Prvo instalira paket koji sadrži skripte za migraciju i funkcije povezane s bazom podataka. Nakon toga ponovno se pokreće aplikacija koja radi s bazom podataka. Slijedi instalacija preostalih komponenti. Redoslijed kojim se paketi instaliraju i aplikacije pokreću opisan je u Puppet manifestu.

Aplikacije koriste osjetljive podatke, kao što su tokeni, lozinke baze podataka, sve se to povlači u konfiguraciju iz Puppet mastera, gdje se pohranjuju u šifriranom obliku.

TFS problemi

Nakon što smo odlučili i shvatili da nam sve stvarno radi, odlučio sam pogledati što se općenito događa sa sklopovima u TFS-u za Win razvojni odjel na drugim projektima - gradimo/izdajemo brzo ili ne, i otkrio značajni problemi s brzinom.

Za sastavljanje jednog od glavnih projekata potrebno je 12-15 minuta - to je dugo, ne može se tako živjeti. Brza analiza pokazala je užasno smanjenje I/O, a to je bilo na nizovima.

Nakon što sam analizirao komponentu po komponentu, identificirao sam tri žarišta. Prvo - "Kaspersky antivirus", što je na svima Windows Agenti za izgradnju skeniraju izvorni kod. Drugi je Windows Indeksator. Nije bio onemogućen, a sve u procesu postavljanja bilo je indeksirano u stvarnom vremenu na Build agentima.

treće - Npm instalacija. Ispostavilo se da smo u većini Pipeline-a koristili upravo ovaj scenarij. Zašto je on loš? Postupak instalacije Npm-a pokreće se kada se formira stablo ovisnosti paket-lock.json, gdje su zabilježene verzije paketa koji će se koristiti za izgradnju projekta. Loša strana je što Npm install svaki put izvlači najnovije verzije paketa s interneta, a to oduzima puno vremena u slučaju velikog projekta.

Programeri ponekad eksperimentiraju na lokalnom računalu kako bi testirali kako funkcionira određeni dio ili cijeli projekt. Ponekad se pokazalo da je lokalno sve cool, ali oni su to sastavili, izbacili i ništa nije radilo. Počinjemo shvaćati u čemu je problem - da, različite verzije paketa s ovisnostima.

odluka

  • Izvori u AV iznimkama.
  • Onemogući indeksiranje.
  • Ići npmci.

Prednosti npm ci su da mi Stablo ovisnosti skupljamo jednom, a mi dobivamo priliku pružiti programera trenutni popis paketa, s kojim može lokalno eksperimentirati koliko god želi. Ovaj štedi vrijeme programeri koji pišu kod.

Konfiguracija

Sada malo o konfiguraciji repozitorija. Povijesno smo koristili Nexus za upravljanje spremištima, uključujući Interni REPO. Ovaj interni repozitorij sadrži sve komponente koje koristimo u interne svrhe, na primjer, samonapisani nadzor.

.NET Core na LinuxDevOps je u porastu

Također koristimo NuGet, budući da sprema bolje od drugih upravitelja paketima.

Rezultirati

Nakon što smo optimizirali agente za izgradnju, prosječno vrijeme izgradnje smanjeno je s 12 minuta na 7.

Ako prebrojimo sve strojeve koje bismo mogli koristiti za Windows, ali prevedeno u Linux U ovom projektu uštedjeli smo oko 10.000 dolara. I to je samo na licencama; ako uzmete u obzir sadržaj, to je još više.

Planovi

Plan za sljedeći kvartal je rad na optimizaciji isporuke koda.

Prebacivanje na prethodno izgrađenu Docker sliku. TFS je super stvar s mnogo dodataka koji vam omogućuju integraciju u Pipeline, uključujući međugradnje temeljene na okidaču, recimo, Docker slike. Želimo napraviti ovaj okidač na istom paket-lock.json. Ako se sastav komponenti korištenih za izgradnju projekta nekako promijeni, gradimo novu Docker sliku. Naknadno se koristi za postavljanje spremnika sa sastavljenom aplikacijom. Sada to nije slučaj, ali planiramo prijeći na mikroservisnu arhitekturu u Kubernetesu, koja se u našoj tvrtki aktivno razvija i već duže vrijeme služi proizvodnim rješenjima.

Rezime

Pozivam sve da ga izbace Windows, ali to nije zato što ne znam kako ga kuhati. Razlog je taj što je većina rješenja otvorenog koda Linux-stog. Jesi li dobro? uštedjeti na resursimaPo mom mišljenju, budućnost leži u rješenjima otvorenog koda. Linux s moćnom zajednicom.

Profil govornika Aleksandra Sinčinova na GitHubu.

DevOps Conf je konferencija o integraciji procesa razvoja, testiranja i rada za profesionalce od strane profesionalaca. Zato projekt o kojem je Alexander govorio? implementiran i pokrenut, s dva uspješna izdanja na dan izvedbe. Na DevOps Conf na RIT++ 27. i 28. svibnja bit će još više sličnih slučajeva od strane praktičara. Još uvijek možete uskočiti u posljednji vagon i podnijeti izvješće ili odvojite vrijeme rezervirati ulaznica. Upoznajte nas u Skolkovu!

Izvor: www.habr.com

Kupite pouzdan hosting za stranice s DDoS zaštitom, VPS VDS poslužiteljima 🔥 Kupite pouzdan web hosting sa DDoS zaštitom, VPS VDS servere | ProHoster