കണ്ടെയ്നർ ചിത്രങ്ങളുടെ "സ്മാർട്ട്" ക്ലീനിംഗ് പ്രശ്നവും വെർഫിൽ അതിന്റെ പരിഹാരവും

കുബർനെറ്റസിലേക്ക് ഡെലിവർ ചെയ്യുന്ന ക്ലൗഡ് നേറ്റീവ് ആപ്ലിക്കേഷനുകൾക്കായുള്ള ആധുനിക സിഐ/സിഡി പൈപ്പ് ലൈനുകളുടെ യാഥാർത്ഥ്യങ്ങളിൽ കണ്ടെയ്‌നർ രജിസ്‌ട്രികളിൽ (ഡോക്കർ രജിസ്‌ട്രിയും അതിന്റെ അനലോഗുകളും) അടിഞ്ഞുകൂടുന്ന ഇമേജുകൾ വൃത്തിയാക്കുന്നതിലെ പ്രശ്‌നങ്ങൾ ലേഖനം ചർച്ച ചെയ്യുന്നു. ചിത്രങ്ങളുടെ പ്രസക്തി, ക്ലീനിംഗ് ഓട്ടോമേറ്റ് ചെയ്യൽ, സ്ഥലം ലാഭിക്കൽ, ടീമുകളുടെ ആവശ്യങ്ങൾ നിറവേറ്റൽ എന്നിവയിലെ ബുദ്ധിമുട്ടുകൾ എന്നിവയ്ക്കുള്ള പ്രധാന മാനദണ്ഡങ്ങൾ നൽകിയിരിക്കുന്നു. അവസാനമായി, ഒരു നിർദ്ദിഷ്ട ഓപ്പൺ സോഴ്സ് പ്രോജക്റ്റിന്റെ ഉദാഹരണം ഉപയോഗിച്ച്, ഈ ബുദ്ധിമുട്ടുകൾ എങ്ങനെ മറികടക്കാമെന്ന് ഞങ്ങൾ നിങ്ങളോട് പറയും.

ആമുഖം

ഒരു കണ്ടെയ്‌നർ രജിസ്‌ട്രിയിലെ ചിത്രങ്ങളുടെ എണ്ണം അതിവേഗം വളരുകയും കൂടുതൽ സ്‌റ്റോറേജ് സ്‌പേസ് എടുക്കുകയും അങ്ങനെ അതിന്റെ വില ഗണ്യമായി വർദ്ധിപ്പിക്കുകയും ചെയ്യും. രജിസ്ട്രിയിൽ കൈവശമുള്ള സ്ഥലത്തിന്റെ സ്വീകാര്യമായ വളർച്ച നിയന്ത്രിക്കുന്നതിനും പരിമിതപ്പെടുത്തുന്നതിനും നിലനിർത്തുന്നതിനും, ഇത് സ്വീകരിക്കുന്നു:

1. ചിത്രങ്ങൾക്കായി ഒരു നിശ്ചിത എണ്ണം ടാഗുകൾ ഉപയോഗിക്കുക;
2. ഏതെങ്കിലും വിധത്തിൽ ചിത്രങ്ങൾ വൃത്തിയാക്കുക.

ആദ്യ പരിമിതി ചിലപ്പോൾ ചെറിയ ടീമുകൾക്ക് സ്വീകാര്യമാണ്. ഡവലപ്പർമാർക്ക് മതിയായ സ്ഥിരമായ ടാഗുകൾ ഉണ്ടെങ്കിൽ (latest, main, test, boris മുതലായവ), രജിസ്ട്രി വലുപ്പത്തിൽ വർദ്ധിക്കുകയില്ല, മാത്രമല്ല ഇത് വൃത്തിയാക്കുന്നതിനെക്കുറിച്ച് വളരെക്കാലം നിങ്ങൾ ചിന്തിക്കേണ്ടതില്ല. എല്ലാത്തിനുമുപരി, അപ്രസക്തമായ എല്ലാ ചിത്രങ്ങളും മായ്‌ച്ചു, കൂടാതെ വൃത്തിയാക്കാൻ ഒരു ജോലിയും അവശേഷിക്കുന്നില്ല (എല്ലാം ചെയ്യുന്നത് ഒരു സാധാരണ മാലിന്യ ശേഖരണമാണ്).

