ഡെലിവറി ടൂളുകളുടെ പരിണാമം അല്ലെങ്കിൽ ഡോക്കർ, ഡെബ്, ജാർ എന്നിവയും മറ്റും സംബന്ധിച്ച ചിന്തകൾ

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

ഏതൊരു ഉൽപ്പന്നവും, അത് എന്തായാലും, എങ്ങനെയെങ്കിലും ഉൽപ്പന്ന സെർവറുകളിൽ എത്തണം, കോൺഫിഗർ ചെയ്യുകയും സമാരംഭിക്കുകയും വേണം. ഈ ലേഖനം അതിനെക്കുറിച്ചായിരിക്കും.

ഒരു ചരിത്ര സന്ദർഭത്തിൽ ഞാൻ ചിന്തിക്കും, "ഞാൻ എന്താണ് പാടുന്നത്, ഞാൻ എന്താണ് പാടുന്നത്," ഞാൻ ആദ്യമായി കോഡ് എഴുതാൻ തുടങ്ങിയപ്പോൾ കണ്ടതും ഇപ്പോൾ ഞാൻ നിരീക്ഷിക്കുന്നതും, നമ്മൾ തന്നെ ഇപ്പോൾ എന്താണ് ഉപയോഗിക്കുന്നത്, എന്തിനാണ്. ലേഖനം ഒരു സമ്പൂർണ്ണ പഠനമാണെന്ന് നടിക്കുന്നില്ല, ചില പോയിന്റുകൾ നഷ്‌ടമായി, ഇത് എന്തായിരുന്നു, ഇപ്പോൾ എന്താണെന്നതിനെക്കുറിച്ചുള്ള എന്റെ വ്യക്തിപരമായ വീക്ഷണമാണ്.

അതുകൊണ്ട്, നല്ല പഴയ കാലത്ത്... ഞാൻ കണ്ടെത്തിയ ആദ്യകാല ഡെലിവറി രീതി ടേപ്പ് റെക്കോർഡറുകളിൽ നിന്നുള്ള കാസറ്റ് ടേപ്പുകൾ ആയിരുന്നു. എനിക്ക് ഒരു കമ്പ്യൂട്ടർ BK-0010.01 ഉണ്ടായിരുന്നു...

കാൽക്കുലേറ്ററുകളുടെ യുഗം

ഇല്ല, അതിലും നേരത്തെ ഒരു നിമിഷം ഉണ്ടായിരുന്നു, ഒരു കാൽക്കുലേറ്ററും ഉണ്ടായിരുന്നു എംകെ-61 и എംകെ-52.

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

അടുത്ത പരിഷ്കാരം ഒരു കാൽക്കുലേറ്ററായിരുന്നു എംകെ-52, ഇതിന് ഇതിനകം തന്നെ അസ്ഥിരമല്ലാത്ത ഡാറ്റ സംഭരണത്തിന്റെ ചില സാമ്യമുണ്ട്. ഇപ്പോൾ ഗെയിമോ പ്രോഗ്രാമോ സ്വമേധയാ നൽകേണ്ടതില്ല, പക്ഷേ ബട്ടണുകൾ ഉപയോഗിച്ച് ചില മാന്ത്രിക പാസുകൾ നടത്തിയ ശേഷം അത് സ്വയം ലോഡ് ചെയ്തു.

കാൽക്കുലേറ്ററിലെ ഏറ്റവും വലിയ പ്രോഗ്രാമിന്റെ വലുപ്പം 105 ഘട്ടങ്ങളായിരുന്നു, കൂടാതെ MK-52 ലെ സ്ഥിരമായ മെമ്മറിയുടെ വലുപ്പം 512 ഘട്ടങ്ങളായിരുന്നു.

വഴിയിൽ, ഈ ലേഖനം വായിക്കുന്ന ഈ കാൽക്കുലേറ്ററുകളുടെ ആരാധകർ ഉണ്ടെങ്കിൽ, ലേഖനം എഴുതുന്ന പ്രക്രിയയിൽ Android- നായുള്ള കാൽക്കുലേറ്റർ എമുലേറ്ററും അതിനുള്ള പ്രോഗ്രാമുകളും ഞാൻ കണ്ടെത്തി. ഭൂതകാലത്തിലേക്ക് മുന്നോട്ട്!

