ഡോക്കർ ഉപയോഗിച്ചുള്ള തുടർച്ചയായ ഡെലിവറി രീതികൾ (അവലോകനവും വീഡിയോയും)

ഞങ്ങളുടെ ടെക്‌നിക്കൽ ഡയറക്ടറുടെ ഏറ്റവും പുതിയ പ്രസംഗങ്ങളെ അടിസ്ഥാനമാക്കിയുള്ള പ്രസിദ്ധീകരണങ്ങളോടെ ഞങ്ങൾ ബ്ലോഗ് ആരംഭിക്കും ഡിസ്റ്റോൾ (ദിമിത്രി സ്റ്റോല്യറോവ്). അവയെല്ലാം 2016-ൽ വിവിധ പ്രൊഫഷണൽ ഇവന്റുകളിൽ നടന്നു, അവ DevOps, Docker എന്നീ വിഷയങ്ങൾക്കായി സമർപ്പിച്ചു. Badoo ഓഫീസിലെ ഡോക്കർ മോസ്കോ മീറ്റിംഗിൽ നിന്നുള്ള ഒരു വീഡിയോ, ഞങ്ങൾക്ക് ഇതിനകം ഉണ്ട് പ്രസിദ്ധീകരിച്ചു ഓൺലൈൻ. പുതിയവയ്‌ക്കൊപ്പം റിപ്പോർട്ടുകളുടെ സാരാംശം നൽകുന്ന ലേഖനങ്ങളും ഉണ്ടായിരിക്കും. അങ്ങനെ…

മെയ് 31 ന് സമ്മേളനത്തിൽ RootConf 2016, "റഷ്യൻ ഇന്റർനെറ്റ് ടെക്നോളജീസ്" (RIT++ 2016) എന്ന ഫെസ്റ്റിവലിന്റെ ഭാഗമായി നടന്ന, "തുടർച്ചയായ വിന്യാസവും വിന്യാസവും" എന്ന വിഭാഗം "ഡോക്കറുമായുള്ള തുടർച്ചയായ ഡെലിവറിയുടെ മികച്ച രീതികൾ" എന്ന റിപ്പോർട്ടോടെ തുറന്നു. ഡോക്കറും മറ്റ് ഓപ്പൺ സോഴ്‌സ് ഉൽപ്പന്നങ്ങളും ഉപയോഗിച്ച് ഒരു തുടർച്ചയായ ഡെലിവറി (സിഡി) പ്രക്രിയ നിർമ്മിക്കുന്നതിനുള്ള മികച്ച രീതികൾ ഇത് സംഗ്രഹിക്കുകയും ചിട്ടപ്പെടുത്തുകയും ചെയ്തു. നിർമ്മാണത്തിൽ ഈ പരിഹാരങ്ങളുമായി ഞങ്ങൾ പ്രവർത്തിക്കുന്നു, ഇത് പ്രായോഗിക അനുഭവത്തിൽ ആശ്രയിക്കാൻ ഞങ്ങളെ അനുവദിക്കുന്നു.

നിങ്ങൾക്ക് ഒരു മണിക്കൂർ ചെലവഴിക്കാൻ അവസരമുണ്ടെങ്കിൽ റിപ്പോർട്ടിന്റെ വീഡിയോ, ഇത് പൂർണ്ണമായി കാണാൻ ഞങ്ങൾ ശുപാർശ ചെയ്യുന്നു. അല്ലെങ്കിൽ, ടെക്സ്റ്റ് രൂപത്തിലുള്ള പ്രധാന സംഗ്രഹം ചുവടെയുണ്ട്.

ഡോക്കറിനൊപ്പം തുടർച്ചയായ ഡെലിവറി

