OpenShift-നുള്ള GitOps-ലേക്കുള്ള ആമുഖം

ഇന്ന് നമ്മൾ GitOps-ന്റെ തത്വങ്ങളെയും മോഡലുകളെയും കുറിച്ച് സംസാരിക്കും, അതുപോലെ തന്നെ ഈ മോഡലുകൾ OpenShift പ്ലാറ്റ്ഫോമിൽ എങ്ങനെ നടപ്പിലാക്കുന്നു. ഈ വിഷയത്തിൽ ഒരു സംവേദനാത്മക ഗൈഡ് ലഭ്യമാണ് ബന്ധം.

ചുരുക്കത്തിൽ, ഇൻഫ്രാസ്ട്രക്ചറും ആപ്ലിക്കേഷൻ കോൺഫിഗറേഷനുകളും കൈകാര്യം ചെയ്യുന്നതിനായി Git പുൾ അഭ്യർത്ഥനകൾ ഉപയോഗിക്കുന്നതിനുള്ള ഒരു കൂട്ടം പരിശീലനമാണ് GitOps. GitOps-ലെ Git റിപ്പോസിറ്ററി, സിസ്റ്റത്തിന്റെ അവസ്ഥയെക്കുറിച്ചുള്ള വിവരങ്ങളുടെ ഒരൊറ്റ സ്രോതസ്സായി കണക്കാക്കുന്നു, കൂടാതെ ഈ അവസ്ഥയിലെ ഏത് മാറ്റവും പൂർണ്ണമായി കണ്ടെത്താവുന്നതും ഓഡിറ്റ് ചെയ്യാവുന്നതുമാണ്.

GitOps-ൽ ട്രാക്കിംഗ് മാറ്റുക എന്ന ആശയം ഒരു തരത്തിലും പുതിയതല്ല; ആപ്ലിക്കേഷൻ സോഴ്‌സ് കോഡുമായി പ്രവർത്തിക്കുമ്പോൾ ഈ സമീപനം വളരെക്കാലമായി സാർവത്രികമായി ഉപയോഗിച്ചുവരുന്നു. ഇൻഫ്രാസ്ട്രക്ചറിലും ആപ്ലിക്കേഷൻ കോൺഫിഗറേഷൻ മാനേജുമെന്റിലും GitOps സമാനമായ സവിശേഷതകൾ (അവലോകനങ്ങൾ, പുൾ അഭ്യർത്ഥനകൾ, ടാഗുകൾ മുതലായവ) നടപ്പിലാക്കുകയും സോഴ്‌സ് കോഡ് മാനേജ്‌മെന്റിന്റെ കാര്യത്തിലെന്നപോലെ സമാനമായ ആനുകൂല്യങ്ങൾ നൽകുകയും ചെയ്യുന്നു.

GitOps-ന് അക്കാദമിക് നിർവചനമോ അംഗീകൃത നിയമങ്ങളോ ഇല്ല, ഈ സമ്പ്രദായം നിർമ്മിച്ചിരിക്കുന്ന തത്വങ്ങളുടെ ഒരു കൂട്ടം മാത്രം:

• സിസ്റ്റത്തിന്റെ ഡിക്ലറേറ്റീവ് വിവരണം Git റിപ്പോസിറ്ററിയിൽ (configs, നിരീക്ഷണം മുതലായവ) സംഭരിച്ചിരിക്കുന്നു.
• പുൾ അഭ്യർത്ഥനകളിലൂടെയാണ് സംസ്ഥാന മാറ്റങ്ങൾ വരുത്തുന്നത്.
• ജിറ്റ് പുഷ് അഭ്യർത്ഥനകൾ ഉപയോഗിച്ച് പ്രവർത്തിക്കുന്ന സിസ്റ്റങ്ങളുടെ അവസ്ഥ റിപ്പോസിറ്ററിയിലെ ഡാറ്റയ്ക്ക് അനുസൃതമായി കൊണ്ടുവരുന്നു.

GitOps തത്ത്വങ്ങൾ

• സിസ്റ്റം നിർവചനങ്ങൾ സോഴ്സ് കോഡായി വിവരിച്ചിരിക്കുന്നു

സിസ്റ്റം കോൺഫിഗറേഷൻ ഒരു കോഡായി കണക്കാക്കുന്നു, അതിനാൽ ഇത് ഒരു Git റിപ്പോസിറ്ററിയിൽ സംഭരിക്കാനും യാന്ത്രികമായി പതിപ്പിക്കാനും കഴിയും, അത് സത്യത്തിന്റെ ഒരൊറ്റ ഉറവിടമായി വർത്തിക്കുന്നു. ഈ സമീപനം സിസ്റ്റങ്ങളിൽ മാറ്റങ്ങൾ വരുത്തുന്നതും റോൾബാക്ക് ചെയ്യുന്നതും എളുപ്പമാക്കുന്നു.

• സിസ്റ്റങ്ങളുടെ ആവശ്യമുള്ള അവസ്ഥയും കോൺഫിഗറേഷനും Git-ൽ സജ്ജമാക്കുകയും പതിപ്പിക്കുകയും ചെയ്യുന്നു

Git-ൽ സിസ്റ്റങ്ങളുടെ ആവശ്യമുള്ള അവസ്ഥ സംഭരിക്കുകയും പതിപ്പിക്കുകയും ചെയ്യുന്നതിലൂടെ, സിസ്റ്റങ്ങളിലേക്കും ആപ്ലിക്കേഷനുകളിലേക്കും എളുപ്പത്തിൽ റോൾ ഔട്ട് ചെയ്യാനും മാറ്റങ്ങൾ തിരികെ കൊണ്ടുവരാനും ഞങ്ങൾക്ക് കഴിയും. കോഡിന്റെ ഉടമസ്ഥാവകാശം നിയന്ത്രിക്കാനും അതിന്റെ ആധികാരികത പരിശോധിക്കാനും Git-ന്റെ സുരക്ഷാ സംവിധാനങ്ങളും നമുക്ക് ഉപയോഗിക്കാം.