എന്നിരുന്നാലും, ഈ സമീപനം വികസനത്തെ വളരെയധികം പരിമിതപ്പെടുത്തുന്നു, മാത്രമല്ല ആധുനിക CI/CD പ്രോജക്റ്റുകൾക്ക് ഇത് വളരെ അപൂർവമായി മാത്രമേ ബാധകമാകൂ. വികസനത്തിന്റെ അവിഭാജ്യ ഘടകമായിരുന്നു ഓട്ടോമേഷൻ, ഇത് ഉപയോക്താക്കൾക്ക് വളരെ വേഗത്തിൽ പുതിയ പ്രവർത്തനക്ഷമത പരിശോധിക്കാനും വിന്യസിക്കാനും വിതരണം ചെയ്യാനും നിങ്ങളെ അനുവദിക്കുന്നു. ഉദാഹരണത്തിന്, ഞങ്ങളുടെ എല്ലാ പ്രോജക്റ്റുകളിലും, ഓരോ കമ്മിറ്റിലും ഒരു CI പൈപ്പ്ലൈൻ സ്വയമേവ സൃഷ്ടിക്കപ്പെടുന്നു. അതിൽ, ഡീബഗ്ഗിംഗിനും ശേഷിക്കുന്ന പരിശോധനകൾക്കുമായി ചിത്രം കൂട്ടിച്ചേർക്കുകയും പരീക്ഷിക്കുകയും വിവിധ കുബർനെറ്റസ് സർക്യൂട്ടുകളിലേക്ക് ഉരുട്ടുകയും ചെയ്യുന്നു, എല്ലാം ശരിയാണെങ്കിൽ, മാറ്റങ്ങൾ അന്തിമ ഉപയോക്താവിൽ എത്തുന്നു. ഇത് മേലിൽ റോക്കറ്റ് സയൻസ് അല്ല, മറിച്ച് പലരുടെയും ദൈനംദിന സംഭവമാണ് - മിക്കവാറും നിങ്ങൾക്കായി, നിങ്ങൾ ഈ ലേഖനം വായിക്കുന്നതിനാൽ.

ബഗുകൾ പരിഹരിക്കുന്നതും പുതിയ പ്രവർത്തനക്ഷമത വികസിപ്പിക്കുന്നതും സമാന്തരമായി നടക്കുന്നതിനാൽ, റിലീസുകൾ ദിവസത്തിൽ പലതവണ നടത്താമെന്നതിനാൽ, വികസന പ്രക്രിയയ്‌ക്കൊപ്പം ഗണ്യമായ എണ്ണം കമ്മിറ്റുകളും ഉണ്ടെന്ന് വ്യക്തമാണ്, അതായത് രജിസ്ട്രിയിൽ ധാരാളം ചിത്രങ്ങൾ. തൽഫലമായി, രജിസ്ട്രിയുടെ ഫലപ്രദമായ ക്ലീനിംഗ് സംഘടിപ്പിക്കുന്നതിനുള്ള പ്രശ്നം ഉയർന്നുവരുന്നു, അതായത്. അപ്രസക്തമായ ചിത്രങ്ങൾ നീക്കം ചെയ്യുന്നു.

എന്നാൽ ഒരു ചിത്രം പ്രസക്തമാണോ എന്ന് പോലും എങ്ങനെ നിർണ്ണയിക്കും?

ചിത്രത്തിന്റെ പ്രസക്തിയുടെ മാനദണ്ഡം

മിക്ക കേസുകളിലും, പ്രധാന മാനദണ്ഡങ്ങൾ ഇതായിരിക്കും:

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

2. രണ്ടാമത്തേത് (വ്യക്തമല്ലാത്തതും എന്നാൽ വളരെ പ്രധാനപ്പെട്ടതും വീണ്ടും ചൂഷണവുമായി ബന്ധപ്പെട്ടതും) - ചിത്രങ്ങൾ ഗുരുതരമായ പ്രശ്‌നങ്ങൾ കണ്ടെത്തിയാൽ തിരിച്ചെടുക്കാൻ ആവശ്യമാണ് നിലവിലെ പതിപ്പിൽ. ഉദാഹരണത്തിന്, ഹെൽമിന്റെ കാര്യത്തിൽ, ഇവ റിലീസിന്റെ സംരക്ഷിച്ച പതിപ്പുകളിൽ ഉപയോഗിക്കുന്ന ചിത്രങ്ങളാണ്. (വഴിയിൽ, ഹെൽമിൽ ഡിഫോൾട്ടായി പരിധി 256 പുനരവലോകനങ്ങളാണ്, എന്നാൽ ആർക്കും ശരിക്കും സംരക്ഷിക്കേണ്ടി വരില്ല അത്തരം ഒരു ധാരാളം പതിപ്പുകൾ?..) എല്ലാത്തിനുമുപരി, ഞങ്ങൾ, പ്രത്യേകിച്ച്, പതിപ്പുകൾ സംഭരിക്കുന്നതിനാൽ അവ പിന്നീട് ഉപയോഗിക്കാനാകും, അതായത്. ആവശ്യമെങ്കിൽ അവരിലേക്ക് "തിരിച്ചുവിടുക".

3. മൂന്നാമത് - ഡെവലപ്പർ ആവശ്യങ്ങൾ: അവരുടെ നിലവിലെ ജോലിയുമായി ബന്ധപ്പെട്ട എല്ലാ ചിത്രങ്ങളും. ഉദാഹരണത്തിന്, ഞങ്ങൾ ഒരു പിആർ പരിഗണിക്കുകയാണെങ്കിൽ, അവസാന കമ്മിറ്റിനും മുമ്പത്തെ പ്രതിബദ്ധതയ്ക്കും അനുയോജ്യമായ ഒരു ഇമേജ് വിടുന്നത് അർത്ഥമാക്കുന്നു: ഇതുവഴി ഡവലപ്പർക്ക് ഏത് ടാസ്ക്കിലേക്കും വേഗത്തിൽ മടങ്ങാനും ഏറ്റവും പുതിയ മാറ്റങ്ങളുമായി പ്രവർത്തിക്കാനും കഴിയും.

