ഡോക്കറും ഗിറ്റ്‌ലാബ് സിഐയും ഉപയോഗിച്ചുള്ള വികസനവും പരിശോധനാ പ്രക്രിയയും

ഇൻവെൻറോസിൽ നിന്നുള്ള അലക്സാണ്ടർ സിഗച്ചേവിന്റെ റിപ്പോർട്ടിന്റെ ട്രാൻസ്ക്രിപ്റ്റ് വായിക്കാൻ ഞാൻ നിർദ്ദേശിക്കുന്നു “ഡോക്കർ + ഗിറ്റ്‌ലാബ് സിഐ ഉപയോഗിച്ചുള്ള വികസനവും പരിശോധനയും”

ഡോക്കർ + ഗിറ്റ്‌ലാബ് സിഐ അടിസ്ഥാനമാക്കിയുള്ള വികസനവും ടെസ്റ്റിംഗ് പ്രക്രിയയും നടപ്പിലാക്കാൻ തുടങ്ങുന്നവർ പലപ്പോഴും അടിസ്ഥാന ചോദ്യങ്ങൾ ചോദിക്കാറുണ്ട്. എവിടെ തുടങ്ങണം? എങ്ങനെ സംഘടിപ്പിക്കാം? എങ്ങനെ ടെസ്റ്റ് ചെയ്യാം?

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

ആർക്കാണ്, പൂച്ചയുടെ കീഴിൽ ദയവായി.

എന്റെ പേര് അലക്സാണ്ടർ സിഗച്ചേവ്. ഞാൻ Inventos-ൽ ജോലി ചെയ്യുന്നു. ഡോക്കർ ഉപയോഗിച്ചുള്ള എന്റെ അനുഭവത്തെക്കുറിച്ചും കമ്പനിയിലെ പ്രോജക്റ്റുകളിൽ ഞങ്ങൾ അത് എങ്ങനെ ക്രമേണ നടപ്പിലാക്കുന്നു എന്നതിനെക്കുറിച്ചും ഞാൻ നിങ്ങളോട് പറയും.

റിപ്പോർട്ടിന്റെ വിഷയം: ഡോക്കറും ഗിറ്റ്‌ലാബ് സിഐയും ഉപയോഗിച്ചുള്ള വികസന പ്രക്രിയ.

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

ഈ റിപ്പോർട്ടിൽ എന്തായിരിക്കും? ഞങ്ങൾ എന്ത് റേക്കുകൾ ശേഖരിച്ചു, എന്തൊക്കെ പ്രശ്നങ്ങൾ പരിഹരിച്ചു എന്നതിനെക്കുറിച്ചുള്ള ഞങ്ങളുടെ അനുഭവം ഞങ്ങൾ പങ്കിടും. അത് എല്ലായിടത്തും മനോഹരമായിരുന്നില്ല, പക്ഷേ അത് ഞങ്ങളെ മുന്നോട്ട് പോകാൻ അനുവദിച്ചു.

ഞങ്ങളുടെ മുദ്രാവാക്യം: നമുക്ക് കൈയിൽ കിട്ടുന്നതെല്ലാം ഡോക്കറൈസ് ചെയ്യുക.

ഞങ്ങൾ എന്ത് പ്രശ്നങ്ങളാണ് പരിഹരിക്കുന്നത്?

ഒരു കമ്പനിക്ക് നിരവധി ടീമുകൾ ഉള്ളപ്പോൾ, പ്രോഗ്രാമർ ഒരു പങ്കിട്ട വിഭവമാണ്. ഒരു പ്രോഗ്രാമറെ ഒരു പ്രോജക്റ്റിൽ നിന്ന് പുറത്താക്കുകയും കുറച്ച് സമയത്തേക്ക് മറ്റൊരു പ്രോജക്റ്റിലേക്ക് നൽകുകയും ചെയ്യുന്ന ഘട്ടങ്ങളുണ്ട്.

ഒരു പ്രോഗ്രാമർക്ക് പെട്ടെന്ന് മനസ്സിലാക്കാൻ, അവൻ പ്രോജക്റ്റിന്റെ സോഴ്സ് കോഡ് ഡൗൺലോഡ് ചെയ്യുകയും കഴിയുന്നത്ര വേഗത്തിൽ ഒരു പരിസ്ഥിതി സമാരംഭിക്കുകയും ചെയ്യേണ്ടതുണ്ട്, ഇത് ഈ പ്രോജക്റ്റിന്റെ പ്രശ്നങ്ങൾ പരിഹരിക്കുന്നതിൽ കൂടുതൽ മുന്നേറാൻ അവനെ അനുവദിക്കും.

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

വികസനത്തിലെ ക്രമീകരണങ്ങളുടെ സ്റ്റാൻഡേർഡൈസേഷനാണ് അടുത്ത കാരണം. എന്റെ അനുഭവത്തിൽ, ഡെവലപ്പർമാർ എപ്പോഴും മുൻകൈയെടുക്കുന്നു. ഓരോ അഞ്ചാമത്തെ കേസിലും, ഒരു ഇഷ്‌ടാനുസൃത ഡൊമെയ്‌ൻ നൽകിയിട്ടുണ്ട്, ഉദാഹരണത്തിന് vasya.dev. എന്റെ അരികിൽ ഇരിക്കുന്നത് എന്റെ അയൽവാസിയായ പെത്യയാണ്, അദ്ദേഹത്തിന്റെ ഡൊമെയ്ൻ petya.dev ആണ്. ഈ ഡൊമെയ്ൻ നാമം ഉപയോഗിച്ച് അവർ ഒരു വെബ്‌സൈറ്റോ ചില സിസ്റ്റം ഘടകങ്ങളോ വികസിപ്പിക്കുന്നു.

സിസ്റ്റം വളരുകയും ഈ ഡൊമെയ്ൻ നാമങ്ങൾ കോൺഫിഗറേഷനിൽ ഉൾപ്പെടുത്താൻ തുടങ്ങുകയും ചെയ്യുമ്പോൾ, വികസന പരിതസ്ഥിതികളിൽ ഒരു വൈരുദ്ധ്യം ഉണ്ടാകുകയും സൈറ്റ് പാത മാറ്റിയെഴുതുകയും ചെയ്യുന്നു.

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

