werf - കുബർനെറ്റസിലെ CI / CD-യ്ക്കുള്ള ഞങ്ങളുടെ ഉപകരണം (അവലോകനവും വീഡിയോ റിപ്പോർട്ടും)

മെയ് 27-ന് ഫെസ്റ്റിവലിന്റെ ഭാഗമായി നടന്ന DevOpsConf 2019 കോൺഫറൻസിന്റെ പ്രധാന ഹാളിൽ RIT++ 2019, “തുടർച്ചയായ ഡെലിവറി” വിഭാഗത്തിന്റെ ഭാഗമായി, ഒരു റിപ്പോർട്ട് നൽകി “വേർഫ് - കുബെർനെറ്റസിലെ സിഐ/സിഡിക്കുള്ള ഞങ്ങളുടെ ഉപകരണം”. അത് അവരെക്കുറിച്ചാണ് സംസാരിക്കുന്നത് Kubernetes-ലേക്ക് വിന്യസിക്കുമ്പോൾ എല്ലാവരും നേരിടുന്ന പ്രശ്നങ്ങളും വെല്ലുവിളികളും, അതുപോലെ പെട്ടെന്ന് ശ്രദ്ധയിൽപ്പെടാത്ത സൂക്ഷ്മതകളെക്കുറിച്ചും. സാധ്യമായ പരിഹാരങ്ങൾ വിശകലനം ചെയ്യുന്നതിലൂടെ, ഒരു ഓപ്പൺ സോഴ്സ് ടൂളിൽ ഇത് എങ്ങനെ നടപ്പിലാക്കുന്നുവെന്ന് ഞങ്ങൾ കാണിക്കുന്നു വെർഫ്.

അവതരണത്തിന് ശേഷം, ഞങ്ങളുടെ യൂട്ടിലിറ്റി (മുമ്പ് ഒരു ഡാപ്പ് എന്നറിയപ്പെട്ടിരുന്നു) ചരിത്രപരമായ ഒരു നാഴികക്കല്ലിൽ എത്തിയിരിക്കുന്നു GitHub-ൽ 1000 നക്ഷത്രങ്ങൾ - അതിന്റെ വർദ്ധിച്ചുവരുന്ന ഉപയോക്താക്കളുടെ കമ്മ്യൂണിറ്റി നിരവധി DevOps എഞ്ചിനീയർമാർക്കും ജീവിതം എളുപ്പമാക്കുമെന്ന് ഞങ്ങൾ പ്രതീക്ഷിക്കുന്നു.

അതിനാൽ, നമുക്ക് പരിചയപ്പെടുത്താം റിപ്പോർട്ടിന്റെ വീഡിയോ (~47 മിനിറ്റ്, ലേഖനത്തേക്കാൾ കൂടുതൽ വിജ്ഞാനപ്രദം) കൂടാതെ അതിൽ നിന്നുള്ള പ്രധാന എക്സ്ട്രാക്റ്റും ടെക്സ്റ്റ് രൂപത്തിൽ. പോകൂ!

കുബർനെറ്റസിന് കോഡ് ഡെലിവർ ചെയ്യുന്നു

സംസാരം ഇനി വെർഫിനെ കുറിച്ചല്ല, കുബെർനെറ്റസിലെ CI/CD നെക്കുറിച്ചായിരിക്കും, ഞങ്ങളുടെ സോഫ്റ്റ്‌വെയർ ഡോക്കർ കണ്ടെയ്‌നറുകളിൽ പാക്കേജ് ചെയ്‌തിരിക്കുന്നുവെന്ന് സൂചിപ്പിക്കുന്നു. (ഞാൻ ഇതിനെക്കുറിച്ച് സംസാരിച്ചു 2016 റിപ്പോർട്ട്), ഉൽപ്പാദനത്തിൽ ഇത് പ്രവർത്തിപ്പിക്കാൻ K8s ഉപയോഗിക്കും (ഇതിനെക്കുറിച്ച് കൂടുതൽ 2017 വർഷം).

കുബർനെറ്റസിൽ ഡെലിവറി എങ്ങനെയായിരിക്കും?

• കോഡും നിർമ്മാണത്തിനുള്ള നിർദ്ദേശങ്ങളും അടങ്ങിയ ഒരു Git ശേഖരം ഉണ്ട്. ആപ്ലിക്കേഷൻ ഒരു ഡോക്കർ ഇമേജിൽ നിർമ്മിച്ച് ഡോക്കർ രജിസ്ട്രിയിൽ പ്രസിദ്ധീകരിക്കുന്നു.
• ആപ്ലിക്കേഷൻ എങ്ങനെ വിന്യസിക്കാമെന്നും പ്രവർത്തിപ്പിക്കാമെന്നും ഉള്ള നിർദ്ദേശങ്ങളും ഇതേ ശേഖരത്തിൽ അടങ്ങിയിരിക്കുന്നു. വിന്യാസ ഘട്ടത്തിൽ, ഈ നിർദ്ദേശങ്ങൾ കുബർനെറ്റസിലേക്ക് അയയ്ക്കുന്നു, അത് രജിസ്ട്രിയിൽ നിന്ന് ആവശ്യമുള്ള ചിത്രം സ്വീകരിക്കുകയും അത് സമാരംഭിക്കുകയും ചെയ്യുന്നു.
• കൂടാതെ, സാധാരണയായി ടെസ്റ്റുകൾ ഉണ്ട്. ഒരു ചിത്രം പ്രസിദ്ധീകരിക്കുമ്പോൾ ഇവയിൽ ചിലത് ചെയ്യാവുന്നതാണ്. നിങ്ങൾക്ക് (അതേ നിർദ്ദേശങ്ങൾ പാലിച്ച്) ആപ്ലിക്കേഷന്റെ ഒരു പകർപ്പ് (ഒരു പ്രത്യേക K8s നെയിംസ്‌പെയ്‌സിലോ പ്രത്യേക ക്ലസ്റ്ററിലോ) വിന്യസിക്കാനും അവിടെ പരിശോധനകൾ നടത്താനും കഴിയും.
• അവസാനമായി, നിങ്ങൾക്ക് Git-ൽ നിന്ന് ഇവന്റുകൾ സ്വീകരിക്കുന്ന (അല്ലെങ്കിൽ ബട്ടൺ ക്ലിക്കുകൾ) എല്ലാ നിയുക്ത ഘട്ടങ്ങളിലേക്കും വിളിക്കുന്ന ഒരു CI സിസ്റ്റം ആവശ്യമാണ്: നിർമ്മിക്കുക, പ്രസിദ്ധീകരിക്കുക, വിന്യസിക്കുക, പരിശോധിക്കുക.

