ഡോക്കർ ഒരു കളിപ്പാട്ടമാണോ അല്ലയോ? അതോ ഇപ്പോഴും സത്യമാണോ?

ഹലോ എല്ലാവർക്കും!

എനിക്ക് നേരിട്ട് വിഷയത്തിലേക്ക് കടക്കാൻ ആഗ്രഹമുണ്ട്, പക്ഷേ എന്റെ കഥയെക്കുറിച്ച് കുറച്ച് പറയുന്നത് കൂടുതൽ ശരിയാണ്:

എൻട്രി

സെർവറിൽ ഫ്രണ്ട്‌എൻഡ് സിംഗിൾ പേജ് ആപ്ലിക്കേഷനുകൾ, സ്‌കാല/ജാവ, നോഡ്‌ജുകൾ എന്നിവ വികസിപ്പിക്കുന്നതിൽ പരിചയമുള്ള ഒരു പ്രോഗ്രാമറാണ് ഞാൻ.

വളരെക്കാലമായി (തീർച്ചയായും ഒന്നോ മൂന്നോ വർഷം), ഡോക്കർ സ്വർഗത്തിൽ നിന്നുള്ള മന്നയാണെന്നും പൊതുവെ വളരെ രസകരമായ ഒരു ഉപകരണമാണെന്നും എല്ലാ ഡെവലപ്പർമാർക്കും ഇത് ഉപയോഗിക്കാൻ കഴിയണമെന്നും ഞാൻ അഭിപ്രായപ്പെട്ടിരുന്നു. ഓരോ ഡവലപ്പർക്കും അവരുടെ ലോക്കൽ മെഷീനിൽ ഡോക്കർ ഇൻസ്റ്റാൾ ചെയ്തിരിക്കണമെന്ന് ഇതിൽ നിന്ന് പിന്തുടരുന്നു. എന്താണ് എന്റെ അഭിപ്രായം, അതേ hh-ൽ പോസ്റ്റ് ചെയ്യുന്ന ഒഴിവുകൾ നോക്കുക. ഓരോ സെക്കൻഡിലും ഡോക്കറെക്കുറിച്ചുള്ള പരാമർശം അടങ്ങിയിരിക്കുന്നു, നിങ്ങളത് സ്വന്തമാക്കിയാൽ, ഇത് നിങ്ങളുടെ മത്സര നേട്ടമായിരിക്കും 😉

എന്റെ വഴിയിൽ, ഡോക്കറിനോടും അതിന്റെ ആവാസവ്യവസ്ഥയോടും വ്യത്യസ്തമായ മനോഭാവമുള്ള നിരവധി ആളുകളെ ഞാൻ കണ്ടുമുട്ടി. ക്രോസ്-പ്ലാറ്റ്ഫോം പ്രവർത്തനം ഉറപ്പുനൽകുന്ന സൗകര്യപ്രദമായ കാര്യമാണിതെന്ന് ചിലർ പറഞ്ഞു. രണ്ടാമത്തെയാൾക്ക് അവർ എന്തിനാണ് കണ്ടെയ്‌നറുകളിൽ ഓടേണ്ടതെന്നും അതിൽ നിന്ന് എന്ത് ലാഭം വരുമെന്നും മനസ്സിലായില്ല, മൂന്നാമൻ അതൊന്നും കാര്യമാക്കിയില്ല, വിഷമിച്ചില്ല (അവർ കോഡ് എഴുതി വീട്ടിലേക്ക് പോയി - എനിക്ക് അവരോട് അസൂയ തോന്നുന്നു, വഴി :)

ഉപയോഗത്തിനുള്ള കാരണങ്ങൾ

എന്തുകൊണ്ടാണ് ഞാൻ ഡോക്കർ ഉപയോഗിച്ചത്? ഒരുപക്ഷേ ഇനിപ്പറയുന്ന കാരണങ്ങളാൽ:

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

ഡോക്കറിനെക്കുറിച്ച് എനിക്ക് എപ്പോഴും ഇഷ്ടപ്പെടാത്തത്:

• എന്റെ ആപ്ലിക്കേഷൻ പ്രവർത്തിക്കുന്നതിന്, എനിക്ക് സെർവറിൽ തന്നെ ഡോക്കർ ആവശ്യമാണ്. എന്റെ ആപ്ലിക്കേഷനുകൾ jre അല്ലെങ്കിൽ nodej-കളിൽ പ്രവർത്തിക്കുകയും അവയ്‌ക്കുള്ള പരിസ്ഥിതി ഇതിനകം സെർവറിൽ ആണെങ്കിൽ എനിക്ക് ഇത് ആവശ്യമായി വരുന്നത് എന്തുകൊണ്ട്?
• ഒരു റിമോട്ട് സെർവറിൽ പ്രാദേശികമായി നിർമ്മിച്ച എന്റെ (സ്വകാര്യ) ഇമേജ് പ്രവർത്തിപ്പിക്കണമെങ്കിൽ, എനിക്ക് എന്റെ സ്വന്തം ഡോക്കർ ശേഖരണം ആവശ്യമാണ്, എവിടെയെങ്കിലും പ്രവർത്തിക്കാൻ എനിക്ക് രജിസ്ട്രി ആവശ്യമാണ്, കൂടാതെ എനിക്ക് https കോൺഫിഗർ ചെയ്യേണ്ടതുണ്ട്, കാരണം ഡോക്കർ ക്ലൈ https വഴി മാത്രമേ പ്രവർത്തിക്കൂ. നാശം... ചിത്രം പ്രാദേശികമായി സേവ് ചെയ്യാനുള്ള ഓപ്ഷനുകളുണ്ട് docker save കൂടാതെ ചിത്രം scp വഴി അയയ്‌ക്കുക... പക്ഷേ അത് ഒരുപാട് ശരീര ചലനങ്ങളാണ്. കൂടാതെ, നിങ്ങളുടെ സ്വന്തം ശേഖരം ദൃശ്യമാകുന്നതുവരെ ഇത് ഒരു "ക്രച്ച്" പരിഹാരം പോലെ കാണപ്പെടുന്നു
• docker-compose. കണ്ടെയ്നറുകൾ പ്രവർത്തിപ്പിക്കാൻ മാത്രമേ ഇത് ആവശ്യമുള്ളൂ. അത്രയേയുള്ളൂ. അയാൾക്ക് മറ്റൊന്നും ചെയ്യാൻ കഴിയില്ല. Docker-compose അതിന്റെ ഫയലുകളുടെ ഒരു കൂട്ടം പതിപ്പുകൾ ഉണ്ട്, സ്വന്തം വാക്യഘടന. അത് എത്ര ഡിക്ലറേറ്റീവ് ആയാലും അവരുടെ ഡോക്യുമെന്റേഷൻ വായിക്കാൻ ഞാൻ ആഗ്രഹിക്കുന്നില്ല. എനിക്ക് അത് മറ്റെവിടെയും ആവശ്യമില്ല.
• ഒരു ടീമിൽ പ്രവർത്തിക്കുമ്പോൾ, മിക്ക ആളുകളും ഒരു ഡോക്കർഫയൽ വളരെ വളച്ചൊടിച്ച് എഴുതുന്നു, അത് എങ്ങനെ കാഷെ ചെയ്യുന്നുവെന്ന് മനസ്സിലാകുന്നില്ല, അവർക്ക് ആവശ്യമുള്ളതും ആവശ്യമില്ലാത്തതുമായ എല്ലാം ചിത്രത്തിലേക്ക് ചേർക്കുക, ഡോക്കർഹബ്ബിലോ സ്വകാര്യ ശേഖരത്തിലോ ഇല്ലാത്ത ചിത്രങ്ങളിൽ നിന്ന് അവകാശം നേടുക, ചിലത് സൃഷ്ടിക്കുക docker-compose ഡാറ്റാബേസുകളുള്ള ഫയലുകൾ, ഒന്നും നിലനിൽക്കുന്നില്ല. അതേ സമയം, ഡവലപ്പർമാർ അഭിമാനത്തോടെ ഡോക്കർ ശാന്തനാണെന്നും എല്ലാം അവർക്ക് പ്രാദേശികമായി പ്രവർത്തിക്കുന്നുവെന്നും പ്രഖ്യാപിക്കുന്നു, കൂടാതെ എച്ച്ആർ പ്രധാനമായും ഒഴിവുകളിൽ എഴുതുന്നു: "ഞങ്ങൾ ഡോക്കർ ഉപയോഗിക്കുന്നു, അത്തരം പ്രവൃത്തി പരിചയമുള്ള ഒരു സ്ഥാനാർത്ഥിയെ ഞങ്ങൾക്ക് ആവശ്യമുണ്ട്."
• ഡോക്കറിൽ എല്ലാം ഉയർത്തുന്നതിനെക്കുറിച്ചുള്ള ചിന്തകൾ എന്നെ നിരന്തരം വേട്ടയാടുന്നു: postgresql, kafka, redis. എല്ലാം കണ്ടെയ്നറുകളിൽ പ്രവർത്തിക്കുന്നില്ല എന്നത് ഒരു ദയനീയമാണ്, എല്ലാം ക്രമീകരിക്കാനും പ്രവർത്തിപ്പിക്കാനും എളുപ്പമല്ല. ഇത് മൂന്നാം കക്ഷി ഡെവലപ്പർമാർ പിന്തുണയ്ക്കുന്നു, അല്ലാതെ വെണ്ടർമാരല്ല. വഴിയിൽ, ചോദ്യം ഉടനടി ഉയർന്നുവരുന്നു: വെണ്ടർമാർ അവരുടെ ഉൽപ്പന്നങ്ങൾ ഡോക്കറിൽ പരിപാലിക്കുന്നതിനെക്കുറിച്ച് വിഷമിക്കേണ്ടതില്ല, എന്തുകൊണ്ടാണ് ഇത്, ഒരുപക്ഷേ അവർക്ക് എന്തെങ്കിലും അറിയാമോ?
• കണ്ടെയ്നർ ഡാറ്റയുടെ സ്ഥിരതയെക്കുറിച്ചുള്ള ചോദ്യം എപ്പോഴും ഉയർന്നുവരുന്നു. എന്നിട്ട് നിങ്ങൾ കരുതുന്നു, ഞാൻ ഹോസ്റ്റ് ഡയറക്‌ടറി മൌണ്ട് ചെയ്യണോ അതോ ഒരു ഡോക്കർ വോളിയം സൃഷ്‌ടിക്കണോ അതോ ഇപ്പോൾ ഉള്ള ഒരു ഡാറ്റ കണ്ടെയ്‌നർ ഉണ്ടാക്കണോ deprecated? ഞാൻ ഒരു ഡയറക്‌ടറി മൌണ്ട് ചെയ്യുകയാണെങ്കിൽ, കണ്ടെയ്‌നറിലെ ഉപയോക്താവിന്റെ uid ഉം gid ഉം കണ്ടെയ്‌നർ സമാരംഭിച്ച ഉപയോക്താവിന്റെ ഐഡിയുമായി പൊരുത്തപ്പെടുന്നുണ്ടെന്ന് ഞാൻ ഉറപ്പാക്കേണ്ടതുണ്ട്, അല്ലാത്തപക്ഷം കണ്ടെയ്‌നർ സൃഷ്‌ടിച്ച ഫയലുകൾ റൂട്ട് അവകാശങ്ങളോടെ സൃഷ്‌ടിക്കും. ഞാൻ ഉപയോഗിക്കുകയാണെങ്കിൽ volume അപ്പോൾ ഡാറ്റ ചിലതിൽ സൃഷ്ടിക്കപ്പെടും /usr/* കൂടാതെ uid-ഉം gid-ഉം ഉള്ള അതേ കഥ ആദ്യ കേസിലെ പോലെ തന്നെ ആയിരിക്കും. നിങ്ങൾ ഒരു മൂന്നാം കക്ഷി ഘടകം സമാരംഭിക്കുകയാണെങ്കിൽ, നിങ്ങൾ ഡോക്യുമെന്റേഷൻ വായിക്കുകയും ചോദ്യത്തിനുള്ള ഉത്തരം തേടുകയും വേണം: "ഏത് കണ്ടെയ്നർ ഡയറക്ടറികളിലാണ് ഘടകം ഫയലുകൾ എഴുതുന്നത്?"

എനിക്ക് ഡോക്കറുമായി കൂടുതൽ നേരം സംസാരിക്കേണ്ടി വന്നത് എനിക്ക് എല്ലായ്പ്പോഴും ഇഷ്ടപ്പെട്ടിരുന്നില്ല പ്രാരംഭ ഘട്ടത്തിൽ: കണ്ടെയ്‌നറുകൾ എങ്ങനെ സമാരംഭിക്കണം, ഏതൊക്കെ ചിത്രങ്ങളിൽ നിന്നാണ് ലോഞ്ച് ചെയ്യേണ്ടത്, ദൈർഘ്യമേറിയ ഡോക്കർ കമാൻഡുകളുടെ അപരനാമങ്ങൾ അടങ്ങിയ മേക്ക്ഫയലുകൾ ഉണ്ടാക്കി. ഡോക്കർ ഇക്കോസിസ്റ്റത്തിൽ മറ്റൊരു ഉപകരണം പഠിക്കാൻ ആഗ്രഹിക്കാത്തതിനാൽ ഞാൻ ഡോക്കർ-കമ്പോസിനെ വെറുത്തു. ഒപ്പം docker-compose up അത് എന്നെ വിഷമിപ്പിച്ചു, പ്രത്യേകിച്ചും അവർ അവിടെ കണ്ടുമുട്ടിയാൽ build ഇതിനകം കൂട്ടിച്ചേർത്ത ചിത്രങ്ങളേക്കാൾ നിർമ്മാണങ്ങൾ. ഞാൻ ശരിക്കും ആഗ്രഹിച്ചത് ഒരു ഉൽപ്പന്നം കാര്യക്ഷമമായും വേഗത്തിലും നിർമ്മിക്കുക എന്നതായിരുന്നു. എന്നാൽ ഡോക്കർ എങ്ങനെ ഉപയോഗിക്കണമെന്ന് എനിക്ക് കണ്ടുപിടിക്കാൻ കഴിഞ്ഞില്ല.

അൻസിബിളിനെ പരിചയപ്പെടുത്തുന്നു

അടുത്തിടെ (മൂന്ന് മാസം മുമ്പ്), ഞാൻ ഒരു DevOps ടീമിനൊപ്പം പ്രവർത്തിച്ചു, അതിൽ മിക്കവാറും എല്ലാ അംഗങ്ങൾക്കും ഡോക്കറിനോട് നിഷേധാത്മക മനോഭാവമുണ്ടായിരുന്നു. കാരണങ്ങളാൽ:

• ഡോക്കർ iptables റൂൾസ് (നിങ്ങൾക്ക് ഇത് daemon.json-ൽ പ്രവർത്തനരഹിതമാക്കാമെങ്കിലും)
• ഡോക്കർ ബഗ്ഗിയാണ്, ഞങ്ങൾ അത് ഉൽപ്പാദനത്തിൽ പ്രവർത്തിപ്പിക്കില്ല
• ഡോക്കർ ഡെമൺ തകരാറിലായാൽ, അടിസ്ഥാന സൗകര്യങ്ങളുള്ള എല്ലാ കണ്ടെയ്‌നറുകളും അതിനനുസരിച്ച് തകരുന്നു
• ഡോക്കറുടെ ആവശ്യമില്ല
• അൻസിബിൾ, വെർച്വൽ മെഷീനുകൾ ഉണ്ടെങ്കിൽ എന്തുകൊണ്ട് ഡോക്കർ

അതേ ജോലിയിൽ, ഞാൻ മറ്റൊരു ഉപകരണവുമായി പരിചയപ്പെട്ടു - അൻസിബിൾ. ഒരിക്കൽ ഞാൻ അതിനെക്കുറിച്ച് കേട്ടിട്ടുണ്ട്, പക്ഷേ എന്റെ സ്വന്തം പ്ലേബുക്കുകൾ എഴുതാൻ ഞാൻ ശ്രമിച്ചില്ല. ഇപ്പോൾ ഞാൻ എന്റെ ജോലികൾ എഴുതാൻ തുടങ്ങി, തുടർന്ന് എന്റെ കാഴ്ചപ്പാട് പൂർണ്ണമായും മാറി! കാരണം ഞാൻ മനസ്സിലാക്കി: ഒരേ ഡോക്കർ കണ്ടെയ്‌നറുകൾ, ഇമേജ് ബിൽഡുകൾ, നെറ്റ്‌വർക്കുകൾ മുതലായവ പ്രവർത്തിപ്പിക്കുന്നതിനുള്ള മൊഡ്യൂളുകൾ അൻസിബിളിലുണ്ട്, കൂടാതെ കണ്ടെയ്‌നറുകൾ പ്രാദേശികമായി മാത്രമല്ല, വിദൂര സെർവറുകളിലും പ്രവർത്തിപ്പിക്കാൻ കഴിയും! എന്റെ ആഹ്ലാദത്തിന് അതിരുകളില്ലായിരുന്നു - ഞാൻ ഒരു സാധാരണ ഉപകരണം കണ്ടെത്തി, എന്റെ മേക്ക്ഫയലും ഡോക്കർ-കംപോസ് ഫയലുകളും വലിച്ചെറിഞ്ഞു, അവയ്ക്ക് പകരം yaml ടാസ്‌ക്കുകൾ നൽകി. പോലുള്ള നിർമ്മാണങ്ങൾ ഉപയോഗിച്ചാണ് കോഡ് കുറച്ചത് loop, when, തുടങ്ങിയവ.

ഡാറ്റാബേസുകൾ പോലുള്ള മൂന്നാം കക്ഷി ഘടകങ്ങൾ പ്രവർത്തിപ്പിക്കുന്നതിനുള്ള ഡോക്കർ

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

ഈ കമാൻഡ് postgresql പ്രവർത്തിക്കുന്ന ഒരു റിമോട്ട് സെർവറിലേക്ക് എന്റെ ലോക്കൽ പോർട്ട് കൈമാറുന്നു:

ssh -L 9000:localhost:5432 [ഇമെയിൽ പരിരക്ഷിച്ചിരിക്കുന്നു]

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

SSH ടണലുകൾ ഒരു സാധാരണ VPN-ന്റെ പരിമിതമായ പ്രവർത്തനമാണെന്ന് ഞാൻ അടുത്തിടെ വായിച്ചു! നിങ്ങൾക്ക് ഓപ്പൺവിപിഎൻ അല്ലെങ്കിൽ മറ്റ് വിപിഎൻ നടപ്പാക്കലുകൾ ഇൻസ്റ്റാൾ ചെയ്യാനും ഇൻഫ്രാസ്ട്രക്ചർ സജ്ജീകരിക്കാനും ഡവലപ്പർമാർക്ക് ഉപയോഗിക്കാനും കഴിയും. ഇത് അടിപൊളിയാണ്!

ഭാഗ്യവശാൽ, AWS, GoogleCloud എന്നിവയും മറ്റും നിങ്ങൾക്ക് ഒരു വർഷത്തെ സൗജന്യ ഉപയോഗം നൽകുന്നു, അതിനാൽ അവ ഉപയോഗിക്കുക! ഉപയോഗത്തിലില്ലാത്തപ്പോൾ നിങ്ങൾ അവ ഓഫാക്കിയാൽ അവ വിലകുറഞ്ഞതാണ്. എനിക്ക് എന്തിനാണ് gcloud പോലുള്ള ഒരു റിമോട്ട് സെർവർ ആവശ്യമായി വരുന്നത് എന്ന് ഞാൻ എപ്പോഴും ചിന്തിച്ചിരുന്നു, ഞാൻ അവ കണ്ടെത്തിയതായി തോന്നുന്നു.

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

ചുവടെയുള്ള വരി: നിങ്ങൾക്ക് റിമോട്ട് സെർവറുകളിലോ വെർച്വൽബോക്സിലോ ഡാറ്റാബേസുകളും മറ്റ് ഇൻഫ്രാസ്ട്രക്ചർ ഗുഡികളും പ്രവർത്തിപ്പിക്കാനും പ്രവർത്തിക്കാനും കഴിയും. ഈ ആവശ്യങ്ങൾക്ക് എനിക്ക് ഡോക്കർ ആവശ്യമില്ല.

ഡോക്കർ ചിത്രങ്ങളെയും വിതരണത്തെയും കുറിച്ച് അൽപ്പം

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

സോഫ്റ്റ്‌വെയർ ഡെവലപ്പർമാർ അവരുടെ ഉൽപ്പന്നങ്ങൾ ഒരു ഡോക്കർ ഇമേജിൽ മാത്രം പോർട്ട് ചെയ്യുന്നത് നിങ്ങൾ എവിടെയെങ്കിലും കണ്ടിട്ടുണ്ടോ?
മിക്ക ഉൽപ്പന്നങ്ങളുടെയും ഫലം ഒരു നിർദ്ദിഷ്ട പ്ലാറ്റ്‌ഫോമിനുള്ള ബൈനറി ഫയലുകളാണ്; അവ ആവശ്യമുള്ള പ്ലാറ്റ്‌ഫോമിൽ നിന്ന് പാരമ്പര്യമായി ലഭിച്ച ഡോക്കർ ഇമേജിലേക്ക് ചേർക്കുന്നു. ഡോക്കർഹബിൽ സമാനമായ നിരവധി ചിത്രങ്ങൾ ഉള്ളത് എന്തുകൊണ്ടാണെന്ന് നിങ്ങൾ എപ്പോഴെങ്കിലും ചിന്തിച്ചിട്ടുണ്ടോ? ഉദാഹരണത്തിന് nginx നൽകുക, വ്യത്യസ്ത ആളുകളിൽ നിന്നുള്ള 100500 ചിത്രങ്ങൾ നിങ്ങൾ കാണും. ഈ ആളുകൾ nginx സ്വയം വികസിപ്പിച്ചെടുത്തില്ല, അവർ അവരുടെ ഡോക്കർ ഇമേജിലേക്ക് ഔദ്യോഗിക nginx ചേർക്കുകയും കണ്ടെയ്നറുകൾ ലോഞ്ച് ചെയ്യുന്നതിനുള്ള സൗകര്യത്തിനായി അവരുടെ സ്വന്തം കോൺഫിഗറുകളിൽ അത് സീസൺ ചെയ്യുകയും ചെയ്തു.

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

ചുവടെയുള്ള വരി: എനിക്ക് ഡോക്കർ രജിസ്ട്രി ആവശ്യമില്ല, ഞാൻ ഏതെങ്കിലും തരത്തിലുള്ള S3 അല്ലെങ്കിൽ ഗൂഗിൾ ഡ്രൈവ്/ഡ്രോപ്പ്ബോക്സ് പോലുള്ള ഫയൽ സ്റ്റോറേജ് ഉപയോഗിക്കും

സിഐയിലെ ഡോക്കർ

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

CI പ്രോസസ്സ് പ്രവർത്തിക്കുന്ന സെർവറുകളിൽ ഈ കമ്പനികൾ ഡോക്കർ ഉപയോഗിക്കുന്നു. ചോദ്യം: നിങ്ങളുടെ സെർവറുകളിൽ ഒരു ഡോക്കർ കണ്ടെയ്‌നറിൽ പ്രോജക്‌റ്റുകൾ നിർമ്മിക്കേണ്ടത് എന്തുകൊണ്ട്? എന്തുകൊണ്ട് ബിൽഡിനായി ഒരു അന്തരീക്ഷം തയ്യാറാക്കിക്കൂടാ, ഉദാഹരണത്തിന്, ബിൽഡ് നടക്കുന്ന സെർവറിലേക്ക് nodejs, php, jdk, copy ssh കീകൾ മുതലായവയുടെ ആവശ്യമായ പതിപ്പുകൾ ഇൻസ്റ്റാൾ ചെയ്യുന്ന ഒരു Ansible പ്ലേബുക്ക് എഴുതുക?

ഇപ്പോൾ ഞാൻ മനസ്സിലാക്കുന്നു, ഇത് എന്നെത്തന്നെ കാലിൽ വെടിവയ്ക്കുകയാണെന്ന്, കാരണം ഡോക്കർ അതിന്റെ ഒറ്റപ്പെടലിലൂടെ ഒരു ലാഭവും കൊണ്ടുവരുന്നില്ല. ഡോക്കറിൽ സിഐയുമായി ഞാൻ നേരിട്ട പ്രശ്നങ്ങൾ:

• നിർമ്മിക്കാൻ നിങ്ങൾക്ക് വീണ്ടും ഒരു ഡോക്കർ ഇമേജ് ആവശ്യമാണ്. നിങ്ങൾ ഒരു ഇമേജിനായി നോക്കുകയോ നിങ്ങളുടെ സ്വന്തം ഡോക്കർഫയൽ എഴുതുകയോ ചെയ്യേണ്ടതുണ്ട്.
• 90% നിങ്ങൾ ചില ssh കീകൾ കൈമാറേണ്ടതുണ്ട്, ഡോക്കർ ഇമേജിലേക്ക് നിങ്ങൾ എഴുതാൻ ആഗ്രഹിക്കാത്ത രഹസ്യ ഡാറ്റ.
• കണ്ടെയ്നർ സൃഷ്ടിക്കപ്പെടുകയും മരിക്കുകയും ചെയ്യുന്നു, അതോടൊപ്പം എല്ലാ കാഷെകളും നഷ്ടപ്പെടും. അടുത്ത ബിൽഡ് എല്ലാ പ്രോജക്റ്റ് ഡിപൻഡൻസികളും വീണ്ടും ഡൗൺലോഡ് ചെയ്യും, അത് സമയമെടുക്കുന്നതും ഫലപ്രദമല്ലാത്തതും സമയം പണവുമാണ്.

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

തീരുമാനം

ഡോക്കർ വളരെ ശക്തവും വഴക്കമുള്ളതുമായ ഉപകരണമാണെന്ന് ഞാൻ വിശ്വസിക്കുന്നു, ഇതാണ് അതിന്റെ പോരായ്മ (വിചിത്രമായി തോന്നുന്നു, അതെ). അതിന്റെ സഹായത്തോടെ, കമ്പനികൾക്ക് ഇത് എളുപ്പത്തിൽ ഹുക്ക് ചെയ്യാനും ആവശ്യമുള്ളിടത്തും ആവശ്യമില്ലാത്തിടത്തും ഉപയോഗിക്കാനും കഴിയും. ഡവലപ്പർമാർ അവരുടെ കണ്ടെയ്‌നറുകൾ, അവരുടെ ചില പരിതസ്ഥിതികൾ എന്നിവ സമാരംഭിക്കുന്നു, തുടർന്ന് അതെല്ലാം സുഗമമായി സിഐയിലേക്കും ഉൽപ്പാദനത്തിലേക്കും ഒഴുകുന്നു. ഈ കണ്ടെയ്‌നറുകൾ പ്രവർത്തിപ്പിക്കുന്നതിന് DevOps ടീം ഒരുതരം കോഡ് എഴുതുകയാണ്.

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

ഡോക്കർ ആവശ്യമുള്ളപ്പോൾ: തന്നിരിക്കുന്ന ഒരു പ്രക്രിയ ഒപ്റ്റിമൈസ് ചെയ്യുന്നതിൽ ഡോക്കർ വളരെ മികച്ചതാണെന്ന് ഞാൻ നിഗമനത്തിലെത്തി, പക്ഷേ അടിസ്ഥാന പ്രവർത്തനക്ഷമത നിർമ്മിക്കുന്നതിൽ അല്ല

നിങ്ങൾ ഇപ്പോഴും ഡോക്കർ ഉപയോഗിക്കാൻ തീരുമാനിക്കുകയാണെങ്കിൽ:

• അതീവ ജാഗ്രത പാലിക്കുക
• ഡോക്കർ ഉപയോഗിക്കാൻ ഡവലപ്പർമാരെ നിർബന്ധിക്കരുത്
• അതിന്റെ ഉപയോഗം ഒരിടത്ത് പ്രാദേശികവൽക്കരിക്കുക, എല്ലാ ഡോക്ക്‌ഫൈലിലും ഡോക്കർ-കംപോസ് റിപ്പോസിറ്ററികളിലും വ്യാപിപ്പിക്കരുത്

PS:

• ഞാൻ അടുത്തിടെ കണ്ടുമുട്ടി പാക്കർ അൻസിബിളിൽ ഇത് നന്നായി പ്രവർത്തിക്കുന്നുവെന്നും ഇമേജുകൾ നിർമ്മിക്കുന്ന പ്രക്രിയ ഏകീകരിക്കാൻ നിങ്ങളെ അനുവദിക്കുമെന്നും അവർ പറയുന്നു (ഡോക്കർ ഇമേജ് ഉൾപ്പെടെ)
• ഡോക്കറെ കുറിച്ചും, രസകരമായ ലേഖനം

വായിച്ചതിന് നന്ദി, നിങ്ങളുടെ കാര്യങ്ങളിലും ഉൽപ്പാദനക്ഷമമായ പ്രവൃത്തി ദിവസങ്ങളിലും സുതാര്യമായ തീരുമാനങ്ങൾ ഉണ്ടാകണമെന്ന് ഞാൻ ആഗ്രഹിക്കുന്നു!

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