Cefnogaeth i monorepo ac multirepo mewn werff a beth sydd gan Gofrestrfa'r Docwyr i'w wneud ag ef

Cefnogaeth i monorepo ac multirepo mewn werff a beth sydd gan Gofrestrfa'r Docwyr i'w wneud ag ef

Mae pwnc mono-storfa wedi'i drafod fwy nag unwaith ac, fel rheol, mae'n achosi dadlau gweithredol iawn. Trwy greu werff Fel offeryn Ffynhonnell Agored a gynlluniwyd i wella'r broses o adeiladu cod cais o Git i mewn i ddelweddau Docker (ac yna eu cyflwyno i Kubernetes), nid ydym yn meddwl llawer am ba ddewis sydd orau. I ni, mae'n sylfaenol darparu popeth sy'n angenrheidiol i gefnogwyr gwahanol farn (os nad yw hyn yn gwrth-ddweud synnwyr cyffredin, wrth gwrs).

Mae'r gefnogaeth a gyflwynwyd yn ddiweddar ar gyfer mono-repo mewn werff yn enghraifft dda o hyn. Ond yn gyntaf, gadewch i ni ddarganfod sut mae'r gefnogaeth hon yn gysylltiedig yn gyffredinol Γ’'r defnydd o werff a beth sydd gan Gofrestrfa Docker i'w wneud ag ef ...

Materion

Gadewch i ni ddychmygu'r sefyllfa hon. Mae gan y cwmni lawer o dimau datblygu sy'n gweithio ar brosiectau annibynnol. Mae'r rhan fwyaf o gymwysiadau yn gweithredu yn Kubernetes ac, yn unol Γ’ hynny, wedi'u gosod mewn cynhwysyddion. I storio cynwysyddion a delweddau, mae angen cofrestrfa. Mae'r cwmni'n defnyddio Docker Hub gydag un cyfrif fel cofrestrfa o'r fath. COMPANY. Yn debyg i'r rhan fwyaf o systemau storio cod ffynhonnell, Nid yw Docker Hub yn caniatΓ‘u ichi greu hierarchaeth nythu o ystorfeydd, fel COMPANY/PROJECT/IMAGE. Yn yr achos hwn... sut allwn ni storio cymwysiadau anmonolithig yn y gofrestrfa gyda'r cyfyngiad hwn heb greu cyfrif ar wahΓ’n ar gyfer pob prosiect?

Cefnogaeth i monorepo ac multirepo mewn werff a beth sydd gan Gofrestrfa'r Docwyr i'w wneud ag ef

Efallai bod y sefyllfa a ddisgrifir yn gyfarwydd i rywun yn uniongyrchol, ond gadewch i ni edrych ar y mater o drefnu storio ceisiadau yn gyffredinol, h.y. heb gyfeirio at yr enghraifft uchod a Docker Hub.

Atebion

Os yw'r cais monolithig, yn dod mewn un ddelwedd, yna nid oes unrhyw gwestiynau yn codi ac rydym yn syml yn arbed y delweddau i gofrestrfa cynhwysydd y prosiect.

Pan gyflwynir cais fel cydrannau lluosog, microwasanaethau, yna mae angen i chi ddewis dull penodol. Gan ddefnyddio'r enghraifft o raglen we nodweddiadol sy'n cynnwys dwy ddelwedd: frontend ΠΈ backend - yr opsiynau posibl yw:

  1. Storio delweddau mewn cadwrfeydd nythu ar wahΓ’n:

    Cefnogaeth i monorepo ac multirepo mewn werff a beth sydd gan Gofrestrfa'r Docwyr i'w wneud ag ef

  2. Storio popeth mewn un ystorfa, a chynnwys enw'r ddelwedd yn y tag, er enghraifft, fel a ganlyn:

    Cefnogaeth i monorepo ac multirepo mewn werff a beth sydd gan Gofrestrfa'r Docwyr i'w wneud ag ef

NB: Mewn gwirionedd, mae opsiwn arall gydag arbed mewn amrywiol ystorfeydd, PROJECT-frontend ΠΈ PROJECT-backend, ond ni fyddwn yn ei ystyried oherwydd cymhlethdod cefnogaeth, trefniadaeth a dosbarthiad hawliau rhwng defnyddwyr.

cefnogaeth werf

I ddechrau, roedd werff yn cyfyngu ei hun i ystorfeydd nythu - yn ffodus, mae'r rhan fwyaf o gofrestrfeydd yn cefnogi'r nodwedd hon. Gan ddechrau o fersiwn v1.0.4-alffa.3, gwaith ychwanegol gyda chofrestrfeydd lle ni chefnogir nythu, ac mae Docker Hub yn un ohonyn nhw. O'r eiliad hon ymlaen, roedd gan y defnyddiwr ddewis sut i storio delweddau cymwysiadau.