ചില പ്രധാന കുറിപ്പുകൾ ഇവിടെയുണ്ട്:

1. കാരണം നമുക്ക് മാറ്റമില്ലാത്ത അടിസ്ഥാന സൗകര്യമുണ്ട് (മാറ്റമില്ലാത്ത അടിസ്ഥാന സൗകര്യങ്ങൾ), എല്ലാ ഘട്ടങ്ങളിലും ഉപയോഗിക്കുന്ന ആപ്ലിക്കേഷൻ ഇമേജ് (സ്റ്റേജിംഗ്, പ്രൊഡക്ഷൻ മുതലായവ), ഒന്ന് ഉണ്ടായിരിക്കണം. ഞാൻ ഇതിനെക്കുറിച്ച് കൂടുതൽ വിശദമായും ഉദാഹരണങ്ങളുമായി സംസാരിച്ചു. ഇവിടെ.
2. കാരണം ഞങ്ങൾ അടിസ്ഥാന സൗകര്യങ്ങളെ കോഡ് സമീപനമായി പിന്തുടരുന്നു (ഐഎസി), ആപ്ലിക്കേഷൻ കോഡ്, അത് കൂട്ടിച്ചേർക്കുന്നതിനും സമാരംഭിക്കുന്നതിനുമുള്ള നിർദ്ദേശങ്ങൾ ആയിരിക്കണം കൃത്യമായി ഒരു ശേഖരത്തിൽ. ഇതിനെക്കുറിച്ചുള്ള കൂടുതൽ വിവരങ്ങൾക്ക്, കാണുക അതേ റിപ്പോർട്ട്.
3. ഡെലിവറി ചെയിൻ (ഡെലിവറി) ഞങ്ങൾ ഇത് സാധാരണയായി ഇതുപോലെയാണ് കാണുന്നത്: ആപ്ലിക്കേഷൻ അസംബിൾ ചെയ്തു, പരീക്ഷിച്ചു, റിലീസ് ചെയ്തു (റിലീസ് ഘട്ടം) അത്രയേയുള്ളൂ - ഡെലിവറി നടന്നു. എന്നാൽ വാസ്തവത്തിൽ, നിങ്ങൾ ഉരുട്ടിയത് ഉപയോക്താവിന് ലഭിക്കുന്നു, അല്ല പിന്നീട് നിങ്ങൾ അത് പ്രൊഡക്ഷനിലേക്ക് എത്തിച്ചപ്പോൾ, അയാൾക്ക് അവിടെ പോകാൻ കഴിഞ്ഞപ്പോൾ ഈ പ്രൊഡക്ഷൻ പ്രവർത്തിച്ചു. അതിനാൽ ഡെലിവറി ശൃംഖല അവസാനിക്കുമെന്ന് ഞാൻ വിശ്വസിക്കുന്നു പ്രവർത്തന ഘട്ടത്തിൽ മാത്രം (ഓട്ടം), അല്ലെങ്കിൽ കൂടുതൽ കൃത്യമായി പറഞ്ഞാൽ, ഉൽപ്പാദനത്തിൽ നിന്ന് കോഡ് നീക്കം ചെയ്ത നിമിഷത്തിൽ പോലും (അത് പുതിയൊരെണ്ണം ഉപയോഗിച്ച് മാറ്റിസ്ഥാപിക്കുന്നു).

കുബെർനെറ്റസിലെ മുകളിലുള്ള ഡെലിവറി സ്കീമിലേക്ക് നമുക്ക് മടങ്ങാം: ഇത് ഞങ്ങൾ മാത്രമല്ല, അക്ഷരാർത്ഥത്തിൽ ഈ പ്രശ്നം കൈകാര്യം ചെയ്ത എല്ലാവരും കണ്ടുപിടിച്ചതാണ്. വാസ്തവത്തിൽ, ഈ പാറ്റേൺ ഇപ്പോൾ GitOps എന്ന് വിളിക്കുന്നു (ഈ പദത്തെക്കുറിച്ചും അതിന്റെ പിന്നിലെ ആശയങ്ങളെക്കുറിച്ചും നിങ്ങൾക്ക് കൂടുതൽ വായിക്കാം ഇവിടെ). പദ്ധതിയുടെ ഘട്ടങ്ങൾ നോക്കാം.

സ്റ്റേജ് നിർമ്മിക്കുക

ഡോക്കർ ഫയലുകൾ എങ്ങനെ എഴുതാമെന്നും പ്രവർത്തിപ്പിക്കാമെന്നും എല്ലാവർക്കും അറിയാവുന്ന 2019-ൽ ഡോക്കർ ഇമേജുകൾ നിർമ്മിക്കുന്നതിനെക്കുറിച്ച് നിങ്ങൾക്ക് സംസാരിക്കാമെന്ന് തോന്നുന്നു docker build?.. ഞാൻ ശ്രദ്ധിക്കാൻ ആഗ്രഹിക്കുന്ന സൂക്ഷ്മതകൾ ഇതാ:

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

