എന്താണ് ഡോക്കർ: ചരിത്രത്തിലേക്കും അടിസ്ഥാന അമൂർത്തങ്ങളിലേക്കും ഒരു ഹ്രസ്വ വിനോദയാത്ര

ആഗസ്ത് 10-ന് ചേരിയിൽ ആരംഭിച്ചു ഡോക്കർ വീഡിയോ കോഴ്സ്, അതിൽ ഞങ്ങൾ ഇത് പൂർണ്ണമായും വിശകലനം ചെയ്യുന്നു - അടിസ്ഥാന അമൂർത്തങ്ങൾ മുതൽ നെറ്റ്‌വർക്ക് പാരാമീറ്ററുകൾ വരെ.

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

എന്താണ് ഡോക്കർ

വിക്കിപീഡിയയിൽ നിന്ന് ഡോക്കറിന്റെ നിർവചനം നോക്കാം.

കണ്ടെയ്നറൈസ്ഡ് പരിതസ്ഥിതികളിൽ ആപ്ലിക്കേഷനുകളുടെ വിന്യാസവും മാനേജ്മെന്റും ഓട്ടോമേറ്റ് ചെയ്യുന്നതിനുള്ള സോഫ്റ്റ്വെയറാണ് ഡോക്കർ.

ഈ നിർവചനത്തിൽ നിന്ന് ഒന്നും വ്യക്തമല്ല. "കണ്ടെയ്‌നറൈസേഷനെ പിന്തുണയ്ക്കുന്ന പരിതസ്ഥിതികളിൽ" എന്താണ് അർത്ഥമാക്കുന്നത് എന്ന് പ്രത്യേകിച്ച് വ്യക്തമല്ല. അതറിയാൻ, നമുക്ക് കാലത്തിലേക്ക് മടങ്ങാം. "ഏകശിലായുഗം" എന്ന് ഞാൻ പരമ്പരാഗതമായി വിളിക്കുന്ന കാലഘട്ടത്തിൽ നിന്ന് നമുക്ക് ആരംഭിക്കാം.

മോണോലിത്തിക്ക് യുഗം

ഏകശിലായുഗം 2000-കളുടെ തുടക്കമാണ്, എല്ലാ ആപ്ലിക്കേഷനുകളും ഒരു കൂട്ടം ആശ്രിതത്വങ്ങളുള്ള ഏകശിലാരൂപമായിരുന്നു. വികസനത്തിന് ഏറെ സമയമെടുത്തു. അതേ സമയം, അധികം സെർവറുകൾ ഉണ്ടായിരുന്നില്ല; ഞങ്ങൾ അവയെല്ലാം പേരിന് അറിയുകയും നിരീക്ഷിക്കുകയും ചെയ്തു. അത്തരമൊരു രസകരമായ താരതമ്യം ഉണ്ട്:

വളർത്തുമൃഗങ്ങൾ വളർത്തുമൃഗങ്ങളാണ്. ഏകശിലയുഗത്തിൽ, ഞങ്ങൾ ഞങ്ങളുടെ സെർവറുകളെ വളർത്തുമൃഗങ്ങളെപ്പോലെ പരിചരിച്ചു, വളർത്തിയെടുക്കുകയും പരിപാലിക്കുകയും, പൊടിപടലങ്ങൾ പറത്തിവിടുകയും ചെയ്തു. മികച്ച റിസോഴ്‌സ് മാനേജ്‌മെന്റിനായി, ഞങ്ങൾ വെർച്വലൈസേഷൻ ഉപയോഗിച്ചു: ഞങ്ങൾ ഒരു സെർവർ എടുത്ത് നിരവധി വെർച്വൽ മെഷീനുകളായി മുറിച്ചു, അതുവഴി പരിസ്ഥിതിയുടെ ഒറ്റപ്പെടൽ ഉറപ്പാക്കുന്നു.

ഹൈപ്പർവൈസർ അടിസ്ഥാനമാക്കിയുള്ള വിർച്ച്വലൈസേഷൻ സിസ്റ്റങ്ങൾ

