.NET Core ar Linux, DevOps ar gefn ceffyl

Fe wnaethom ddatblygu DevOps orau y gallem. Roedd 8 ohonom, a Vasya oedd y cŵl yn Windows. Yn sydyn gadawodd Vasya, a chefais y dasg o lansio prosiect newydd a ddarparwyd gan ddatblygiad Windows. Pan wnes i ddympio'r pentwr datblygu Windows cyfan ar y bwrdd, sylweddolais fod y sefyllfa'n boen ...

Dyma sut mae'r stori'n dechrau Alexandra Sinchinova ar DevOpsConf. Pan adawodd yr arbenigwr Windows blaenllaw y cwmni, roedd Alexander yn meddwl tybed beth i'w wneud nawr. Newid i Linux, wrth gwrs! Bydd Alexander yn dweud wrthych sut y llwyddodd i greu cynsail a throsglwyddo rhan o ddatblygiad Windows i Linux gan ddefnyddio'r enghraifft o brosiect gorffenedig ar gyfer 100 o ddefnyddwyr terfynol.

.NET Core ar Linux, DevOps ar gefn ceffyl

Sut i gyflwyno prosiect i RPM yn hawdd ac yn ddiymdrech gan ddefnyddio craidd TFS, Puppet, Linux .NET? Sut i gefnogi fersiwn o gronfa ddata prosiect os yw'r tîm datblygu yn clywed y geiriau Postgres a Flyway am y tro cyntaf, a'r dyddiad cau yw'r diwrnod ar ôl yfory? Sut i integreiddio â Docker? Sut i gymell datblygwyr .NET i gefnu ar Windows a smwddis o blaid Puppet a Linux? Sut i ddatrys gwrthdaro ideolegol os nad oes na'r cryfder, na'r awydd, na'r adnoddau i gynnal Windows wrth gynhyrchu? Ynglŷn â hyn, yn ogystal ag am Web Deploy, profi, CI, am yr arferion o ddefnyddio TFS mewn prosiectau sy'n bodoli eisoes, ac, wrth gwrs, am faglau toredig a datrysiadau gweithio, yn y trawsgrifiad o adroddiad Alexander.


Felly, gadawodd Vasya, mae'r dasg arnaf, mae'r datblygwyr yn aros yn ddiamynedd gyda pitchforks. Pan sylweddolais o'r diwedd na ellid dychwelyd Vasya, dechreuais fusnes. I ddechrau, asesais ganran y Win VMs yn ein fflyd. Nid oedd y sgôr o blaid Windows.

.NET Core ar Linux, DevOps ar gefn ceffyl

Gan ein bod wrthi'n datblygu DevOps, sylweddolais fod angen newid rhywbeth yn y dull o gyflwyno cais newydd. Dim ond un ateb oedd - os yn bosibl, trosglwyddwch bopeth i Linux. Helpodd Google fi - ar y pryd roedd .Net eisoes wedi'i borthi i Linux, a sylweddolais mai dyma'r ateb!

Pam craidd .NET ar y cyd â Linux?

Roedd sawl rheswm am hyn. Rhwng “pay money” a “not pay”, bydd y mwyafrif yn dewis yr ail – fel fi. Mae trwydded ar gyfer MSDB yn costio tua $1; mae cynnal fflyd o beiriannau rhithwir Windows yn costio cannoedd o ddoleri. I gwmni mawr mae hyn yn gost fawr. Dyna pam arbed - rheswm cyntaf. Nid y pwysicaf, ond un o'r rhai arwyddocaol.

Mae peiriannau rhithwir Windows yn cymryd mwy o adnoddau na'u brodyr Linux - maent yn drwm. O ystyried maint y cwmni mawr, dewisom Linux.

Yn syml, mae'r system wedi'i hintegreiddio i'r CI presennol. Rydym yn ystyried ein hunain yn DevOps blaengar, rydym yn defnyddio Bambŵ, Jenkins a GitLab CI, felly mae'r rhan fwyaf o'n gwaith yn rhedeg ar Linux.