ലൈബ്രറികളുടെ വ്യത്യസ്ത പതിപ്പുകളാണ് മറ്റൊരു പ്രശ്നം. ഒരു ഡവലപ്പർ വ്യത്യസ്ത പ്രോജക്റ്റുകളിൽ പ്രവർത്തിക്കുന്നത് പലപ്പോഴും സംഭവിക്കുന്നു. അഞ്ച് വർഷം മുമ്പ് ആരംഭിച്ച ഒരു ലെഗസി പ്രോജക്റ്റ് ഉണ്ട് (2017 മുതൽ - എഡിറ്ററുടെ കുറിപ്പ്). തുടക്കത്തിൽ ഞങ്ങൾ MySQL 5.5 ഉപയോഗിച്ച് ആരംഭിച്ചു. MySQL-ന്റെ കൂടുതൽ ആധുനിക പതിപ്പുകൾ നടപ്പിലാക്കാൻ ഞങ്ങൾ ശ്രമിക്കുന്ന ആധുനിക പ്രോജക്റ്റുകളും ഉണ്ട്, ഉദാഹരണത്തിന് 5.7 അല്ലെങ്കിൽ പഴയത് (2017-ൽ - എഡിറ്ററുടെ കുറിപ്പ്)

MySQL-ൽ പ്രവർത്തിക്കുന്ന ആർക്കും ഈ ലൈബ്രറികൾ ഡിപൻഡൻസികൾ ഉണ്ടെന്ന് അറിയാം. 2 ഡാറ്റാബേസുകൾ ഒരുമിച്ച് പ്രവർത്തിപ്പിക്കുന്നത് തികച്ചും പ്രശ്നകരമാണ്. ഏറ്റവും കുറഞ്ഞത്, പഴയ ക്ലയന്റുകളെ പുതിയ ഡാറ്റാബേസിലേക്ക് ബന്ധിപ്പിക്കുന്നത് പ്രശ്നമാണ്. ഇത് വീണ്ടും നിരവധി പ്രശ്നങ്ങൾക്ക് കാരണമാകുന്നു.

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

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

JS-ൽ വികസിക്കുന്ന ഒരു ഫ്രണ്ട്‌എൻഡ് ഡെവലപ്പർക്ക് ബാക്കെൻഡിൽ ഫലത്തിൽ സ്വാധീനമില്ല. ബാക്കെൻഡ് ഡെവലപ്പർ, ഞങ്ങളുടെ കാര്യത്തിൽ, റൂബി ഓൺ റെയിൽസ് വികസിപ്പിക്കുകയും ഫ്രണ്ടെൻഡിൽ ഇടപെടുകയും ചെയ്യുന്നില്ല. API ഉപയോഗിച്ചാണ് ഇടപെടൽ നടത്തുന്നത്.

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

ഉപകരണങ്ങൾ. നമ്മൾ എന്താണ് ഉപയോഗിക്കുന്നത്?

• ഡോക്കർ തന്നെ. ഒരു ഡോക്കർഫയൽ ഒരൊറ്റ ആപ്ലിക്കേഷന്റെ ഡിപൻഡൻസികളെ വിവരിക്കുന്നു.
• ഞങ്ങളുടെ നിരവധി ഡോക്കർ ആപ്ലിക്കേഷനുകൾ ഒരുമിച്ച് കൊണ്ടുവരുന്ന ഒരു ബണ്ടിൽ ആണ് ഡോക്കർ-കംപോസ്.
• സോഴ്സ് കോഡ് സംഭരിക്കുന്നതിന് ഞങ്ങൾ GitLab ഉപയോഗിക്കുന്നു.
• സിസ്റ്റം ഇന്റഗ്രേഷനായി ഞങ്ങൾ GitLab-CI ഉപയോഗിക്കുന്നു.

റിപ്പോർട്ടിൽ രണ്ട് ഭാഗങ്ങളാണുള്ളത്.

ഡവലപ്പർമാരുടെ മെഷീനുകളിൽ ഡോക്കർ എങ്ങനെ പ്രവർത്തിപ്പിക്കാമെന്ന് ആദ്യ ഭാഗം നിങ്ങളോട് പറയും.

GitLab-മായി എങ്ങനെ ഇടപഴകാം, ഞങ്ങൾ എങ്ങനെ ടെസ്റ്റുകൾ നടത്തുന്നു, എങ്ങനെ സ്റ്റേജിംഗിലേക്ക് പോകുന്നു എന്നതിനെ കുറിച്ച് രണ്ടാം ഭാഗം സംസാരിക്കും.

ആവശ്യമായ ഘടകങ്ങളെ വിവരിക്കാൻ (ഡിക്ലറേറ്റീവ് സമീപനം ഉപയോഗിച്ച്) അനുവദിക്കുന്ന ഒരു സാങ്കേതികവിദ്യയാണ് ഡോക്കർ. ഇതൊരു ഉദാഹരണമാണ് Dockerfile. റൂബി:2.3.0 ന്റെ ഔദ്യോഗിക ഡോക്കർ ഇമേജിൽ നിന്നാണ് നമുക്ക് അവകാശം ലഭിക്കുന്നതെന്ന് ഇവിടെ പ്രഖ്യാപിക്കുന്നു. ഇതിൽ റൂബി പതിപ്പ് 2.3 ഇൻസ്റ്റാൾ ചെയ്തിട്ടുണ്ട്. ആവശ്യമായ അസംബ്ലി ലൈബ്രറികളും നോഡ്ജെഎസും ഞങ്ങൾ ഇൻസ്റ്റാൾ ചെയ്യുന്നു. ഞങ്ങൾ ഒരു ഡയറക്ടറി സൃഷ്ടിക്കുകയാണെന്ന് ഞങ്ങൾ വിവരിക്കുന്നു /app. ഞങ്ങൾ ആപ്പ് ഡയറക്‌ടറി പ്രവർത്തന ഡയറക്‌ടറിയായി നിയോഗിക്കുന്നു. ഈ ഡയറക്ടറിയിൽ ഞങ്ങൾ ആവശ്യമായ ഏറ്റവും കുറഞ്ഞ Gemfile, Gemfile.lock എന്നിവ സ്ഥാപിക്കുന്നു. തുടർന്ന് ഈ ഡിപൻഡൻസി ഇമേജ് ഇൻസ്റ്റാൾ ചെയ്യുന്ന പ്രോജക്ടുകൾ ഞങ്ങൾ നിർമ്മിക്കുന്നു. എക്‌സ്‌റ്റേണൽ പോർട്ട് 3000-ൽ കേൾക്കാൻ കണ്ടെയ്‌നർ തയ്യാറാകുമെന്ന് ഞങ്ങൾ സൂചിപ്പിക്കുന്നു. ഞങ്ങളുടെ ആപ്ലിക്കേഷൻ നേരിട്ട് ലോഞ്ച് ചെയ്യുന്ന കമാൻഡാണ് അവസാന കമാൻഡ്. നമ്മൾ പ്രൊജക്റ്റ് റൺ കമാൻഡ് എക്സിക്യൂട്ട് ചെയ്യുകയാണെങ്കിൽ, നിർദ്ദിഷ്ട കമാൻഡ് പ്രവർത്തിപ്പിക്കാനും പ്രവർത്തിപ്പിക്കാനും ആപ്ലിക്കേഷൻ ശ്രമിക്കും.

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

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