• പുൾ അഭ്യർത്ഥനകൾ വഴി കോൺഫിഗറേഷൻ മാറ്റങ്ങൾ സ്വയമേവ പ്രയോഗിക്കാൻ കഴിയും

ജിറ്റ് പുൾ അഭ്യർത്ഥനകൾ ഉപയോഗിച്ച്, റിപ്പോസിറ്ററിയിലെ കോൺഫിഗറേഷനുകളിൽ മാറ്റങ്ങൾ എങ്ങനെ പ്രയോഗിക്കണമെന്ന് നമുക്ക് എളുപ്പത്തിൽ നിയന്ത്രിക്കാനാകും. ഉദാഹരണത്തിന്, അവ മറ്റ് ടീം അംഗങ്ങൾക്ക് അവലോകനത്തിനായി നൽകാം അല്ലെങ്കിൽ CI ടെസ്റ്റുകളിലൂടെ നടത്താം.

അതേ സമയം, അഡ്മിൻ അധികാരങ്ങൾ ഇടത്തോട്ടും വലത്തോട്ടും വിതരണം ചെയ്യേണ്ട ആവശ്യമില്ല. കോൺഫിഗറേഷൻ മാറ്റങ്ങൾ വരുത്തുന്നതിന്, ഉപയോക്താക്കൾക്ക് ആ കോൺഫിഗറേഷനുകൾ സംഭരിച്ചിരിക്കുന്ന Git റിപ്പോസിറ്ററിയിൽ ഉചിതമായ അനുമതികൾ മാത്രമേ ആവശ്യമുള്ളൂ.

• കോൺഫിഗറേഷനുകളുടെ അനിയന്ത്രിതമായ ഡ്രിഫ്റ്റിന്റെ പ്രശ്നം പരിഹരിക്കുന്നു

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

OpenShift-നുള്ള GitOps മോഡലുകൾ

ഓൺ-ക്ലസ്റ്റർ റിസോഴ്സ് റീകൺസൈലർ

ഈ മോഡൽ അനുസരിച്ച്, ക്ലസ്റ്ററിന് ഒരു കൺട്രോളർ ഉണ്ട്, അത് Git റിപ്പോസിറ്ററിയിലെ Kubernetes റിസോഴ്‌സുകളെ (YAML ഫയലുകൾ) ക്ലസ്റ്ററിന്റെ യഥാർത്ഥ ഉറവിടങ്ങളുമായി താരതമ്യം ചെയ്യുന്നു. പൊരുത്തക്കേടുകൾ കണ്ടെത്തിയാൽ, കൺട്രോളർ അറിയിപ്പുകൾ അയയ്ക്കുകയും പൊരുത്തക്കേടുകൾ ശരിയാക്കാൻ നടപടിയെടുക്കുകയും ചെയ്യും. ഈ GitOps മോഡൽ Anthos കോൺഫിഗ് മാനേജ്മെന്റിലും വീവ് വർക്ക്സ് ഫ്ലക്സിലും ഉപയോഗിക്കുന്നു.

എക്സ്റ്റേണൽ റിസോഴ്സ് റീകൺസൈലർ (പുഷ്)

"Git repository - Kubernetes cluster" ജോഡികളിൽ ഉറവിടങ്ങൾ സമന്വയിപ്പിക്കുന്നതിന് ഒന്നോ അതിലധികമോ കൺട്രോളറുകൾ ഉത്തരവാദികളായിരിക്കുമ്പോൾ, ഈ മാതൃക മുമ്പത്തേതിന്റെ ഒരു വ്യതിയാനമായി കണക്കാക്കാം. നിയന്ത്രിക്കപ്പെടുന്ന ഓരോ ക്ലസ്റ്ററിനും അതിന്റേതായ പ്രത്യേക കൺട്രോളർ ഉണ്ടായിരിക്കണമെന്നില്ല എന്നതാണ് ഇവിടെയുള്ള വ്യത്യാസം. Git - k8s ക്ലസ്റ്റർ ജോഡികൾ പലപ്പോഴും CRDകൾ (ഇഷ്‌ടാനുസൃത റിസോഴ്‌സ് നിർവചനങ്ങൾ) ആയി നിർവചിക്കപ്പെടുന്നു, ഇത് കൺട്രോളർ എങ്ങനെ സമന്വയിപ്പിക്കണം എന്ന് വിവരിക്കാനാകും. ഈ മോഡലിനുള്ളിൽ, കൺട്രോളറുകൾ CRD-യിൽ വ്യക്തമാക്കിയിട്ടുള്ള Git ശേഖരണത്തെ CRD-യിലും വ്യക്തമാക്കിയിട്ടുള്ള കുബർനെറ്റസ് ക്ലസ്റ്റർ റിസോഴ്സുകളുമായി താരതമ്യം ചെയ്യുകയും താരതമ്യത്തിന്റെ ഫലങ്ങളെ അടിസ്ഥാനമാക്കി ഉചിതമായ പ്രവർത്തനങ്ങൾ നടത്തുകയും ചെയ്യുന്നു. പ്രത്യേകിച്ചും, ഈ GitOps മോഡൽ ArgoCD-യിൽ ഉപയോഗിക്കുന്നു.

OpenShift പ്ലാറ്റ്‌ഫോമിലെ GitOps

