GitOps: പുൾ, പുഷ് രീതികളുടെ താരതമ്യം

കുറിപ്പ്. വിവർത്തനം.: Kubernetes കമ്മ്യൂണിറ്റിയിൽ, GitOps എന്ന ഒരു ട്രെൻഡ് വ്യക്തമായ ജനപ്രീതി നേടുന്നു, ഞങ്ങൾ വ്യക്തിപരമായി കണ്ടതുപോലെ, സന്ദർശിക്കുന്നു KubeCon Europe 2019. ഈ പദം താരതമ്യേന അടുത്തിടെയുള്ളതാണ് കണ്ടുപിടിച്ചു Weaveworks-ന്റെ തലവൻ - അലക്സിസ് റിച്ചാർഡ്‌സൺ - കൂടാതെ ഡെവലപ്പർമാർക്ക് പരിചിതമായ ഉപകരണങ്ങളുടെ ഉപയോഗം (പ്രാഥമികമായി Git, അതിനാൽ പേര്) പ്രവർത്തന പ്രശ്നങ്ങൾ പരിഹരിക്കാൻ അർത്ഥമാക്കുന്നു. പ്രത്യേകിച്ചും, ഞങ്ങൾ കുബെർനെറ്റസിന്റെ പ്രവർത്തനത്തെക്കുറിച്ചാണ് സംസാരിക്കുന്നത്, അതിന്റെ കോൺഫിഗറേഷനുകൾ Git-ൽ സംഭരിക്കുകയും ക്ലസ്റ്ററിലേക്ക് സ്വയമേവ മാറ്റങ്ങൾ വരുത്തുകയും ചെയ്യുന്നു. ഈ ലേഖനത്തിൽ ഈ റോൾഔട്ടിലേക്കുള്ള രണ്ട് സമീപനങ്ങളെക്കുറിച്ച് മത്തിയാസ് ജെജി സംസാരിക്കുന്നു.

കഴിഞ്ഞ വർഷം (വാസ്തവത്തിൽ, ഔപചാരികമായി ഇത് 2017 ഓഗസ്റ്റിൽ സംഭവിച്ചു - ഏകദേശം. വിവർത്തനം.) കുബർനെറ്റസിൽ ആപ്ലിക്കേഷനുകൾ വിന്യസിക്കാൻ ഒരു പുതിയ സമീപനമുണ്ട്. ഇതിനെ GitOps എന്ന് വിളിക്കുന്നു, വിന്യാസ പതിപ്പുകൾ ഒരു Git റിപ്പോസിറ്ററിയുടെ സുരക്ഷിത പരിതസ്ഥിതിയിൽ ട്രാക്ക് ചെയ്യപ്പെടുന്നു എന്ന അടിസ്ഥാന ആശയത്തെ അടിസ്ഥാനമാക്കിയുള്ളതാണ് ഇത്.

ഈ സമീപനത്തിന്റെ പ്രധാന ഗുണങ്ങൾ ഇനിപ്പറയുന്നവയാണ്::