• ആൻഡ്രോയിഡിനുള്ള എമുലേറ്റർ MK-61
• MK-61-നുള്ള പ്രോഗ്രാം കാറ്റലോഗ്

MK-52-നെക്കുറിച്ചുള്ള ഒരു ചെറിയ വ്യതിചലനം (വിക്കിപീഡിയയിൽ നിന്ന്)

സോയൂസ് ടിഎം-52 പേടകത്തിൽ എംകെ-7 ബഹിരാകാശത്തേക്ക് പറന്നു. ഓൺ-ബോർഡ് കമ്പ്യൂട്ടർ പരാജയപ്പെട്ടാൽ ലാൻഡിംഗ് പാത കണക്കാക്കാൻ ഇത് ഉപയോഗിക്കേണ്ടതായിരുന്നു.

52 മുതൽ, നാവിഗേഷൻ കമ്പ്യൂട്ടിംഗ് കിറ്റിന്റെ ഭാഗമായി നാവികസേനയുടെ കപ്പലുകൾക്ക് ഇലക്‌ട്രോണിക്ക-ആസ്ട്രോ മെമ്മറി വിപുലീകരണ യൂണിറ്റുള്ള MK-1988 വിതരണം ചെയ്തുവരുന്നു.

ആദ്യത്തെ പേഴ്സണൽ കമ്പ്യൂട്ടറുകൾ

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

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

വിശ്വസനീയവും വലുതുമായ സ്റ്റോറേജ് മീഡിയയുടെ ഉദയം

പിന്നീട്, ഫ്ലോപ്പി ഡിസ്കുകൾ പ്രത്യക്ഷപ്പെട്ടു, പകർത്തൽ പ്രക്രിയ ലളിതമാക്കി, വിശ്വാസ്യത വർദ്ധിച്ചു.
എന്നാൽ ആവശ്യത്തിന് വലിയ പ്രാദേശിക സംഭരണികൾ HDD-കളുടെ രൂപത്തിൽ ദൃശ്യമാകുമ്പോൾ മാത്രമേ സ്ഥിതിഗതികൾ ഗണ്യമായി മാറുകയുള്ളൂ.

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

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

അക്കാലത്ത്, ലിനക്സിന്റെ അസ്തിത്വം ഇതുവരെ എനിക്ക് തുറന്നിട്ടില്ല; ഞാൻ എംഎസ് ഡോസിന്റെയും പിന്നീട് വിൻഡോസിന്റെയും ലോകത്ത് ജീവിച്ചു, ബോർലാൻഡ് പാസ്കലിലും ഡെൽഫിയിലും എഴുതി, ചിലപ്പോൾ സി ++ ലേക്ക് നോക്കി. അക്കാലത്ത് ഉൽപ്പന്നങ്ങൾ വിതരണം ചെയ്യാൻ പലരും InstallShield ഉപയോഗിച്ചിരുന്നു. ru.wikipedia.org/wiki/InstallShield, സോഫ്റ്റ്‌വെയർ വിന്യസിക്കുന്നതിനും കോൺഫിഗർ ചെയ്യുന്നതിനുമുള്ള എല്ലാ ചുമതലകളും വിജയകരമായി പരിഹരിച്ചു.

ഇന്റർനെറ്റ് യുഗം

ക്രമേണ, സോഫ്റ്റ്വെയർ സിസ്റ്റങ്ങളുടെ സങ്കീർണ്ണത കൂടുതൽ സങ്കീർണ്ണമാവുകയാണ്; മോണോലിത്ത്, ഡെസ്ക്ടോപ്പ് ആപ്ലിക്കേഷനുകളിൽ നിന്ന് വിതരണം ചെയ്ത സിസ്റ്റങ്ങളിലേക്കും നേർത്ത ക്ലയന്റുകളിലേക്കും മൈക്രോസർവീസുകളിലേക്കും ഒരു പരിവർത്തനമുണ്ട്. ഇപ്പോൾ നിങ്ങൾ ഒരു പ്രോഗ്രാം മാത്രമല്ല, അവയുടെ ഒരു കൂട്ടം കോൺഫിഗർ ചെയ്യേണ്ടതുണ്ട്, അങ്ങനെ അവയെല്ലാം ഒരുമിച്ച് പ്രവർത്തിക്കും.