വിർച്വലൈസേഷൻ സിസ്റ്റങ്ങളെ കുറിച്ച് എല്ലാവരും കേട്ടിട്ടുണ്ടാകും: VMware, VirtualBox, Hyper-V, Qemu KVM മുതലായവ. അവ ആപ്ലിക്കേഷൻ ഐസൊലേഷനും റിസോഴ്സ് മാനേജ്മെന്റും നൽകുന്നു, പക്ഷേ അവയ്ക്ക് ദോഷങ്ങളുമുണ്ട്. വിർച്ച്വലൈസേഷൻ ചെയ്യുന്നതിന്, നിങ്ങൾക്ക് ഒരു ഹൈപ്പർവൈസർ ആവശ്യമാണ്. കൂടാതെ ഹൈപ്പർവൈസർ ഒരു റിസോഴ്സ് ഓവർഹെഡാണ്. വെർച്വൽ മെഷീൻ തന്നെ സാധാരണയായി ഒരു വലിയ ഭീമാകാരമാണ് - ഒരു ഓപ്പറേറ്റിംഗ് സിസ്റ്റം, Nginx, Apache, ഒരുപക്ഷേ MySQL എന്നിവ അടങ്ങിയിരിക്കുന്ന കനത്ത ചിത്രം. ചിത്രം വലുതാണ്, വെർച്വൽ മെഷീൻ പ്രവർത്തിക്കാൻ അസൗകര്യമുണ്ട്. തൽഫലമായി, വെർച്വൽ മെഷീനുകളിൽ പ്രവർത്തിക്കുന്നത് മന്ദഗതിയിലാകും. ഈ പ്രശ്നം പരിഹരിക്കുന്നതിനായി, കേർണൽ തലത്തിൽ വിർച്ച്വലൈസേഷൻ സിസ്റ്റങ്ങൾ സൃഷ്ടിച്ചു.

കേർണൽ-ലെവൽ വിർച്ച്വലൈസേഷൻ സിസ്റ്റങ്ങൾ

കേർണൽ-ലെവൽ വിർച്ച്വലൈസേഷനെ OpenVZ, Systemd-nspawn, LXC സിസ്റ്റങ്ങൾ പിന്തുണയ്ക്കുന്നു. അത്തരം വിർച്ച്വലൈസേഷന്റെ ശ്രദ്ധേയമായ ഉദാഹരണമാണ് LXC (ലിനക്സ് കണ്ടെയ്നറുകൾ).

ഒരൊറ്റ നോഡിൽ ലിനക്സ് ഓപ്പറേറ്റിംഗ് സിസ്റ്റത്തിന്റെ ഒന്നിലധികം ഒറ്റപ്പെട്ട സംഭവങ്ങൾ പ്രവർത്തിപ്പിക്കുന്നതിനുള്ള ഒരു ഓപ്പറേറ്റിംഗ് സിസ്റ്റം-ലെവൽ വിർച്ച്വലൈസേഷൻ സിസ്റ്റമാണ് LXC. LXC വെർച്വൽ മെഷീനുകൾ ഉപയോഗിക്കുന്നില്ല, എന്നാൽ സ്വന്തം പ്രോസസ്സ് സ്‌പെയ്‌സും നെറ്റ്‌വർക്ക് സ്റ്റാക്കും ഉപയോഗിച്ച് ഒരു വെർച്വൽ പരിസ്ഥിതി സൃഷ്ടിക്കുന്നു.

അടിസ്ഥാനപരമായി LXC കണ്ടെയ്നറുകൾ സൃഷ്ടിക്കുന്നു. വെർച്വൽ മെഷീനുകളും കണ്ടെയ്‌നറുകളും തമ്മിലുള്ള വ്യത്യാസം എന്താണ്?

ഒറ്റപ്പെടുത്തൽ പ്രക്രിയകൾക്ക് കണ്ടെയ്നർ അനുയോജ്യമല്ല: കേർണൽ തലത്തിലുള്ള വിർച്ച്വലൈസേഷൻ സിസ്റ്റങ്ങളിൽ കേടുപാടുകൾ കാണപ്പെടുന്നു, അത് കണ്ടെയ്നറിൽ നിന്ന് ഹോസ്റ്റിലേക്ക് രക്ഷപ്പെടാൻ അനുവദിക്കുന്നു. അതിനാൽ, നിങ്ങൾക്ക് എന്തെങ്കിലും ഒറ്റപ്പെടുത്തണമെങ്കിൽ, ഒരു വെർച്വൽ മെഷീൻ ഉപയോഗിക്കുന്നതാണ് നല്ലത്.

വിർച്ച്വലൈസേഷനും കണ്ടെയ്‌നറൈസേഷനും തമ്മിലുള്ള വ്യത്യാസങ്ങൾ ഡയഗ്രാമിൽ കാണാം.
ഹാർഡ്‌വെയർ ഹൈപ്പർവൈസറുകൾ, ഒഎസിന് മുകളിൽ ഹൈപ്പർവൈസറുകൾ, കണ്ടെയ്‌നറുകൾ എന്നിവയുണ്ട്.