1. വിന്യാസ പതിപ്പ്, ചരിത്രം മാറ്റുക. മുഴുവൻ ക്ലസ്റ്ററിന്റെയും അവസ്ഥ ഒരു Git റിപ്പോസിറ്ററിയിൽ സംഭരിച്ചിരിക്കുന്നു, വിന്യാസങ്ങൾ കമ്മിറ്റുകളിലൂടെ മാത്രമേ അപ്ഡേറ്റ് ചെയ്യപ്പെടുകയുള്ളൂ. കൂടാതെ, കമ്മിറ്റ് ഹിസ്റ്ററി ഉപയോഗിച്ച് എല്ലാ മാറ്റങ്ങളും ട്രാക്ക് ചെയ്യാനാകും.
2. പരിചിതമായ Git കമാൻഡുകൾ ഉപയോഗിച്ച് റോൾബാക്കുകൾ. ലളിതം git reset വിന്യാസങ്ങളിലെ മാറ്റങ്ങൾ പുനഃസജ്ജമാക്കാൻ നിങ്ങളെ അനുവദിക്കുന്നു; കഴിഞ്ഞ സംസ്ഥാനങ്ങൾ എപ്പോഴും ലഭ്യമാണ്.
3. റെഡി ആക്സസ് നിയന്ത്രണം. സാധാരണഗതിയിൽ, ഒരു Git സിസ്റ്റത്തിൽ ധാരാളം സെൻസിറ്റീവ് ഡാറ്റ അടങ്ങിയിരിക്കുന്നു, അതിനാൽ മിക്ക കമ്പനികളും അത് സംരക്ഷിക്കുന്നതിൽ പ്രത്യേക ശ്രദ്ധ ചെലുത്തുന്നു. അതനുസരിച്ച്, വിന്യാസങ്ങളുള്ള പ്രവർത്തനങ്ങൾക്കും ഈ പരിരക്ഷ ബാധകമാണ്.
4. വിന്യാസങ്ങൾക്കുള്ള നയങ്ങൾ. മിക്ക Git സിസ്റ്റങ്ങളും പ്രാദേശികമായി ബ്രാഞ്ച്-ബൈ-ബ്രാഞ്ച് നയങ്ങളെ പിന്തുണയ്ക്കുന്നു-ഉദാഹരണത്തിന്, പുൾ അഭ്യർത്ഥനകൾക്ക് മാത്രമേ മാസ്റ്റർ അപ്‌ഡേറ്റ് ചെയ്യാൻ കഴിയൂ, മാറ്റങ്ങൾ മറ്റൊരു ടീം അംഗം അവലോകനം ചെയ്യുകയും അംഗീകരിക്കുകയും വേണം. ആക്സസ് നിയന്ത്രണം പോലെ, വിന്യാസ അപ്ഡേറ്റുകൾക്കും അതേ നയങ്ങൾ ബാധകമാണ്.

നിങ്ങൾക്ക് കാണാനാകുന്നതുപോലെ, GitOps രീതിക്ക് ധാരാളം ഗുണങ്ങളുണ്ട്. കഴിഞ്ഞ വർഷം, രണ്ട് സമീപനങ്ങൾ പ്രത്യേക ജനപ്രീതി നേടിയിട്ടുണ്ട്. ഒന്ന് പുഷ് ബേസ്ഡ്, മറ്റൊന്ന് പുൾ ബേസ്ഡ്. അവ നോക്കുന്നതിന് മുമ്പ്, സാധാരണ കുബർനെറ്റസ് വിന്യാസങ്ങൾ എങ്ങനെയുണ്ടെന്ന് നോക്കാം.

വിന്യാസ രീതികൾ

സമീപ വർഷങ്ങളിൽ, കുബർനെറ്റസ് വിന്യാസങ്ങൾക്കായി വിവിധ രീതികളും ഉപകരണങ്ങളും സ്ഥാപിച്ചു:

1. നേറ്റീവ് Kubernetes/Kustomize ടെംപ്ലേറ്റുകളെ അടിസ്ഥാനമാക്കി. Kubernetes-ൽ ആപ്ലിക്കേഷനുകൾ വിന്യസിക്കാനുള്ള ഏറ്റവും എളുപ്പമുള്ള മാർഗമാണിത്. ഡെവലപ്പർ അടിസ്ഥാന YAML ഫയലുകൾ സൃഷ്ടിക്കുകയും അവ പ്രയോഗിക്കുകയും ചെയ്യുന്നു. ഒരേ ടെംപ്ലേറ്റുകൾ നിരന്തരം മാറ്റിയെഴുതുന്നതിൽ നിന്ന് രക്ഷപ്പെടാൻ, കസ്റ്റോമൈസ് വികസിപ്പിച്ചെടുത്തു (ഇത് കുബർനെറ്റസ് ടെംപ്ലേറ്റുകളെ മൊഡ്യൂളുകളാക്കി മാറ്റുന്നു). കുറിപ്പ്. വിവർത്തനം.: Kustomize kubectl-ലേക്ക് സംയോജിപ്പിച്ചിരിക്കുന്നു കുബർനെറ്റസ് 1.14 റിലീസ്.
2. ഹെൽം ചാർട്ടുകൾ. ടെംപ്ലേറ്റുകൾ, init കണ്ടെയ്‌നറുകൾ, സൈഡ്‌കാറുകൾ മുതലായവയുടെ സെറ്റ് സൃഷ്‌ടിക്കുന്നതിന് ഹെൽം ചാർട്ടുകൾ നിങ്ങളെ അനുവദിക്കുന്നു, അവ ടെംപ്ലേറ്റ് അടിസ്ഥാനമാക്കിയുള്ള സമീപനത്തേക്കാൾ കൂടുതൽ വഴക്കമുള്ള ഇഷ്‌ടാനുസൃതമാക്കൽ ഓപ്‌ഷനുകൾ ഉപയോഗിച്ച് അപ്ലിക്കേഷനുകൾ വിന്യസിക്കാൻ ഉപയോഗിക്കുന്നു. ഈ രീതി ടെംപ്ലേറ്റ് ചെയ്ത YAML ഫയലുകളെ അടിസ്ഥാനമാക്കിയുള്ളതാണ്. ഹെൽം അവയെ വിവിധ പാരാമീറ്ററുകൾ ഉപയോഗിച്ച് നിറയ്ക്കുകയും തുടർന്ന് അവയെ ക്ലസ്റ്ററിലേക്ക് വിന്യസിക്കുകയും അപ്‌ഡേറ്റുകളും റോൾബാക്കുകളും അനുവദിക്കുകയും ചെയ്യുന്ന ക്ലസ്റ്റർ ഘടകമായ ടില്ലറിലേക്ക് അയയ്ക്കുന്നു. പ്രധാന കാര്യം, ഹെൽം അടിസ്ഥാനപരമായി ആവശ്യമുള്ള മൂല്യങ്ങൾ ടെംപ്ലേറ്റുകളിലേക്ക് തിരുകുകയും പരമ്പരാഗത സമീപനത്തിൽ ചെയ്യുന്നത് പോലെ തന്നെ അവ പ്രയോഗിക്കുകയും ചെയ്യുന്നു എന്നതാണ്. (എല്ലാം എങ്ങനെ പ്രവർത്തിക്കുന്നു എന്നതിനെക്കുറിച്ചും നിങ്ങൾക്ക് ഇത് എങ്ങനെ ഉപയോഗിക്കാം എന്നതിനെക്കുറിച്ചും കൂടുതൽ വായിക്കുക ഹെൽമിന്റെ ലേഖനം - ഏകദേശം. പരിഭാഷ.). വൈവിധ്യമാർന്ന ജോലികൾ ഉൾക്കൊള്ളുന്ന റെഡിമെയ്ഡ് ഹെൽം ചാർട്ടുകൾ ഉണ്ട്.
3. ഇതര ഉപകരണങ്ങൾ. നിരവധി ബദൽ ഉപകരണങ്ങൾ ഉണ്ട്. അവയ്‌ക്കെല്ലാം പൊതുവായുള്ളത്, അവർ ചില ടെംപ്ലേറ്റ് ഫയലുകളെ കുബെർനെറ്റസ്-റീഡബിൾ YAML ഫയലുകളാക്കി മാറ്റുകയും തുടർന്ന് അവ ഉപയോഗിക്കുകയും ചെയ്യുന്നു എന്നതാണ്.

