O sgriptiau i'n platfform ein hunain: sut y gwnaethom awtomeiddio datblygiad yn CIAN

Yn RIT 2019, gwnaeth ein cydweithiwr Alexander Korotkov adroddiad am awtomeiddio datblygiad yn CIAN: i symleiddio bywyd a gwaith, rydym yn defnyddio ein platfform Integro ein hunain. Mae'n olrhain cylch bywyd tasgau, yn lleddfu datblygwyr o weithrediadau arferol ac yn lleihau'n sylweddol nifer y bygiau wrth gynhyrchu. Yn y swydd hon, byddwn yn ategu adroddiad Alexander ac yn dweud wrthych sut yr aethom o sgriptiau syml i gyfuno cynhyrchion ffynhonnell agored trwy ein platfform ein hunain a'r hyn y mae ein tîm awtomeiddio ar wahân yn ei wneud.
 

Lefel sero

“Nid oes y fath beth â lefel sero, nid wyf yn gwybod y fath beth”
Meistr Shifu o'r ffilm "Kung Fu Panda"

Dechreuodd awtomeiddio yn CIAN 14 mlynedd ar ôl sefydlu'r cwmni. Bryd hynny roedd 35 o bobl yn y tîm datblygu. Anodd credu, iawn? Wrth gwrs, roedd awtomatiaeth yn bodoli mewn rhyw ffurf, ond dechreuodd cyfeiriad ar wahân ar gyfer integreiddio parhaus a chyflwyno cod gael ei ffurfio yn 2015. 

Bryd hynny, roedd gennym monolith enfawr o Python, C# a PHP, wedi'i ddefnyddio ar weinyddion Linux/Windows. I ddefnyddio'r anghenfil hwn, roedd gennym set o sgriptiau a redwyd â llaw. Roedd yna hefyd gynulliad y monolith, a ddaeth â phoen a dioddefaint oherwydd gwrthdaro wrth uno canghennau, cywiro diffygion, ac ailadeiladu “gyda set wahanol o dasgau yn yr adeiladu.” Roedd proses symlach yn edrych fel hyn:

Nid oeddem yn hapus â hynny, ac roeddem am adeiladu proses adeiladu a defnyddio amlroddadwy, awtomataidd a hylaw. Ar gyfer hyn, roedd angen system CI/CD arnom, a gwnaethom ddewis rhwng y fersiwn am ddim o Teamcity a'r fersiwn am ddim o Jenkins, gan ein bod yn gweithio gyda nhw ac roedd y ddau yn ein siwtio ni o ran y set o swyddogaethau. Fe wnaethon ni ddewis Teamcity fel cynnyrch mwy diweddar. Ar y pryd, nid oeddem wedi defnyddio pensaernïaeth microwasanaeth eto ac nid oeddem yn disgwyl nifer fawr o dasgau a phrosiectau.

Rydym yn dod at y syniad o'n system ein hunain

Dim ond rhan o'r gwaith llaw a ddilëwyd gan weithredu Teamcity: yr hyn sydd ar ôl yw creu Ceisiadau Tynnu, hyrwyddo materion yn ôl statws yn Jira, a dewis materion i'w rhyddhau. Ni allai system Teamcity ymdopi â hyn mwyach. Roedd angen dewis llwybr awtomeiddio pellach. Fe wnaethom ystyried opsiynau ar gyfer gweithio gyda sgriptiau yn Teamcity neu newid i systemau awtomeiddio trydydd parti. Ond yn y diwedd fe wnaethom benderfynu bod angen yr hyblygrwydd mwyaf posibl, a dim ond ein datrysiad ein hunain y gall ei ddarparu. Dyma sut yr ymddangosodd y fersiwn gyntaf o'r system awtomeiddio fewnol o'r enw Integro.

