വെർഫ് കളക്ടറിലെ ഉള്ളടക്കം അടിസ്ഥാനമാക്കിയുള്ള ടാഗിംഗ്: എന്തുകൊണ്ട്, എങ്ങനെയാണ് ഇത് പ്രവർത്തിക്കുന്നത്?

വെർഫ് Kubernetes-ലേക്ക് ആപ്ലിക്കേഷനുകൾ നിർമ്മിക്കുന്നതിനും വിതരണം ചെയ്യുന്നതിനുമുള്ള ഞങ്ങളുടെ ഓപ്പൺ സോഴ്‌സ് GitOps CLI യൂട്ടിലിറ്റിയാണ്. IN റിലീസ് v1.1 ഇമേജ് കളക്ടറിൽ ഒരു പുതിയ ഫീച്ചർ അവതരിപ്പിച്ചു: ഉള്ളടക്കം അനുസരിച്ച് ചിത്രങ്ങൾ ടാഗുചെയ്യുന്നു അല്ലെങ്കിൽ ഉള്ളടക്കം അടിസ്ഥാനമാക്കിയുള്ള ടാഗിംഗ്. ഇതുവരെ, Git ടാഗ്, Git ബ്രാഞ്ച് അല്ലെങ്കിൽ Git കമ്മിറ്റ് എന്നിവ ഉപയോഗിച്ച് ഡോക്കർ ഇമേജുകൾ ടാഗുചെയ്യുന്നത് വെർഫിലെ സാധാരണ ടാഗിംഗ് സ്കീമിൽ ഉൾപ്പെട്ടിരുന്നു. എന്നാൽ ഈ സ്കീമുകൾക്കെല്ലാം പോരായ്മകളുണ്ട്, അത് പുതിയ ടാഗിംഗ് തന്ത്രത്തിലൂടെ പൂർണ്ണമായും പരിഹരിക്കപ്പെടും. അതിനെ കുറിച്ചുള്ള വിശദാംശങ്ങളും എന്തുകൊണ്ട് ഇത് വളരെ നല്ലതാണ്.

ഒരു Git റിപ്പോസിറ്ററിയിൽ നിന്ന് ഒരു കൂട്ടം മൈക്രോസർവീസുകൾ പുറത്തിറക്കുന്നു

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

സേവനങ്ങൾ യഥാർത്ഥത്തിൽ സ്വതന്ത്രവും ഒരൊറ്റ ആപ്ലിക്കേഷനുമായി ബന്ധമില്ലാത്തതുമായ സാഹചര്യങ്ങളുണ്ട്. ഈ സാഹചര്യത്തിൽ, അവ പ്രത്യേക പ്രോജക്റ്റുകളിൽ സ്ഥാപിക്കുകയും ഓരോ പ്രോജക്റ്റുകളിലും പ്രത്യേക സിഐ/സിഡി പ്രക്രിയകളിലൂടെ അവയുടെ റിലീസ് നടപ്പിലാക്കുകയും ചെയ്യും.

എന്നിരുന്നാലും, വാസ്തവത്തിൽ, ഡവലപ്പർമാർ പലപ്പോഴും ഒരൊറ്റ ആപ്ലിക്കേഷനെ നിരവധി മൈക്രോസർവീസുകളായി വിഭജിക്കുന്നു, എന്നാൽ ഓരോന്നിനും ഒരു പ്രത്യേക ശേഖരണവും പ്രോജക്റ്റും സൃഷ്ടിക്കുന്നത് വ്യക്തമായ ഒരു ഓവർകില്ലാണ്. ഈ സാഹചര്യമാണ് കൂടുതൽ ചർച്ചചെയ്യുന്നത്: അത്തരം നിരവധി മൈക്രോസർവീസുകൾ ഒരു പ്രോജക്റ്റ് റിപ്പോസിറ്ററിയിൽ സ്ഥിതിചെയ്യുന്നു, കൂടാതെ CI/CD-യിലെ ഒരൊറ്റ പ്രക്രിയയിലൂടെ റിലീസുകൾ സംഭവിക്കുന്നു.

Git ബ്രാഞ്ചും Git ടാഗും ഉപയോഗിച്ച് ടാഗിംഗ്