ഞങ്ങളുടെ ജോലിയിൽ, പ്രധാനപ്പെട്ട ടൂളുകൾക്കായി ഞങ്ങൾ നിരന്തരം ഹെൽം ചാർട്ടുകളും (അവർക്ക് ഇതിനകം ധാരാളം കാര്യങ്ങൾ തയ്യാറായതിനാൽ, അത് ജീവിതം വളരെ എളുപ്പമാക്കുന്നു) ഞങ്ങളുടെ സ്വന്തം ആപ്ലിക്കേഷനുകൾ വിന്യസിക്കുന്നതിന് "ശുദ്ധമായ" Kubernetes YAML ഫയലുകളും ഉപയോഗിക്കുന്നു.

വലിക്കുക തള്ളൂക

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

NB! GitOps ഉപയോഗിക്കുന്നതിന്റെ എല്ലാ നേട്ടങ്ങളും രണ്ട് സമീപനങ്ങൾക്കും സമാനമാണ്.

പുൾ അടിസ്ഥാനമാക്കിയുള്ള സമീപനം

എല്ലാ മാറ്റങ്ങളും ക്ലസ്റ്ററിനുള്ളിൽ നിന്ന് പ്രയോഗിക്കുന്നു എന്ന വസ്തുതയെ അടിസ്ഥാനമാക്കിയാണ് പുൾ സമീപനം. അനുബന്ധ Git, Docker Registry repositories പതിവായി പരിശോധിക്കുന്ന ഒരു ഓപ്പറേറ്റർ ക്ലസ്റ്ററിനുള്ളിൽ ഉണ്ട്. അവയിൽ എന്തെങ്കിലും മാറ്റങ്ങൾ സംഭവിക്കുകയാണെങ്കിൽ, ക്ലസ്റ്ററിന്റെ അവസ്ഥ ആന്തരികമായി അപ്ഡേറ്റ് ചെയ്യപ്പെടും. ഒരു ബാഹ്യ ക്ലയന്റിനും ക്ലസ്റ്റർ അഡ്മിനിസ്ട്രേറ്റർ അവകാശങ്ങളിലേക്ക് ആക്‌സസ് ഇല്ലാത്തതിനാൽ ഈ പ്രക്രിയ സാധാരണയായി വളരെ സുരക്ഷിതമായി കണക്കാക്കപ്പെടുന്നു.

പ്രോസ്:

1. ക്ലസ്റ്ററിൽ മാറ്റങ്ങൾ വരുത്താൻ ഒരു ബാഹ്യ ക്ലയന്റിനും അവകാശമില്ല; എല്ലാ അപ്‌ഡേറ്റുകളും ഉള്ളിൽ നിന്നാണ്.
2. ഹെൽം ചാർട്ട് അപ്‌ഡേറ്റുകൾ സമന്വയിപ്പിക്കാനും ക്ലസ്റ്ററിലേക്ക് ലിങ്ക് ചെയ്യാനും ചില ടൂളുകൾ നിങ്ങളെ അനുവദിക്കുന്നു.
3. പുതിയ പതിപ്പുകൾക്കായി ഡോക്കർ രജിസ്ട്രി സ്കാൻ ചെയ്യാവുന്നതാണ്. ഒരു പുതിയ ചിത്രം ലഭ്യമാണെങ്കിൽ, Git ശേഖരണവും വിന്യാസവും പുതിയ പതിപ്പിലേക്ക് അപ്ഡേറ്റ് ചെയ്യപ്പെടും.
4. വ്യത്യസ്‌ത Git റിപ്പോസിറ്ററികളും അനുമതികളും ഉപയോഗിച്ച് വിവിധ നെയിംസ്‌പെയ്‌സുകളിൽ പുൾ ടൂളുകൾ വിതരണം ചെയ്യാൻ കഴിയും. ഇതിന് നന്ദി, ഒരു മൾട്ടിടെനന്റ് മോഡൽ ഉപയോഗിക്കാം. ഉദാഹരണത്തിന്, ടീം എ നെയിംസ്പേസ് എ ഉപയോഗിച്ചേക്കാം, ടീം ബി നെയിംസ്പേസ് ബി ഉപയോഗിച്ചേക്കാം, ഇൻഫ്രാസ്ട്രക്ചർ ടീം ആഗോള ഇടം ഉപയോഗിച്ചേക്കാം.
5. ചട്ടം പോലെ, ഉപകരണങ്ങൾ വളരെ ഭാരം കുറഞ്ഞതാണ്.
6. ഓപ്പറേറ്റർ പോലുള്ള ഉപകരണങ്ങളുമായി സംയോജിപ്പിച്ചിരിക്കുന്നു ബിറ്റ്നാമി സീൽ ചെയ്ത രഹസ്യങ്ങൾ, രഹസ്യങ്ങൾ ഒരു Git റിപ്പോസിറ്ററിയിൽ എൻക്രിപ്റ്റുചെയ്‌ത് സംഭരിക്കാനും ക്ലസ്റ്ററിനുള്ളിൽ വീണ്ടെടുക്കാനും കഴിയും.
7. ക്ലസ്റ്ററിനുള്ളിൽ വിന്യാസങ്ങൾ നടക്കുന്നതിനാൽ സിഡി പൈപ്പ്ലൈനുകളുമായി ബന്ധമില്ല.