Gweithredu ar gael fel rhan o'r opsiwn --images-repo-mode=multirepo|monorepo (diofyn multirepo, h.y. storio mewn cadwrfeydd nythu). Mae'n diffinio'r patrymau a ddefnyddir i storio delweddau yn y gofrestrfa. Mae'n ddigon i ddewis y modd a ddymunir wrth ddefnyddio'r gorchmynion sylfaenol, a bydd popeth arall yn aros yn ddigyfnewid.

Oherwydd gellir gosod y rhan fwyaf o opsiynau werf newidynnau amgylchedd, mewn 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 Ychwanegwch newidyn amgylchedd yng ngosodiadau'r prosiect: Gosodiadau -> CI / CD -> Newidynnau: WERF_IMAGES_REPO_MODE: multirepo|monorepo.

Os byddwn yn sΓ΄n am gyhoeddi delweddau a chyflwyno ceisiadau (gallwch ddarllen am y prosesau hyn yn fanwl yn yr erthyglau dogfennaeth perthnasol: Cyhoeddi'r broses ΠΈ Defnyddio proses), yna mae'r modd yn pennu'r templed yn unig y gallwch chi weithio gyda'r ddelwedd trwyddo.

Mae'r diafol yn y manylion

Mae'r gwahaniaeth a'r prif anhawster wrth ychwanegu dull storio newydd yn y broses o lanhau'r gofrestrfa (am nodweddion purge a gefnogir gan werff, gw Proses lanhau).

Wrth lanhau, mae werf yn ystyried y delweddau a ddefnyddir yng nghlystyrau Kubernetes, yn ogystal Γ’ pholisΓ―au wedi'u ffurfweddu gan ddefnyddwyr. Mae polisΓ―au yn seiliedig ar rannu tagiau yn strategaethau. Strategaethau a gefnogir ar hyn o bryd:

  1. 3 strategaeth yn ymwneud Γ’ chyntefig Git megis tagio, cangen ac ymrwymo;
  2. 1 strategaeth ar gyfer tagiau personol wedi'u teilwra.

Rydym yn cadw gwybodaeth am y strategaeth tagiau wrth gyhoeddi'r ddelwedd yn labeli'r ddelwedd derfynol. Yr ystyr ei hun yw'r hyn a elwir tag meta β€” yn angenrheidiol ar gyfer gweithredu rhai polisΓ―au. Er enghraifft, wrth ddileu cangen neu dag o ystorfa Git, mae'n rhesymegol dileu cysylltiedig heb ei ddefnyddio delweddau o'r gofrestrfa, sy'n cael eu cynnwys yn rhan o'n polisΓ―au.

Wrth gadw mewn un gadwrfa (monorepo), yn y tag delwedd, yn ogystal Γ’'r tag meta, gellir storio enw'r ddelwedd hefyd: PROJECT:frontend-META-TAG. Er mwyn eu gwahanu, ni wnaethom gyflwyno unrhyw wahanydd penodol, ond yn syml wedi ychwanegu'r gwerth angenrheidiol at label y ddelwedd derfynol wrth gyhoeddi.

NB: Os oes gennych ddiddordeb mewn edrych ar bopeth a ddisgrifir yn y cod ffynhonnell werf, yna gall y man cychwyn fod PR 1684.

Yn yr erthygl hon ni fyddwn yn talu mwy o sylw i broblemau a chyfiawnhad ein hymagwedd: am strategaethau tagio, storio data mewn labeli a'r broses gyhoeddi yn gyffredinol - disgrifir hyn i gyd yn fanwl yn adroddiad diweddar Dmitry Stolyarov: β€œwerf yw ein hofferyn ar gyfer CI/CD yn Kubernetes'.

I grynhoi

Nid oedd y diffyg cefnogaeth i gofrestrfeydd heb eu nythu yn ffactor blocio i ni na'r defnyddwyr werf sy'n hysbys i ni - wedi'r cyfan, gallwch chi bob amser godi cofrestrfa ddelwedd ar wahΓ’n (neu newid i Gofrestrfa Cynhwysydd amodol yn Google Cloud) ... Fodd bynnag, roedd dileu cyfyngiad o'r fath yn ymddangos yn rhesymegol er mwyn i'r offeryn fod yn fwy cyfleus i gymuned ehangach DevOps. Wrth ei weithredu, roeddem yn wynebu'r prif anhawster wrth ail-weithio mecanwaith glanhau'r gofrestr cynhwysydd. Nawr bod popeth yn barod, mae'n braf sylweddoli ei fod wedi dod yn haws i rywun, ac ni fyddwn ni (fel prif ddatblygwyr y prosiect) yn cael unrhyw anawsterau amlwg wrth gefnogi'r nodwedd hon ymhellach.

Arhoswch gyda ni ac yn fuan iawn byddwn yn dweud wrthych am ddatblygiadau arloesol eraill werff!

PS

Darllenwch hefyd ar ein blog:

Ffynhonnell: hab.com

Ychwanegu sylw