മൾട്ടി-ക്ലസ്റ്റർ കുബർനെറ്റസ് ഇൻഫ്രാസ്ട്രക്ചറിന്റെ അഡ്മിനിസ്ട്രേഷൻ

കുബർനെറ്റസിന്റെ വ്യാപനവും മൾട്ടി-ക്ലൗഡ് സ്ട്രാറ്റജികളുടെയും എഡ്ജ് കമ്പ്യൂട്ടിംഗിന്റെയും വർദ്ധിച്ചുവരുന്ന ജനപ്രീതിയോടെ, ഓരോ ഉപഭോക്താവിനും ശരാശരി ഓപ്പൺഷിഫ്റ്റ് ക്ലസ്റ്ററുകളുടെ എണ്ണവും വർദ്ധിച്ചുകൊണ്ടിരിക്കുകയാണ്.

ഉദാഹരണത്തിന്, എഡ്ജ് കമ്പ്യൂട്ടിംഗ് ഉപയോഗിക്കുമ്പോൾ, ഒരു ഉപഭോക്താവിന്റെ ക്ലസ്റ്ററുകൾ നൂറുകണക്കിന് അല്ലെങ്കിൽ ആയിരക്കണക്കിന് വിന്യസിക്കാൻ കഴിയും. തൽഫലമായി, പബ്ലിക് ക്ലൗഡിലും ഓൺ-പ്രെമൈസിലും നിരവധി സ്വതന്ത്ര അല്ലെങ്കിൽ ഏകോപിത ഓപ്പൺഷിഫ്റ്റ് ക്ലസ്റ്ററുകൾ കൈകാര്യം ചെയ്യാൻ അദ്ദേഹം നിർബന്ധിതനാകുന്നു.

ഈ സാഹചര്യത്തിൽ, നിരവധി പ്രശ്നങ്ങൾ പരിഹരിക്കേണ്ടതുണ്ട്, പ്രത്യേകിച്ചും:

• ക്ലസ്റ്ററുകൾ ഒരേ നിലയിലാണെന്ന് നിയന്ത്രിക്കുക (കോൺഫിഗേഷനുകൾ, നിരീക്ഷണം, സംഭരണം മുതലായവ)
• അറിയപ്പെടുന്ന അവസ്ഥയെ അടിസ്ഥാനമാക്കി ക്ലസ്റ്ററുകൾ പുനഃസൃഷ്ടിക്കുക (അല്ലെങ്കിൽ പുനഃസ്ഥാപിക്കുക).
• അറിയപ്പെടുന്ന അവസ്ഥയെ അടിസ്ഥാനമാക്കി പുതിയ ക്ലസ്റ്ററുകൾ സൃഷ്ടിക്കുക.
• ഒന്നിലധികം ഓപ്പൺഷിഫ്റ്റ് ക്ലസ്റ്ററുകളിലേക്ക് മാറ്റങ്ങൾ റോൾ ചെയ്യുക.
• ഒന്നിലധികം OpenShift ക്ലസ്റ്ററുകളിലുടനീളം മാറ്റങ്ങൾ തിരികെ കൊണ്ടുവരിക.
• ടെംപ്ലേറ്റ് ചെയ്ത കോൺഫിഗറേഷനുകൾ വ്യത്യസ്ത പരിതസ്ഥിതികളിലേക്ക് ലിങ്ക് ചെയ്യുക.

ആപ്ലിക്കേഷൻ കോൺഫിഗറേഷനുകൾ

അവരുടെ ജീവിതചക്രത്തിൽ, ഒരു പ്രൊഡക്ഷൻ ക്ലസ്റ്ററിൽ അവസാനിക്കുന്നതിന് മുമ്പ് ആപ്ലിക്കേഷനുകൾ പലപ്പോഴും ക്ലസ്റ്ററുകളുടെ ഒരു ശൃംഖലയിലൂടെ (ദേവ്, സ്റ്റേജ് മുതലായവ) കടന്നുപോകുന്നു. കൂടാതെ, ലഭ്യതയും സ്കേലബിളിറ്റി ആവശ്യകതകളും കാരണം, ഉപഭോക്താക്കൾ പലപ്പോഴും ഒരു പൊതു ക്ലൗഡ് പ്ലാറ്റ്‌ഫോമിന്റെ ഒന്നിലധികം ഓൺ-പ്രെമൈസ് ക്ലസ്റ്ററുകളിലോ ഒന്നിലധികം പ്രദേശങ്ങളിലോ ആപ്ലിക്കേഷനുകൾ വിന്യസിക്കുന്നു.

ഈ സാഹചര്യത്തിൽ, ഇനിപ്പറയുന്ന ജോലികൾ പരിഹരിക്കേണ്ടതുണ്ട്:

• ക്ലസ്റ്ററുകൾക്കിടയിൽ (ദേവ്, സ്റ്റേജ്, മുതലായവ) ആപ്ലിക്കേഷനുകളുടെ (ബൈനറികൾ, കോൺഫിഗറുകൾ മുതലായവ) ചലനം ഉറപ്പാക്കുക.
• നിരവധി ഓപ്പൺഷിഫ്റ്റ് ക്ലസ്റ്ററുകളിൽ ആപ്ലിക്കേഷനുകളിൽ (ബൈനറികൾ, കോൺഫിഗറുകൾ മുതലായവ) മാറ്റങ്ങൾ റോൾ ചെയ്യുക.
• അപ്ലിക്കേഷനുകളിലേക്കുള്ള മാറ്റങ്ങൾ മുമ്പത്തെ അറിയപ്പെടുന്ന അവസ്ഥയിലേക്ക് തിരികെ കൊണ്ടുവരിക.

OpenShift GitOps ഉപയോഗ കേസുകൾ