വഴി തുടർച്ചയായ ഡെലിവറി Git റിപ്പോസിറ്ററിയിൽ നിന്നുള്ള ആപ്ലിക്കേഷൻ കോഡ് ആദ്യം ഉൽപ്പാദനത്തിലേക്ക് വരികയും തുടർന്ന് ആർക്കൈവിൽ അവസാനിക്കുകയും ചെയ്യുന്നതിന്റെ ഫലമായി സംഭവങ്ങളുടെ ശൃംഖല ഞങ്ങൾ മനസ്സിലാക്കുന്നു. ഇത് ഇതുപോലെ കാണപ്പെടുന്നു: Git → ബിൽഡ് → ടെസ്റ്റ് → റിലീസ് → പ്രവർത്തിപ്പിക്കുക.

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

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

പ്രധാന റോൾഔട്ട് പാറ്റേൺ

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

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

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

നമുക്ക് സംഗ്രഹിക്കാം പ്രധാന റോൾഔട്ട് പാറ്റേൺ ഇനിപ്പറയുന്ന ഘടകങ്ങൾ കണക്കിലെടുത്ത് പുതിയ പതിപ്പുകൾ:

1. ആദ്യം, ആപ്ലിക്കേഷന്റെ പഴയ പതിപ്പ് ആദ്യ കണ്ടെയ്നറിൽ പ്രവർത്തിക്കുന്നു.
2. പുതിയ പതിപ്പ് പിന്നീട് പുറത്തെടുത്ത് രണ്ടാമത്തെ കണ്ടെയ്നറിൽ "ചൂട്" ചെയ്യുന്നു. ഈ പുതിയ പതിപ്പ് തന്നെ അപ്‌ഡേറ്റ് ചെയ്ത ആപ്ലിക്കേഷൻ കോഡ് മാത്രമല്ല, അതിന്റെ ഏതെങ്കിലും ഡിപൻഡൻസികളും സിസ്റ്റം ഘടകങ്ങളും (ഉദാഹരണത്തിന്, OpenSSL-ന്റെ ഒരു പുതിയ പതിപ്പ് അല്ലെങ്കിൽ മുഴുവൻ വിതരണവും) വഹിക്കുമെന്നത് ശ്രദ്ധേയമാണ്.
3. പുതിയ പതിപ്പ് അഭ്യർത്ഥനകൾ നൽകാൻ പൂർണ്ണമായും തയ്യാറാകുമ്പോൾ, ട്രാഫിക് ആദ്യ കണ്ടെയ്നറിൽ നിന്ന് രണ്ടാമത്തേതിലേക്ക് മാറുന്നു.
4. പഴയ പതിപ്പ് ഇപ്പോൾ നിർത്താം.

ആപ്ലിക്കേഷന്റെ വ്യത്യസ്ത പതിപ്പുകൾ പ്രത്യേക കണ്ടെയ്‌നറുകളിൽ വിന്യസിക്കുന്ന ഈ സമീപനം മറ്റൊരു സൗകര്യം നൽകുന്നു - പെട്ടെന്നുള്ള റോൾബാക്ക് പഴയ പതിപ്പിലേക്ക് (എല്ലാത്തിനുമുപരി, ആവശ്യമുള്ള കണ്ടെയ്നറിലേക്ക് ട്രാഫിക് മാറ്റാൻ ഇത് മതിയാകും).

അവസാനത്തെ ആദ്യ ശുപാർശയിൽ ക്യാപ്റ്റന് പോലും തെറ്റ് കണ്ടെത്താൻ കഴിയാത്തത് പോലെ തോന്നുന്നു: "[ഡോക്കറുമായി തുടർച്ചയായ ഡെലിവറി സംഘടിപ്പിക്കുമ്പോൾ] ഡോക്കർ ഉപയോഗിക്കുക [അത് എന്താണ് നൽകുന്നതെന്ന് മനസിലാക്കുക]" ഓർക്കുക, ഇത് എല്ലാ പ്രശ്‌നങ്ങളും പരിഹരിക്കുന്ന ഒരു വെള്ളി ബുള്ളറ്റല്ല, മറിച്ച് അതിശയകരമായ അടിത്തറ നൽകുന്ന ഒരു ഉപകരണമാണ്.

