Avemu sviluppatu DevOps cum'è megliu pudemu. Eramu 8 di noi, è Vasya era u più cool in Windows. Improvvisamente Vasya partì, è aghju avutu u compitu di lanciari un novu prughjettu chì era furnitu da u sviluppu di Windows. Quandu aghju scaricatu tutta a pila di sviluppu di Windows nantu à a tavula, aghju realizatu chì a situazione era un dolore ...
Hè cusì chì a storia principia Alexandra Sinchinova nantu . Quandu u primu specialista di Windows abbandunò a cumpagnia, Alexander si dumandava chì fà avà. Cambia à Linux, sicuru! Alexander vi dicerà cumu hà sappiutu di creà un precedente è trasfiriri una parte di u sviluppu di Windows à Linux utilizendu l'esempiu di un prughjettu finitu per 100 000 utenti finali.
Cumu furnisce facilmente è senza sforzu un prughjettu à RPM utilizendu TFS, Puppet, Linux .NET core? Cumu sustene a versione di una basa di dati di u prughjettu se u squadra di sviluppu sente e parolle Postgres è Flyway per a prima volta, è a scadenza hè dopu dumani? Cumu integrà cù Docker? Cumu motivà i sviluppatori .NET per abbandunà Windows è smoothies in favore di Puppet è Linux? Cumu risolve i cunflitti ideologichi s'ellu ùn ci hè nè a forza, nè u desideriu, nè e risorse per mantene Windows in produzzione? Circa issu, oltri ca comu circa Web Deploy, testing, CI, circa i pratichi di usu TFS in prughjetti esistenti, è, sicuru, circa crutches rottu è suluzioni di travagliu, in a trascrizione di u rapportu di Alexander.
Allora, Vasya si n'andò, u compitu hè nantu à mè, i sviluppatori aspettanu impazienti cù pitchforks. Quandu aghju realizatu infine chì Vasya ùn pudia micca esse tornatu, aghju pigliatu l'affari. Per cumincià, aghju valutatu u percentuale di Win VMs in a nostra flotta. A partitura ùn era micca in favore di Windows.
Siccomu sviluppemu attivamente DevOps, aghju capitu chì qualcosa deve esse cambiatu in l'approcciu di furnisce una nova applicazione. Ci era solu una solu suluzione - se pussibule, trasferisce tuttu à Linux. Google m'hà aiutatu - à quellu tempu .Net era digià statu purtatu à Linux, è aghju realizatu chì questa era a suluzione!
Perchè .NET core in cunghjunzione cù Linux?
Ci era parechje ragioni per questu. Trà "paga soldi" è "micca pagà", a maiuranza sceglie u sicondu - cum'è mè. Una licenza per MSDB costa circa $ 1; mantene una flotta di macchine virtuali Windows costa centinaie di dollari. Per una grande cumpagnia, questu hè un grande spesa. Hè perchè saving - prima ragione. Ùn hè micca u più impurtante, ma unu di i più impurtanti.
E macchine virtuali Windows occupanu più risorse cà i so fratelli Linux - sò pisanti. Data a scala di a grande cumpagnia, avemu sceltu Linux.
U sistema hè solu integratu in CI esistenti. Ci cunsideremu DevOps progressivi, usemu Bamboo, Jenkins è GitLab CI, cusì a maiò parte di u nostru travagliu funziona in Linux.
L'ultimu mutivu hè accumpagnamentu convenientu. Avemu bisognu di calà a barriera à l'ingressu per "scorts" - i picciotti chì capiscenu a parte tecnica, assicuranu un serviziu senza interruzzione è mantene i servizii da a seconda linea. Eranu digià familiarizati cù a pila Linux, cusì hè assai più faciule per elli à capisce, sustene è mantene un novu pruduttu cà di spende risorse supplementari per capiscenu a stessa funziunalità di u software per a piattaforma Windows.
esigenze
Prima di tuttu - comodità di a nova suluzione per i sviluppatori. Ùn sò micca tutti pronti per u cambiamentu, soprattuttu dopu chì a parolla Linux hè stata parlata. I sviluppatori volenu u so Visual Studio preferitu, TFS cù autotest per assemblee è smoothies. Cumu a consegna à a produzzione ùn hè micca impurtante per elli. Dunque, avemu decisu di ùn cambià u prucessu abituale è di lascià tuttu invariatu per u sviluppu di Windows.
Un novu prughjettu necessariu integrà in CI esistenti. I rails eranu digià quì è tuttu u travagliu deve esse fattu tenendu in contu i paràmetri di u sistema di gestione di cunfigurazione, i normi di consegna accettati è i sistemi di surviglianza.
Facilità di sustegnu è operazione, cum'è una cundizione per u limitu minimu di ingressu per tutti i novi participanti da e diverse divisioni è u dipartimentu di supportu.
Terminu - ieri.
Win Group Development
Chì era a squadra di Windows chì travaglia allora?
Avà possu cunfidenza dì chì IdentityServer 4 hè una alternativa gratuita fresca à ADFS cù capacità simili, o chì Entity Framework Core - un paradisu per un sviluppatore, induve ùn avete micca bisognu di scrive script SQL, ma descrive e dumande in a basa di dati in termini OOP. Ma dopu, durante a discussione di u pianu d'azzione, aghju guardatu sta pila cum'è s'ellu era cuneiforme sumericu, ricunnoscendu solu PostgreSQL è Git.
À quellu tempu avemu usatu attivamente Puppet cum'è un sistema di gestione di cunfigurazione. In a maiò parte di i nostri prughjetti avemu usatu GitLab CI, elastica, servizii equilibrati high-load usu HAProxy monitoratu tuttu cù Zabbix, ligamenti Grafana и Prometheus, Jaeger, è tuttu chistu girava nantu à pezzi di ferru HP c ESXi nantu Panda. Tuttu u mondu sapi - un classicu di u generu.
Fighjemu è pruvemu à capisce ciò chì succede prima di principià tutte ste intervenzioni.
Chì hè accadutu
TFS hè un sistema abbastanza putente chì ùn solu furnisce u codice da u sviluppatore à a macchina di produzzione finale, ma hà ancu un set per una integrazione assai flexible cù diversi servizii - per furnisce CI à un livellu multipiattaforma.
Prima, questi eranu finestri solidi. TFS hà utilizatu parechji agenti Build, chì sò stati usati per assemblà parechji prughjetti. Ogni agentu hà 3-4 travagliadori per parallelizà i travaglii è ottimisà u prucessu. Dopu, secondu i piani di liberazione, TFS hà consegnatu u Build appena cottu à u servitore di l'applicazioni Windows.
Chì vulemu ghjunghje ?
Avemu aduprà TFS per a consegna è u sviluppu, è eseguite l'applicazione nantu à un servitore di Applicazioni Linux, è ci hè una sorta di magia trà elli. Questu Scatula magica è ci hè u sali di u travagliu avanti. Prima di smontallu, aghju da fà un passu da latu è dicu uni pochi di parolle nantu à l'applicazione.
U prugettu
L'applicazione furnisce funziunalità per a gestione di carte prepagate.
Client
Ci era dui tipi di utilizatori. U primu hà acquistatu accessu accedendu cù un certificatu SSL SHA-2. U u sicondu ci era accessu cù un login è password.
HAProxy
Allora a dumanda di u cliente hè andata à HAProxy, chì risolve i seguenti prublemi:
- l'autorizazione primaria;
- terminazione SSL;
- sintonizza e dumande HTTP;
- richieste di trasmissione.
U certificatu di u cliente hè statu verificatu longu a catena. noi - auturità è pudemu permette questu, postu chì noi stessi emettemu certificati à i clienti di serviziu.
Attenti à u terzu puntu, avemu da vultà à questu un pocu dopu.
Backend
Anu pianificatu di fà u backend in Linux. U backend interagisce cù a basa di dati, carica a lista necessaria di privileggi è dopu, sicondu i privilegi chì l'utilizatori auturizati hà, furnisce l'accessu per firmà documenti finanziarii è mandà per l'esekzione, o generà un tipu di rapportu.
Risparmi cù HAProxy
In più di i dui cuntesti chì ogni cliente hà navigatu, ci era ancu un cuntestu identitariu. IdentityServer 4 permette solu di login, questu hè un analogu gratuitu è putente per ADFS - Servizi di Federazione Active Directory.
A dumanda d'identità hè stata trattata in parechji passi. primu passu - cliente entra in u backend, chì hà cumunicatu cù stu servitore è verificatu a presenza di un token per u cliente. S'ellu ùn hè micca truvatu, a dumanda hè stata tornata à u cuntestu da quale hè vinutu, ma cù una redirezzione, è cù a redirezzione andò à l'identità.
Secondu passu - a dumanda hè stata ricevuta à a pagina d'autorizazione in IdentityServer, induve u cliente hà registratu, è quellu token longu aspittatu apparsu in a basa di dati IdentityServer.
Terzu passu - u cliente hè statu reindirizzatu à u cuntestu da quale hè vinutu.
IdentityServer4 hà una funzione: torna a risposta à a dumanda di ritornu via HTTP. Ùn importa micca quantu avemu luttatu cù a stallazione di u servitore, ùn importa micca quantu avemu illuminatu cù a ducumentazione, ogni volta avemu ricevutu una dumanda iniziale di u cliente cù un URL chì vene via HTTPS, è IdentityServer hà tornatu u stessu cuntestu, ma cù HTTP. Eramu scunfitti ! E avemu trasfirutu tuttu questu attraversu u cuntestu d'identità à HAProxy, è in l'intestazione avemu avutu à mudificà u protocolu HTTP à HTTPS.
Chì hè a migliione è induve avete salvatu?
Avemu risparmiatu soldi usendu una suluzione libera per auturizà un gruppu di utilizatori, risorse, postu chì ùn avemu micca piazzatu IdentityServer4 cum'è un node separatu in un segmentu separatu, ma l'utilizamu inseme cù u backend in u stessu servitore induve u backend di l'applicazione corre. .
Cumu si deve travaglià
Allora, cum'è aghju prumessu - Magic Box. Avemu digià capitu chì simu garantiti per andà versu Linux. Formulemu compiti specifichi chì necessitanu suluzioni.
Puppet manifesta. Per furnisce è gestisce a cunfigurazione di u serviziu è di l'applicazioni, ricette cool anu da esse scritte. Un rotulu di lapis mostra eloquently quantu rapidu è efficace hè stata fatta.
Metudu di consegna. U standard hè RPM. Tutti capiscenu chì in Linux ùn pudete micca fà senza, ma u prughjettu stessu, dopu à l'assemblea, era un inseme di schedarii DLL eseguibili. Ci era circa 150 di elli, u prugettu era abbastanza difficiule. L'unica suluzione armoniosa hè di imballà stu binariu in RPM è implementà l'applicazione da ellu.
Versioning. Avemu avutu à liberà assai spessu, è avemu avutu a decide cumu furmà u nome di u pacchettu. Questa hè una quistione di u livellu di integrazione cù TFS. Avemu avutu un agente di custruzzione in Linux. Quandu TFS manda un compitu à un gestore - travagliadore - à l'agente di Build, passa ancu una mansa di variàbili chì finiscinu in l'ambiente di u prucessu di gestione. Queste variabili di l'ambiente cuntenenu u nome di Custruzzione, u nome di a versione è altre variàbili. Leghjite più nantu à questu in a sezione "Custruisce un pacchettu RPM".
Configurazione di TFS hè vinutu à creà Pipeline. Nanzu, avemu cullatu tutti i prughjetti di Windows nantu à l'agenti Windows, ma avà appare un agentu Linux - un agentu di custruzzione, chì deve esse inclusu in u gruppu di custruzzione, arricchitu cù qualchi artefatti, è hà dettu chì tipu di prughjetti seranu custruiti nantu à questu agentu di custruzzione. , è in qualchì modu mudificà u Pipeline.
IdentityServer. ADFS ùn hè micca u nostru modu, andemu per Open Source.
Andemu à traversu i cumpunenti.
Scatula magica
Hè custituitu di quattru parti.
Agente Linux Build. Linux, perchè custruemu per questu - hè logicu. Sta parte hè stata fatta in trè passi.
- Configurate i travagliadori è micca solu, postu chì u travagliu distribuitu nantu à u prugettu era previstu.
- Installa .NET Core 1.x. Perchè 1.x quandu 2.0 hè digià dispunibule in u repositoriu standard? Perchè quandu avemu principiatu u sviluppu, a versione stabile era 1.09, è hè statu decisu di fà u prugettu basatu annantu à questu.
- Git 2.x.
Repository RPM. I pacchetti RPM anu da esse guardatu in qualchì locu. Hè stata presunta chì avemu aduprà u stessu repository RPM corporativu chì hè dispunibule per tutti l'ospiti Linux. Hè ciò chì anu fattu. U servitore di repository hè cunfiguratu webhook chì hà scaricatu u pacchettu RPM necessariu da u locu specificatu. A versione di u pacchettu hè stata informata à u webhook da l'agente Build.
GitLab. Attenzione ! GitLab quì hè adupratu micca da i sviluppatori, ma da u dipartimentu di l'operazioni per cuntrullà e versioni di l'applicazioni, versioni di pacchetti, monitorizà u statutu di tutte e macchine Linux, è guarda a ricetta - tutti i manifesti Puppet.
Puppet - risolve tutti i prublemi cuntruversi è furnisce esattamente a cunfigurazione chì vulemu da Gitlab.
Cuminciamu à immerse. Cumu funziona a consegna DLL à RPM?
Consegna DDL à RPM
Dicemu chì avemu una stella di roccia di sviluppu .NET. Utiliza Visual Studio è crea un ramu di liberazione. Dopu quì, u carica in Git, è Git quì hè una entità TFS, vale à dì, hè u repositoriu di l'applicazioni cù quale u sviluppatore travaglia.
Dopu chì TFS vede chì un novu impegnu hè ghjuntu. Quale app? In i paràmetri di TFS ci hè una etichetta chì indica quale risorse hà un agentu Build particulare. In questu casu, vede chì avemu custruitu un prughjettu .NET Core è selezziunate un agentu Linux Build da a piscina.
L'agente Build riceve e fonti è scaricate u necessariu dependenziali da u repository .NET, npm, etc. è dopu avè custruitu l'applicazione stessa è l'imballazione sussegwente, manda u pacchettu RPM à u repository RPM.
Per d 'altra banda, i seguenti succede. L'ingegnere di u dipartimentu di l'operazioni hè direttamente implicatu in u rollout di u prugettu: cambia e versioni di i pacchetti in Hiera in u repository induve a ricetta di l'applicazione hè guardata, dopu chì Puppet attiva Yum, piglia u novu pacchettu da u repository, è a nova versione di l'applicazione hè pronta à aduprà.
Tuttu hè simplice in parolle, ma chì succede in l'agente Build stessu?
Packaging DLL RPM
Ricevutu fonti di prughjettu è custruisce compitu da TFS. Agente di custruzzione principia à custruisce u prughjettu stessu da e fonti. U prughjettu assemblatu hè dispunibule cum'è un set i schedari DLL, chì sò imballati in un archiviu zip per riduce a carica nantu à u sistema di fugliale.
L'archiviu ZIP hè ghjittatu à u cartulare di creazione di u pacchettu RPM. In seguitu, u script Bash inizializza e variabili di l'ambiente, trova a versione Build, a versione di prughjettu, u percorsu à u cartulare di custruzzione, è eseguisce RPM-build. Una volta chì a custruzione hè cumpleta, u pacchettu hè publicatu à repository locale, chì si trova nantu à l'agente Build.
In seguitu, da l'agente Build à u servitore in u repository RPM A dumanda JSON hè mandata indicà u nome di a versione è custruisce. Webhook, di quale aghju parlatu prima, scarica stu pacchettu da u repositoriu lucale nantu à l'agente di Build è rende a nova assemblea dispunibule per a stallazione.
Perchè stu schema di consegna di pacchettu particulare à u repositoriu RPM? Perchè ùn possu micca mandà immediatamente u pacchettu assemblatu à u repository? U fattu hè chì questu hè una cundizione per assicurà a sicurità. Stu scenariu limita a pussibilità di e persone micca autorizate chì caricanu pacchetti RPM à un servitore accessibile à tutte e macchine Linux.
Versione di basa di dati
In una cunsultazione cù u gruppu di sviluppu, hè risultatu chì i picciotti eranu più vicinu à MS SQL, ma in a maiò parte di i prughjetti chì ùn sò micca Windows avemu digià utilizatu PostgreSQL cù tutte e so putenza. Siccomu avemu digià decisu di abbandunà tuttu ciò chì hè pagatu, avemu cuminciatu à aduprà PostgreSQL ancu quì.
In questa parte, vogliu dicu cumu avemu versionatu a basa di dati è cumu avemu sceltu trà Flyway è Entity Framework Core. Fighjemu i so pro è i contra.
Минусы
Flyway và solu in un modu, noi ùn pudemu micca retrocede - questu hè un svantaghju significativu. Pudete paragunà cù Entity Framework Core in altri modi - in termini di cunvenzione di u sviluppatore. Ricurdativi chì avemu messu questu in prima linea, è u criteriu principale ùn era micca cambià nunda per u sviluppu di Windows.
Per noi Flyway era necessariu un tipu di wrapperper chì i picciotti ùn scrivenu micca dumande SQL. Sò assai più vicinu à operare in termini OOP. Avemu scrittu struzzioni per travaglià cù l'oggetti di basa di dati, generatu una dumanda SQL è eseguitu. A nova versione di a basa di dati hè pronta, pruvata - tuttu hè bè, tuttu funziona.
Entity Framework Core hà un minus - sottu carichi pesanti crea queries SQL subottimali, è u drawdown in a basa di dati pò esse significativu. Ma postu chì ùn avemu micca un serviziu d'alta carica, ùn avemu micca calculatu a carica in centinaie di RPS, avemu accettatu questi risichi è delegate u prublema à noi futuri.
Плюсы
Entity Framework Core funziona fora di a scatula è hè faciule da sviluppà, è Flyway Si integra facilmente in CI esistenti. Ma facemu cunvene per i sviluppatori :)
Prucedura di roll-up
Puppet vede chì un cambiamentu in a versione di u pacchettu vene, cumpresu quellu chì hè rispunsevule per a migrazione. Prima, stalla un pacchettu chì cuntene script di migrazione è funziunalità di basa di dati. Dopu questu, l'applicazione chì travaglia cù a basa di dati hè riavviata. Dopu vene a stallazione di i cumpunenti rimanenti. L'ordine in quale i pacchetti sò installati è l'applicazioni sò lanciate hè descrittu in u manifestu Puppet.
L'applicazioni utilizanu dati sensittivi, cum'è tokens, password di basa di dati, tuttu questu hè tiratu in a cunfigurazione da Puppet master, induve sò almacenati in forma criptata.
prublemi TFS
Dopu avemu decisu è capitu chì tuttu funzionava veramente per noi, aghju decisu di guardà ciò chì passava cù l'assemblee in TFS in tuttu per u dipartimentu di sviluppu di Win in altri prughjetti - s'ellu eramu custruendu / liberatu rapidamente o micca, è scupertu prublemi impurtanti cù a velocità.
Unu di i prughjetti principali pigghia 12-15 minuti per assemblà - hè assai tempu, ùn pudete micca campà cusì. Un analisi rapidu hà dimustratu un terribile drawdown in I / O, è questu era in arrays.
Dopu l'analizà cumpunente per cumpunente, aghju identificatu trè foci. Primu - "Kaspersky antivirus", chì scansa e fonti nantu à tutti l'agenti di Windows Build. Sicondu - Windows Indicizzatore. Ùn era micca disattivatu, è tuttu era indiziatu in tempu reale nantu à l'agenti di Custruzzione durante u prucessu di implementazione.
Terzu - Installa Npm. Hè risultatu chì in a maiò parte di Pipelines avemu usatu stu scenariu esatta. Perchè hè male ? A prucedura di installazione di Npm hè eseguita quandu l'arbre di dipendenza hè furmatu package-lock.json, induve e versioni di pacchetti chì seranu utilizati per custruisce u prugettu sò registrati. U svantaghju hè chì l'installazione di Npm tira l'ultime versioni di pacchetti da Internet ogni volta, è questu piglia assai tempu in u casu di un grande prughjettu.
I sviluppatori à volte sperimentanu in una macchina lucale per pruvà cumu funziona una parte particulare o un prughjettu tutale. Calchì volta era chì tuttu era frescu in u locu, ma l'anu assemblatu, u rollu fora, è nunda hà travagliatu. Cuminciamu à capisce quale hè u prublema - sì, diverse versioni di pacchetti cù dipendenze.
dicisioni
- Fonti in eccezzioni AV.
- Disattiva l'indexazione.
- Andà à npm ci.
I vantaghji di npm ci sò chì noi Cullemu l'arbre di dependenza una volta, è avemu l'uppurtunità di furnisce u sviluppatore lista attuale di pacchetti, cù quale ellu pò sperimentà in u locu quantu li piace. Questu risparmia u tempu sviluppatori chì scrivenu codice.
Cunfigurazione
Avà un pocu nantu à a cunfigurazione di u repository. Stòricamente avemu usatu Nexus per a gestione di i repositori, cumprese REPO internu. Stu repositoriu internu cuntene tutti i cumpunenti chì avemu usatu per scopi internu, per esempiu, surviglianza auto-scritta.
Avemu ancu aduprà NuGet, postu chì hà una cache megliu cumparatu cù altri gestori di pacchetti.
risultatu
Dopu avè ottimizatu l'Agenti di Custruzzione, u tempu mediu di creazione hè statu riduttu da 12 minuti à 7.
Se cuntamu tutte e machini chì pudemu avè usatu per Windows, ma cambiatu à Linux in questu prughjettu, avemu salvatu circa $ 10 000. È questu hè solu nantu à licenze, è più si pigliamu in contu u cuntenutu.
Piani
Per u prossimu trimestre, avemu previstu di travaglià per ottimisà a consegna di codice.
Passendu à una maghjina di Docker prebuild. TFS hè una cosa fantastica cù parechji plugins chì permettenu di integrà in Pipeline, cumprese l'assemblea basata in trigger di, per dì, una maghjina Docker. Vulemu fà stu trigger per u listessu package-lock.json. Se a cumpusizioni di i cumpunenti utilizati per custruisce u prugettu cambia in qualchì modu, custruemu una nova maghjina Docker. Hè più tardi utilizatu per implementà u cuntinuu cù l'applicazione assemblata. Questu ùn hè micca u casu avà, ma avemu a pianificazione di cambià à una architettura di microserviziu in Kubernetes, chì si sviluppa attivamente in a nostra cumpagnia è chì serve suluzioni di produzzione per un bellu pezzu.
Resumen
Incuraghjite à tutti à scaccià Windows, ma ùn hè micca perchè ùn sò micca sapè cumu fà a cucina. U mutivu hè chì a maiò parte di e soluzioni Opensource sò pila Linux. sì d'accordu risparmià risorse. In u mo parè, u futuru appartene à e soluzioni Open Source in Linux cù una cumunità putente.
Profilu di parlante di Alexander Sinchinov .
hè una cunferenza nantu à l'integrazione di prucessi di sviluppu, teste è operazione per i prufessiunali da i prufessiunali. Hè per quessa u prughjettu chì Alexander hà parlatu? implementatu è travagliendu, è u ghjornu di u spettaculu ci sò stati dui versioni successi. On U 27 è 28 di maghju ci saranu ancu più casi simili da i praticanti. Pudete ancu saltà in l'ultimu carrughju è o pigliate u vostru tempu bigliettu. Incontraci in Skolkovo!
Source: www.habr.com