Y rheswm olaf yw cyfeiliant cyfleus. Roedd angen i ni leihau'r rhwystr i fynediad i “hebryngwyr” - y dynion sy'n deall y rhan dechnegol, yn sicrhau gwasanaeth di-dor, ac yn cynnal gwasanaethau o'r ail linell. Roeddent eisoes yn gyfarwydd â stac Linux, felly mae'n llawer haws iddynt ddeall, cefnogi a chynnal cynnyrch newydd na gwario adnoddau ychwanegol i ddeall yr un ymarferoldeb meddalwedd ar gyfer platfform Windows.

Gofynion

Yn gyntaf ac yn bennaf - hwylustod yr ateb newydd i ddatblygwyr. Nid oedd pob un ohonynt yn barod am newid, yn enwedig ar ôl i'r gair Linux gael ei siarad. Mae datblygwyr eisiau eu hoff Stiwdio Weledol, TFS gyda phrofion awtomatig ar gyfer gwasanaethau a smwddis. Nid yw sut mae danfon i gynhyrchu yn digwydd yn bwysig iddynt. Felly, penderfynasom beidio â newid y broses arferol a gadael popeth heb ei newid ar gyfer datblygiad Windows.

Angen prosiect newydd integreiddio i CI presennol. Roedd y rheiliau yno eisoes ac roedd yn rhaid gwneud yr holl waith gan ystyried paramedrau'r system rheoli cyfluniad, safonau cyflenwi derbyniol a systemau monitro.

Rhwyddineb cefnogaeth a gweithrediad, fel amod ar gyfer y trothwy mynediad isaf ar gyfer yr holl gyfranogwyr newydd o wahanol adrannau a'r adran gymorth.

Dyddiad cau - ddoe.

Ennill Grŵp Datblygu

Gyda beth roedd tîm Windows yn gweithio bryd hynny?

.NET Core ar Linux, DevOps ar gefn ceffyl

Nawr gallaf ddweud hynny'n hyderus Gweinydd Hunaniaeth4 yn ddewis arall rhad ac am ddim cŵl i ADFS gyda galluoedd tebyg, neu beth Craidd y Fframwaith Endid - paradwys i ddatblygwr, lle nad oes rhaid i chi drafferthu ysgrifennu sgriptiau SQL, ond disgrifiwch ymholiadau yn y gronfa ddata yn nhermau OOP. Ond wedyn, yn ystod y drafodaeth ar y cynllun gweithredu, edrychais ar y pentwr hwn fel pe bai'n cuneiform Sumerian, gan gydnabod PostgreSQL a Git yn unig.

Ar y pryd roedden ni'n mynd ati i ddefnyddio pyped fel system rheoli cyfluniad. Yn y rhan fwyaf o'n prosiectau a ddefnyddiwyd gennym GitLab CI, Elastig, gwasanaethau uchel-llwyth cytbwys gan ddefnyddio HAProxy monitro popeth gyda Zabbix, gewynnau Grafana и Prometheus, Jaeger, ac roedd hyn i gyd yn nyddu ar ddarnau o haearn HPESXi ar VMware. Mae pawb yn ei wybod - clasur o'r genre.

.NET Core ar Linux, DevOps ar gefn ceffyl

Gadewch i ni edrych a cheisio deall beth ddigwyddodd cyn i ni ddechrau'r holl ymyriadau hyn.

Beth ddigwyddodd

Mae TFS yn system eithaf pwerus sydd nid yn unig yn darparu cod o'r datblygwr i'r peiriant cynhyrchu terfynol, ond mae ganddo hefyd set ar gyfer integreiddio hyblyg iawn gyda gwasanaethau amrywiol - i ddarparu CI ar lefel traws-lwyfan.

