Razvili smo DevOps najbolje što smo mogli. Bilo nas je 8, a Vasya je bio najcool na Windowsima. Odjednom je Vasya otišao, a ja sam imao zadatak pokrenuti novi projekt koji je osigurao Windows development. Kad sam bacio cijeli razvojni paket Windowsa na stol, 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 tvrtku, Alexander se pitao što sada učiniti. Prijeđite na Linux, naravno! Alexander će vam ispričati kako je uspio stvoriti presedan i prenijeti dio razvoja Windowsa na Linux na primjeru završenog projekta za 100 krajnjih korisnika.
Kako jednostavno i bez napora isporučiti projekt u RPM koristeći TFS, Puppet, Linux .NET core? Kako podržati verzioniranje baze podataka projekta ako razvojni tim 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 smoothie u korist Puppeta i Linuxa? Kako riješiti ideološke sukobe ako nema ni snage, ni želje, ni sredstava za održavanje Windowsa u proizvodnji? O tome, kao i o Web Deployu, testiranju, CI-ju, o praksi korištenja TFS-a u postojećim projektima, i, naravno, o pokvarenim štakama i radnim rješenjima, u Alexanderovom izvješću.
Dakle, Vasya je otišao, zadatak je na meni, programeri čekaju s vilama s nestrpljenjem. Kad sam konačno shvatio da se Vasja ne može vratiti, bacio sam se na posao. Za početak sam procijenio postotak Win VM-ova u našoj floti. Rezultat nije bio u korist Windowsa.
Budući da aktivno razvijamo DevOps, shvatio sam da treba nešto promijeniti u pristupu pokretanja nove aplikacije. Postojalo je samo jedno rješenje - ako je moguće, prebaciti sve na Linux. Google mi je pomogao - tada je .Net već bio portiran na Linux, i shvatio sam da je to rješenje!
Zašto je .NET Core u kombinaciji s Linuxom?
Za to je bilo više razloga. Između “plati novac” i “ne plati”, većina će izabrati ovo drugo - kao ja. Licenca za MSDB košta oko 1 dolara; održavanje flote Windows virtualnih strojeva košta stotine dolara. Za veliko poduzeće to je veliki trošak. Zato štednja - prvi razlog. Ne najvažniji, ali jedan od najznačajnijih.
Windows virtualni strojevi zauzimaju više resursa od svoje Linux braće. teški su. S obzirom na veličinu velike tvrtke, odabrali smo Linux.
Sustav se jednostavno integrira u postojeći CI. Smatramo se progresivnim DevOpsom, koristimo Bamboo, Jenkins i GitLab CI, tako da većina našeg rada radi na Linuxu.
Posljednji razlog je zgodna pratnja. Morali smo smanjiti barijeru za ulazak "pratitelja" - dečki koji razumiju tehnički dio, osiguravaju nesmetanu uslugu i održavaju usluge s druge linije. Već su bili upoznati s Linux stackom, pa im je puno lakše razumjeti, podržati i održavati novi proizvod nego trošiti dodatne resurse na razumijevanje sličnih funkcija softvera za Windows platformu.
Zahtjevi
Prva i najvažnija stvar je praktičnost novog rješenja za programere. Nisu svi bili spremni na promjene, pogotovo nakon što je izgovorena riječ Linux. Programeri žele svoj omiljeni Visual Studio, TFS s automatskim testovima za sklopove i smoothije. Nije im važno kako će doći do isporuke u proizvodnju. Stoga smo odlučili ne mijenjati uobičajeni proces i ostaviti sve nepromijenjeno za Windows razvoj.
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 Windowsa tada radio?
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 HP c ESXi na VMware. Svi su upoznati s klasicima žanra.
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.
Prije su to bili čvrsti prozori. TFS je koristio nekoliko Build agenata, na kojima su sklopljeni mnogi projekti. Svaki agent ima 3-4 radnika za paralelizaciju zadataka i optimizaciju procesa. Zatim je, prema planovima za izdavanje, TFS isporučio novopečenu Build na Windows aplikacijski poslužitelj.
Ono što smo htjeli postići
Koristimo TFS za isporuku i razvoj, a aplikaciju pokrećemo na Linux aplikacijskom poslužitelju i između njih postoji neka magija. Ovaj Č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.
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 izgradi na Linuxu. Backend je u interakciji s bazom podataka, učitava potrebnu listu privilegija i potom, ovisno o tome koje privilegije ima ovlašteni korisnik, omogućuje pristup potpisivanju financijskih dokumenata i slanju istih na izvršenje ili generiranju neke vrste 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.
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 - Magic Box. Već razumijemo da se sigurno krećemo prema Linuxu. Formulirajmo konkretne zadatke koji su zahtijevali rješenja.
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 razumiju da u Linuxu ne možete bez njega, ali sam projekt, nakon montaže, bio je skup izvršnih DLL datoteka. Bilo ih je oko 150, projekt je bio dosta težak. Jedino skladno rješenje je upakirati ovu binarnu datoteku u RPM i implementirati aplikaciju iz nje.
Verziranje. Morali smo izdavati vrlo često i morali smo odlučiti kako formirati naziv paketa. Ovo je pitanje razine integracije s TFS-om. Imali smo agenta za izgradnju na Linuxu. Kada TFS pošalje zadatak rukovatelju - radniku - Build agentu, prosljeđuje mu i hrpu varijabli koje spadaju u okruženje procesa rukovatelja. Ove varijable okruženja sadrže naziv međuverzije, naziv verzije i druge varijable. Pročitajte više o tome u odjeljku "Izrada RPM paketa".
Postavljanje TFS-a sveo na postavljanje Pipelinea. Prethodno smo sastavljali sve Windows projekte na Windows agentima, ali sada se pojavljuje Linux agent - Build agent, koji treba biti uključen u grupu za izgradnju, obogaćen nekim artefaktima i reći koji tip projekata će se sastavljati na ovom Build agentu , i nekako modificirati cjevovod.
IdentityServer. ADFS nije naš način, mi smo za Open Source.
Prođimo kroz komponente.
Čarobna kutija
Sastoji se od četiri dijela.
Linux Build agent. Linux, jer mi gradimo za njega - to je logično. Ovaj dio je rađ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 trebalo je negdje pohraniti. Pretpostavljalo se da ćemo koristiti isto korporativno RPM spremište koje je dostupno svim Linux hostovima. I tako su 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. Pažnja! GitLab ovdje ne koriste programeri, već operativni odjel za kontrolu verzija aplikacija, verzija paketa, praćenje stanja svih Linux strojeva 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.
Nakon čega TFS vidi da je stigao novi commit. Koja aplikacija? U postavkama TFS-a postoji oznaka koja pokazuje koje resurse ima određeni Build agent. U ovom slučaju, on vidi da gradimo .NET Core projekt i odabire Linux Build agenta iz skupa.
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.
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.
Zašto baš ova shema za isporuku paketa u RPM repozitorij? Zašto ne mogu odmah poslati sastavljeni paket u repozitorij? Poanta je da je to uvjet za sigurnost. Ovaj scenarij ograničava mogućnost da neovlašteni ljudi učitaju RPM pakete na poslužitelj koji je dostupan svim Linux strojevima.
Verzija baze podataka
Na konzultacijama s razvojnim timom pokazalo se da je dečkima bliži MS SQL, ali u većini ne-Windows projekata već smo svom snagom koristili PostgreSQL. Budući da smo već bili odlučili napustiti sve što se plaća, i ovdje smo počeli koristiti PostgreSQL.
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žete ga usporediti s Entity Framework Core na druge načine - sa stajališta pogodnosti za programere. Sjećate se da smo to stavili u prvi plan, a glavni kriterij je bio ne mijenjati ništa za Windows razvoj.
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", koji skenira izvore na svim Windows Build agentima. drugo - 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.
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 računamo sve strojeve koje smo mogli koristiti za Windowse, a prešli smo na Linux u ovom projektu, uštedjeli smo oko 10 000 dolara, i to samo na licencama, a ako uzmemo u obzir sadržaj i 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
Potičem sve da bace Windowse, ali nije zato što ih ja ne znam kuhati. Razlog je što većina Opensource rješenja jest Linux stog. Jesi li dobro? uštedjeti na resursima. Po mom mišljenju, budućnost leži u Open Source rješenjima na Linuxu s moćnom zajednicom.
Profil govornika Aleksandra Sinčinova .
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 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 ili odvojite vrijeme ulaznica. Upoznajte nas u Skolkovu!
Izvor: www.habr.com