പുനരുൽപാദനക്ഷമത

"പുനർനിർമ്മാണം" എന്നതുകൊണ്ട് ഞങ്ങൾ അർത്ഥമാക്കുന്നത് ആപ്ലിക്കേഷനുകൾ പ്രവർത്തിപ്പിക്കുമ്പോൾ നേരിടുന്ന പൊതുവായ ഒരു കൂട്ടം പ്രശ്നങ്ങളാണ്. ഞങ്ങൾ അത്തരം കേസുകളെക്കുറിച്ചാണ് സംസാരിക്കുന്നത്:

• സ്റ്റേജിനായി ഗുണനിലവാര വകുപ്പ് പരിശോധിച്ച സ്ക്രിപ്റ്റുകൾ നിർമ്മാണത്തിൽ കൃത്യമായി പുനർനിർമ്മിക്കണം.
• വ്യത്യസ്ത റിപ്പോസിറ്ററി മിററുകളിൽ നിന്ന് പാക്കേജുകൾ സ്വീകരിക്കാൻ കഴിയുന്ന സെർവറുകളിൽ ആപ്ലിക്കേഷനുകൾ പ്രസിദ്ധീകരിക്കുന്നു (കാലക്രമേണ അവ അപ്ഡേറ്റ് ചെയ്യപ്പെടുന്നു, അവയ്ക്കൊപ്പം ഇൻസ്റ്റാൾ ചെയ്ത ആപ്ലിക്കേഷനുകളുടെ പതിപ്പുകളും).
• "എല്ലാം എനിക്ക് പ്രാദേശികമായി പ്രവർത്തിക്കുന്നു!" (...കൂടാതെ ഡവലപ്പർമാരെ ഉൽപ്പാദനത്തിലേക്ക് അനുവദിക്കില്ല.)
• പഴയ (ആർക്കൈവ് ചെയ്ത) പതിപ്പിൽ നിങ്ങൾ എന്തെങ്കിലും പരിശോധിക്കേണ്ടതുണ്ട്.
• പങ്ക് € |

ഉപയോഗിച്ച പരിതസ്ഥിതികളുടെ പൂർണ്ണമായ അനുസരണം (അതുപോലെ തന്നെ മനുഷ്യ ഘടകത്തിന്റെ അഭാവവും) ആവശ്യമാണ് എന്ന വസ്തുതയിലേക്ക് അവരുടെ പൊതുവായ സാരാംശം തിളച്ചുമറിയുന്നു. പുനരുൽപാദനക്ഷമത നമുക്ക് എങ്ങനെ ഉറപ്പുനൽകാനാകും? ഡോക്കർ ചിത്രങ്ങൾ നിർമ്മിക്കുക Git-ൽ നിന്നുള്ള കോഡ് അടിസ്ഥാനമാക്കി, തുടർന്ന് ഏത് ജോലിക്കും അവ ഉപയോഗിക്കുക: ടെസ്റ്റ് സൈറ്റുകളിൽ, ഉൽപ്പാദനത്തിൽ, പ്രോഗ്രാമർമാരുടെ പ്രാദേശിക മെഷീനുകളിൽ... അതേ സമയം, നിർവ്വഹിക്കുന്ന പ്രവർത്തനങ്ങൾ ചെറുതാക്കേണ്ടത് പ്രധാനമാണ്. после ചിത്രം കൂട്ടിച്ചേർക്കുന്നു: ഇത് ലളിതമാണ്, പിശകുകൾ ഉണ്ടാകാനുള്ള സാധ്യത കുറവാണ്.

അടിസ്ഥാന സൗകര്യങ്ങൾ ഒരു കോഡാണ്

