Mae pwnc monorepo wedi cael ei drafod sawl gwaith ac, fel rheol, mae'n achosi dadleuon eithaf bywiog. Fel offeryn ffynhonnell agored a gynlluniwyd i wella'r broses o adeiladu cod cymwysiadau o Git i ddelweddau Docker (ac yna eu cyflwyno i Kubernetes), nid ydym yn treulio llawer o amser yn dyfalu ynghylch pa ddewis sydd orau. Ein prif bryder yw darparu popeth sy'n angenrheidiol i gefnogwyr gwahanol farnau (cyn belled nad yw'n gwrth-ddweud synnwyr cyffredin, wrth gwrs).
Mae'r gefnogaeth mono-repo a ychwanegwyd yn ddiweddar yn werf yn enghraifft dda o hyn. Ond yn gyntaf, gadewch i ni ddarganfod sut mae'r gefnogaeth hon yn ymwneud â defnyddio werf a beth sydd gan Gofrestrfa Docker i'w wneud ag ef…
Materion
Dychmygwch y sefyllfa hon. Mae gan gwmni nifer o dimau datblygu yn gweithio ar brosiectau annibynnol. Mae'r rhan fwyaf o gymwysiadau'n rhedeg ar Kubernetes ac felly maent wedi'u cynwysyddion. Mae angen cofrestrfa i storio cynwysyddion a delweddau. Mae'r cwmni'n defnyddio Docker Hub fel ei gofrestrfa, gydag un cyfrif. COMPANYYn debyg i'r rhan fwyaf o systemau storio cod ffynhonnell, Nid yw Docker Hub yn caniatáu hierarchaethau ystorfeydd nythu., fel COMPANY/PROJECT/IMAGEYn yr achos hwnnw... sut allwn ni storio cymwysiadau nad ydynt yn monolithig yn y gofrestrfa gyda'r cyfyngiad hwn, heb greu cyfrif ar wahân ar gyfer pob prosiect?
Efallai bod y sefyllfa hon yn gyfarwydd i rai, ond gadewch i ni edrych ar fater trefnu storfa cymwysiadau yn gyffredinol, heb gyfeirio at yr enghraifft uchod a Docker Hub.
Datrysiadau
Os yw'r cais yn monolithig, yn cael ei gyflenwi mewn un ddelwedd, yna nid oes unrhyw gwestiynau'n codi ac rydym yn syml yn arbed y delweddau i gofrestrfa cynhwysydd y prosiect.
Pan gyflwynir cymhwysiad fel sawl cydrannau, microwasanaethau, yna rhaid dewis dull penodol. Gan ddefnyddio enghraifft o gymhwysiad gwe nodweddiadol sy'n cynnwys dau ddelwedd: frontend и backend — y dewisiadau posibl yw:
- Storiwch ddelweddau mewn ystorfeydd nythu ar wahân:
- Storiwch bopeth mewn un storfa, a chynnwys enw'r ddelwedd yn y tag, er enghraifft, fel hyn:
NBMewn gwirionedd, mae opsiwn arall gydag arbed mewn gwahanol ystorfeydd, PROJECT-frontend и PROJECT-backend, ond ni fyddwn yn ei ystyried oherwydd cymhlethdod y gefnogaeth, y trefniadaeth a'r dosbarthiad o hawliau rhwng defnyddwyr.
Cymorth yn y werf
I ddechrau, roedd werf yn cyfyngu ei hun i ystorfeydd nythu—yn ffodus, mae'r rhan fwyaf o gofrestrfeydd yn cefnogi'r nodwedd hon. Gan ddechrau gyda fersiwn , gwaith ychwanegol gyda chofrestrfeydd lle ni chefnogir nythu, ac mae Docker Hub yn un ohonyn nhw. O hyn ymlaen, mae gan ddefnyddwyr ddewis o sut i storio delweddau cymwysiadau.
Mae gweithredu ar gael fel opsiwn --images-repo-mode=multirepo|monorepo (yn ddiofyn multirepo(h.y., storio mewn ystorfeydd nythu). Mae'n diffinio'r templedi y mae delweddau'n cael eu storio drwyddynt yn y gofrestrfa. Dewiswch y modd a ddymunir wrth ddefnyddio'r gorchmynion sylfaenol, a bydd popeth arall yn aros yr un fath.
Gan y gellir gosod y rhan fwyaf o opsiynau werf newidynnau amgylcheddolMewn systemau CI/CD, mae'r modd storio fel arfer yn hawdd i'w osod yn fyd-eang ar gyfer y prosiect cyfan. Er enghraifft, yn achos GitLab Mae'n ddigon i ychwanegu newidyn amgylcheddol yn y gosodiadau prosiect: Gosodiadau -> CI / CD -> Newidynnau: WERF_IMAGES_REPO_MODE: multirepo|monorepo.
Gan sôn am gyhoeddi delweddau a chyflwyno cymwysiadau (gallwch ddarllen am y prosesau hyn yn fanwl yn yr erthyglau dogfennaeth perthnasol): и ), yna mae'r modd yn pennu'r templed y gallwch weithio gyda'r ddelwedd drwyddo yn unig.
Mae'r diafol yn y manylion
Y gwahaniaeth a'r prif anhawster wrth ychwanegu dull storio newydd yw yn y broses o lanhau'r gofrestrfa. (am alluoedd glanhau a gefnogir gan werf, gweler ).
Wrth lanhau, mae Werf yn ystyried y delweddau a ddefnyddir mewn clystyrau Kubernetes, yn ogystal â pholisïau a ffurfiwyd gan ddefnyddwyr. Mae polisïau'n seiliedig ar rannu tagiau yn strategaethau. Strategaethau a gefnogir ar hyn o bryd:
- 3 strategaeth sy'n gysylltiedig â chyntefigion Git fel tag, branch, ac commit;
- 1 strategaeth ar gyfer tagiau personol.
Rydym yn storio'r wybodaeth strategaeth tag wrth gyhoeddi delwedd yn labeli'r ddelwedd derfynol. Y gwerth ei hun yw'r hyn a elwir yn tag meta — yn angenrheidiol ar gyfer cymhwyso rhai polisïau. Er enghraifft, wrth ddileu cangen neu dag o storfa Git, mae'n gwneud synnwyr dileu'r rhai cysylltiedig hefyd. heb ei ddefnyddio delweddau o'r gofrestrfa, sy'n dod o dan ran o'n polisïau.
Wrth arbed mewn un storfa (monorepo), yn ogystal â'r tag meta, gall y tag delwedd hefyd storio enw'r ddelwedd: PROJECT:frontend-META-TAGEr mwyn eu gwahanu, ni wnaethom gyflwyno unrhyw wahanydd penodol, ond yn syml ychwanegu'r gwerth angenrheidiol at label terfynol y ddelwedd ar ôl ei chyhoeddi.
NBOs oes gennych ddiddordeb mewn edrych ar bopeth a ddisgrifir yn y cod ffynhonnell werf, yna gall man cychwyn fod .
Yn yr erthygl hon, ni fyddwn yn rhoi mwy o sylw i'r problemau a chyfiawnhad ein dull: ynglŷn â strategaethau tagio, storio data mewn labeli a'r broses gyhoeddi yn gyffredinol - disgrifir hyn i gyd yn fanwl mewn adroddiad diweddar gan Dmitry Stolyarov: “'.
I grynhoi
Nid oedd y diffyg cefnogaeth i gofrestrfeydd heb nythu yn broblem i ni nac unrhyw un o'r defnyddwyr werf rydyn ni'n eu hadnabod—mae bob amser yn bosibl sefydlu cofrestrfa delweddau ar wahân (neu newid i rywbeth fel Cofrestrfa Cynwysyddion yn Google Cloud). Fodd bynnag, roedd cael gwared ar y cyfyngiad hwn yn ymddangos yn rhesymegol i wneud yr offeryn yn fwy defnyddiadwy gan y gymuned DevOps ehangach. Wrth ei weithredu, daethom ar draws y brif her wrth ailgynllunio'r mecanwaith glanhau cofrestrfa cynwysyddion. Nawr bod popeth yn barod, mae'n braf gwybod bod pethau wedi dod yn haws i rywun, ac nid ydym ni (fel prif ddatblygwyr y prosiect) yn rhagweld unrhyw anawsterau sylweddol wrth gefnogi'r nodwedd hon ymhellach.
Daliwch ati i wylio a byddwn yn dweud wrthych chi am arloesiadau eraill yn y dyfodol agos. !
PS
Darllenwch hefyd ar ein blog:
- «";
- «'.
Ffynhonnell: hab.com