.NET Core ar Linux, DevOps ar gefn ceffyl
Yn flaenorol, ffenestri solet oedd y rhain. Defnyddiodd TFS nifer o asiantau Adeiladu, a ddefnyddiwyd i gydosod llawer o brosiectau. Mae gan bob asiant 3-4 o weithwyr i gyfochrog â thasgau a gwneud y gorau o'r broses. Yna, yn ôl cynlluniau rhyddhau, cyflwynodd TFS yr Adeilad wedi'i bobi'n ffres i weinydd cymwysiadau Windows.

Beth oeddem ni eisiau ei gyflawni?

Rydym yn defnyddio TFS ar gyfer cyflwyno a datblygu, ac yn rhedeg y cais ar weinydd Cais Linux, ac mae rhyw fath o hud rhyngddynt. hwn Blwch Hud ac y mae halen y gwaith o'i flaen. Cyn i mi ei dynnu ar wahân, byddaf yn cymryd cam o'r neilltu ac yn dweud ychydig eiriau am y cais.

Prosiect

Mae'r cymhwysiad yn darparu ymarferoldeb ar gyfer trin cardiau rhagdaledig.

.NET Core ar Linux, DevOps ar gefn ceffyl

Cwsmeriaid

Roedd dau fath o ddefnyddwyr. Cyntaf cael mynediad trwy fewngofnodi gan ddefnyddio tystysgrif SSL SHA-2. U o'r ail roedd mynediad gan ddefnyddio mewngofnodi a chyfrinair.

HAProxy

Yna aeth cais y cleient i HAProxy, a ddatrysodd y problemau canlynol:

  • awdurdodiad cynradd;
  • terfynu SSL;
  • tiwnio ceisiadau HTTP;
  • ceisiadau darlledu.

Dilyswyd tystysgrif y cleient ar hyd y gadwyn. Rydym - awdurdod a gallwn fforddio hyn, gan ein bod ni ein hunain yn rhoi tystysgrifau i gleientiaid gwasanaeth.

Rhowch sylw i'r trydydd pwynt, byddwn yn dychwelyd ato ychydig yn ddiweddarach.

Backend

Roeddent yn bwriadu gwneud y backend ar Linux. Mae'r backend yn rhyngweithio â'r gronfa ddata, yn llwytho'r rhestr angenrheidiol o freintiau ac yna, yn dibynnu ar ba freintiau sydd gan y defnyddiwr awdurdodedig, yn darparu mynediad i lofnodi dogfennau ariannol a'u hanfon i'w gweithredu, neu gynhyrchu rhyw fath o adroddiad.

Arbedion gyda HAProxy

Yn ogystal â'r ddau gyd-destun yr oedd pob cleient yn eu llywio, roedd cyd-destun hunaniaeth hefyd. Gweinydd Hunaniaeth4 dim ond yn caniatáu i chi fewngofnodi, mae hwn yn analog rhad ac am ddim a phwerus ar gyfer ADFS - Gwasanaethau Ffederasiwn Cyfeiriadur Gweithredol.

Cafodd y cais hunaniaeth ei brosesu mewn sawl cam. Cam cyntaf - cleient mynd i mewn i'r backend, a oedd yn cyfathrebu â'r gweinydd hwn ac yn gwirio presenoldeb tocyn ar gyfer y cleient. Os na ddaethpwyd o hyd iddo, dychwelwyd y cais yn ôl i'r cyd-destun y daeth ohono, ond gydag ailgyfeiriad, a chyda'r ailgyfeiriad aeth i hunaniaeth.

Ail gam - derbyniwyd y cais i'r dudalen awdurdodi yn IdentityServer, lle cofrestrodd y cleient, ac ymddangosodd y tocyn hir-ddisgwyliedig hwnnw yng nghronfa ddata IdentityServer.

Trydydd cam - cafodd y cleient ei ailgyfeirio yn ôl i'r cyd-destun y daeth ohono.

.NET Core ar Linux, DevOps ar gefn ceffyl