Mae Teamcity yn delio ag awtomeiddio ar lefel lansio'r prosesau adeiladu a defnyddio, tra bod Integro yn canolbwyntio ar awtomeiddio lefel uchaf prosesau datblygu. Roedd angen cyfuno gwaith gyda materion yn Jira â phrosesu cod ffynhonnell cysylltiedig yn Bitbucket. Ar y cam hwn, dechreuodd Integro gael ei lifoedd gwaith ei hun ar gyfer gweithio gyda thasgau o wahanol fathau. 

Oherwydd y cynnydd mewn awtomeiddio mewn prosesau busnes, mae nifer y prosiectau a rhediadau yn Teamcity wedi cynyddu. Felly daeth problem newydd: nid oedd un enghraifft Teamcity am ddim yn ddigon (3 asiant a 100 o brosiectau), fe wnaethom ychwanegu enghraifft arall (3 asiant arall a 100 o brosiectau), yna un arall. O ganlyniad, yn y pen draw, cawsom system o sawl clwstwr, a oedd yn anodd ei rheoli:

Pan gododd cwestiwn 4ydd achos, sylweddolom na allem barhau i fyw fel hyn, gan nad oedd cyfanswm costau cefnogi 4 achos bellach o fewn unrhyw derfynau. Cododd y cwestiwn ynghylch prynu Teamcity â thâl neu ddewis Jenkins am ddim. Gwnaethom gyfrifiadau ar achosion a chynlluniau awtomeiddio a phenderfynwyd y byddem yn byw ar Jenkins. Ar ôl ychydig wythnosau, fe wnaethom newid i Jenkins a dileu rhywfaint o'r cur pen sy'n gysylltiedig â chynnal nifer o achosion Teamcity. Felly, roeddem yn gallu canolbwyntio ar ddatblygu Integro ac addasu Jenkins i ni ein hunain.