നിങ്ങൾക്ക് ശരിക്കും എന്തെങ്കിലും ഒറ്റപ്പെടുത്തണമെങ്കിൽ ഹാർഡ്‌വെയർ ഹൈപ്പർവൈസറുകൾ രസകരമാണ്. കാരണം മെമ്മറി പേജുകളുടെയും പ്രോസസ്സറുകളുടെയും തലത്തിൽ ഒറ്റപ്പെടുത്താൻ സാധിക്കും.

ഒരു പ്രോഗ്രാമായി ഹൈപ്പർവൈസറുകൾ ഉണ്ട്, കണ്ടെയ്നറുകൾ ഉണ്ട്, ഞങ്ങൾ അവരെ കുറിച്ച് കൂടുതൽ സംസാരിക്കും. കണ്ടെയ്‌നറൈസേഷൻ സിസ്റ്റങ്ങൾക്ക് ഹൈപ്പർവൈസർ ഇല്ല, പക്ഷേ കണ്ടെയ്‌നറുകൾ സൃഷ്‌ടിക്കുകയും നിയന്ത്രിക്കുകയും ചെയ്യുന്ന ഒരു കണ്ടെയ്‌നർ എഞ്ചിൻ ഉണ്ട്. ഈ കാര്യം കൂടുതൽ ഭാരം കുറഞ്ഞതാണ്, അതിനാൽ കോർ ഉപയോഗിച്ച് പ്രവർത്തിക്കുന്നത് കാരണം ഓവർഹെഡ് കുറവാണ് അല്ലെങ്കിൽ ഒന്നുമില്ല.

കെർണൽ തലത്തിൽ കണ്ടെയ്നറൈസേഷനായി എന്താണ് ഉപയോഗിക്കുന്നത്

മറ്റ് പ്രക്രിയകളിൽ നിന്ന് ഒറ്റപ്പെട്ട ഒരു കണ്ടെയ്നർ സൃഷ്ടിക്കാൻ നിങ്ങളെ അനുവദിക്കുന്ന പ്രധാന സാങ്കേതികവിദ്യകൾ നെയിംസ്പേസുകളും നിയന്ത്രണ ഗ്രൂപ്പുകളുമാണ്.

നെയിംസ്‌പെയ്‌സ്: PID, നെറ്റ്‌വർക്കിംഗ്, മൗണ്ട്, യൂസർ. കൂടുതൽ ഉണ്ട്, എന്നാൽ മനസ്സിലാക്കാനുള്ള എളുപ്പത്തിനായി ഞങ്ങൾ ഇവയിൽ ശ്രദ്ധ കേന്ദ്രീകരിക്കും.

PID നെയിംസ്പേസ് പ്രക്രിയകളെ പരിമിതപ്പെടുത്തുന്നു. ഉദാഹരണത്തിന്, നമ്മൾ ഒരു PID നെയിംസ്പേസ് സൃഷ്ടിച്ച് അവിടെ ഒരു പ്രോസസ്സ് സ്ഥാപിക്കുമ്പോൾ, അത് PID 1 ആയി മാറുന്നു. സാധാരണയായി സിസ്റ്റങ്ങളിൽ PID 1 എന്നത് systemd അല്ലെങ്കിൽ init ആണ്. അതനുസരിച്ച്, നമ്മൾ ഒരു പുതിയ നെയിംസ്പേസിൽ ഒരു പ്രക്രിയ സ്ഥാപിക്കുമ്പോൾ, അതിന് PID 1-ഉം ലഭിക്കും.

നെറ്റ്‌വർക്കിംഗ് നെയിംസ്‌പേസ് നിങ്ങളെ നെറ്റ്‌വർക്ക് പരിമിതപ്പെടുത്താനും/ഒറ്റപ്പെടുത്താനും നിങ്ങളുടെ സ്വന്തം ഇന്റർഫേസുകൾ ഉള്ളിൽ സ്ഥാപിക്കാനും അനുവദിക്കുന്നു. മൗണ്ട് ഒരു ഫയൽ സിസ്റ്റം പരിമിതിയാണ്. ഉപയോക്താവ് - ഉപയോക്താക്കൾക്കുള്ള നിയന്ത്രണം.

നിയന്ത്രണ ഗ്രൂപ്പുകൾ: മെമ്മറി, CPU, IOPS, നെറ്റ്‌വർക്ക് - ആകെ 12 ക്രമീകരണങ്ങൾ. അല്ലെങ്കിൽ അവയെ Cgroups ("C-groups") എന്നും വിളിക്കുന്നു.