ഞങ്ങളുടെ ഡെവലപ്പർ ഹോസ്റ്റ് മെഷീനിൽ 3000 മുതൽ 3000 വരെ കണ്ടെയ്‌നർ പോർട്ട് ഫോർവേഡ് ചെയ്യേണ്ടതുണ്ടെന്നും ഞങ്ങൾ വിവരിക്കുന്നു. ഡോക്കറിൽ നേരിട്ട് ഉൾച്ചേർത്ത iptables ഉം അതിന്റെ സ്വന്തം മെക്കാനിസവും ഉപയോഗിച്ച് ഇത് യാന്ത്രികമായി ചെയ്യപ്പെടുന്നു.

ഡെവലപ്പർക്ക് മുമ്പത്തെപ്പോലെ, ലഭ്യമായ ഏതെങ്കിലും IP വിലാസം ആക്‌സസ് ചെയ്യാൻ കഴിയും, ഉദാഹരണത്തിന്, മെഷീന്റെ 127.0.0.1 പ്രാദേശിക അല്ലെങ്കിൽ ബാഹ്യ IP വിലാസം.

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

ഡാറ്റാബേസ് അപ്രാപ്‌തമാകുമ്പോൾ പിശകുകൾ ഒഴിവാക്കാനും ഡാറ്റാബേസ് കണ്ടെയ്‌നർ നിർത്തുമ്പോൾ ഉറവിടങ്ങൾ സംരക്ഷിക്കാനും ഇത് ഞങ്ങളെ അനുവദിക്കുന്നു, അതുവഴി മറ്റ് പ്രോജക്റ്റുകൾക്കായി ഉറവിടങ്ങൾ സ്വതന്ത്രമാക്കുന്നു.

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

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

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

ചിത്രം നിർമ്മിച്ച ശേഷം, വികസനത്തിലും ഉൽ‌പാദനത്തിലും ഉള്ള കണ്ടെയ്‌നറുകൾ ഒന്നുതന്നെയായിരിക്കും. വലിയ ഇൻസ്റ്റാളേഷനുകൾക്ക് ഇത് പ്രത്യേകിച്ച് സത്യമാണ്.

ഫ്രണ്ടെൻഡിൽ ഞങ്ങൾ JavaScipt ഉം NodeJS ഉം ഉപയോഗിക്കുന്നു.

ഇപ്പോൾ ReacJS-ൽ ഞങ്ങളുടെ അവസാന പ്രോജക്‌റ്റ് ഉണ്ട്. ഡവലപ്പർ കണ്ടെയ്‌നറിൽ എല്ലാം സമാരംഭിക്കുകയും ഹോട്ട്-റീലോഡ് ഉപയോഗിച്ച് വികസിപ്പിച്ചെടുക്കുകയും ചെയ്തു.

അടുത്തതായി, JavaScipt അസംബ്ലിംഗ് ചെയ്യുന്നതിനുള്ള ചുമതല സമാരംഭിക്കുകയും ഉറവിടങ്ങൾ സംരക്ഷിക്കുകയും ചെയ്യുന്ന nginx വഴി സ്റ്റാറ്റിക്കലി അസംബിൾ ചെയ്ത കോഡ് അയയ്ക്കുകയും ചെയ്യുന്നു.

ഞങ്ങളുടെ ഏറ്റവും പുതിയ പ്രോജക്റ്റിന്റെ ഒരു ഡയഗ്രം ഞാൻ ഇവിടെ നൽകിയിരിക്കുന്നു.

നിങ്ങൾ എന്ത് പ്രശ്നങ്ങൾ പരിഹരിച്ചു? മൊബൈൽ ഉപകരണങ്ങൾ സംവദിക്കുന്ന ഒരു സിസ്റ്റം നിർമ്മിക്കേണ്ടതിന്റെ ആവശ്യകത ഞങ്ങൾക്ക് ഉണ്ടായിരുന്നു. അവർ ഡാറ്റ സ്വീകരിക്കുന്നു. ഈ ഉപകരണത്തിലേക്ക് പുഷ് അറിയിപ്പുകൾ അയയ്ക്കുക എന്നതാണ് ഒരു സാധ്യത.

ഇതിനായി ഞങ്ങൾ എന്താണ് ചെയ്തത്?

ഞങ്ങൾ ആപ്ലിക്കേഷനെ ഇനിപ്പറയുന്ന ഘടകങ്ങളായി വിഭജിച്ചു: JS-ലെ ഒരു അഡ്‌മിൻ ഭാഗം, റൂബി ഓൺ റെയിൽസിന് കീഴിലുള്ള ഒരു REST ഇന്റർഫേസിലൂടെ പ്രവർത്തിക്കുന്ന ഒരു ബാക്കെൻഡ്. ബാക്കെൻഡ് ഡാറ്റാബേസുമായി സംവദിക്കുന്നു. സൃഷ്ടിക്കുന്ന ഫലം ക്ലയന്റിന് നൽകുന്നു. ഒരു REST ഇന്റർഫേസ് വഴി ബാക്കെൻഡുമായും ഡാറ്റാബേസുമായും അഡ്മിൻ പാനൽ സംവദിക്കുന്നു.

ഞങ്ങൾക്ക് പുഷ് അറിയിപ്പുകൾ അയയ്‌ക്കേണ്ടതും ഉണ്ടായിരുന്നു. ഇതിന് മുമ്പ്, മൊബൈൽ പ്ലാറ്റ്‌ഫോമുകളിലേക്ക് അറിയിപ്പുകൾ എത്തിക്കുന്നതിന് ഉത്തരവാദിത്തമുള്ള ഒരു സംവിധാനം നടപ്പിലാക്കിയ ഒരു പ്രോജക്റ്റ് ഞങ്ങൾക്ക് ഉണ്ടായിരുന്നു.

ഞങ്ങൾ ഇനിപ്പറയുന്ന സ്കീം വികസിപ്പിച്ചെടുത്തു: ബ്രൗസറിൽ നിന്നുള്ള ഓപ്പറേറ്റർ അഡ്മിൻ പാനലുമായി സംവദിക്കുന്നു, അഡ്മിൻ പാനൽ ബാക്കെൻഡുമായി സംവദിക്കുന്നു, പുഷ് അറിയിപ്പുകൾ അയയ്ക്കുക എന്നതാണ് ചുമതല.

NodeJS-ൽ നടപ്പിലാക്കിയിരിക്കുന്ന മറ്റൊരു ഘടകവുമായി പുഷ് അറിയിപ്പുകൾ സംവദിക്കുന്നു.