ഏറ്റവും സാധാരണമായ ടാഗിംഗ് തന്ത്രമാണ് ഉപയോഗിക്കുന്നതെന്ന് നമുക്ക് പറയാം - ടാഗ്-ഓ-ബ്രാഞ്ച്. Git ശാഖകൾക്കായി, ശാഖയുടെ പേരിനൊപ്പം ചിത്രങ്ങൾ ടാഗ് ചെയ്‌തിരിക്കുന്നു, ഒരു ബ്രാഞ്ചിന് ഒരു സമയം ആ ശാഖയുടെ പേരിൽ ഒരു പ്രസിദ്ധീകരിച്ച ചിത്രം മാത്രമേ ഉണ്ടാകൂ. Git ടാഗുകൾക്കായി, ടാഗ് നാമത്തിനനുസരിച്ച് ചിത്രങ്ങൾ ടാഗ് ചെയ്യുന്നു.

ഒരു പുതിയ Git ടാഗ് സൃഷ്ടിക്കപ്പെടുമ്പോൾ-ഉദാഹരണത്തിന്, ഒരു പുതിയ പതിപ്പ് പുറത്തിറങ്ങുമ്പോൾ-ഡോക്കർ രജിസ്ട്രിയിലെ എല്ലാ പ്രോജക്റ്റ് ഇമേജുകൾക്കുമായി ഒരു പുതിയ ഡോക്കർ ടാഗ് സൃഷ്ടിക്കപ്പെടും:

• myregistry.org/myproject/frontend:v1.1.10
• myregistry.org/myproject/myservice1:v1.1.10
• myregistry.org/myproject/myservice2:v1.1.10
• myregistry.org/myproject/myservice3:v1.1.10
• myregistry.org/myproject/myservice4:v1.1.10
• myregistry.org/myproject/myservice5:v1.1.10
• myregistry.org/myproject/database:v1.1.10

ഈ പുതിയ ചിത്ര നാമങ്ങൾ ഹെൽം ടെംപ്ലേറ്റുകളിലൂടെ കുബർനെറ്റസ് കോൺഫിഗറേഷനിലേക്ക് കൈമാറുന്നു. കമാൻഡ് ഉപയോഗിച്ച് വിന്യാസം ആരംഭിക്കുമ്പോൾ werf deploy ഫീൽഡ് അപ്ഡേറ്റ് ചെയ്യുകയാണ് image Kubernetes റിസോഴ്‌സ് മാനിഫെസ്‌റ്റുചെയ്യുകയും ഇമേജിൻ്റെ പേര് മാറ്റിയതിനാൽ അനുബന്ധ ഉറവിടങ്ങൾ പുനരാരംഭിക്കുകയും ചെയ്യുന്നു.

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

തൽഫലമായി, നിലവിലെ ടാഗിംഗ് സ്കീമിനൊപ്പം നിരവധി വ്യത്യസ്ത ജിറ്റ് റിപ്പോസിറ്ററികൾ വേലിയിറക്കേണ്ടത് ആവശ്യമാണ്, കൂടാതെ ഈ നിരവധി ശേഖരണങ്ങളുടെ റോൾഔട്ട് സംഘടിപ്പിക്കുന്നതിൽ പ്രശ്നം ഉയർന്നുവരുന്നു. പൊതുവേ, അത്തരമൊരു സ്കീം അമിതഭാരവും സങ്കീർണ്ണവുമായി മാറുന്നു. അനാവശ്യമായ പുനരാരംഭങ്ങൾ ഉണ്ടാകാതിരിക്കാൻ നിരവധി സേവനങ്ങൾ ഒരു ശേഖരത്തിലേക്ക് സംയോജിപ്പിച്ച് ഡോക്കർ ടാഗുകൾ സൃഷ്ടിക്കുന്നതാണ് നല്ലത്.

ജിറ്റ് കമ്മിറ്റിന്റെ ടാഗിംഗ്

Git കമിറ്റുകളുമായി ബന്ധപ്പെട്ട ഒരു ടാഗിംഗ് തന്ത്രവും werf-നുണ്ട്.

Git-commit എന്നത് Git റിപ്പോസിറ്ററിയിലെ ഉള്ളടക്കങ്ങൾക്കായുള്ള ഒരു ഐഡന്റിഫയറാണ്, അത് Git റിപ്പോസിറ്ററിയിലെ ഫയലുകളുടെ എഡിറ്റ് ചരിത്രത്തെ ആശ്രയിച്ചിരിക്കുന്നു, അതിനാൽ ഡോക്കർ രജിസ്ട്രിയിൽ ഇമേജുകൾ ടാഗുചെയ്യുന്നതിന് ഇത് ഉപയോഗിക്കുന്നത് യുക്തിസഹമാണെന്ന് തോന്നുന്നു.