Mae gan IdentityServer4 nodwedd: mae'n dychwelyd yr ymateb i'r cais dychwelyd trwy HTTP. Ni waeth faint yr oeddem yn ei chael hi'n anodd sefydlu'r gweinydd, ni waeth faint y gwnaethom ein goleuo ein hunain gyda'r ddogfennaeth, bob tro cawsom gais cleient cychwynnol gydag URL a ddaeth trwy HTTPS, a dychwelodd IdentityServer yr un cyd-destun, ond gyda HTTP. Cawsom sioc! Ac fe wnaethom drosglwyddo hyn i gyd trwy'r cyd-destun hunaniaeth i HAProxy, ac yn y penawdau roedd yn rhaid i ni addasu'r protocol HTTP i HTTPS.

Beth yw'r gwelliant a ble wnaethoch chi arbed?

Fe wnaethom arbed arian trwy ddefnyddio datrysiad rhad ac am ddim ar gyfer awdurdodi grŵp o ddefnyddwyr, adnoddau, gan na wnaethom osod IdentityServer4 fel nod ar wahân mewn segment ar wahân, ond fe'i defnyddiwyd ynghyd â'r ôl-wyneb ar yr un gweinydd lle mae backend y rhaglen yn rhedeg .

Sut ddylai weithio

Felly, fel yr addewais - Magic Box. Rydym eisoes yn deall ein bod yn sicr o symud tuag at Linux. Gadewch i ni lunio tasgau penodol a oedd yn gofyn am atebion.

.NET Core ar Linux, DevOps ar gefn ceffyl

Mae pyped yn amlygu. Er mwyn cyflwyno a rheoli cyfluniad gwasanaeth a rhaglenni, roedd yn rhaid ysgrifennu ryseitiau cŵl. Mae rholyn o bensil yn huawdl yn dangos pa mor gyflym ac effeithlon y cafodd ei wneud.

Dull cyflwyno. Y safon yw RPM. Mae pawb yn deall na allwch chi wneud hebddo yn Linux, ond roedd y prosiect ei hun, ar ôl y cynulliad, yn set o ffeiliau DLL gweithredadwy. Roedd tua 150 ohonyn nhw, roedd y prosiect yn eithaf anodd. Yr unig ateb cytûn yw pecynnu'r deuaidd hwn yn RPM a defnyddio'r cymhwysiad ohono.

Fersiynu. Roedd yn rhaid i ni ryddhau yn aml iawn, ac roedd yn rhaid i ni benderfynu sut i ffurfio enw'r pecyn. Mae hwn yn gwestiwn o lefel yr integreiddio â TFS. Roedd gennym ni asiant adeiladu ar Linux. Pan fydd TFS yn anfon tasg at driniwr - gweithiwr - i'r asiant Adeiladu, mae hefyd yn ei drosglwyddo i griw o newidynnau sy'n dod i ben yn amgylchedd y broses triniwr. Mae'r newidynnau amgylchedd hyn yn cynnwys yr enw Adeiladu, enw'r fersiwn, a newidynnau eraill. Darllenwch fwy am hyn yn yr adran “Adeiladu pecyn RPM”.

Sefydlu TFS daeth i lawr i sefydlu Piblinell. Yn flaenorol, casglwyd yr holl brosiectau Windows ar asiantau Windows, ond nawr mae asiant Linux yn ymddangos - asiant Adeiladu, y mae angen ei gynnwys yn y grŵp adeiladu, wedi'i gyfoethogi â rhai arteffactau, a dywedwyd wrth ba fath o brosiectau fydd yn cael eu hadeiladu ar yr asiant Adeiladu hwn , a rhywsut addasu'r Piblinell.

Gweinydd Hunaniaeth. Nid ADFS yw ein ffordd ni, rydyn ni'n mynd am Ffynhonnell Agored.

Gadewch i ni fynd drwy'r cydrannau.

Blwch Hud

Mae'n cynnwys pedair rhan.

