Nodyn. traws.: Yn y gymuned Kubernetes, mae tuedd o'r enw GitOps yn ennill poblogrwydd amlwg, fel y gwelsom yn bersonol, KubeCon Europe 2019. Roedd y tymor hwn yn gymharol ddiweddar gan bennaeth Weaveworks - Alexis Richardson - ac mae'n golygu defnyddio offer sy'n gyfarwydd i ddatblygwyr (Git yn bennaf, felly'r enw) i ddatrys problemau gweithredol. Yn benodol, rydym yn sôn am weithrediad Kubernetes trwy storio ei ffurfweddiadau yn Git a chyflwyno newidiadau i'r clwstwr yn awtomatig. Mae Matthias Jg yn sôn am ddau ddull o gyflwyno hyn yn yr erthygl hon.
Y llynedd, (yn wir, digwyddodd hyn yn ffurfiol ym mis Awst 2017 - tua. transl.) Mae yna ddull newydd o ddefnyddio ceisiadau yn Kubernetes. Fe'i gelwir yn GitOps, ac mae'n seiliedig ar y syniad sylfaenol bod fersiynau defnydd yn cael eu holrhain yn amgylchedd diogel ystorfa Git.
Mae prif fanteision y dull hwn fel a ganlyn::
- Fersiynau lleoli a hanes newid. Mae cyflwr y clwstwr cyfan yn cael ei storio mewn ystorfa Git, a dim ond trwy ymrwymiadau y caiff gosodiadau eu diweddaru. Yn ogystal, gellir olrhain yr holl newidiadau gan ddefnyddio'r hanes ymrwymo.
- Dychlamiadau gan ddefnyddio gorchmynion Git cyfarwydd. Syml
git resetyn eich galluogi i ailosod newidiadau mewn gosodiadau; mae taleithiau'r gorffennol bob amser ar gael. - Rheolaeth mynediad parod. Yn nodweddiadol, mae system Git yn cynnwys llawer o ddata sensitif, felly mae'r rhan fwyaf o gwmnïau'n rhoi sylw arbennig i'w warchod. Yn unol â hynny, mae'r amddiffyniad hwn hefyd yn berthnasol i weithrediadau gyda lleoliadau.
- Polisïau ar gyfer Defnyddio. Mae'r rhan fwyaf o systemau Git yn cefnogi polisïau cangen-wrth-gangen yn frodorol - er enghraifft, dim ond ceisiadau tynnu all ddiweddaru meistr, a rhaid i newidiadau gael eu hadolygu a'u derbyn gan aelod arall o'r tîm. Yn yr un modd â rheoli mynediad, mae'r un polisïau'n berthnasol i ddiweddariadau lleoli.
Fel y gallwch weld, mae yna lawer o fanteision i'r dull GitOps. Dros y flwyddyn ddiwethaf, mae dau ddull wedi dod yn arbennig o boblogaidd. Mae un yn seiliedig ar wthio, mae'r llall yn seiliedig ar dynnu. Cyn i ni edrych arnyn nhw, gadewch i ni edrych yn gyntaf ar sut olwg sydd ar leoliadau Kubernetes nodweddiadol.
Dulliau Defnyddio
Yn ystod y blynyddoedd diwethaf, mae gwahanol ddulliau ac offer ar gyfer defnyddio wedi'u sefydlu yn Kubernetes:
- Yn seiliedig ar dempledi brodorol Kubernetes/Kustomize. Dyma'r ffordd hawsaf o ddefnyddio cymwysiadau ar Kubernetes. Mae'r datblygwr yn creu'r ffeiliau YAML sylfaenol ac yn eu cymhwyso. Er mwyn cael gwared ar ailysgrifennu'r un templedi yn gyson, datblygwyd Kustomize (mae'n troi templedi Kubernetes yn fodiwlau). Nodyn. traws.: Kustomize wedi cael ei integreiddio i kubectl gyda .
- Siartiau Helm. Mae siartiau Helm yn caniatáu ichi greu setiau o dempledi, cynwysyddion init, ceir ochr, ac ati, a ddefnyddir i ddefnyddio cymwysiadau gydag opsiynau addasu mwy hyblyg nag mewn dull seiliedig ar dempled. Mae'r dull hwn yn seiliedig ar ffeiliau YAML wedi'u templedi. Mae Helm yn eu llenwi â pharamedrau amrywiol ac yna'n eu hanfon at Tiller, cydran clwstwr sy'n eu defnyddio i'r clwstwr ac yn caniatáu diweddariadau a dychweliadau. Y peth pwysig yw bod Helm yn ei hanfod yn gosod y gwerthoedd dymunol yn y templedi ac yna'n eu cymhwyso yn yr un modd ag y gwneir yn y dull traddodiadol (darllenwch fwy am sut mae'r cyfan yn gweithio a sut y gallwch ei ddefnyddio yn ein - tua. cyfieithu.). Mae amrywiaeth eang o siartiau Helm parod sy'n cwmpasu ystod eang o dasgau.
- Offer Amgen. Mae yna lawer o offer amgen. Yr hyn sydd ganddynt i gyd yn gyffredin yw eu bod yn troi rhai ffeiliau templed yn ffeiliau YAML sy'n ddarllenadwy gan Kubernetes ac yna'n eu defnyddio.
Yn ein gwaith, rydym yn defnyddio siartiau Helm yn gyson ar gyfer offer pwysig (gan fod ganddyn nhw lawer o bethau'n barod, sy'n gwneud bywyd yn llawer haws) a ffeiliau Kubernetes YAML “pur” ar gyfer defnyddio ein cymwysiadau ein hunain.
Tynnu a Gwthio
Yn un o fy swyddi blog diweddar, cyflwynais yr offeryn , sy'n eich galluogi i ymrwymo templedi i ystorfa Git a diweddaru'r defnydd ar ôl pob ymrwymiad neu wthio'r cynhwysydd. Mae fy mhrofiad yn dangos bod yr offeryn hwn yn un o'r prif rai wrth hyrwyddo'r dull tynnu, felly byddaf yn aml yn cyfeirio ato. Os ydych chi eisiau gwybod mwy am sut i'w ddefnyddio, yma .
DS! Mae holl fanteision defnyddio GitOps yn aros yr un fath ar gyfer y ddau ddull.
Dull seiliedig ar dynnu
Mae'r dull tynnu yn seiliedig ar y ffaith bod pob newid yn cael ei gymhwyso o'r tu mewn i'r clwstwr. Mae gweithredwr y tu mewn i'r clwstwr sy'n gwirio'r storfeydd cysylltiedig â'r Gofrestrfa Git a Docker yn rheolaidd. Os bydd unrhyw newidiadau yn digwydd iddynt, caiff cyflwr y clwstwr ei ddiweddaru'n fewnol. Yn gyffredinol, ystyrir bod y broses hon yn ddiogel iawn, gan nad oes gan unrhyw gleient allanol fynediad at hawliau gweinyddwr clwstwr.
Manteision:
- Nid oes gan unrhyw gleient allanol hawliau i wneud newidiadau i'r clwstwr; caiff yr holl ddiweddariadau eu cyflwyno o'r tu mewn.
- Mae rhai offer hefyd yn caniatáu ichi gydamseru diweddariadau siart Helm a'u cysylltu â'r clwstwr.
- Gellir sganio Cofrestrfa Docker am fersiynau newydd. Os oes delwedd newydd ar gael, mae ystorfa a defnydd Git yn cael eu diweddaru i'r fersiwn newydd.
- Gellir dosbarthu offer tynnu ar draws gwahanol ofodau enwau gyda gwahanol storfeydd Git a chaniatâd. Diolch i hyn, gellir defnyddio model aml-denant. Er enghraifft, gallai tîm A ddefnyddio gofod enw A, gallai tîm B ddefnyddio gofod enw B, a gallai tîm seilwaith ddefnyddio gofod byd-eang.
- Fel rheol, mae'r offer yn ysgafn iawn.
- Wedi'i gyfuno ag offer fel gweithredwr , gellir storio cyfrinachau wedi'u hamgryptio mewn ystorfa Git a'u hadalw o fewn y clwstwr.
- Nid oes unrhyw gysylltiad â phiblinellau CD gan fod gosodiadau yn digwydd o fewn y clwstwr.
Cons:
- Mae rheoli cyfrinachau lleoli o siartiau Helm yn anoddach na rhai arferol, gan fod yn rhaid eu cynhyrchu yn gyntaf ar ffurf, dyweder, cyfrinachau wedi'u selio, yna eu dadgryptio gan weithredwr mewnol, a dim ond ar ôl hynny y byddant ar gael i'r teclyn tynnu. Yna gallwch chi redeg y datganiad yn Helm gyda'r gwerthoedd yn y cyfrinachau sydd eisoes wedi'u defnyddio. Y ffordd hawsaf yw creu cyfrinach gyda'r holl werthoedd Helm a ddefnyddir ar gyfer ei ddefnyddio, ei ddadgryptio a'i ymrwymo i Git.
- Pan fyddwch chi'n cymryd ymagwedd dynnu, rydych chi'n dod yn gaeth i offer tynnu. Mae hyn yn cyfyngu ar y gallu i addasu'r broses leoli mewn clwstwr. Er enghraifft, mae Kustomize yn cael ei gymhlethu gan y ffaith bod yn rhaid iddo redeg cyn i'r templedi terfynol ymrwymo i Git. Nid wyf yn dweud na allwch ddefnyddio offer annibynnol, ond maent yn fwy anodd eu hintegreiddio i'ch proses defnyddio.
Ymagwedd sy'n seiliedig ar wthio
Yn y dull gwthio, mae system allanol (piblinellau CD yn bennaf) yn lansio gosodiadau i'r clwstwr ar ôl ymrwymo i ystorfa Git neu os yw'r biblinell CI flaenorol yn llwyddiannus. Yn y dull hwn, mae gan y system fynediad i'r clwstwr.
Manteision:
- Pennir diogelwch gan ystorfa Git a phiblinell adeiladu.
- Mae'n haws defnyddio siartiau Helm ac mae'n cefnogi ategion Helm.
- Mae'n haws rheoli cyfrinachau oherwydd gellir defnyddio cyfrinachau mewn piblinellau a gellir eu storio hefyd wedi'u hamgryptio yn Git (yn dibynnu ar ddewisiadau'r defnyddiwr).
- Nid oes unrhyw gysylltiad ag offeryn penodol, oherwydd gellir defnyddio unrhyw fath.
- Gellir cychwyn diweddariadau fersiwn cynhwysydd gan y biblinell adeiladu.
Cons:
- Mae data mynediad y clwstwr y tu mewn i'r system adeiladu.
- Mae diweddaru cynwysyddion lleoli yn dal yn haws gyda phroses dynnu.
- Dibyniaeth drom ar y system CD, oherwydd efallai bod y piblinellau sydd eu hangen arnom wedi'u hysgrifennu'n wreiddiol ar gyfer Gitlab Runners, ac yna mae'r tîm yn penderfynu symud i Azure DevOps neu Jenkins ... a bydd yn rhaid iddynt symud nifer fawr o bibellau adeiladu.
Canlyniadau: Gwthio neu Dynnu?
Fel sy'n digwydd fel arfer, mae gan bob dull ei fanteision a'i anfanteision. Mae rhai tasgau yn haws i'w cyflawni gydag un ac yn fwy anodd ag un arall. Ar y dechrau roeddwn i'n gwneud gosodiadau â llaw, ond ar ôl i mi ddod ar draws ychydig o erthyglau am Weave Flux, penderfynais weithredu prosesau GitOps ar gyfer pob prosiect. Ar gyfer templedi sylfaenol roedd hyn yn hawdd, ond yna dechreuais fynd i drafferthion gyda siartiau Helm. Ar y pryd, dim ond fersiwn elfennol o'r Gweithredwr Siart Helm a gynigiodd Weave Flux, ond hyd yn oed nawr mae rhai tasgau'n anoddach oherwydd yr angen i greu cyfrinachau â llaw a'u cymhwyso. Gallech ddadlau bod y dull tynnu’n llawer mwy sicr oherwydd nad yw rhinweddau’r clwstwr yn hygyrch y tu allan i’r clwstwr, sy’n ei wneud yn llawer mwy sicr ei fod yn werth yr ymdrech ychwanegol.
Ar ôl peth meddwl, deuthum i'r casgliad annisgwyl nad yw hyn felly. Os byddwn yn siarad am gydrannau sydd angen yr amddiffyniad mwyaf, bydd y rhestr hon yn cynnwys storfa gyfrinachol, systemau CI / CD, a storfeydd Git. Mae'r wybodaeth y tu mewn iddynt yn agored iawn i niwed ac mae angen y diogelwch mwyaf posibl. Yn ogystal, os bydd rhywun yn mynd i mewn i'ch storfa Git ac yn gallu gwthio cod yno, gallant ddefnyddio beth bynnag y mae ei eisiau (p'un a yw'n dynnu neu'n gwthio) ac ymdreiddio i systemau'r clwstwr. Felly, y cydrannau pwysicaf y mae angen eu diogelu yw'r ystorfa Git a systemau CI/CD, nid y nodweddion clwstwr. Os oes gennych chi bolisïau a rheolaethau diogelwch wedi'u ffurfweddu'n dda ar gyfer y mathau hyn o systemau, a dim ond fel cyfrinachau y caiff rhinweddau clwstwr eu tynnu i'r piblinellau, efallai na fydd diogelwch ychwanegol dull tynnu mor werthfawr ag a feddyliwyd yn wreiddiol.
Felly, os yw'r dull tynnu yn fwy llafurddwys ac nad yw'n darparu budd diogelwch, onid yw'n rhesymegol defnyddio'r dull gwthio yn unig? Ond efallai y bydd rhywun yn dadlau eich bod chi'n rhy gaeth i'r system CD yn y dull gwthio ac, efallai, ei bod yn well peidio â gwneud hyn fel y bydd yn haws cyflawni mudo yn y dyfodol.
Yn fy marn i (fel bob amser), dylech ddefnyddio'r hyn sydd fwyaf addas ar gyfer achos penodol neu gyfuniad. Yn bersonol, rwy'n defnyddio'r ddau ddull: Weave Flux ar gyfer gosodiadau sy'n seiliedig ar dynnu sy'n cynnwys ein gwasanaethau ein hunain yn bennaf, a dull gwthio gyda Helm ac ategion, sy'n ei gwneud hi'n hawdd cymhwyso siartiau Helm i'r clwstwr ac sy'n eich galluogi i greu cyfrinachau yn ddi-dor. Rwy'n credu na fydd byth un ateb sy'n addas ar gyfer pob achos, oherwydd mae yna lawer o arlliwiau bob amser ac maen nhw'n dibynnu ar y cymhwysiad penodol. Wedi dweud hynny, rwy'n argymell GitOps yn fawr - mae'n gwneud bywyd yn llawer haws ac yn gwella diogelwch.
Rwy'n gobeithio y bydd fy mhrofiad ar y pwnc hwn yn eich helpu i benderfynu pa ddull sy'n fwyaf addas ar gyfer eich math o ddefnydd, a byddwn yn falch o glywed eich barn.
PS Nodyn gan y cyfieithydd
Anfantais y model tynnu yw ei bod hi'n anodd rhoi maniffestau wedi'u rendro yn Git, ond nid oes unrhyw anfantais bod y biblinell CD yn y model tynnu yn byw ar wahân i'r cyflwyniad ac yn ei hanfod yn dod yn biblinell categori. Parhaus Gwneud cais. Felly, bydd angen hyd yn oed mwy o ymdrech i gasglu eu statws o bob lleoliad a rhywsut darparu mynediad i logiau/statws, gan gyfeirio at y system CD yn ddelfrydol.
Yn yr ystyr hwn, mae'r model gwthio yn ein galluogi i ddarparu o leiaf rhai gwarantau o gyflwyno, oherwydd gellir gwneud oes y biblinell yn hafal i oes y cyflwyniad.
Fe wnaethon ni roi cynnig ar y ddau fodel a dod i'r un casgliadau ag awdur yr erthygl:
- Mae'r model tynnu yn addas i ni drefnu diweddariadau o gydrannau system ar nifer fawr o glystyrau (gweler. ).
- Mae'r model gwthio sy'n seiliedig ar GitLab CI yn addas iawn ar gyfer cyflwyno cymwysiadau gan ddefnyddio siartiau Helm. Ar yr un pryd, mae'r broses o gyflwyno gosodiadau o fewn piblinellau yn cael ei fonitro gan ddefnyddio'r offeryn . Gyda llaw, yng nghyd-destun y prosiect hwn o'n un ni, clywsom y “GitOps” cyson wrth drafod problemau enbyd peirianwyr DevOps yn ein stondin yn KubeCon Europe'19.
PPS gan y cyfieithydd
Darllenwch hefyd ar ein blog:
- «";
- «";
- «";
- «'.
Dim ond defnyddwyr cofrestredig all gymryd rhan yn yr arolwg. os gwelwch yn dda.
Ydych chi'n defnyddio GitOps?
-
Ie, dull tynnu
-
Ie, gwthio
-
Ie, tynnu + gwthio
-
Ie, rhywbeth arall
-
Dim
Pleidleisiodd 30 o ddefnyddwyr. Ataliodd 10 o ddefnyddwyr.
Ffynhonnell: hab.com