എന്നിരുന്നാലും, Git കമ്മിറ്റിന്റെ ടാഗിംഗിന് Git ശാഖകളോ Git ടാഗുകളോ ടാഗുചെയ്യുന്നതിന് സമാനമായ ദോഷങ്ങളുണ്ട്:

• ഫയലുകളൊന്നും മാറ്റാത്ത ഒരു ശൂന്യമായ കമ്മിറ്റ് സൃഷ്ടിക്കാൻ കഴിയും, എന്നാൽ ചിത്രത്തിൻ്റെ ഡോക്കർ ടാഗ് മാറ്റപ്പെടും.
• ഫയലുകൾ മാറ്റാത്ത ഒരു ലയന കമ്മിറ്റ് സൃഷ്ടിക്കാൻ കഴിയും, എന്നാൽ ചിത്രത്തിൻ്റെ ഡോക്കർ ടാഗ് മാറ്റപ്പെടും.
• ഇമേജിലേക്ക് ഇറക്കുമതി ചെയ്യാത്ത Git-ലെ ഫയലുകൾ മാറ്റുന്ന ഒരു പ്രതിബദ്ധത ഉണ്ടാക്കാം, കൂടാതെ ചിത്രത്തിൻ്റെ ഡോക്കർ ടാഗ് വീണ്ടും മാറ്റപ്പെടും.

Git ബ്രാഞ്ചിന്റെ പേര് ടാഗുചെയ്യുന്നത് ചിത്രത്തിന്റെ പതിപ്പിനെ പ്രതിഫലിപ്പിക്കുന്നില്ല

Git ശാഖകൾക്കായുള്ള ടാഗിംഗ് തന്ത്രവുമായി ബന്ധപ്പെട്ട മറ്റൊരു പ്രശ്നമുണ്ട്.

ആ ശാഖയിലെ കമ്മിറ്റുകൾ കാലക്രമത്തിൽ ക്രമാനുഗതമായി ശേഖരിക്കുന്നിടത്തോളം കാലം ബ്രാഞ്ച് നാമം ടാഗുചെയ്യുന്നത് പ്രവർത്തിക്കുന്നു.

നിലവിലെ സ്‌കീമിൽ ഉപയോക്താവ് ഒരു പ്രത്യേക ശാഖയുമായി ബന്ധപ്പെട്ട പഴയ കമ്മിറ്റ് പുനർനിർമ്മിക്കാൻ തുടങ്ങിയാൽ, പഴയ കമ്മിറ്റിനായി ഇമേജിന്റെ പുതുതായി നിർമ്മിച്ച പതിപ്പിനൊപ്പം അനുബന്ധ ഡോക്കർ ടാഗ് ഉപയോഗിച്ച് വെർഫ് ചിത്രം വീണ്ടും എഴുതും. ഇനി മുതൽ ഈ ടാഗ് ഉപയോഗിക്കുന്ന വിന്യാസങ്ങൾ പോഡുകൾ പുനരാരംഭിക്കുമ്പോൾ ചിത്രത്തിന്റെ മറ്റൊരു പതിപ്പ് വലിക്കുന്നതിനുള്ള അപകടസാധ്യതയുണ്ട്, അതിന്റെ ഫലമായി ഞങ്ങളുടെ ആപ്ലിക്കേഷന് CI സിസ്റ്റവുമായുള്ള ബന്ധം നഷ്‌ടപ്പെടുകയും ഡീസിൻക്രണൈസ് ചെയ്യപ്പെടുകയും ചെയ്യും.