ഇൻഫ്രാസ്ട്രക്ചർ ആവശ്യകതകൾ (സെർവർ സോഫ്‌റ്റ്‌വെയറിന്റെ ലഭ്യത, അതിന്റെ പതിപ്പ് മുതലായവ) ഔപചാരികമാക്കുകയും “പ്രോഗ്രാം” ചെയ്യുകയും ചെയ്തിട്ടില്ലെങ്കിൽ, ഏതെങ്കിലും ആപ്ലിക്കേഷൻ അപ്‌ഡേറ്റിന്റെ റോൾഔട്ട് വിനാശകരമായ പ്രത്യാഘാതങ്ങൾക്ക് ഇടയാക്കും. ഉദാഹരണത്തിന്, സ്റ്റേജിംഗിൽ നിങ്ങൾ ഇതിനകം തന്നെ PHP 7.0 ലേക്ക് മാറുകയും അതിനനുസരിച്ച് കോഡ് മാറ്റിയെഴുതുകയും ചെയ്തിട്ടുണ്ട് - അപ്പോൾ ചില പഴയ PHP (5.5) ഉപയോഗിച്ച് ഉൽപ്പാദനത്തിൽ അതിന്റെ രൂപം തീർച്ചയായും ആരെയെങ്കിലും അത്ഭുതപ്പെടുത്തും. ഇന്റർപ്രെറ്റർ പതിപ്പിലെ ഒരു പ്രധാന മാറ്റത്തെക്കുറിച്ച് നിങ്ങൾ മറന്നേക്കില്ല, പക്ഷേ "വിശദാംശങ്ങളിൽ പിശാച് ഉണ്ട്": ആശ്ചര്യം ഏതെങ്കിലും ആശ്രിതത്വത്തിന്റെ ചെറിയ അപ്‌ഡേറ്റിലായിരിക്കാം.

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

ഒരു മൾട്ടി-ലെയർ ആപ്ലിക്കേഷൻ ആർക്കിടെക്ചറിന്റെ കാര്യത്തിൽ - ഉദാഹരണത്തിന്, ഒരു ഡോക്കർ കണ്ടെയ്‌നറിനുള്ളിൽ ഇതിനകം പ്രവർത്തിക്കുന്ന ഒരു ആപ്ലിക്കേഷന്റെ മുന്നിൽ നിൽക്കുന്ന nginx ഉണ്ട് - ഓരോ ലെയറിനും വേണ്ടി Git-ലെ കോഡിൽ നിന്ന് ഡോക്കർ ഇമേജുകൾ സൃഷ്ടിക്കണം. അപ്പോൾ ആദ്യത്തെ ചിത്രത്തിൽ ഒരു ഇന്റർപ്രെറ്ററും മറ്റ് "ക്ലോസ്" ഡിപൻഡൻസിയും ഉള്ള ഒരു ആപ്ലിക്കേഷൻ അടങ്ങിയിരിക്കും, രണ്ടാമത്തെ ചിത്രത്തിൽ അപ്‌സ്ട്രീം nginx അടങ്ങിയിരിക്കും.

ഡോക്കർ ചിത്രങ്ങൾ, ജിറ്റുമായുള്ള ആശയവിനിമയം

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

താൽക്കാലിക ചിത്രങ്ങളായി ശേഖരിക്കുന്നതിൽ അർത്ഥമുണ്ട്: മാസ്റ്റർ ബ്രാഞ്ച് (മാസ്റ്ററിന്റെ നിലവിലെ പതിപ്പ് നിരന്തരം കാണുന്നതിന് നിങ്ങൾക്ക് ഇത് ഒരു പ്രത്യേക സൈറ്റിലേക്ക് സ്വപ്രേരിതമായി റോൾ ചെയ്യാൻ കഴിയും), റിലീസുകളുള്ള ശാഖകൾ, നിർദ്ദിഷ്ട പുതുമകളുടെ ശാഖകൾ.