1. Git റിപ്പോസിറ്ററിയിൽ നിന്ന് മാറ്റങ്ങൾ പ്രയോഗിക്കുന്നു

ഒരു ക്ലസ്റ്റർ അഡ്മിനിസ്ട്രേറ്റർക്ക് ഓപ്പൺഷിഫ്റ്റ് ക്ലസ്റ്റർ കോൺഫിഗറേഷനുകൾ ഒരു Git റിപ്പോസിറ്ററിയിൽ സംഭരിക്കാനും അവ സ്വയമേവ പ്രയോഗിക്കാനും പുതിയ ക്ലസ്റ്ററുകൾ സൃഷ്ടിക്കാനും Git റിപ്പോസിറ്ററിയിൽ സംഭരിച്ചിരിക്കുന്ന അറിയപ്പെടുന്ന അവസ്ഥയ്ക്ക് സമാനമായ അവസ്ഥയിലേക്ക് കൊണ്ടുവരാനും കഴിയും.

2. സീക്രട്ട് മാനേജറുമായുള്ള സമന്വയം

ഇതിനായി പ്രത്യേകം സൃഷ്‌ടിച്ച ടൂളുകൾ ഉപയോഗിച്ച് ഓപ്പൺഷിഫ്റ്റ് രഹസ്യ ഒബ്‌ജക്റ്റുകൾ കൈകാര്യം ചെയ്യുന്നതിനായി, വോൾട്ട് പോലുള്ള ഉചിതമായ സോഫ്‌റ്റ്‌വെയർ ഉപയോഗിച്ച് സമന്വയിപ്പിക്കാനുള്ള കഴിവിൽ നിന്നും അഡ്മിനിസ്ട്രേറ്റർക്ക് പ്രയോജനം ലഭിക്കും.

3. ഡ്രിഫ്റ്റ് കോൺഫിഗറേഷനുകളുടെ നിയന്ത്രണം

യഥാർത്ഥ കോൺഫിഗറേഷനുകളും റിപ്പോസിറ്ററിയിൽ വ്യക്തമാക്കിയവയും തമ്മിലുള്ള പൊരുത്തക്കേടുകൾ OpenShift GitOps തന്നെ തിരിച്ചറിയുകയും മുന്നറിയിപ്പ് നൽകുകയും ചെയ്താൽ മാത്രമേ അഡ്മിൻ അനുകൂലനാകൂ, അതുവഴി അവർക്ക് ഡ്രിഫ്റ്റിനോട് പെട്ടെന്ന് പ്രതികരിക്കാനാകും.

4. കോൺഫിഗറേഷൻ ഡ്രിഫ്റ്റിനെക്കുറിച്ചുള്ള അറിയിപ്പുകൾ

സ്വന്തമായി ഉചിതമായ നടപടികൾ കൈക്കൊള്ളുന്നതിനായി, കോൺഫിഗറേഷൻ ഡ്രിഫ്റ്റിന്റെ കേസുകളെക്കുറിച്ച് വേഗത്തിൽ അറിയാൻ അഡ്മിനിസ്ട്രേറ്റർ ആഗ്രഹിക്കുന്ന സാഹചര്യത്തിൽ അവ ഉപയോഗപ്രദമാണ്.

5. ഡ്രിഫ്റ്റിംഗ് ചെയ്യുമ്പോൾ കോൺഫിഗറേഷനുകളുടെ മാനുവൽ സിൻക്രൊണൈസേഷൻ

കോൺഫിഗറേഷൻ ഡ്രിഫ്റ്റ് സംഭവിക്കുമ്പോൾ, ക്ലസ്റ്ററിനെ മുമ്പത്തെ അറിയപ്പെടുന്ന അവസ്ഥയിലേക്ക് വേഗത്തിൽ തിരികെ കൊണ്ടുവരാൻ, ഓപ്പൺഷിഫ്റ്റ് ക്ലസ്റ്ററിനെ Git റിപ്പോസിറ്ററിയുമായി സമന്വയിപ്പിക്കാൻ അഡ്‌മിനെ അനുവദിക്കുന്നു.

6.ഡ്രിഫ്റ്റ് ചെയ്യുമ്പോൾ കോൺഫിഗറേഷനുകളുടെ ഓട്ടോ-സിൻക്രൊണൈസേഷൻ

ഒരു ഡ്രിഫ്റ്റ് കണ്ടെത്തുമ്പോൾ റിപ്പോസിറ്ററിയുമായി യാന്ത്രികമായി സമന്വയിപ്പിക്കുന്നതിനായി അഡ്മിനിസ്ട്രേറ്റർക്ക് OpenShift ക്ലസ്റ്റർ ക്രമീകരിക്കാനും കഴിയും, അങ്ങനെ ക്ലസ്റ്റർ കോൺഫിഗറേഷൻ എല്ലായ്പ്പോഴും Git ലെ കോൺഫിഗറേഷനുമായി പൊരുത്തപ്പെടുന്നു.

7. നിരവധി ക്ലസ്റ്ററുകൾ - ഒരു ശേഖരം

അഡ്‌മിനിസ്‌ട്രേറ്റർക്ക് വിവിധ ഓപ്പൺഷിഫ്റ്റ് ക്ലസ്റ്ററുകളുടെ കോൺഫിഗറേഷനുകൾ ഒരു Git റിപ്പോസിറ്ററിയിൽ സംഭരിക്കാനും ആവശ്യാനുസരണം അവ തിരഞ്ഞെടുത്ത് പ്രയോഗിക്കാനും കഴിയും.

8. ക്ലസ്റ്റർ കോൺഫിഗറേഷനുകളുടെ ശ്രേണി (പൈതൃകം)