കൂടാതെ, അവയ്ക്കിടയിൽ ഒരു ചെറിയ കാലയളവുള്ള ഒരു ശാഖയിലേക്ക് തുടർച്ചയായ പുഷ്കളോടെ, പഴയ പ്രതിബദ്ധത പുതിയതിനേക്കാൾ പിന്നീട് സമാഹരിച്ചേക്കാം: ചിത്രത്തിൻ്റെ പഴയ പതിപ്പ് Git ബ്രാഞ്ച് ടാഗ് ഉപയോഗിച്ച് പുതിയതിനെ പുനരാലേഖനം ചെയ്യും. അത്തരം പ്രശ്നങ്ങൾ ഒരു CI/CD സിസ്റ്റം വഴി പരിഹരിക്കാൻ കഴിയും (ഉദാഹരണത്തിന്, GitLab CI-ൽ രണ്ടാമത്തേതിൻ്റെ പൈപ്പ്ലൈൻ കമ്മിറ്റുകളുടെ ഒരു പരമ്പരയ്ക്കായി സമാരംഭിക്കുന്നു). എന്നിരുന്നാലും, എല്ലാ സിസ്റ്റങ്ങളും ഇതിനെ പിന്തുണയ്ക്കുന്നില്ല, അത്തരമൊരു അടിസ്ഥാന പ്രശ്നം തടയുന്നതിന് കൂടുതൽ വിശ്വസനീയമായ മാർഗം ഉണ്ടായിരിക്കണം.

എന്താണ് ഉള്ളടക്കത്തെ അടിസ്ഥാനമാക്കിയുള്ള ടാഗിംഗ്?

അതിനാൽ, എന്താണ് ഉള്ളടക്കം അടിസ്ഥാനമാക്കിയുള്ള ടാഗിംഗ് - ഉള്ളടക്കം അനുസരിച്ച് ചിത്രങ്ങൾ ടാഗുചെയ്യുന്നു.

ഡോക്കർ ടാഗുകൾ സൃഷ്‌ടിക്കുന്നതിന്, Git പ്രിമിറ്റീവുകളല്ല (Git ബ്രാഞ്ച്, Git ടാഗ്...) ഉപയോഗിക്കുന്നത്, എന്നാൽ ഇതുമായി ബന്ധപ്പെട്ട ഒരു ചെക്ക്‌സം:

• ചിത്രത്തിന്റെ ഉള്ളടക്കം. ഇമേജ് ഐഡി ടാഗ് അതിൻ്റെ ഉള്ളടക്കത്തെ പ്രതിഫലിപ്പിക്കുന്നു. ഒരു പുതിയ പതിപ്പ് നിർമ്മിക്കുമ്പോൾ, ചിത്രത്തിലെ ഫയലുകൾ മാറിയിട്ടില്ലെങ്കിൽ ഈ ഐഡൻ്റിഫയർ മാറില്ല;
• Git-ൽ ഈ ചിത്രം സൃഷ്ടിച്ചതിൻ്റെ ചരിത്രം. വ്യത്യസ്‌ത Git ശാഖകളുമായി ബന്ധപ്പെട്ട ചിത്രങ്ങൾക്കും വെർഫ് വഴിയുള്ള വ്യത്യസ്‌ത ബിൽഡ് ഹിസ്റ്ററിക്കും വ്യത്യസ്‌ത ഐഡി ടാഗുകൾ ഉണ്ടായിരിക്കും.

അത്തരമൊരു ഐഡന്റിഫയർ ടാഗ് വിളിക്കപ്പെടുന്നതാണ് ചിത്രം സ്റ്റേജ് ഒപ്പ്.

ഓരോ ചിത്രവും ഒരു കൂട്ടം ഘട്ടങ്ങൾ ഉൾക്കൊള്ളുന്നു: from, before-install, git-archive, install, imports-after-install, before-setup, ... git-latest-patch തുടങ്ങിയവ. ഓരോ ഘട്ടത്തിനും അതിന്റെ ഉള്ളടക്കം പ്രതിഫലിപ്പിക്കുന്ന ഒരു ഐഡന്റിഫയർ ഉണ്ട് - സ്റ്റേജ് ഒപ്പ് (സ്റ്റേജ് ഒപ്പ്).

ഈ ഘട്ടങ്ങൾ അടങ്ങുന്ന അവസാന ചിത്രം, ഈ ഘട്ടങ്ങളുടെ സെറ്റിന്റെ ഒപ്പ് എന്ന് വിളിക്കപ്പെടുന്ന ടാഗ് ചെയ്തിരിക്കുന്നു - ഘട്ടങ്ങളുടെ ഒപ്പ്, - ഇത് ചിത്രത്തിന്റെ എല്ലാ ഘട്ടങ്ങൾക്കും സാമാന്യവൽക്കരിക്കുന്നു.

കോൺഫിഗറേഷനിൽ നിന്നുള്ള ഓരോ ചിത്രത്തിനും werf.yaml പൊതുവായ സാഹചര്യത്തിൽ, അതിൻ്റേതായ ഒപ്പും അതനുസരിച്ച് ഒരു ഡോക്കർ ടാഗും ഉണ്ടായിരിക്കും.