ആശയം പൂർണ്ണമായും മാറി, ഇന്റർനെറ്റ് വന്നു, ക്ലൗഡ് സേവനങ്ങളുടെ യുഗം എത്തി. ഇതുവരെ, പ്രാരംഭ ഘട്ടത്തിൽ, വെബ്‌സൈറ്റുകളുടെ രൂപത്തിൽ, ആരും സേവനങ്ങളെക്കുറിച്ച് പ്രത്യേകിച്ച് സ്വപ്നം കണ്ടിട്ടില്ല. എന്നാൽ ആപ്ലിക്കേഷനുകളുടെ വികസനത്തിലും ഡെലിവറിയിലും ഇത് ഒരു വഴിത്തിരിവായിരുന്നു.

എന്നെ സംബന്ധിച്ചിടത്തോളം, ആ നിമിഷം ഡെവലപ്പർമാരുടെ തലമുറകളിൽ (അല്ലെങ്കിൽ അത് എന്റെ പരിതസ്ഥിതിയിൽ മാത്രമായിരുന്നു) ഒരു മാറ്റമുണ്ടായി എന്ന് ഞാൻ ശ്രദ്ധിച്ചു, കൂടാതെ എല്ലാ നല്ല പഴയ ഡെലിവറി രീതികളും ഒരു നിമിഷത്തിൽ മറന്നുപോയി, എല്ലാം ആരംഭിച്ചത് തുടക്കം: എല്ലാ ഡെലിവറികളും മുട്ട് സ്ക്രിപ്റ്റുകൾ ചെയ്യാൻ തുടങ്ങി, അഭിമാനത്തോടെ അതിനെ "തുടർച്ചയുള്ള ഡെലിവറി" എന്ന് വിളിച്ചു. വാസ്തവത്തിൽ, അരാജകത്വത്തിന്റെ ഒരു കാലഘട്ടം ആരംഭിച്ചു, പഴയത് മറക്കുകയും ഉപയോഗിക്കാതിരിക്കുകയും പുതിയത് നിലനിൽക്കാതിരിക്കുകയും ചെയ്യുന്നു.

ഞാൻ അന്ന് ജോലി ചെയ്തിരുന്ന ഞങ്ങളുടെ കമ്പനിയിൽ (ഞാൻ പേര് പറയുന്നില്ല), ഉറുമ്പ് വഴി പണിയുന്നതിനുപകരം (മാവൻ ഇതുവരെ ജനപ്രിയമായിരുന്നില്ല അല്ലെങ്കിൽ നിലവിലില്ല), ആളുകൾ ഐഡിഇയിൽ ജാറുകൾ ശേഖരിച്ച് ശാന്തമായി പ്രതിജ്ഞാബദ്ധരായ സമയങ്ങൾ ഞാൻ ഓർക്കുന്നു. അത് SVN-ൽ. അതനുസരിച്ച്, SVN-ൽ നിന്ന് ഫയൽ വീണ്ടെടുക്കുകയും SSH വഴി ആവശ്യമുള്ള മെഷീനിലേക്ക് പകർത്തുകയും ചെയ്യുന്നതായിരുന്നു വിന്യാസം. ഇത് വളരെ ലളിതവും വിചിത്രവുമാണ്.

അതേ സമയം, PHP-യിലെ ലളിതമായ സൈറ്റുകളുടെ ഡെലിവറി വളരെ പ്രാകൃതമായ രീതിയിൽ FTP വഴി ടാർഗെറ്റ് മെഷീനിലേക്ക് പകർത്തി. ചിലപ്പോൾ ഇത് അങ്ങനെയായിരുന്നില്ല - ഉൽപ്പന്ന സെർവറിൽ കോഡ് തത്സമയം എഡിറ്റുചെയ്‌തു, എവിടെയെങ്കിലും ബാക്കപ്പുകൾ ഉണ്ടെങ്കിൽ അത് വളരെ ചിക് ആയിരുന്നു.

RPM, DEB പാക്കേജുകൾ