അവരുടെ സ്വന്തം സംവിധാനം അനുസരിച്ച് ക്യൂകൾ നിർമ്മിക്കുകയും അറിയിപ്പുകൾ അയയ്ക്കുകയും ചെയ്യുന്നു.

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

ഒരേ കാര്യം, പക്ഷേ അക്കങ്ങളിൽ. കോഡ് പുനരുപയോഗം ഇവിടെ പ്രധാനമാണ്.

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

ആ സമയത്ത് ഞങ്ങൾ NodeJS-ന്റെ പതിപ്പ് 4 ഉപയോഗിച്ചിരുന്നു. ഇപ്പോൾ (2017-ൽ - എഡിറ്ററുടെ കുറിപ്പ്) ഞങ്ങളുടെ ഏറ്റവും പുതിയ സംഭവവികാസങ്ങളിൽ ഞങ്ങൾ NodeJS-ന്റെ പതിപ്പ് 7 ഉപയോഗിക്കുന്നു. ലൈബ്രറികളുടെ പുതിയ പതിപ്പുകൾ ഉൾപ്പെടുത്തുന്നതിന് പുതിയ ഘടകങ്ങളിൽ ഒരു പ്രശ്നവുമില്ല.

ആവശ്യമെങ്കിൽ, നിങ്ങൾക്ക് പുഷ് അറിയിപ്പ് സേവനത്തിന്റെ NodeJS പതിപ്പ് റീഫാക്റ്റർ ചെയ്യാനും ഉയർത്താനും കഴിയും.

ഞങ്ങൾക്ക് API അനുയോജ്യത നിലനിർത്താൻ കഴിയുമെങ്കിൽ, മുമ്പ് ഉപയോഗിച്ച മറ്റ് പ്രോജക്റ്റുകൾ ഉപയോഗിച്ച് ഇത് മാറ്റിസ്ഥാപിക്കാൻ കഴിയും.

ഡോക്കർ ചേർക്കാൻ എന്താണ് വേണ്ടത്? ആവശ്യമായ ഡിപൻഡൻസികൾ വിവരിക്കുന്ന ഞങ്ങളുടെ ശേഖരത്തിലേക്ക് ഞങ്ങൾ ഒരു ഡോക്കർഫയൽ ചേർക്കുന്നു. ഈ ഉദാഹരണത്തിൽ, ഘടകങ്ങൾ യുക്തിസഹമായി വിഭജിച്ചിരിക്കുന്നു. ഒരു ബാക്കെൻഡ് ഡെവലപ്പർക്കുള്ള ഏറ്റവും കുറഞ്ഞ കിറ്റാണിത്.

ഒരു പുതിയ പ്രോജക്‌റ്റ് സൃഷ്‌ടിക്കുമ്പോൾ, ഞങ്ങൾ ഒരു ഡോക്കർഫയൽ സൃഷ്‌ടിക്കുകയും ആവശ്യമുള്ള ഇക്കോസിസ്റ്റം (പൈത്തൺ, റൂബി, നോഡ്‌ജെഎസ്) വിവരിക്കുകയും ചെയ്യുന്നു. ഡോക്കർ-കമ്പോസിൽ, അത് ആവശ്യമായ ആശ്രിതത്വത്തെ വിവരിക്കുന്നു - ഡാറ്റാബേസ്. അവിടെയും അവിടെയും ഡാറ്റ സംഭരിക്കുന്നതിന്, അത്തരമൊരു പതിപ്പിന്റെ ഒരു ഡാറ്റാബേസ് ഞങ്ങൾക്ക് ആവശ്യമാണെന്ന് ഞങ്ങൾ വിവരിക്കുന്നു.

സ്റ്റാറ്റിക് ഉള്ളടക്കം നൽകുന്നതിന് ഞങ്ങൾ nginx ഉള്ള ഒരു പ്രത്യേക മൂന്നാം കണ്ടെയ്നർ ഉപയോഗിക്കുന്നു. ചിത്രങ്ങൾ അപ്‌ലോഡ് ചെയ്യാൻ സാധിക്കും. ബാക്കെൻഡ് അവയെ മുൻകൂട്ടി തയ്യാറാക്കിയ വോള്യത്തിൽ ഇടുന്നു, ഇത് സ്റ്റാറ്റിക് ഡാറ്റ നൽകുന്ന nginx ഉള്ള ഒരു കണ്ടെയ്‌നറിലും ഘടിപ്പിച്ചിരിക്കുന്നു.

nginx, mysql കോൺഫിഗറേഷൻ സംഭരിക്കുന്നതിന്, ആവശ്യമായ കോൺഫിഗറേഷനുകൾ സംഭരിക്കുന്ന ഒരു ഡോക്കർ ഫോൾഡർ ഞങ്ങൾ ചേർത്തു. ഒരു ഡെവലപ്പർ തന്റെ മെഷീനിൽ ഒരു റിപ്പോസിറ്ററിയുടെ ഒരു ജിറ്റ് ക്ലോൺ നിർമ്മിക്കുമ്പോൾ, പ്രാദേശിക വികസനത്തിനായി ഒരു പ്രോജക്റ്റ് തയ്യാറായിക്കഴിഞ്ഞു. ഏത് പോർട്ട് അല്ലെങ്കിൽ ഏത് ക്രമീകരണങ്ങൾ പ്രയോഗിക്കണം എന്നതിനെക്കുറിച്ച് ഒരു ചോദ്യവുമില്ല.

അടുത്തതായി ഞങ്ങൾക്ക് നിരവധി ഘടകങ്ങൾ ഉണ്ട്: അഡ്മിൻ, ഇൻഫോ-എപിഐ, പുഷ് അറിയിപ്പുകൾ.

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

ഡോക്കറൈസ്ഡ്-ആപ്പിന്റെ ഉള്ളടക്കത്തിന്റെ ഒരു ഉദാഹരണമാണിത്. ഞങ്ങൾ ഇവിടെ ഒരു ഡോക്കർ ഡയറക്ടറിയും സ്ഥാപിക്കുന്നു, അതിൽ എല്ലാ ഘടകങ്ങളുടെയും ഇടപെടലുകൾക്ക് ആവശ്യമായ കോൺഫിഗറേഷനുകൾ ഞങ്ങൾ പൂരിപ്പിക്കുന്നു. പ്രോജക്റ്റ് എങ്ങനെ സമാരംഭിക്കണമെന്ന് ചുരുക്കമായി വിവരിക്കുന്ന ഒരു README.md ഉണ്ട്.

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

പുഷ് അറിയിപ്പുകളുമായി സംയോജിപ്പിക്കേണ്ട ആവശ്യമുണ്ടെങ്കിൽ, docker-compose.yaml, docker-compose-push.yaml എന്നിവ സമാരംഭിക്കും.