അഡ്‌മിന് റിപ്പോസിറ്ററിയിൽ ക്ലസ്റ്റർ കോൺഫിഗറേഷനുകളുടെ ഒരു ശ്രേണി സജ്ജീകരിക്കാൻ കഴിയും (ഘട്ടം, പ്രോഡ്, ആപ്പ് പോർട്ട്‌ഫോളിയോ മുതലായവ. അനന്തരാവകാശത്തോടെ). മറ്റൊരു വിധത്തിൽ പറഞ്ഞാൽ, ഒന്നോ അതിലധികമോ ക്ലസ്റ്ററുകളിൽ കോൺഫിഗറേഷനുകൾ പ്രയോഗിക്കണമോ എന്ന് ഇതിന് നിർണ്ണയിക്കാനാകും.

ഉദാഹരണത്തിന്, ഒരു അഡ്മിനിസ്ട്രേറ്റർ Git റിപ്പോസിറ്ററിയിൽ “പ്രൊഡക്ഷൻ ക്ലസ്റ്ററുകൾ (പ്രൊഡ്) → സിസ്റ്റം X ക്ലസ്റ്ററുകൾ → പ്രൊഡക്ഷൻ ക്ലസ്റ്ററുകൾ സിസ്റ്റം എക്‌സ്” എന്ന ശ്രേണി സജ്ജീകരിക്കുകയാണെങ്കിൽ, ഇനിപ്പറയുന്ന കോൺഫിഗറുകളുടെ സംയോജനം സിസ്റ്റം X-ന്റെ പ്രൊഡക്ഷൻ ക്ലസ്റ്ററുകളിൽ പ്രയോഗിക്കുന്നു:

• എല്ലാ പ്രൊഡക്ഷൻ ക്ലസ്റ്ററുകൾക്കും പൊതുവായ കോൺഫിഗറേഷനുകൾ.
• സിസ്റ്റം എക്സ് ക്ലസ്റ്ററിനായുള്ള കോൺഫിഗറേഷനുകൾ.
• എക്സ് സിസ്റ്റം പ്രൊഡക്ഷൻ ക്ലസ്റ്ററിനായുള്ള കോൺഫിഗറേഷനുകൾ.

9. ടെംപ്ലേറ്റുകളും കോൺഫിഗറേഷനും അസാധുവാക്കുന്നു

അഡ്‌മിനിസ്‌ട്രേറ്റർക്ക് പാരമ്പര്യമായി ലഭിച്ച ഒരു കൂട്ടം കോൺഫിഗറേഷനുകളും അവയുടെ മൂല്യങ്ങളും അസാധുവാക്കാൻ കഴിയും, ഉദാഹരണത്തിന്, അവ പ്രയോഗിക്കുന്ന നിർദ്ദിഷ്ട ക്ലസ്റ്ററുകൾക്കായുള്ള കോൺഫിഗറേഷൻ മികച്ചതാക്കാൻ.

10. കോൺഫിഗറേഷനുകൾ, ആപ്ലിക്കേഷൻ കോൺഫിഗറേഷനുകൾ എന്നിവയ്ക്കായി തിരഞ്ഞെടുത്തവ ഉൾപ്പെടുത്തുകയും ഒഴിവാക്കുകയും ചെയ്യുക

ചില പ്രത്യേകതകളുള്ള ക്ലസ്റ്ററുകളിലേക്ക് ചില കോൺഫിഗറേഷനുകൾ പ്രയോഗിക്കുന്നതിനോ അല്ലാത്തതിനോ ഉള്ള വ്യവസ്ഥകൾ അഡ്മിനിസ്ട്രേറ്റർക്ക് സജ്ജമാക്കാൻ കഴിയും.

11. ടെംപ്ലേറ്റ് പിന്തുണ

ഓരോ നിർദ്ദിഷ്ട ആപ്ലിക്കേഷനും ഏറ്റവും അനുയോജ്യമായ ഫോർമാറ്റ് ഉപയോഗിക്കുന്നതിന്, ആപ്ലിക്കേഷൻ ഉറവിടങ്ങൾ എങ്ങനെ നിർവചിക്കണമെന്ന് (ഹെൽം ചാർട്ട്, പ്യുവർ കുബർനെറ്റസ് യാംൽ മുതലായവ) തിരഞ്ഞെടുക്കാനുള്ള കഴിവിൽ നിന്ന് ഡെവലപ്പർമാർക്ക് പ്രയോജനം ലഭിക്കും.

OpenShift പ്ലാറ്റ്‌ഫോമിലെ GitOps ടൂളുകൾ

ആർഗോസിഡി

ArgoCD എക്‌സ്‌റ്റേണൽ റിസോഴ്‌സ് റീകൺസൈൽ മോഡൽ നടപ്പിലാക്കുകയും ക്ലസ്റ്ററുകളും Git റിപ്പോസിറ്ററികളും തമ്മിൽ ഒന്നിൽ നിന്ന് നിരവധി ബന്ധങ്ങൾ ക്രമീകരിക്കുന്നതിന് ഒരു കേന്ദ്രീകൃത യുഐ വാഗ്ദാനം ചെയ്യുകയും ചെയ്യുന്നു. ഈ പ്രോഗ്രാമിന്റെ പോരായ്മകളിൽ ArgoCD പ്രവർത്തിക്കാത്തപ്പോൾ ആപ്ലിക്കേഷനുകൾ കൈകാര്യം ചെയ്യാനുള്ള കഴിവില്ലായ്മ ഉൾപ്പെടുന്നു.

ഔദ്യോഗിക വെബ്സൈറ്റ്

ഒഴുകുക