സ്റ്റേജ് സിഗ്നേച്ചർ ഈ പ്രശ്നങ്ങളെല്ലാം പരിഹരിക്കുന്നു:

• ശൂന്യമായ Git കമ്മിറ്റുകളെ പ്രതിരോധിക്കും.
• ചിത്രത്തിന് പ്രസക്തമല്ലാത്ത ഫയലുകൾ മാറ്റുന്ന Git-ലെ പ്രതിരോധം.
• ഒരു ബ്രാഞ്ചിന്റെ പഴയ Git കമ്മിറ്റുകൾക്കായി ബിൽഡുകൾ പുനരാരംഭിക്കുമ്പോൾ ചിത്രത്തിന്റെ നിലവിലെ പതിപ്പ് ഓവർഹോൾ ചെയ്യുന്ന പ്രശ്നത്തിലേക്ക് നയിക്കില്ല.

ഇത് ഇപ്പോൾ ശുപാർശ ചെയ്യപ്പെടുന്ന ടാഗിംഗ് തന്ത്രമാണ് കൂടാതെ എല്ലാ CI സിസ്റ്റങ്ങൾക്കുമുള്ള werf-ൽ സ്ഥിരസ്ഥിതിയാണിത്.

വെർഫിൽ എങ്ങനെ പ്രവർത്തനക്ഷമമാക്കുകയും ഉപയോഗിക്കുകയും ചെയ്യാം

കമാൻഡിന് ഇപ്പോൾ ഒരു അനുബന്ധ ഓപ്ഷൻ ഉണ്ട് werf publish: --tag-by-stages-signature=true|false

ഒരു CI സിസ്റ്റത്തിൽ, ടാഗിംഗ് തന്ത്രം കമാൻഡ് വ്യക്തമാക്കുന്നു werf ci-env. മുമ്പ്, അതിനുള്ള പരാമീറ്റർ നിർവചിക്കപ്പെട്ടിരുന്നു werf ci-env --tagging-strategy=tag-or-branch. ഇപ്പോൾ, നിങ്ങൾ വ്യക്തമാക്കുകയാണെങ്കിൽ werf ci-env --tagging-strategy=stages-signature അല്ലെങ്കിൽ ഈ ഓപ്ഷൻ വ്യക്തമാക്കരുത്, സ്ഥിരസ്ഥിതിയായി werf ടാഗിംഗ് തന്ത്രം ഉപയോഗിക്കും stages-signature. ടീം werf ci-env കമാൻഡിന് ആവശ്യമായ ഫ്ലാഗുകൾ സ്വയമേവ സജ്ജീകരിക്കും werf build-and-publish (അല്ലെങ്കിൽ werf publish), അതിനാൽ ഈ കമാൻഡുകൾക്ക് അധിക ഓപ്‌ഷനുകളൊന്നും നൽകേണ്ടതില്ല.

ഉദാഹരണത്തിന്, കമാൻഡ്:

werf publish --stages-storage :local --images-repo registry.hello.com/web/core/system --tag-by-stages-signature

...ഇനിപ്പറയുന്ന ചിത്രങ്ങൾ സൃഷ്ടിക്കാൻ കഴിയും:

• registry.hello.com/web/core/system/backend:4ef339f84ca22247f01fb335bb19f46c4434014d8daa3d5d6f0e386d
• registry.hello.com/web/core/system/frontend:f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6

ഇത് 4ef339f84ca22247f01fb335bb19f46c4434014d8daa3d5d6f0e386d ചിത്രത്തിൻ്റെ ഘട്ടങ്ങളുടെ ഒരു ഒപ്പ് ആണ് backendഒപ്പം f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6 - ചിത്ര ഘട്ടങ്ങളുടെ ഒപ്പ് frontend.

പ്രത്യേക പ്രവർത്തനങ്ങൾ ഉപയോഗിക്കുമ്പോൾ werf_container_image и werf_container_env ഹെൽം ടെംപ്ലേറ്റുകളിൽ ഒന്നും മാറ്റേണ്ട ആവശ്യമില്ല: ഈ ഫംഗ്ഷനുകൾ യാന്ത്രികമായി ശരിയായ ഇമേജ് പേരുകൾ സൃഷ്ടിക്കും.