docker-compose.yaml, docker-compose-push.yaml എന്നിവ ഫോൾഡറിൽ ഉള്ളതിനാൽ, ഒരൊറ്റ വെർച്വൽ നെറ്റ്‌വർക്ക് സ്വയമേവ സൃഷ്ടിക്കപ്പെടുന്നു.

ഘടകങ്ങളുടെ വിവരണം. ഘടകങ്ങൾ ശേഖരിക്കുന്നതിനുള്ള ഉത്തരവാദിത്തമുള്ള കൂടുതൽ വിപുലമായ ഫയലാണിത്. ഇവിടെ ശ്രദ്ധേയമായത് എന്താണ്? ഇവിടെ നമ്മൾ ബാലൻസർ ഘടകം അവതരിപ്പിക്കുന്നു.

ഇത് nginx പ്രവർത്തിപ്പിക്കുന്ന ഒരു റെഡിമെയ്ഡ് ഡോക്കർ ഇമേജും ഡോക്കർ സോക്കറ്റ് ശ്രദ്ധിക്കുന്ന ഒരു ആപ്ലിക്കേഷനുമാണ്. ഡൈനാമിക്, കണ്ടെയ്നറുകൾ ഓണാക്കുകയും ഓഫാക്കുകയും ചെയ്യുന്നതിനാൽ, nginx കോൺഫിഗറേഷൻ പുനഃസൃഷ്ടിക്കപ്പെടുന്നു. മൂന്നാം-ലെവൽ ഡൊമെയ്ൻ നാമങ്ങൾ ഉപയോഗിച്ച് ഞങ്ങൾ ഘടകങ്ങളുടെ കൈകാര്യം ചെയ്യൽ വിതരണം ചെയ്യുന്നു.

വികസന പരിതസ്ഥിതിക്കായി ഞങ്ങൾ .dev ഡൊമെയ്ൻ ഉപയോഗിക്കുന്നു - api.informer.dev. ഡെവലപ്പറുടെ ലോക്കൽ മെഷീനിൽ .dev ഡൊമെയ്‌നുള്ള ആപ്ലിക്കേഷനുകൾ ലഭ്യമാണ്.

തുടർന്ന് കോൺഫിഗറുകൾ ഓരോ പ്രോജക്റ്റിലേക്കും മാറ്റുകയും എല്ലാ പ്രോജക്റ്റുകളും ഒരേ സമയം ഒരുമിച്ച് സമാരംഭിക്കുകയും ചെയ്യുന്നു.

ഞങ്ങൾ ഇത് ഗ്രാഫിക്കായി ചിത്രീകരിക്കുകയാണെങ്കിൽ, ക്ലയന്റ് ഞങ്ങളുടെ ബ്രൗസറോ അല്ലെങ്കിൽ ബാലൻസറോട് ഞങ്ങൾ അഭ്യർത്ഥനകൾ നടത്തുന്ന ഏതെങ്കിലും തരത്തിലുള്ള ഉപകരണമോ ആണെന്ന് മാറുന്നു.

ഡൊമെയ്‌ൻ നാമത്തെ അടിസ്ഥാനമാക്കി ഏത് കണ്ടെയ്‌നറാണ് ആക്‌സസ് ചെയ്യേണ്ടതെന്ന് ബാലൻസർ നിർണ്ണയിക്കുന്നു.

ഇത് അഡ്മിൻ പാനലിന് JS നൽകുന്ന nginx ആയിരിക്കാം. API നൽകുന്ന nginx അല്ലെങ്കിൽ ഇമേജുകൾ ലോഡ് ചെയ്യുന്ന രൂപത്തിൽ nginx നൽകുന്ന സ്റ്റാറ്റിക് ഫയലുകൾ വഴി ഇത് ചെയ്യാൻ കഴിയും.

കണ്ടെയ്‌നറുകൾ ഒരു വെർച്വൽ നെറ്റ്‌വർക്കിലേക്ക് ബന്ധിപ്പിച്ചിട്ടുണ്ടെന്നും ഒരു പ്രോക്സിക്ക് പിന്നിൽ മറച്ചിട്ടുണ്ടെന്നും ഡയഗ്രം കാണിക്കുന്നു.

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

എന്റെ ആപ്ലിക്കേഷൻ ഡോക്കറൈസ് ചെയ്യാൻ ഞാൻ എന്ത് ഉദാഹരണമാണ് നോക്കേണ്ടത്? എന്റെ അഭിപ്രായത്തിൽ, MySQL-നുള്ള ഔദ്യോഗിക ഡോക്കർ ഇമേജാണ് ഒരു നല്ല ഉദാഹരണം.

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

Hub.docker.com-ൽ സാധാരണയായി github.com-ലേക്കുള്ള ലിങ്കുകൾ അടങ്ങിയിരിക്കുന്നു, ഇവിടെ നിങ്ങൾക്ക് നേരിട്ട് ഒരു ചിത്രം നിർമ്മിക്കാൻ കഴിയുന്ന റോ ഡാറ്റ നേരിട്ട് നൽകുന്നു.

ഈ ശേഖരത്തിൽ ഒരു സ്‌ക്രിപ്റ്റ് docker-endpoint.sh ഉണ്ട്, ഇത് ആപ്ലിക്കേഷൻ ലോഞ്ചിന്റെ പ്രാരംഭ സമാരംഭത്തിനും തുടർന്നുള്ള പ്രോസസ്സിംഗിനും ഉത്തരവാദിയാണ്.

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

ക്രമരഹിതമായ പാസ്‌വേഡ് സൃഷ്‌ടിക്കുന്നതിനുള്ള ഒരു ഓപ്ഷൻ ഉണ്ട്. ഞങ്ങൾക്ക് ഒരു ഉപയോക്താവിനെ ആവശ്യമുണ്ടെന്ന് ഞങ്ങൾ പറയുന്നു, ഉപയോക്താവിനായി ഒരു പാസ്‌വേഡ് സജ്ജീകരിക്കേണ്ടതുണ്ട്, ഞങ്ങൾ ഒരു ഡാറ്റാബേസ് സൃഷ്ടിക്കേണ്ടതുണ്ട്.

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

MySQL-ന്റെ ഒരു പ്രത്യേക പതിപ്പ് github.com-ൽ എങ്ങനെയിരിക്കും എന്നതിന്റെ ഒരു ഉദാഹരണമാണിത്. നിങ്ങൾക്ക് Dockerfile തുറന്ന് അവിടെ എങ്ങനെ ഇൻസ്റ്റലേഷൻ നടക്കുന്നു എന്ന് കാണാൻ കഴിയും.