ഫ്ലക്സ് ഒരു ഓൺ-ക്ലസ്റ്റർ റിസോഴ്സ് റീകൺസൈൽ മോഡൽ നടപ്പിലാക്കുന്നു, തൽഫലമായി, ഡെഫനിഷൻ റിപ്പോസിറ്ററിയുടെ കേന്ദ്രീകൃത മാനേജ്മെന്റ് ഇല്ല, അത് ഒരു ദുർബലമായ പോയിന്റാണ്. മറുവശത്ത്, കൃത്യമായി കേന്ദ്രീകരണത്തിന്റെ അഭാവം കാരണം, ഒരു ക്ലസ്റ്റർ പരാജയപ്പെട്ടാലും ആപ്ലിക്കേഷനുകൾ കൈകാര്യം ചെയ്യാനുള്ള കഴിവ് നിലനിൽക്കും.

ഔദ്യോഗിക വെബ്സൈറ്റ്

OpenShift-ൽ ArgoCD ഇൻസ്റ്റാൾ ചെയ്യുന്നു

ArgoCD ഒരു മികച്ച കമാൻഡ് ലൈൻ ഇന്റർഫേസും വെബ് കൺസോളും വാഗ്ദാനം ചെയ്യുന്നു, അതിനാൽ ഞങ്ങൾ ഫ്ലക്സും മറ്റ് ഇതര മാർഗങ്ങളും ഇവിടെ ഉൾപ്പെടുത്തില്ല.

OpenShift 4 പ്ലാറ്റ്‌ഫോമിൽ ArgoCD വിന്യസിക്കാൻ, ഒരു ക്ലസ്റ്റർ അഡ്മിനിസ്ട്രേറ്ററായി ഈ ഘട്ടങ്ങൾ പാലിക്കുക:

OpenShift പ്ലാറ്റ്‌ഫോമിൽ ArgoCD ഘടകങ്ങൾ വിന്യസിക്കുന്നു

# Create a new namespace for ArgoCD components
oc create namespace argocd
# Apply the ArgoCD Install Manifest
oc -n argocd apply -f https://raw.githubusercontent.com/argoproj/argo-cd/v1.2.2/manifests/install.yaml
# Get the ArgoCD Server password
ARGOCD_SERVER_PASSWORD=$(oc -n argocd get pod -l "app.kubernetes.io/name=argocd-server" -o jsonpath='{.items[*].metadata.name}')

ArgoCD സെർവറിന്റെ മെച്ചപ്പെടുത്തൽ, അതുവഴി ഓപ്പൺഷിഫ്റ്റ് റൂട്ടിന് കാണാൻ കഴിയും

# Patch ArgoCD Server so no TLS is configured on the server (--insecure)
PATCH='{"spec":{"template":{"spec":{"$setElementOrder/containers":[{"name":"argocd-server"}],"containers":[{"command":["argocd-server","--insecure","--staticassets","/shared/app"],"name":"argocd-server"}]}}}}'
oc -n argocd patch deployment argocd-server -p $PATCH
# Expose the ArgoCD Server using an Edge OpenShift Route so TLS is used for incoming connections
oc -n argocd create route edge argocd-server --service=argocd-server --port=http --insecure-policy=Redirect

ArgoCD Cli ടൂൾ വിന്യസിക്കുന്നു

# Download the argocd binary, place it under /usr/local/bin and give it execution permissions
curl -L https://github.com/argoproj/argo-cd/releases/download/v1.2.2/argocd-linux-amd64 -o /usr/local/bin/argocd
chmod +x /usr/local/bin/argocd

ArgoCD സെർവർ അഡ്മിൻ പാസ്‌വേഡ് മാറ്റുന്നു

# Get ArgoCD Server Route Hostname
ARGOCD_ROUTE=$(oc -n argocd get route argocd-server -o jsonpath='{.spec.host}')
# Login with the current admin password
argocd --insecure --grpc-web login ${ARGOCD_ROUTE}:443 --username admin --password ${ARGOCD_SERVER_PASSWORD}
# Update admin's password
argocd --insecure --grpc-web --server ${ARGOCD_ROUTE}:443 account update-password --current-password ${ARGOCD_SERVER_PASSWORD} --new-password

ഈ ഘട്ടങ്ങൾ പൂർത്തിയാക്കിയ ശേഷം, നിങ്ങൾക്ക് ArgoCD WebUI വെബ് കൺസോൾ അല്ലെങ്കിൽ ArgoCD Cli കമാൻഡ് ലൈൻ ടൂൾ വഴി ArgoCD സെർവറുമായി പ്രവർത്തിക്കാനാകും.
https://blog.openshift.com/is-it-too-late-to-integrate-gitops/

GitOps - ഇത് ഒരിക്കലും വൈകില്ല

“ട്രെയിൻ പോയി” - എന്തെങ്കിലും ചെയ്യാനുള്ള അവസരം നഷ്‌ടപ്പെടുമ്പോൾ ഒരു സാഹചര്യത്തെക്കുറിച്ച് അവർ പറയുന്നത് ഇതാണ്. ഓപ്പൺഷിഫ്റ്റിന്റെ കാര്യത്തിൽ, ഈ രസകരമായ പുതിയ പ്ലാറ്റ്‌ഫോം ഉപയോഗിച്ച് ഉടൻ ആരംഭിക്കാനുള്ള ആഗ്രഹം റൂട്ടുകൾ, വിന്യാസങ്ങൾ, മറ്റ് ഓപ്പൺഷിഫ്റ്റ് ഒബ്‌ജക്റ്റുകൾ എന്നിവയുടെ മാനേജ്‌മെന്റും അറ്റകുറ്റപ്പണിയും ഉപയോഗിച്ച് പലപ്പോഴും ഈ സാഹചര്യം സൃഷ്ടിക്കുന്നു. എന്നാൽ അവസരം എല്ലായ്പ്പോഴും പൂർണ്ണമായും നഷ്‌ടപ്പെടുമോ?