താൽക്കാലിക ചിത്രങ്ങളുടെ പ്രിവ്യൂ ഉൽപ്പാദനത്തിലേക്ക് വിവർത്തനം ചെയ്യേണ്ടതിന്റെ ആവശ്യകതയിലേക്ക് വന്നതിനുശേഷം, ഡവലപ്പർമാർ ഒരു നിശ്ചിത ടാഗ് ഇടുന്നു. ടാഗ് വഴി സ്വയമേവ ശേഖരിക്കുന്നു റിലീസ് ചിത്രം (അതിന്റെ ടാഗ് Git-ൽ നിന്നുള്ള ടാഗുമായി യോജിക്കുന്നു) കൂടാതെ സ്റ്റേജിംഗിലേക്ക് ഉരുട്ടി. ഗുണനിലവാര വകുപ്പ് ഇത് വിജയകരമായി പരിശോധിച്ചാൽ, അത് ഉൽപാദനത്തിലേക്ക് പോകുന്നു.

dapp

വിവരിച്ച എല്ലാം (റോൾഔട്ട്, ഇമേജ് അസംബ്ലി, തുടർന്നുള്ള അറ്റകുറ്റപ്പണികൾ) ബാഷ് സ്ക്രിപ്റ്റുകളും മറ്റ് "മെച്ചപ്പെടുത്തിയ" ഉപകരണങ്ങളും ഉപയോഗിച്ച് സ്വതന്ത്രമായി നടപ്പിലാക്കാൻ കഴിയും. എന്നാൽ നിങ്ങൾ ഇത് ചെയ്യുകയാണെങ്കിൽ, ചില ഘട്ടങ്ങളിൽ നടപ്പിലാക്കുന്നത് വലിയ സങ്കീർണ്ണതയിലേക്കും മോശം നിയന്ത്രണത്തിലേക്കും നയിക്കും. ഇത് മനസിലാക്കി, CI/CD നിർമ്മിക്കുന്നതിന് ഞങ്ങളുടേതായ പ്രത്യേക വർക്ക്ഫ്ലോ യൂട്ടിലിറ്റി സൃഷ്ടിക്കാൻ ഞങ്ങൾ എത്തി - dapp.

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

13 ഓഗസ്റ്റ് 2019-ന് അപ്ഡേറ്റ് ചെയ്തത്: നിലവിൽ ഒരു പദ്ധതി dapp എന്ന് പുനർനാമകരണം ചെയ്തു വെർഫ്, അതിന്റെ കോഡ് പൂർണ്ണമായും Go-യിൽ മാറ്റിയെഴുതി, അതിന്റെ ഡോക്യുമെന്റേഷൻ ഗണ്യമായി മെച്ചപ്പെടുത്തി.

കുബേർനെറ്റ്

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

റോൾഔട്ടിനായി, Kubernetes ഓഫറുകൾ:

• റെഡിനെസ് പ്രോബ് - ആപ്ലിക്കേഷന്റെ ഒരു പുതിയ പതിപ്പിന്റെ സന്നദ്ധത പരിശോധിക്കുന്നു (അതിലേക്ക് ട്രാഫിക് മാറ്റാൻ);
• റോളിംഗ് അപ്‌ഡേറ്റ് - കണ്ടെയ്‌നറുകളുടെ ഒരു ക്ലസ്റ്ററിലെ തുടർച്ചയായ ഇമേജ് അപ്‌ഡേറ്റ് (ഷട്ട്ഡൗൺ, അപ്‌ഡേറ്റ്, ലോഞ്ചിനുള്ള തയ്യാറെടുപ്പ്, ട്രാഫിക് സ്വിച്ചിംഗ്);
• സിൻക്രണസ് അപ്‌ഡേറ്റ് - മറ്റൊരു സമീപനത്തോടെ ഒരു ക്ലസ്റ്ററിൽ ഒരു ചിത്രം അപ്‌ഡേറ്റ് ചെയ്യുന്നു: ആദ്യം കണ്ടെയ്‌നറുകളുടെ പകുതിയിലും ബാക്കിയുള്ളവയിലും;
• കാനറി റിലീസുകൾ - അപാകതകൾ നിരീക്ഷിക്കാൻ പരിമിതമായ (ചെറിയ) കണ്ടെയ്‌നറുകളിൽ ഒരു പുതിയ ചിത്രം സമാരംഭിക്കുന്നു.

