വെർഫിലെ മോണോറെപ്പോ, മൾട്ടിറെപ്പോ എന്നിവയ്ക്കുള്ള പിന്തുണയും ഡോക്കർ രജിസ്ട്രിയും ഇതുമായി എന്താണ് ചെയ്യേണ്ടത്

മോണോറെപ്പോ എന്ന വിഷയം പലതവണ ചർച്ച ചെയ്യപ്പെട്ടിട്ടുണ്ട്, ചട്ടം പോലെ, വളരെ സജീവമായ സംവാദങ്ങൾക്ക് കാരണമാകുന്നു. വെർഫ് Git-ൽ നിന്ന് Docker ഇമേജുകളിലേക്ക് ആപ്ലിക്കേഷൻ കോഡ് നിർമ്മിക്കുന്ന പ്രക്രിയ മെച്ചപ്പെടുത്തുന്നതിനായി രൂപകൽപ്പന ചെയ്‌തിരിക്കുന്ന ഒരു ഓപ്പൺ സോഴ്‌സ് ഉപകരണം എന്ന നിലയിൽ (തുടർന്ന് അവ Kubernetes-ലേക്ക് എത്തിക്കുന്നു), ഏത് ചോയ്‌സാണ് ഏറ്റവും നല്ലതെന്ന് ഊഹിക്കാൻ ഞങ്ങൾ കൂടുതൽ സമയം ചെലവഴിക്കുന്നില്ല. വ്യത്യസ്ത അഭിപ്രായങ്ങളെ പിന്തുണയ്ക്കുന്നവർക്ക് ആവശ്യമായതെല്ലാം നൽകുക എന്നതാണ് ഞങ്ങളുടെ പ്രാഥമിക ആശങ്ക (തീർച്ചയായും അത് സാമാന്യബുദ്ധിക്ക് വിരുദ്ധമാകാത്തിടത്തോളം).

werf-ൽ അടുത്തിടെ ചേർത്ത മോണോ-റെപ്പോ പിന്തുണ ഇതിന് ഒരു നല്ല ഉദാഹരണമാണ്. എന്നാൽ ആദ്യം, ഈ പിന്തുണ werf ഉപയോഗിക്കുന്നതുമായി എങ്ങനെ ബന്ധപ്പെട്ടിരിക്കുന്നുവെന്നും ഡോക്കർ രജിസ്ട്രി ഇതുമായി എന്ത് ബന്ധമാണുള്ളതെന്നും നമുക്ക് കണ്ടെത്താം...

പ്രശ്നങ്ങൾ

ഈ സാഹചര്യം നമുക്ക് സങ്കൽപ്പിക്കാം. ഒരു കമ്പനിക്ക് സ്വതന്ത്ര പ്രോജക്ടുകളിൽ പ്രവർത്തിക്കുന്ന ഒന്നിലധികം ഡെവലപ്‌മെന്റ് ടീമുകളുണ്ട്. മിക്ക ആപ്ലിക്കേഷനുകളും കുബേർനെറ്റസിൽ പ്രവർത്തിക്കുന്നു, അതിനാൽ അവ കണ്ടെയ്‌നറൈസ് ചെയ്യപ്പെടുന്നു. കണ്ടെയ്‌നറുകളും ചിത്രങ്ങളും സംഭരിക്കുന്നതിന് ഒരു രജിസ്ട്രി ആവശ്യമാണ്. കമ്പനി ഒരൊറ്റ അക്കൗണ്ടുള്ള രജിസ്ട്രിയായി ഡോക്കർ ഹബിനെ ഉപയോഗിക്കുന്നു. COMPANY. മിക്ക സോഴ്‌സ് കോഡ് സ്റ്റോറേജ് സിസ്റ്റങ്ങൾക്കും സമാനമായി, ഡോക്കർ ഹബ് നെസ്റ്റഡ് റിപ്പോസിറ്ററി ശ്രേണികളെ അനുവദിക്കുന്നില്ല., അതുപോലെ COMPANY/PROJECT/IMAGEഅങ്ങനെയെങ്കിൽ... ഓരോ പ്രോജക്റ്റിനും പ്രത്യേക അക്കൗണ്ട് സൃഷ്ടിക്കാതെ, ഈ പരിമിതിയോടെ, മോണോലിത്തിക്ക് അല്ലാത്ത ആപ്ലിക്കേഷനുകൾ രജിസ്ട്രിയിൽ എങ്ങനെ സംഭരിക്കാൻ കഴിയും?

