Razvijali smo DevOps koliko smo mogli. Bilo nas je 8, a Vasa je bio najjači po Windowsu. Iznenada je Vasa otišao, a meni je zadaća bila pokrenuti novi projekt koji se bavi Windows razvojem. Kada sam stavio sav Windows razvoj na stol, shvatio sam da situacija boli...
Tako počinje priča Aleksandra Sinčinova na . Kada je iz kompanije otišao vodeći stručnjak za Windows, Aleksandar se zapitao što sada raditi. Naravno, preći na Linux! Aleksandar će ispričati kako je uspio stvoriti presedan i prevesti dio Windows razvoja na Linux na primjeru realiziranog projekta sa 100.000 krajnjih korisnika.
Kako lako i neprimjetno donijeti projekt u RPM, koristeći TFS, Puppet, Linux .NET core? Kako održavati verzioniranje DB-a projekta kada razvoj prvi put čuje riječi Postgres i Flyway, a rok je sutra? Kako integrirati s Dockerom? Kako motivirati .NET programere da se odrgnu od Windowsa i smoothija u korist Puppeta i Linuxa? Kako riješiti ideološke sukobe kad održavanje Windowsa u produkciji nije opcija niti iz snova? O tome, kao i o Web Deploy, testiranju, CI, praksama korištenja TFS-a u postojećim projektima, i naravno, o slomljenim štakama i funkcionalnim rješenjima, detaljno govori Aleksandar.
Dakle, Vasa je otišao, zadatak je na meni, a programeri čekaju s vilama nestrpljivo. Kada sam konačno shvatio da Vasine povratka nema, krenuo sam na posao. Prvo sam ocijenio postotak Win VM-a u našem parku. Broj nije bio na strani Windowsa.
Budući da aktivno razvijamo DevOps, shvatio sam da je potrebno nešto promijeniti u pristupu uvođenju nove aplikacije. Rješenje je bilo jedno - prevesti sve na Linux kad god je to moguće. 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 kombinaciji s Linuxom?
Postojalo je nekoliko razloga za to. Između „plaćanja novca“ i „ne plaćanja“, većina će odabrati drugo - kao i ja. Licenca za MSDB košta oko 1000 $, održavanje parka virtualnih mašina Windows košta stotine dolara. Za veliku kompaniju to su veliki troškovi. Zato štednja — prvi razlog. Nije najvažniji, ali jedan od značajnijih.
Windows virtualne mašine troše više resursa od svojih Linux rođaka - teške su. Uzimajući u obzir veličinu velike kompanije, odabrali smo Linux.
Sustav se jednostavno integrira u postojeći CI.. Smatramo se progresivnim DevOps-ima, koristimo Bamboo, Jenkins i GitLab CI, pa se većina našeg rada vrti na Linuxu.
Posljednji razlog je praktična podrška. Trebalo nam je smanjiti barijeru ulaska za 'podupirače' – ljude koji razumiju tehnički dio, osiguravaju kontinuitet i podržavaju usluge druge linije. Već su bili upoznati sa stekom Linux, pa im je puno lakše razumjeti novi proizvod, podržavati ga i održavati nego trošiti dodatne resurse kako bi se snašli s sličnom funkcionalnošću softvera za Windows.
Zahtjevi
Prvo i najvažnije – prikladnost novog rješenja za programere.. Nisu svi bili spremni za promjene, osobito nakon spomenutog imena Linux. Programeri žele svoju omiljenu Visual Studio, TFS s automatskim testovima za buildove i smoothie. Način na koji se isporučuje u produkciju – njima nije važno. Zato smo odlučili ne mijenjati uobičajen postupak i ostaviti sve nepromijenjeno za Windows programere.
Novi projekt treba integrirati u postojeći CI.. Pruge su već postojale i sav posao morao se obaviti uzimajući u obzir parametre sustava upravljanja konfiguracijom, usvojene standarde isporuke i sustave nadzora.
Jednostavnost podrške i eksploatacije, kao uvjet za minimalnu barijeru ulaska za sve nove sudionike iz različitih odjela i odjela potpore.
Rok je bio jučer..
Grupa Win razvoja.
S čim je tada radila Windows ekipa?
Sada mogu sigurno reći da IdentityServer4 je fantastična besplatna alternativa ADFS-u s sličnim mogućnostima, ili da Entity Framework Core je raj za programera, gdje se ne treba zamarati pisanjem SQL skripti, već opisivati upite u Bazi podataka u terminima OOP-a. No tada, tijekom rasprave o planu akcije, na ovaj sam stek gledao kao na sumersko klimavo pismo prepoznajući samo PostgreSQL i Git.
U to vrijeme aktivno smo koristili Puppet kao sustav upravljanja konfiguracijom. U većini naših projekata koristili smo GitLab CI, Elastic, uravnotežili smo visoko opterećene usluge uz pomoć HAProxy, pratili smo sve uz pomoć Zabbix,spojili smo Grafana i Prometheus, Jaeger, i sve je to radilo na hardveru HP c ESXi. na VMware. Svi znamo – klasika žanra.
Pogledajmo i pokušajmo razumjeti što se događalo 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 developera do završne proizvodne mašine, već također ima skup alata za vrlo fleksibilnu integraciju s raznim servisima - za osiguranje CI na višepplatformskom nivou.
Ranije su to bile samo prozore. TFS je koristio nekoliko Build agenata na kojima je bilo mnogo projekata. U svakom agentu bilo je 3-4 radnika kako bi se paralelizirale zadatke i optimizirao proces. Zatim, prema planovima izdanja, TFS je isporučivao sveže napravljeni Build na Windows server aplikacija.
Na što smo željeli doći
Za isporuku i razvoj koristimo TFS, a pokrećemo aplikaciju na Linux Application serveru, a između njih je neka vrsta magije. Ovaj Magic Box je srž nadolazećeg posla. Prije nego što ga raštrkamo na dijelove, malo ću se skloniti i reći nekoliko riječi o aplikaciji.
Projekt
Aplikacija pruža funkcionalnost za upravljanje unaprijed plaćenim karticama.
Klijent
Postojala su dva tipa korisnika. Prvi dobio je pristup autorizirajući se putem SSL SHA-2 certifikata. Drugi je imao pristup putem korisničkog imena i lozinke. HAProxy
Dalje, klijentski zahtjev se slao u HAProxy, koji je rješavao sljedeće zadatke:
prvotna autorizacija;
- terminiranje SSL;
- tuning HTTP zahtjeva;
- prijenos zahtjeva.
- Provjera klijentovog certifikata je išla putem lance. Mi smo
authority i možemo si priuštiti to, jer sami izdavati certifikate klijentima usluge. Obratite pažnju na treću točku, malo ćemo se kasnije vratiti na to.
Backend
Backend smo planirali napraviti na Linuxu. Backend komunicira s bazom podataka, učitava potrebne popise privilegija i zatim, ovisno o privilegijama koje ima autorizirani korisnik, osigurava pristup za potpisivanje financijskih dokumenata i slanje na izvršenje, ili generiranje nekog izvještaja.
Ušteda s HAProxy
Osim dva konteksta kroz koja je svaki klijent prolazio, postojao je još kontekst identity.
koji upravo omogućava autorizaciju, to je besplatan i moćan pandan za IdentityServer4 ADFS Active Directory Federation Services — Zahtjev u identity obrađivao se u nekoliko koraka. Prvi korak -.
dolazio je u backend. klijent upadati u backend, koji je razmjenjivao podatke s ovim poslužiteljem i provjeravao prisutnost tokena za klijenta. Ako nije pronalazio – zahtjev se vraćao natrag na kontekst iz kojeg je došao, ali već s redirekcijom, i s redirekcijom išao na identity.
Drugi korak – zahtjev je stizao na stranicu za autorizaciju u IdentityServer, gdje se klijent registrirao, a u bazi podataka IdentityServer pojavljivao se taj dugo iščekivani token.
Treći korak – klijent je bio redirektiran natrag na kontekst iz kojeg je došao.
IdentityServer4 ima jednu osobitost: odgovor na povratni zahtjev vraća putem HTTP. Koliko god se trudili s postavkom poslužitelja, koliko god se educirali dokumentacijom, svaki put smo dobivali početni zahtjev klijenta s URL-om koji je došao putem HTTPS-a, a IdentityServer je vraćao isti taj kontekst, ali s HTTP. Bili smo u šoku! I preusmjerili smo sve to preko konteksta identity na HAProxy, a u headerima smo morali modificirati protokol HTTP na HTTPS.
U čemu je poboljšanje i gdje smo uštedjeli?
Uštedjeli smo novac koristeći besplatno rješenje za autorizaciju grupe korisnika, resurse, jer nismo iznosili IdentityServer4 kao zasebnu nodu u zasebni segment, već smo ga koristili zajedno s backendom na istom poslužitelju gdje se vrti backend aplikacije.
Kako bi trebalo raditi
Dakle, kao što sam obećao – Magic Box. Već razumijemo da garantirano idemo prema Linuxu. Pokažimo konkretne zadatke koje je trebalo riješiti.
Manifesti Puppet. Kako bismo isporučili i upravljali konfiguracijom usluge i aplikacije, trebalo je napisati odlične recepte. Rolica s olovkom slikovito prikazuje koliko je brzo i kvalitetno to napravljeno.
Način isporuke. Standard je RPM. Svi razumiju da to u Linuxu ne može bez njega, ali sam projekt nakon gradnje predstavljao skup izvršnih DLL-datoteka. Bilo ih je oko 150, projekt je dovoljno težak. Jedino skladno rješenje je upakirati tu binarnu hrpu u RPM i iz nje kasnije razvijati aplikaciju.
Verzioniranje. Morali smo često objavljivati, i trebali smo odlučiti kako formirati ime paketa. To je pitanje razine integracije s TFS-om. Build-agent je bio na Linuxu. Kada TFS pošalje zadatak radniku na Build-agentu, također mu proslijedi i skup varijabli koje ulaze u environment procesa radnika. Ove varijable okruženja uključuju ime Build-a, ime verzije i druge varijable. Više o tome u odjeljku 'izrada RPM-paketa'.
Postavljanje TFS-a svelo se na postavljanje cjevovoda. Prije smo na Windows-agentima sastavljali sve Windows projekte, a sada se pojavljuje Linux-agent - Build-agent, koji treba uključiti u grupu sastavljanja, obogatiti nekim artefaktima, reći kakve vrste projekata će se sastavljati na ovom Build-agentu i nekako modificirati cjevovod.
IdentityServer. ADFS nije naš put, podržavamo Open Source.
Prođimo kroz komponente.
Magic Box
Sastoji se od četiri dijela.
Linux Build-agent. Linux, jer za njega sastavljamo - logično. Ovaj dio je izvršavan u tri koraka.
- Postaviti radnike i ne samo jednog, jer se predviđao distribuirani rad na projektu.
- Instalirati .NET Core 1.x. Zašto baš 1.x, kada je već dostupna 2.0 u standardnom repozitoriju? Zato što je, kada smo započeli razvoj, stabilna verzija bila 1.09, i odlučeno je da će se projekt raditi na njoj.
- Git 2.x.
RPM-repozitorij. RPM-paketi trebali su se negdje čuvati. Predviđeno je da ćemo koristiti isti korporativni RPM-repozitorij koji je dostupan svim Linux hostovima. Tako smo i učinili. Na serveru repozitorija postavljen je webhook koji je preuzimao potrebni RPM-paket iz naznačenog mjesta. Verziju paketa webhook-u je javljala Build-agent.
GitLab. Pažnja! GitLab se ovdje ne koristi od strane programera, već od strane odjela za opskrbu za kontrolu verzija aplikacije, verzija paketa, kontrolu stanja svih Linux mašina, a u njemu se čuva receptura - svi manifesti Puppet.
Puppet — razrješava sve sporne trenutke i isporučuje upravo onu konfiguraciju koju želimo, iz GitLab-a.
Počinjemo s uranjanjem. Kako se događa isporuka DLL u RPM?
Isporuka DDL u RPM
Pretpostavimo da imamo rock zvijezdu razvoja na .NET-u. Koristi Visual Studio i stvara izdanak. Nakon toga ga učitava u Git, a Git ovdje je TFS-entitet, tj. to je repozitorij aplikacije s kojim radi programer.
Nakon čega TFS prepoznaje da je stigao novi commit. Koja aplikacija? U podešavanjima TFS-a postoji oznaka kojim resursima raspolaže određeni Build-agent. U ovom slučaju prepoznaje da sastavljamo .NET Core projekt i bira Linux Build-agent iz bazena.
Build-agent preuzima izvorne kodove, preuzima potrebne zavisnosti iz .NET repozitorijuma, npm itd. i nakon sastavljanja same aplikacije i kasnije pakiranja šalje RPM-paket u RPM-repozitorij.
S druge strane dešava se sledeće. Inženjer iz odeljenja za operacije se direktno bavi implementacijom projekta: menja verzije paketa u Hiera u repozitoriju gde se čuva receptura aplikacije, nakon čega Puppet aktivira Yum, preuzima novi paket iz repozitorija, i nova verzija aplikacije je spremna za upotrebu.
Na rečima je sve jednostavno, ali šta se dešava unutar samog Build-agenta?
Pakovanje DLL RPM
Izvorni kodovi projekta su dobijeni i zadatak za sastavljanje od TFS-a. Build-agent pokreće sastavljanje samog projekta iz izvora. Sastavljeni projekt je dostupan u obliku više DLL datoteka, koje su upakovane u zip-arhiv radi smanjenja opterećenja na datotečkom sistemu.
ZIP-arhiv se šalje u direktorijum za sastavljanje RPM paketa. Zatim Bash skripta inicijalizuje promenljive okruženja, pronalazi verziju Build-a, verziju projekta, putanju do direktorijuma za sastavljanje, i pokreće RPM-build. Po završetku sastavljanja paket se objavljuje u lokalnom repozitoriju, koji se nalazi na Build-agentu.
Zatim, sa Build-agenta na server u RPM-repozitorij šalje se JSON-upit sa označenim imenom verzije i build-a. Webhook, o kojem sam ranije pričao, preuzima ovaj paket iz lokalnog repozitorija na Build-agentu i čini novu verziju dostupnom za instalaciju.
Zašto je ovakav sistem dostave paketa u RPM repozitorij? Zašto se ne može odmah poslati sastavljeni paket u repozitorij? Poenta je u tome što su to uslovi za obezbeđivanje sigurnosti. Ovakav scenario ograničava mogućnost neovlašćenog postavljanja RPM paketa od strane nepoznatih osoba na server koji je dostupan svim Linux mašinama.
Versioniranje Baze Podataka
Na konsultacijama sa razvojem otkriveno je da su programerima bliži MS SQL, ali u većini non-Windows projekata već smo koristili PostgreSQL. Pošto smo već odlučili da se odreknemo svega plaćenog, počeli smo da koristimo PostgreSQL i ovde.
U ovom dijelu želim objasniti kako smo provodili verzioniranje baze podataka i kako smo birali između Flyway-a i Entity Framework Core-a. Razmotrite njihove prednosti i nedostatke.
Nedostaci
Flyway ide samo u jednom smjeru, ne možemo se vratiti natrag — to je značajan nedostatak. Uspoređivati s Entity Framework Core-om možemo po drugim parametrima — s gledišta pogodnosti za programere. Pamtite, to smo stavili na prvo mjesto, a osnovni kriterij je bio ne mijenjati ništa za Windows-razvoj.
Za Flyway nam trebala neka omotnica, kako dečki ne bi pisali SQL upite. Njima je mnogo bliže manipulirati terminima OOP-a. Napisali smo upute za rad s objektima baze podataka, generiran je SQL upit i izvršen. Nova verzija baze podataka je spremna, prošla je testiranje — sve radi, sve je dobro.
Entity Framework Core ima nedostatak — pri velikim opterećenjima on izgrađuje neoptimalne SQL upite, a opterećenje baze podataka može biti značajno. No kako imamo nezahtevnu uslugu, ne računamo opterećenje u stotinama RPS, prihvatili smo te rizike i delegirali problem budućim nama.
Prednosti
Entity Framework Core radi iz kutije i pogodan je za razvoj, dok se Flyway lako integriše u postojeći CI. No, radimo to da bismo olakšali programerima :)
Postupak implementacije
Puppet vidi da dolazi do promjene verzije paketa među kojima je i onaj koji odgovara za migraciju. Prvo instalira paket koji sadrži migracijske skripte i funkcionalnosti vezane uz bazu podataka. Nakon toga se restartuje aplikacija koja koristi bazu podataka. Slijedi instalacija preostalih komponenti. Redoslijed instalacije paketa i pokretanja aplikacija opisan je u manifestu Puppet-a.
Aplikacije koriste osjetljive podatke, kao što su tokeni, lozinke za bazu podataka, sve to se povlači u konfiguraciju s Puppet master-om, gdje se čuvaju u šifriranom obliku.
Problemi TFS-a
Nakon što smo se definirali i shvatili da nam sve zapravo funkcionira, odlučio sam pogledati što se događa sa sastavnicama u TFS-u u cjelini za odjel Win-razvoja za druge projekte — brzo li se sastavljamo/objavljujemo, i otkrio značajne probleme sa brzinom.
Jedan od glavnih projekata sastavlja se 12-15 minuta — to je dugo, tako se ne može živjeti. Brza analiza pokazala je strašno opterećenje po I/O, i to na masivima.
Analizirajući per komponentu, izvojio sam tri žarišta. Prvo — «Kaspersky antivirus», koji na svim Windows Build agentima skenira izvore. Drugi — Windows Indexer. Nije bio isključen, a na Build agentima se u realnom vremenu indeksiralo sve u procesu deploya.
Treći — Npm install. Ispostavilo se da smo u većini Pipelines koristili upravo ovaj scenarij. Što je loše u tome? Procedura Npm install pokreće se prilikom formiranja stabla zavisnosti u package-lock.json, gdje se bilježe verzije paketa koji će se koristiti za izgradnju projekta. Minus u tome je što Npm install svaki put povlači aktuelne verzije paketa sa interneta, a to oduzima značajno vreme u slučaju velikog projekta.
Programeri ponekad eksperimentišu na lokalnom računaru kako bi proverili rad pojedinog dela ili projekta u celini. Ponekad se ispostavi da je sve dobro lokalno, ali prilikom izgradnje i deploya — ništa ne radi. Počinjemo da istražujemo u čemu je problem — aha, različite verzije paketa sa zavisnostima.
Rešenje
- Izvori u isključenja AV.
- Isključivanje indeksacije.
- Prelazak na npm ci.
Prednosti npm ci su u tome što stvaramo stablo zavisnosti jedini put, i dobijamo mogućnost da obezbedimo programeru aktuelnu listu paketa, s kojom može koliko god želi eksperimentisati lokalno. To štedi vreme programerima koji pišu kod.
Konfiguracija
Sada malo o konfiguraciji repozitorijuma. Istorijski, koristimo Nexus za upravljanje repozitorijumima, uključujući Internal REPO. U ovu unutrašnju repozitoriju dolaze svi komponenti koje koristimo za unutrašnje potrebe, na primer, samoprojektovani monitoring.
Takođe koristimo NuGet, jer bolje kešira u poređenju sa drugim paket menadžerima.
Rezultat
Nakon što smo optimizovali Build agente, prosek vremena izgradnje smanjen je sa 12 minuta na 7.
Ako zbrojimo sve mašine koje bismo mogli koristiti za Windows, ali su prebačene na Linux u ovom projektu, uštedeli smo oko $10.000. I to samo za licence, a ako uzmemo u obzir troškove održavanja — više.
Planovi
Za sledeći kvartal planirali smo rad na optimizaciji isporuke koda.
Prelazak na prebuild Docker-image. TFS je sjajna stvar sa mnoštvom pluginova koji omogućavaju integraciju u Pipeline, uključujući i izgradnju po okidaču, recimo, Docker-imagea. Ovaj okidač želimo da napravimo za baš taj package-lock.json. Ako se iz bilo kojeg razloga promijeni sastav komponenti koji se koriste za izradu projekta - stvara se nova Docker slika. Ona se kasnije koristi za postavljanje kontejnera s izgrađenom aplikacijom. Trenutno to nema, ali planiramo preći na mikroservisnu arhitekturu u Kubernetesu, koja se aktivno razvija u našoj kompaniji i već dugo podržava produkcijska rješenja.
Sažetak
Pozivam sve da zaborave Windows, ali to nije zbog toga što ne znam kako je pripremiti. Razlog je taj što je velika većina opensource rješenja - to je Linux stack. Uštedjet ćete na resursima . Po mom mišljenju, budućnost pripada Open Source rješenjima na Linuxu s jakom zajednicom.Profil govornika Aleksandra Sinčinova
na GitHubu .
DevOps Conf na RIT++ podnijeti izlaganje rezervirati „Glazba pulsara”, ili Kako zvuče brzo rotirajuće neutronske zvijezde
Izvor: habr.com