4. നാലാമത് - ആ ചിത്രങ്ങൾ ഞങ്ങളുടെ ആപ്ലിക്കേഷന്റെ പതിപ്പുകളുമായി പൊരുത്തപ്പെടുന്നു, അതായത്. അന്തിമ ഉൽപ്പന്നമാണ്: v1.0.0, 20.04.01/XNUMX/XNUMX, sierra, മുതലായവ.

NB: ഇവിടെ നിർവചിച്ചിരിക്കുന്ന മാനദണ്ഡങ്ങൾ വിവിധ കമ്പനികളിൽ നിന്നുള്ള ഡസൻ കണക്കിന് ഡെവലപ്‌മെന്റ് ടീമുകളുമായി സംവദിച്ച അനുഭവത്തിന്റെ അടിസ്ഥാനത്തിലാണ് രൂപപ്പെടുത്തിയത്. എന്നിരുന്നാലും, തീർച്ചയായും, വികസന പ്രക്രിയകളിലെ പ്രത്യേകതകളെയും ഉപയോഗിച്ച അടിസ്ഥാന സൗകര്യങ്ങളെയും ആശ്രയിച്ച് (ഉദാഹരണത്തിന്, കുബർനെറ്റസ് ഉപയോഗിക്കുന്നില്ല), ഈ മാനദണ്ഡങ്ങൾ വ്യത്യാസപ്പെടാം.

യോഗ്യതയും നിലവിലുള്ള പരിഹാരങ്ങളും

കണ്ടെയ്നർ രജിസ്ട്രികളുള്ള ജനപ്രിയ സേവനങ്ങൾ, ഒരു ചട്ടം പോലെ, അവരുടെ സ്വന്തം ഇമേജ് ക്ലീനപ്പ് നയങ്ങൾ വാഗ്ദാനം ചെയ്യുന്നു: രജിസ്ട്രിയിൽ നിന്ന് ഒരു ടാഗ് നീക്കം ചെയ്യപ്പെടുന്ന വ്യവസ്ഥകൾ അവയിൽ നിങ്ങൾക്ക് നിർവചിക്കാം. എന്നിരുന്നാലും, ഈ വ്യവസ്ഥകൾ പേരുകൾ, സൃഷ്‌ടിക്കൽ സമയം, ടാഗുകളുടെ എണ്ണം എന്നിവ പോലുള്ള പാരാമീറ്ററുകൾ കൊണ്ട് പരിമിതപ്പെടുത്തിയിരിക്കുന്നു*.

* നിർദ്ദിഷ്ട കണ്ടെയ്നർ രജിസ്ട്രി നടപ്പിലാക്കലുകളെ ആശ്രയിച്ചിരിക്കുന്നു. ഇനിപ്പറയുന്ന പരിഹാരങ്ങളുടെ സാധ്യതകൾ ഞങ്ങൾ പരിഗണിച്ചു: Azure CR, Docker Hub, ECR, GCR, GitHub പാക്കേജുകൾ, GitLab കണ്ടെയ്‌നർ രജിസ്‌ട്രി, ഹാർബർ രജിസ്‌ട്രി, JFrog ആർട്ടിഫാക്‌ടറി, Quay.io - സെപ്റ്റംബർ'2020 മുതൽ.

ഈ പാരാമീറ്ററുകളുടെ സെറ്റ് നാലാമത്തെ മാനദണ്ഡം നിറവേറ്റാൻ പര്യാപ്തമാണ് - അതായത്, പതിപ്പുകൾക്ക് അനുയോജ്യമായ ചിത്രങ്ങൾ തിരഞ്ഞെടുക്കുന്നതിന്. എന്നിരുന്നാലും, മറ്റെല്ലാ മാനദണ്ഡങ്ങൾക്കുമായി, ഒരാൾ ഏതെങ്കിലും തരത്തിലുള്ള വിട്ടുവീഴ്ച പരിഹാരം തിരഞ്ഞെടുക്കേണ്ടതുണ്ട് (കഠിനമായ അല്ലെങ്കിൽ, മറിച്ച്, കൂടുതൽ മൃദുവായ നയം) - പ്രതീക്ഷകളും സാമ്പത്തിക ശേഷിയും അനുസരിച്ച്.

ഉദാഹരണത്തിന്, മൂന്നാമത്തെ മാനദണ്ഡം - ഡവലപ്പർമാരുടെ ആവശ്യങ്ങളുമായി ബന്ധപ്പെട്ടത് - ടീമുകൾക്കുള്ളിൽ പ്രക്രിയകൾ സംഘടിപ്പിക്കുന്നതിലൂടെ പരിഹരിക്കാൻ കഴിയും: ചിത്രങ്ങളുടെ പ്രത്യേക നാമകരണം, പ്രത്യേക അനുമതി ലിസ്റ്റുകളും ആന്തരിക കരാറുകളും നിലനിർത്തൽ. എന്നാൽ ആത്യന്തികമായി ഇത് ഇപ്പോഴും ഓട്ടോമേറ്റ് ചെയ്യേണ്ടതുണ്ട്. റെഡിമെയ്ഡ് സൊല്യൂഷനുകളുടെ കഴിവുകൾ പര്യാപ്തമല്ലെങ്കിൽ, നിങ്ങൾ സ്വന്തമായി എന്തെങ്കിലും ചെയ്യണം.

