Razvili smo DevOps najbolje što smo mogli. Bilo nas je 8, a Vasja je bio najbolji u Windowsu. Odjednom je Vasja otišao, a ja sam imao zadatak da pokrenem novi projekat koji je obezbedio Windows razvoj. Kada sam bacio ceo Windows razvojni stog na sto, shvatio sam da je situacija mučna...
Ovako priča počinje Aleksandra Sinčinova na . Kada je vodeći stručnjak za Windows napustio kompaniju, Aleksandar se pitao šta da radi sada. Prebacite se na Linux, naravno! Aleksandar će vam ispričati kako je uspio napraviti presedan i prenijeti dio Windows razvoja na Linux na primjeru završenog projekta za 100 krajnjih korisnika.
Kako lako i bez napora isporučiti projekat u RPM koristeći TFS, Puppet, Linux .NET core? Kako podržati verziju projektne baze podataka ako razvojni tim prvi put čuje riječi Postgres i Flyway, a rok je prekosutra? Kako se integrirati sa Dockerom? Kako motivirati .NET programere da napuste Windows i smoothieje u korist Puppet-a i Linuxa? Kako riješiti ideološke sukobe ako nema ni snage, ni želje, ni resursa za održavanje Windowsa u proizvodnji? O ovome, kao i o Web Deploy-u, testiranju, CI-u, o praksama korišćenja TFS-a u postojećim projektima i, naravno, o pokvarenim štakama i radnim rešenjima, u transkriptu Aleksandrovog izveštaja.
Dakle, Vasya je otišao, zadatak je na meni, programeri nestrpljivo čekaju s vilama. Kada sam konačno shvatio da Vasju nije moguće vratiti, prionuo sam poslu. Za početak, procijenio sam postotak Win VM-a u našoj floti. Rezultat nije bio u korist Windowsa.
Budući da aktivno razvijamo DevOps, shvatio sam da nešto treba promijeniti u pristupu isporuci nove aplikacije. Postojalo je samo jedno rješenje - ako je moguće, prenijeti sve na Linux. Google 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 sprezi sa Linuxom?
Za to je bilo nekoliko razloga. Između "plati novac" i "ne plati", većina će izabrati drugo - kao ja. Licenca za MSDB košta oko 1 dolara; održavanje flote Windows virtuelnih mašina košta stotine dolara. Za veliku kompaniju ovo je veliki trošak. Zbog toga uštede - prvi razlog. Ne najvažniji, ali jedan od značajnih.
Windows virtuelne mašine zauzimaju više resursa od njihove Linux braće - teški su. S obzirom na veličinu velike kompanije, odabrali smo Linux.
Sistem je jednostavno integrisan u postojeći CI. Smatramo se progresivnim DevOps-om, koristimo Bamboo, Jenkins i GitLab CI, tako da većina našeg rada radi na Linuxu.
Poslednji razlog je zgodna pratnja. Trebalo je da spustimo barijeru ulasku za „prateće“ – momke koji razumiju tehnički dio, osiguravaju nesmetanu uslugu i održavaju usluge iz druge linije. Oni su već bili upoznati sa Linux stekom, tako da im je mnogo lakše razumjeti, podržati i održavati novi proizvod nego da troše dodatne resurse da razumiju istu funkcionalnost softvera za Windows platformu.
zahtjevi
Prvo i najvažnije - pogodnost novog rješenja za programere. Nisu svi bili spremni za promjene, posebno nakon što je izgovorena riječ Linux. Programeri žele svoj omiljeni Visual Studio, TFS sa autotestovima za sklopove i smutije. Za njih nije važno kako se odvija isporuka u proizvodnju. Stoga smo odlučili da ne mijenjamo uobičajeni proces i ostavimo sve nepromijenjeno za Windows razvoj.
Potreban novi projekat integrirati u postojeći CI. Šine su već bile tu i sav posao je morao biti obavljen uzimajući u obzir parametre sistema za upravljanje konfiguracijom, prihvaćene standarde isporuke i sisteme za praćenje.
Jednostavnost podrške i rada, kao uslov za minimalni ulazni prag za sve nove učesnike iz različitih divizija i odjela za podršku.
Rok - juče.
Win Development Group
S čime je Windows tim tada radio?
Sada to mogu sa sigurnošću da kažem IdentityServer4 je kul besplatna alternativa za ADFS sa sličnim mogućnostima, ili što Entity Framework Core - raj za programere, u kojem se ne morate truditi pisati SQL skripte, već opisati upite u bazi podataka OOP terminima. Ali onda, tokom rasprave o akcionom planu, pogledao sam na ovaj stog kao da je sumerski klinopis, prepoznajući samo PostgreSQL i Git.
U to vrijeme smo aktivno koristili lutka kao sistem za upravljanje konfiguracijom. U većini naših projekata koristili smo se GitLab CI, Elastičan, korištenje uravnoteženih usluga visokog opterećenja HAProxy pratili sve sa Zabbix, ligamenti grafana и Prometej, strijelac, a sve se to vrtjelo na komadima željeza HP c ESXi na VMware. Svi to znaju - klasik žanra.
Pogledajmo i pokušajmo da shvatimo šta se dogodilo prije nego što smo započeli sve ove intervencije.
Šta se desilo
TFS je prilično moćan sistem koji ne samo da isporučuje kod od programera do finalne proizvodne mašine, već ima i set za veoma fleksibilnu integraciju sa različitim servisima - da obezbedi CI na nivou više platformi.
Ranije su to bili čvrsti prozori. TFS je koristio nekoliko Build agenata, koji su korišteni za sklapanje mnogih projekata. Svaki agent ima 3-4 radnika za paralelizaciju zadataka i optimizaciju procesa. Zatim, prema planovima za izdavanje, TFS je isporučio svježe ispečeni Build na Windows aplikacijski server.
Šta smo hteli da postignemo?
Koristimo TFS za isporuku i razvoj i pokrećemo aplikaciju na Linux aplikacijskom serveru, a između njih postoji neka vrsta magije. Ovo Magic Box i tu je sol posla koji je pred nama. Prije nego što ga rastavim, napravit ću korak u stranu i reći nekoliko riječi o aplikaciji.
Projekat
Aplikacija pruža funkcionalnost za rukovanje prepaid karticama.
Klijent
Postojale su dvije vrste korisnika. Prvi stekli pristup prijavom koristeći SSL SHA-2 certifikat. U drugi postojao je pristup koristeći login i lozinku.
HAProxy
Zatim je zahtjev klijenta otišao na HAProxy, koji je riješio sljedeće probleme:
- primarno ovlaštenje;
- SSL terminacija;
- podešavanje HTTP zahteva;
- zahtjevi za emitovanje.
Certifikat klijenta je verificiran duž lanca. mi - vlast i to si možemo priuštiti, jer sami izdajemo certifikate klijentima usluga.
Obratite pažnju na treću tačku, na nju ćemo se vratiti malo kasnije.
backend
Planirali su napraviti backend na Linuxu. Backend stupa u interakciju sa bazom podataka, učitava potrebnu listu privilegija i zatim, u zavisnosti od toga koje privilegije ima ovlašćeni korisnik, omogućava pristup za potpisivanje finansijskih dokumenata i njihovo slanje na izvršenje ili generisanje neke vrste izveštaja.
Ušteda uz HAProxy
Pored dva konteksta kojima se svaki klijent kretao, postojao je i kontekst identiteta. IdentityServer4 samo vam omogućava da se prijavite, ovo je besplatan i moćan analog za ADFS - Usluge federacije Active Directory.
Zahtjev za identitet je obrađen u nekoliko koraka. Prvi korak - mušterija ušao u backend, koji je komunicirao s ovim serverom i provjerio prisustvo tokena za klijenta. Ako nije pronađen, zahtjev je vraćen nazad u kontekst iz kojeg je došao, ali s preusmjeravanjem, a sa preusmjeravanjem je otišao na identitet.
Drugi korak - zahtjev je primljen na stranicu za autorizaciju u IdentityServeru, gdje se klijent registrirao, a taj dugo očekivani token se pojavio u bazi podataka IdentityServera.
Treći korak - klijent je preusmjeren nazad kontekstu iz kojeg je došlo.
IdentityServer4 ima funkciju: vraća odgovor na zahtjev za povrat putem HTTP-a. Koliko god da smo se mučili oko podešavanja servera, koliko god da smo se prosvetlili dokumentacijom, svaki put smo dobili početni zahtev klijenta sa URL-om koji je došao preko HTTPS-a, a IdentityServer je vraćao isti kontekst, ali sa HTTP-om. Bili smo šokirani! I sve smo to prenijeli kroz kontekst identiteta na HAProxy, a u zaglavljima smo morali modificirati HTTP protokol u HTTPS.
Kakvo je poboljšanje i gdje ste uštedjeli?
Uštedjeli smo korištenjem besplatnog rješenja za autorizaciju grupe korisnika, resursa, budući da IdentityServer4 nismo postavili kao poseban čvor u poseban segment, već smo ga koristili zajedno sa backendom na istom serveru na kojem se pokreće backend aplikacije. .
Kako bi trebalo da radi
Dakle, kao što sam obećao - Magic Box. Već razumijemo da ćemo zajamčeno krenuti ka Linuxu. Hajde da formulišemo konkretne zadatke koji zahtevaju rešenja.
Lutkarski manifesti. Za isporuku i upravljanje konfiguracijom usluge i aplikacije, morali su biti napisani cool recepti. Rola olovke elokventno pokazuje koliko je to brzo i efikasno urađeno.
Način isporuke. Standard je RPM. Svi razumiju da u Linuxu ne možete bez njega, ali sam projekt, nakon sklapanja, bio je skup izvršnih DLL datoteka. Bilo ih je oko 150, projekat je bio prilično težak. Jedino harmonično rješenje je da se ovaj binarni program spakuje u RPM i iz njega implementira aplikacija.
Versioniranje. Morali smo izdavati vrlo često i morali smo odlučiti kako da formiramo ime paketa. Ovo je pitanje nivoa integracije sa TFS-om. Imali smo agenta za izgradnju na Linuxu. Kada TFS pošalje zadatak rukovaocu - radniku - agentu za izgradnju, on mu također prosljeđuje gomilu varijabli koje završavaju u okruženju procesa rukovanja. Ove varijable okruženja sadrže naziv izgradnje, naziv verzije i druge varijable. Pročitajte više o tome u odjeljku “Izgradnja RPM paketa”.
Postavljanje TFS-a svodio se na postavljanje Pipeline-a. Ranije smo prikupljali sve Windows projekte na Windows agentima, ali sada se pojavljuje Linux agent - Build agent, koji treba da bude uključen u grupu za izgradnju, obogaćen nekim artefaktima i reći koji tip projekata će biti izgrađen na ovom Build agentu , i nekako modificirati Pipeline.
IdentityServer. ADFS nije naš način, mi idemo na Open Source.
Idemo kroz komponente.
Magic Box
Sastoji se od četiri dijela.
Linux Build agent. Linux, jer mi gradimo za njega - logično je. Ovaj dio je rađen u tri koraka.
- Konfigurišite radnike a ne sama, jer se očekivao distribuiran rad na projektu.
- Instalirajte .NET Core 1.x. Zašto 1.x kada je 2.0 već dostupan u standardnom spremištu? Jer kada smo krenuli sa razvojem, stabilna verzija je bila 1.09 i odlučeno je da se projekat napravi na njoj.
- Git 2.x.
RPM-repozitorijum. RPM pakete je trebalo negdje pohraniti. Pretpostavljalo se da ćemo koristiti isto korporativno RPM spremište koje je dostupno svim Linux hostovima. To su oni uradili. Server spremišta je konfigurisan web kuka koji je preuzeo traženi RPM paket sa navedene lokacije. Verzija paketa je prijavljena webhooku od strane Build agenta.
gitlab. Pažnja! GitLab ovdje ne koriste programeri, već odjel za operacije za kontrolu verzija aplikacija, verzija paketa, praćenje statusa svih Linux strojeva i pohranjuje recept - sve manifeste lutke.
lutka — rješava sva kontroverzna pitanja i isporučuje upravo onu konfiguraciju koju želimo od Gitlaba.
Počinjemo da ronimo. Kako funkcionira DLL isporuka u RPM?
Isporuka DDL u RPM
Recimo da imamo .NET razvojnu rock zvijezdu. Koristi Visual Studio i kreira granu izdanja. Nakon toga ga učitava u Git, a Git ovdje je TFS entitet, odnosno, to je spremište aplikacije sa kojim programer radi.
Nakon čega TFS vidi da je stiglo novo urezivanje. Koja aplikacija? U TFS postavkama postoji oznaka koja pokazuje koje resurse ima određeni Build agent. U ovom slučaju, on vidi da gradimo .NET Core projekat i bira agenta za Linux Build iz skupa.
Agent za izgradnju prima izvore i preuzima potrebne zavisnosti iz .NET spremišta, npm, itd. i nakon izrade same aplikacije i naknadnog pakovanja, šalje RPM paket u RPM spremište.
S druge strane, dešava se sljedeće. Inženjer operativnog odjela je direktno uključen u implementaciju projekta: mijenja verzije paketa Hiera u spremištu gdje je pohranjen recept aplikacije, nakon čega se Puppet aktivira Yum, preuzima novi paket iz spremišta, a nova verzija aplikacije je spremna za korištenje.
Sve je jednostavno rečima, ali šta se dešava unutar samog Build agenta?
Pakovanje DLL RPM
Primljeni izvori projekta i zadatak izgradnje iz TFS-a. Build agent počinje izgradnju samog projekta iz izvora. Sastavljeni projekat dostupan je u kompletu DLL datoteke, koji su upakovani u zip arhivu kako bi se smanjilo opterećenje sistema datoteka.
ZIP arhiva se baca u direktorij izgradnje RPM paketa. Zatim, Bash skripta inicijalizira varijable okruženja, pronalazi verziju Build-a, verziju projekta, putanju do direktorija izgradnje i pokreće RPM-build. Kada se izgradnja završi, paket se objavljuje na lokalno spremište, koji se nalazi na Build agentu.
Zatim, od agenta za izgradnju do servera u RPM spremištu JSON zahtjev je poslan označavajući naziv verzije i verzije. Webhook, o kojem sam ranije govorio, preuzima upravo ovaj paket iz lokalnog spremišta na Build agentu i čini novi sklop dostupnim za instalaciju.
Zašto baš ova šema isporuke paketa u RPM spremište? Zašto ne mogu odmah poslati sastavljeni paket u spremište? Činjenica je da je to uslov za sigurnost. Ovaj scenario ograničava mogućnost da neovlaštene osobe učitavaju RPM pakete na server koji je dostupan svim Linux mašinama.
Verzija baze podataka
Na konsultaciji sa razvojnim timom pokazalo se da su momci bliži MS SQL-u, ali u većini projekata koji nisu Windows već smo koristili PostgreSQL svom snagom. Pošto smo već odlučili da napustimo sve plaćeno, počeli smo da koristimo PostgreSQL i ovde.
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 nedostatke.
Minusy
Flyway ide samo u jednom pravcu, mi ne možemo da se vratimo - ovo je značajan nedostatak. Možete ga uporediti sa Entity Framework Core na druge načine - u smislu pogodnosti za programere. Sjećate se da smo ovo stavili u prvi plan, a glavni kriterij je bio da se ništa ne mijenja za Windows razvoj.
Za nas Flyway bila je potrebna neka vrsta omotačada momci ne pišu SQL upiti. Oni su mnogo bliži radu u OOP terminima. Napisali smo upute za rad s objektima baze podataka, generirali SQL upit i izvršili ga. Nova verzija baze je spremna, testirana - sve je u redu, sve radi.
Entity Framework Core ima minus - pod velikim opterećenjem gradi suboptimalne SQL upite, a smanjenje u bazi podataka može biti značajno. Ali pošto nemamo servis sa velikim opterećenjem, ne računamo opterećenje u stotinama RPS-a, prihvatili smo ove rizike i delegirali problem na sebe.
Plûsy
Entity Framework Core radi iz kutije i lako se razvija, i Flyway Lako se integriše u postojeći CI. Ali mi ga činimo zgodnim za programere :)
Procedura roll-up
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 funkcionalnost vezanu za bazu podataka. Nakon toga se ponovo pokreće aplikacija koja radi sa bazom podataka. Slijedi ugradnja preostalih komponenti. Redoslijed kojim se paketi instaliraju i aplikacije pokreću opisan je u manifestu lutke.
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 zaista radi, odlučio sam da pogledam šta se dešava sa sklopovima u TFS-u u cjelini za Win razvojni odjel na drugim projektima - da li smo gradili/obpuštali brzo ili ne, i otkrili značajne probleme sa brzinom.
Za sklapanje jednog od glavnih projekata potrebno je 12-15 minuta - to je dugo, ne možete tako živjeti. Brza analiza je pokazala užasan pad u I/O, i to na nizovima.
Nakon što sam ga analizirao komponentu po komponentu, identifikovao sam tri žarišta. Prvo - "Kaspersky antivirus", koji skenira izvore na svim Windows Build agentima. Sekunda - Windows Indexer. Nije onemogućeno i sve je indeksirano u realnom vremenu na Build agentima tokom procesa implementacije.
Treće - Npm install. Ispostavilo se da smo u većini Pipeline-a koristili upravo ovaj scenario. Zašto je loš? Procedura Npm instalacije se pokreće kada se formira stablo zavisnosti package-lock.json, gdje su zabilježene verzije paketa koji će se koristiti za izgradnju projekta. Nedostatak je što Npm install svaki put izvlači najnovije verzije paketa sa Interneta, a to oduzima dosta vremena u slučaju velikog projekta.
Programeri ponekad eksperimentišu na lokalnom stroju kako bi testirali kako određeni dio ili cijeli projekt funkcionira. Ponekad se ispostavilo da je sve kul lokalno, ali oni su to sastavili, razmotali i ništa nije radilo. Počinjemo da otkrivamo u čemu je problem - da, različite verzije paketa sa zavisnostima.
odluka
- Izvori u AV izuzecima.
- Onemogući indeksiranje.
- Idi npm ci.
Prednosti npm ci su da mi Sakupljamo stablo zavisnosti jednom, a mi dobijamo priliku da obezbedimo programera aktuelna lista paketa, s kojim može lokalno eksperimentirati koliko god želi. Ovo štedi vrijeme programeri koji pišu kod.
Konfiguracija
Sada malo o konfiguraciji spremišta. Istorijski gledano koristimo veza za upravljanje repozitorijumima, uključujući Interni REPO. Ovo interno spremište sadrži sve komponente koje koristimo za interne svrhe, na primjer, samopisno praćenje.
Takođe koristimo NuGet, jer ima bolje keširanje u poređenju sa drugim menadžerima paketa.
rezultat
Nakon što smo optimizirali Build Agente, prosječno vrijeme izgradnje smanjeno je sa 12 minuta na 7.
Ako računamo sve mašine koje smo mogli da koristimo za Windows, ali smo u ovom projektu prešli na Linux, uštedeli smo oko 10 dolara, i to samo na licencama, i više ako uzmemo u obzir sadržaj.
Planovi
Za naredni kvartal planirali smo da radimo na optimizaciji isporuke koda.
Prebacivanje na prethodno izgrađenu Docker sliku. TFS je super stvar sa mnogo dodataka koji vam omogućavaju da se integrišete u Pipeline, uključujući sastavljanje zasnovano na okidaču, recimo, Docker slike. Želimo napraviti ovaj okidač za isti package-lock.json. Ako se sastav komponenti korištenih za izgradnju projekta nekako promijeni, gradimo novu Docker sliku. Kasnije se koristi za postavljanje kontejnera sa sastavljenom aplikacijom. Sada to nije slučaj, ali planiramo da pređemo na mikroservisnu arhitekturu u Kubernetesu, koja se aktivno razvija u našoj kompaniji i već duže vreme opslužuje proizvodna rešenja.
Rezime
Ohrabrujem sve da bace Windows, ali to nije zato što ja ne znam da ga kuvam. Razlog je taj što većina Opensource rješenja jeste Linux stog. Jesi li uredu uštedite na resursima. Po mom mišljenju, budućnost pripada rješenjima otvorenog koda na Linuxu sa moćnom zajednicom.
Profil govornika Aleksandra Sinčinova .
je konferencija o integraciji procesa razvoja, testiranja i rada za profesionalce od strane profesionalaca. Zato je projekat o kome je Aleksandar pričao? implementiran i u funkciji, a na dan izvođenja bila su dva uspješna izdanja. On 27. i 28. maja bit će još više sličnih slučajeva od praktikanata. Još uvijek možete uskočiti u posljednji vagon i ili uzmite vremena ulaznica. Upoznajte nas u Skolkovu!
izvor: www.habr.com