.NET Core ar Linux, DevOps ar gefn ceffyl

Asiant Linux Build. Linux, oherwydd rydyn ni'n adeiladu ar ei gyfer - mae'n rhesymegol. Gwnaed y rhan hon mewn tri cham.

  • Ffurfweddu gweithwyr ac nid yn unig, gan fod disgwyl gwaith dosranedig ar y prosiect.
  • Gosod .NET Core 1.x. Pam 1.x pan fydd 2.0 eisoes ar gael yn yr ystorfa safonol? Oherwydd pan ddechreuon ni ddatblygu, y fersiwn sefydlog oedd 1.09, a phenderfynwyd gwneud y prosiect yn seiliedig arno.
  • Git 2.x.

RPM-storfa. Roedd angen storio pecynnau RPM yn rhywle. Tybiwyd y byddem yn defnyddio'r un ystorfa RPM corfforaethol sydd ar gael i bob gwesteiwr Linux. Dyna beth wnaethon nhw. Mae gweinydd y gadwrfa wedi'i ffurfweddu gwenyn a ddadlwythodd y pecyn RPM gofynnol o'r lleoliad penodedig. Adroddwyd y fersiwn pecyn i'r bachyn gwe gan yr asiant Adeiladu.

GitLab. Sylw! Mae GitLab yma yn cael ei ddefnyddio nid gan ddatblygwyr, ond gan yr adran weithrediadau i reoli fersiynau cais, fersiynau pecyn, monitro statws yr holl beiriannau Linux, ac mae'n storio'r rysáit - mae pob Pyped yn amlygu.

pyped — yn datrys yr holl faterion dadleuol ac yn cyflwyno'r union ffurfweddiad yr ydym ei eisiau gan Gitlab.

Rydyn ni'n dechrau plymio. Sut mae danfon DLL i RPM yn gweithio?

Dosbarthu DDL i RPM

Gadewch i ni ddweud bod gennym rockstar datblygu .NET. Mae'n defnyddio Visual Studio ac yn creu cangen rhyddhau. Ar ôl hynny, mae'n ei uwchlwytho i Git, ac mae Git yma yn endid TFS, hynny yw, dyma'r storfa ymgeisio y mae'r datblygwr yn gweithio gyda hi.

.NET Core ar Linux, DevOps ar gefn ceffyl

Ar ôl hynny mae TFS yn gweld bod ymrwymiad newydd wedi cyrraedd. Pa ap? Yn y gosodiadau TFS mae label yn nodi pa adnoddau sydd gan asiant Adeiladu penodol. Yn yr achos hwn, mae'n gweld ein bod yn adeiladu prosiect .NET Core ac yn dewis asiant Linux Build o'r pwll.

Mae'r asiant Adeiladu yn derbyn y ffynonellau ac yn lawrlwytho'r hyn sydd ei angen dibyniaethau o'r ystorfa .NET, npm, etc. ac ar ôl adeiladu'r cais ei hun a phecynnu dilynol, yn anfon y pecyn RPM i'r ystorfa RPM.

Ar y llaw arall, mae'r canlynol yn digwydd. Mae peiriannydd yr adran weithrediadau yn ymwneud yn uniongyrchol â chyflwyno'r prosiect: mae'n newid y fersiynau o becynnau i mewn Hiera yn y storfa lle mae'r rysáit cais yn cael ei storio, ac ar ôl hynny sbardunau Pyped Iym, yn nôl y pecyn newydd o'r ystorfa, ac mae'r fersiwn newydd o'r cais yn barod i'w ddefnyddio.

.NET Core ar Linux, DevOps ar gefn ceffyl

Mae popeth yn syml mewn geiriau, ond beth sy'n digwydd y tu mewn i'r asiant Adeiladu ei hun?

Pecynnu DLL RPM