Минусы:

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

പുഷ് അടിസ്ഥാനമാക്കിയുള്ള സമീപനം

പുഷ് സമീപനത്തിൽ, Git ശേഖരണത്തോടുള്ള പ്രതിബദ്ധതയ്ക്ക് ശേഷം അല്ലെങ്കിൽ മുമ്പത്തെ CI പൈപ്പ്ലൈൻ വിജയിച്ചാൽ, ഒരു ബാഹ്യ സിസ്റ്റം (പ്രധാനമായും സിഡി പൈപ്പ്ലൈനുകൾ) ക്ലസ്റ്ററിലേക്ക് വിന്യാസം ആരംഭിക്കുന്നു. ഈ സമീപനത്തിൽ, സിസ്റ്റത്തിന് ക്ലസ്റ്ററിലേക്ക് ആക്സസ് ഉണ്ട്.

പുലി:

1. Git റിപ്പോസിറ്ററിയും ബിൽഡ് പൈപ്പ്‌ലൈനും ആണ് സുരക്ഷ നിർണ്ണയിക്കുന്നത്.
2. ഹെൽം ചാർട്ടുകൾ വിന്യസിക്കുന്നത് എളുപ്പവും ഹെൽം പ്ലഗിന്നുകളെ പിന്തുണയ്ക്കുന്നതുമാണ്.
3. രഹസ്യങ്ങൾ കൈകാര്യം ചെയ്യാൻ എളുപ്പമാണ്, കാരണം രഹസ്യങ്ങൾ പൈപ്പ് ലൈനുകളിൽ ഉപയോഗിക്കാനും Git-ൽ എൻക്രിപ്റ്റ് ചെയ്‌ത് സൂക്ഷിക്കാനും കഴിയും (ഉപയോക്താവിന്റെ മുൻഗണനകൾ അനുസരിച്ച്).
4. ഒരു പ്രത്യേക ഉപകരണവുമായി ബന്ധമില്ല, കാരണം ഏത് തരവും ഉപയോഗിക്കാം.
5. ബിൽഡ് പൈപ്പ്‌ലൈൻ വഴി കണ്ടെയ്‌നർ പതിപ്പ് അപ്‌ഡേറ്റുകൾ ആരംഭിക്കാൻ കഴിയും.

Минусы:

1. ക്ലസ്റ്റർ ആക്സസ് ഡാറ്റ ബിൽഡ് സിസ്റ്റത്തിനുള്ളിലാണ്.
2. വിന്യാസ കണ്ടെയ്‌നറുകൾ അപ്‌ഡേറ്റ് ചെയ്യുന്നത് ഒരു പുൾ പ്രോസസ് ഉപയോഗിച്ച് ഇപ്പോഴും എളുപ്പമാണ്.
3. സിഡി സിസ്റ്റത്തെ വളരെയധികം ആശ്രയിക്കുന്നു, കാരണം നമുക്ക് ആവശ്യമായ പൈപ്പ് ലൈനുകൾ യഥാർത്ഥത്തിൽ Gitlab റണ്ണേഴ്സിനായി എഴുതിയതാകാം, തുടർന്ന് ടീം Azure DevOps അല്ലെങ്കിൽ Jenkins ലേക്ക് മാറാൻ തീരുമാനിക്കുന്നു... കൂടാതെ ധാരാളം ബിൽഡ് പൈപ്പ്ലൈനുകൾ മൈഗ്രേറ്റ് ചെയ്യേണ്ടിവരും.

ഫലങ്ങൾ: തള്ളുകയോ വലിക്കുകയോ?

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

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

അതിനാൽ, പുൾ സമീപനം കൂടുതൽ അധ്വാനമുള്ളതും സുരക്ഷാ ആനുകൂല്യം നൽകുന്നില്ലെങ്കിൽ, പുഷ് സമീപനം മാത്രം ഉപയോഗിക്കുന്നത് യുക്തിസഹമല്ലേ? എന്നാൽ പുഷ് സമീപനത്തിൽ നിങ്ങൾ സിഡി സിസ്റ്റവുമായി വളരെയധികം ബന്ധപ്പെട്ടിരിക്കുന്നുവെന്നും ഒരുപക്ഷേ, ഇത് ചെയ്യാതിരിക്കുന്നതാണ് നല്ലതെന്നും അതിനാൽ ഭാവിയിൽ മൈഗ്രേഷനുകൾ നടത്തുന്നത് എളുപ്പമാകുമെന്നും ആരെങ്കിലും വാദിച്ചേക്കാം.

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

ഈ വിഷയത്തെക്കുറിച്ചുള്ള എന്റെ അനുഭവം നിങ്ങളുടെ തരം വിന്യാസത്തിന് ഏറ്റവും അനുയോജ്യമായ രീതി ഏതെന്ന് തീരുമാനിക്കാൻ നിങ്ങളെ സഹായിക്കുമെന്ന് ഞാൻ പ്രതീക്ഷിക്കുന്നു, നിങ്ങളുടെ അഭിപ്രായം കേൾക്കുന്നതിൽ എനിക്ക് സന്തോഷമുണ്ട്.

വിവർത്തകനിൽ നിന്നുള്ള PS കുറിപ്പ്

പുൾ മോഡലിന്റെ പോരായ്മ, റെൻഡർ ചെയ്‌ത മാനിഫെസ്റ്റുകൾ Git-ൽ ഉൾപ്പെടുത്തുന്നത് ബുദ്ധിമുട്ടാണ്, എന്നാൽ പുൾ മോഡലിലെ സിഡി പൈപ്പ്‌ലൈൻ റോൾഔട്ടിൽ നിന്ന് വേറിട്ട് ജീവിക്കുകയും അടിസ്ഥാനപരമായി ഒരു വിഭാഗ പൈപ്പ്‌ലൈനായി മാറുകയും ചെയ്യുന്നു എന്നതാണ്. തുടർച്ചയായി പ്രയോഗിക്കുക. അതിനാൽ, എല്ലാ വിന്യാസങ്ങളിൽ നിന്നും അവരുടെ സ്റ്റാറ്റസ് ശേഖരിക്കാനും എങ്ങനെയെങ്കിലും ലോഗുകൾ/സ്റ്റാറ്റസ് എന്നിവയിലേക്ക് പ്രവേശനം നൽകാനും കൂടുതൽ പരിശ്രമം ആവശ്യമായി വരും.

ഈ അർത്ഥത്തിൽ, റോൾഔട്ടിന്റെ ചില ഗ്യാരന്റികളെങ്കിലും നൽകാൻ പുഷ് മോഡൽ ഞങ്ങളെ അനുവദിക്കുന്നു, കാരണം പൈപ്പ്ലൈനിന്റെ ആയുസ്സ് റോൾഔട്ടിന്റെ ആയുസ്സിന് തുല്യമാക്കാം.