Gyda thwf awtomeiddio sylfaenol (ar ffurf creu Ceisiadau Tynnu'n awtomatig, casglu a chyhoeddi sylw Cod a gwiriadau eraill), mae awydd cryf i roi'r gorau i ryddhau â llaw cymaint â phosibl a rhoi'r gwaith hwn i robotiaid. Yn ogystal, dechreuodd y cwmni symud i ficrowasanaethau o fewn y cwmni, a oedd angen rhyddhau aml, ac ar wahân i'w gilydd. Dyma sut y daethom yn raddol i ryddhau ein microwasanaethau yn awtomatig (ar hyn o bryd rydym yn rhyddhau'r monolith â llaw oherwydd cymhlethdod y broses). Ond, fel sy'n digwydd fel arfer, cododd cymhlethdod newydd. 

Rydym yn awtomeiddio profion

Oherwydd awtomeiddio rhyddhau, mae prosesau datblygu wedi cyflymu, yn rhannol oherwydd sgipio rhai camau profi. Ac arweiniodd hyn at golli ansawdd dros dro. Mae'n swnio'n ddibwys, ond ynghyd â chyflymu datganiadau, roedd angen newid y fethodoleg datblygu cynnyrch. Roedd angen meddwl am awtomeiddio'r profion, gan sefydlu cyfrifoldeb personol (yma rydyn ni'n sôn am "dderbyn y syniad yn y pen", nid dirwyon ariannol) y datblygwr ar gyfer y cod a ryddhawyd a bygiau ynddo, yn ogystal â'r penderfyniad i rhyddhau/peidio â rhyddhau tasg trwy ddefnydd awtomatig. 

Gan ddileu problemau ansawdd, daethom i ddau benderfyniad pwysig: dechreuasom gynnal profion caneri a chyflwyno monitro awtomatig o gefndir y gwall gydag ymateb awtomatig i'w ormodedd. Roedd yr ateb cyntaf yn ei gwneud hi'n bosibl dod o hyd i wallau amlwg cyn i'r cod gael ei ryddhau'n llawn i'w gynhyrchu, ac roedd yr ail yn lleihau'r amser ymateb i broblemau cynhyrchu. Mae camgymeriadau, wrth gwrs, yn digwydd, ond rydyn ni'n treulio'r rhan fwyaf o'n hamser a'n hymdrech nid ar eu cywiro, ond ar eu lleihau. 

Tîm Awtomatiaeth

Ar hyn o bryd mae gennym staff o 130 o ddatblygwyr, ac rydym yn parhau tyfu. Mae'r tîm ar gyfer integreiddio parhaus a chyflwyno cod (y cyfeirir ato o hyn ymlaen fel y tîm Deploy and Integration neu DI) yn cynnwys 7 o bobl ac yn gweithio mewn 2 gyfeiriad: datblygu platfform awtomeiddio Integro a DevOps. 

Mae DevOps yn gyfrifol am amgylchedd Dev/Beta safle CIAN, yr amgylchedd Integro, yn helpu datblygwyr i ddatrys problemau ac yn datblygu dulliau newydd o ymdrin ag amgylcheddau graddio. Mae cyfeiriad datblygu Integro yn delio ag Integro ei hun a gwasanaethau cysylltiedig, er enghraifft, ategion ar gyfer Jenkins, Jira, Confluence, a hefyd yn datblygu cyfleustodau a chymwysiadau ategol ar gyfer timau datblygu. 

Mae'r tîm DI yn gweithio ar y cyd â thîm Platfform, sy'n datblygu pensaernïaeth, llyfrgelloedd, a dulliau datblygu yn fewnol. Ar yr un pryd, gall unrhyw ddatblygwr o fewn CIAN gyfrannu at awtomeiddio, er enghraifft, gwneud micro-awtomatiaeth i weddu i anghenion y tîm neu rannu syniad cŵl ar sut i wneud awtomeiddio hyd yn oed yn well.

Cacen haen o awtomeiddio yn CIAN

Gellir rhannu'r holl systemau sy'n ymwneud ag awtomeiddio yn sawl haen:

1. Systemau allanol (Jira, Bitbucket, ac ati). Mae timau datblygu yn gweithio gyda nhw.
2. Llwyfan Integro. Yn fwyaf aml, nid yw datblygwyr yn gweithio gydag ef yn uniongyrchol, ond dyna sy'n cadw'r holl awtomeiddio i redeg.
3. Gwasanaethau dosbarthu, cerddorfaol a darganfod (er enghraifft, Jeknins, Consul, Nomad). Gyda'u cymorth, rydym yn defnyddio cod ar weinyddion ac yn sicrhau bod gwasanaethau'n gweithio gyda'i gilydd.
4. Haen ffisegol (gweinyddwyr, OS, meddalwedd cysylltiedig). Mae ein cod yn gweithredu ar y lefel hon. Gall hyn fod naill ai'n weinydd corfforol neu'n un rhithwir (LXC, KVM, Docker).

Yn seiliedig ar y cysyniad hwn, rydym yn rhannu meysydd cyfrifoldeb o fewn y tîm DI. Mae'r ddwy lefel gyntaf ym maes cyfrifoldeb cyfeiriad datblygu Integro, ac mae'r ddwy lefel olaf eisoes ym maes cyfrifoldeb DevOps. Mae'r gwahaniad hwn yn ein galluogi i ganolbwyntio ar dasgau ac nid yw'n ymyrryd â rhyngweithio, gan ein bod yn agos at ein gilydd ac yn cyfnewid gwybodaeth a phrofiad yn gyson.

Yn gyfan

Gadewch i ni ganolbwyntio ar Integro a dechrau gyda'r pentwr technoleg:

• CentOS 7
• Dociwr + Nomad + Conswl + Vault
• Java 11 (bydd yr hen monolith Integro yn aros ar Java 8)
• Cist Gwanwyn 2.X + Ffurfwedd Cwmwl y Gwanwyn
• PostgreSql 11
• RabbitMQ 
• Apache Tanio
• Camunda (wedi'i fewnosod)
• Grafana + Graffit + Prometheus + Jaeger + ELK
• UI Gwe: React (CSR) + MobX
• SSO: Clogyn clo

Rydym yn cadw at yr egwyddor o ddatblygu microwasanaeth, er bod gennym etifeddiaeth ar ffurf monolith o fersiwn gynnar o Integro. Mae pob microwasanaeth yn rhedeg yn ei gynhwysydd Docker ei hun, ac mae'r gwasanaethau'n cyfathrebu â'i gilydd trwy geisiadau HTTP a negeseuon RabbitMQ. Mae microwasanaethau yn dod o hyd i'w gilydd trwy Consul ac yn gwneud cais iddo, gan basio awdurdodiad trwy SSO (Keycloak, OAuth 2/OpenID Connect).

Fel enghraifft o fywyd go iawn, ystyriwch ryngweithio â Jenkins, sy'n cynnwys y camau canlynol:

1. Mae'r meicrowasanaeth rheoli llif gwaith (y cyfeirir ato o hyn ymlaen fel y microservice Flow) eisiau rhedeg adeilad yn Jenkins. I wneud hyn, mae'n defnyddio Conswl i ddod o hyd i IP:PORT y meicrowasanaeth i'w integreiddio â Jenkins (y cyfeirir ato o hyn ymlaen fel Jenkins microservice) ac yn anfon cais anghydamserol ato i ddechrau'r gwaith adeiladu yn Jenkins.
2. Ar ôl derbyn cais, mae microwasanaeth Jenkins yn cynhyrchu ac yn ymateb gydag ID Swydd, y gellir ei ddefnyddio wedyn i nodi canlyniad y gwaith. Ar yr un pryd, mae'n sbarduno adeiladu Jenkins trwy alwad REST API.
3. Jenkins sy'n perfformio'r gwaith adeiladu ac, ar ôl ei gwblhau, mae'n anfon bachyn gwe gyda'r canlyniadau gweithredu i wasanaeth meicro Jenkins.
4. Ar ôl derbyn y bachyn gwe, mae microwasanaeth Jenkins yn cynhyrchu neges am gwblhau prosesu ceisiadau ac yn atodi'r canlyniadau gweithredu iddo. Anfonir y neges a gynhyrchir i'r ciw RabbitMQ.
5. Trwy RabbitMQ, mae'r neges gyhoeddedig yn cyrraedd y microwasanaeth Llif, sy'n dysgu am ganlyniad prosesu ei dasg trwy baru'r ID Swydd o'r cais a'r neges a dderbyniwyd.

Nawr mae gennym tua 30 o ficrowasanaethau, y gellir eu rhannu'n sawl grŵp:

1. Rheoli cyfluniad.
2. Gwybodaeth a rhyngweithio â defnyddwyr (negeswyr, post).
3. Gweithio gyda chod ffynhonnell.
4. Integreiddio ag offer lleoli (jenkins, nomad, consul, ac ati).
5. Monitro (rhyddhau, gwallau, ac ati).
6. Cyfleustodau gwe (UI ar gyfer rheoli amgylcheddau prawf, casglu ystadegau, ac ati).
7. Integreiddio â thracwyr tasgau a systemau tebyg.
8. Rheoli llif gwaith ar gyfer gwahanol dasgau.

Tasgau llif gwaith

Mae Integro yn awtomeiddio gweithgareddau sy'n gysylltiedig â chylch bywyd y dasg. Mewn termau symlach, bydd cylch bywyd tasg yn cael ei ddeall fel llif gwaith tasg yn Jira. Mae gan ein prosesau datblygu sawl amrywiad llif gwaith yn dibynnu ar y prosiect, y math o dasg a'r opsiynau a ddewiswyd mewn tasg benodol. 

Edrychwn ar y llif gwaith a ddefnyddiwn amlaf:

Yn y diagram, mae'r gêr yn nodi bod y trawsnewid yn cael ei alw'n awtomatig gan Integro, tra bod y ffigur dynol yn nodi bod person yn galw'r trawsnewidiad â llaw. Edrychwn ar sawl llwybr y gall tasg eu cymryd yn y llif gwaith hwn.

Profi â llaw yn gyfan gwbl ar DEV + BETA heb brofion caneri (fel arfer dyma sut rydyn ni'n rhyddhau monolith):

Gall fod cyfuniadau pontio eraill. Weithiau gellir dewis y llwybr y bydd mater yn ei gymryd trwy opsiynau yn Jira.

Symud tasg

Edrychwn ar y prif gamau a gyflawnir pan fydd tasg yn symud trwy'r llif gwaith “DEV Testing + Canary Tests”:

1. Y datblygwr neu PM sy'n creu'r dasg.

2. Mae'r datblygwr yn cymryd y dasg i weithio. Ar ôl ei gwblhau, mae'n newid i statws IN REVIEW.

3. Mae Jira yn anfon Webhook i ficrowasanaeth Jira (sy'n gyfrifol am integreiddio â Jira).

4. Mae microwasanaeth Jira yn anfon cais i'r gwasanaeth Llif (sy'n gyfrifol am lifoedd gwaith mewnol lle mae gwaith yn cael ei berfformio) i gychwyn y llif gwaith.

5. Y tu mewn i'r gwasanaeth Llif:

• Adolygwyr yn cael eu neilltuo i'r dasg (Defnyddwyr microservice sy'n gwybod popeth am ddefnyddwyr + Jira microservice).
• Trwy'r microservice Source (mae'n gwybod am ystorfeydd a changhennau, ond nid yw'n gweithio gyda'r cod ei hun), gwneir chwiliad am ystorfeydd sy'n cynnwys cangen o'n rhifyn (i symleiddio'r chwiliad, mae enw'r gangen yn cyd-fynd â'r mater rhif yn Jira). Yn fwyaf aml, dim ond un gangen sydd gan dasg mewn un gadwrfa; mae hyn yn symleiddio rheolaeth y ciw lleoli ac yn lleihau cysylltedd rhwng cadwrfeydd.
• Ar gyfer pob cangen a ganfyddir, cyflawnir y dilyniant canlynol o gamau gweithredu:

  i) Diweddaru'r brif gangen (Git microservice ar gyfer gweithio gyda chod).
  ii) Mae'r gangen yn cael ei rhwystro rhag newidiadau gan y datblygwr (Bitbucket microservice).
  iii) Crëir Cais Tynnu ar gyfer y gangen hon (Bitbucket microservice).
  iv) Anfonir neges am Gais Tynnu newydd i sgyrsiau datblygwyr (Hysbysu microwasanaeth am weithio gyda hysbysiadau).
  v) Dechreuir tasgau adeiladu, profi a lleoli ar DEV (Jenkins microservice ar gyfer gweithio gyda Jenkins).
  vi) Os bydd yr holl gamau blaenorol yn cael eu cwblhau'n llwyddiannus, yna mae Integro yn rhoi ei Gymeradwyaeth yn y Cais Tynnu (Bitbucket microservice).