കൺട്രോൾ ഗ്രൂപ്പുകൾ ഒരു കണ്ടെയ്‌നറിനായി ഉറവിടങ്ങൾ നിയന്ത്രിക്കുന്നു. കൺട്രോൾ ഗ്രൂപ്പുകൾ വഴി, കണ്ടെയ്നർ ഒരു നിശ്ചിത അളവിൽ കൂടുതൽ വിഭവങ്ങൾ ഉപയോഗിക്കരുതെന്ന് നമുക്ക് പറയാൻ കഴിയും.

കണ്ടെയ്നറൈസേഷൻ പൂർണ്ണമായി പ്രവർത്തിക്കുന്നതിന്, അധിക സാങ്കേതികവിദ്യകൾ ഉപയോഗിക്കുന്നു: കഴിവുകൾ, കോപ്പി-ഓൺ-റൈറ്റും മറ്റുള്ളവയും.

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

കോപ്പി-ഓൺ-റൈറ്റ് സിസ്റ്റം ഡോക്കർ ഇമേജുകൾക്കൊപ്പം പ്രവർത്തിക്കാനും കൂടുതൽ കാര്യക്ഷമമായി ഉപയോഗിക്കാനും ഞങ്ങളെ അനുവദിക്കുന്നു.

ഡോക്കറിന് നിലവിൽ Cgroups v2-മായി അനുയോജ്യത പ്രശ്‌നങ്ങളുണ്ട്, അതിനാൽ ഈ ലേഖനം Cgroups v1-ൽ പ്രത്യേകം ശ്രദ്ധ കേന്ദ്രീകരിക്കുന്നു.

എന്നാൽ നമുക്ക് ചരിത്രത്തിലേക്ക് മടങ്ങാം.

കേർണൽ തലത്തിൽ വിർച്ച്വലൈസേഷൻ സിസ്റ്റങ്ങൾ പ്രത്യക്ഷപ്പെട്ടപ്പോൾ, അവ സജീവമായി ഉപയോഗിക്കാൻ തുടങ്ങി. ഹൈപ്പർവൈസറിലെ ഓവർഹെഡ് അപ്രത്യക്ഷമായി, പക്ഷേ ചില പ്രശ്നങ്ങൾ അവശേഷിച്ചു:

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

ഈ പ്രശ്നങ്ങളെല്ലാം പരിഹരിക്കാൻ, അടുത്ത യുഗം വന്നിരിക്കുന്നു.

കണ്ടെയ്നർ യുഗം

കണ്ടെയ്നറുകളുടെ യുഗം വന്നപ്പോൾ, അവരോടൊപ്പം പ്രവർത്തിക്കാനുള്ള തത്വശാസ്ത്രം മാറി:

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

വളർത്തുമൃഗങ്ങൾ vs കന്നുകാലികളെ കുറിച്ച് ഞാൻ പറഞ്ഞത് ഓർക്കുന്നുണ്ടോ? മുമ്പ് വളർത്തുമൃഗങ്ങളെപ്പോലെയായിരുന്നു സന്ദർഭങ്ങൾ, എന്നാൽ ഇപ്പോൾ അവ കന്നുകാലികളെപ്പോലെയായി. മുമ്പ്, ഒരു മോണോലിത്ത് ഉണ്ടായിരുന്നു - ഒരു ആപ്ലിക്കേഷൻ. ഇപ്പോൾ ഇത് 100 മൈക്രോ സർവീസുകൾ, 100 കണ്ടെയ്നറുകൾ. ചില പാത്രങ്ങളിൽ 2-3 പകർപ്പുകൾ ഉണ്ടായിരിക്കാം. ഓരോ കണ്ടെയ്‌നറും നിയന്ത്രിക്കുന്നത് ഞങ്ങൾക്ക് അത്ര പ്രധാനമല്ല. ഞങ്ങൾക്ക് കൂടുതൽ പ്രധാനപ്പെട്ടത് സേവനത്തിന്റെ ലഭ്യതയാണ്: ഈ കണ്ടെയ്നറുകൾ എന്താണ് ചെയ്യുന്നത്. ഇത് നിരീക്ഷണത്തിലേക്കുള്ള സമീപനങ്ങളെ മാറ്റുന്നു.

2014-2015 ൽ, ഡോക്കർ അഭിവൃദ്ധി പ്രാപിച്ചു - നമ്മൾ ഇപ്പോൾ സംസാരിക്കുന്ന സാങ്കേതികവിദ്യ.