Wedi derbyn ffynonellau prosiect a thasg adeiladu gan TFS. Asiant adeiladu yn dechrau adeiladu'r prosiect ei hun o ffynonellau. Mae'r prosiect sydd wedi'i ymgynnull ar gael fel set Ffeiliau DLL, sy'n cael eu pecynnu mewn archif sip i leihau'r llwyth ar y system ffeiliau.

Mae'r archif ZIP yn cael ei daflu i'r cyfeiriadur adeiladu pecyn RPM. Nesaf, mae'r sgript Bash yn cychwyn y newidynnau amgylchedd, yn dod o hyd i'r fersiwn Adeiladu, fersiwn y prosiect, y llwybr i'r cyfeiriadur adeiladu, ac yn rhedeg RPM-build. Unwaith y bydd y gwaith adeiladu wedi'i gwblhau, caiff y pecyn ei gyhoeddi i ystorfa leol, sydd wedi'i leoli ar yr asiant Adeiladu.

Nesaf, o'r asiant Adeiladu i'r gweinydd yn y storfa RPM Cais JSON yn cael ei anfon gan nodi enw'r fersiwn a'r adeilad. Mae Webhook, y soniais amdano yn gynharach, yn lawrlwytho'r union becyn hwn o'r ystorfa leol ar yr asiant Adeiladu ac yn sicrhau bod y cynulliad newydd ar gael i'w osod.

.NET Core ar Linux, DevOps ar gefn ceffyl

Pam y cynllun cyflenwi pecynnau penodol hwn i'r gadwrfa RPM? Pam na allaf anfon y pecyn wedi'i ymgynnull i'r ystorfa ar unwaith? Y ffaith yw bod hwn yn amod ar gyfer sicrhau diogelwch. Mae'r senario hwn yn cyfyngu ar y posibilrwydd y bydd pobl heb awdurdod yn uwchlwytho pecynnau RPM i weinydd sy'n hygyrch i bob peiriant Linux.

Fersiynau cronfa ddata

Mewn ymgynghoriad â'r tîm datblygu, daeth yn amlwg bod y dynion yn agosach at MS SQL, ond yn y rhan fwyaf o brosiectau nad oeddent yn ymwneud â Windows roeddem eisoes yn defnyddio PostgreSQL gyda'u holl allu. Gan ein bod eisoes wedi penderfynu rhoi'r gorau i bopeth a dalwyd, dechreuon ni ddefnyddio PostgreSQL yma hefyd.

.NET Core ar Linux, DevOps ar gefn ceffyl

Yn y rhan hon rwyf am ddweud wrthych sut y gwnaethom fersiwnio'r gronfa ddata a sut y gwnaethom ddewis rhwng Flyway a Endity Framework Core. Gadewch i ni edrych ar eu manteision a'u hanfanteision.

Cons

Dim ond un ffordd y mae Flyway yn mynd, ni allwn ni ddim rholio yn ôl - mae hyn yn anfantais sylweddol. Gallwch ei gymharu â Chraidd Fframwaith Endid mewn ffyrdd eraill - o ran hwylustod datblygwr. Rydych chi'n cofio ein bod ni'n rhoi hyn ar y blaen, a'r prif faen prawf oedd peidio â newid unrhyw beth ar gyfer datblygu Windows.

Ar gyfer Flyway ni roedd angen rhyw fath o ddeunydd lapiorhag i'r bois ysgrifennu Ymholiadau SQL. Maent yn llawer agosach at weithredu mewn termau OOP. Fe wnaethom ysgrifennu cyfarwyddiadau ar gyfer gweithio gyda gwrthrychau cronfa ddata, cynhyrchu ymholiad SQL a'i weithredu. Mae'r fersiwn newydd o'r gronfa ddata yn barod, wedi'i brofi - mae popeth yn iawn, mae popeth yn gweithio.

