Rhan 1: Gwe/Android
Nodyn: mae'r erthygl hon yn gyfieithiad i Rwsieg o'r erthygl wreiddiol Fodd bynnag, mae'r holl ddarluniau, dolenni, dyfyniadau a thermau yn cael eu cadw yn yr iaith wreiddiol er mwyn osgoi ystumio'r ystyr wrth ei gyfieithu i Rwsieg. Rwy'n dymuno hapus i chi astudio!
Ar hyn o bryd, mae arbenigedd DevOps yn un o'r rhai y mae galw mwyaf amdano yn y diwydiant TG. Os byddwch chi'n agor gwefannau chwilio am swyddi poblogaidd ac yn hidlo yn ôl cyflog, fe welwch fod swyddi sy'n gysylltiedig â DevOps ar frig y rhestr. Fodd bynnag, mae'n bwysig deall bod hyn yn cyfeirio'n bennaf at swydd 'Uwch', sy'n awgrymu bod gan yr ymgeisydd lefel uchel o sgiliau, gwybodaeth am dechnoleg ac offer. Daw hyn hefyd â lefel uchel o gyfrifoldeb sy'n gysylltiedig â gweithrediad di-dor y cynhyrchiad. Fodd bynnag, dechreuon ni anghofio beth yw DevOps. I ddechrau, nid oedd yn unrhyw berson neu adran benodol. Os edrychwn am ddiffiniadau o'r term hwn, byddwn yn dod o hyd i lawer o enwau hardd a chywir, megis methodoleg, arferion, athroniaeth ddiwylliannol, grŵp o gysyniadau, ac ati.
Peiriannydd awtomeiddio prawf (peiriannydd awtomatiaeth QA) yw fy arbenigedd, ond credaf na ddylai fod yn gysylltiedig ag ysgrifennu profion auto neu ddatblygu pensaernïaeth fframwaith prawf yn unig. Yn 2020, mae gwybodaeth am seilwaith awtomeiddio hefyd yn hanfodol. Mae hyn yn caniatáu ichi drefnu'r broses awtomeiddio eich hun, o redeg profion i ddarparu canlyniadau i'r holl randdeiliaid yn unol â'ch nodau. O ganlyniad, mae sgiliau DevOps yn hanfodol i gyflawni'r swydd. Ac mae hyn i gyd yn dda, ond, yn anffodus, mae yna broblem (spoiler: mae'r erthygl hon yn ceisio symleiddio'r broblem hon). Y pwynt yw bod DevOps yn anodd. Ac mae hyn yn amlwg, oherwydd ni fydd cwmnïau'n talu llawer am rywbeth sy'n hawdd i'w wneud... Yn y byd DevOps, mae yna nifer fawr o offer, termau ac arferion y mae angen eu meistroli. Mae hyn yn arbennig o anodd ar ddechrau gyrfa ac yn dibynnu ar y profiad technegol cronedig.
Ffynhonnell:
Yma mae'n debyg y byddwn yn gorffen gyda'r rhan ragarweiniol ac yn canolbwyntio ar bwrpas yr erthygl hon.
Am beth mae'r erthygl hon?
Yn yr erthygl hon, rydw i'n mynd i rannu fy mhrofiad o adeiladu seilwaith awtomeiddio prawf. Mae yna lawer o ffynonellau gwybodaeth ar y Rhyngrwyd am wahanol offer a sut i'w defnyddio, ond hoffwn edrych arnynt yng nghyd-destun awtomeiddio yn unig. Credaf fod llawer o beirianwyr awtomeiddio yn gyfarwydd â'r sefyllfa pan nad oes neb heblaw chi yn rhedeg y profion datblygedig neu'n poeni am eu cynnal. O ganlyniad, mae profion yn mynd yn hen ffasiwn ac mae'n rhaid i chi dreulio amser yn eu diweddaru. Unwaith eto, ar ddechrau gyrfa, gall hon fod yn dasg eithaf anodd: penderfynu yn ddoeth pa offer a ddylai helpu i ddileu problem benodol, sut i'w dewis, eu ffurfweddu a'u cynnal. Mae rhai profwyr yn troi at DevOps (bodau dynol) am help a, gadewch i ni fod yn onest, mae'r dull hwn yn gweithio. Mewn llawer o achosion efallai mai dyma'r unig opsiwn gan nad oes gennym ni welededd i bob dibyniaeth. Ond fel y gwyddom, mae DevOps yn fechgyn prysur iawn, oherwydd mae'n rhaid iddynt feddwl am seilwaith, defnydd, monitro, microwasanaethau a thasgau tebyg eraill y cwmni yn dibynnu ar y sefydliad / tîm. Fel sy'n digwydd fel arfer, nid yw awtomeiddio yn flaenoriaeth. Mewn achos o'r fath, rhaid inni geisio gwneud popeth posibl ar ein rhan o'r dechrau i'r diwedd. Bydd hyn yn lleihau dibyniaethau, yn cyflymu llif gwaith, yn gwella ein sgiliau ac yn ein galluogi i weld y darlun ehangach o'r hyn sy'n digwydd.
Mae'r erthygl yn cyflwyno'r offer mwyaf poblogaidd a phoblogaidd ac yn dangos sut i'w defnyddio i adeiladu seilwaith awtomeiddio gam wrth gam. Mae pob grŵp yn cael ei gynrychioli gan offer sydd wedi'u profi trwy brofiad personol. Ond nid yw hynny'n golygu bod yn rhaid i chi ddefnyddio'r un peth. Nid yw'r offer eu hunain yn bwysig, maent yn ymddangos ac yn dod yn ddarfodedig. Ein tasg peirianneg yw deall yr egwyddorion sylfaenol: pam mae angen y grŵp hwn o offer arnom a pha broblemau gwaith y gallwn eu datrys gyda'u cymorth. Dyna pam yr wyf ar ddiwedd pob adran yn gadael dolenni i offer tebyg y gellir eu defnyddio yn eich sefydliad.
Beth sydd ddim yn yr erthygl hon
Ailadroddaf unwaith eto nad yw'r erthygl yn ymwneud ag offer penodol, felly ni fydd unrhyw fewnosod cod o'r ddogfennaeth a disgrifiadau o orchmynion penodol. Ond ar ddiwedd pob adran rwy'n gadael dolenni ar gyfer astudiaeth fanwl.
Gwneir hyn oherwydd:
- mae'r deunydd hwn yn hawdd iawn i'w ddarganfod mewn amrywiol ffynonellau (dogfennau, llyfrau, cyrsiau fideo);
- os byddwn yn dechrau mynd yn ddyfnach, bydd yn rhaid i ni ysgrifennu 10, 20, 30 rhan o'r erthygl hon (tra bod y cynlluniau yn 2-3);
- Dydw i ddim eisiau gwastraffu'ch amser oherwydd efallai y byddwch am ddefnyddio offer eraill i gyflawni'r un nodau.
Ymarfer
Hoffwn i'r deunydd hwn fod yn ddefnyddiol i bob darllenydd, ac nid dim ond ei ddarllen a'i anghofio. Mewn unrhyw astudiaeth, mae ymarfer yn elfen bwysig iawn. Ar gyfer hyn yr wyf wedi paratoi. Mae yna waith cartref hefyd yn aros i chi wneud yn siŵr nad ydych chi'n copïo llinellau'r gorchmynion rydych chi'n eu gweithredu yn ddifeddwl.
Cynllun
Cam
Technoleg
offer
1
Rhedeg lleol (paratowch brofion demo gwe / android a'i redeg yn lleol)
Node.js, Selenium, Appium
2
Systemau rheoli fersiwn
mynd
3
Containerization
Dociwr, grid Seleniwm, Selenoid (Gwe, Android)
4
CI/CD
Gitlab CI
5
Llwyfannau Cloud
Llwyfan Google Cloud
6
Cerddorfa
Kubernetes
7
Isadeiledd fel cod (IaC)
Terraform, Asible
Strwythur pob adran
Er mwyn cadw’r naratif yn glir, disgrifir pob adran yn ôl yr amlinelliad canlynol:
- disgrifiad byr o'r dechnoleg,
- gwerth ar gyfer seilwaith awtomeiddio,
- enghraifft o gyflwr presennol y seilwaith,
- dolenni i astudio,
- offer tebyg.
1. Cynnal profion yn lleol
Disgrifiad byr o'r dechnoleg
Dim ond cam paratoadol yw hwn i redeg y profion demo yn lleol a gwirio eu bod yn pasio. Yn y rhan ymarferol, defnyddir Node.js, ond nid yw'r iaith raglennu a'r platfform hefyd yn bwysig a gallwch ddefnyddio'r rhai a ddefnyddir yn eich cwmni.
Fodd bynnag, fel offer awtomeiddio, rwy'n argymell defnyddio Selenium WebDriver ar gyfer llwyfannau gwe ac Appium ar gyfer y platfform Android, yn y drefn honno, oherwydd yn y camau nesaf byddwn yn defnyddio delweddau Docker sydd wedi'u teilwra i weithio'n benodol gyda'r offer hyn. Ar ben hynny, gan gyfeirio at ofynion y swydd, yr offer hyn yw'r galw mwyaf yn y farchnad.
Fel efallai y byddwch wedi sylwi, dim ond profion gwe ac Android rydym yn eu hystyried. Yn anffodus, mae iOS yn stori hollol wahanol (diolch Apple). Rwy'n bwriadu arddangos atebion ac arferion cysylltiedig â IOS yn y rhannau sydd i ddod.
Gwerth am seilwaith awtomeiddio
O safbwynt seilwaith, nid yw rhedeg yn lleol yn rhoi unrhyw werth. Dim ond mewn porwyr ac efelychwyr lleol y byddwch yn gwirio bod y profion yn rhedeg ar y peiriant lleol. Ond beth bynnag, mae hwn yn fan cychwyn angenrheidiol.
Darlun o gyflwr presennol yr isadeiledd
Dolenni i archwilio
Offer tebyg
- unrhyw iaith raglennu yr ydych yn ei hoffi ar y cyd â phrofion Selenium/Appium;
- unrhyw brofion;
- unrhyw rhedwr prawf.
2. Systemau rheoli fersiwn (Git)
Disgrifiad byr o'r dechnoleg
Ni fydd yn ddatguddiad mawr i unrhyw un os dywedaf fod rheoli fersiynau yn rhan hynod bwysig o ddatblygiad, mewn tîm ac yn unigol. Yn seiliedig ar wahanol ffynonellau, mae'n ddiogel dweud mai Git yw'r cynrychiolydd mwyaf poblogaidd. Mae system rheoli fersiwn yn darparu llawer o fanteision, megis rhannu cod, storio fersiynau, adfer i ganghennau blaenorol, monitro hanes prosiect, a chopïau wrth gefn. Ni fyddwn yn trafod pob pwynt yn fanwl, gan yr wyf yn siŵr eich bod yn gyfarwydd iawn ag ef ac yn ei ddefnyddio yn eich gwaith beunyddiol. Ond os nad yn sydyn, yna rwy'n argymell oedi i ddarllen yr erthygl hon a llenwi'r bwlch hwn cyn gynted â phosibl.
Gwerth am seilwaith awtomeiddio
Ac yma gallwch chi ofyn cwestiwn rhesymol: “Pam ei fod yn dweud wrthym am Git? Mae pawb yn gwybod hyn ac yn ei ddefnyddio ar gyfer cod datblygu ac ar gyfer cod profi ceir.” Byddwch yn llygad eich lle, ond yn yr erthygl hon rydym yn sôn am seilwaith ac mae'r adran hon yn gweithredu fel rhagolwg ar gyfer adran 7: “Isadeiledd fel Cod (IaC)”. I ni, mae hyn yn golygu bod y seilwaith cyfan, gan gynnwys profi, yn cael ei ddisgrifio ar ffurf cod, felly gallwn hefyd gymhwyso systemau fersiwn iddo a chael buddion tebyg ag ar gyfer cod datblygu ac awtomeiddio.
Byddwn yn edrych ar IaC yn fanylach yng Ngham 7, ond hyd yn oed nawr gallwch chi ddechrau defnyddio Git yn lleol trwy greu ystorfa leol. Bydd y darlun mawr yn cael ei ehangu pan fyddwn yn ychwanegu ystorfa anghysbell at y seilwaith.
Darlun o gyflwr presennol yr isadeiledd
Dolenni i archwilio
Offer tebyg
3. Containerization (Docker)
Disgrifiad byr o'r dechnoleg
I ddangos sut mae cynhwysydd wedi newid rheolau'r gêm, gadewch i ni fynd yn ôl mewn amser ychydig ddegawdau. Yn ôl wedyn, roedd pobl yn prynu ac yn defnyddio peiriannau gweinydd i redeg cymwysiadau. Ond yn y rhan fwyaf o achosion, nid oedd yr adnoddau cychwyn gofynnol yn hysbys ymlaen llaw. O ganlyniad, gwariodd cwmnïau arian ar brynu gweinyddwyr drud, pwerus, ond ni ddefnyddiwyd rhywfaint o'r gallu hwn yn llwyr.
Y cam nesaf o esblygiad oedd peiriannau rhithwir (VMs), a ddatrysodd y broblem o wastraffu arian ar adnoddau nas defnyddiwyd. Roedd y dechnoleg hon yn ei gwneud hi'n bosibl rhedeg cymwysiadau yn annibynnol ar ei gilydd o fewn yr un gweinydd, gan ddyrannu gofod cwbl ynysig. Ond, yn anffodus, mae anfanteision i unrhyw dechnoleg. Mae rhedeg VM yn gofyn am system weithredu lawn, sy'n defnyddio CPU, RAM, storfa ac, yn dibynnu ar yr OS, mae angen ystyried costau trwydded. Mae'r ffactorau hyn yn effeithio ar gyflymder llwytho ac yn gwneud hygludedd yn anodd.
Ac yn awr rydym yn dod i containerization. Unwaith eto, mae'r dechnoleg hon yn datrys y broblem flaenorol, gan nad yw cynwysyddion yn defnyddio OS llawn, sy'n rhyddhau llawer iawn o adnoddau ac yn darparu ateb cyflym a hyblyg ar gyfer hygludedd.
Wrth gwrs, nid yw technoleg cynhwysyddion yn ddim byd newydd ac fe'i cyflwynwyd gyntaf yn y 70au hwyr. Yn y dyddiau hynny, gwnaed llawer o ymchwil, datblygiadau ac ymdrechion. Ond Docker a addasodd y dechnoleg hon a'i gwneud yn hawdd i'r llu. Y dyddiau hyn, pan fyddwn yn siarad am gynwysyddion, yn y rhan fwyaf o achosion rydym yn golygu Docker. Pan fyddwn yn siarad am gynwysyddion Docker, rydym yn golygu cynwysyddion Linux. Gallwn ddefnyddio systemau Windows a macOS i redeg cynwysyddion, ond mae'n bwysig deall bod haen ychwanegol yn ymddangos yn yr achos hwn. Er enghraifft, mae Docker on Mac yn rhedeg cynwysyddion yn dawel y tu mewn i Linux VM ysgafn. Byddwn yn dychwelyd at y pwnc hwn pan fyddwn yn trafod rhedeg efelychwyr Android y tu mewn i gynwysyddion, felly yma mae naws bwysig iawn y mae angen ei drafod yn fanylach.
Gwerth am seilwaith awtomeiddio
Cawsom wybod bod cynhwysydd a Docker yn cŵl. Gadewch i ni edrych ar hyn yng nghyd-destun awtomeiddio, oherwydd mae angen i bob offeryn neu dechnoleg ddatrys problem. Gadewch inni amlinellu problemau amlwg awtomeiddio prawf yng nghyd-destun profion UI:
- nifer enfawr o ddibyniaethau wrth osod Seleniwm ac yn enwedig Appium;
- problemau cydnawsedd rhwng fersiynau o borwyr, efelychwyr a gyrwyr;
- diffyg gofod ynysig ar gyfer porwyr/efelychwyr, sy'n arbennig o hanfodol ar gyfer rhedeg yn gyfochrog;
- anodd ei reoli a'i gynnal os oes angen i chi redeg 10, 50, 100 neu hyd yn oed 1000 o borwyr ar yr un pryd.
Ond gan mai Seleniwm yw'r offeryn awtomeiddio mwyaf poblogaidd a Docker yw'r offeryn cynhwysyddio mwyaf poblogaidd, ni ddylai fod yn syndod bod rhywun wedi ceisio eu cyfuno i greu offeryn pwerus i ddatrys y problemau a grybwyllwyd uchod. Gadewch i ni ystyried atebion o'r fath yn fwy manwl.
Grid seleniwm yn y docwr
Yr offeryn hwn yw'r mwyaf poblogaidd yn y byd Seleniwm ar gyfer rhedeg porwyr lluosog ar beiriannau lluosog a'u rheoli o ganolbwynt canolog. I ddechrau, mae angen i chi gofrestru o leiaf 2 ran: Hyb a Nod(s). Mae Hub yn nod canolog sy'n derbyn pob cais o brofion ac yn eu dosbarthu i'r Nodau priodol. Ar gyfer pob Nod, gallwn ffurfweddu cyfluniad penodol, er enghraifft, trwy nodi'r porwr a ddymunir a'i fersiwn. Fodd bynnag, mae angen i ni ofalu am yrwyr porwr cydnaws ein hunain o hyd a'u gosod ar y Nodau a ddymunir. Am y rheswm hwn, ni ddefnyddir grid Seleniwm yn ei ffurf pur, ac eithrio pan fydd angen i ni weithio gyda phorwyr na ellir eu gosod ar Linux OS. Ar gyfer pob achos arall, ateb hynod hyblyg a chywir fyddai defnyddio delweddau Docker i redeg grid Selenium Hub a Nodes. Mae'r dull hwn yn symleiddio rheolaeth nodau yn fawr, oherwydd gallwn ddewis y ddelwedd sydd ei hangen arnom gyda fersiynau cydnaws o borwyr a gyrwyr sydd eisoes wedi'u gosod.
Er gwaethaf adolygiadau negyddol am sefydlogrwydd, yn enwedig wrth redeg nifer fawr o Nodau yn gyfochrog, grid Seleniwm yw'r offeryn mwyaf poblogaidd o hyd ar gyfer rhedeg profion Seleniwm yn gyfochrog. Mae'n bwysig nodi bod amrywiol welliannau ac addasiadau i'r offeryn hwn yn ymddangos yn gyson mewn ffynhonnell agored, sy'n brwydro yn erbyn amrywiol dagfeydd.
Selenoid ar gyfer y We
Mae'r offeryn hwn yn ddatblygiad arloesol ym myd Seleniwm gan ei fod yn gweithio allan o'r bocs ac wedi gwneud bywyd llawer o beirianwyr awtomeiddio yn llawer haws. Yn gyntaf oll, nid yw hwn yn addasiad arall o grid Seleniwm. Yn lle hynny, creodd y datblygwyr fersiwn hollol newydd o Selenium Hub yn Golang, a roddodd, ynghyd â delweddau ysgafn Docker ar gyfer gwahanol borwyr, ysgogiad i ddatblygu awtomeiddio prawf. Ar ben hynny, yn achos Grid Seleniwm, rhaid inni bennu'r holl borwyr gofynnol a'u fersiynau ymlaen llaw, nad yw'n broblem wrth weithio gyda dim ond un porwr. Ond o ran nifer o borwyr â chymorth, Selenoid yw'r ateb mwyaf poblogaidd diolch i'w nodwedd 'porwr ar alw'. Y cyfan sy'n ofynnol gennym ni yw lawrlwytho'r delweddau angenrheidiol gyda phorwyr ymlaen llaw a diweddaru'r ffeil ffurfweddu y mae Selenoid yn rhyngweithio â hi. Ar ôl i Selenoid dderbyn cais o'r profion, bydd yn lansio'r cynhwysydd a ddymunir yn awtomatig gyda'r porwr a ddymunir. Pan fydd y prawf wedi'i gwblhau, bydd Selenoid yn ymddeol y cynhwysydd, gan ryddhau adnoddau ar gyfer ceisiadau yn y dyfodol. Mae'r dull hwn yn dileu'n llwyr y broblem adnabyddus o 'ddiraddio nod' yr ydym yn aml yn dod ar ei thraws yn y grid Seleniwm.
Ond, gwaetha'r modd, nid bwled arian mo Selenoid o hyd. Cawsom y nodwedd 'porwr ar alw', ond nid yw'r nodwedd 'adnoddau ar alw' ar gael o hyd. Er mwyn defnyddio Selenoid, rhaid inni ei ddefnyddio ar galedwedd corfforol neu ar VM, sy'n golygu bod yn rhaid i ni wybod ymlaen llaw faint o adnoddau sydd angen eu dyrannu. Mae'n debyg nad yw hyn yn broblem i brosiectau bach sy'n rhedeg 10, 20 neu hyd yn oed 30 o borwyr ochr yn ochr. Ond beth os oes angen 100, 500, 1000 a mwy arnom? Nid yw'n gwneud unrhyw synnwyr i gynnal a thalu am gymaint o adnoddau drwy'r amser. Yn adrannau 5 a 6 yr erthygl hon, byddwn yn trafod atebion sy'n eich galluogi i raddfa, a thrwy hynny leihau costau cwmni yn sylweddol.
Selenoid ar gyfer Android
Ar ôl llwyddiant Selenoid fel offeryn awtomeiddio gwe, roedd pobl eisiau rhywbeth tebyg ar gyfer Android. Ac fe ddigwyddodd - rhyddhawyd Selenoid gyda chefnogaeth Android. O safbwynt defnyddiwr lefel uchel, mae'r egwyddor o weithredu yn debyg i awtomeiddio gwe. Yr unig wahaniaeth yw bod Selenoid yn rhedeg cynwysyddion efelychwyr Android yn lle cynwysyddion porwr. Yn fy marn i, dyma'r offeryn rhad ac am ddim mwyaf pwerus ar hyn o bryd ar gyfer rhedeg profion Android yn gyfochrog.
Ni fyddwn yn hoffi siarad am agweddau negyddol yr offeryn hwn, gan fy mod yn ei hoffi'n fawr. Ond o hyd, mae yna'r un anfanteision sy'n berthnasol i awtomeiddio gwe ac sy'n gysylltiedig â graddio. Yn ogystal â hyn, mae angen inni siarad am un cyfyngiad arall a allai fod yn syndod os ydym yn sefydlu'r offeryn am y tro cyntaf. I redeg delweddau Android, mae angen peiriant corfforol neu VM gyda chefnogaeth rhithwiroli nythu. Yn y canllaw sut-i, rwy'n dangos sut i alluogi hyn ar Linux VM. Fodd bynnag, os ydych chi'n ddefnyddiwr macOS ac eisiau defnyddio Selenoid yn lleol, yna ni fydd hyn yn bosibl rhedeg profion Android. Ond gallwch chi bob amser redeg Linux VM yn lleol gyda 'rhithwiroli nythu' wedi'i ffurfweddu a defnyddio Selenoid y tu mewn.
Darlun o gyflwr presennol yr isadeiledd
Yng nghyd-destun yr erthygl hon, byddwn yn ychwanegu 2 offeryn i ddangos y seilwaith. Y rhain yw grid Seleniwm ar gyfer profion gwe a Selenoid ar gyfer profion Android. Yn y tiwtorial GitHub, byddaf hefyd yn dangos i chi sut i ddefnyddio Selenoid i redeg profion gwe.
Dolenni i archwilio
Offer tebyg
- Mae yna offer cynhwysyddion eraill, ond Docker yw'r mwyaf poblogaidd. Os ydych chi am roi cynnig ar rywbeth arall, cofiwch na fydd yr offer rydyn ni wedi'u cynnwys ar gyfer rhedeg profion Seleniwm yn gyfochrog yn gweithio allan o'r bocs.
- Fel y dywedwyd eisoes, mae yna lawer o addasiadau i grid Seleniwm, er enghraifft,.
4.CI/CD
Disgrifiad byr o'r dechnoleg
Mae'r arfer o integreiddio parhaus yn eithaf poblogaidd yn cael ei ddatblygu ac mae ar yr un lefel â systemau rheoli fersiynau. Er gwaethaf hyn, teimlaf fod dryswch mewn terminoleg. Yn y paragraff hwn hoffwn ddisgrifio 3 addasiad i'r dechnoleg hon o'm safbwynt i. Ar y rhyngrwyd fe welwch lawer o erthyglau gyda dehongliadau gwahanol, ac mae'n gwbl normal os yw eich barn yn wahanol. Y peth pwysicaf yw eich bod ar yr un dudalen gyda'ch cydweithwyr.
Felly, mae yna 3 thymor: CI - Integreiddio Parhaus, CD - Cyflenwi Parhaus ac eto CD - Defnydd Parhaus. (Isod byddaf yn defnyddio'r termau hyn yn Saesneg). Mae pob addasiad yn ychwanegu sawl cam ychwanegol at eich piblinell ddatblygu. Ond y gair barhaus (parhaus) yw'r peth pwysicaf. Yn y cyd-destun hwn, rydym yn golygu rhywbeth sy'n digwydd o'r dechrau i'r diwedd, heb ymyrraeth neu ymyrraeth â llaw. Gadewch i ni edrych ar CI a CD a CD yn y cyd-destun hwn.
- Integreiddio Parhaus dyma'r cam cychwynnol o esblygiad. Ar ôl cyflwyno cod newydd i'r gweinydd, rydym yn disgwyl derbyn adborth cyflym bod ein newidiadau yn iawn. Yn nodweddiadol, mae CI yn cynnwys rhedeg offer dadansoddi cod statig a phrofion API uned/mewnol, sy'n ein galluogi i gael gwybodaeth am ein cod o fewn ychydig eiliadau/munudau.
- Cyflawniad Parhaus yn gam mwy datblygedig lle rydym yn cynnal profion integreiddio/UI. Fodd bynnag, ar hyn o bryd nid ydym yn cael canlyniadau mor gyflym â gyda CI. Yn gyntaf, mae'r mathau hyn o brofion yn cymryd mwy o amser i'w cwblhau. Yn ail, cyn lansio, rhaid inni ddefnyddio ein newidiadau i'r amgylchedd prawf/llwyfannu. Ar ben hynny, os ydym yn sôn am ddatblygiad symudol, yna mae'n ymddangos bod cam ychwanegol yn creu adeiladwaith o'n cais.
- Defnyddio Parhaus yn cymryd yn ganiataol ein bod yn rhyddhau ein newidiadau i gynhyrchiad yn awtomatig os yw pob prawf derbyn wedi'i basio yn y camau blaenorol. Yn ogystal â hyn, ar ôl y cam rhyddhau, gallwch chi ffurfweddu gwahanol gamau, megis cynnal profion mwg ar gynhyrchu a chasglu metrigau o ddiddordeb. Dim ond gyda sylw da gan brofion awtomataidd y mae Defnydd Parhaus yn bosibl. Os oes angen unrhyw ymyriadau â llaw, gan gynnwys profi, yna nid yw hyn bellach Parhaus (parhaus). Yna gallwn ddweud bod ein piblinell yn cydymffurfio â'r arfer o Ddarparu Parhaus yn unig.
Gwerth am seilwaith awtomeiddio
Yn yr adran hon, dylwn egluro, pan fyddwn yn siarad am brofion UI o'r dechrau i'r diwedd, mae'n golygu y dylem ddefnyddio ein newidiadau a'n gwasanaethau cysylltiedig i brofi amgylcheddau. Integreiddio Parhaus - nid yw'r broses yn berthnasol ar gyfer y dasg hon ac mae'n rhaid i ni ofalu am weithredu arferion Cyflenwi Parhaus o leiaf. Mae Defnydd Parhaus hefyd yn gwneud synnwyr yng nghyd-destun profion UI os ydym am eu rhedeg wrth gynhyrchu.
A chyn i ni edrych ar y darluniad o'r newid pensaernïaeth, rwyf am ddweud ychydig eiriau am GitLab CI. Yn wahanol i offer CI/CD eraill, mae GitLab yn darparu ystorfa bell a llawer o nodweddion ychwanegol eraill. Felly, mae GitLab yn fwy na CI. Mae'n cynnwys rheoli cod ffynhonnell, rheolaeth Agile, piblinellau CI/CD, offer logio a chasglu metrigau allan o'r bocs. Mae pensaernïaeth GitLab yn cynnwys Gitlab CI/CD a GitLab Runner. Dyma ddisgrifiad byr o'r wefan swyddogol:
Mae Gitlab CI/CD yn gymhwysiad gwe gydag API sy'n storio ei gyflwr mewn cronfa ddata, yn rheoli prosiectau / adeiladu ac yn darparu rhyngwyneb defnyddiwr. Mae GitLab Runner yn gymhwysiad sy'n adeiladu prosesau. Gellir ei ddefnyddio ar wahân ac mae'n gweithio gyda GitLab CI/CD trwy API. Ar gyfer profion sy'n rhedeg mae angen enghraifft Gitlab a Runner arnoch chi.
Darlun o gyflwr presennol yr isadeiledd
Dolenni i archwilio
Offer tebyg
- A llawer o rai eraill
5. llwyfannau cwmwl
Disgrifiad byr o'r dechnoleg
Yn yr adran hon byddwn yn siarad am duedd boblogaidd o'r enw 'cymylau cyhoeddus'. Er gwaethaf y manteision enfawr y mae'r technolegau rhithwiroli a chynhwysiant a ddisgrifir uchod yn eu darparu, mae angen adnoddau cyfrifiadurol arnom o hyd. Mae cwmnïau'n prynu gweinyddion drud neu'n rhentu canolfannau data, ond yn yr achos hwn mae angen gwneud cyfrifiadau (afrealistig weithiau) o faint o adnoddau y bydd eu hangen arnom, a fyddwn yn eu defnyddio 24/7 ac at ba ddibenion. Er enghraifft, mae angen gweinydd sy'n rhedeg XNUMX/XNUMX ar gyfer cynhyrchu, ond a oes angen adnoddau tebyg arnom ar gyfer profi y tu allan i oriau gwaith? Mae hefyd yn dibynnu ar y math o brofion sy'n cael eu cynnal. Un enghraifft fyddai profion llwyth/straen yr ydym yn bwriadu eu cynnal yn ystod oriau nad ydynt yn waith er mwyn cael canlyniadau drannoeth. Ond yn bendant nid oes angen argaeledd gweinydd XNUMX/XNUMX ar gyfer profion awtomataidd o'r dechrau i'r diwedd ac yn enwedig nid ar gyfer amgylcheddau profi â llaw. Ar gyfer sefyllfaoedd o'r fath, byddai'n dda cael cymaint o adnoddau ag sydd eu hangen ar alw, eu defnyddio, a rhoi'r gorau i dalu pan nad oes eu hangen mwyach. Ar ben hynny, byddai'n wych eu derbyn ar unwaith trwy wneud ychydig o gliciau llygoden neu redeg cwpl o sgriptiau. Dyma beth mae cymylau cyhoeddus yn cael eu defnyddio ar ei gyfer. Edrychwn ar y diffiniad:
“Diffinnir y cwmwl cyhoeddus fel gwasanaethau cyfrifiadura a gynigir gan ddarparwyr trydydd parti dros y Rhyngrwyd cyhoeddus, gan sicrhau eu bod ar gael i unrhyw un sydd am eu defnyddio neu eu prynu. Gallant fod yn rhad ac am ddim neu'n cael eu gwerthu ar-alw, gan ganiatáu i gwsmeriaid dalu fesul defnydd yn unig am y cylchoedd CPU, y storfa, neu'r lled band y maent yn ei fwyta. ”
Mae yna farn bod cymylau cyhoeddus yn ddrud. Ond eu syniad allweddol yw lleihau costau cwmni. Fel y soniwyd yn gynharach, mae cymylau cyhoeddus yn caniatáu ichi gael adnoddau ar alw a thalu dim ond am yr amser y byddwch chi'n eu defnyddio. Hefyd, weithiau rydym yn anghofio bod gweithwyr yn derbyn cyflogau, ac mae arbenigwyr hefyd yn adnodd drud. Rhaid cymryd i ystyriaeth bod cymylau cyhoeddus yn gwneud cefnogaeth seilwaith yn llawer haws, sy'n caniatáu i beirianwyr ganolbwyntio ar dasgau pwysicach.
Gwerth am seilwaith awtomeiddio
Pa adnoddau penodol sydd eu hangen arnom ar gyfer profion UI o'r dechrau i'r diwedd? Yn y bôn, peiriannau rhithwir neu glystyrau yw'r rhain (byddwn yn siarad am Kubernetes yn yr adran nesaf) ar gyfer rhedeg porwyr ac efelychwyr. Po fwyaf o borwyr ac efelychwyr yr ydym am eu rhedeg ar yr un pryd, y mwyaf o CPU a chof sydd eu hangen a'r mwyaf o arian y mae'n rhaid i ni dalu amdano. Felly, mae cymylau cyhoeddus yng nghyd-destun awtomeiddio prawf yn ein galluogi i redeg nifer fawr (100, 200, 1000...) o borwyr/efelychwyr ar alw, cael canlyniadau profion cyn gynted â phosibl a rhoi'r gorau i dalu am adnoddau mor wallgof. grym.
Y darparwyr cwmwl mwyaf poblogaidd yw Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP). Mae'r canllaw sut-i yn rhoi enghreifftiau o sut i ddefnyddio GCP, ond yn gyffredinol nid oes ots beth rydych chi'n ei ddefnyddio ar gyfer tasgau awtomeiddio. Maent i gyd yn darparu tua'r un swyddogaeth. Yn nodweddiadol, i ddewis darparwr, mae rheolaeth yn canolbwyntio ar seilwaith cyffredinol a gofynion busnes y cwmni, sydd y tu hwnt i gwmpas yr erthygl hon. Ar gyfer peirianwyr awtomeiddio, bydd yn fwy diddorol cymharu'r defnydd o ddarparwyr cwmwl â'r defnydd o lwyfannau cwmwl yn benodol at ddibenion profi, megis Sauce Labs, BrowserStack, BitBar, ac ati. Felly gadewch i ni ei wneud hefyd! Yn fy marn i, Sauce Labs yw'r fferm profi cwmwl enwocaf, a dyna pam y defnyddiais ef ar gyfer cymhariaeth.
GCP yn erbyn Saws Labs at ddibenion awtomeiddio:
Gadewch i ni ddychmygu bod angen i ni redeg 8 prawf gwe ac 8 prawf Android ar yr un pryd. Ar gyfer hyn byddwn yn defnyddio GCP ac yn rhedeg 2 beiriant rhithwir gyda Selenoid. Ar yr un cyntaf byddwn yn codi 8 cynwysyddion gyda phorwyr. Ar yr ail mae 8 cynhwysydd gydag efelychwyr. Gadewch i ni edrych ar y prisiau:
I redeg un cynhwysydd gyda Chrome, mae angen n1-safon-1 car. Yn achos Android bydd n1-safon-4 ar gyfer un efelychydd. Mewn gwirionedd, ffordd fwy hyblyg a rhatach yw gosod gwerthoedd defnyddwyr penodol ar gyfer CPU / Cof, ond ar hyn o bryd nid yw hyn yn bwysig ar gyfer cymharu â Sauce Labs.
A dyma’r tariffau ar gyfer defnyddio Saws Labs:
Rwy'n credu eich bod eisoes wedi sylwi ar y gwahaniaeth, ond byddaf yn dal i ddarparu tabl gyda chyfrifiadau ar gyfer ein tasg:
Adnoddau angenrheidiol
Misol
Oriau gwaith(8 am - 8 pm)
Oriau gwaith+Rhagweladwy
GCP ar gyfer y We
n1-safonol-1 x 8 = n1-safonol-8
$194.18
23 diwrnod * 12 awr * 0.38 = $104.88
23 diwrnod * 12 awr * 0.08 = $22.08
Labordai Saws ar gyfer y We
Profion cyfochrog Virtual Cloud8
$1.559
-
-
GCP ar gyfer Android
n1-safonol-4 x 8: n1-safonol-16
$776.72
23 diwrnod * 12 awr * 1.52 = $419.52
23 diwrnod * 12 awr * 0.32 = $88.32
Labordai Saws ar gyfer Android
Dyfais Go Iawn Cloud 8 profion cyfochrog
$1.999
-
-
Fel y gallwch weld, mae'r gwahaniaeth yn y gost yn enfawr, yn enwedig os ydych chi'n cynnal profion yn ystod cyfnod gwaith deuddeg awr yn unig. Ond gallwch dorri costau hyd yn oed ymhellach os ydych yn defnyddio peiriannau preemptible. Beth yw e?
Mae VM rhagweladwy yn enghraifft y gallwch chi ei chreu a'i rhedeg am bris llawer mwy nag achosion arferol. Fodd bynnag, gallai Compute Engine derfynu (rhagweld) yr achosion hyn os bydd angen mynediad at yr adnoddau hynny ar gyfer tasgau eraill. Enghreifftiau rhagweladwy yw cynhwysedd Injan Gyfrifiadurol gormodol, felly mae eu hargaeledd yn amrywio yn ôl defnydd.
Os yw'ch apiau'n oddefgar o fai ac yn gallu gwrthsefyll rhagdybiaethau posibl, yna gall achosion rhagweladwy leihau eich costau Compute Engine yn sylweddol. Er enghraifft, gall swyddi prosesu swp redeg ar achosion rhagweladwy. Os daw rhai o'r achosion hynny i ben wrth brosesu, mae'r swydd yn arafu ond nid yw'n dod i ben yn llwyr. Mae achosion rhagweladwy yn cwblhau eich tasgau prosesu swp heb osod llwyth gwaith ychwanegol ar eich achosion presennol a heb orfod talu pris llawn am achosion arferol ychwanegol.
Ac nid yw ar ben eto! Mewn gwirionedd, rwy'n siŵr nad oes unrhyw un yn cynnal profion am 12 awr heb egwyl. Ac os felly, yna gallwch chi ddechrau a stopio peiriannau rhithwir yn awtomatig pan nad oes eu hangen. Gellir lleihau'r amser defnydd gwirioneddol i 6 awr y dydd. Yna bydd y taliad yng nghyd-destun ein tasg yn gostwng i $11 y mis ar gyfer 8 porwr. Onid yw hyn yn wych? Ond gyda pheiriannau rhagweladwy mae'n rhaid i ni fod yn ofalus a pharatoi ar gyfer ymyriadau ac ansefydlogrwydd, er y gellir darparu ar gyfer y sefyllfaoedd hyn a'u trin mewn meddalwedd. Mae'n werth chweil!
Ond nid wyf yn dweud o bell ffordd 'peidiwch byth â defnyddio ffermydd prawf cwmwl'. Mae ganddynt nifer o fanteision. Yn gyntaf oll, nid peiriant rhithwir yn unig yw hwn, ond datrysiad awtomeiddio prawf llawn gyda set o swyddogaethau allan o'r bocs: mynediad o bell, logiau, sgrinluniau, recordiad fideo, porwyr amrywiol a dyfeisiau symudol corfforol. Mewn llawer o sefyllfaoedd, gall hwn fod yn ddewis amgen chic hanfodol. Mae llwyfannau profi yn arbennig o ddefnyddiol ar gyfer awtomeiddio IOS, pan mai dim ond systemau Linux/Windows y gall cymylau cyhoeddus eu cynnig. Ond byddwn yn siarad am iOS yn yr erthyglau canlynol. Rwy'n argymell edrych ar y sefyllfa bob amser a dechrau o'r tasgau: mewn rhai achosion mae'n rhatach ac yn fwy effeithlon defnyddio cymylau cyhoeddus, ac mewn eraill mae'r llwyfannau prawf yn bendant yn werth yr arian a wariwyd.
Darlun o gyflwr presennol yr isadeiledd
Dolenni i archwilio
Offer tebyg:
6. Cerddorfa
Disgrifiad byr o'r dechnoleg
Mae gen i newyddion da - rydyn ni bron ar ddiwedd yr erthygl! Ar hyn o bryd, mae ein seilwaith awtomeiddio yn cynnwys profion gwe ac Android, yr ydym yn eu rhedeg trwy GitLab CI ochr yn ochr, gan ddefnyddio offer a alluogir gan Docker: grid Seleniwm a Selenoid. Ar ben hynny, rydym yn defnyddio peiriannau rhithwir a grëwyd trwy GCP i gynnal cynwysyddion gyda phorwyr ac efelychwyr. Er mwyn lleihau costau, rydym yn cychwyn y peiriannau rhithwir hyn yn ôl y galw yn unig ac yn eu hatal pan nad yw profion yn cael eu cynnal. A oes unrhyw beth arall a all wella ein seilwaith? Yr ateb yw ydy! Dewch i gwrdd â Kubernetes (K8s)!
Yn gyntaf, gadewch i ni edrych ar sut mae'r geiriau cerddorfaol, clwstwr, a Kubernetes yn gysylltiedig â'i gilydd. Ar lefel uchel, offeryniaeth yw'r system sy'n defnyddio ac yn rheoli cymwysiadau. Ar gyfer awtomeiddio prawf, cymwysiadau cynhwysydd o'r fath yw grid Seleniwm a Selenoid. Mae Dociwr a K8s yn ategu ei gilydd. Defnyddir y cyntaf ar gyfer defnyddio cymwysiadau, a'r ail ar gyfer offeryniaeth. Yn ei dro, mae K8s yn glwstwr. Tasg y clwstwr yw defnyddio VMs fel Nodau, sy'n eich galluogi i osod amrywiol swyddogaethau, rhaglenni a gwasanaethau o fewn un gweinydd (clwstwr). Os bydd unrhyw un o'r Nodau yn methu, bydd Nodau eraill yn codi, sy'n sicrhau gweithrediad di-dor ein cais. Yn ogystal â hyn, mae gan K8s ymarferoldeb pwysig sy'n gysylltiedig â graddio, oherwydd rydym yn cael y swm gorau posibl o adnoddau yn awtomatig yn seiliedig ar y llwyth a'r terfynau gosod.
Mewn gwirionedd, nid yw defnyddio Kubernetes â llaw o'r dechrau yn dasg ddibwys o gwbl. Gadawaf ddolen i'r canllaw enwog sut-i "Kubernetes The Hard Way" ac os oes gennych ddiddordeb, gallwch ei ymarfer. Ond, yn ffodus, mae yna ddulliau ac offer amgen. Y ffordd hawsaf yw defnyddio Google Kubernetes Engine (GKE) yn GCP, a fydd yn caniatáu ichi gael clwstwr parod mewn ychydig o gliciau. Rwy'n argymell defnyddio'r dull hwn i ddechrau dysgu, gan y bydd yn caniatáu ichi ganolbwyntio ar ddysgu sut i ddefnyddio'r K8s ar gyfer eich tasgau yn hytrach na dysgu sut y dylid integreiddio'r cydrannau mewnol â'i gilydd.
Gwerth am seilwaith awtomeiddio
Gadewch i ni edrych ar ychydig o nodweddion arwyddocaol y mae'r K8s yn eu darparu:
- defnyddio cymhwysiad: defnyddio clwstwr aml-nodau yn lle VMs;
- graddio deinamig: yn lleihau cost adnoddau a ddefnyddir ar alw yn unig;
- hunan-iachau: adfer codennau'n awtomatig (y mae cynwysyddion hefyd yn cael eu hadfer o ganlyniad);
- cyflwyno diweddariadau a dychwelyd newidiadau heb amser segur: nid yw diweddaru offer, porwyr ac efelychwyr yn amharu ar waith defnyddwyr presennol
Ond nid yw'r K8s yn fwled arian o hyd. Er mwyn deall yr holl fanteision a chyfyngiadau yng nghyd-destun yr offer yr ydym yn eu hystyried (grid Seleniwm, Selenoid), byddwn yn trafod strwythur K8s yn fyr. Mae clwstwr yn cynnwys dau fath o Nodau: Prif Nodau a Nodau Gweithwyr. Mae Master Nodes yn gyfrifol am reoli, lleoli ac amserlennu penderfyniadau. Nodau gweithwyr yw lle mae cymwysiadau'n cael eu rhedeg. Mae nodau hefyd yn cynnwys amgylchedd amser rhedeg cynhwysydd. Yn ein hachos ni, Docker yw hwn, sy'n gyfrifol am weithrediadau sy'n gysylltiedig â chynhwysydd. Ond mae yna hefyd atebion amgen, er enghraifft. Mae'n bwysig deall nad yw graddio neu hunan-iachau yn berthnasol yn uniongyrchol i gynwysyddion. Gweithredir hyn trwy ychwanegu/lleihau nifer y codennau, sydd yn eu tro yn cynnwys cynwysyddion (un cynhwysydd fesul pod fel arfer, ond yn dibynnu ar y dasg efallai y bydd mwy). Mae'r hierarchaeth lefel uchel yn cynnwys nodau gweithwyr, y tu mewn iddynt mae codennau, y mae cynwysyddion wedi'u codi y tu mewn iddynt.
Mae'r nodwedd raddio yn allweddol a gellir ei chymhwyso i'r ddau nod o fewn pwll nod clwstwr a chodau o fewn nod. Mae 2 fath o raddfa sy'n berthnasol i nodau a chodau. Mae'r math cyntaf yn llorweddol - mae graddio'n digwydd trwy gynyddu nifer y nodau / codennau. Mae'r math hwn yn fwy ffafriol. Mae'r ail fath, yn unol â hynny, yn fertigol. Cyflawnir graddio trwy gynyddu maint nodau/codennau, ac nid eu nifer.
Nawr, gadewch i ni edrych ar ein hoffer yng nghyd-destun y termau uchod.
Grid seleniwm
Fel y soniwyd yn gynharach, mae grid Seleniwm yn offeryn poblogaidd iawn, ac nid yw'n syndod ei fod wedi'i gynhwysydd. Felly, nid yw'n syndod y gellir defnyddio grid Seleniwm mewn K8s. Ceir enghraifft o sut i wneud hyn yn ystorfa swyddogol K8s. Yn ôl yr arfer, rwy'n atodi dolenni ar ddiwedd yr adran. Yn ogystal, mae'r canllaw sut i wneud hyn yn dangos sut i wneud hyn yn Terraform. Mae yna hefyd gyfarwyddiadau ar sut i raddio nifer y codennau sy'n cynnwys cynwysyddion porwr. Ond nid yw'r swyddogaeth graddio awtomatig yng nghyd-destun K8s yn dasg gwbl amlwg o hyd. Pan ddechreuais astudio, ni wnes i ddod o hyd i unrhyw ganllawiau ymarferol nac argymhellion. Ar ôl sawl astudiaeth ac arbrofion gyda chefnogaeth tîm DevOps, fe wnaethom ddewis y dull o godi cynwysyddion gyda'r porwyr angenrheidiol y tu mewn i un pod, sydd wedi'i leoli y tu mewn i un nod gweithiwr. Mae'r dull hwn yn ein galluogi i gymhwyso'r strategaeth o raddio nodau'n llorweddol trwy gynyddu eu nifer. Rwy'n gobeithio y bydd hyn yn newid yn y dyfodol a byddwn yn gweld mwy a mwy o ddisgrifiadau o ddulliau gwell ac atebion parod, yn enwedig ar ôl rhyddhau grid Seleniwm 4 gyda phensaernïaeth fewnol wedi'i newid.
Selenoid:
Y siom fwyaf yw defnyddio selenoid yn K8s ar hyn o bryd. Nid ydynt yn gydnaws. Mewn theori, gallwn godi cynhwysydd Selenoid y tu mewn i god, ond pan fydd Selenoid yn dechrau lansio cynwysyddion gyda phorwyr, byddant yn dal i fod y tu mewn i'r un pod. Mae hyn yn gwneud graddio yn amhosibl ac, o ganlyniad, ni fydd gwaith Selenoid y tu mewn i glwstwr yn wahanol i waith y tu mewn i beiriant rhithwir. Diwedd y stori.
Moon:
Gan wybod y dagfa hon wrth weithio gyda Selenoid, rhyddhaodd y datblygwyr offeryn mwy pwerus o'r enw Moon. Dyluniwyd yr offeryn hwn yn wreiddiol i weithio gyda Kubernetes ac, o ganlyniad, gellir a dylid defnyddio'r nodwedd graddio awtomatig. Ar ben hynny, byddwn yn dweud hynny ar hyn o bryd yr unig teclyn yn y byd Seleniwm, sydd â chefnogaeth clwstwr brodorol K8s allan o'r bocs (ddim ar gael bellach, gweler yr offeryn nesaf ). Nodweddion allweddol Moon sy'n darparu'r gefnogaeth hon yw:
Hollol ddi-wladwriaeth. Mae Selenoid yn storio gwybodaeth cof am sesiynau porwr sy'n rhedeg ar hyn o bryd. Os bydd ei broses yn chwalu am ryw reswm - yna mae'r holl sesiynau rhedeg yn cael eu colli. Yn groes, nid oes gan Moon gyflwr mewnol a gellir ei ailadrodd ar draws canolfannau data. Mae sesiynau porwr yn parhau'n fyw hyd yn oed os bydd un neu fwy o gopïau'n mynd i lawr.
Felly, mae Moon yn ateb gwych, ond mae un broblem: nid yw'n rhad ac am ddim. Mae'r pris yn dibynnu ar nifer y sesiynau. Dim ond 0-4 sesiwn y gallwch chi eu cynnal am ddim, sydd ddim yn arbennig o ddefnyddiol. Ond, gan ddechrau o'r bumed sesiwn, bydd yn rhaid i chi dalu $5 yr un. Gall y sefyllfa amrywio o gwmni i gwmni, ond yn ein hachos ni, mae defnyddio Moon yn ddibwrpas. Fel y disgrifiais uchod, gallwn redeg VMs gyda Grid Seleniwm ar alw neu gynyddu nifer y Nodau yn y clwstwr. Ar gyfer tua un biblinell, rydym yn lansio 500 o borwyr ac yn atal yr holl adnoddau ar ôl i'r profion gael eu cwblhau. Pe baem ni'n defnyddio Moon, byddai'n rhaid i ni dalu 500 x 5 = $ 2500 ychwanegol y mis, ni waeth pa mor aml rydyn ni'n cynnal profion. Unwaith eto, nid wyf yn dweud peidiwch â defnyddio Moon. Ar gyfer eich tasgau, gall hwn fod yn ateb anhepgor, er enghraifft, os oes gennych lawer o brosiectau/timau yn eich sefydliad a bod angen clwstwr cyffredin enfawr arnoch i bawb. Fel bob amser, rwy'n gadael dolen ar y diwedd ac yn argymell gwneud yr holl gyfrifiadau angenrheidiol yng nghyd-destun eich tasg.
Callisto: (Sylw! Nid yw hyn yn yr erthygl wreiddiol ac mae wedi'i gynnwys yn y cyfieithiad Rwsieg yn unig)
Fel y dywedais, mae Seleniwm yn arf poblogaidd iawn, ac mae’r maes TG yn datblygu’n gyflym iawn. Tra roeddwn i'n gweithio ar y cyfieithiad, ymddangosodd teclyn addawol newydd o'r enw Callisto ar y we (helo Cypress and other Selenium killers). Mae'n gweithio'n frodorol gyda K8s ac yn caniatáu ichi redeg cynwysyddion Selenoid mewn codennau, wedi'u dosbarthu ar draws Nodes. Mae popeth yn gweithio allan o'r bocs, gan gynnwys awtoscaling. Gwych, ond mae angen ei brofi. Rwyf eisoes wedi llwyddo i ddefnyddio'r offeryn hwn a rhedeg sawl arbrawf. Ond mae'n rhy gynnar i ddod i gasgliadau, ar ôl derbyn canlyniadau dros bellter maith, efallai y gwnaf adolygiad mewn erthyglau yn y dyfodol. Am y tro rwy'n gadael dim ond dolenni ar gyfer ymchwil annibynnol.
Darlun o gyflwr presennol yr isadeiledd
Dolenni i archwilio
Offer tebyg
7. Isadeiledd fel Cod (IaC)
Disgrifiad byr o'r dechnoleg
Ac yn awr rydym yn dod at yr adran olaf. Yn nodweddiadol, nid cyfrifoldeb peirianwyr awtomeiddio yw'r dechnoleg hon a thasgau cysylltiedig. Ac mae yna resymau am hyn. Yn gyntaf, mewn llawer o sefydliadau, mae materion seilwaith o dan reolaeth yr adran DevOps ac nid yw'r timau datblygu yn poeni mewn gwirionedd beth sy'n gwneud i'r biblinell weithio a sut mae angen cefnogi popeth sy'n gysylltiedig ag ef. Yn ail, gadewch i ni fod yn onest, nid yw'r arfer o Seilwaith fel Cod (IaC) yn cael ei fabwysiadu o hyd mewn llawer o gwmnïau. Ond yn bendant mae wedi dod yn duedd boblogaidd ac mae'n bwysig ceisio bod yn rhan o'r prosesau, y dulliau a'r offer sy'n gysylltiedig ag ef. Neu o leiaf cadwch yn gyfoes.
Gadewch i ni ddechrau gyda'r cymhelliant dros ddefnyddio'r dull hwn. Rydym eisoes wedi trafod y bydd angen o leiaf yr adnoddau i redeg Gitlab Runner i gynnal profion yn GitlabCI. Ac i redeg cynwysyddion gyda phorwyr / efelychwyr, mae angen i ni gadw VM neu glwstwr. Yn ogystal â phrofi adnoddau, mae angen cryn dipyn o gapasiti arnom i gefnogi datblygiad, llwyfannu, amgylcheddau cynhyrchu, sydd hefyd yn cynnwys cronfeydd data, amserlenni awtomatig, ffurfweddiadau rhwydwaith, balanswyr llwyth, hawliau defnyddwyr, ac ati. Y mater allweddol yw'r ymdrech sydd ei angen i gefnogi'r cyfan. Mae sawl ffordd y gallwn wneud newidiadau a chyflwyno diweddariadau. Er enghraifft, yng nghyd-destun GCP, gallwn ddefnyddio'r consol UI yn y porwr a chyflawni'r holl gamau gweithredu trwy glicio botymau. Dewis arall fyddai defnyddio galwadau API i ryngweithio ag endidau cwmwl, neu ddefnyddio'r cyfleustodau llinell orchymyn gcloud i gyflawni'r triniaethau a ddymunir. Ond gyda nifer fawr iawn o wahanol endidau ac elfennau seilwaith, mae'n dod yn anodd neu hyd yn oed yn amhosibl cyflawni'r holl weithrediadau â llaw. Ar ben hynny, mae'r holl gamau gweithredu hyn â llaw yn afreolus. Ni allwn eu cyflwyno i'w hadolygu cyn eu gweithredu, defnyddio system rheoli fersiynau, a dychwelyd yn gyflym y newidiadau a arweiniodd at y digwyddiad. Er mwyn datrys problemau o'r fath, creodd peirianwyr a chreu sgriptiau bash/cragen awtomatig, nad ydynt yn llawer gwell na dulliau blaenorol, gan nad ydynt mor hawdd i'w darllen, eu deall, eu cynnal a'u haddasu'n gyflym mewn arddull gweithdrefnol.
Yn yr erthygl hon a chanllaw sut i, rwy'n defnyddio 2 offeryn sy'n gysylltiedig ag ymarfer IaC. Y rhain yw Terraform ac Ansible. Mae rhai pobl yn credu nad yw'n gwneud unrhyw synnwyr i'w defnyddio ar yr un pryd, gan fod eu swyddogaeth yn debyg ac yn gyfnewidiol. Ond y ffaith yw eu bod yn cael tasgau hollol wahanol i ddechrau. A chadarnhawyd y ffaith y dylai'r offer hyn ategu ei gilydd mewn cyflwyniad ar y cyd gan ddatblygwyr sy'n cynrychioli HashiCorp a RedHat. Y gwahaniaeth cysyniadol yw bod Terraform yn offeryn darparu ar gyfer rheoli'r gweinyddwyr eu hunain. Er bod Ansible yn offeryn rheoli cyfluniad a'i dasg yw gosod, ffurfweddu a rheoli meddalwedd ar y gweinyddwyr hyn.
Nodwedd wahaniaethol allweddol arall o'r offer hyn yw'r arddull codio. Yn wahanol i bash ac Ansible, mae Terraform yn defnyddio arddull ddatganiadol yn seiliedig ar ddisgrifiad o'r cyflwr terfynol dymunol i'w gyflawni o ganlyniad i gyflawni. Er enghraifft, os ydym am greu 10 VM a chymhwyso'r newidiadau trwy Terraform, yna byddwn yn cael 10 VM. Os byddwn yn rhedeg y sgript eto, ni fydd dim yn digwydd gan fod gennym eisoes 10 VMs, ac mae Terraform yn gwybod am hyn oherwydd ei fod yn storio cyflwr presennol y seilwaith mewn ffeil cyflwr. Ond mae Ansible yn defnyddio dull gweithdrefnol ac, os gofynnwch iddo greu 10 VM, yna ar y lansiad cyntaf byddwn yn cael 10 VM, yn debyg i Terraform. Ond ar ôl ailgychwyn bydd gennym ni 20 VM yn barod. Dyma'r gwahaniaeth pwysig. Mewn arddull gweithdrefnol, nid ydym yn storio'r cyflwr presennol ac yn syml yn disgrifio dilyniant o gamau y mae'n rhaid eu perfformio. Wrth gwrs, gallwn ymdrin â sefyllfaoedd amrywiol, ychwanegu sawl siec am fodolaeth adnoddau a'r cyflwr presennol, ond nid oes diben gwastraffu ein hamser a rhoi ymdrech i reoli'r rhesymeg hon. Yn ogystal, mae hyn yn cynyddu'r risg o wneud camgymeriadau.
Gan grynhoi pob un o'r uchod, gallwn ddod i'r casgliad bod Terraform a nodiant datganiadol yn arf mwy addas ar gyfer darparu gweinyddwyr. Ond mae'n well dirprwyo'r gwaith o reoli cyfluniad i Ansible. Gyda hynny allan o'r ffordd, gadewch i ni edrych ar achosion defnydd yng nghyd-destun awtomeiddio.
Gwerth am seilwaith awtomeiddio
Yr unig beth pwysig i'w ddeall yma yw y dylid ystyried y seilwaith awtomeiddio prawf fel rhan o seilwaith cyfan y cwmni. Mae hyn yn golygu bod yn rhaid i holl arferion IaC gael eu cymhwyso'n fyd-eang i adnoddau'r sefydliad cyfan. Mae pwy sy'n gyfrifol am hyn yn dibynnu ar eich prosesau. Mae tîm DevOps yn fwy profiadol yn y materion hyn, maent yn gweld y darlun cyfan o'r hyn sy'n digwydd. Fodd bynnag, mae peirianwyr SA yn cymryd mwy o ran yn y broses o awtomeiddio adeiladu a strwythur y biblinell, sy'n caniatáu iddynt weld yr holl newidiadau gofynnol a chyfleoedd ar gyfer gwella yn well. Yr opsiwn gorau yw cydweithio, cyfnewid gwybodaeth a syniadau i gyflawni'r canlyniad disgwyliedig.
Dyma rai enghreifftiau o ddefnyddio Terraform ac Ansible yng nghyd-destun awtomeiddio prawf a'r offer a drafodwyd gennym o'r blaen:
1. Disgrifiwch nodweddion a pharamedrau angenrheidiol VMs a chlystyrau gan ddefnyddio Terraform.
2. Gan ddefnyddio Ansible, gosodwch yr offer angenrheidiol ar gyfer profi: docker, Selenoid, Selenium Grid a lawrlwythwch y fersiynau gofynnol o borwyr/efelychwyr.
3. Gan ddefnyddio Terraform, disgrifiwch nodweddion y VM y bydd GitLab Runner yn cael ei lansio ynddo.
4. Gosod GitLab Runner a'r offer cysylltiedig angenrheidiol gan ddefnyddio Ansible, gosodiadau gosod a ffurfweddau.
Darlun o gyflwr presennol yr isadeiledd
Dolenni i archwilio:
Offer tebyg
Gadewch i ni ei grynhoi!
Cam
Technoleg
offer
Gwerth am seilwaith awtomeiddio
1
Rhedeg lleol
Node.js, Selenium, Appium
- Yr offer mwyaf poblogaidd ar gyfer gwe a symudol
- Yn cefnogi llawer o ieithoedd a llwyfannau (gan gynnwys Node.js)
2
Systemau rheoli fersiwn
mynd
- Buddion tebyg gyda chod datblygu
3
Containerization
Dociwr, grid Seleniwm, Selenoid (Gwe, Android)
- Cynnal profion ochr yn ochr
- Amgylcheddau ynysig
- Uwchraddiadau fersiwn syml, hyblyg
- Rhoi'r gorau i adnoddau nas defnyddir yn ddeinamig
- Hawdd i'w sefydlu
4
CI/CD
Gitlab CI
- Yn profi rhan o'r biblinell
- Adborth Cyflym
- Gwelededd ar gyfer y cwmni/tîm cyfan
5
Llwyfannau Cloud
Llwyfan Google Cloud
- Adnoddau ar gais (dim ond pan fo angen y byddwn yn talu)
- Hawdd i'w reoli a'i ddiweddaru
- Amlygrwydd a rheolaeth ar yr holl adnoddau
6
Cerddorfa
Kubernetes
Yng nghyd-destun cynwysyddion gyda phorwyr/efelychwyr y tu mewn i godau:
- Graddio / graddio'n awtomatig
- Hunan-iachau
- Diweddariadau a dychweliadau heb ymyrraeth
7
Isadeiledd fel cod (IaC)
Terraform, Asible
- Manteision tebyg gyda seilwaith datblygu
- Holl fanteision fersiwn cod
- Hawdd i wneud newidiadau a chynnal
- Wedi'i awtomeiddio'n llawn
Diagramau map meddwl: esblygiad seilwaith
cam1: Lleol
cam 2: VCS
cam 3: Containerization
cam 4: CI / CD
cam5: Platfformau Cwmwl
cam 6: Cerddorfa
cam7: IaC
Beth sydd nesaf?
Felly, dyma ddiwedd yr erthygl. Ond i gloi, hoffwn sefydlu rhai cytundebau gyda chi.
O'ch ochr chi
Fel y dywedais ar y dechrau, hoffwn i'r erthygl fod o ddefnydd ymarferol a'ch helpu i gymhwyso'r wybodaeth a gafwyd mewn gwaith go iawn. Rwy'n ychwanegu eto.
Ond hyd yn oed ar ôl hynny, peidiwch â stopio, ymarfer, astudio dolenni a llyfrau perthnasol, darganfod sut mae'n gweithio yn eich cwmni, dod o hyd i leoedd y gellir eu gwella a chymryd rhan ynddo. Pob lwc!
O fy ochr
O'r teitl gallwch weld mai dim ond y rhan gyntaf oedd hon. Er gwaethaf y ffaith ei fod yn troi allan i fod yn eithaf mawr, nid yw pynciau pwysig yn cael sylw yma o hyd. Yn yr ail ran, rwy'n bwriadu edrych ar seilwaith awtomeiddio yng nghyd-destun IOS. Oherwydd cyfyngiadau Apple ar redeg efelychwyr iOS yn unig ar systemau macOS, mae ein hystod o atebion wedi'u culhau. Er enghraifft, ni allwn ddefnyddio Docker i redeg yr efelychydd na chymylau cyhoeddus i redeg peiriannau rhithwir. Ond nid yw hyn yn golygu nad oes unrhyw ddewisiadau eraill. Byddaf yn ceisio rhoi'r wybodaeth ddiweddaraf i chi am atebion datblygedig ac offer modern!
Hefyd, nid wyf wedi crybwyll pynciau eithaf mawr yn ymwneud â monitro. Yn Rhan 3, rydw i'n mynd i edrych ar yr offer monitro seilwaith mwyaf poblogaidd a pha ddata a metrigau i'w hystyried.
Ac yn olaf. Yn y dyfodol, rwy'n bwriadu rhyddhau cwrs fideo ar adeiladu seilwaith prawf ac offer poblogaidd. Ar hyn o bryd, mae cryn dipyn o gyrsiau a darlithoedd ar DevOps ar y Rhyngrwyd, ond cyflwynir yr holl ddeunyddiau yng nghyd-destun datblygu, nid awtomeiddio prawf. Ar y mater hwn, mae gwir angen adborth arnaf ynghylch a fydd cwrs o'r fath yn ddiddorol ac yn werthfawr i'r gymuned o brofwyr a pheirianwyr awtomeiddio. Diolch ymlaen llaw!
Ffynhonnell: hab.com