എല്ലാവരും അഭിമുഖീകരിക്കുന്ന മഞ്ഞുമലയുടെ അഗ്രം മാത്രമായിരുന്നു ഇത്. എന്നാൽ മറ്റ് പ്രശ്നങ്ങളുണ്ട്, പ്രത്യേകിച്ച്:

1. പലപ്പോഴും അസംബ്ലി ഘട്ടത്തിൽ നമുക്ക് എന്തെങ്കിലും ആവശ്യമാണ് മൗണ്ട് (ഉദാഹരണത്തിന്, apt പോലെയുള്ള ഒരു കമാൻഡിന്റെ ഫലം ഒരു മൂന്നാം കക്ഷി ഡയറക്ടറിയിൽ കാഷെ ചെയ്യുക).
2. ഞങ്ങൾ ആഗ്രഹിക്കുന്നു അസാധ്യം ഷെല്ലിൽ എഴുതുന്നതിനുപകരം.
3. ഞങ്ങൾ ആഗ്രഹിക്കുന്നു ഡോക്കർ ഇല്ലാതെ നിർമ്മിക്കുക (നമുക്ക് ഇതിനകം തന്നെ കണ്ടെയ്‌നറുകൾ പ്രവർത്തിപ്പിക്കാൻ കഴിയുന്ന ഒരു കുബർനെറ്റസ് ക്ലസ്റ്റർ ഉള്ളപ്പോൾ, ഇതിനായി എല്ലാം കോൺഫിഗർ ചെയ്യേണ്ട ഒരു അധിക വെർച്വൽ മെഷീൻ ആവശ്യമായി വരുന്നത് എന്തുകൊണ്ട്?).
4. സമാന്തര അസംബ്ലി, ഇത് വ്യത്യസ്ത രീതികളിൽ മനസ്സിലാക്കാം: ഡോക്കർഫയലിൽ നിന്നുള്ള വ്യത്യസ്ത കമാൻഡുകൾ (മൾട്ടി-സ്റ്റേജ് ഉപയോഗിച്ചിട്ടുണ്ടെങ്കിൽ), ഒരേ ശേഖരണത്തിന്റെ നിരവധി കമ്മിറ്റുകൾ, നിരവധി ഡോക്കർഫയലുകൾ.
5. വിതരണം ചെയ്ത അസംബ്ലി: "എഫിമെറൽ" ആയ കായ്കളിൽ കാര്യങ്ങൾ ശേഖരിക്കാൻ ഞങ്ങൾ ആഗ്രഹിക്കുന്നു അവരുടെ കാഷെ അപ്രത്യക്ഷമാകുന്നു, അതിനർത്ഥം അത് പ്രത്യേകം എവിടെയെങ്കിലും സൂക്ഷിക്കേണ്ടതുണ്ട് എന്നാണ്.
6. ഒടുവിൽ ആഗ്രഹങ്ങളുടെ പരകോടിക്ക് ഞാൻ പേരിട്ടു ഓട്ടോമാജിക്: റിപ്പോസിറ്ററിയിൽ പോയി കുറച്ച് കമാൻഡ് ടൈപ്പ് ചെയ്ത് ഒരു റെഡിമെയ്ഡ് ഇമേജ് നേടുന്നത് നല്ലതാണ്, എങ്ങനെ, എന്ത് ശരിയായി ചെയ്യണം എന്നതിനെക്കുറിച്ചുള്ള ധാരണയോടെ. എന്നിരുന്നാലും, എല്ലാ സൂക്ഷ്മതകളും ഈ രീതിയിൽ മുൻകൂട്ടി കാണാൻ കഴിയുമെന്ന് എനിക്ക് വ്യക്തിപരമായി ഉറപ്പില്ല.

കൂടാതെ പദ്ധതികൾ ഇതാ:

• moby/buildkit - ഈ പ്രശ്നങ്ങളെല്ലാം പരിഹരിക്കാൻ ശ്രമിക്കുന്ന ഡോക്കർ ഇങ്കിൽ നിന്നുള്ള ഒരു ബിൽഡർ (ഇതിനകം ഡോക്കറിന്റെ നിലവിലെ പതിപ്പുകളിലേക്ക് സംയോജിപ്പിച്ചിരിക്കുന്നു);
• കാണിക്കോ - ഡോക്കർ ഇല്ലാതെ നിർമ്മിക്കാൻ നിങ്ങളെ അനുവദിക്കുന്ന Google-ൽ നിന്നുള്ള ഒരു ബിൽഡർ;
• Buildpacks.io - ഓട്ടോമാറ്റിക് മാജിക് ഉണ്ടാക്കാനുള്ള CNCF ന്റെ ശ്രമം, പ്രത്യേകിച്ച്, ലെയറുകളുടെ റീബേസ് ഉള്ള രസകരമായ ഒരു പരിഹാരം;
• പോലുള്ള മറ്റ് യൂട്ടിലിറ്റികളുടെ ഒരു കൂട്ടം ബിൽഡ, genuinetools/imgപങ്ക് € |

... കൂടാതെ അവർക്ക് GitHub-ൽ എത്ര നക്ഷത്രങ്ങളുണ്ടെന്ന് നോക്കൂ. അതായത്, ഒരു വശത്ത് docker build നിലവിലുണ്ട്, എന്തെങ്കിലും ചെയ്യാൻ കഴിയും, പക്ഷേ വാസ്തവത്തിൽ പ്രശ്നം പൂർണ്ണമായും പരിഹരിച്ചിട്ടില്ല - ഇതര കളക്ടർമാരുടെ സമാന്തര വികസനമാണ് ഇതിന്റെ തെളിവ്, അവയിൽ ഓരോന്നും ചില പ്രശ്നങ്ങൾ പരിഹരിക്കുന്നു.

വെർഫിലെ അസംബ്ലി

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

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