മറുവശത്ത്, ഇന്റർനെറ്റിന്റെ വികാസത്തോടെ, UNIX പോലുള്ള സിസ്റ്റങ്ങൾ കൂടുതൽ കൂടുതൽ ജനപ്രീതി നേടാൻ തുടങ്ങി, പ്രത്യേകിച്ചും, ആ സമയത്താണ് ഞാൻ ഏകദേശം 6-ൽ RedHat Linux 2000 കണ്ടെത്തിയത്. സ്വാഭാവികമായും, സോഫ്‌റ്റ്‌വെയർ വിതരണം ചെയ്യുന്നതിനുള്ള ചില മാർഗങ്ങളും ഉണ്ടായിരുന്നു; വിക്കിപീഡിയയുടെ അഭിപ്രായത്തിൽ, പ്രധാന പാക്കേജ് മാനേജറായി RPM 1995-ൽ RedHat Linux 2.0-ന്റെ പതിപ്പിൽ പ്രത്യക്ഷപ്പെട്ടു. അന്നുമുതൽ ഇന്നുവരെ, സിസ്റ്റം ആർ‌പി‌എം പാക്കേജുകളുടെ രൂപത്തിലാണ് വിതരണം ചെയ്യുന്നത്, അത് വിജയകരമായി നിലനിൽക്കുകയും വികസിക്കുകയും ചെയ്യുന്നു.

ഡെബിയൻ കുടുംബത്തിന്റെ വിതരണവും സമാനമായ പാത പിന്തുടരുകയും ഡെബ് പാക്കേജുകളുടെ രൂപത്തിൽ ഡെലിവറി നടപ്പിലാക്കുകയും ചെയ്തു, അത് ഇന്നും മാറ്റമില്ലാതെ തുടരുന്നു.

സോഫ്‌റ്റ്‌വെയർ ഉൽപ്പന്നങ്ങൾ സ്വയം ഡെലിവറി ചെയ്യാനും, ഇൻസ്റ്റലേഷൻ പ്രക്രിയയിൽ കോൺഫിഗർ ചെയ്യാനും, വ്യത്യസ്ത പാക്കേജുകൾക്കിടയിലുള്ള ഡിപൻഡൻസികൾ നിയന്ത്രിക്കാനും, അൺഇൻസ്റ്റാളേഷൻ പ്രക്രിയയിൽ ഉൽപ്പന്നങ്ങൾ നീക്കം ചെയ്യാനും, അനാവശ്യമായ ഇനങ്ങൾ വൃത്തിയാക്കാനും പാക്കേജ് മാനേജർമാർ നിങ്ങളെ അനുവദിക്കുന്നു. ആ. മിക്കവാറും, അത്രമാത്രം ആവശ്യമാണ്, അതുകൊണ്ടാണ് അവ ഫലത്തിൽ മാറ്റമില്ലാതെ ദശാബ്ദങ്ങളോളം നീണ്ടുനിന്നത്.

ക്ലൗഡ് കമ്പ്യൂട്ടിംഗ് പാക്കേജ് മാനേജർമാർക്ക് ഫിസിക്കൽ മീഡിയയിൽ നിന്ന് മാത്രമല്ല, ക്ലൗഡ് റിപ്പോസിറ്ററികളിൽ നിന്നും ഇൻസ്റ്റലേഷൻ ചേർത്തിട്ടുണ്ട്, എന്നാൽ അടിസ്ഥാനപരമായി ചെറിയ മാറ്റങ്ങളൊന്നും സംഭവിച്ചിട്ടില്ല.

നിലവിൽ ഡെബിൽ നിന്ന് മാറി സ്നാപ്പ് പാക്കേജുകളിലേക്ക് മാറുന്നതിലേക്ക് ചില നീക്കങ്ങൾ നടക്കുന്നുണ്ട് എന്നത് ശ്രദ്ധിക്കേണ്ടതാണ്, എന്നാൽ പിന്നീട് അതിനെക്കുറിച്ച് കൂടുതൽ.