Mae gan Craidd Fframwaith Endid minws - o dan lwythi trwm yn adeiladu ymholiadau SQL suboptimal, a gall y tynnu i lawr yn y gronfa ddata fod yn sylweddol. Ond gan nad oes gennym wasanaeth llwyth uchel, nid ydym yn cyfrifo'r llwyth mewn cannoedd o RPS, fe wnaethom dderbyn y risgiau hyn a dirprwyo'r broblem i ni yn y dyfodol.

Manteision

Craidd y Fframwaith Endid yn gweithio allan o'r bocs ac yn hawdd i'w ddatblygu, a Flyway Yn integreiddio'n hawdd i CI presennol. Ond rydyn ni'n ei gwneud hi'n gyfleus i ddatblygwyr :)

Trefn rholio i fyny

Mae pyped yn gweld bod newid yn y fersiwn pecyn yn dod, gan gynnwys yr un sy'n gyfrifol am fudo. Yn gyntaf, mae'n gosod pecyn sy'n cynnwys sgriptiau mudo ac ymarferoldeb sy'n gysylltiedig â chronfa ddata. Ar ôl hyn, mae'r cais sy'n gweithio gyda'r gronfa ddata yn cael ei ailgychwyn. Nesaf daw gosod y cydrannau sy'n weddill. Disgrifir y drefn y caiff pecynnau eu gosod a'r rhaglenni eu lansio yn y maniffest Pypedau.

Mae cymwysiadau'n defnyddio data sensitif, fel tocynnau, cyfrineiriau cronfa ddata, mae hyn i gyd yn cael ei dynnu i mewn i'r ffurfwedd gan Puppet Master, lle cânt eu storio ar ffurf wedi'i hamgryptio.

problemau TFS

Ar ôl i ni benderfynu a sylweddoli bod popeth yn gweithio mewn gwirionedd i ni, penderfynais edrych ar yr hyn oedd yn digwydd gyda'r cynulliadau yn TFS yn ei gyfanrwydd ar gyfer adran datblygu Win ar brosiectau eraill - p'un a oeddem yn adeiladu / rhyddhau'n gyflym ai peidio, a darganfod problemau sylweddol gyda chyflymder.

Mae un o'r prif brosiectau yn cymryd 12-15 munud i gydosod - mae hynny'n amser hir, ni allwch fyw felly. Roedd dadansoddiad cyflym yn dangos gostyngiad ofnadwy yn I/O, ac roedd hyn ar araeau.

Ar ôl ei ddadansoddi fesul cydran, nodais dri ffocws. Yn gyntaf - "Kaspersky antivirus", sy'n sganio ffynonellau ar bob asiant Windows Build. Ail - ffenestri Mynegeiwr. Nid oedd yn anabl, a mynegwyd popeth mewn amser real ar yr Asiantau Adeiladu yn ystod y broses leoli.

Trydydd - Npm gosod. Daeth i'r amlwg ein bod wedi defnyddio'r union senario hwn yn y rhan fwyaf o Biblinellau. Pam ei fod yn ddrwg? Mae gweithdrefn gosod Npm yn cael ei rhedeg pan fydd y goeden dibyniaeth yn cael ei ffurfio pecyn-clo.json, lle mae'r fersiynau o becynnau a ddefnyddir i adeiladu'r prosiect yn cael eu cofnodi. Yr anfantais yw bod Npm install yn tynnu'r fersiynau diweddaraf o becynnau o'r Rhyngrwyd bob tro, ac mae hyn yn cymryd llawer o amser yn achos prosiect mawr.

Weithiau mae datblygwyr yn arbrofi ar beiriant lleol i brofi sut mae rhan benodol neu brosiect cyfan yn gweithio. Weithiau mae'n troi allan bod popeth yn oer yn lleol, ond maent yn ei gydosod, ei gyflwyno, a dim byd yn gweithio. Rydyn ni'n dechrau darganfod beth yw'r broblem - ie, gwahanol fersiynau o becynnau gyda dibyniaethau.

penderfyniad

  • Ffynonellau mewn eithriadau AV.
  • Analluogi mynegeio.
  • Mynd i npm ci.