എന്നതിനെക്കുറിച്ചുള്ള ലേഖനങ്ങളുടെ പരമ്പര തുടരുന്നു GitOps, ഒരു കരകൗശല ആപ്ലിക്കേഷനും അതിന്റെ ഉറവിടങ്ങളും എല്ലാം GitOps ടൂളുകൾ കൈകാര്യം ചെയ്യുന്ന ഒരു പ്രക്രിയയിലേക്ക് എങ്ങനെ മാറ്റാമെന്ന് ഇന്ന് ഞങ്ങൾ നിങ്ങളെ കാണിച്ചുതരാം. ഇത് ചെയ്യുന്നതിന്, ഞങ്ങൾ ആദ്യം httpd ആപ്ലിക്കേഷൻ സ്വമേധയാ വിന്യസിക്കും. താഴെയുള്ള സ്ക്രീൻഷോട്ട് ഞങ്ങൾ ഒരു നെയിംസ്പേസ്, വിന്യാസം, സേവനം എന്നിവ സൃഷ്ടിക്കുന്നത് എങ്ങനെയെന്ന് കാണിക്കുന്നു, തുടർന്ന് ഒരു റൂട്ട് സൃഷ്ടിക്കുന്നതിന് ഈ സേവനം തുറന്നുകാട്ടുന്നു.

oc create -f https://raw.githubusercontent.com/openshift/federation-dev/master/labs/lab-4-assets/namespace.yaml
oc create -f https://raw.githubusercontent.com/openshift/federation-dev/master/labs/lab-4-assets/deployment.yaml
oc create -f https://raw.githubusercontent.com/openshift/federation-dev/master/labs/lab-4-assets/service.yaml
oc expose svc/httpd -n simple-app

അതിനാൽ ഞങ്ങൾക്ക് ഒരു കരകൗശല ആപ്ലിക്കേഷൻ ഉണ്ട്. ഇപ്പോൾ അത് ലഭ്യത നഷ്ടപ്പെടാതെ GitOps മാനേജുമെന്റിന് കീഴിൽ കൈമാറേണ്ടതുണ്ട്. ചുരുക്കത്തിൽ, ഇത് ചെയ്യുന്നു:

• കോഡിനായി ഒരു Git റിപ്പോസിറ്ററി സൃഷ്ടിക്കുക.
• ഞങ്ങളുടെ നിലവിലുള്ള ഒബ്‌ജക്‌റ്റുകൾ ഞങ്ങൾ എക്‌സ്‌പോർട്ട് ചെയ്യുകയും അവയെ Git ശേഖരത്തിലേക്ക് അപ്‌ലോഡ് ചെയ്യുകയും ചെയ്യുന്നു.
• GitOps ടൂളുകൾ തിരഞ്ഞെടുത്ത് വിന്യസിക്കുന്നു.
• ഈ ടൂൾകിറ്റിലേക്ക് ഞങ്ങൾ ഞങ്ങളുടെ ശേഖരം ചേർക്കുന്നു.
• ഞങ്ങളുടെ GitOps ടൂൾകിറ്റിൽ ഞങ്ങൾ ആപ്ലിക്കേഷൻ നിർവ്വചിക്കുന്നു.
• GitOps ടൂൾകിറ്റ് ഉപയോഗിച്ച് ഞങ്ങൾ ആപ്ലിക്കേഷന്റെ ഒരു പരീക്ഷണ ഓട്ടം നടത്തുന്നു.
• GitOps ടൂൾകിറ്റ് ഉപയോഗിച്ച് ഞങ്ങൾ ഒബ്ജക്റ്റുകൾ സമന്വയിപ്പിക്കുന്നു.
• ഒബ്‌ജക്‌റ്റുകളുടെ പ്രൂണിംഗും യാന്ത്രിക സമന്വയവും പ്രവർത്തനക്ഷമമാക്കുക.

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

ഞങ്ങളുടെ ഉദാഹരണത്തിൽ, GitHub-ൽ ഞങ്ങൾ ഒരു പുതിയ പൊതു ശേഖരം സൃഷ്ടിക്കും. നിങ്ങൾക്ക് ഇഷ്ടമുള്ളതെന്തും വിളിക്കാം, ഞങ്ങൾ ബ്ലോഗ്‌പോസ്റ്റ് എന്ന പേര് ഉപയോഗിക്കുന്നു.

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

oc get namespace simple-app -o yaml --export > namespace.yaml
oc get deployment httpd -o yaml -n simple-app --export > deployment.yaml
oc get service httpd -o yaml -n simple-app --export > service.yaml
oc get route httpd -o yaml -n simple-app --export > route.yaml

Argo CD സമന്വയിപ്പിക്കാൻ കഴിയാത്ത ഫീൽഡ് നീക്കം ചെയ്യുന്നതിനായി deployment.yaml ഫയൽ എഡിറ്റ് ചെയ്യാം.

sed -i '/sgeneration: .*/d' deployment.yaml

കൂടാതെ, റൂട്ട് മാറ്റേണ്ടതുണ്ട്. ഞങ്ങൾ ആദ്യം ഒരു മൾട്ടിലൈൻ വേരിയബിൾ സജ്ജീകരിക്കും, തുടർന്ന് ഇൻഗ്രെസ്സ് മാറ്റിസ്ഥാപിക്കും: ആ വേരിയബിളിലെ ഉള്ളടക്കങ്ങൾ ഉപയോഗിച്ച് null.

export ROUTE="  ingress:                                                            
    - conditions:
        - status: 'True'
          type: Admitted"

sed -i "s/  ingress: null/$ROUTE/g" route.yaml