രജിസ്ട്രിയിൽ പ്രസിദ്ധീകരിക്കുന്ന ഘട്ടം (പ്രസിദ്ധീകരിക്കുക)

ഞങ്ങൾ ഡയൽ ചെയ്തു docker push... - രജിസ്ട്രിയിലേക്ക് ഒരു ചിത്രം അപ്‌ലോഡ് ചെയ്യുന്നതിൽ എന്താണ് ബുദ്ധിമുട്ടുള്ളത്? തുടർന്ന് ചോദ്യം ഉയർന്നുവരുന്നു: "ചിത്രത്തിൽ ഞാൻ എന്ത് ടാഗ് ഇടണം?" നമുക്കുള്ള കാരണത്താലാണ് ഇത് ഉണ്ടാകുന്നത് Gitflow (അല്ലെങ്കിൽ മറ്റ് Git സ്ട്രാറ്റജി) കുബെർനെറ്റുകളും, വ്യവസായവും കുബർനെറ്റസിൽ സംഭവിക്കുന്നത് Git-ൽ സംഭവിക്കുന്നതിനെ പിന്തുടരുന്നുവെന്ന് ഉറപ്പാക്കാൻ ശ്രമിക്കുന്നു. എല്ലാത്തിനുമുപരി, Git മാത്രമാണ് നമ്മുടെ സത്യത്തിന്റെ ഉറവിടം.

ഇതിൽ എന്താണ് ഇത്ര ബുദ്ധിമുട്ടുള്ളത്? പുനരുൽപാദനക്ഷമത ഉറപ്പാക്കുക: Git-ലെ പ്രതിബദ്ധതയിൽ നിന്ന്, അത് മാറ്റമില്ലാത്ത സ്വഭാവമാണ് (മാറ്റമില്ലാത്തത്), ഒരു ഡോക്കർ ചിത്രത്തിലേക്ക്, അത് അതേപടി നിലനിർത്തണം.

അത് നമുക്കും പ്രധാനമാണ് ഉത്ഭവം നിർണ്ണയിക്കുക, കാരണം Kubernetes-ൽ പ്രവർത്തിക്കുന്ന ആപ്ലിക്കേഷൻ ഏത് കമ്മിറ്റിൽ നിന്നാണ് നിർമ്മിച്ചതെന്ന് മനസിലാക്കാൻ ഞങ്ങൾ ആഗ്രഹിക്കുന്നു (അപ്പോൾ നമുക്ക് വ്യത്യാസങ്ങളും സമാന കാര്യങ്ങളും ചെയ്യാം).

ടാഗിംഗ് തന്ത്രങ്ങൾ

ആദ്യത്തേത് ലളിതമാണ് git ടാഗ്. എന്ന് ടാഗ് ചെയ്‌ത ഒരു ചിത്രമുള്ള ഒരു രജിസ്‌ട്രി ഞങ്ങളുടെ പക്കലുണ്ട് 1.0. ഈ ചിത്രം അപ്‌ലോഡ് ചെയ്‌തിരിക്കുന്ന സ്റ്റേജും നിർമ്മാണവും കുബർനെറ്റസിനുണ്ട്. Git-ൽ നമ്മൾ കമ്മിറ്റ് ചെയ്യുകയും ചില ഘട്ടങ്ങളിൽ ടാഗ് ചെയ്യുകയും ചെയ്യുന്നു 2.0. റിപ്പോസിറ്ററിയിൽ നിന്നുള്ള നിർദ്ദേശങ്ങൾക്കനുസൃതമായി ഞങ്ങൾ അത് ശേഖരിക്കുകയും ടാഗ് ഉപയോഗിച്ച് രജിസ്ട്രിയിൽ സ്ഥാപിക്കുകയും ചെയ്യുന്നു 2.0. ഞങ്ങൾ അത് സ്റ്റേജിലേക്കും എല്ലാം ശരിയാണെങ്കിൽ ഉൽപ്പാദനത്തിലേക്കും മാറ്റുന്നു.

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

രണ്ടാമത്തെ ഓപ്ഷൻ - git കമ്മിറ്റ് + ടാഗ്. മാസ്റ്റർ ബ്രാഞ്ചിന് ഒരു ടാഗ് ഉണ്ട് 1.0; രജിസ്ട്രിയിൽ അതിനായി - നിർമ്മാണത്തിനായി വിന്യസിച്ചിരിക്കുന്ന ഒരു ചിത്രം. കൂടാതെ, കുബർനെറ്റസ് ക്ലസ്റ്ററിന് പ്രിവ്യൂ, സ്റ്റേജിംഗ് കോണ്ടൂർ എന്നിവയുണ്ട്. അടുത്തതായി ഞങ്ങൾ Gitflow പിന്തുടരുന്നു: വികസനത്തിനായുള്ള പ്രധാന ശാഖയിൽ (develop) ഞങ്ങൾ പുതിയ സവിശേഷതകൾ ഉണ്ടാക്കുന്നു, അതിന്റെ ഫലമായി ഐഡന്റിഫയറുമായുള്ള പ്രതിബദ്ധത #c1. ഈ ഐഡന്റിഫയർ ഉപയോഗിച്ച് ഞങ്ങൾ അത് ശേഖരിക്കുകയും രജിസ്ട്രിയിൽ പ്രസിദ്ധീകരിക്കുകയും ചെയ്യുന്നു (#c1). അതേ ഐഡന്റിഫയർ ഉപയോഗിച്ച് ഞങ്ങൾ തിരനോട്ടം നടത്തുന്നു. കമ്മിറ്റുകളുടെ കാര്യത്തിലും ഞങ്ങൾ അങ്ങനെ തന്നെ ചെയ്യുന്നു #c2 и #c3.