ആദ്യത്തെ രണ്ട് മാനദണ്ഡങ്ങളുമായുള്ള സാഹചര്യം സമാനമാണ്: ഒരു ബാഹ്യ സിസ്റ്റത്തിൽ നിന്ന് ഡാറ്റ സ്വീകരിക്കാതെ അവ തൃപ്തിപ്പെടുത്താൻ കഴിയില്ല - ആപ്ലിക്കേഷനുകൾ വിന്യസിച്ചിരിക്കുന്ന ഒന്ന് (ഞങ്ങളുടെ കാര്യത്തിൽ, കുബർനെറ്റസ്).

Git-ലെ വർക്ക്ഫ്ലോയുടെ ചിത്രീകരണം

നിങ്ങൾ Git-ൽ ഇതുപോലൊന്ന് പ്രവർത്തിക്കുകയാണെന്ന് പറയാം:

ഡയഗ്രാമിലെ തലയുള്ള ഐക്കൺ, നിലവിൽ ഏതെങ്കിലും ഉപയോക്താക്കൾക്കായി (അവസാന ഉപയോക്താക്കൾ, ടെസ്റ്റർമാർ, മാനേജർമാർ, മുതലായവ) വിന്യസിച്ചിരിക്കുന്ന അല്ലെങ്കിൽ ഡീബഗ്ഗിംഗിനും സമാന ആവശ്യങ്ങൾക്കുമായി ഡവലപ്പർമാർ ഉപയോഗിക്കുന്ന കണ്ടെയ്നർ ചിത്രങ്ങളെ സൂചിപ്പിക്കുന്നു.

ക്ലീനപ്പ് നയങ്ങൾ ചിത്രങ്ങൾ നിലനിർത്താൻ മാത്രം അനുവദിക്കുകയാണെങ്കിൽ എന്ത് സംഭവിക്കും (ഇല്ലാതാക്കില്ല) നൽകിയിരിക്കുന്ന ടാഗ് പേരുകൾ പ്രകാരം?

വ്യക്തമായും, അത്തരമൊരു സാഹചര്യം ആരെയും സന്തോഷിപ്പിക്കില്ല.

ചിത്രങ്ങൾ ഇല്ലാതാക്കാതിരിക്കാൻ നയങ്ങൾ അനുവദിക്കുകയാണെങ്കിൽ എന്ത് മാറും? ഒരു നിശ്ചിത സമയ ഇടവേള / അവസാന കമ്മിറ്റുകളുടെ എണ്ണം അനുസരിച്ച്?

ഫലം വളരെ മികച്ചതായി മാറിയിരിക്കുന്നു, പക്ഷേ ഇപ്പോഴും ആദർശത്തിൽ നിന്ന് വളരെ അകലെയാണ്. എല്ലാത്തിനുമുപരി, ബഗുകൾ ഡീബഗ് ചെയ്യുന്നതിന് രജിസ്ട്രിയിൽ (അല്ലെങ്കിൽ K8-കളിൽ പോലും വിന്യസിച്ചിരിക്കുന്ന) ഇമേജുകൾ ആവശ്യമുള്ള ഡെവലപ്പർമാർ ഞങ്ങൾക്കുണ്ട്...

നിലവിലെ വിപണി സാഹചര്യം സംഗ്രഹിക്കാൻ: കണ്ടെയ്‌നർ രജിസ്‌ട്രികളിൽ ലഭ്യമായ ഫംഗ്‌ഷനുകൾ വൃത്തിയാക്കുമ്പോൾ മതിയായ വഴക്കം നൽകുന്നില്ല, ഇതിന്റെ പ്രധാന കാരണം പുറം ലോകവുമായി ഇടപഴകാൻ വഴിയില്ല. അത്തരം വഴക്കം ആവശ്യമുള്ള ടീമുകൾ ഡോക്കർ രജിസ്ട്രി API (അല്ലെങ്കിൽ അനുബന്ധ നടപ്പാക്കലിന്റെ നേറ്റീവ് API) ഉപയോഗിച്ച് "പുറത്ത് നിന്ന്" ഇമേജ് ഇല്ലാതാക്കൽ സ്വതന്ത്രമായി നടപ്പിലാക്കാൻ നിർബന്ധിതരാണെന്ന് ഇത് മാറുന്നു.

എന്നിരുന്നാലും, വ്യത്യസ്ത രജിസ്ട്രികൾ ഉപയോഗിച്ച് വ്യത്യസ്ത ടീമുകൾക്കായി ഇമേജ് ക്ലീനപ്പ് ഓട്ടോമേറ്റ് ചെയ്യുന്ന ഒരു സാർവത്രിക പരിഹാരത്തിനായി ഞങ്ങൾ തിരയുകയായിരുന്നു...

സാർവത്രിക ഇമേജ് ക്ലീനിംഗിലേക്കുള്ള ഞങ്ങളുടെ പാത