അതിനാൽ, DEB അല്ലെങ്കിൽ RPM എന്നിവയൊന്നും അറിയാത്ത ഈ പുതിയ തലമുറ ക്ലൗഡ് ഡെവലപ്പർമാരും സാവധാനം വളർന്നു, അനുഭവം നേടി, ഉൽപ്പന്നങ്ങൾ കൂടുതൽ സങ്കീർണ്ണമായി, കൂടാതെ FTP, ബാഷ് സ്ക്രിപ്റ്റുകൾ, സമാനമായ വിദ്യാർത്ഥി കരകൌശലങ്ങൾ എന്നിവയേക്കാൾ കൂടുതൽ ന്യായമായ ഡെലിവറി രീതികൾ ആവശ്യമാണ്.
ഇവിടെയാണ് ഡോക്കർ ചിത്രത്തിലേക്ക് വരുന്നത്, വെർച്വലൈസേഷൻ, റിസോഴ്സ് ഡിലിമിറ്റേഷൻ, ഡെലിവറി രീതി എന്നിവയുടെ ഒരുതരം മിശ്രിതം. ഇത് ഇപ്പോൾ ഫാഷനും യുവത്വവുമാണ്, എന്നാൽ എല്ലാത്തിനും ഇത് ആവശ്യമാണോ? ഇതൊരു സമാന്തര രോഗമാണോ?

എന്റെ നിരീക്ഷണങ്ങളിൽ നിന്ന്, പലപ്പോഴും ഡോക്കർ നിർദ്ദേശിക്കുന്നത് ന്യായമായ ഒരു തിരഞ്ഞെടുപ്പായിട്ടല്ല, മറിച്ച്, ഒരു വശത്ത്, അത് സമൂഹത്തിൽ സംസാരിക്കപ്പെടുന്നതിനാലും അത് നിർദ്ദേശിക്കുന്നവർക്ക് മാത്രമേ അത് അറിയൂ എന്നതിനാലുമാണ്. മറുവശത്ത്, മിക്കപ്പോഴും അവർ പഴയ നല്ല പാക്കേജിംഗ് സംവിധാനങ്ങളെക്കുറിച്ച് നിശബ്ദരാണ് - അവ നിലവിലുണ്ട്, അവരുടെ ജോലി നിശബ്ദമായും ശ്രദ്ധിക്കപ്പെടാതെയും ചെയ്യുന്നു. അത്തരമൊരു സാഹചര്യത്തിൽ, മറ്റൊരു തിരഞ്ഞെടുപ്പും ഇല്ല - ചോയ്സ് വ്യക്തമാണ് - ഡോക്കർ.

ഞങ്ങൾ എങ്ങനെയാണ് ഡോക്കർ നടപ്പിലാക്കിയതെന്നും അതിന്റെ ഫലമായി എന്ത് സംഭവിച്ചുവെന്നും എന്റെ അനുഭവം പങ്കിടാൻ ഞാൻ ശ്രമിക്കും.

സ്വയം എഴുതിയ സ്ക്രിപ്റ്റുകൾ

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

എന്നാൽ സ്ക്രിപ്റ്റുകൾക്ക് നിരവധി ദോഷങ്ങളുണ്ട്:

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

തീർച്ചയായും, നിങ്ങൾക്ക് ഒരു സങ്കീർണ്ണമായ സ്ക്രിപ്റ്റ് എഴുതാൻ കഴിയും, പക്ഷേ, ഞാൻ മുകളിൽ എഴുതിയതുപോലെ, ഇത് വികസന സമയമാണ്, ഏറ്റവും കുറവല്ല, നമുക്കറിയാവുന്നതുപോലെ, എല്ലായ്പ്പോഴും മതിയായ സമയമില്ല.

ഇതെല്ലാം ഈ വിന്യാസ രീതിയുടെ പ്രയോഗത്തിന്റെ പരിധി ഏറ്റവും ലളിതമായ സിസ്റ്റങ്ങളിലേക്ക് മാത്രം പരിമിതപ്പെടുത്തുന്നു. ഇത് മാറ്റേണ്ട സമയം അതിക്രമിച്ചിരിക്കുന്നു.

ഡോക്കർ

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

എന്ത് അസൗകര്യങ്ങളാണ് ഞങ്ങൾ നേരിട്ടത്?

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

മറുവശത്ത്, അതേ ഡെബ് വഴി ഒരു ജാർ ആർക്കൈവിന്റെ രൂപത്തിൽ ഒരു സ്പ്രിംഗ് സേവനം വിന്യസിക്കുന്നത് മോശമായിരിക്കുന്നത് എന്തുകൊണ്ട്? റിസോഴ്സ് ഐസൊലേഷൻ ശരിക്കും ആവശ്യമാണോ? വളരെ കുറഞ്ഞ ഒരു കണ്ടെയ്‌നറിലേക്ക് ഒരു സേവനം നിറച്ചുകൊണ്ട് സൗകര്യപ്രദമായ ഓപ്പറേറ്റിംഗ് സിസ്റ്റം ടൂളുകൾ നഷ്‌ടപ്പെടുത്തുന്നത് മൂല്യവത്താണോ?