പ്രവേശന പോയിന്റിന്റെ ഉത്തരവാദിത്തം docker-endpoint.sh സ്ക്രിപ്റ്റ്. പ്രാരംഭ സമാരംഭ സമയത്ത്, ചില തയ്യാറെടുപ്പ് പ്രവർത്തനങ്ങൾ ആവശ്യമാണ്, ഈ പ്രവർത്തനങ്ങളെല്ലാം ഇനിഷ്യലൈസേഷൻ സ്ക്രിപ്റ്റിൽ ഉൾപ്പെടുത്തിയിട്ടുണ്ട്.

നമുക്ക് രണ്ടാം ഭാഗത്തിലേക്ക് കടക്കാം.

സോഴ്‌സ് കോഡുകൾ സംഭരിക്കാൻ ഞങ്ങൾ gitlab-ലേക്ക് മാറി. വിഷ്വൽ ഇന്റർഫേസ് ഉള്ള സാമാന്യം ശക്തമായ ഒരു സംവിധാനമാണിത്.

Gitlab ഘടകങ്ങളിലൊന്നാണ് Gitlab CI. ഒരു കോഡ് ഡെലിവറി സിസ്റ്റം ഓർഗനൈസുചെയ്യുന്നതിനോ ഓട്ടോമേറ്റഡ് ടെസ്റ്റിംഗ് പ്രവർത്തിപ്പിക്കുന്നതിനോ പിന്നീട് ഉപയോഗിക്കുന്ന കമാൻഡുകളുടെ ഒരു ശ്രേണി വിവരിക്കാൻ ഇത് നിങ്ങളെ അനുവദിക്കുന്നു.

Gitlab CI 2-നെക്കുറിച്ചുള്ള റിപ്പോർട്ട് https://goo.gl/uohKjI - റൂബി റഷ്യ ക്ലബ്ബിൽ നിന്നുള്ള റിപ്പോർട്ട് വളരെ വിശദമായതും നിങ്ങൾക്ക് താൽപ്പര്യമുള്ളതുമാകാം.

Gitlab CI സജീവമാക്കാൻ എന്താണ് വേണ്ടതെന്ന് ഇപ്പോൾ നോക്കാം. Gitlab CI സമാരംഭിക്കുന്നതിന്, ഞങ്ങൾ പ്രോജക്റ്റിന്റെ റൂട്ടിൽ .gitlab-ci.yml ഫയൽ ഇടേണ്ടതുണ്ട്.

ടെസ്റ്റ്, വിന്യാസം തുടങ്ങിയ സംസ്ഥാനങ്ങളുടെ ഒരു ക്രമം നടത്താൻ ഞങ്ങൾ ആഗ്രഹിക്കുന്നുവെന്ന് ഞങ്ങൾ ഇവിടെ വിവരിക്കുന്നു.

ഞങ്ങളുടെ ആപ്ലിക്കേഷന്റെ ഡോക്കർ-കമ്പോസ് ബിൽഡിനെ നേരിട്ട് വിളിക്കുന്ന സ്ക്രിപ്റ്റുകൾ ഞങ്ങൾ എക്സിക്യൂട്ട് ചെയ്യുന്നു. ഇത് ബാക്കെൻഡിന്റെ ഒരു ഉദാഹരണമാണ്.

ഡാറ്റാബേസ് മാറ്റുന്നതിനും ടെസ്റ്റുകൾ പ്രവർത്തിപ്പിക്കുന്നതിനും മൈഗ്രേഷനുകൾ പ്രവർത്തിപ്പിക്കേണ്ടത് ആവശ്യമാണെന്ന് ഞങ്ങൾ അടുത്തതായി പറയുന്നു.

സ്ക്രിപ്റ്റുകൾ ശരിയായി നടപ്പിലാക്കുകയും ഒരു പിശക് കോഡ് നൽകാതിരിക്കുകയും ചെയ്താൽ, സിസ്റ്റം വിന്യാസത്തിന്റെ രണ്ടാം ഘട്ടത്തിലേക്ക് പോകുന്നു.

സ്റ്റേജിനായി വിന്യാസ ഘട്ടമാണ് നിലവിൽ നടപ്പിലാക്കുന്നത്. പ്രവർത്തനരഹിതമായ പുനരാരംഭം ഞങ്ങൾ സംഘടിപ്പിച്ചില്ല.

ഞങ്ങൾ എല്ലാ കണ്ടെയ്നറുകളും നിർബന്ധിതമായി കെടുത്തിക്കളയുന്നു, തുടർന്ന് ഞങ്ങൾ എല്ലാ കണ്ടെയ്നറുകളും വീണ്ടും ഉയർത്തുന്നു, പരീക്ഷണ സമയത്ത് ആദ്യ ഘട്ടത്തിൽ ശേഖരിച്ചു.

നിലവിലെ വേരിയബിൾ എൻവയോൺമെന്റിനായി ഡെവലപ്പർമാർ എഴുതിയ ഡാറ്റാബേസ് മൈഗ്രേഷനുകൾ പ്രവർത്തിപ്പിക്കാം.

ഇത് മാസ്റ്റർ ബ്രാഞ്ചിൽ മാത്രമേ പ്രയോഗിക്കാവൂ എന്ന് ഒരു കുറിപ്പുണ്ട്.

മറ്റ് ശാഖകൾ മാറ്റുമ്പോൾ പ്രവർത്തിക്കില്ല.

ശാഖകൾക്കൊപ്പം റോളൗട്ടുകൾ സംഘടിപ്പിക്കാൻ സാധിക്കും.

ഇത് കൂടുതൽ സംഘടിപ്പിക്കുന്നതിന്, ഞങ്ങൾ Gitlab Runner ഇൻസ്റ്റാൾ ചെയ്യേണ്ടതുണ്ട്.

ഈ യൂട്ടിലിറ്റി ഗോലാങ്ങിൽ എഴുതിയിരിക്കുന്നു. ഗോലാങ് ലോകത്ത് സാധാരണമായിരിക്കുന്നതുപോലെ ഇത് ഒരൊറ്റ ഫയലാണ്, ഇതിന് ആശ്രിതത്വങ്ങളൊന്നും ആവശ്യമില്ല.

തുടക്കത്തിൽ ഞങ്ങൾ Gitlab റണ്ണർ രജിസ്റ്റർ ചെയ്യുന്നു.

Gitlab വെബ് ഇന്റർഫേസിൽ ഞങ്ങൾക്ക് കീ ലഭിക്കും.

അപ്പോൾ നമ്മൾ കമാൻഡ് ലൈനിലെ ഇനീഷ്യലൈസേഷൻ കമാൻഡിനെ വിളിക്കുന്നു.

ഡയലോഗ് മോഡിൽ Gitlab റണ്ണർ കോൺഫിഗർ ചെയ്യുന്നു (ഷെൽ, ഡോക്കർ, വിർച്ച്വൽബോക്സ്, എസ്എസ്എച്ച്)