• Integro yn aros am Gymeradwyaeth Tynnu Cais gan adolygwyr dynodedig.
• Cyn gynted ag y bydd yr holl gymeradwyaethau angenrheidiol wedi'u derbyn (gan gynnwys profion awtomataidd wedi pasio'n gadarnhaol), mae Integro yn trosglwyddo'r dasg i statws Test on Dev (Jira microservice).

6. Mae profwyr yn profi'r dasg. Os nad oes unrhyw broblemau, yna trosglwyddir y dasg i'r statws Ready For Build.

7. Mae Integro yn “gweld” bod y dasg yn barod i'w rhyddhau ac yn dechrau ei defnyddio yn y modd caneri (Jenkins microservice). Pennir parodrwydd ar gyfer rhyddhau gan set o reolau. Er enghraifft, mae'r dasg yn y statws gofynnol, nid oes cloeon ar dasgau eraill, ar hyn o bryd nid oes unrhyw uwchlwythiadau gweithredol o'r microwasanaeth hwn, ac ati.

8. Trosglwyddir y dasg i statws Canary (Jira microservice).

9. Jenkins yn lansio tasg lleoli trwy Nomad yn y modd caneri (1-3 achos fel arfer) ac yn hysbysu'r gwasanaeth monitro rhyddhau (meicrowasanaeth DeployWatch) am y defnydd.