ഈ സാഹചര്യം ചിലർക്ക് പരിചിതമായിരിക്കാം, പക്ഷേ മുകളിൽ പറഞ്ഞ ഉദാഹരണത്തെയും ഡോക്കർ ഹബ്ബിനെയും പരാമർശിക്കാതെ, ആപ്ലിക്കേഷൻ സംഭരണം പൊതുവായി സംഘടിപ്പിക്കുന്നതിന്റെ പ്രശ്നം നോക്കാം.

പരിഹാരങ്ങൾ

അപേക്ഷയാണെങ്കിൽ ഏകശിലാരൂപത്തിൽ, ഒരൊറ്റ ഇമേജിൽ വിതരണം ചെയ്യുന്നു, തുടർന്ന് ചോദ്യങ്ങളൊന്നും ഉയരുന്നില്ല, ഞങ്ങൾ ചിത്രങ്ങൾ പ്രോജക്റ്റിന്റെ കണ്ടെയ്നർ രജിസ്ട്രിയിൽ സംരക്ഷിക്കുന്നു.

ഒരു ആപ്ലിക്കേഷൻ ഒന്നിലധികം ഘടകങ്ങളായി അവതരിപ്പിക്കുമ്പോൾ, മൈക്രോസർവീസുകൾ, തുടർന്ന് ഒരു പ്രത്യേക സമീപനം തിരഞ്ഞെടുക്കണം. രണ്ട് ചിത്രങ്ങൾ അടങ്ങുന്ന ഒരു സാധാരണ വെബ് ആപ്ലിക്കേഷന്റെ ഉദാഹരണം ഉപയോഗിച്ച്: frontend и backend — സാധ്യമായ ഓപ്ഷനുകൾ ഇവയാണ്:

1. ചിത്രങ്ങൾ പ്രത്യേക നെസ്റ്റഡ് റിപ്പോസിറ്ററികളിൽ സൂക്ഷിക്കുക:

   

2. എല്ലാം ഒരു റിപ്പോസിറ്ററിയിൽ സൂക്ഷിക്കുക, ടാഗിൽ ചിത്രത്തിന്റെ പേര് ഉൾപ്പെടുത്തുക, ഉദാഹരണത്തിന്, ഇതുപോലെ:

   

NB: യഥാർത്ഥത്തിൽ, വ്യത്യസ്ത റിപ്പോസിറ്ററികളിൽ സേവ് ചെയ്യുന്നതിനുള്ള മറ്റൊരു ഓപ്ഷൻ ഉണ്ട്, PROJECT-frontend и PROJECT-backend, എന്നാൽ ഉപയോക്താക്കൾക്കിടയിലുള്ള അവകാശങ്ങളുടെ പിന്തുണ, ഓർഗനൈസേഷൻ, വിതരണം എന്നിവയുടെ സങ്കീർണ്ണത കാരണം ഞങ്ങൾ അത് പരിഗണിക്കില്ല.

വെർഫിൽ പിന്തുണ

