Mijara mono-depoyek ji carekê zêdetir hatî nîqaş kirin û, wekî qaîdeyek, dibe sedema nîqaşên pir çalak. Bi afirandinê wekî amûrek çavkaniyek vekirî ya ku ji bo baştirkirina pêvajoya avakirina koda serîlêdanê ji wêneyên Git berbi Docker ve hatî çêkirin (û dûv re gihandina wan ji Kubernetes re), em pir nafikirin ka kîjan bijare çêtirîn e. Ji bo me, seretayî ye ku em her tiştê pêwîst ji bo alîgirên ramanên cihêreng peyda bikin (bê guman, heke ev ne li dijî hişmendiya hevpar be).
Piştgiriya mono-repo ya werfê ya dawî mînakek baş a vê yekê ye. Lê pêşî, em fêr bibin ka ev piştgirî çawa bi gelemperî bi karanîna werf ve girêdayî ye û Tomara Docker bi wê re çi heye ...
Issues
Werin em rewşek weha xeyal bikin. Pargîdanî gelek tîmên pêşveçûnê hene ku li ser projeyên serbixwe dixebitin. Piraniya serîlêdan li ser Kubernetes têne xebitandin û ji ber vê yekê konteyneran têne kirin. Ji bo hilanîna konteyneran, wêneyan, ji we re qeydek (qeyd) hewce ye. Wekî qeydek wusa, pargîdanî bi hesabek yekane Docker Hub bikar tîne COMPANY. Mîna piraniya pergalên hilanîna koda çavkaniyê, Docker Hub destûr nade hiyerarşiya depoya hêlîn, wekî COMPANY/PROJECT/IMAGE. Di wê rewşê de… hûn çawa dikarin serîlêdanên ne-yekdest di qeydê de bi vê tixûbê hilînin bêyî ku ji bo her projeyê hesabek cûda biafirînin?
Dibe ku, rewşa diyarkirî ji kesek pêşî re nas e, lê bila em mijara organîzekirina hilanîna serîlêdanê bi gelemperî bifikirin, ango. bêyî referansa mînaka jorîn û Docker Hub.
Solutions
Heke serîlêdanê monolîtîk, di yek wêneyê de tê, wê hingê pirs tune ne û em bi tenê wêneyan di qeyda konteynerê projeyê de tomar dikin.
Dema ku serîlêdanek wekî gelek pêkhateyan tê pêşkêş kirin, microservices, wê demê hin nêzîkatiyek pêdivî ye. Li ser nimûneya serîlêdana webê ya tîpîk ku ji du wêneyan pêk tê: frontend и backend - Vebijarkên gengaz ev in:
- Wêneyan di depoyên hêlînkirî yên cihê de hilînin:
- Her tiştî di yek depoyê de hilînin, û navê wêneyê di tagê de, mînakî, wekî jêrîn binirxînin:
NB: Bi rastî, vebijarkek din heye ku di depoyên cihêreng de tomar bike, PROJECT-frontend и PROJECT-backend, lê ji ber tevliheviya piştgirî, rêxistin û belavkirina mafan di navbera bikarhêneran de em ê wê nehesibînin.
piştgiriya werf
Di destpêkê de, werf xwe bi depoyên hêlînkirî ve sînordar kir - bextewar, piraniya qeydan vê taybetmendiyê piştgirî dikin. Ji versiyonê dest pê dike , kar bi qeydên ku tê de zêde kir hêlînê nayê piştgirî kirin, û Docker Hub yek ji wan e. Ji wê gavê pê ve, bikarhêner bijarek heye ka meriv çawa wêneyên serîlêdanê hilîne.
Pêkanîna di bin vebijarkê de heye --images-repo-mode=multirepo|monorepo (destçûnî multirepo, yanî hilanîn li depoyên hêlînkirî). Ew qalibên ku wêne di qeydê de têne hilanîn diyar dike. Dema ku emrên bingehîn bikar tînin meriv moda xwestinê hilbijêrin bes e, û her tiştê din dê bêguhez bimîne.
Ji ber ku piraniya vebijarkên werf dikarin bêne danîn guherbarên jîngehê, di pergalên CI / CD de, moda hilanînê bi gelemperî ji bo tevahiya projeyê li seranserê cîhanê hêsan e. Bo nimûne, di doza GitLab de tenê guhêrbarek jîngehê di mîhengên projeyê de zêde bike: Mîheng -> CI / CD -> Guherbar: WERF_IMAGES_REPO_MODE: multirepo|monorepo.
Ger em li ser weşandina wêneyan û serîlêdanan derxistinê biaxivin (hûn dikarin li ser van pêvajoyan bi hûrgulî di gotarên belgeyên têkildar de bixwînin: и ), wê hingê mod bi tenê şablona ku hûn dikarin bi wêneyê re bixebitin destnîşan dike.
Şeytan di hûrguliyan de ye
Cûdahî û dijwariya sereke dema ku rêbazek hilanînê ya nû lê zêde bike di pêvajoya paqijkirina qeydê de ye (ji bo taybetmendiyên paqijkirinê yên ku ji hêla werf ve têne piştgirî kirin, binêre ).
Dema paqijkirinê, werf wêneyên ku di komikên Kubernetes de têne bikar anîn, û her weha polîtîkayên ku ji hêla bikarhêner ve hatine mîheng kirin, digire. Polîtîka li ser dabeşkirina tagên stratejiyan têne çêkirin. Stratejiyên ku niha têne piştgirî kirin:
- 3 stratejiyên ku ji hêla primitives Git ve girêdayî ne, wekî tag, şax, û commit;
- 1 stratejî ji bo tagên xwerû yên keyfî.
Dema ku wêneyê di etîketên wêneya paşîn de diweşîne em agahdariya di derbarê stratejiya tagê de hilînin. Wate bi xwe tê gotin meta tag - Pêwîst e ku hin polîtîka bêne sepandin. Mînakî, dema ku şaxek an etîketek ji depoyek Git jêbirin, mentiqî ye ku meriv têkildar jê bibe. bikarnehat wêneyên ji qeydê, ku ji hêla beşek polîtîkayên me ve girêdayî ye.
Dema ku di yek depoyê de tê hilanîn (monorepo), di taga wêneyê de, ji bilî meta tagê, navê wêneyê jî dikare were hilanîn: PROJECT:frontend-META-TAG. Ji bo veqetandina wan, me tu veqetankerek taybetî destnîşan nekir, lê tenê dema weşana xwe nirxa pêwîst li etîketa wêneya paşîn zêde kir.
NB: Ger bala we dikişîne ku li her tiştê ku di koda çavkaniya werfê de hatî destnîşan kirin binihêrin, wê hingê xala destpêkê dikare bibe .
Di vê gotarê de, em ê bêtir guh nedin pirsgirêk û rastdariya nêzîkatiya xwe: li ser stratejiyên nîşankirinê, hilanîna daneyan di etîketan de û pêvajoya weşanê bi tevahî - ev hemî di raporek vê dawiyê ya Dmitry Stolyarov de bi hûrgulî têne vegotin:".
Bi kurtahî
Nebûna piştgirîya ji bo qeydên nenaskirî ji bo me an jî bikarhênerên werf ên ku ji me re naskirî ne faktorek astengker bû - her tiştî, hûn dikarin her gav tomarek wêneyek cihêreng rakin (an jî di Google Cloud de veguhezînin Tomarek konteyner a şertî) ... Lêbelê, rakirina sînordariyek wusa mentiqî xuya bû da ku amûr ji civata berfireh a DevOps re hêsantir be. Bi cîbicîkirina wê, em di ji nû ve xebitandina mekanîzmaya paqijkirina qeyda konteynerê de bi dijwariya sereke re rû bi rû man. Naha ku her tişt amade ye, xweş e ku meriv zanibe ku ew ji bo kesek hêsantir bûye, û em (wek pêşdebirên sereke yên projeyê) dê di piştgirîkirina bêtir vê taybetmendiyê de ti dijwariyên berbiçav nebin.
Bi me re bimînin û di demek nêzîk de em ê ji we re li ser nûbûnên din ên di nav de vebêjin !
PS
Li ser bloga me jî bixwînin:
- «»;
- «".
Source: www.habr.com