ഞങ്ങൾ രണ്ട് മോഡലുകളും പരീക്ഷിക്കുകയും ലേഖനത്തിന്റെ രചയിതാവിന്റെ അതേ നിഗമനങ്ങളിൽ എത്തിച്ചേരുകയും ചെയ്തു:

1. ധാരാളം ക്ലസ്റ്ററുകളിൽ സിസ്റ്റം ഘടകങ്ങളുടെ അപ്‌ഡേറ്റുകൾ സംഘടിപ്പിക്കുന്നതിന് പുൾ മോഡൽ ഞങ്ങൾക്ക് അനുയോജ്യമാണ് (കാണുക. addon-operator-നെക്കുറിച്ചുള്ള ലേഖനം).
2. GitLab CI അടിസ്ഥാനമാക്കിയുള്ള പുഷ് മോഡൽ ഹെൽം ചാർട്ടുകൾ ഉപയോഗിച്ച് ആപ്ലിക്കേഷനുകൾ പുറത്തിറക്കുന്നതിന് അനുയോജ്യമാണ്. അതേ സമയം, പൈപ്പ്ലൈനുകൾക്കുള്ളിലെ വിന്യാസങ്ങളുടെ റോൾഔട്ട് ഉപകരണം ഉപയോഗിച്ച് നിരീക്ഷിക്കുന്നു വെർഫ്. വഴിയിൽ, ഞങ്ങളുടെ ഈ പ്രോജക്റ്റിന്റെ പശ്ചാത്തലത്തിൽ, KubeCon Europe'19-ലെ ഞങ്ങളുടെ സ്റ്റാൻഡിൽ DevOps എഞ്ചിനീയർമാരുടെ ഗുരുതരമായ പ്രശ്‌നങ്ങൾ ചർച്ച ചെയ്തപ്പോൾ ഞങ്ങൾ നിരന്തരമായ “GitOps” കേട്ടു.

വിവർത്തകനിൽ നിന്നുള്ള PPS

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

• «കുബെർനെറ്റസ് നുറുങ്ങുകളും തന്ത്രങ്ങളും: ഒരു ക്ലസ്റ്ററിൽ പ്രവർത്തിക്കുന്ന ഉറവിടങ്ങൾ ഹെൽം 2 മാനേജ്മെന്റിലേക്ക് കൈമാറുന്നു";
• «കുബെർനെറ്റസ് റിസോഴ്‌സുകൾ ട്രാക്ക് ചെയ്യുന്നതിനുള്ള ഒരു ലൈബ്രറിയായ കുബെഡോഗ് അവതരിപ്പിക്കുന്നു";
• «കുബർനെറ്റസ് വികസിപ്പിക്കുകയും പൂരകമാക്കുകയും ചെയ്യുക (അവലോകനവും വീഡിയോ റിപ്പോർട്ടും)";
• «GitLab CI-ൽ ഇഷ്‌ടാനുസൃത വർക്ക്ഫ്ലോകൾ സൃഷ്‌ടിക്കുന്നതിനുള്ള നുറുങ്ങുകൾ".

രജിസ്റ്റർ ചെയ്ത ഉപയോക്താക്കൾക്ക് മാത്രമേ സർവേയിൽ പങ്കെടുക്കാൻ കഴിയൂ. സൈൻ ഇൻദയവായി.

നിങ്ങൾ GitOps ഉപയോഗിക്കുന്നുണ്ടോ?

• അതെ, സമീപനം വലിക്കുക

• അതെ, തള്ളുക

• അതെ, വലിക്കുക + തള്ളുക

• അതെ, മറ്റെന്തെങ്കിലും

• ഇല്ല

30 ഉപയോക്താക്കൾ വോട്ട് ചെയ്തു. 10 ഉപയോക്താക്കൾ വിട്ടുനിന്നു.

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