10. Mae microwasanaeth DeployWatch yn casglu cefndir y gwall ac yn ymateb iddo, os oes angen. Os eir y tu hwnt i gefndir y gwall (cyfrifir y norm cefndir yn awtomatig), hysbysir datblygwyr trwy'r microwasanaeth Hysbysu. Os nad yw'r datblygwr wedi ymateb ar ôl 5 munud (cliciwch Revert or Stay), yna mae dychweliad awtomatig o'r achosion caneri yn cael ei lansio. Os na eir y tu hwnt i'r cefndir, yna rhaid i'r datblygwr lansio'r gosodiad tasg i Gynhyrchu â llaw (trwy glicio botwm yn yr UI). Os nad yw'r datblygwr wedi lansio'r adleoli i Gynhyrchu o fewn 60 munud, yna bydd yr achosion caneri hefyd yn cael eu dychwelyd am resymau diogelwch.

11. Ar ôl lansio'r defnydd i Gynhyrchu:

• Trosglwyddir y dasg i statws Cynhyrchu (Jira microservice).
• Mae microwasanaeth Jenkins yn dechrau'r broses leoli ac yn hysbysu microwasanaeth DeployWatch am y defnydd.
• Mae microwasanaeth DeployWatch yn gwirio bod yr holl gynwysyddion ar Gynhyrchu wedi'u diweddaru (roedd achosion pan na chafodd pob un ei ddiweddaru).
• Trwy'r microwasanaeth Hysbysu, anfonir hysbysiad am ganlyniadau'r defnydd i Gynhyrchu.