ഈ ആവശ്യം എവിടെ നിന്ന് വരുന്നു? ഞങ്ങൾ ഡവലപ്പർമാരുടെ ഒരു പ്രത്യേക ഗ്രൂപ്പല്ല, മറിച്ച് അവരിൽ പലർക്കും ഒരേസമയം സേവനം നൽകുന്ന ഒരു ടീമാണ്, സിഐ/സിഡി പ്രശ്നങ്ങൾ സമഗ്രമായി പരിഹരിക്കാൻ സഹായിക്കുന്നു എന്നതാണ് വസ്തുത. ഇതിനുള്ള പ്രധാന സാങ്കേതിക ഉപകരണം ഓപ്പൺ സോഴ്സ് യൂട്ടിലിറ്റിയാണ് വെർഫ്. അതിന്റെ പ്രത്യേകത, അത് ഒരൊറ്റ ഫംഗ്ഷൻ നിർവ്വഹിക്കുന്നില്ല, എന്നാൽ എല്ലാ ഘട്ടങ്ങളിലും തുടർച്ചയായ ഡെലിവറി പ്രക്രിയകൾ അനുഗമിക്കുന്നു: അസംബ്ലി മുതൽ വിന്യാസം വരെ.

രജിസ്ട്രിയിലേക്ക് ചിത്രങ്ങൾ പ്രസിദ്ധീകരിക്കുന്നത്* (അവ നിർമ്മിച്ചതിന് തൊട്ടുപിന്നാലെ) അത്തരമൊരു യൂട്ടിലിറ്റിയുടെ വ്യക്തമായ പ്രവർത്തനമാണ്. ഇമേജുകൾ അവിടെ സംഭരണത്തിനായി സ്ഥാപിച്ചിരിക്കുന്നതിനാൽ - നിങ്ങളുടെ സംഭരണം പരിധിയില്ലാത്തതാണെങ്കിൽ - അവ തുടർന്നുള്ള വൃത്തിയാക്കലിന് നിങ്ങൾ ഉത്തരവാദിയായിരിക്കണം. എല്ലാ നിർദ്ദിഷ്ട മാനദണ്ഡങ്ങളും തൃപ്തിപ്പെടുത്തിക്കൊണ്ട് ഞങ്ങൾ ഇതിൽ എങ്ങനെ വിജയം കൈവരിച്ചു എന്നത് കൂടുതൽ ചർച്ചചെയ്യും.

* രജിസ്‌ട്രികൾ തന്നെ വ്യത്യസ്തമാണെങ്കിലും (ഡോക്കർ രജിസ്‌ട്രി, ജിറ്റ്‌ലാബ് കണ്ടെയ്‌നർ രജിസ്‌ട്രി, ഹാർബർ മുതലായവ), അവരുടെ ഉപയോക്താക്കൾ ഒരേ പ്രശ്‌നങ്ങൾ നേരിടുന്നു. ഞങ്ങളുടെ കാര്യത്തിൽ സാർവത്രിക പരിഹാരം രജിസ്ട്രി നടപ്പിലാക്കുന്നതിനെ ആശ്രയിക്കുന്നില്ല, കാരണം രജിസ്ട്രികൾക്ക് പുറത്ത് പ്രവർത്തിക്കുകയും എല്ലാവർക്കും ഒരേ സ്വഭാവം നൽകുകയും ചെയ്യുന്നു.

ഞങ്ങൾ വെർഫ് ഒരു ഉദാഹരണമായി നടപ്പിലാക്കുന്നുണ്ടെങ്കിലും, ഉപയോഗിച്ച സമീപനങ്ങൾ സമാനമായ ബുദ്ധിമുട്ടുകൾ നേരിടുന്ന മറ്റ് ടീമുകൾക്ക് ഉപയോഗപ്രദമാകുമെന്ന് ഞങ്ങൾ പ്രതീക്ഷിക്കുന്നു.

അങ്ങനെ ഞങ്ങൾ തിരക്കിലായി ബാഹ്യ ഇമേജുകൾ വൃത്തിയാക്കുന്നതിനുള്ള ഒരു സംവിധാനം നടപ്പിലാക്കൽ - കണ്ടെയ്നറുകൾക്കുള്ള രജിസ്ട്രികളിൽ ഇതിനകം നിർമ്മിച്ചിരിക്കുന്ന കഴിവുകൾക്ക് പകരം. ടാഗുകളുടെ എണ്ണത്തിനും അവ സൃഷ്ടിച്ച സമയത്തിനും (മുകളിൽ സൂചിപ്പിച്ചത്) അതേ പ്രാകൃത നയങ്ങൾ സൃഷ്ടിക്കുന്നതിന് ഡോക്കർ രജിസ്ട്രി API ഉപയോഗിക്കുന്നതായിരുന്നു ആദ്യപടി. അവയിൽ ചേർത്തു വിന്യസിച്ചിരിക്കുന്ന ഇൻഫ്രാസ്ട്രക്ചറിൽ ഉപയോഗിച്ചിരിക്കുന്ന ചിത്രങ്ങളെ അടിസ്ഥാനമാക്കി ലിസ്റ്റ് അനുവദിക്കുക, അതായത്. കുബെർനെറ്റസ്. രണ്ടാമത്തേതിന്, വിന്യസിച്ചിരിക്കുന്ന എല്ലാ ഉറവിടങ്ങളിലൂടെയും ആവർത്തിക്കാനും മൂല്യങ്ങളുടെ ഒരു ലിസ്റ്റ് നേടാനും Kubernetes API ഉപയോഗിച്ചാൽ മതിയായിരുന്നു. image.