തുടർച്ചയായ ഡെലിവറി ഒരു പുതിയ പതിപ്പിന്റെ റിലീസ് മാത്രമല്ല, തുടർന്നുള്ള ഇൻഫ്രാസ്ട്രക്ചർ അറ്റകുറ്റപ്പണികൾക്ക് Kubernetes-ന് നിരവധി അവസരങ്ങളുണ്ട്: ബിൽറ്റ്-ഇൻ മോണിറ്ററിംഗ്, എല്ലാ കണ്ടെയ്‌നറുകൾക്കും ലോഗിംഗ്, ഓട്ടോമാറ്റിക് സ്കെയിലിംഗ് മുതലായവ. ഇതെല്ലാം ഇതിനകം തന്നെ പ്രവർത്തിക്കുന്നു, ശരിയായ കാര്യങ്ങൾക്കായി കാത്തിരിക്കുകയാണ്. നിങ്ങളുടെ പ്രക്രിയകളിൽ നടപ്പിലാക്കൽ.

അന്തിമ ശുപാർശകൾ

1. ഡോക്കർ ഉപയോഗിക്കുക.
2. നിങ്ങളുടെ എല്ലാ ആവശ്യങ്ങൾക്കുമായി ആപ്ലിക്കേഷനുകളുടെ ഡോക്കർ ഇമേജുകൾ സൃഷ്ടിക്കുക.
3. "ഇൻഫ്രാസ്ട്രക്ചർ കോഡ് ആണ്" എന്ന തത്വം പിന്തുടരുക.
4. ഡോക്കറിലേക്ക് Git ലിങ്ക് ചെയ്യുക.
5. റോൾഔട്ടിന്റെ ക്രമം നിയന്ത്രിക്കുക.
6. ഒരു റെഡിമെയ്ഡ് പ്ലാറ്റ്ഫോം ഉപയോഗിക്കുക (കുബർനെറ്റസ് അല്ലെങ്കിൽ മറ്റൊന്ന്).

വീഡിയോകളും സ്ലൈഡുകളും

പ്രകടനത്തിൽ നിന്നുള്ള വീഡിയോ (ഏകദേശം ഒരു മണിക്കൂർ) YouTube-ൽ പ്രസിദ്ധീകരിച്ചു (റിപ്പോർട്ട് 5-ാം മിനിറ്റ് മുതൽ ആരംഭിക്കുന്നു - ഈ നിമിഷം മുതൽ പ്ലേ ചെയ്യാൻ ലിങ്ക് പിന്തുടരുക).

റിപ്പോർട്ടിന്റെ അവതരണം:

പി.എസ്

ഞങ്ങളുടെ ബ്ലോഗിലെ വിഷയത്തെക്കുറിച്ചുള്ള മറ്റ് റിപ്പോർട്ടുകൾ:

• «werf - കുബർനെറ്റസിലെ CI / CD-യ്ക്കുള്ള ഞങ്ങളുടെ ഉപകരണം (അവലോകനവും വീഡിയോ റിപ്പോർട്ടും)» (Dmitry Stolyarov; മെയ് 27, 2019 DevOpsConf-ൽ);
• «ഡാറ്റാബേസുകളും കുബർനെറ്റുകളും» (Dmitry Stolyarov; നവംബർ 8, 2018 ഹൈലോഡ്++ ൽ);
• «കുബർനെറ്റസ്, GitLab എന്നിവയ്‌ക്കൊപ്പമുള്ള CI/CD മികച്ച രീതികൾ» (Dmitry Stolyarov; നവംബർ 7, 2017 ഹൈലോഡ്++ ൽ);
• «ചെറിയ പ്രോജക്ടുകളിൽ കുബർനെറ്റുകളുമായുള്ള ഞങ്ങളുടെ അനുഭവം» (Dmitry Stolyarov; ജൂൺ 6, 2017 RootConf-ൽ).

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