ഡോക്കർ തത്ത്വചിന്തയും സ്റ്റാൻഡേർഡ് ആപ്ലിക്കേഷൻ പാക്കേജിംഗും മാറ്റി. ഡോക്കർ ഉപയോഗിച്ച്, നമുക്ക് ഒരു ആപ്ലിക്കേഷൻ പാക്കേജ് ചെയ്യാനും അത് ഒരു ശേഖരത്തിലേക്ക് അയയ്ക്കാനും അവിടെ നിന്ന് ഡൗൺലോഡ് ചെയ്യാനും വിന്യസിക്കാനും കഴിയും.

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

ഓവർഹെഡിനെക്കുറിച്ച് വ്യതിചലനം

ഓവർഹെഡുകൾ സംബന്ധിച്ച് എപ്പോഴും തർക്കങ്ങൾ ഉണ്ടാകാറുണ്ട്. ലിനക്സ് കേർണലും കണ്ടെയ്‌നറൈസേഷന് ആവശ്യമായ എല്ലാ പ്രക്രിയകളും ഉപയോഗിക്കുന്നതിനാൽ ഡോക്കർ അധിക ലോഡ് വഹിക്കില്ലെന്ന് ചിലർ വിശ്വസിക്കുന്നു. "ഡോക്കർ ഓവർഹെഡ് ആണെന്ന് നിങ്ങൾ പറഞ്ഞാൽ, ലിനക്സ് കേർണൽ ഓവർഹെഡാണ്."

മറുവശത്ത്, നിങ്ങൾ കൂടുതൽ ആഴത്തിൽ പോയാൽ, ഡോക്കറിൽ തീർച്ചയായും നിരവധി കാര്യങ്ങൾ ഉണ്ട്, അത് ഒരു നീണ്ടുനിൽക്കുമ്പോൾ, ഓവർഹെഡ് എന്ന് പറയാം.

ആദ്യത്തേത് PID നെയിംസ്പേസ് ആണ്. നമ്മൾ ഒരു നെയിംസ്‌പെയ്‌സിൽ ഒരു പ്രോസസ്സ് സ്ഥാപിക്കുമ്പോൾ, അതിന് PID 1 അസൈൻ ചെയ്യപ്പെടുന്നു. അതേ സമയം, ഈ പ്രോസസ്സിന് മറ്റൊരു PID ഉണ്ട്, അത് കണ്ടെയ്‌നറിന് പുറത്ത് ഹോസ്റ്റ് നെയിംസ്‌പെയ്‌സിൽ സ്ഥിതിചെയ്യുന്നു. ഉദാഹരണത്തിന്, ഞങ്ങൾ Nginx ഒരു കണ്ടെയ്‌നറിൽ സമാരംഭിച്ചു, അത് PID 1 ആയി (മാസ്റ്റർ പ്രോസസ്) മാറി. കൂടാതെ ഹോസ്റ്റിൽ ഇതിന് PID 12623 ഉണ്ട്. കൂടാതെ ഇത് എത്രമാത്രം ഓവർഹെഡ് ആണെന്ന് പറയാൻ പ്രയാസമാണ്.

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

ഒപ്പം പ്രകടനത്തെക്കുറിച്ച് ഒരു കുറിപ്പ് കൂടി. ചില കേർണൽ പാരാമീറ്ററുകൾ ഹോസ്റ്റിൽ നിന്ന് കണ്ടെയ്നറിലേക്ക് കൈമാറുന്നു. പ്രത്യേകിച്ച്, ചില നെറ്റ്വർക്ക് പരാമീറ്ററുകൾ. അതിനാൽ, നിങ്ങൾക്ക് ഡോക്കറിൽ ഉയർന്ന പ്രകടനമുള്ള എന്തെങ്കിലും പ്രവർത്തിപ്പിക്കണമെങ്കിൽ, ഉദാഹരണത്തിന്, നെറ്റ്‌വർക്ക് സജീവമായി ഉപയോഗിക്കുന്ന ഒന്ന്, നിങ്ങൾ ഈ പാരാമീറ്ററുകളെങ്കിലും ക്രമീകരിക്കേണ്ടതുണ്ട്. ചില nf_contrack, ഉദാഹരണത്തിന്.

ഡോക്കർ ആശയത്തെക്കുറിച്ച്

ഡോക്കറിൽ നിരവധി ഘടകങ്ങൾ അടങ്ങിയിരിക്കുന്നു:

1. ഡോക്കർ ഡെമൺ ഇതേ കണ്ടെയ്‌നർ എഞ്ചിനാണ്; കണ്ടെയ്നറുകൾ വിക്ഷേപിക്കുന്നു.
2. ഡോക്കർ സിഐഐ ഒരു ഡോക്കർ മാനേജ്മെന്റ് യൂട്ടിലിറ്റിയാണ്.
3. ഡോക്കർഫയൽ - ഒരു ചിത്രം എങ്ങനെ നിർമ്മിക്കാം എന്നതിനെക്കുറിച്ചുള്ള നിർദ്ദേശങ്ങൾ.
4. ചിത്രം - കണ്ടെയ്നർ പുറത്തെടുത്ത ചിത്രം.
5. കണ്ടെയ്നർ.
6. ഡോക്കർ രജിസ്ട്രി ഒരു ഇമേജ് ശേഖരമാണ്.

ആസൂത്രിതമായി ഇത് ഇതുപോലെ കാണപ്പെടുന്നു:

ഡോക്കർ ഡെമൺ ഡോക്കർ_ഹോസ്റ്റിൽ പ്രവർത്തിക്കുകയും കണ്ടെയ്‌നറുകൾ ലോഞ്ച് ചെയ്യുകയും ചെയ്യുന്നു. കമാൻഡുകൾ അയയ്ക്കുന്ന ഒരു ക്ലയന്റ് ഉണ്ട്: ചിത്രം നിർമ്മിക്കുക, ചിത്രം ഡൗൺലോഡ് ചെയ്യുക, കണ്ടെയ്നർ സമാരംഭിക്കുക. ഡോക്കർ ഡെമൺ രജിസ്ട്രിയിലേക്ക് പോയി അവ നടപ്പിലാക്കുന്നു. ഡോക്കർ ക്ലയന്റിന് പ്രാദേശികമായും (യുണിക്സ് സോക്കറ്റിലേക്ക്) ടിസിപി വഴിയും റിമോട്ട് ഹോസ്റ്റിൽ നിന്ന് ആക്സസ് ചെയ്യാൻ കഴിയും.

നമുക്ക് ഓരോ ഘടകങ്ങളിലൂടെയും പോകാം.

ഡോക്കർ ഡെമൺ - ഇതാണ് സെർവർ ഭാഗം, ഇത് ഹോസ്റ്റ് മെഷീനിൽ പ്രവർത്തിക്കുന്നു: ഇമേജുകൾ ഡൌൺലോഡ് ചെയ്യുകയും അവയിൽ നിന്ന് കണ്ടെയ്നറുകൾ ലോഞ്ച് ചെയ്യുകയും, കണ്ടെയ്നറുകൾക്കിടയിൽ ഒരു നെറ്റ്വർക്ക് സൃഷ്ടിക്കുകയും ലോഗുകൾ ശേഖരിക്കുകയും ചെയ്യുന്നു. "ഒരു ഇമേജ് സൃഷ്ടിക്കുക" എന്ന് നമ്മൾ പറയുമ്പോൾ ഭൂതം അതും ചെയ്യുന്നു.

ഡോക്കർ CLI — ഡോക്കർ ക്ലയന്റ് ഭാഗം, ഡെമണുമായി പ്രവർത്തിക്കുന്നതിനുള്ള കൺസോൾ യൂട്ടിലിറ്റി. ഞാൻ ആവർത്തിക്കുന്നു, ഇത് പ്രാദേശികമായി മാത്രമല്ല, നെറ്റ്‌വർക്കിലൂടെയും പ്രവർത്തിക്കാൻ കഴിയും.

അടിസ്ഥാന കമാൻഡുകൾ:

ഡോക്കർ പിഎസ് - ഡോക്കർ ഹോസ്റ്റിൽ നിലവിൽ പ്രവർത്തിക്കുന്ന കണ്ടെയ്‌നറുകൾ കാണിക്കുക.
ഡോക്കർ ഇമേജുകൾ - പ്രാദേശികമായി ഡൗൺലോഡ് ചെയ്ത ചിത്രങ്ങൾ കാണിക്കുക.
ഡോക്കർ തിരയൽ <> - രജിസ്ട്രിയിൽ ഒരു ചിത്രത്തിനായി തിരയുക.
ഡോക്കർ പുൾ <> - രജിസ്ട്രിയിൽ നിന്ന് മെഷീനിലേക്ക് ഒരു ചിത്രം ഡൗൺലോഡ് ചെയ്യുക.
ഡോക്കർ ബിൽഡ് < > - ചിത്രം ശേഖരിക്കുക.
ഡോക്കർ റൺ <> - കണ്ടെയ്നർ സമാരംഭിക്കുക.
ഡോക്കർ rm <> - കണ്ടെയ്നർ നീക്കം ചെയ്യുക.
ഡോക്കർ ലോഗുകൾ <> - കണ്ടെയ്നർ ലോഗുകൾ
ഡോക്കർ സ്റ്റാർട്ട്/സ്റ്റോപ്പ്/റീസ്റ്റാർട്ട് <> - കണ്ടെയ്‌നറിൽ പ്രവർത്തിക്കുന്നു