.gitlab-ci.yml ക്രമീകരണം അനുസരിച്ച് Gitlab റണ്ണറിലെ കോഡ് ഓരോ കമ്മിറ്റിലും എക്സിക്യൂട്ട് ചെയ്യും.

വെബ് ഇന്റർഫേസിലെ Gitlab-ൽ ഇത് ദൃശ്യപരമായി എങ്ങനെ കാണപ്പെടുന്നു. GITlab CI കണക്റ്റുചെയ്‌ത ശേഷം, ബിൽഡ് ഇപ്പോൾ ഏത് അവസ്ഥയിലാണെന്ന് കാണിക്കുന്ന ഒരു ഫ്ലാഗ് ഞങ്ങളുടെ പക്കലുണ്ട്.

4 മിനിറ്റ് മുമ്പ് എല്ലാ ടെസ്റ്റുകളും വിജയിച്ച ഒരു കമ്മിറ്റ് ഉണ്ടാക്കിയത് ഞങ്ങൾ കാണുന്നു, പ്രശ്നങ്ങളൊന്നും ഉണ്ടാകില്ല.

നമുക്ക് കെട്ടിടങ്ങൾ കൂടുതൽ വിശദമായി പരിശോധിക്കാം. രണ്ട് സംസ്ഥാനങ്ങൾ ഇതിനകം കടന്നുപോയതായി ഇവിടെ കാണാം. സ്റ്റേജിലെ ടെസ്റ്റിംഗ് സ്റ്റാറ്റസും വിന്യാസ നിലയും.

നമ്മൾ ഒരു നിർദ്ദിഷ്‌ട ബിൽഡിൽ ക്ലിക്ക് ചെയ്യുകയാണെങ്കിൽ, .gitlab-ci.yml അനുസരിച്ച് പ്രക്രിയയിൽ സമാരംഭിച്ച കമാൻഡുകളുടെ കൺസോൾ ഔട്ട്‌പുട്ട് ഉണ്ടാകും.

ഞങ്ങളുടെ ഉൽപ്പന്നത്തിന്റെ കഥ ഇങ്ങനെയാണ്. വിജയകരമായ ശ്രമങ്ങൾ ഉണ്ടായതായി നാം കാണുന്നു. ടെസ്റ്റുകൾ സമർപ്പിക്കുമ്പോൾ, അവ അടുത്ത ഘട്ടത്തിലേക്ക് നീങ്ങുന്നില്ല, കൂടാതെ സ്റ്റേജിംഗ് കോഡ് അപ്ഡേറ്റ് ചെയ്യുന്നില്ല.

ഞങ്ങൾ ഡോക്കർ നടപ്പിലാക്കിയപ്പോൾ സ്റ്റേജിൽ എന്ത് പ്രശ്‌നങ്ങളാണ് ഞങ്ങൾ പരിഹരിച്ചത്? ഞങ്ങളുടെ സിസ്റ്റത്തിൽ ഘടകങ്ങൾ അടങ്ങിയിരിക്കുന്നു, റിപ്പോസിറ്ററിയിൽ അപ്‌ഡേറ്റ് ചെയ്‌ത ചില ഘടകങ്ങൾ മാത്രമേ ഞങ്ങൾക്ക് പുനരാരംഭിക്കേണ്ടതുള്ളൂ, മുഴുവൻ സിസ്റ്റവും അല്ല.

ഇത് ചെയ്യുന്നതിന്, ഞങ്ങൾ എല്ലാം പ്രത്യേക ഫോൾഡറുകളായി വേർതിരിക്കേണ്ടതുണ്ട്.

ഞങ്ങൾ ഇത് ചെയ്‌തതിന് ശേഷം, ഡോക്കർ-കമ്പോസ് ഓരോ ഫോൾഡറിനും അതിന്റേതായ നെറ്റ്‌വർക്ക് സ്‌പെയ്‌സ് സൃഷ്‌ടിക്കുകയും അതിന്റെ അയൽക്കാരന്റെ ഘടകങ്ങൾ കാണാതിരിക്കുകയും ചെയ്യുന്നത് ഞങ്ങൾക്ക് പ്രശ്‌നമുണ്ടാക്കി.

ചുറ്റിക്കറങ്ങാൻ, ഡോക്കറിൽ ഞങ്ങൾ സ്വമേധയാ നെറ്റ്‌വർക്ക് സൃഷ്‌ടിച്ചു. ഈ പ്രോജക്റ്റിനായി നിങ്ങൾ അത്തരമൊരു നെറ്റ്‌വർക്ക് ഉപയോഗിക്കണമെന്ന് ഡോക്കർ-കമ്പോസിൽ എഴുതിയിരുന്നു.

അങ്ങനെ, ഈ മെഷ് ഉപയോഗിച്ച് ആരംഭിക്കുന്ന ഓരോ ഘടകങ്ങളും സിസ്റ്റത്തിന്റെ മറ്റ് ഭാഗങ്ങളിൽ ഘടകങ്ങൾ കാണുന്നു.

നിരവധി പ്രോജക്റ്റുകൾക്കിടയിൽ സ്റ്റേജിംഗ് വിഭജിക്കുന്നതാണ് അടുത്ത പ്രശ്നം.

ഇതെല്ലാം മനോഹരവും ഉൽപ്പാദനവുമായി കഴിയുന്നത്ര അടുത്തും കാണുന്നതിന്, വെബ്ബിൽ എല്ലായിടത്തും ഉപയോഗിക്കുന്ന പോർട്ട് 80 അല്ലെങ്കിൽ 443 ഉപയോഗിക്കുന്നത് നല്ലതാണ്.

ഞങ്ങൾ ഇത് എങ്ങനെ പരിഹരിച്ചു? എല്ലാ വലിയ പ്രോജക്ടുകൾക്കും ഞങ്ങൾ ഒരു Gitlab റണ്ണറെ നിയോഗിച്ചു.

വിതരണം ചെയ്‌ത നിരവധി ഗിറ്റ്‌ലാബ് റണ്ണേഴ്‌സ് സമാരംഭിക്കാൻ Gitlab നിങ്ങളെ അനുവദിക്കുന്നു, ഇത് എല്ലാ ജോലികളും ക്രമരഹിതമായ ക്രമത്തിൽ എടുത്ത് പ്രവർത്തിപ്പിക്കും.

വീട്ടിലെ പ്രശ്‌നങ്ങൾ ഒഴിവാക്കാൻ, ഞങ്ങളുടെ പ്രോജക്‌റ്റുകളുടെ ഗ്രൂപ്പിനെ ഒരു ഗിറ്റ്‌ലാബ് റണ്ണറായി ഞങ്ങൾ പരിമിതപ്പെടുത്തി, അത് പ്രശ്‌നങ്ങളില്ലാതെ ഞങ്ങളുടെ വോള്യങ്ങളുമായി പൊരുത്തപ്പെടുന്നു.