തുടക്കത്തിൽ, werf നെസ്റ്റഡ് റിപ്പോസിറ്ററികളിലേക്ക് മാത്രമായി പരിമിതപ്പെടുത്തി - ഭാഗ്യവശാൽ, മിക്ക രജിസ്ട്രികളും ഈ സവിശേഷതയെ പിന്തുണയ്ക്കുന്നു. പതിപ്പ് മുതൽ ആരംഭിക്കുന്നു v1.0.4-alpha.3, രജിസ്ട്രികളുമായി ചേർത്ത പ്രവർത്തനം നെസ്റ്റിംഗ് പിന്തുണയ്ക്കുന്നില്ല, കൂടാതെ ഡോക്കർ ഹബ് അതിലൊന്നാണ്. ഇനി മുതൽ, ആപ്ലിക്കേഷൻ ഇമേജുകൾ എങ്ങനെ സംഭരിക്കണമെന്ന് ഉപയോക്താക്കൾക്ക് തിരഞ്ഞെടുക്കാം.

നടപ്പിലാക്കൽ ഒരു ഓപ്ഷനായി ലഭ്യമാണ്. --images-repo-mode=multirepo|monorepo (സ്ഥിരസ്ഥിതിയായി multirepo(അതായത്, നെസ്റ്റഡ് റിപ്പോസിറ്ററികളിൽ സംഭരിക്കുന്നു). രജിസ്ട്രിയിൽ ഇമേജുകൾ സംഭരിക്കുന്ന ടെംപ്ലേറ്റുകളെ ഇത് നിർവചിക്കുന്നു. അടിസ്ഥാന കമാൻഡുകൾ ഉപയോഗിക്കുമ്പോൾ ആവശ്യമുള്ള മോഡ് തിരഞ്ഞെടുക്കുക, മറ്റെല്ലാം മാറ്റമില്ലാതെ തുടരും.

മിക്ക വെർഫ് ഓപ്ഷനുകളും സജ്ജമാക്കാൻ കഴിയുന്നതിനാൽ പരിസ്ഥിതി വേരിയബിളുകൾCI/CD സിസ്റ്റങ്ങളിൽ, മുഴുവൻ പ്രോജക്റ്റിനും വേണ്ടി ആഗോളതലത്തിൽ സ്റ്റോറേജ് മോഡ് സജ്ജീകരിക്കാൻ സാധാരണയായി എളുപ്പമാണ്. ഉദാഹരണത്തിന്, GitLab-ന്റെ കാര്യത്തിൽ പ്രോജക്റ്റ് ക്രമീകരണങ്ങളിൽ ഒരു പരിസ്ഥിതി വേരിയബിൾ ചേർത്താൽ മതി: ക്രമീകരണങ്ങൾ -> CI / CD -> വേരിയബിളുകൾ: WERF_IMAGES_REPO_MODE: multirepo|monorepo.

ചിത്രങ്ങൾ പ്രസിദ്ധീകരിക്കുന്നതിനെക്കുറിച്ചും ആപ്ലിക്കേഷനുകൾ പുറത്തിറക്കുന്നതിനെക്കുറിച്ചും പറയുമ്പോൾ (ഈ പ്രക്രിയകളെക്കുറിച്ച് നിങ്ങൾക്ക് പ്രസക്തമായ ഡോക്യുമെന്റേഷൻ ലേഖനങ്ങളിൽ വിശദമായി വായിക്കാം: പ്രസിദ്ധീകരണ പ്രക്രിയ и വിന്യസിക്കൽ പ്രക്രിയ), തുടർന്ന് ഇമേജിനൊപ്പം നിങ്ങൾക്ക് പ്രവർത്തിക്കാൻ കഴിയുന്ന ടെംപ്ലേറ്റ് മോഡ് പ്രത്യേകമായി നിർണ്ണയിക്കുന്നു.

വിശദാംശങ്ങളിൽ പിശാച് ഉണ്ട്

ഒരു പുതിയ സംഭരണ ​​രീതി ചേർക്കുമ്പോൾ വ്യത്യാസവും പ്രധാന ബുദ്ധിമുട്ടും രജിസ്ട്രി വൃത്തിയാക്കുന്ന പ്രക്രിയയിലാണ്. (werf പിന്തുണയ്ക്കുന്ന ക്ലീനിംഗ് കഴിവുകൾക്ക്, കാണുക വൃത്തിയാക്കൽ പ്രക്രിയ).

വൃത്തിയാക്കുമ്പോൾ, കുബേർനെറ്റസ് ക്ലസ്റ്ററുകളിൽ ഉപയോഗിക്കുന്ന ചിത്രങ്ങളും ഉപയോക്തൃ കോൺഫിഗർ ചെയ്ത നയങ്ങളും വെർഫ് കണക്കിലെടുക്കുന്നു. ടാഗുകളെ തന്ത്രങ്ങളായി വിഭജിക്കുന്നതിനെ അടിസ്ഥാനമാക്കിയുള്ളതാണ് നയങ്ങൾ. നിലവിൽ പിന്തുണയ്ക്കുന്ന തന്ത്രങ്ങൾ:

1. ടാഗ്, ബ്രാഞ്ച്, കമ്മിറ്റ് തുടങ്ങിയ Git പ്രൈമിറ്റീവുകളുമായി ബന്ധപ്പെട്ട 3 തന്ത്രങ്ങൾ;
2. ഇഷ്ടാനുസൃത ടാഗുകൾക്കുള്ള 1 തന്ത്രം.

ഒരു ചിത്രം പ്രസിദ്ധീകരിക്കുമ്പോൾ, അന്തിമ ചിത്രത്തിന്റെ ലേബലുകളിൽ ടാഗ് തന്ത്ര വിവരങ്ങൾ ഞങ്ങൾ സംഭരിക്കുന്നു. മൂല്യം തന്നെ വിളിക്കപ്പെടുന്നതാണ് മെറ്റാ ടാഗ് — ചില നയങ്ങൾ പ്രയോഗിക്കുന്നതിന് അത്യാവശ്യമാണ്. ഉദാഹരണത്തിന്, ഒരു Git റിപ്പോസിറ്ററിയിൽ നിന്ന് ഒരു ബ്രാഞ്ചോ ടാഗോ ഇല്ലാതാക്കുമ്പോൾ, ബന്ധപ്പെട്ടവയും ഇല്ലാതാക്കുന്നത് അർത്ഥവത്താണ്. ഉപയോഗിക്കാത്ത ഞങ്ങളുടെ നയങ്ങളുടെ ഭാഗമായി ഉൾപ്പെടുന്ന രജിസ്ട്രിയിൽ നിന്നുള്ള ചിത്രങ്ങൾ.

ഒരു റിപ്പോസിറ്ററിയിൽ സേവ് ചെയ്യുമ്പോൾ (monorepo), മെറ്റാ ടാഗിന് പുറമേ, ഇമേജ് ടാഗിന് ചിത്രത്തിന്റെ പേരും സംഭരിക്കാൻ കഴിയും: PROJECT:frontend-META-TAGഅവയെ വേർതിരിക്കുന്നതിന്, ഞങ്ങൾ ഒരു പ്രത്യേക സെപ്പറേറ്ററും അവതരിപ്പിച്ചില്ല, മറിച്ച് പ്രസിദ്ധീകരിച്ചപ്പോൾ അന്തിമ ഇമേജ് ലേബലിൽ ആവശ്യമായ മൂല്യം ചേർത്തു.

NB: werf സോഴ്‌സ് കോഡിൽ വിവരിച്ചിരിക്കുന്നതെല്ലാം നോക്കാൻ നിങ്ങൾക്ക് താൽപ്പര്യമുണ്ടെങ്കിൽ, ഒരു ആരംഭ പോയിന്റ് ഇതായിരിക്കാം പിആർ 1684.

ഈ ലേഖനത്തിൽ, ഞങ്ങളുടെ സമീപനത്തിന്റെ പ്രശ്നങ്ങളിലേക്കും ന്യായീകരണത്തിലേക്കും ഞങ്ങൾ കൂടുതൽ ശ്രദ്ധ ചെലുത്തില്ല: ടാഗിംഗ് തന്ത്രങ്ങൾ, ലേബലുകളിൽ ഡാറ്റ സംഭരിക്കൽ, പൊതുവെ പ്രസിദ്ധീകരണ പ്രക്രിയ എന്നിവയെക്കുറിച്ച് - ഇതെല്ലാം ദിമിത്രി സ്റ്റോലിയാരോവിന്റെ സമീപകാല റിപ്പോർട്ടിൽ വിശദമായി വിവരിച്ചിരിക്കുന്നു: “കുബെർനെറ്റസിലെ CI/CD-ക്കുള്ള ഞങ്ങളുടെ ഉപകരണമാണ് werf".

ചുരുക്കി പറഞ്ഞാൽ

നെസ്റ്റഡ് അല്ലാത്ത രജിസ്ട്രികൾക്കുള്ള പിന്തുണയുടെ അഭാവം ഞങ്ങൾക്കോ ​​ഞങ്ങൾക്കറിയാവുന്ന ഏതെങ്കിലും വെർഫ് ഉപയോക്താക്കൾക്കോ ​​ഒരു ഡീൽ ബ്രേക്കർ ആയിരുന്നില്ല - ഒരു പ്രത്യേക ഇമേജ് രജിസ്ട്രി സജ്ജീകരിക്കുന്നത് (അല്ലെങ്കിൽ Google ക്ലൗഡിലെ കണ്ടെയ്നർ രജിസ്ട്രി പോലുള്ള ഒന്നിലേക്ക് മാറുന്നത്) എല്ലായ്പ്പോഴും സാധ്യമാണ്. എന്നിരുന്നാലും, വിശാലമായ DevOps കമ്മ്യൂണിറ്റിക്ക് ടൂൾ കൂടുതൽ ഉപയോഗപ്രദമാക്കുന്നതിന് ഈ പരിധി നീക്കം ചെയ്യുന്നത് യുക്തിസഹമായി തോന്നി. ഇത് നടപ്പിലാക്കുമ്പോൾ, കണ്ടെയ്നർ രജിസ്ട്രി ക്ലീനപ്പ് സംവിധാനം പുനർരൂപകൽപ്പന ചെയ്യുന്നതിലെ പ്രധാന വെല്ലുവിളി ഞങ്ങൾ നേരിട്ടു. ഇപ്പോൾ എല്ലാം തയ്യാറായതിനാൽ, മറ്റൊരാൾക്ക് കാര്യങ്ങൾ എളുപ്പമായി എന്ന് അറിയുന്നത് സന്തോഷകരമാണ്, കൂടാതെ (പ്രോജക്റ്റിന്റെ ലീഡ് ഡെവലപ്പർമാർ എന്ന നിലയിൽ) ഈ സവിശേഷതയെ കൂടുതൽ പിന്തുണയ്ക്കുന്നതിൽ കാര്യമായ ബുദ്ധിമുട്ടുകൾ ഉണ്ടാകുമെന്ന് ഞങ്ങൾ പ്രതീക്ഷിക്കുന്നില്ല.

കാത്തിരിക്കൂ, സമീപഭാവിയിൽ മറ്റ് പുതുമകളെക്കുറിച്ച് ഞങ്ങൾ നിങ്ങളോട് പറയും. വെർഫ്!

പി.എസ്

ഞങ്ങളുടെ ബ്ലോഗിലും വായിക്കുക:

• «നിങ്ങൾക്ക് ഇപ്പോൾ ഒരു സാധാരണ ഡോക്കർ ഫയൽ ഉപയോഗിച്ച് വെർഫിൽ ഡോക്കർ ഇമേജുകൾ നിർമ്മിക്കാം";
• «werf - കുബർനെറ്റസിലെ CI / CD-യ്ക്കുള്ള ഞങ്ങളുടെ ഉപകരണം (അവലോകനവും വീഡിയോ റിപ്പോർട്ടും)".

അവലംബം: www.habr.com