നിങ്ങൾ ഈ കമാൻഡുകൾ മാസ്റ്റർ ചെയ്യുകയും അവ ഉപയോഗിക്കുന്നതിൽ ആത്മവിശ്വാസം പ്രകടിപ്പിക്കുകയും ചെയ്യുന്നുവെങ്കിൽ, ഉപയോക്തൃ തലത്തിൽ ഡോക്കറിൽ 70% പ്രാവീണ്യമുള്ളതായി സ്വയം കണക്കാക്കുക.

Dockerfile - ഒരു ചിത്രം സൃഷ്ടിക്കുന്നതിനുള്ള നിർദ്ദേശങ്ങൾ. മിക്കവാറും എല്ലാ നിർദ്ദേശ കമാൻഡും ഒരു പുതിയ ലെയറാണ്. നമുക്ക് ഒരു ഉദാഹരണം നോക്കാം.

Dockerfile ഇതുപോലെ കാണപ്പെടുന്നു: ഇടതുവശത്തുള്ള കമാൻഡുകൾ, വലതുവശത്ത് ആർഗ്യുമെന്റുകൾ. ഇവിടെയുള്ള ഓരോ കമാൻഡും (സാധാരണയായി ഡോക്കർഫയലിൽ എഴുതിയത്) ഇമേജിൽ ഒരു പുതിയ ലെയർ സൃഷ്ടിക്കുന്നു.

ഇടതുവശത്തേക്ക് നോക്കിയാൽ പോലും എന്താണ് സംഭവിക്കുന്നതെന്ന് ഏകദേശം മനസ്സിലാക്കാൻ കഴിയും. ഞങ്ങൾ പറയുന്നു: "ഞങ്ങൾക്കായി ഒരു ഫോൾഡർ സൃഷ്ടിക്കുക" - ഇത് ഒരു പാളിയാണ്. "ഫോൾഡർ പ്രവർത്തനക്ഷമമാക്കുക" എന്നത് മറ്റൊരു പാളിയാണ്. ലെയർ കേക്ക് ജീവിതം എളുപ്പമാക്കുന്നു. ഞാൻ മറ്റൊരു Dockerfile സൃഷ്ടിക്കുകയും അവസാന വരിയിൽ എന്തെങ്കിലും മാറ്റുകയും ചെയ്താൽ - "python" "main.py" അല്ലാതെ മറ്റെന്തെങ്കിലും ഞാൻ പ്രവർത്തിപ്പിക്കുകയോ മറ്റൊരു ഫയലിൽ നിന്ന് ഡിപൻഡൻസികൾ ഇൻസ്റ്റാൾ ചെയ്യുകയോ ചെയ്താൽ - മുമ്പത്തെ ലെയറുകൾ ഒരു കാഷെ ആയി വീണ്ടും ഉപയോഗിക്കും.

ചിത്രം - ഇതാണ് കണ്ടെയ്നർ പാക്കേജിംഗ്; ചിത്രത്തിൽ നിന്ന് കണ്ടെയ്നറുകൾ ലോഞ്ച് ചെയ്യുന്നു. ഒരു പാക്കേജ് മാനേജറുടെ വീക്ഷണകോണിൽ നിന്ന് ഡോക്കറിനെ നോക്കുകയാണെങ്കിൽ (നമ്മൾ deb അല്ലെങ്കിൽ rpm പാക്കേജുകളിൽ പ്രവർത്തിക്കുന്നത് പോലെ), അപ്പോൾ ചിത്രം അടിസ്ഥാനപരമായി ഒരു rpm പാക്കേജാണ്. yum install വഴി നമുക്ക് ആപ്ലിക്കേഷൻ ഇൻസ്റ്റാൾ ചെയ്യാനും ഡിലീറ്റ് ചെയ്യാനും റിപ്പോസിറ്ററിയിൽ കണ്ടെത്താനും ഡൗൺലോഡ് ചെയ്യാനും കഴിയും. ഇവിടെയും ഏതാണ്ട് സമാനമാണ്: ചിത്രത്തിൽ നിന്ന് കണ്ടെയ്‌നറുകൾ ലോഞ്ച് ചെയ്‌തിരിക്കുന്നു, അവ ഡോക്കർ രജിസ്‌ട്രിയിൽ സംഭരിച്ചിരിക്കുന്നു (yum-ന് സമാനമായത്, ഒരു ശേഖരത്തിൽ), കൂടാതെ ഓരോ ചിത്രത്തിനും ഒരു SHA-256 ഹാഷും പേരും ഒരു ടാഗും ഉണ്ട്.