ഒരു CI സിസ്റ്റത്തിലെ കോൺഫിഗറേഷൻ ഉദാഹരണം:

type multiwerf && source <(multiwerf use 1.1 beta)
type werf && source <(werf ci-env gitlab)
werf build-and-publish|deploy

കോൺഫിഗറേഷനെക്കുറിച്ചുള്ള കൂടുതൽ വിവരങ്ങൾ ഡോക്യുമെന്റേഷനിൽ ലഭ്യമാണ്:

• ഡയറക്ടറി → പ്രസിദ്ധീകരണം (പ്രസിദ്ധീകരിക്കുക);
• CI/CD ഉപയോഗിച്ച് പ്രവർത്തിക്കുന്നു → പൊതുവായ വിവരങ്ങൾ → ഘട്ടങ്ങൾ-ഒപ്പ്;
• GitLab CI/CD → .gitlab-ci.yml എന്നിവയുമായുള്ള സംയോജനം.

ആകെ

• പുതിയ ഓപ്ഷൻ werf publish --tag-by-stages-signature=true|false.
• പുതിയ ഓപ്ഷൻ മൂല്യം werf ci-env --tagging-strategy=stages-signature|tag-or-branch (വ്യക്തമാക്കിയിട്ടില്ലെങ്കിൽ, സ്ഥിരസ്ഥിതി ആയിരിക്കും stages-signature).
• നിങ്ങൾ മുമ്പ് Git commits-നായി ടാഗിംഗ് ഓപ്ഷനുകൾ ഉപയോഗിച്ചിരുന്നെങ്കിൽ (WERF_TAG_GIT_COMMIT അല്ലെങ്കിൽ ഓപ്ഷൻ werf publish --tag-git-commit COMMIT), തുടർന്ന് ടാഗിംഗ് തന്ത്രത്തിലേക്ക് മാറുന്നത് ഉറപ്പാക്കുക ഘട്ടങ്ങൾ-ഒപ്പ്.
• പുതിയ പദ്ധതികൾ ഉടൻ തന്നെ പുതിയ ടാഗിംഗ് സ്കീമിലേക്ക് മാറ്റുന്നതാണ് നല്ലത്.
• werf 1.1 ലേക്ക് മാറ്റുമ്പോൾ, പഴയ പ്രോജക്റ്റുകൾ പുതിയ ടാഗിംഗ് സ്കീമിലേക്ക് മാറ്റുന്നത് നല്ലതാണ്, എന്നാൽ പഴയത് ടാഗ്-ഓ-ബ്രാഞ്ച് ഇപ്പോഴും പിന്തുണയ്ക്കുന്നു.

ഉള്ളടക്കം അടിസ്ഥാനമാക്കിയുള്ള ടാഗിംഗ് ലേഖനത്തിൽ ഉൾപ്പെടുത്തിയിരിക്കുന്ന എല്ലാ പ്രശ്നങ്ങളും പരിഹരിക്കുന്നു:

• ശൂന്യമായ Git കമ്മിറ്റുകളോടുള്ള ഡോക്കർ ടാഗ് നാമ പ്രതിരോധം.
• Git-ലേക്കുള്ള ഡോക്കർ ടാഗ് നാമത്തിന്റെ പ്രതിരോധം, ചിത്രത്തിന് അപ്രസക്തമായ ഫയലുകൾ മാറ്റുന്നു.
• Git ശാഖകൾക്കായുള്ള പഴയ Git കമ്മിറ്റുകൾക്കായുള്ള ബിൽഡുകൾ പുനരാരംഭിക്കുമ്പോൾ ചിത്രത്തിൻ്റെ നിലവിലെ പതിപ്പ് ഓവർഹോൾ ചെയ്യുന്ന പ്രശ്നത്തിലേക്ക് നയിക്കില്ല.

ഉപയോഗികുക! ഒപ്പം ഞങ്ങളെ സന്ദർശിക്കാൻ മറക്കരുത് സാമൂഹികംഒരു പ്രശ്നം സൃഷ്ടിക്കുന്നതിനോ നിലവിലുള്ളത് കണ്ടെത്തുന്നതിനോ ഒരു പ്ലസ് ചേർക്കുക, ഒരു PR സൃഷ്ടിക്കുക അല്ലെങ്കിൽ പ്രോജക്റ്റിൻ്റെ വികസനം കാണുക.

പി.എസ്

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

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

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