ഈ നിസ്സാരമായ പരിഹാരം ഏറ്റവും നിർണായകമായ പ്രശ്നം പരിഹരിച്ചു (മാനദണ്ഡം നമ്പർ 1), എന്നാൽ ക്ലീനിംഗ് സംവിധാനം മെച്ചപ്പെടുത്തുന്നതിനുള്ള ഞങ്ങളുടെ യാത്രയുടെ തുടക്കം മാത്രമായിരുന്നു അത്. അടുത്തതും കൂടുതൽ രസകരവുമായ ഘട്ടം തീരുമാനമായിരുന്നു പ്രസിദ്ധീകരിച്ച ചിത്രങ്ങൾ Git ചരിത്രവുമായി ബന്ധപ്പെടുത്തുക.

ടാഗിംഗ് സ്കീമുകൾ

ആരംഭിക്കുന്നതിന്, അന്തിമ ചിത്രം വൃത്തിയാക്കുന്നതിന് ആവശ്യമായ വിവരങ്ങൾ സംഭരിക്കേണ്ട ഒരു സമീപനം ഞങ്ങൾ തിരഞ്ഞെടുത്തു, കൂടാതെ ടാഗിംഗ് സ്കീമുകളിൽ പ്രക്രിയ നിർമ്മിക്കുകയും ചെയ്തു. ഒരു ചിത്രം പ്രസിദ്ധീകരിക്കുമ്പോൾ, ഉപയോക്താവ് ഒരു നിർദ്ദിഷ്ട ടാഗിംഗ് ഓപ്ഷൻ തിരഞ്ഞെടുത്തു (git-branch, git-commit അഥവാ git-tag) കൂടാതെ അനുബന്ധ മൂല്യം ഉപയോഗിച്ചു. CI സിസ്റ്റങ്ങളിൽ, പരിസ്ഥിതി വേരിയബിളുകളെ അടിസ്ഥാനമാക്കി ഈ മൂല്യങ്ങൾ സ്വയമേവ സജ്ജീകരിച്ചിരിക്കുന്നു. സത്യത്തിൽ അന്തിമ ചിത്രം ഒരു നിർദ്ദിഷ്ട Git പ്രാകൃതവുമായി ബന്ധപ്പെട്ടിരിക്കുന്നു, ലേബലുകളിൽ വൃത്തിയാക്കുന്നതിന് ആവശ്യമായ ഡാറ്റ സംഭരിക്കുന്നു.

ഈ സമീപനം Git-നെ സത്യത്തിന്റെ ഏക ഉറവിടമായി ഉപയോഗിക്കാൻ അനുവദിക്കുന്ന ഒരു കൂട്ടം നയങ്ങളിൽ കലാശിച്ചു:

• Git-ൽ ഒരു ബ്രാഞ്ച്/ടാഗ് ഇല്ലാതാക്കുമ്പോൾ, രജിസ്ട്രിയിലെ അനുബന്ധ ചിത്രങ്ങൾ സ്വയമേവ ഇല്ലാതാക്കപ്പെടും.
• തിരഞ്ഞെടുത്ത സ്‌കീമയിൽ ഉപയോഗിച്ച ടാഗുകളുടെ എണ്ണവും അനുബന്ധ കമ്മിറ്റ് സൃഷ്‌ടിച്ച സമയവും ഉപയോഗിച്ച് Git ടാഗുകളുമായും കമ്മിറ്റുകളുമായും ബന്ധപ്പെട്ട ചിത്രങ്ങളുടെ എണ്ണം നിയന്ത്രിക്കാനാകും.

മൊത്തത്തിൽ, തത്ഫലമായുണ്ടാകുന്ന നടപ്പാക്കൽ ഞങ്ങളുടെ ആവശ്യങ്ങൾ തൃപ്തിപ്പെടുത്തി, എന്നാൽ ഒരു പുതിയ വെല്ലുവിളി ഉടൻ തന്നെ ഞങ്ങളെ കാത്തിരുന്നു. Git പ്രിമിറ്റീവുകളെ അടിസ്ഥാനമാക്കിയുള്ള ടാഗിംഗ് സ്കീമുകൾ ഉപയോഗിക്കുമ്പോൾ, ഞങ്ങൾക്ക് നിരവധി പോരായ്മകൾ നേരിട്ടു എന്നതാണ് വസ്തുത. (അവരുടെ വിവരണം ഈ ലേഖനത്തിന്റെ പരിധിക്കപ്പുറമായതിനാൽ, എല്ലാവർക്കും വിശദാംശങ്ങളുമായി പരിചയപ്പെടാം ഇവിടെ.) അതിനാൽ, ടാഗിംഗിലേക്ക് (ഉള്ളടക്കത്തെ അടിസ്ഥാനമാക്കിയുള്ള ടാഗിംഗ്) കൂടുതൽ കാര്യക്ഷമമായ സമീപനത്തിലേക്ക് മാറാൻ തീരുമാനിച്ചതിനാൽ, ഇമേജ് ക്ലീനിംഗ് നടപ്പിലാക്കുന്നത് പുനഃപരിശോധിക്കേണ്ടി വന്നു.

പുതിയ അൽഗോരിതം