ആവശ്യത്തിന് സവിശേഷതകൾ ഉണ്ടെന്ന് ഞങ്ങൾ മനസ്സിലാക്കുമ്പോൾ, ഞങ്ങൾ എല്ലാം സ്ഥിരപ്പെടുത്താൻ തുടങ്ങുന്നു. Git-ൽ ഒരു ശാഖ ഉണ്ടാക്കുക release_1.1 (അടിസ്ഥാനത്തിൽ #c3 നിന്ന് develop). ഈ റിലീസ് ശേഖരിക്കേണ്ട ആവശ്യമില്ല, കാരണം... ഇത് മുമ്പത്തെ ഘട്ടത്തിൽ ചെയ്തു. അതിനാൽ, നമുക്ക് ഇത് സ്റ്റേജിലേക്ക് മാറ്റാം. ഞങ്ങൾ ബഗുകൾ പരിഹരിക്കുന്നു #c4 അതുപോലെ സ്റ്റേജിലേക്ക് റോൾ ഔട്ട്. അതേ സമയം, വികസനം നടക്കുന്നു develop, മാറ്റങ്ങൾ ഇടയ്ക്കിടെ എടുക്കുന്നത് release_1.1. ചില ഘട്ടങ്ങളിൽ, ഞങ്ങൾക്ക് ഒരു പ്രതിബദ്ധത സമാഹരിച്ച് സ്റ്റേജിലേക്ക് അപ്‌ലോഡ് ചെയ്യപ്പെടും, അതിൽ ഞങ്ങൾ സന്തുഷ്ടരാണ് (#c25).

തുടർന്ന് ഞങ്ങൾ റിലീസ് ബ്രാഞ്ച് (ഫാസ്റ്റ് ഫോർവേഡുമായി) ലയിപ്പിക്കുന്നു (release_1.1) മാസ്റ്ററിൽ. ഈ കമ്മിറ്റിൽ പുതിയ പതിപ്പിനൊപ്പം ഞങ്ങൾ ഒരു ടാഗ് ഇട്ടു (1.1). എന്നാൽ ഈ ചിത്രം ഇതിനകം രജിസ്ട്രിയിൽ ശേഖരിച്ചിട്ടുണ്ട്, അതിനാൽ ഇത് വീണ്ടും ശേഖരിക്കാതിരിക്കാൻ, നിലവിലുള്ള ചിത്രത്തിലേക്ക് ഞങ്ങൾ രണ്ടാമത്തെ ടാഗ് ചേർക്കുന്നു (ഇപ്പോൾ ഇതിന് രജിസ്ട്രിയിൽ ടാഗുകൾ ഉണ്ട്. #c25 и 1.1). അതിനുശേഷം, ഞങ്ങൾ അത് ഉൽപ്പാദിപ്പിക്കും.

സ്റ്റേജിലേക്ക് ഒരു ചിത്രം മാത്രമേ അപ്‌ലോഡ് ചെയ്‌തിട്ടുള്ളൂ എന്നൊരു പോരായ്മയുണ്ട് (#c25), നിർമ്മാണത്തിൽ ഇത് വ്യത്യസ്തമാണ് (1.1), എന്നാൽ "ശാരീരികമായി" ഇവ രജിസ്ട്രിയിൽ നിന്നുള്ള അതേ ചിത്രമാണെന്ന് ഞങ്ങൾക്കറിയാം.

ലയന കമ്മിറ്റുകൾക്ക് പിന്തുണയില്ല എന്നതാണ് യഥാർത്ഥ പോരായ്മ, നിങ്ങൾ വേഗത്തിൽ മുന്നോട്ട് പോകേണ്ടതുണ്ട്.

നമുക്ക് കൂടുതൽ മുന്നോട്ട് പോയി ഒരു ട്രിക്ക് ചെയ്യാം... നമുക്ക് ഒരു ലളിതമായ ഡോക്കർഫയലിന്റെ ഒരു ഉദാഹരണം നോക്കാം:

FROM ruby:2.3 as assets
RUN mkdir -p /app
WORKDIR /app
COPY . ./
RUN gem install bundler && bundle install
RUN bundle exec rake assets:precompile
CMD bundle exec puma -C config/puma.rb

FROM nginx:alpine
COPY --from=assets /app/public /usr/share/nginx/www/public

ഇനിപ്പറയുന്ന തത്വമനുസരിച്ച് അതിൽ നിന്ന് ഒരു ഫയൽ നിർമ്മിക്കാം:

• ഉപയോഗിച്ച ചിത്രങ്ങളുടെ ഐഡന്റിഫയറിൽ നിന്ന് SHA256 (ruby:2.3 и nginx:alpine), അവയുടെ ഉള്ളടക്കങ്ങളുടെ ചെക്ക്സം ആകുന്നു;
• എല്ലാ ടീമുകളും (RUN, CMD ഇത്യാദി.);
• ചേർത്ത ഫയലുകളിൽ നിന്ന് SHA256.

... കൂടാതെ അത്തരമൊരു ഫയലിൽ നിന്ന് ചെക്ക്സം (വീണ്ടും SHA256) എടുക്കുക. ഈ കയ്യൊപ്പ് ഡോക്കർ ഇമേജിന്റെ ഉള്ളടക്കം നിർവചിക്കുന്ന എല്ലാം.

നമുക്ക് ഡയഗ്രാമിലേക്കും തിരിച്ചും പോകാം കമ്മിറ്റുകൾക്ക് പകരം ഞങ്ങൾ അത്തരം ഒപ്പുകൾ ഉപയോഗിക്കും, അതായത്. ഒപ്പുകൾ ഉപയോഗിച്ച് ചിത്രങ്ങൾ ടാഗ് ചെയ്യുക.

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

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

വെർഫിൽ ടാഗുചെയ്യുന്നു

വെർഫിൽ ഞങ്ങൾ കൂടുതൽ മുന്നോട്ട് പോയി, ഒരു മെഷീനിൽ സൂക്ഷിക്കാത്ത ഒരു കാഷെ ഉപയോഗിച്ച് ഒരു ഡിസ്ട്രിബ്യൂട്ടഡ് ബിൽഡ് ചെയ്യാൻ തയ്യാറെടുക്കുകയാണ്... അതിനാൽ, ഞങ്ങൾ രണ്ട് തരം ഡോക്കർ ഇമേജുകൾ നിർമ്മിക്കുന്നു, ഞങ്ങൾ അവയെ വിളിക്കുന്നു സ്റ്റേജ് и ചിത്രം.

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

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

അങ്ങനെ, സ്റ്റേജ് ഇമേജുകൾ വിതരണം ചെയ്യാവുന്ന ഒരു കാഷെയാണ്, അതിൽ നിന്ന് ഇതിനകം സൃഷ്ടിച്ച ചിത്രങ്ങൾ ഡോക്കർ രജിസ്ട്രിയിലേക്ക് അപ്ലോഡ് ചെയ്യുന്നു.

രജിസ്ട്രി വൃത്തിയാക്കുന്നു

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

ശുചീകരണ തന്ത്രങ്ങൾ എന്തൊക്കെയാണ്?

1. നിങ്ങൾക്ക് ഒന്നും ചെയ്യാൻ കഴിയില്ല വൃത്തിയാക്കരുത്. ടാഗുകളുടെ ഒരു വലിയ കുരുക്ക് അഴിക്കുന്നതിനേക്കാൾ ചിലപ്പോൾ അധിക സ്ഥലത്തിനായി കുറച്ച് പണം നൽകുന്നത് വളരെ എളുപ്പമാണ്. എന്നാൽ ഇത് ഒരു നിശ്ചിത പോയിന്റ് വരെ മാത്രമേ പ്രവർത്തിക്കൂ.
2. പൂർണ്ണമായ പുനഃസജ്ജീകരണം. നിങ്ങൾ എല്ലാ ചിത്രങ്ങളും ഇല്ലാതാക്കുകയും CI സിസ്റ്റത്തിൽ നിലവിലുള്ളവ മാത്രം പുനർനിർമ്മിക്കുകയും ചെയ്താൽ, ഒരു പ്രശ്നം ഉണ്ടാകാം. നിർമ്മാണത്തിൽ കണ്ടെയ്നർ പുനരാരംഭിക്കുകയാണെങ്കിൽ, അതിനായി ഒരു പുതിയ ചിത്രം ലോഡ് ചെയ്യും - ഇതുവരെ ആരും പരീക്ഷിച്ചിട്ടില്ലാത്ത ഒന്ന്. ഇത് മാറ്റമില്ലാത്ത അടിസ്ഥാന സൗകര്യങ്ങൾ എന്ന ആശയത്തെ ഇല്ലാതാക്കുന്നു.
3. നീല പച്ച. ഒരു രജിസ്ട്രി ഓവർഫ്ലോ തുടങ്ങി - ഞങ്ങൾ ചിത്രങ്ങൾ മറ്റൊന്നിലേക്ക് അപ്‌ലോഡ് ചെയ്യുന്നു. മുമ്പത്തെ രീതിയിലെ അതേ പ്രശ്നം: ഓവർഫ്ലോ ചെയ്യാൻ തുടങ്ങിയ രജിസ്ട്രി ഏത് ഘട്ടത്തിലാണ് നിങ്ങൾക്ക് മായ്‌ക്കാൻ കഴിയുക?
4. സമയം. ഒരു മാസത്തിലധികം പഴക്കമുള്ള എല്ലാ ചിത്രങ്ങളും ഇല്ലാതാക്കണോ? എന്നാൽ ഒരു മാസമായി അപ്ഡേറ്റ് ചെയ്യാത്ത ഒരു സേവനം തീർച്ചയായും ഉണ്ടാകും...
5. സ്വമേധയാ ഇതിനകം ഇല്ലാതാക്കാൻ കഴിയുന്നവ നിർണ്ണയിക്കുക.

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

നമ്മൾ എന്തിലേക്കാണ് വന്നത് വെർഫ്? ഞങ്ങൾ ശേഖരിക്കുന്നു:

1. Git head: എല്ലാ ടാഗുകളും, എല്ലാ ശാഖകളും - ചിത്രങ്ങളിൽ Git-ൽ ടാഗ് ചെയ്തിരിക്കുന്നതെല്ലാം നമുക്ക് ആവശ്യമാണെന്ന് കരുതുക (അല്ലെങ്കിൽ, Git-ൽ തന്നെ അത് ഇല്ലാതാക്കേണ്ടതുണ്ട്);
2. നിലവിൽ കുബർനെറ്റസിലേക്ക് പമ്പ് ചെയ്യുന്ന എല്ലാ കായ്കളും;
3. പഴയ ReplicaSets (അടുത്തിടെ റിലീസ് ചെയ്തത്), കൂടാതെ Helm റിലീസുകൾ സ്കാൻ ചെയ്യാനും അവിടെ ഏറ്റവും പുതിയ ചിത്രങ്ങൾ തിരഞ്ഞെടുക്കാനും ഞങ്ങൾ പദ്ധതിയിടുന്നു.

... കൂടാതെ ഈ സെറ്റിൽ നിന്ന് ഒരു വൈറ്റ്‌ലിസ്റ്റ് ഉണ്ടാക്കുക - ഞങ്ങൾ ഇല്ലാതാക്കാത്ത ചിത്രങ്ങളുടെ ഒരു ലിസ്റ്റ്. മറ്റെല്ലാം ഞങ്ങൾ വൃത്തിയാക്കുന്നു, അതിനുശേഷം ഞങ്ങൾ അനാഥ സ്റ്റേജ് ചിത്രങ്ങൾ കണ്ടെത്തി അവയും ഇല്ലാതാക്കുന്നു.

ഘട്ടം വിന്യസിക്കുക

വിശ്വസനീയമായ പ്രഖ്യാപനം

വിന്യാസത്തിൽ ഞാൻ ശ്രദ്ധ ആകർഷിക്കാൻ ആഗ്രഹിക്കുന്ന ആദ്യ പോയിന്റ്, ഡിക്ലറേറ്റീവ് ആയി പ്രഖ്യാപിച്ച, അപ്ഡേറ്റ് ചെയ്ത റിസോഴ്സ് കോൺഫിഗറേഷന്റെ റോൾഔട്ട് ആണ്. Kubernetes ഉറവിടങ്ങൾ വിവരിക്കുന്ന യഥാർത്ഥ YAML പ്രമാണം ക്ലസ്റ്ററിൽ യഥാർത്ഥത്തിൽ പ്രവർത്തിക്കുന്ന ഫലത്തിൽ നിന്ന് വളരെ വ്യത്യസ്തമാണ്. കാരണം, കോൺഫിഗറേഷനിലേക്ക് Kubernetes ചേർക്കുന്നു:

1. ഐഡന്റിഫയറുകൾ;
2. സേവന വിവരം;
3. നിരവധി സ്ഥിര മൂല്യങ്ങൾ;
4. നിലവിലെ നിലയുള്ള വിഭാഗം;
5. അഡ്മിഷൻ വെബ്ഹുക്കിന്റെ ഭാഗമായി വരുത്തിയ മാറ്റങ്ങൾ;
6. വിവിധ കൺട്രോളറുകളുടെ (ഒപ്പം ഷെഡ്യൂളറുടെയും) പ്രവർത്തനത്തിന്റെ ഫലം.

അതിനാൽ, ഒരു പുതിയ റിസോഴ്സ് കോൺഫിഗറേഷൻ ദൃശ്യമാകുമ്പോൾ (പുതിയ), നിലവിലുള്ള, “തത്സമയ” കോൺഫിഗറേഷൻ എടുത്ത് പുനരാലേഖനം ചെയ്യാൻ ഞങ്ങൾക്ക് കഴിയില്ല (ജീവിക്കൂ). ഇത് ചെയ്യുന്നതിന്, നമ്മൾ താരതമ്യം ചെയ്യേണ്ടതുണ്ട് പുതിയ അവസാനം പ്രയോഗിച്ച കോൺഫിഗറേഷൻ ഉപയോഗിച്ച് (അവസാനം പ്രയോഗിച്ചത്) ഒപ്പം ഉരുട്ടുക ജീവിക്കൂ പാച്ച് ലഭിച്ചു.

ഈ സമീപനത്തെ വിളിക്കുന്നു 2-വേ ലയനം. ഉദാഹരണത്തിന്, ഹെൽമിൽ ഇത് ഉപയോഗിക്കുന്നു.

അവിടെയും ഉണ്ട് 3-വേ ലയനം, അതിൽ വ്യത്യാസമുണ്ട്:

• താരതമ്യം ചെയ്യുന്നു അവസാനം പ്രയോഗിച്ചത് и പുതിയ, എന്താണ് ഇല്ലാതാക്കിയതെന്ന് ഞങ്ങൾ നോക്കുന്നു;
• താരതമ്യം ചെയ്യുന്നു പുതിയ и ജീവിക്കൂ, എന്താണ് ചേർത്തത് അല്ലെങ്കിൽ മാറ്റിയത് എന്ന് ഞങ്ങൾ നോക്കുന്നു;
• സംഗ്രഹ പാച്ച് പ്രയോഗിക്കുന്നു ജീവിക്കൂ.

ഞങ്ങൾ ഹെൽമിനൊപ്പം 1000+ ആപ്ലിക്കേഷനുകൾ വിന്യസിക്കുന്നു, അതിനാൽ ഞങ്ങൾ യഥാർത്ഥത്തിൽ 2-വേ ലയനത്തിലൂടെയാണ് ജീവിക്കുന്നത്. എന്നിരുന്നാലും, ഞങ്ങളുടെ പാച്ചുകൾ ഉപയോഗിച്ച് ഞങ്ങൾ പരിഹരിച്ച നിരവധി പ്രശ്‌നങ്ങളുണ്ട്, ഇത് സാധാരണയായി പ്രവർത്തിക്കാൻ ഹെൽമിനെ സഹായിക്കുന്നു.

യഥാർത്ഥ റോൾഔട്ട് നില

ഞങ്ങളുടെ CI സിസ്റ്റം അടുത്ത ഇവന്റിനെ അടിസ്ഥാനമാക്കി Kubernetes-നായി ഒരു പുതിയ കോൺഫിഗറേഷൻ സൃഷ്ടിച്ച ശേഷം, അത് ഉപയോഗത്തിനായി അത് കൈമാറുന്നു (അപേക്ഷിക്കുക) ഒരു ക്ലസ്റ്ററിലേക്ക് - ഹെൽം ഉപയോഗിച്ച് അല്ലെങ്കിൽ kubectl apply. അടുത്തതായി, ഇതിനകം വിവരിച്ച N-way ലയനം സംഭവിക്കുന്നു, അതിന് Kubernetes API CI സിസ്റ്റത്തിനും അതിന്റെ ഉപയോക്താവിനും അംഗീകാരം നൽകുന്നു.

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

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

വിന്യാസത്തിലോ സ്റ്റേറ്റ്ഫുൾസെറ്റുകളിലോ സ്ഥാപിച്ചിട്ടുള്ള വ്യാഖ്യാനങ്ങൾ ഉപയോഗിച്ചാണ് വെർഫ് തലത്തിലുള്ള ഈ ട്രാക്കറിന്റെ പെരുമാറ്റം കോൺഫിഗർ ചെയ്തിരിക്കുന്നത്. പ്രധാന വ്യാഖ്യാനം - fail-mode - ഇനിപ്പറയുന്ന അർത്ഥങ്ങൾ മനസ്സിലാക്കുന്നു:

• IgnoreAndContinueDeployProcess - ഈ ഘടകം പുറത്തെടുക്കുന്നതിലെ പ്രശ്നങ്ങൾ ഞങ്ങൾ അവഗണിക്കുകയും വിന്യാസം തുടരുകയും ചെയ്യുന്നു;
• FailWholeDeployProcessImmediately - ഈ ഘടകത്തിലെ ഒരു പിശക് വിന്യാസ പ്രക്രിയ നിർത്തുന്നു;
• HopeUntilEndOfDeployProcess - വിന്യാസത്തിന്റെ അവസാനത്തോടെ ഈ ഘടകം പ്രവർത്തിക്കുമെന്ന് ഞങ്ങൾ പ്രതീക്ഷിക്കുന്നു.

ഉദാഹരണത്തിന്, ഉറവിടങ്ങളുടെയും വ്യാഖ്യാന മൂല്യങ്ങളുടെയും ഈ സംയോജനം fail-mode:

ഞങ്ങൾ ആദ്യമായി വിന്യസിക്കുമ്പോൾ, ഡാറ്റാബേസ് (MongoDB) ഇതുവരെ തയ്യാറായേക്കില്ല - വിന്യാസങ്ങൾ പരാജയപ്പെടും. എന്നാൽ അത് ആരംഭിക്കുന്നതിനുള്ള നിമിഷത്തിനായി നിങ്ങൾക്ക് കാത്തിരിക്കാം, വിന്യാസം തുടർന്നും നടക്കും.

വെർഫിലെ കുബെഡോഗിന് രണ്ട് വ്യാഖ്യാനങ്ങൾ കൂടിയുണ്ട്:

• failures-allowed-per-replica - ഓരോ പകർപ്പിനും അനുവദനീയമായ വീഴ്ചകളുടെ എണ്ണം;
• show-logs-until - ഉരുട്ടിയ എല്ലാ പോഡുകളിൽ നിന്നും വെർഫ് (stdout-ൽ) ലോഗുകൾ കാണിക്കുന്ന നിമിഷം നിയന്ത്രിക്കുന്നു. സ്ഥിരസ്ഥിതിയാണ് PodIsReady (പോഡിലേക്ക് ട്രാഫിക്ക് വരാൻ തുടങ്ങുമ്പോൾ നമുക്ക് ആവശ്യമില്ലാത്ത സന്ദേശങ്ങൾ അവഗണിക്കാൻ), എന്നാൽ മൂല്യങ്ങളും സാധുവാണ്: ControllerIsReady и EndOfDeploy.

വിന്യാസത്തിൽ നിന്ന് നമുക്ക് മറ്റെന്താണ് വേണ്ടത്?

ഇതിനകം വിവരിച്ച രണ്ട് പോയിന്റുകൾക്ക് പുറമേ, ഞങ്ങൾ ആഗ്രഹിക്കുന്നു:

• കാണാൻ രേഖകൾ - ആവശ്യമുള്ളവ മാത്രം, ഒരു നിരയിലെ എല്ലാം അല്ല;
• ട്രാക്ക് പുരോഗതി, കാരണം ജോലി നിരവധി മിനിറ്റ് "നിശബ്ദമായി" തൂങ്ങിക്കിടക്കുകയാണെങ്കിൽ, അവിടെ എന്താണ് സംഭവിക്കുന്നതെന്ന് മനസ്സിലാക്കേണ്ടത് പ്രധാനമാണ്;
• ഉണ്ട് ഓട്ടോമാറ്റിക് റോൾബാക്ക് എന്തെങ്കിലും തെറ്റ് സംഭവിച്ചാൽ (അതിനാൽ വിന്യാസത്തിന്റെ യഥാർത്ഥ നില അറിയുന്നത് വളരെ പ്രധാനമാണ്). റോൾഔട്ട് ആറ്റോമിക് ആയിരിക്കണം: ഒന്നുകിൽ അത് അവസാനം വരെ പോകുന്നു, അല്ലെങ്കിൽ എല്ലാം അതിന്റെ മുൻ നിലയിലേക്ക് മടങ്ങുന്നു.

ഫലങ്ങൾ

ഒരു കമ്പനിയെന്ന നിലയിൽ, വിവരിച്ച എല്ലാ സൂക്ഷ്മതകളും ഡെലിവറിയുടെ വിവിധ ഘട്ടങ്ങളിൽ നടപ്പിലാക്കാൻ (ബിൽഡ്, പബ്ലിഷ്, വിന്യസിക്കുക), ഒരു സിഐ സിസ്റ്റവും യൂട്ടിലിറ്റിയും മതി. വെർഫ്.

ഒരു നിഗമനത്തിന് പകരം:

Werf-ന്റെ സഹായത്തോടെ, DevOps എഞ്ചിനീയർമാർക്കുള്ള ധാരാളം പ്രശ്‌നങ്ങൾ പരിഹരിക്കുന്നതിൽ ഞങ്ങൾ നല്ല പുരോഗതി കൈവരിച്ചു, കൂടാതെ വിശാലമായ കമ്മ്യൂണിറ്റിയെങ്കിലും ഈ യൂട്ടിലിറ്റി പ്രവർത്തനത്തിൽ പരീക്ഷിച്ചാൽ സന്തോഷിക്കും. ഒരുമിച്ച് ഒരു നല്ല ഫലം നേടുന്നത് എളുപ്പമായിരിക്കും.

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

പ്രകടനത്തിൽ നിന്നുള്ള വീഡിയോ (~47 മിനിറ്റ്):

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

പി.എസ്

ഞങ്ങളുടെ ബ്ലോഗിലെ കുബർനെറ്റസിനെക്കുറിച്ചുള്ള മറ്റ് റിപ്പോർട്ടുകൾ:

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

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