Manteision npm ci yw ein bod ni Rydyn ni'n casglu'r goeden dibyniaeth unwaith, ac rydym yn cael y cyfle i ddarparu'r datblygwr rhestr gyfredol o becynnau, y gall arbrofi ag ef yn lleol cymaint ag y dymuna. hwn yn arbed amser datblygwyr sy'n ysgrifennu cod.

Ffurfweddiad

Nawr ychydig am gyfluniad y storfa. Yn hanesyddol rydym yn defnyddio Nexus ar gyfer rheoli storfeydd, gan gynnwys REPO mewnol. Mae'r ystorfa fewnol hon yn cynnwys yr holl gydrannau a ddefnyddiwn at ddibenion mewnol, er enghraifft, monitro hunan-ysgrifenedig.

.NET Core ar Linux, DevOps ar gefn ceffyl

Rydym hefyd yn defnyddio NuGet, gan fod ganddo well caching o'i gymharu â rheolwyr pecyn eraill.

Canlyniad

Ar ôl i ni optimeiddio'r Asiantau Adeiladu, gostyngwyd yr amser adeiladu cyfartalog o 12 munud i 7.

Os byddwn yn cyfrif yr holl beiriannau y gallem fod wedi'u defnyddio ar gyfer Windows, ond wedi newid i Linux yn y prosiect hwn, rydym yn arbed tua $ 10. Ac mae hynny ar drwyddedau yn unig, a mwy os byddwn yn ystyried y cynnwys.

Cynlluniau

Ar gyfer y chwarter nesaf, roeddem yn bwriadu gweithio ar optimeiddio darpariaeth cod.

Newid i ddelwedd Docker wedi'i hadeiladu ymlaen llaw. Mae TFS yn beth cŵl gyda llawer o ategion sy'n eich galluogi i integreiddio i Piblinell, gan gynnwys cydosod ar sail sbardun o, dyweder, delwedd Dociwr. Rydym am wneud y sbardun hwn ar gyfer yr un un pecyn-clo.json. Os bydd cyfansoddiad y cydrannau a ddefnyddir i adeiladu'r prosiect yn newid rhywsut, rydym yn adeiladu delwedd Docker newydd. Fe'i defnyddir yn ddiweddarach i ddefnyddio'r cynhwysydd gyda'r cymhwysiad wedi'i ymgynnull. Nid yw hyn yn wir yn awr, ond rydym yn bwriadu newid i bensaernïaeth microservice yn Kubernetes, sy'n datblygu'n weithredol yn ein cwmni ac sydd wedi bod yn gwasanaethu atebion cynhyrchu ers amser maith.

Crynodeb

Rwy'n annog pawb i daflu Windows i ffwrdd, ond nid yw oherwydd nad wyf yn gwybod sut i'w goginio. Y rheswm yw bod y rhan fwyaf o atebion Opensource stack Linux. wyt ti'n iawn arbed adnoddau. Yn fy marn i, mae'r dyfodol yn perthyn i atebion Ffynhonnell Agored ar Linux gyda chymuned bwerus.

Proffil siaradwr o Alexander Sinchinov ar GitHub.

DevOps Conf yn gynhadledd ar integreiddio prosesau datblygu, profi a gweithredu ar gyfer gweithwyr proffesiynol gan weithwyr proffesiynol. Dyna pam y prosiect y soniodd Alexander amdano? gweithredu ac yn gweithio, ac ar ddiwrnod y perfformiad cafwyd dau ryddhad llwyddiannus. Ar DevOps Conf yn RIT++ Ar Fai 27 a 28 bydd hyd yn oed mwy o achosion tebyg gan ymarferwyr. Gallwch ddal i neidio i mewn i'r cerbyd olaf a cyflwyno adroddiad neu cymerwch eich amser i archebu tocyn. Dewch i gwrdd â ni yn Skolkovo!

Ffynhonnell: hab.com

Ychwanegu sylw