12. Bydd gan ddatblygwyr 30 munud i ddechrau treiglo tasg yn ôl o Gynhyrchu os canfyddir ymddygiad microwasanaeth anghywir. Ar ôl yr amser hwn, bydd y dasg yn cael ei huno'n awtomatig yn feistr (Git microservice).

13. Ar ôl uno llwyddiannus i feistr, bydd statws y dasg yn cael ei newid i Ar Gau (Jira microservice).

Nid yw'r diagram yn esgus bod yn gwbl fanwl (mewn gwirionedd mae hyd yn oed mwy o gamau), ond mae'n caniatáu ichi asesu i ba raddau y mae prosesau'n cael eu hintegreiddio. Nid ydym yn ystyried y cynllun hwn yn ddelfrydol ac rydym yn gwella prosesau rhyddhau awtomatig a chymorth lleoli.

Beth sydd nesaf

Mae gennym gynlluniau mawr ar gyfer datblygu awtomeiddio, er enghraifft, dileu gweithrediadau llaw yn ystod rhyddhau monolith, gwella monitro yn ystod defnydd awtomatig, a gwella rhyngweithio â datblygwyr.

Ond gadewch i ni stopio yma am y tro. Gwnaethom ymdrin â llawer o bynciau yn yr adolygiad awtomeiddio yn arwynebol, ni chyffyrddwyd â rhai o gwbl, felly byddwn yn hapus i ateb cwestiynau. Rydym yn aros am awgrymiadau ar beth i'w gynnwys yn fanwl, ysgrifennwch y sylwadau.

Ffynhonnell: hab.com