എന്തുകൊണ്ട്? ഉള്ളടക്കം അടിസ്ഥാനമാക്കിയുള്ള ടാഗിംഗ് ഉപയോഗിച്ച്, ഓരോ ടാഗിനും Git-ലെ ഒന്നിലധികം കമ്മിറ്റുകൾ തൃപ്തിപ്പെടുത്താൻ കഴിയും. ചിത്രങ്ങൾ വൃത്തിയാക്കുമ്പോൾ, നിങ്ങൾക്ക് ഇനി അനുമാനിക്കാൻ കഴിയില്ല മാത്രം രജിസ്ട്രിയിൽ പുതിയ ടാഗ് ചേർത്ത കമ്മിറ്റിൽ നിന്ന്.

പുതിയ ക്ലീനിംഗ് അൽഗോരിതത്തിനായി, ടാഗിംഗ് സ്കീമുകളിൽ നിന്ന് മാറി നിർമ്മിക്കാൻ തീരുമാനിച്ചു മെറ്റാ ഇമേജ് പ്രക്രിയ, ഓരോന്നും ഒരു കൂട്ടം സംഭരിക്കുന്നു:

• പ്രസിദ്ധീകരണം നടപ്പിലാക്കിയ പ്രതിബദ്ധത (കണ്ടെയ്‌നർ രജിസ്ട്രിയിൽ ചിത്രം ചേർത്തിട്ടുണ്ടോ, മാറ്റിയിട്ടുണ്ടോ അല്ലെങ്കിൽ അതേപടി നിലവിലുണ്ടോ എന്നത് പ്രശ്നമല്ല);
• സമാഹരിച്ച ചിത്രവുമായി ബന്ധപ്പെട്ട ഞങ്ങളുടെ ആന്തരിക ഐഡന്റിഫയറും.

മറ്റൊരു വിധത്തിൽ പറഞ്ഞാൽ, അത് നൽകപ്പെട്ടു പ്രസിദ്ധീകരിച്ച ടാഗുകളെ Git-ലെ കമ്മിറ്റുകളുമായി ബന്ധിപ്പിക്കുന്നു.

അന്തിമ കോൺഫിഗറേഷനും പൊതു അൽഗോരിതവും

ക്ലീനിംഗ് കോൺഫിഗർ ചെയ്യുമ്പോൾ, നിലവിലെ ഇമേജുകൾ തിരഞ്ഞെടുക്കുന്ന നയങ്ങളിലേക്ക് ഇപ്പോൾ ഉപയോക്താക്കൾക്ക് ആക്സസ് ഉണ്ട്. അത്തരം ഓരോ നയവും നിർവചിച്ചിരിക്കുന്നു:

• നിരവധി റഫറൻസുകൾ, അതായത്. സ്കാനിംഗ് സമയത്ത് ഉപയോഗിക്കുന്ന Git ടാഗുകൾ അല്ലെങ്കിൽ Git ശാഖകൾ;
• സെറ്റിൽ നിന്നുള്ള ഓരോ റഫറൻസിനും വേണ്ടി തിരഞ്ഞ ചിത്രങ്ങളുടെ പരിധിയും.

ദൃഷ്ടാന്തീകരിക്കുന്നതിന്, ഡിഫോൾട്ട് പോളിസി കോൺഫിഗറേഷൻ ഇങ്ങനെയാണ് കാണാൻ തുടങ്ങിയത്:

cleanup:
  keepPolicies:
  - references:
      tag: /.*/
      limit:
        last: 10
  - references:
      branch: /.*/
      limit:
        last: 10
        in: 168h
        operator: And
    imagesPerReference:
      last: 2
      in: 168h
      operator: And
  - references:  
      branch: /^(main|staging|production)$/
    imagesPerReference:
      last: 10

ഈ കോൺഫിഗറേഷനിൽ ഇനിപ്പറയുന്ന നിയമങ്ങൾ പാലിക്കുന്ന മൂന്ന് നയങ്ങൾ അടങ്ങിയിരിക്കുന്നു:

1. അവസാന 10 Git ടാഗുകൾക്കായി ചിത്രം സംരക്ഷിക്കുക (ടാഗ് സൃഷ്ടിച്ച തീയതി പ്രകാരം).
2. കഴിഞ്ഞ ആഴ്‌ചയിലെ പ്രവർത്തനങ്ങളുള്ള 2 ത്രെഡുകളിൽ കൂടുതലായി കഴിഞ്ഞ ആഴ്‌ചയിൽ പ്രസിദ്ധീകരിച്ച 10 ചിത്രങ്ങളിൽ കൂടുതൽ സംരക്ഷിക്കരുത്.
3. ശാഖകൾക്കായി 10 ചിത്രങ്ങൾ സംരക്ഷിക്കുക main, staging и production.

അന്തിമ അൽഗോരിതം ഇനിപ്പറയുന്ന ഘട്ടങ്ങളിലേക്ക് ചുരുങ്ങുന്നു:

• കണ്ടെയ്നർ രജിസ്ട്രിയിൽ നിന്ന് മാനിഫെസ്റ്റുകൾ വീണ്ടെടുക്കുന്നു.
• കുബർനെറ്റസിൽ ഉപയോഗിച്ച ചിത്രങ്ങൾ ഒഴികെ, കാരണം K8s API-യിൽ വോട്ടെടുപ്പ് നടത്തി ഞങ്ങൾ അവരെ നേരത്തെ തന്നെ തിരഞ്ഞെടുത്തിട്ടുണ്ട്.
• Git ചരിത്രം സ്കാൻ ചെയ്യുകയും നിർദ്ദിഷ്ട നയങ്ങളെ അടിസ്ഥാനമാക്കി ചിത്രങ്ങൾ ഒഴിവാക്കുകയും ചെയ്യുന്നു.
• ശേഷിക്കുന്ന ചിത്രങ്ങൾ നീക്കം ചെയ്യുന്നു.

ഞങ്ങളുടെ ചിത്രീകരണത്തിലേക്ക് മടങ്ങുമ്പോൾ, വെർഫിൽ സംഭവിക്കുന്നത് ഇതാണ്:

എന്നിരുന്നാലും, നിങ്ങൾ വെർഫ് ഉപയോഗിക്കുന്നില്ലെങ്കിലും, വിപുലമായ ഇമേജ് ക്ലീനിംഗിന് സമാനമായ ഒരു സമീപനം - ഒന്നല്ലെങ്കിൽ മറ്റൊന്നിൽ (ഇമേജ് ടാഗിംഗിന് മുൻഗണന നൽകുന്ന സമീപനം അനുസരിച്ച്) - മറ്റ് സിസ്റ്റങ്ങൾക്ക്/യൂട്ടിലിറ്റികളിൽ പ്രയോഗിക്കാവുന്നതാണ്. ഇത് ചെയ്യുന്നതിന്, ഉയർന്നുവരുന്ന പ്രശ്നങ്ങൾ ഓർമ്മിക്കുകയും അവയുടെ പരിഹാരം കഴിയുന്നത്ര സുഗമമായി സമന്വയിപ്പിക്കാൻ നിങ്ങളെ അനുവദിക്കുന്ന നിങ്ങളുടെ സ്റ്റാക്കിൽ ആ അവസരങ്ങൾ കണ്ടെത്തുകയും ചെയ്താൽ മതി. പുതിയ വിശദാംശങ്ങളും ചിന്തകളും ഉപയോഗിച്ച് നിങ്ങളുടെ പ്രത്യേക സാഹചര്യം നോക്കാൻ ഞങ്ങൾ സഞ്ചരിച്ച പാത നിങ്ങളെ സഹായിക്കുമെന്ന് ഞങ്ങൾ പ്രതീക്ഷിക്കുന്നു.

തീരുമാനം

• താമസിയാതെ അല്ലെങ്കിൽ പിന്നീട്, മിക്ക ടീമുകളും രജിസ്ട്രി ഓവർഫ്ലോയുടെ പ്രശ്നം നേരിടുന്നു.
• പരിഹാരങ്ങൾക്കായി തിരയുമ്പോൾ, ചിത്രത്തിന്റെ പ്രസക്തിയുടെ മാനദണ്ഡം നിർണ്ണയിക്കേണ്ടത് ആദ്യം ആവശ്യമാണ്.
• ജനപ്രിയ കണ്ടെയ്നർ രജിസ്ട്രി സേവനങ്ങൾ വാഗ്ദാനം ചെയ്യുന്ന ടൂളുകൾ "പുറം ലോകം" കണക്കിലെടുക്കാത്ത വളരെ ലളിതമായ ഒരു ക്ലീനപ്പ് സംഘടിപ്പിക്കാൻ നിങ്ങളെ അനുവദിക്കുന്നു: കുബർനെറ്റസിൽ ഉപയോഗിച്ച ചിത്രങ്ങളും ടീമിന്റെ വർക്ക്ഫ്ലോകളുടെ പ്രത്യേകതകളും.
• ഒരു വഴക്കമുള്ളതും കാര്യക്ഷമവുമായ അൽഗോരിതത്തിന് സിഐ/സിഡി പ്രക്രിയകളെക്കുറിച്ച് ധാരണ ഉണ്ടായിരിക്കുകയും ഡോക്കർ ഇമേജ് ഡാറ്റയിൽ മാത്രമല്ല പ്രവർത്തിക്കുകയും വേണം.

പി.എസ്

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

• «വെർഫ് കളക്ടറിലെ ഉള്ളടക്കം അടിസ്ഥാനമാക്കിയുള്ള ടാഗിംഗ്: എന്തുകൊണ്ട്, എങ്ങനെയാണ് ഇത് പ്രവർത്തിക്കുന്നത്?";
• «വെർഫിലേക്കുള്ള 3-വേ ലയനം: "സ്റ്റിറോയിഡുകളിൽ" ഹെൽമിനൊപ്പം കുബർനെറ്റസിലേക്ക് വിന്യാസം";
• «വെർഫിലെ മോണോറെപ്പോ, മൾട്ടിറെപ്പോ എന്നിവയ്ക്കുള്ള പിന്തുണയും ഡോക്കർ രജിസ്ട്രിയും ഇതുമായി എന്താണ് ചെയ്യേണ്ടത്";
• «werf 1.1 റിലീസ്: ഇന്ന് ബിൽഡർക്കുള്ള മെച്ചപ്പെടുത്തലുകളും ഭാവിയിലേക്കുള്ള പദ്ധതികളും".

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