ഡോക്കർഫയലിൽ നിന്നുള്ള നിർദ്ദേശങ്ങൾക്കനുസൃതമായാണ് ചിത്രം നിർമ്മിച്ചിരിക്കുന്നത്. Dockerfile-ൽ നിന്നുള്ള ഓരോ നിർദ്ദേശവും ഒരു പുതിയ ലെയർ സൃഷ്ടിക്കുന്നു. പാളികൾ വീണ്ടും ഉപയോഗിക്കാം.

ഡോക്കർ രജിസ്ട്രി ഒരു ഡോക്കർ ഇമേജ് ശേഖരമാണ്. OS-ന് സമാനമായി, ഡോക്കറിന് ഒരു പൊതു സ്റ്റാൻഡേർഡ് രജിസ്ട്രിയുണ്ട് - ഡോക്കർഹബ്. എന്നാൽ നിങ്ങൾക്ക് നിങ്ങളുടെ സ്വന്തം ശേഖരം, നിങ്ങളുടെ സ്വന്തം ഡോക്കർ രജിസ്ട്രി നിർമ്മിക്കാൻ കഴിയും.

കണ്ടെയ്നർ - ചിത്രത്തിൽ നിന്ന് എന്താണ് ആരംഭിച്ചത്. Dockerfile-ൽ നിന്നുള്ള നിർദ്ദേശങ്ങൾക്കനുസൃതമായി ഞങ്ങൾ ഒരു ചിത്രം നിർമ്മിച്ചു, തുടർന്ന് ഈ ചിത്രത്തിൽ നിന്ന് ഞങ്ങൾ അത് സമാരംഭിക്കുന്നു. ഈ കണ്ടെയ്‌നർ മറ്റ് കണ്ടെയ്‌നറുകളിൽ നിന്ന് വേർതിരിച്ചിരിക്കുന്നു, കൂടാതെ ആപ്ലിക്കേഷന്റെ പ്രവർത്തനത്തിന് ആവശ്യമായ എല്ലാം അടങ്ങിയിരിക്കണം. ഈ സാഹചര്യത്തിൽ, ഒരു കണ്ടെയ്നർ - ഒരു പ്രക്രിയ. നിങ്ങൾ രണ്ട് പ്രക്രിയകൾ ചെയ്യേണ്ടതുണ്ട്, പക്ഷേ ഇത് ഡോക്കർ പ്രത്യയശാസ്ത്രത്തിന് വിരുദ്ധമാണ്.

"ഒരു കണ്ടെയ്നർ, ഒരു പ്രക്രിയ" ആവശ്യകത PID നെയിംസ്പേസുമായി ബന്ധപ്പെട്ടതാണ്. നെയിംസ്‌പേസിൽ PID 1 ഉള്ള ഒരു പ്രോസസ്സ് ആരംഭിക്കുമ്പോൾ, അത് പെട്ടെന്ന് മരിക്കുകയാണെങ്കിൽ, മുഴുവൻ കണ്ടെയ്‌നറും മരിക്കും. രണ്ട് പ്രക്രിയകൾ അവിടെ പ്രവർത്തിക്കുന്നുണ്ടെങ്കിൽ: ഒന്ന് ജീവനുള്ളതും മറ്റൊന്ന് മരിച്ചതുമാണ്, പിന്നെ കണ്ടെയ്നർ തുടർന്നും ജീവിക്കും. എന്നാൽ ഇത് മികച്ച സമ്പ്രദായങ്ങളുടെ ഒരു ചോദ്യമാണ്, ഞങ്ങൾ അവയെക്കുറിച്ച് മറ്റ് മെറ്റീരിയലുകളിൽ സംസാരിക്കും.

കോഴ്‌സിന്റെ സവിശേഷതകളും പൂർണ്ണ പ്രോഗ്രാമും കൂടുതൽ വിശദമായി പഠിക്കാൻ, ദയവായി ലിങ്ക് പിന്തുടരുക: "ഡോക്കർ വീഡിയോ കോഴ്സ്".

രചയിതാവ്: മാർസെൽ ഇബ്രേവ്, അംഗീകൃത കുബർനെറ്റസ് അഡ്മിനിസ്ട്രേറ്റർ, സൗത്ത്ബ്രിഡ്ജിലെ പ്രാക്ടീസ് എഞ്ചിനീയർ, സ്ലർം കോഴ്സുകളുടെ സ്പീക്കറും ഡെവലപ്പറും.

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