അതിനാൽ, ഞങ്ങൾ ഫയലുകൾ ക്രമീകരിച്ചു, അവ ജിറ്റ് ശേഖരത്തിലേക്ക് സംരക്ഷിക്കുക മാത്രമാണ് അവശേഷിക്കുന്നത്. അതിനുശേഷം ഈ ശേഖരം വിവരങ്ങളുടെ ഏക സ്രോതസ്സായി മാറുന്നു, കൂടാതെ ഒബ്‌ജക്റ്റുകളിൽ സ്വമേധയാലുള്ള മാറ്റങ്ങൾ കർശനമായി നിരോധിക്കേണ്ടതാണ്.

git commit -am ‘initial commit of objects’
git push origin master

നിങ്ങൾ ഇതിനകം ArgoCD വിന്യസിച്ചു എന്ന വസ്തുതയിൽ നിന്ന് ഞങ്ങൾ മുന്നോട്ട് പോകുന്നു (ഇത് എങ്ങനെ ചെയ്യാം - മുമ്പത്തേത് കാണുക ഒരു പോസ്റ്റ്). അതിനാൽ, ഞങ്ങളുടെ ഉദാഹരണത്തിൽ നിന്നുള്ള ആപ്ലിക്കേഷൻ കോഡ് അടങ്ങിയ ഞങ്ങൾ സൃഷ്ടിച്ച ശേഖരം ഞങ്ങൾ ആർഗോ സിഡിയിൽ ചേർക്കും. നിങ്ങൾ നേരത്തെ സൃഷ്‌ടിച്ച കൃത്യമായ ശേഖരം നിങ്ങൾ വ്യക്തമാക്കിയിട്ടുണ്ടെന്ന് ഉറപ്പാക്കുക.

argocd repo add https://github.com/cooktheryan/blogpost

ഇനി നമുക്ക് ആപ്ലിക്കേഷൻ ഉണ്ടാക്കാം. ഏത് ശേഖരണവും പാതകളും ഉപയോഗിക്കണം, ഒബ്‌ജക്‌റ്റുകൾ നിയന്ത്രിക്കാൻ ഏത് ഓപ്പൺഷിഫ്റ്റ് ആവശ്യമാണ്, റിപ്പോസിറ്ററിയുടെ ഏത് പ്രത്യേക ബ്രാഞ്ച് ആവശ്യമുണ്ട്, ഉറവിടങ്ങൾ യാന്ത്രികമായി സമന്വയിപ്പിക്കണമോ എന്ന് GitOps ടൂൾകിറ്റ് മനസ്സിലാക്കുന്ന തരത്തിൽ ആപ്ലിക്കേഷൻ മൂല്യങ്ങൾ സജ്ജമാക്കുന്നു.

argocd app create --project default 
--name simple-app --repo https://github.com/cooktheryan/blogpost.git 
--path . --dest-server https://kubernetes.default.svc 
--dest-namespace simple-app --revision master --sync-policy none

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

ഇനി നമുക്ക് ഒരു ടെസ്റ്റ് റൺ നടത്തി നമ്മുടെ ഫയലുകളിൽ പിശകുകൾ ഇല്ലെന്ന് ഉറപ്പ് വരുത്താം.

argocd app sync simple-app --dry-run

പിശകുകളൊന്നുമില്ലെങ്കിൽ, നിങ്ങൾക്ക് സമന്വയത്തിലേക്ക് പോകാം.

argocd app sync simple-app

ഞങ്ങളുടെ ആപ്ലിക്കേഷനിൽ argocd get കമാൻഡ് പ്രവർത്തിപ്പിച്ചതിന് ശേഷം, ആപ്ലിക്കേഷൻ സ്റ്റാറ്റസ് ആരോഗ്യമുള്ളതോ സമന്വയിപ്പിച്ചതോ ആയി മാറിയതായി കാണണം. Git റിപ്പോസിറ്ററിയിലെ എല്ലാ ഉറവിടങ്ങളും ഇതിനകം വിന്യസിച്ചിട്ടുള്ള ഉറവിടങ്ങളുമായി പൊരുത്തപ്പെടുന്നു എന്നാണ് ഇതിനർത്ഥം.

argocd app get simple-app
Name:               simple-app
Project:            default
Server:             https://kubernetes.default.svc
Namespace:          simple-app
URL:                https://argocd-server-route-argocd.apps.example.com/applications/simple-app
Repo:               https://github.com/cooktheryan/blogpost.git
Target:             master
Path:               .
Sync Policy:        <none>
Sync Status:        Synced to master (60e1678)
Health Status:      Healthy
...   

സ്വമേധയാ ഒന്നും സൃഷ്‌ടിച്ചിട്ടില്ലെന്നും ഓരോ തവണയും ഒരു ഒബ്‌ജക്റ്റ് സൃഷ്‌ടിക്കുമ്പോഴോ ശേഖരത്തിലേക്ക് അപ്‌ഡേറ്റ് ചെയ്യുമ്പോഴോ ഒരു വിന്യാസം സംഭവിക്കുമെന്നും ഉറപ്പാക്കാൻ ഇപ്പോൾ നിങ്ങൾക്ക് യാന്ത്രിക സമന്വയവും ക്ലീനപ്പും പ്രവർത്തനക്ഷമമാക്കാനാകും.

argocd app set simple-app --sync-policy automated --auto-prune

അതിനാൽ, തുടക്കത്തിൽ GitOps ഒരു തരത്തിലും ഉപയോഗിക്കാത്ത ഒരു ആപ്ലിക്കേഷൻ ഞങ്ങൾ GitOps നിയന്ത്രണത്തിന് കീഴിൽ കൊണ്ടുവന്നു.

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