"ക്ലൗഡ് നേറ്റീവ്" അല്ലെങ്കിൽ ലളിതമായി "ക്ലൗഡ്" ആപ്ലിക്കേഷനുകൾ ക്ലൗഡ് ഇൻഫ്രാസ്ട്രക്ചറുകളിൽ പ്രവർത്തിക്കാൻ പ്രത്യേകം സൃഷ്ടിച്ചതാണ്. അവ സാധാരണയായി കണ്ടെയ്നറുകളിൽ പാക്കേജുചെയ്‌ത അയഞ്ഞ കപ്പിൾഡ് മൈക്രോസർവീസുകളുടെ ഒരു കൂട്ടമായാണ് നിർമ്മിച്ചിരിക്കുന്നത്, അവ നിയന്ത്രിക്കുന്നത് ഒരു ക്ലൗഡ് പ്ലാറ്റ്‌ഫോമാണ്. അത്തരം ആപ്ലിക്കേഷനുകൾ ഡിഫോൾട്ടായി പരാജയങ്ങൾക്കായി തയ്യാറാക്കപ്പെടുന്നു, അതായത് ഗുരുതരമായ ഇൻഫ്രാസ്ട്രക്ചർ ലെവൽ പരാജയങ്ങൾ ഉണ്ടാകുമ്പോൾ പോലും അവ വിശ്വസനീയമായി പ്രവർത്തിക്കുകയും സ്കെയിൽ ചെയ്യുകയും ചെയ്യുന്നു. കണ്ടെയ്നർ ആപ്ലിക്കേഷനുകൾ സ്വയമേവ കൈകാര്യം ചെയ്യുന്നതിനായി ക്ലൗഡ് പ്ലാറ്റ്ഫോം ഏർപ്പെടുത്തുന്ന നിയന്ത്രണങ്ങളുടെ (കരാർ) ആണ് നാണയത്തിൻ്റെ മറുവശം.
ക്ലൗഡ് അധിഷ്‌ഠിത ആപ്ലിക്കേഷനുകളിലേക്ക് മാറേണ്ടതിൻ്റെ ആവശ്യകതയെക്കുറിച്ചും പ്രാധാന്യത്തെക്കുറിച്ചും പൂർണ്ണമായി അറിയാമെങ്കിലും, എവിടെ തുടങ്ങണമെന്ന് പല സ്ഥാപനങ്ങൾക്കും ഇപ്പോഴും അറിയില്ല. ഈ പോസ്റ്റിൽ, കണ്ടെയ്‌നറൈസ് ചെയ്ത ആപ്ലിക്കേഷനുകൾ വികസിപ്പിക്കുമ്പോൾ, ക്ലൗഡ് പ്ലാറ്റ്‌ഫോമുകളുടെ സാധ്യതകൾ തിരിച്ചറിയാനും ഐടി ഇൻഫ്രാസ്ട്രക്ചറിലെ ഗുരുതരമായ പരാജയങ്ങളിൽപ്പോലും ആപ്ലിക്കേഷനുകളുടെ വിശ്വസനീയമായ പ്രവർത്തനവും സ്കെയിലിംഗും നേടാനും നിങ്ങളെ അനുവദിക്കുന്ന നിരവധി തത്ത്വങ്ങൾ ഞങ്ങൾ പരിശോധിക്കും. നില. Kubernetes പോലുള്ള ക്ലൗഡ് പ്ലാറ്റ്‌ഫോമുകൾക്ക് സ്വയമേവ മാനേജ് ചെയ്യാൻ കഴിയുന്ന ആപ്ലിക്കേഷനുകൾ എങ്ങനെ നിർമ്മിക്കാമെന്ന് മനസിലാക്കുക എന്നതാണ് ഇവിടെ വിവരിച്ചിരിക്കുന്ന തത്വങ്ങളുടെ ആത്യന്തിക ലക്ഷ്യം.
സോഫ്റ്റ്വെയർ ഡിസൈൻ തത്വങ്ങൾ
പ്രോഗ്രാമിംഗ് ലോകത്ത്, സോഫ്റ്റ്വെയർ വികസിപ്പിക്കുമ്പോൾ പാലിക്കേണ്ട പൊതുവായ നിയമങ്ങളെയാണ് തത്വങ്ങൾ സൂചിപ്പിക്കുന്നത്. ഏതെങ്കിലും പ്രോഗ്രാമിംഗ് ഭാഷയിൽ പ്രവർത്തിക്കുമ്പോൾ അവ ഉപയോഗിക്കാം. ഓരോ തത്ത്വത്തിനും അതിൻ്റേതായ ലക്ഷ്യങ്ങളുണ്ട്, അത് നേടുന്നതിനുള്ള ഉപകരണങ്ങൾ സാധാരണയായി ടെംപ്ലേറ്റുകളും പ്രയോഗങ്ങളുമാണ്. ഉയർന്ന നിലവാരമുള്ള സോഫ്റ്റ്വെയർ സൃഷ്‌ടിക്കുന്നതിന് നിരവധി അടിസ്ഥാന തത്വങ്ങളും ഉണ്ട്, അവയിൽ നിന്ന് മറ്റെല്ലാം ഒഴുകുന്നു. അടിസ്ഥാന തത്വങ്ങളുടെ ചില ഉദാഹരണങ്ങൾ ഇതാ:
- (ഇത് ലളിതമാക്കുക, മണ്ടത്തരം) - അത് സങ്കീർണ്ണമാക്കരുത്;
- (സ്വയം ആവർത്തിക്കരുത്) - സ്വയം ആവർത്തിക്കരുത്;
- (നിങ്ങൾക്ക് ഇത് ആവശ്യമില്ല) - ഉടനടി ആവശ്യമില്ലാത്ത എന്തെങ്കിലും സൃഷ്ടിക്കരുത്;
- ആശങ്കകളുടെ വേർതിരിവ് - ഉത്തരവാദിത്തങ്ങൾ പങ്കിടുക.
നിങ്ങൾക്ക് കാണാനാകുന്നതുപോലെ, ഈ തത്ത്വങ്ങൾ പ്രത്യേക നിയമങ്ങളൊന്നും സജ്ജീകരിക്കുന്നില്ല, എന്നാൽ പ്രായോഗിക അനുഭവത്തെ അടിസ്ഥാനമാക്കിയുള്ള സാമാന്യബുദ്ധി പരിഗണനകൾ എന്ന് വിളിക്കപ്പെടുന്ന വിഭാഗത്തിൽ പെടുന്നു, അവ പല ഡവലപ്പർമാരും പങ്കിടുന്നു, അവ പതിവായി പരാമർശിക്കുന്നു.
കൂടാതെ, ഉണ്ട് - റോബർട്ട് മാർട്ടിൻ രൂപപ്പെടുത്തിയ ഒബ്ജക്റ്റ് ഓറിയൻ്റഡ് പ്രോഗ്രാമിംഗിൻ്റെയും ഡിസൈനിൻ്റെയും ആദ്യ അഞ്ച് തത്വങ്ങളുടെ ഒരു കൂട്ടം. SOLID-ൽ വിശാലവും തുറന്നതും പരസ്പര പൂരകവുമായ തത്ത്വങ്ങൾ ഉൾപ്പെടുന്നു—ഒരുമിച്ചു പ്രയോഗിക്കുമ്പോൾ—മികച്ച സോഫ്റ്റ്വെയർ സംവിധാനങ്ങൾ സൃഷ്‌ടിക്കാനും ദീർഘകാലത്തേക്ക് അവയെ മികച്ച രീതിയിൽ പരിപാലിക്കാനും സഹായിക്കുന്നു.
SOLID തത്ത്വങ്ങൾ OOP ഫീൽഡിൽ പെടുന്നു, ക്ലാസുകൾ, ഇൻ്റർഫേസുകൾ, അനന്തരാവകാശം തുടങ്ങിയ ആശയങ്ങളുടെയും ആശയങ്ങളുടെയും ഭാഷയിൽ രൂപപ്പെടുത്തിയവയാണ്. സമാനതകളാൽ, ക്ലൗഡ് ആപ്ലിക്കേഷനുകൾക്കായി വികസന തത്ത്വങ്ങൾ രൂപപ്പെടുത്താനും കഴിയും, ഇവിടെ അടിസ്ഥാന ഘടകം മാത്രം ഒരു ക്ലാസ് ആയിരിക്കില്ല, ഒരു കണ്ടെയ്നർ ആയിരിക്കും. ഈ തത്ത്വങ്ങൾ പാലിക്കുന്നതിലൂടെ, കുബർനെറ്റസ് പോലുള്ള ക്ലൗഡ് പ്ലാറ്റ്‌ഫോമുകളുടെ ലക്ഷ്യങ്ങളും ലക്ഷ്യങ്ങളും മികച്ച രീതിയിൽ നിറവേറ്റുന്ന കണ്ടെയ്നറൈസ്ഡ് ആപ്ലിക്കേഷനുകൾ നിങ്ങൾക്ക് സൃഷ്‌ടിക്കാനാകും.
ക്ലൗഡ്-നേറ്റീവ് കണ്ടെയ്നറുകൾ: Red Hat സമീപനം
ഇന്ന്, മിക്കവാറും ഏത് ആപ്ലിക്കേഷനും താരതമ്യേന എളുപ്പത്തിൽ കണ്ടെയ്നറുകളിലേക്ക് പാക്കേജുചെയ്യാനാകും. എന്നാൽ കുബെർനെറ്റസ് പോലുള്ള ഒരു ക്ലൗഡ് പ്ലാറ്റ്‌ഫോമിനുള്ളിൽ ആപ്ലിക്കേഷനുകൾ ഫലപ്രദമായി ഓട്ടോമേറ്റ് ചെയ്യാനും ക്രമീകരിക്കാനും കൂടുതൽ പരിശ്രമം ആവശ്യമാണ്.
താഴെ വിവരിച്ചിരിക്കുന്ന ആശയങ്ങളുടെ അടിസ്ഥാനം രീതിശാസ്ത്രമായിരുന്നു കൂടാതെ സോഴ്‌സ് കോഡ് മാനേജ്‌മെൻ്റ് മുതൽ സ്കെയിലിംഗ് മോഡലുകൾ വരെ വെബ് ആപ്ലിക്കേഷനുകൾ നിർമ്മിക്കുന്നതിൻ്റെ വിവിധ വശങ്ങളെക്കുറിച്ചുള്ള മറ്റ് നിരവധി പ്രവർത്തനങ്ങൾ. വിവരിച്ച തത്വങ്ങൾ മൈക്രോസർവീസുകളുടെ മുകളിൽ നിർമ്മിച്ചതും കുബർനെറ്റസ് പോലുള്ള ക്ലൗഡ് പ്ലാറ്റ്‌ഫോമുകൾക്കായി രൂപകൽപ്പന ചെയ്തതുമായ കണ്ടെയ്നറൈസ്ഡ് ആപ്ലിക്കേഷനുകളുടെ വികസനത്തിന് മാത്രമേ ബാധകമാകൂ. ഞങ്ങളുടെ ചർച്ചയിലെ അടിസ്ഥാന ഘടകം കണ്ടെയ്നർ ഇമേജാണ്, ടാർഗെറ്റ് കണ്ടെയ്നർ റൺടൈം കണ്ടെയ്നർ ഓർക്കസ്ട്രേഷൻ പ്ലാറ്റ്‌ഫോമാണ്. മിക്ക ഓർക്കസ്ട്രേഷൻ പ്ലാറ്റ്‌ഫോമുകളിലും ഷെഡ്യൂളിംഗ്, സ്കെയിലിംഗ്, മോണിറ്ററിംഗ് ടാസ്‌ക്കുകൾ ഓട്ടോമേറ്റ് ചെയ്യാൻ കഴിയുന്ന കണ്ടെയ്നറുകൾ സൃഷ്‌ടിക്കുക എന്നതാണ് നിർദ്ദിഷ്ട തത്വങ്ങളുടെ ലക്ഷ്യം. തത്വങ്ങൾ പ്രത്യേക ക്രമത്തിൽ അവതരിപ്പിച്ചിട്ടില്ല.
ഏക ആശങ്ക തത്വം (SCP)
ഈ തത്വം ഏക ഉത്തരവാദിത്ത തത്വത്തിന് സമാനമാണ്. ), ഇത് SOLID സെറ്റിൻ്റെ ഭാഗമാണ് കൂടാതെ എല്ലാ ഒബ്‌ജക്റ്റിനും ഒരു ഉത്തരവാദിത്തം ഉണ്ടായിരിക്കണമെന്നും ആ ഉത്തരവാദിത്തം പൂർണ്ണമായും ഒരു ക്ലാസിൽ ഉൾപ്പെടുത്തിയിരിക്കണമെന്നും പ്രസ്താവിക്കുന്നു. ഓരോ ഉത്തരവാദിത്തവും മാറ്റത്തിനുള്ള കാരണമാണ്, ഒരു ക്ലാസിന് മാറ്റത്തിന് ഒരേയൊരു കാരണം ഉണ്ടായിരിക്കണം എന്നതാണ് എസ്ആർപിയുടെ കാര്യം.
എസ്‌സിപിയിൽ, ഒരു ഒഒപി ക്ലാസുമായി താരതമ്യപ്പെടുത്തുമ്പോൾ ഒരു കണ്ടെയ്‌നറിൻ്റെ ഉയർന്ന തലത്തിലുള്ള അമൂർത്തീകരണവും വിശാലമായ ഉദ്ദേശ്യവും സൂചിപ്പിക്കാൻ “ഉത്തരവാദിത്തം” എന്ന വാക്കിന് പകരം ഞങ്ങൾ “ആശങ്ക” എന്ന വാക്ക് ഉപയോഗിക്കുന്നു. മാറ്റത്തിന് ഒരേയൊരു കാരണം മാത്രമേ എസ്ആർപിയുടെ ലക്ഷ്യമാണെങ്കിൽ, കണ്ടെയ്നറുകൾ വീണ്ടും ഉപയോഗിക്കാനും മാറ്റിസ്ഥാപിക്കാനുമുള്ള കഴിവ് വികസിപ്പിക്കാനുള്ള ആഗ്രഹമാണ് എസ്സിപിക്ക് പിന്നിൽ. SRP പിന്തുടരുന്നതിലൂടെയും ഒരൊറ്റ പ്രശ്നം പരിഹരിക്കുന്ന ഒരു കണ്ടെയ്നർ സൃഷ്‌ടിക്കുന്നതിലൂടെയും അത് പ്രവർത്തനപരമായി പൂർണ്ണമായ രീതിയിൽ ചെയ്യുന്നതിലൂടെയും, നിങ്ങൾ ആ കണ്ടെയ്നർ ചിത്രം വ്യത്യസ്ത അപ്ലിക്കേഷൻ സന്ദർഭങ്ങളിൽ വീണ്ടും ഉപയോഗിക്കാനുള്ള സാധ്യത വർദ്ധിപ്പിക്കുന്നു.
ഓരോ കണ്ടെയ്‌നറും ഒരൊറ്റ പ്രശ്നം പരിഹരിച്ച് അത് നന്നായി ചെയ്യണമെന്ന് SCP തത്വം പറയുന്നു. കൂടാതെ, OOP ലോകത്തിലെ SRP-യെക്കാൾ കണ്ടെയ്നർ ലോകത്തിലെ SCP നേടുന്നത് എളുപ്പമാണ്, കാരണം കണ്ടെയ്നറുകൾ സാധാരണയായി ഒരൊറ്റ പ്രോസസ്സ് പ്രവർത്തിപ്പിക്കുന്നു, കൂടാതെ മിക്കപ്പോഴും ഈ പ്രക്രിയ ഒരൊറ്റ ടാസ്‌ക്ക് പരിഹരിക്കുന്നു.
ഒരു കണ്ടെയ്നർ മൈക്രോസർവീസിന് ഒരേസമയം നിരവധി പ്രശ്‌നങ്ങൾ പരിഹരിക്കണമെങ്കിൽ, സൈഡ്‌കാർ, init കണ്ടെയ്നർ ടെംപ്ലേറ്റുകൾ ഉപയോഗിച്ച് അതിനെ സിംഗിൾ-ടാസ്‌ക് കണ്ടെയ്‌നറുകളായി വിഭജിച്ച് ഒരു പോഡിനുള്ളിൽ (കണ്ടെയ്നർ പ്ലാറ്റ്ഫോം വിന്യാസത്തിൻ്റെ ഒരു യൂണിറ്റ്) സംയോജിപ്പിക്കാം. കൂടാതെ, പഴയ കണ്ടെയ്നർ (വെബ് സെർവർ അല്ലെങ്കിൽ മെസേജ് ബ്രോക്കർ പോലുള്ളവ) മാറ്റി പകരം വയ്ക്കുന്നത് SCP എളുപ്പമാക്കുന്നു, അത് അതേ പ്രശ്നം പരിഹരിക്കുന്നു, എന്നാൽ വികസിപ്പിച്ച പ്രവർത്തനക്ഷമതയോ സ്കെയിലുകളോ മികച്ചതാണ്.
ഉയർന്ന നിരീക്ഷണ തത്വം (HOP)
ആപ്ലിക്കേഷനുകൾ പാക്കേജ് ചെയ്യുന്നതിനും പ്രവർത്തിപ്പിക്കുന്നതിനുമുള്ള ഒരു ഏകീകൃത മാർഗമായി കണ്ടെയ്നറുകൾ ഉപയോഗിക്കുമ്പോൾ, ആപ്ലിക്കേഷനുകൾ തന്നെ ഒരു ബ്ലാക്ക് ബോക്സായി കണക്കാക്കുന്നു. എന്നിരുന്നാലും, ഇവ ക്ലൗഡ് കണ്ടെയ്‌നറുകളാണെങ്കിൽ, കണ്ടെയ്‌നറുകളുടെ ആരോഗ്യം നിരീക്ഷിക്കുന്നതിനും ആവശ്യമെങ്കിൽ ഉചിതമായ നടപടി സ്വീകരിക്കുന്നതിനും റൺടൈമിലേക്ക് പ്രത്യേക API-കൾ നൽകണം. ഇത് കൂടാതെ, കണ്ടെയ്നറുകൾ അപ്‌ഡേറ്റ് ചെയ്യുന്നതിനും അവയുടെ ജീവിത ചക്രം നിയന്ത്രിക്കുന്നതിനുമുള്ള ഓട്ടോമേഷൻ ഏകീകരിക്കാൻ കഴിയില്ല, ഇത് സോഫ്റ്റ്വെയർ സിസ്റ്റത്തിൻ്റെ സ്ഥിരതയും ഉപയോഗക്ഷമതയും മോശമാക്കും.
പ്രായോഗികമായി, ഒരു കണ്ടെയ്നറൈസ്ഡ് ആപ്ലിക്കേഷനിൽ, വിവിധ തരത്തിലുള്ള ആരോഗ്യ പരിശോധനകൾക്കായി ഒരു API ഉണ്ടായിരിക്കണം: ലൈവ്‌നെസ് ടെസ്റ്റുകളും റെഡിനെസ് ടെസ്റ്റുകളും. കൂടുതൽ ചെയ്യാൻ ഒരു ആപ്ലിക്കേഷൻ അവകാശപ്പെടുകയാണെങ്കിൽ, അത് അതിൻ്റെ അവസ്ഥ നിരീക്ഷിക്കുന്നതിനുള്ള മറ്റ് മാർഗങ്ങൾ നൽകണം. ഉദാഹരണത്തിന്, Fluentd, Logstash, മറ്റ് സമാന ടൂളുകൾ എന്നിവ ഉപയോഗിച്ച് ലോഗ് അഗ്രഗേഷനായി STDERR, STDOUT എന്നിവ വഴി പ്രധാനപ്പെട്ട ഇവൻ്റുകൾ ലോഗ് ചെയ്യുന്നു. ഓപ്പൺ ട്രെയ്‌സിംഗ്, പ്രോമിത്യൂസ് മുതലായ ട്രേസിംഗ്, മെട്രിക്‌സ് കളക്ഷൻ ലൈബ്രറികളുമായുള്ള സംയോജനവും.
പൊതുവേ, ആപ്ലിക്കേഷൻ ഇപ്പോഴും ഒരു ബ്ലാക്ക് ബോക്സായി കണക്കാക്കാം, പക്ഷേ പ്ലാറ്റ്‌ഫോമിന് ആവശ്യമായ എല്ലാ API-കളും ഇത് മികച്ച രീതിയിൽ നിരീക്ഷിക്കാനും നിയന്ത്രിക്കാനും നൽകണം.
ലൈഫ് സൈക്കിൾ കൺഫോർമൻസ് പ്രിൻസിപ്പൽ (LCP)
HOP യുടെ വിരുദ്ധമാണ് LCP. കണ്ടെയ്നർ റീഡ് എപിഐകളെ പ്ലാറ്റ്‌ഫോമിലേക്ക് തുറന്നുകാട്ടണമെന്ന് HOP പ്രസ്‌താവിക്കുമ്പോൾ, പ്ലാറ്റ്‌ഫോമിൽ നിന്ന് വിവരങ്ങൾ സ്വീകരിക്കാൻ അപ്ലിക്കേഷന് കഴിയണമെന്ന് LCP ആവശ്യപ്പെടുന്നു. മാത്രമല്ല, കണ്ടെയ്നർ ഇവൻ്റുകൾ സ്വീകരിക്കുക മാത്രമല്ല, മറ്റ് വാക്കുകളിൽ പറഞ്ഞാൽ, അവയോട് പ്രതികരിക്കുകയും വേണം. അതിനാൽ തത്ത്വത്തിൻ്റെ പേര്, പ്ലാറ്റ്‌ഫോമിന് എഴുത്ത് API-കൾ നൽകുന്നതിനുള്ള ആവശ്യകതയായി കണക്കാക്കാം.
ഒരു കണ്ടെയ്‌നറിൻ്റെ ലൈഫ് സൈക്കിൾ നിയന്ത്രിക്കാൻ സഹായിക്കുന്നതിന് പ്ലാറ്റ്‌ഫോമുകൾക്ക് വ്യത്യസ്ത തരത്തിലുള്ള ഇവൻ്റുകൾ ഉണ്ട്. എന്നാൽ അവയിൽ ഏതാണ് ഗ്രഹിക്കേണ്ടതെന്നും എങ്ങനെ പ്രതികരിക്കണമെന്നും പ്രയോഗം തന്നെയാണ് തീരുമാനിക്കേണ്ടത്.
ചില സംഭവങ്ങൾ മറ്റുള്ളവയേക്കാൾ പ്രധാനമാണെന്ന് വ്യക്തമാണ്. ഉദാഹരണത്തിന്, ഒരു ആപ്ലിക്കേഷൻ ക്രാഷുകൾ നന്നായി സഹിക്കുന്നില്ലെങ്കിൽ, അത് സിഗ്നൽ: അവസാനിപ്പിക്കുക (SIGTERM) സന്ദേശങ്ങൾ സ്വീകരിക്കുകയും സിഗ്നൽ പിടിക്കാൻ കഴിയുന്നത്ര വേഗത്തിൽ അതിൻ്റെ അവസാനിപ്പിക്കൽ ദിനചര്യ ആരംഭിക്കുകയും വേണം: SIGTERM-ന് ശേഷം വരുന്ന കൊല്ലുക (SIGKILL).
കൂടാതെ, പോസ്റ്റ്സ്റ്റാർട്ട്, പ്രീസ്റ്റോപ്പ് എന്നിവ പോലുള്ള ഇവൻ്റുകൾ ഒരു ആപ്ലിക്കേഷൻ്റെ ജീവിതചക്രത്തിന് പ്രധാനമാണ്. ഉദാഹരണത്തിന്, ഒരു ആപ്ലിക്കേഷൻ സമാരംഭിച്ചതിന് ശേഷം, അഭ്യർത്ഥനകളോട് പ്രതികരിക്കുന്നതിന് കുറച്ച് സന്നാഹ സമയം ആവശ്യമായി വന്നേക്കാം. അല്ലെങ്കിൽ ഷട്ട് ഡൗൺ ചെയ്യുമ്പോൾ ആപ്ലിക്കേഷൻ ഏതെങ്കിലും പ്രത്യേക രീതിയിൽ ഉറവിടങ്ങൾ റിലീസ് ചെയ്യണം.
ഇമേജ് ഇമ്മ്യൂട്ടബിലിറ്റി പ്രിൻസിപ്പിൾ (IIP)
വ്യത്യസ്ത പരിതസ്ഥിതികളിൽ പ്രവർത്തിപ്പിച്ചാലും, കണ്ടെയ്‌നറൈസ് ചെയ്ത അപ്ലിക്കേഷനുകൾ നിർമ്മിച്ചതിന് ശേഷവും മാറ്റമില്ലാതെ തുടരണമെന്നാണ് പൊതുവെ അംഗീകരിക്കപ്പെട്ടിട്ടുള്ളത്. ഇത് റൺടൈമിൽ ഡാറ്റ സ്റ്റോറേജ് ബാഹ്യവൽക്കരിക്കേണ്ടതിൻ്റെ ആവശ്യകത (മറ്റൊരു രീതിയിൽ പറഞ്ഞാൽ, ഇതിനായി ബാഹ്യ ഉപകരണങ്ങൾ ഉപയോഗിക്കുന്നതിന്) കൂടാതെ ഓരോ പരിതസ്ഥിതിക്കും തനതായ കണ്ടെയ്നറുകൾ പരിഷ്‌ക്കരിക്കുന്നതിനോ സൃഷ്ടിക്കുന്നതിനോ പകരം ബാഹ്യ, റൺടൈം-നിർദ്ദിഷ്ട കോൺഫിഗറേഷനുകളെ ആശ്രയിക്കേണ്ടതിൻ്റെ ആവശ്യകത ആവശ്യമാണ്. ആപ്ലിക്കേഷനിൽ എന്തെങ്കിലും മാറ്റങ്ങൾ വരുത്തിയ ശേഷം, കണ്ടെയ്നർ ഇമേജ് പുനർനിർമ്മിക്കുകയും ഉപയോഗിക്കുന്ന എല്ലാ പരിതസ്ഥിതികളിലേക്കും വിന്യസിക്കുകയും വേണം. വഴിയിൽ, ഐടി സംവിധാനങ്ങൾ കൈകാര്യം ചെയ്യുമ്പോൾ, സമാനമായ ഒരു തത്വം ഉപയോഗിക്കുന്നു, സെർവറുകളുടെയും ഇൻഫ്രാസ്ട്രക്ചറിൻ്റെയും മാറ്റമില്ലാത്ത തത്വം എന്നറിയപ്പെടുന്നു.
വ്യത്യസ്ത റൺടൈം എൻവയോൺമെൻ്റുകൾക്കായി പ്രത്യേകം കണ്ടെയ്നർ ഇമേജുകൾ സൃഷ്ടിക്കുന്നത് തടയുകയും ഉചിതമായ പരിസ്ഥിതി-നിർദ്ദിഷ്ട കോൺഫിഗറേഷനോടൊപ്പം എല്ലായിടത്തും ഒരേ ചിത്രം ഉപയോഗിക്കുകയും ചെയ്യുക എന്നതാണ് ഐഐപിയുടെ ലക്ഷ്യം. ഈ തത്വം പിന്തുടരുന്നത്, ക്ലൗഡ് സിസ്റ്റങ്ങളുടെ ഓട്ടോമേഷൻ വീക്ഷണകോണിൽ നിന്ന് റോൾ-ബാക്ക്, റോൾ-ഫോർവേഡ് ആപ്ലിക്കേഷൻ അപ്‌ഡേറ്റുകൾ പോലുള്ള പ്രധാനപ്പെട്ട സമ്പ്രദായങ്ങൾ നടപ്പിലാക്കാൻ നിങ്ങളെ അനുവദിക്കുന്നു.
പ്രോസസ്സ് ഡിസ്പോസിബിലിറ്റി തത്വം (PDP)
ഒരു കണ്ടെയ്‌നറിൻ്റെ ഏറ്റവും പ്രധാനപ്പെട്ട സവിശേഷതകളിലൊന്ന് അതിൻ്റെ ക്ഷണികതയാണ്: ഒരു കണ്ടെയ്‌നറിൻ്റെ ഒരു ഉദാഹരണം സൃഷ്ടിക്കാൻ എളുപ്പവും നശിപ്പിക്കാൻ എളുപ്പവുമാണ്, അതിനാൽ അത് എപ്പോൾ വേണമെങ്കിലും മറ്റൊരു ഉദാഹരണം ഉപയോഗിച്ച് എളുപ്പത്തിൽ മാറ്റിസ്ഥാപിക്കാം. അത്തരമൊരു മാറ്റിസ്ഥാപിക്കുന്നതിന് നിരവധി കാരണങ്ങളുണ്ടാകാം: സേവനക്ഷമതാ പരിശോധനയുടെ പരാജയം, ആപ്ലിക്കേഷൻ്റെ സ്കെയിലിംഗ്, മറ്റൊരു ഹോസ്റ്റിലേക്ക് കൈമാറ്റം, പ്ലാറ്റ്ഫോം വിഭവങ്ങളുടെ ക്ഷീണം അല്ലെങ്കിൽ മറ്റ് സാഹചര്യങ്ങൾ.
തൽഫലമായി, കണ്ടെയ്‌നറൈസ് ചെയ്ത ആപ്ലിക്കേഷനുകൾ ചില ബാഹ്യ മാർഗങ്ങൾ ഉപയോഗിച്ച് അവയുടെ അവസ്ഥ നിലനിർത്തണം, അല്ലെങ്കിൽ ഇതിനായി ആവർത്തനത്തോടെയുള്ള ആന്തരിക വിതരണം ചെയ്ത സ്കീമുകൾ ഉപയോഗിക്കുക. കൂടാതെ, ആപ്ലിക്കേഷൻ വേഗത്തിൽ ആരംഭിക്കുകയും വേഗത്തിൽ ഷട്ട്ഡൗൺ ചെയ്യുകയും വേണം, കൂടാതെ പെട്ടെന്നുള്ള മാരകമായ ഹാർഡ്‌വെയർ പരാജയത്തിന് തയ്യാറാകുകയും വേണം.
ഈ തത്ത്വം നടപ്പിലാക്കാൻ സഹായിക്കുന്ന ഒരു സമ്പ്രദായം കണ്ടെയ്നറുകൾ ചെറുതായി സൂക്ഷിക്കുക എന്നതാണ്. ഒരു കണ്ടെയ്നർ ഇൻസ്‌റ്റൻസ് സമാരംഭിക്കുന്നതിന് ക്ലൗഡ് പരിതസ്ഥിതികൾക്ക് സ്വയമേവ ഒരു ഹോസ്റ്റിനെ തിരഞ്ഞെടുക്കാൻ കഴിയും, അതിനാൽ ചെറിയ കണ്ടെയ്നർ, വേഗത്തിൽ അത് ആരംഭിക്കും - ഇത് നെറ്റ്‌വർക്കിലെ ടാർഗെറ്റ് ഹോസ്റ്റിലേക്ക് വേഗത്തിൽ പകർത്തും.
സ്വയം നിയന്ത്രണ തത്വം (S-CP)
ഈ തത്വമനുസരിച്ച്, അസംബ്ലി ഘട്ടത്തിൽ, ആവശ്യമായ എല്ലാ ഘടകങ്ങളും കണ്ടെയ്നറിൽ ഉൾപ്പെടുത്തിയിട്ടുണ്ട്. സിസ്റ്റത്തിന് ഒരു ശുദ്ധമായ ലിനക്സ് കേർണൽ മാത്രമേ ഉള്ളൂ എന്ന അനുമാനത്തിലാണ് കണ്ടെയ്നർ നിർമ്മിക്കേണ്ടത്, അതിനാൽ ആവശ്യമായ എല്ലാ അധിക ലൈബ്രറികളും കണ്ടെയ്നറിൽ തന്നെ സ്ഥാപിക്കണം. അനുബന്ധ പ്രോഗ്രാമിംഗ് ഭാഷയ്ക്കുള്ള റൺടൈം, ആപ്ലിക്കേഷൻ പ്ലാറ്റ്ഫോം (ആവശ്യമെങ്കിൽ), കണ്ടെയ്നർ ആപ്ലിക്കേഷൻ പ്രവർത്തിക്കുമ്പോൾ ആവശ്യമായ മറ്റ് ഡിപൻഡൻസികൾ എന്നിവയും ഇതിൽ അടങ്ങിയിരിക്കണം.
പരിസ്ഥിതിയിൽ നിന്ന് പരിതസ്ഥിതിയിൽ വ്യത്യാസപ്പെടുന്ന കോൺഫിഗറേഷനുകൾക്കായി ഒഴിവാക്കലുകൾ ഉണ്ടാക്കിയിട്ടുണ്ട്, കൂടാതെ റൺടൈമിൽ നൽകണം, ഉദാഹരണത്തിന് ഒരു Kubernetes കോൺഫിഗ്മാപ്പ് വഴി.
ഒരു അപ്ലിക്കേഷനിൽ നിരവധി കണ്ടെയ്‌നറൈസ് ചെയ്ത ഘടകങ്ങൾ ഉൾപ്പെട്ടേക്കാം, ഉദാഹരണത്തിന്, ഒരു കണ്ടെയ്നറൈസ്ഡ് വെബ് ആപ്ലിക്കേഷനിൽ ഒരു പ്രത്യേക ഡിബിഎംഎസ് കണ്ടെയ്നർ. എസ്-സിപി തത്വമനുസരിച്ച്, ഈ കണ്ടെയ്നറുകൾ ഒന്നായി സംയോജിപ്പിക്കരുത്, പക്ഷേ ഡാറ്റാബേസിൻ്റെ പ്രവർത്തനത്തിന് ആവശ്യമായ എല്ലാം DBMS കണ്ടെയ്നറിൽ അടങ്ങിയിരിക്കുന്ന തരത്തിൽ നിർമ്മിക്കണം, കൂടാതെ വെബ് ആപ്ലിക്കേഷൻ കണ്ടെയ്നറിൽ വെബിൻ്റെ പ്രവർത്തനത്തിന് ആവശ്യമായ എല്ലാം അടങ്ങിയിരിക്കുന്നു. ആപ്ലിക്കേഷൻ, അതേ വെബ് സെർവർ . തൽഫലമായി, റൺടൈമിൽ വെബ് ആപ്ലിക്കേഷൻ കണ്ടെയ്നർ ഡിബിഎംഎസ് കണ്ടെയ്‌നറിനെ ആശ്രയിക്കുകയും ആവശ്യാനുസരണം ആക്‌സസ് ചെയ്യുകയും ചെയ്യും.
റൺടൈം കൺഫൈൻമെൻ്റ് തത്വം (RCP)
കണ്ടെയ്നർ എങ്ങനെ നിർമ്മിക്കണമെന്നും ഇമേജ് ബൈനറിയിൽ എന്ത് അടങ്ങിയിരിക്കണമെന്നും എസ്-സിപി തത്വം നിർവ്വചിക്കുന്നു. എന്നാൽ ഒരു കണ്ടെയ്നർ എന്നത് ഒരു "ബ്ലാക്ക് ബോക്സ്" മാത്രമല്ല, അതിന് ഒരു സവിശേഷത മാത്രമേയുള്ളൂ - ഫയൽ വലുപ്പം. എക്സിക്യൂഷൻ സമയത്ത്, കണ്ടെയ്നർ മറ്റ് അളവുകൾ സ്വീകരിക്കുന്നു: ഉപയോഗിച്ച മെമ്മറിയുടെ അളവ്, സിപിയു സമയം, മറ്റ് സിസ്റ്റം ഉറവിടങ്ങൾ.
ഇവിടെ ആർസിപി തത്വം ഉപയോഗപ്രദമാണ്, അതനുസരിച്ച് കണ്ടെയ്നർ സിസ്റ്റം ഉറവിടങ്ങൾക്കായുള്ള അതിൻ്റെ ആവശ്യകതകൾ ശിരഛേദം ചെയ്യുകയും അവയെ പ്ലാറ്റ്‌ഫോമിലേക്ക് മാറ്റുകയും വേണം. ഓരോ കണ്ടെയ്‌നറിൻ്റെയും റിസോഴ്സ് പ്രൊഫൈലുകൾ ഉപയോഗിച്ച് (അതിന് എത്ര സിപിയു, മെമ്മറി, നെറ്റ്‌വർക്ക്, ഡിസ്‌ക് ഉറവിടങ്ങൾ എന്നിവ ആവശ്യമാണ്), പ്ലാറ്റ്‌ഫോമിന് മികച്ച രീതിയിൽ ഷെഡ്യൂളിംഗും ഓട്ടോസ്‌കേലിംഗും നടത്താനും ഐടി ശേഷി നിയന്ത്രിക്കാനും കണ്ടെയ്‌നറുകൾക്കായി SLA ലെവലുകൾ നിലനിർത്താനും കഴിയും.
കണ്ടെയ്‌നറിൻ്റെ ഉറവിട ആവശ്യകതകൾ നിറവേറ്റുന്നതിനൊപ്പം, ആപ്ലിക്കേഷൻ്റെ സ്വന്തം അതിരുകൾക്കപ്പുറത്തേക്ക് പോകാതിരിക്കുന്നതും പ്രധാനമാണ്. അല്ലെങ്കിൽ, ഒരു റിസോഴ്സ് ക്ഷാമം സംഭവിക്കുമ്പോൾ, പ്ലാറ്റ്ഫോം അത് അവസാനിപ്പിക്കുകയോ മൈഗ്രേറ്റ് ചെയ്യുകയോ ചെയ്യേണ്ട ആപ്ലിക്കേഷനുകളുടെ പട്ടികയിൽ ഉൾപ്പെടുത്താൻ സാധ്യതയുണ്ട്.
ക്ലൗഡ്-ഫസ്റ്റ് എന്നതിനെക്കുറിച്ച് സംസാരിക്കുമ്പോൾ, നമ്മൾ ജോലി ചെയ്യുന്ന രീതിയെക്കുറിച്ചാണ് സംസാരിക്കുന്നത്.
മുകളിൽ, ക്ലൗഡ് പരിതസ്ഥിതികൾക്കായി ഉയർന്ന നിലവാരമുള്ള കണ്ടെയ്നർ ആപ്ലിക്കേഷനുകൾ നിർമ്മിക്കുന്നതിനുള്ള രീതിശാസ്ത്രപരമായ അടിത്തറ സജ്ജീകരിക്കുന്ന നിരവധി പൊതു തത്ത്വങ്ങൾ ഞങ്ങൾ രൂപപ്പെടുത്തി.
ഈ പൊതു തത്ത്വങ്ങൾക്ക് പുറമേ, കണ്ടെയ്നറുകളിൽ പ്രവർത്തിക്കുന്നതിന് നിങ്ങൾക്ക് കൂടുതൽ വിപുലമായ രീതികളും സാങ്കേതികതകളും ആവശ്യമാണെന്ന് ശ്രദ്ധിക്കുക. കൂടാതെ, ഞങ്ങൾക്ക് കുറച്ച് ഹ്രസ്വ ശുപാർശകൾ ഉണ്ട്, അവ കൂടുതൽ നിർദ്ദിഷ്ടവും സാഹചര്യത്തെ ആശ്രയിച്ച് പ്രയോഗിക്കേണ്ടതുമാണ് (അല്ലെങ്കിൽ പ്രയോഗിക്കരുത്):
- ചിത്രങ്ങളുടെ വലുപ്പം കുറയ്ക്കാൻ ശ്രമിക്കുക: താൽക്കാലിക ഫയലുകൾ ഇല്ലാതാക്കുക, അനാവശ്യ പാക്കേജുകൾ ഇൻസ്റ്റാൾ ചെയ്യരുത് - കണ്ടെയ്നർ വലുപ്പം ചെറുതാണെങ്കിൽ, അത് വേഗത്തിൽ കൂട്ടിച്ചേർക്കപ്പെടുകയും നെറ്റ്‌വർക്കിലൂടെ ടാർഗെറ്റ് ഹോസ്റ്റിലേക്ക് പകർത്തുകയും ചെയ്യുന്നു.
- അനിയന്ത്രിതമായ ഉപയോക്തൃ ഐഡികളിൽ ശ്രദ്ധ കേന്ദ്രീകരിക്കുക: നിങ്ങളുടെ കണ്ടെയ്നറുകൾ സമാരംഭിക്കുന്നതിന് സുഡോ കമാൻഡോ ഏതെങ്കിലും പ്രത്യേക യൂസർ ഐഡിയോ ഉപയോഗിക്കരുത്.
- പ്രധാനപ്പെട്ട പോർട്ടുകൾ അടയാളപ്പെടുത്തുക: നിങ്ങൾക്ക് റൺടൈമിൽ പോർട്ട് നമ്പറുകൾ സജ്ജീകരിക്കാൻ കഴിയും, എന്നാൽ EXPOSE കമാൻഡ് ഉപയോഗിച്ച് അവ വ്യക്തമാക്കുന്നതാണ് നല്ലത് - ഇത് മറ്റ് ആളുകൾക്കും പ്രോഗ്രാമുകൾക്കും നിങ്ങളുടെ ഇമേജുകൾ ഉപയോഗിക്കുന്നത് എളുപ്പമാക്കും.
- വോള്യങ്ങളിൽ സ്ഥിരമായ ഡാറ്റ സംഭരിക്കുക: കണ്ടെയ്നർ നശിച്ചതിനുശേഷം ശേഷിക്കുന്ന ഡാറ്റ വോള്യങ്ങളിൽ എഴുതണം.
- ഇമേജ് മെറ്റാഡാറ്റ എഴുതുക: ടാഗുകളും ലേബലുകളും വ്യാഖ്യാനങ്ങളും ചിത്രങ്ങൾ ഉപയോഗിക്കാൻ എളുപ്പമാക്കുന്നു - മറ്റ് ഡെവലപ്പർമാർ നിങ്ങൾക്ക് നന്ദി പറയും.
- ഹോസ്റ്റും ചിത്രങ്ങളും സമന്വയിപ്പിക്കുക: ചില കണ്ടെയ്നറൈസ്ഡ് ആപ്ലിക്കേഷനുകൾക്ക്, സമയം അല്ലെങ്കിൽ മെഷീൻ ഐഡി പോലുള്ള ചില ആട്രിബ്യൂട്ടുകളിൽ ഹോസ്റ്റുമായി സമന്വയിപ്പിക്കാൻ കണ്ടെയ്നർ ആവശ്യമാണ്.
- ഉപസംഹാരമായി, മുകളിൽ ലിസ്റ്റുചെയ്തിരിക്കുന്ന തത്വങ്ങൾ കൂടുതൽ ഫലപ്രദമായി നടപ്പിലാക്കാൻ നിങ്ങളെ സഹായിക്കുന്ന ടെംപ്ലേറ്റുകളും മികച്ച രീതികളും ഞങ്ങൾ പങ്കിടുന്നു:
ജൂൺ 11ന് 11.00
നിങ്ങൾ എന്ത് പഠിക്കും:
- മാറ്റാനാകാത്ത Red Hat Enterprise Linux CoreOS
- ഓപ്പൺഷിഫ്റ്റ് സേവന മെഷ്
- ഓപ്പറേറ്റർ ചട്ടക്കൂട്
- നേറ്റീവ് ചട്ടക്കൂട്
അവലംബം: www.habr.com