പ്രാക്ടീസ് കാണിച്ചിരിക്കുന്നതുപോലെ, വാസ്തവത്തിൽ ഇത് ആവശ്യമില്ല, 90% കേസുകളിലും ഡെബ് പാക്കേജ് മതിയാകും.

എപ്പോഴാണ് നല്ല പഴയ ഡെബ് പരാജയപ്പെടുന്നത്, എപ്പോഴാണ് നമുക്ക് ശരിക്കും ഡോക്കർ ആവശ്യമുള്ളത്?

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

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

സ്നാപ്പ് പാക്കേജുകൾ

നമുക്ക് സ്നാപ്പ് പാക്കേജുകളിലേക്ക് മടങ്ങാം. അവർ ആദ്യം ഔദ്യോഗികമായി പ്രത്യക്ഷപ്പെട്ടത് ഉബുണ്ടു 16.04 ലാണ്. സാധാരണ deb പാക്കേജുകളിൽ നിന്നും rpm പാക്കേജുകളിൽ നിന്നും വ്യത്യസ്തമായി, സ്നാപ്പ് എല്ലാ ഡിപൻഡൻസികളും വഹിക്കുന്നു. ഒരു വശത്ത്, ലൈബ്രറി വൈരുദ്ധ്യങ്ങൾ ഒഴിവാക്കാൻ ഇത് നിങ്ങളെ അനുവദിക്കുന്നു, മറുവശത്ത്, തത്ഫലമായുണ്ടാകുന്ന പാക്കേജ് വലുപ്പത്തിൽ വലുതാണ്. കൂടാതെ, ഇത് സിസ്റ്റത്തിന്റെ സുരക്ഷയെയും ബാധിക്കും: സ്നാപ്പ് ഡെലിവറിയുടെ കാര്യത്തിൽ, ഉൾപ്പെടുത്തിയ ലൈബ്രറികളിലെ എല്ലാ മാറ്റങ്ങളും പാക്കേജ് സൃഷ്ടിക്കുന്ന ഡവലപ്പർ നിരീക്ഷിക്കണം. പൊതുവേ, എല്ലാം വളരെ ലളിതമല്ല, സാർവത്രിക സന്തോഷം അവ ഉപയോഗിക്കുന്നതിൽ നിന്ന് വരുന്നില്ല. എന്നിരുന്നാലും, അതേ ഡോക്കർ ഒരു പാക്കേജിംഗ് ഉപകരണമായി മാത്രമേ ഉപയോഗിക്കുന്നുള്ളൂ, വിർച്ച്വലൈസേഷനായി ഉപയോഗിക്കുന്നില്ലെങ്കിൽ ഇത് തികച്ചും ന്യായമായ ഒരു ബദലാണ്.

തൽഫലമായി, ഞങ്ങൾ ഇപ്പോൾ deb പാക്കേജുകളും ഡോക്കർ കണ്ടെയ്‌നറുകളും ഒരു ന്യായമായ സംയോജനത്തിൽ ഉപയോഗിക്കുന്നു, ഒരുപക്ഷേ, ചില സന്ദർഭങ്ങളിൽ ഞങ്ങൾ സ്‌നാപ്പ് പാക്കേജുകൾ ഉപയോഗിച്ച് മാറ്റിസ്ഥാപിക്കും.

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

ഡെലിവറിക്ക് നിങ്ങൾ എന്താണ് ഉപയോഗിക്കുന്നത്?

• സ്വയം എഴുതിയ സ്ക്രിപ്റ്റുകൾ

• FTP-യിലേക്ക് സ്വമേധയാ പകർത്തുക

• deb പാക്കേജുകൾ

• rpm പാക്കേജുകൾ

• സ്നാപ്പ് പാക്കേജുകൾ

• ഡോക്കർ ചിത്രങ്ങൾ

• വെർച്വൽ മെഷീൻ ഇമേജുകൾ

• മുഴുവൻ എച്ച്ഡിഡിയും ക്ലോൺ ചെയ്യുക

• പാവാട

• ഉത്തരം

• മറ്റുള്ളവ

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

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