Rydym ni yn True Engineering wedi sefydlu proses ar gyfer cyflwyno diweddariadau parhaus i weinyddion cwsmeriaid ac rydym am rannu'r profiad hwn.
I ddechrau, rydym wedi datblygu system ar-lein ar gyfer y cwsmer a'i defnyddio yn ein clwstwr Kubernetes ein hunain. Nawr mae ein datrysiad llwyth uchel wedi symud i blatfform y cwsmer, ac rydym wedi sefydlu proses Defnydd Parhaus cwbl awtomatig ar ei gyfer. Diolch i hyn, gwnaethom gyflymu'r amser-i-farchnad - cyflwyno newidiadau i'r amgylchedd cynnyrch.
Yn yr erthygl hon byddwn yn siarad am bob cam o'r broses Defnydd Parhaus (CD) neu gyflwyno diweddariadau i blatfform y cwsmer:
- Sut mae'r broses hon yn dechrau?
- cydamseru ag ystorfa Git y cwsmer,
- cydosod pen Γ΄l a blaen,
- defnyddio cymhwysiad awtomatig mewn amgylchedd prawf,
- defnydd awtomatig i Prod.
Byddwn yn rhannu'r manylion gosod ar hyd y ffordd.
1. Dechrau CD
Mae Defnydd Parhaus yn dechrau gyda'r datblygwr yn gwthio newidiadau i gangen rhyddhau ein cadwrfa Git.
Mae ein cymhwysiad yn rhedeg ar bensaernΓ―aeth microwasanaeth ac mae ei holl gydrannau'n cael eu storio mewn un ystorfa. Diolch i hyn, mae'r holl ficrowasanaethau yn cael eu casglu a'u gosod, hyd yn oed os yw un ohonynt wedi newid.
Fe wnaethom drefnu gwaith trwy un gadwrfa am sawl rheswm:
- Rhwyddineb datblygu - mae'r cymhwysiad yn datblygu'n weithredol, felly gallwch chi weithio gyda'r holl god ar unwaith.
- Piblinell CI / CD sengl sy'n gwarantu bod y cais fel un system yn pasio pob prawf ac yn cael ei gyflwyno i amgylchedd cynhyrchu'r cwsmer.
- Rydym yn dileu dryswch mewn fersiynau - nid oes rhaid i ni storio map o fersiynau microservice a disgrifio ei ffurfweddiad ar gyfer pob microservice yn sgriptiau Helm.
2. Cydamseru Γ’ storfa Git cod ffynhonnell y cwsmer
Mae newidiadau a wneir yn cael eu cysoni'n awtomatig Γ’ storfa Git y cwsmer. Yno mae'r cynulliad cais wedi'i ffurfweddu, sy'n cael ei lansio ar Γ΄l diweddaru'r gangen, a'i ddefnyddio i'r parhad. Mae'r ddwy broses yn tarddu o'u hamgylchedd o gadwrfa Git.
Ni allwn weithio gyda storfa'r cwsmer yn uniongyrchol oherwydd mae angen ein hamgylcheddau ein hunain ar gyfer datblygu a phrofi. Rydym yn defnyddio ein cadwrfa Git at y dibenion hyn - mae wedi'i gydamseru Γ’'u cadwrfa Git. Cyn gynted ag y bydd datblygwr yn postio newidiadau i gangen briodol ein cadwrfa, mae GitLab yn gwthio'r newidiadau hyn i'r cwsmer ar unwaith.
Ar Γ΄l hyn mae angen i chi wneud y cynulliad. Mae'n cynnwys sawl cam: cynulliad cefn a blaen, profi a danfon i'r cynhyrchiad.
3. Cydosod y pen Γ΄l a'r blaen
Mae adeiladu'r pen Γ΄l a'r blaen yn ddwy dasg gyfochrog sy'n cael eu perfformio yn system GitLab Runner. Mae ei ffurfweddiad cynulliad gwreiddiol wedi'i leoli yn yr un ystorfa.
.
Mae GitLab Runner yn cymryd y cod o'r ystorfa ofynnol, yn ei ymgynnull gyda'r gorchymyn adeiladu cymhwysiad Java a'i anfon i gofrestrfa Docker. Yma rydyn ni'n cydosod y backend a'r blaen, yn cael delweddau Docker, rydyn ni'n eu rhoi mewn ystorfa ar ochr y cwsmer. I reoli delweddau Docker rydym yn eu defnyddio .
Rydym yn cydamseru'r fersiynau o'n delweddau Γ’'r fersiwn rhyddhau a fydd yn cael ei chyhoeddi yn Docker. Ar gyfer gweithrediad llyfn rydym wedi gwneud nifer o addasiadau:
1. Nid yw cynwysyddion yn cael eu hailadeiladu rhwng yr amgylchedd prawf a'r amgylchedd cynhyrchu. Gwnaethom barametrizations fel y gallai'r un cynhwysydd weithio gyda'r holl leoliadau, newidynnau amgylchedd a gwasanaethau yn yr amgylchedd prawf ac wrth gynhyrchu heb ailadeiladu.
2. I ddiweddaru cais drwy Helm, rhaid ichi nodi ei fersiwn. Rydyn ni'n adeiladu'r backend, y blaen ac yn diweddaru'r rhaglen - mae'r rhain yn dair tasg wahanol, felly mae'n bwysig defnyddio'r un fersiwn o'r rhaglen ym mhobman. Ar gyfer y dasg hon, rydym yn defnyddio data o hanes Git, gan fod ein cyfluniad clwstwr K8S a'n cymwysiadau yn yr un ystorfa Git.
Rydym yn cael y fersiwn cais o'r canlyniadau gweithredu gorchymyn
git describe --tags --abbrev=7.
4. Defnydd awtomatig o'r holl newidiadau i'r amgylchedd prawf (UAT)
Y cam nesaf yn y sgript adeiladu hon yw diweddaru'r clwstwr K8S yn awtomatig. Mae hyn yn digwydd ar yr amod bod y cymhwysiad cyfan wedi'i adeiladu a bod yr holl arteffactau wedi'u cyhoeddi i Gofrestrfa'r Docwyr. Ar Γ΄l hyn, mae'r diweddariad amgylchedd prawf yn dechrau.
Mae'r diweddariad clwstwr yn dechrau defnyddio . Os, o ganlyniad, nad aeth rhywbeth yn unol Γ’'r cynllun, bydd Helm yn dychwelyd ei holl newidiadau yn awtomatig ac yn annibynnol. Nid oes angen rheoli ei waith.
Rydym yn cyflenwi cyfluniad clwstwr K8S ynghyd Γ’'r cynulliad. Felly, y cam nesaf yw ei ddiweddaru: configMaps, defnydd, gwasanaethau, cyfrinachau ac unrhyw ffurfweddiadau K8S eraill yr ydym wedi'u newid.
Yna mae Helm yn rhedeg diweddariad Cyflwyno'r cais ei hun yn yr amgylchedd prawf. Cyn i'r cais gael ei ddefnyddio i gynhyrchu. Gwneir hyn fel y gall defnyddwyr brofi'r nodweddion busnes a roddwn yn yr amgylchedd prawf Γ’ llaw.
5. Defnydd awtomatig o'r holl newidiadau i Prod
I ddefnyddio diweddariad i'r amgylchedd cynhyrchu, does ond angen i chi glicio un botwm yn GitLab - ac mae'r cynwysyddion yn cael eu danfon ar unwaith i'r amgylchedd cynhyrchu.
Gall yr un cymhwysiad weithio mewn gwahanol amgylcheddau - profi a chynhyrchu - heb ailadeiladu. Rydym yn defnyddio'r un arteffactau heb newid unrhyw beth yn y cais, ac rydym yn gosod y paramedrau yn allanol.
Mae parameterization hyblyg o osodiadau cais yn dibynnu ar yr amgylchedd y bydd y cais yn cael ei weithredu ynddo. Rydym wedi symud yr holl osodiadau amgylchedd yn allanol: mae popeth wedi'i baramedroli trwy gyfluniad K8S a pharamedrau Helm. Pan fydd Helm yn defnyddio cynulliad i'r amgylchedd prawf, mae'r gosodiadau prawf yn cael eu cymhwyso iddo, ac mae gosodiadau'r cynnyrch yn cael eu cymhwyso i'r amgylchedd cynhyrchu.
Y peth anoddaf oedd paramedreiddio'r holl wasanaethau a newidynnau a ddefnyddir sy'n dibynnu ar yr amgylchedd, a'u trosi'n newidynnau amgylchedd a disgrifiad-ffurfweddiadau paramedrau amgylchedd Helm.
Mae gosodiadau cymhwysiad yn defnyddio newidynnau amgylchedd. Mae eu gwerthoedd yn cael eu gosod mewn cynwysyddion gan ddefnyddio configmap K8S, sy'n cael ei dempled gan ddefnyddio templedi Go. Er enghraifft, gellir gosod newidyn amgylchedd i'r enw parth fel hyn:
APP_EXTERNAL_DOMAIN: {{ (pluck .Values.global.env .Values.app.properties.app_external_domain | first) }}
.gwerthoedd.global.env β mae'r newidyn hwn yn storio enw'r amgylchedd (prod, stage, UAT).
.Gwerthoedd.app.properties.app_external_domain β yn y newidyn hwn rydym yn gosod y parth dymunol yn y ffeil .Values.yaml
Wrth ddiweddaru cais, mae Helm yn creu ffeil configmap.yaml o dempledi ac yn llenwi'r gwerth APP_EXTERNAL_DOMAIN gyda'r gwerth dymunol yn dibynnu ar yr amgylchedd y mae diweddariad y cais yn cychwyn ynddo. Mae'r newidyn hwn eisoes wedi'i osod yn y cynhwysydd. Gellir ei gyrchu o'r cais, felly bydd gan bob amgylchedd cais werth gwahanol ar gyfer y newidyn hwn.
Yn gymharol ddiweddar, ymddangosodd cefnogaeth K8S yn Spring Cloud, gan gynnwys gwaith gyda configMaps: . Er bod y prosiect wrthi'n datblygu ac yn newid yn radical, ni allwn ei ddefnyddio wrth gynhyrchu. Ond rydym yn monitro ei gyflwr yn weithredol ac yn ei ddefnyddio mewn ffurfweddiadau DEV. Cyn gynted ag y bydd yn sefydlogi, byddwn yn newid o ddefnyddio newidynnau amgylchedd iddo.
Yn gyfan gwbl
Felly, mae Defnydd Parhaus wedi'i ffurfweddu ac yn gweithio. Mae pob diweddariad yn digwydd gydag un trawiad bysell. Mae cyflwyno newidiadau i'r amgylchedd cynnyrch yn awtomatig. Ac, yn bwysig, nid yw diweddariadau yn atal y system.
Cynlluniau ar gyfer y dyfodol: mudo cronfa ddata awtomatig
Fe wnaethom feddwl am uwchraddio'r gronfa ddata a'r posibilrwydd o gyflwyno'r newidiadau hyn yn Γ΄l. Wedi'r cyfan, mae dwy fersiwn wahanol o'r cais yn rhedeg ar yr un pryd: mae'r hen un yn rhedeg, ac mae'r un newydd ar ben. A byddwn yn diffodd yr hen un dim ond pan fyddwn yn sicr bod y fersiwn newydd yn gweithio. Dylai mudo cronfa ddata eich galluogi i weithio gyda'r ddau fersiwn o'r rhaglen.
Felly, ni allwn newid enw'r golofn na data arall yn unig. Ond gallwn greu colofn newydd, copΓ―o data o'r hen golofn i mewn iddi ac ysgrifennu sbardunau a fydd, wrth ddiweddaru'r data, yn ei gopΓ―o a'i ddiweddaru mewn colofn arall ar yr un pryd. Ac ar Γ΄l defnyddio'r fersiwn newydd o'r cais yn llwyddiannus, ar Γ΄l y cyfnod cymorth ar Γ΄l lansio, byddwn yn gallu dileu'r hen golofn a'r sbardun sydd wedi dod yn ddiangen.
Os nad yw'r fersiwn newydd o'r rhaglen yn gweithio'n gywir, gallwn rolio'n Γ΄l i'r fersiwn flaenorol, gan gynnwys fersiwn flaenorol y gronfa ddata. Yn fyr, bydd ein newidiadau yn caniatΓ‘u ichi weithio ar yr un pryd Γ’ sawl fersiwn o'r cais.
Rydym yn bwriadu awtomeiddio mudo cronfa ddata trwy swydd K8S, gan ei integreiddio i'r broses CD. A byddwn yn bendant yn rhannu'r profiad hwn ar HabrΓ©.
Ffynhonnell: hab.com