ഞങ്ങൾ nginx-proxy ഒരു പ്രത്യേക ലോഞ്ച് സ്‌ക്രിപ്റ്റിലേക്ക് മാറ്റി, അതിൽ എല്ലാ പ്രോജക്റ്റുകളുടെയും ഗ്രിഡുകൾ എഴുതി.

ഞങ്ങളുടെ പ്രോജക്റ്റിന് ഒരു ഗ്രിഡ് ഉണ്ട്, കൂടാതെ പ്രോജക്റ്റ് പേരുകൾ അടിസ്ഥാനമാക്കി ബാലൻസറിന് നിരവധി ഗ്രിഡുകൾ ഉണ്ട്. ഇതിന് ഡൊമെയ്ൻ നാമങ്ങൾ ഉപയോഗിച്ച് കൂടുതൽ പ്രോക്‌സി ചെയ്യാൻ കഴിയും.

ഞങ്ങളുടെ അഭ്യർത്ഥനകൾ പോർട്ട് 80-ലെ ഡൊമെയ്‌നിലൂടെ വരുന്നു, ഈ ഡൊമെയ്‌നിൽ സേവനം നൽകുന്ന ഒരു കൂട്ടം കണ്ടെയ്‌നറുകൾക്ക് അത് പരിഹരിക്കപ്പെടും.

വേറെ എന്തൊക്കെ പ്രശ്നങ്ങൾ ഉണ്ടായിരുന്നു? എല്ലാ കണ്ടെയ്നറുകളും ഡിഫോൾട്ടായി റൂട്ട് ആയി പ്രവർത്തിക്കുന്നത് ഇതാണ്. ഇത് സിസ്റ്റത്തിന്റെ റൂട്ട് അസമമായ റൂട്ട് ഹോസ്റ്റാണ്.

എന്നിരുന്നാലും, നിങ്ങൾ കണ്ടെയ്നറിൽ നൽകിയാൽ, അത് റൂട്ട് ആയിരിക്കും, ഈ കണ്ടെയ്നറിൽ ഞങ്ങൾ സൃഷ്ടിക്കുന്ന ഫയലിന് റൂട്ട് അവകാശങ്ങൾ ലഭിക്കും.

ഒരു ഡവലപ്പർ കണ്ടെയ്‌നറിൽ പ്രവേശിച്ച് ഫയലുകൾ സൃഷ്‌ടിക്കുന്ന ചില കമാൻഡുകൾ അവിടെ സൃഷ്‌ടിക്കുകയും കണ്ടെയ്‌നർ ഉപേക്ഷിക്കുകയും ചെയ്‌താൽ, അവന്റെ പ്രവർത്തന ഡയറക്‌ടറിയിൽ അയാൾക്ക് ആക്‌സസ്സ് ഇല്ലാത്ത ഒരു ഫയൽ ഉണ്ട്.

ഇത് എങ്ങനെ പരിഹരിക്കാനാകും? കണ്ടെയ്‌നറിൽ ഉള്ള ഉപയോക്താക്കളെ നിങ്ങൾക്ക് ചേർക്കാം.

ഞങ്ങൾ ഉപയോക്താവിനെ ചേർത്തപ്പോൾ എന്ത് പ്രശ്നങ്ങൾ ഉണ്ടായി?

ഒരു ഉപയോക്താവിനെ സൃഷ്ടിക്കുമ്പോൾ, ഗ്രൂപ്പ് ഐഡിയും (UID) ഉപയോക്തൃ ഐഡിയും (GID) പലപ്പോഴും പൊരുത്തപ്പെടുന്നില്ല.

കണ്ടെയ്‌നറിലെ ഈ പ്രശ്നം പരിഹരിക്കാൻ ഞങ്ങൾ ഐഡി 1000 ഉള്ള ഉപയോക്താക്കളെ ഉപയോഗിക്കുന്നു.

ഞങ്ങളുടെ കാര്യത്തിൽ, മിക്കവാറും എല്ലാ ഡെവലപ്പർമാരും ഉബുണ്ടു ഒഎസ് ഉപയോഗിക്കുന്ന വസ്തുതയുമായി ഇത് പൊരുത്തപ്പെട്ടു. ഉബുണ്ടു ഒഎസിൽ ആദ്യ ഉപയോക്താവിന് ഐഡി 1000 ഉണ്ട്.

ഞങ്ങൾക്ക് പദ്ധതികളുണ്ടോ?

ഡോക്കർ ഡോക്യുമെന്റേഷൻ വീണ്ടും വായിക്കുക. പ്രോജക്റ്റ് സജീവമായി വികസിച്ചുകൊണ്ടിരിക്കുന്നു, ഡോക്യുമെന്റേഷൻ മാറുകയാണ്. രണ്ടോ മൂന്നോ മാസം മുമ്പ് ലഭിച്ച ഡാറ്റ പതുക്കെ കാലഹരണപ്പെട്ടു.

ഞങ്ങൾ പരിഹരിച്ച ചില പ്രശ്നങ്ങൾ ഇതിനകം തന്നെ സ്റ്റാൻഡേർഡ് മാർഗങ്ങളിലൂടെ പരിഹരിച്ചിരിക്കാം.

ഞാൻ ശരിക്കും മുന്നോട്ട് പോകാനും ഓർക്കസ്ട്രേഷനിലേക്ക് നേരിട്ട് നീങ്ങാനും ആഗ്രഹിക്കുന്നു.

ഒരു ഉദാഹരണമാണ് ഡോക്കറിന്റെ ബിൽറ്റ്-ഇൻ മെക്കാനിസമായ ഡോക്കർ സ്വാം, അത് ബോക്സിൽ നിന്ന് പുറത്തുവരുന്നു. ഡോക്കർ സ്വാം സാങ്കേതികവിദ്യയെ അടിസ്ഥാനമാക്കി എന്തെങ്കിലും പ്രൊഡക്ഷൻ ആരംഭിക്കാൻ ഞാൻ ആഗ്രഹിക്കുന്നു.

മുട്ടയിടുന്ന കണ്ടെയ്‌നറുകൾ ലോഗുകൾക്കൊപ്പം പ്രവർത്തിക്കുന്നത് അസൗകര്യമുണ്ടാക്കുന്നു. ഇപ്പോൾ രേഖകൾ ഒറ്റപ്പെട്ട നിലയിലാണ്. അവ പാത്രങ്ങളിൽ ചിതറിക്കിടക്കുന്നു. ഒരു വെബ് ഇന്റർഫേസ് വഴി ലോഗുകളിലേക്ക് സൗകര്യപ്രദമായ ആക്സസ് ഉണ്ടാക്കുക എന്നതാണ് ചുമതലകളിൽ ഒന്ന്.

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