ഒരു പതിപ്പ് ഡോക്യുമെന്റേഷൻ സൈറ്റിന്റെ ഉദാഹരണം ഉപയോഗിച്ച് വെർഫിനൊപ്പം ഡൈനാമിക് അസംബ്ലിയും ഡോക്കർ ചിത്രങ്ങളുടെ വിന്യാസവും

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

സൈറ്റ് ഘടനയുടെ സൂക്ഷ്മതകളിലേക്ക് പോകുക: എല്ലാ പതിപ്പുകൾക്കും ഒരു പൊതു മെനു സൃഷ്ടിക്കുന്നു, റിലീസുകളെക്കുറിച്ചുള്ള വിവരങ്ങളുള്ള പേജുകൾ മുതലായവ. - ഞങ്ങൾ ചെയ്യില്ല. പകരം, ഡൈനാമിക് അസംബ്ലിയുടെ പ്രശ്നങ്ങളും സവിശേഷതകളും ഒപ്പം സിഐ/സിഡി പ്രോസസുകളിൽ അല്പം ശ്രദ്ധ കേന്ദ്രീകരിക്കാം.

ആമുഖം: സൈറ്റ് എങ്ങനെ പ്രവർത്തിക്കുന്നു

ആരംഭിക്കുന്നതിന്, വെർഫ് ഡോക്യുമെന്റേഷൻ അതിന്റെ കോഡിനൊപ്പം സംഭരിച്ചിരിക്കുന്നു. ഇത് പൊതുവെ ഈ ലേഖനത്തിന്റെ പരിധിക്കപ്പുറമുള്ള ചില വികസന ആവശ്യകതകൾ ചുമത്തുന്നു, എന്നാൽ ചുരുങ്ങിയത് ഇങ്ങനെ പറയാം:

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

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

വെബ്‌സൈറ്റിലെ പതിപ്പ് തിരഞ്ഞെടുക്കൽ മെനുവിൽ, വെർഫിന്റെ ഏറ്റവും പുതിയ പതിപ്പുകൾ ഓരോ ചാനലിലും ലഭ്യമാണ്. സ്ഥിരസ്ഥിതിയായി, വിലാസമനുസരിച്ച് werf.io/documentation ഏറ്റവും പുതിയ റിലീസിനായുള്ള ഏറ്റവും സ്ഥിരതയുള്ള ചാനലിന്റെ പതിപ്പ് തുറക്കുന്നു - ഇത് തിരയൽ എഞ്ചിനുകളും സൂചികയിലാക്കിയിരിക്കുന്നു. ചാനലിനായുള്ള ഡോക്യുമെന്റേഷൻ പ്രത്യേക വിലാസങ്ങളിൽ ലഭ്യമാണ് (ഉദാഹരണത്തിന്, werf.io/v1.0-beta/documentation ബീറ്റ റിലീസിനായി 1.0).

മൊത്തത്തിൽ, സൈറ്റിന് ഇനിപ്പറയുന്ന പതിപ്പുകൾ ലഭ്യമാണ്:

1. റൂട്ട് (സ്ഥിരസ്ഥിതിയായി തുറക്കുന്നു),
2. ഓരോ റിലീസിന്റെയും ഓരോ സജീവ അപ്‌ഡേറ്റ് ചാനലിനും (ഉദാഹരണത്തിന്, werf.io/v1.0-beta).

ഒരു സൈറ്റിന്റെ ഒരു പ്രത്യേക പതിപ്പ് ജനറേറ്റുചെയ്യുന്നതിന്, പൊതുവേ, അത് ഉപയോഗിച്ച് കംപൈൽ ചെയ്താൽ മതിയാകും ജെക്കിൾഡയറക്ടറിയിൽ പ്രവർത്തിപ്പിക്കുന്നതിലൂടെ /docs werf repository അനുബന്ധ കമാൻഡ് (jekyll build), ആവശ്യമുള്ള പതിപ്പിന്റെ Git ടാഗിലേക്ക് മാറിയ ശേഷം.

ഇത് ചേർക്കാൻ മാത്രം അവശേഷിക്കുന്നു:

• യൂട്ടിലിറ്റി തന്നെ (വെർഫ്) അസംബ്ലിക്കായി ഉപയോഗിക്കുന്നു;
• CI/CD പ്രക്രിയകൾ GitLab CI യുടെ അടിസ്ഥാനത്തിലാണ് നിർമ്മിച്ചിരിക്കുന്നത്;
• ഇതെല്ലാം തീർച്ചയായും കുബർനെറ്റസിൽ പ്രവർത്തിക്കുന്നു.

ചുമതലകൾ

ഇപ്പോൾ വിവരിച്ച എല്ലാ സവിശേഷതകളും കണക്കിലെടുക്കുന്ന ടാസ്ക്കുകൾ രൂപപ്പെടുത്താം:

1. ഏതെങ്കിലും അപ്‌ഡേറ്റ് ചാനലിൽ വെർഫ് പതിപ്പ് മാറ്റിയ ശേഷം സൈറ്റിലെ ഡോക്യുമെന്റേഷൻ സ്വയമേവ അപ്ഡേറ്റ് ചെയ്യണം.
2. വികസനത്തിന് നിങ്ങൾക്ക് ചിലപ്പോൾ കഴിയേണ്ടതുണ്ട് സൈറ്റിന്റെ പ്രിവ്യൂ പതിപ്പുകൾ കാണുക.

അനുബന്ധ Git ടാഗുകളിൽ നിന്ന് ഏതെങ്കിലും ചാനലിലെ പതിപ്പ് മാറ്റിയതിന് ശേഷം സൈറ്റ് വീണ്ടും കംപൈൽ ചെയ്യണം, എന്നാൽ ചിത്രം നിർമ്മിക്കുന്ന പ്രക്രിയയിൽ നമുക്ക് ഇനിപ്പറയുന്ന സവിശേഷതകൾ ലഭിക്കും:

• ചാനലുകളിലെ പതിപ്പുകളുടെ ലിസ്റ്റ് മാറുന്നതിനാൽ, പതിപ്പ് മാറിയ ചാനലുകൾക്കുള്ള ഡോക്യുമെന്റേഷൻ പുനർനിർമ്മിക്കേണ്ടത് ആവശ്യമാണ്. എല്ലാത്തിനുമുപരി, എല്ലാം വീണ്ടും പുനർനിർമ്മിക്കുന്നത് വളരെ നല്ലതല്ല.
• റിലീസുകൾക്കുള്ള ചാനലുകളുടെ സെറ്റ് മാറിയേക്കാം. ചില സമയങ്ങളിൽ, ഉദാഹരണത്തിന്, ആദ്യകാല ആക്സസ് 1.1 റിലീസിനേക്കാൾ സ്ഥിരതയുള്ള ഒരു പതിപ്പ് ചാനലുകളിൽ ഉണ്ടാകണമെന്നില്ല, എന്നാൽ കാലക്രമേണ അവ ദൃശ്യമാകും - ഈ സാഹചര്യത്തിൽ, നിങ്ങൾ അസംബ്ലി സ്വമേധയാ മാറ്റേണ്ടതല്ലേ?

അത് മാറുകയാണ് അസംബ്ലി ബാഹ്യ ഡാറ്റ മാറ്റുന്നതിനെ ആശ്രയിച്ചിരിക്കുന്നു.

നടപ്പാക്കൽ

ഒരു സമീപനം തിരഞ്ഞെടുക്കുന്നു

പകരമായി, നിങ്ങൾക്ക് ആവശ്യമായ ഓരോ പതിപ്പും പ്രത്യേക പോഡായി കുബർനെറ്റസിൽ പ്രവർത്തിപ്പിക്കാം. ഈ ഓപ്‌ഷൻ ക്ലസ്റ്ററിലെ ഒബ്‌ജക്റ്റുകളുടെ ഒരു വലിയ സംഖ്യയെ സൂചിപ്പിക്കുന്നു, ഇത് സ്ഥിരതയുള്ള വെർഫ് റിലീസുകളുടെ എണ്ണം കൂടുന്നതിനനുസരിച്ച് വളരും. ഇത് കൂടുതൽ സങ്കീർണ്ണമായ അറ്റകുറ്റപ്പണികളെ സൂചിപ്പിക്കുന്നു: ഓരോ പതിപ്പിനും അതിന്റേതായ HTTP സെർവറും ഒരു ചെറിയ ലോഡും ഉണ്ട്. തീർച്ചയായും, ഇത് കൂടുതൽ വിഭവ ചെലവുകൾ ഉൾക്കൊള്ളുന്നു.

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

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

werf vs git ക്ലോണും പുരാവസ്തുക്കളും

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

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

ജെക്കിൽ സ്റ്റാറ്റിക് ഡാറ്റ കംപൈൽ ചെയ്യുന്നതിനായി രൂപകല്പന ചെയ്ത ഒരു ടൂൾ ആയതിനാൽ അവസാന ചിത്രത്തിൽ ആവശ്യമില്ല, ഇത് കംപൈൽ ചെയ്യുന്നത് യുക്തിസഹമായിരിക്കും. വെർഫ് ആർട്ടിഫാക്റ്റ്, അവസാന ചിത്രത്തിലേക്ക് സമാഹാര ഫലം മാത്രം ഇറക്കുമതി ചെയ്യുക.

ഞങ്ങൾ werf.yaml എഴുതുന്നു

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

werf നിങ്ങളെ ഉപയോഗിക്കാൻ അനുവദിക്കുന്നു ടെംപ്ലേറ്റുകളിലേക്ക് പോകുക നിങ്ങളുടെ കോൺഫിഗറേഷൻ ഫയലിൽ (werf.yaml), ഇത് സാധ്യമാക്കുന്നു ഈച്ചയിൽ കോൺഫിഗറേഷൻ സൃഷ്ടിക്കുക ബാഹ്യ ഡാറ്റയെ ആശ്രയിച്ച് (നിങ്ങൾക്ക് എന്താണ് വേണ്ടത്!). ഞങ്ങളുടെ കേസിലെ ബാഹ്യ ഡാറ്റ പതിപ്പുകളെയും റിലീസുകളെയും കുറിച്ചുള്ള വിവരങ്ങളാണ്, അതിന്റെ അടിസ്ഥാനത്തിൽ ഞങ്ങൾ ആവശ്യമായ പുരാവസ്തുക്കൾ ശേഖരിക്കുകയും അതിന്റെ ഫലമായി ഞങ്ങൾക്ക് രണ്ട് ചിത്രങ്ങൾ ലഭിക്കുകയും ചെയ്യുന്നു: werf-doc и werf-dev വ്യത്യസ്ത സർക്യൂട്ടുകളിൽ പ്രവർത്തിക്കാൻ.

പരിസ്ഥിതി വേരിയബിളുകളിലൂടെയാണ് ബാഹ്യ ഡാറ്റ കൈമാറുന്നത്. അവയുടെ ഘടന ഇതാ:

• RELEASES - റിലീസുകളുടെ ഒരു ലിസ്റ്റും വെർഫിന്റെ നിലവിലെ പതിപ്പും ഉള്ള ഒരു വരി, ഫോർമാറ്റിലുള്ള മൂല്യങ്ങളുടെ ഇടം-വേർതിരിക്കപ്പെട്ട പട്ടികയുടെ രൂപത്തിൽ <НОМЕР_РЕЛИЗА>%<НОМЕР_ВЕРСИИ>. ഉദാഹരണം: 1.0%v1.0.4-beta.20
• CHANNELS - ചാനലുകളുടെ ഒരു ലിസ്റ്റും വെർഫിന്റെ നിലവിലെ പതിപ്പും ഉള്ള ഒരു വരി, ഫോർമാറ്റിലുള്ള മൂല്യങ്ങളുടെ ഇടം-വേർതിരിക്കപ്പെട്ട പട്ടികയുടെ രൂപത്തിൽ <КАНАЛ>%<НОМЕР_ВЕРСИИ>. ഉദാഹരണം: 1.0-beta%v1.0.4-beta.20 1.0-alpha%v1.0.5-alpha.22
• ROOT_VERSION — സൈറ്റിൽ സ്ഥിരസ്ഥിതിയായി പ്രദർശിപ്പിക്കേണ്ട werf റിലീസ് പതിപ്പ് (എല്ലായ്‌പ്പോഴും ഏറ്റവും ഉയർന്ന റിലീസ് നമ്പർ ഉപയോഗിച്ച് ഡോക്യുമെന്റേഷൻ പ്രദർശിപ്പിക്കേണ്ട ആവശ്യമില്ല). ഉദാഹരണം: v1.0.4-beta.20
• REVIEW_SHA - ടെസ്റ്റ് ലൂപ്പിനായി നിങ്ങൾ പതിപ്പ് നിർമ്മിക്കേണ്ട റിവ്യൂ കമ്മിറ്റിന്റെ ഹാഷ്.

ഈ വേരിയബിളുകൾ GitLab CI പൈപ്പ്‌ലൈനിൽ പൂരിപ്പിക്കും, എങ്ങനെ കൃത്യമായി താഴെ എഴുതിയിരിക്കുന്നു.

ഒന്നാമതായി, സൗകര്യാർത്ഥം ഞങ്ങൾ നിർവചിക്കുന്നു werf.yaml ടെംപ്ലേറ്റ് വേരിയബിളുകളിലേക്ക് പോകുക, പരിസ്ഥിതി വേരിയബിളുകളിൽ നിന്ന് അവയ്ക്ക് മൂല്യങ്ങൾ നൽകുക:

{{ $_ := set . "WerfVersions" (cat (env "CHANNELS") (env "RELEASES") | splitList " ") }}
{{ $Root := . }}
{{ $_ := set . "WerfRootVersion" (env "ROOT_VERSION") }}
{{ $_ := set . "WerfReviewCommit" (env "REVIEW_SHA") }}

സൈറ്റിന്റെ സ്റ്റാറ്റിക് പതിപ്പ് കംപൈൽ ചെയ്യുന്നതിനുള്ള ആർട്ടിഫാക്റ്റിന്റെ വിവരണം നമുക്ക് ആവശ്യമുള്ള എല്ലാ സാഹചര്യങ്ങളിലും (റൂട്ട് പതിപ്പ് സൃഷ്ടിക്കുന്നതും ഡെവലപ്പ് സർക്യൂട്ടിന്റെ പതിപ്പും ഉൾപ്പെടെ) പൊതുവെ സമാനമാണ്. അതിനാൽ, ഫംഗ്ഷൻ ഉപയോഗിച്ച് ഞങ്ങൾ അതിനെ ഒരു പ്രത്യേക ബ്ലോക്കിലേക്ക് മാറ്റും define - തുടർന്നുള്ള ഉപയോഗത്തിനായി include. ഇനിപ്പറയുന്ന ആർഗ്യുമെന്റുകൾ ഞങ്ങൾ ടെംപ്ലേറ്റിലേക്ക് കൈമാറും:

• Version - സൃഷ്ടിച്ച പതിപ്പ് (ടാഗ് നാമം);
• Channel - ആർട്ടിഫാക്റ്റ് സൃഷ്ടിച്ച അപ്ഡേറ്റ് ചാനലിന്റെ പേര്;
• Commit - ഹാഷ് കമ്മിറ്റ് ചെയ്യുക, ഒരു റിവ്യൂ കമ്മിറ്റിനായി ആർട്ടിഫാക്റ്റ് സൃഷ്‌ടിച്ചതാണെങ്കിൽ;
• സന്ദർഭം.

ആർട്ടിഫാക്റ്റ് ടെംപ്ലേറ്റ് വിവരണം

{{- define "doc_artifact" -}}
{{- $Root := index . "Root" -}}
artifact: doc-{{ .Channel }}
from: jekyll/builder:3
mount:
- from: build_dir
  to: /usr/local/bundle
ansible:
  install:
  - shell: |
      export PATH=/usr/jekyll/bin/:$PATH
  - name: "Install Dependencies"
    shell: bundle install
    args:
      executable: /bin/bash
      chdir: /app/docs
  beforeSetup:
{{- if .Commit }}
  - shell: echo "Review SHA - {{ .Commit }}."
{{- end }}
{{- if eq .Channel "root" }}
  - name: "releases.yml HASH: {{ $Root.Files.Get "releases.yml" | sha256sum }}"
    copy:
      content: |
{{ $Root.Files.Get "releases.yml" | indent 8 }}
      dest:  /app/docs/_data/releases.yml
{{- else }}
  - file:
      path: /app/docs/_data/releases.yml
      state: touch
{{- end }}
  - file:
      path: "{{`{{ item }}`}}"
      state: directory
      mode: 0777
    with_items:
    - /app/main_site/
    - /app/ru_site/
  - file:
      dest: /app/docs/pages_ru/cli
      state: link
      src: /app/docs/pages/cli
  - shell: |
      echo -e "werfVersion: {{ .Version }}nwerfChannel: {{ .Channel }}" > /tmp/_config_additional.yml
      export PATH=/usr/jekyll/bin/:$PATH
{{- if and (ne .Version "review") (ne .Channel "root") }}
{{- $_ := set . "BaseURL" ( printf "v%s" .Channel ) }}
{{- else if ne .Channel "root" }}
{{- $_ := set . "BaseURL" .Channel }}
{{- end }}
      jekyll build -s /app/docs  -d /app/_main_site/{{ if .BaseURL }} --baseurl /{{ .BaseURL }}{{ end }} --config /app/docs/_config.yml,/tmp/_config_additional.yml
      jekyll build -s /app/docs  -d /app/_ru_site/{{ if .BaseURL }} --baseurl /{{ .BaseURL }}{{ end }} --config /app/docs/_config.yml,/app/docs/_config_ru.yml,/tmp/_config_additional.yml
    args:
      executable: /bin/bash
      chdir: /app/docs
git:
- url: https://github.com/flant/werf.git
  to: /app/
  owner: jekyll
  group: jekyll
{{- if .Commit }}
  commit: {{ .Commit }}
{{- else }}
  tag: {{ .Version }}
{{- end }}
  stageDependencies:
    install: ['docs/Gemfile','docs/Gemfile.lock']
    beforeSetup: '**/*'
  includePaths: 'docs'
  excludePaths: '**/*.sh'
{{- end }}

പുരാവസ്തു നാമം അദ്വിതീയമായിരിക്കണം. ഉദാഹരണത്തിന്, ചാനലിന്റെ പേര് (വേരിയബിളിന്റെ മൂല്യം) ചേർത്ത് നമുക്ക് ഇത് നേടാനാകും .Channel) പുരാവസ്തുവിന്റെ പേരിന്റെ പ്രത്യയമായി: artifact: doc-{{ .Channel }}. എന്നാൽ പുരാവസ്തുക്കളിൽ നിന്ന് ഇറക്കുമതി ചെയ്യുമ്പോൾ, നിങ്ങൾ അതേ പേരുകൾ പരാമർശിക്കേണ്ടതുണ്ട് എന്ന് നിങ്ങൾ മനസ്സിലാക്കേണ്ടതുണ്ട്.

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

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

സോപാധിക പ്രസ്താവന ഉപയോഗിച്ചാണ് ഇത് നടപ്പിലാക്കുന്നത് if ടെംപ്ലേറ്റുകളും ഡിസൈനുകളും പോകുക {{ $Root.Files.Get "releases.yml" | sha256sum }} ഘട്ടത്തിൽ ഘട്ടങ്ങൾ. ഇത് ഇനിപ്പറയുന്ന രീതിയിൽ പ്രവർത്തിക്കുന്നു: റൂട്ട് പതിപ്പിനായി ഒരു ആർട്ടിഫാക്റ്റ് നിർമ്മിക്കുമ്പോൾ (വേരിയബിൾ .Channel എന്നതിന് തുല്യമാണ് root) ഫയൽ ഹാഷ് releases.yml മുഴുവൻ ഘട്ടത്തിന്റെയും ഒപ്പിനെ ബാധിക്കുന്നു, കാരണം ഇത് അൻസിബിൾ ടാസ്ക്കിന്റെ പേരിന്റെ ഭാഗമാണ് (പാരാമീറ്റർ name). അങ്ങനെ, മാറുമ്പോൾ ഉള്ളടക്കം ഫയൽ releases.yml അനുബന്ധ പുരാവസ്തു വീണ്ടും കൂട്ടിച്ചേർക്കും.

ഒരു ബാഹ്യ ശേഖരത്തിൽ പ്രവർത്തിക്കാനും ദയവായി ശ്രദ്ധിക്കുക. നിന്നുള്ള ഒരു പുരാവസ്തുവിന്റെ ചിത്രത്തിൽ werf ശേഖരം, ഡയറക്ടറി മാത്രമേ ചേർത്തിട്ടുള്ളൂ /docs, കൂടാതെ പാസായ പാരാമീറ്ററുകളെ ആശ്രയിച്ച്, ആവശ്യമായ ടാഗിന്റെയോ അവലോകന കമ്മിറ്റിന്റെയോ ഡാറ്റ ഉടനടി ചേർക്കുന്നു.

ചാനലുകളുടെയും റിലീസുകളുടെയും കൈമാറ്റം ചെയ്ത പതിപ്പുകളുടെ ആർട്ടിഫാക്റ്റിന്റെ വിവരണം സൃഷ്ടിക്കാൻ ആർട്ടിഫാക്റ്റ് ടെംപ്ലേറ്റ് ഉപയോഗിക്കുന്നതിന്, ഞങ്ങൾ വേരിയബിളിൽ ഒരു ലൂപ്പ് സംഘടിപ്പിക്കുന്നു. .WerfVersions в werf.yaml:

{{ range .WerfVersions -}}
{{ $VersionsDict := splitn "%" 2 . -}}
{{ dict "Version" $VersionsDict._1 "Channel" $VersionsDict._0 "Root" $Root | include "doc_artifact" }}
---
{{ end -}}

കാരണം ലൂപ്പ് നിരവധി പുരാവസ്തുക്കൾ സൃഷ്ടിക്കും (ഞങ്ങൾ അങ്ങനെ പ്രതീക്ഷിക്കുന്നു), അവയ്ക്കിടയിലുള്ള സെപ്പറേറ്റർ കണക്കിലെടുക്കേണ്ടത് ആവശ്യമാണ് - ക്രമം --- (കോൺഫിഗറേഷൻ ഫയൽ വാക്യഘടനയെക്കുറിച്ചുള്ള കൂടുതൽ വിവരങ്ങൾക്ക്, കാണുക പ്രമാണീകരണം). നേരത്തെ നിർവചിച്ചതുപോലെ, ഒരു ലൂപ്പിൽ ഒരു ടെംപ്ലേറ്റ് വിളിക്കുമ്പോൾ, ഞങ്ങൾ പതിപ്പ് പാരാമീറ്ററുകൾ, URL, റൂട്ട് സന്ദർഭം എന്നിവ കൈമാറുന്നു.

അതുപോലെ, എന്നാൽ ഒരു ലൂപ്പ് ഇല്ലാതെ, "പ്രത്യേക കേസുകൾ" എന്നതിനായുള്ള ആർട്ടിഫാക്റ്റ് ടെംപ്ലേറ്റിനെ ഞങ്ങൾ വിളിക്കുന്നു: റൂട്ട് പതിപ്പിനും അതുപോലെ അവലോകനത്തിൽ നിന്നുള്ള പതിപ്പിനും:

{{ dict "Version" .WerfRootVersion "Channel" "root" "Root" $Root  | include "doc_artifact" }}
---
{{- if .WerfReviewCommit }}
{{ dict "Version" "review" "Channel" "review" "Commit" .WerfReviewCommit "Root" $Root  | include "doc_artifact" }}
{{- end }}

വേരിയബിൾ സജ്ജമാക്കിയാൽ മാത്രമേ റിവ്യൂ കമ്മിറ്റിനുള്ള ആർട്ടിഫാക്റ്റ് നിർമ്മിക്കപ്പെടുകയുള്ളൂ എന്നത് ശ്രദ്ധിക്കുക .WerfReviewCommit.

പുരാവസ്തുക്കൾ തയ്യാറാണ് - ഇറക്കുമതി ആരംഭിക്കാനുള്ള സമയമാണിത്!

Kubernetes-ൽ പ്രവർത്തിക്കാൻ രൂപകൽപ്പന ചെയ്‌ത അവസാന ചിത്രം, സെർവർ കോൺഫിഗറേഷൻ ഫയൽ ചേർത്ത ഒരു സാധാരണ NGINX ആണ്. nginx.conf പുരാവസ്തുക്കളിൽ നിന്നുള്ള സ്റ്റാറ്റിക്. സൈറ്റിന്റെ റൂട്ട് പതിപ്പിന്റെ ആർട്ടിഫാക്റ്റിന് പുറമേ, വേരിയബിളിൽ ഞങ്ങൾ ലൂപ്പ് ആവർത്തിക്കേണ്ടതുണ്ട് .WerfVersions ചാനലിന്റെ പുരാവസ്തുക്കൾ ഇറക്കുമതി ചെയ്യുന്നതിനും പതിപ്പുകൾ പുറത്തിറക്കുന്നതിനും + ഞങ്ങൾ നേരത്തെ സ്വീകരിച്ച ആർട്ടിഫാക്‌റ്റ് നാമകരണ നിയമം പാലിക്കുക. ഓരോ ആർട്ടിഫാക്‌റ്റും രണ്ട് ഭാഷകൾക്കായി സൈറ്റിന്റെ പതിപ്പുകൾ സംഭരിക്കുന്നതിനാൽ, കോൺഫിഗറേഷൻ നൽകുന്ന സ്ഥലങ്ങളിലേക്ക് ഞങ്ങൾ അവ ഇറക്കുമതി ചെയ്യുന്നു.

അവസാന ചിത്രത്തിന്റെ വിവരണം werf-doc

image: werf-doc
from: nginx:stable-alpine
ansible:
  setup:
  - name: "Setup /etc/nginx/nginx.conf"
    copy:
      content: |
{{ .Files.Get ".werf/nginx.conf" | indent 8 }}
      dest: /etc/nginx/nginx.conf
  - file:
      path: "{{`{{ item }}`}}"
      state: directory
      mode: 0777
    with_items:
    - /app/main_site/assets
    - /app/ru_site/assets
import:
- artifact: doc-root
  add: /app/_main_site
  to: /app/main_site
  before: setup
- artifact: doc-root
  add: /app/_ru_site
  to: /app/ru_site
  before: setup
{{ range .WerfVersions -}}
{{ $VersionsDict := splitn "%" 2 . -}}
{{ $Channel := $VersionsDict._0 -}}
{{ $Version := $VersionsDict._1 -}}
- artifact: doc-{{ $Channel }}
  add: /app/_main_site
  to: /app/main_site/v{{ $Channel }}
  before: setup
{{ end -}}
{{ range .WerfVersions -}}
{{ $VersionsDict := splitn "%" 2 . -}}
{{ $Channel := $VersionsDict._0 -}}
{{ $Version := $VersionsDict._1 -}}
- artifact: doc-{{ $Channel }}
  add: /app/_ru_site
  to: /app/ru_site/v{{ $Channel }}
  before: setup
{{ end -}}

പ്രധാന ചിത്രത്തിനൊപ്പം ഡെവ് സർക്യൂട്ടിൽ സമാരംഭിച്ച അധിക ഇമേജിൽ സൈറ്റിന്റെ രണ്ട് പതിപ്പുകൾ മാത്രമേ അടങ്ങിയിട്ടുള്ളൂ: അവലോകന കമ്മിറ്റിൽ നിന്നുള്ള പതിപ്പും സൈറ്റിന്റെ റൂട്ട് പതിപ്പും (പൊതു അസറ്റുകൾ ഉണ്ട്, നിങ്ങൾ ഓർക്കുന്നുണ്ടെങ്കിൽ , ഡാറ്റ റിലീസ് ചെയ്യുക). അതിനാൽ, അധിക ചിത്രം ഇറക്കുമതി വിഭാഗത്തിൽ മാത്രം പ്രധാനമായതിൽ നിന്ന് വ്യത്യസ്തമായിരിക്കും (തീർച്ചയായും, പേരിൽ):

image: werf-dev
...
import:
- artifact: doc-root
  add: /app/_main_site
  to: /app/main_site
  before: setup
- artifact: doc-root
  add: /app/_ru_site
  to: /app/ru_site
  before: setup
{{- if .WerfReviewCommit  }}
- artifact: doc-review
  add: /app/_main_site
  to: /app/main_site/review
  before: setup
- artifact: doc-review
  add: /app/_ru_site
  to: /app/ru_site/review
  before: setup
{{- end }}

മുകളിൽ സൂചിപ്പിച്ചതുപോലെ, സെറ്റ് എൻവയോൺമെന്റ് വേരിയബിൾ റൺ ചെയ്യുമ്പോൾ മാത്രമേ റിവ്യൂ കമ്മിറ്റിനുള്ള ആർട്ടിഫാക്റ്റ് ജനറേറ്റ് ചെയ്യപ്പെടുകയുള്ളൂ REVIEW_SHA. എൻവയോൺമെന്റ് വേരിയബിൾ ഇല്ലെങ്കിൽ werf-dev ഇമേജ് സൃഷ്ടിക്കാതിരിക്കാൻ സാധിക്കും REVIEW_SHA, എന്നാൽ ക്രമത്തിൽ നയങ്ങളാൽ വൃത്തിയാക്കൽ werf-ലെ ഡോക്കർ ഇമേജുകൾ werf-dev ഇമേജിനായി പ്രവർത്തിച്ചു, പൈപ്പ്‌ലൈൻ ഘടന ലളിതമാക്കുന്നതിന്, റൂട്ട് പതിപ്പ് ആർട്ടിഫാക്റ്റ് (ഇത് ഇതിനകം തന്നെ നിർമ്മിച്ചതാണ്) ഉപയോഗിച്ച് മാത്രം നിർമ്മിക്കാൻ ഞങ്ങൾ അത് വിടും.

അസംബ്ലി തയ്യാറാണ്! നമുക്ക് സിഐ/സിഡിയിലേക്കും പ്രധാനപ്പെട്ട സൂക്ഷ്മതകളിലേക്കും പോകാം.

GitLab CI-യിലെ പൈപ്പ്ലൈനും ഡൈനാമിക് ബിൽഡിന്റെ സവിശേഷതകളും

ബിൽഡ് പ്രവർത്തിപ്പിക്കുമ്പോൾ നമ്മൾ ഉപയോഗിക്കുന്ന പരിസ്ഥിതി വേരിയബിളുകൾ സജ്ജീകരിക്കേണ്ടതുണ്ട് werf.yaml. REVIEW_SHA വേരിയബിളിന് ഇത് ബാധകമല്ല, GitHub ഹുക്കിൽ നിന്ന് പൈപ്പ്ലൈനിലേക്ക് വിളിക്കുമ്പോൾ ഞങ്ങൾ സജ്ജീകരിക്കും.

ആവശ്യമായ ബാഹ്യ ഡാറ്റ ഞങ്ങൾ ഒരു ബാഷ് സ്ക്രിപ്റ്റിൽ സൃഷ്ടിക്കും generate_artifacts, ഇത് രണ്ട് GitLab പൈപ്പ്ലൈൻ ആർട്ടിഫാക്റ്റുകൾ സൃഷ്ടിക്കും:

• ഫയൽ releases.yml റിലീസ് ഡാറ്റയോടൊപ്പം,
• ഫയൽ common_envs.sh, കയറ്റുമതി ചെയ്യേണ്ട പരിസ്ഥിതി വേരിയബിളുകൾ അടങ്ങിയിരിക്കുന്നു.

ഫയൽ ഉള്ളടക്കം generate_artifacts നിങ്ങൾ ഞങ്ങളുടെ കണ്ടെത്തും ഉദാഹരണങ്ങളുള്ള ശേഖരങ്ങൾ. ഡാറ്റ സ്വീകരിക്കുന്നത് ലേഖനത്തിന്റെ വിഷയമല്ല, ഫയലാണ് common_envs.sh ഞങ്ങൾക്ക് പ്രധാനമാണ്, കാരണം വെർഫിന്റെ ജോലി അതിനെ ആശ്രയിച്ചിരിക്കുന്നു. അതിന്റെ ഉള്ളടക്കത്തിന്റെ ഒരു ഉദാഹരണം:

export RELEASES='1.0%v1.0.6-4'
export CHANNELS='1.0-alpha%v1.0.7-1 1.0-beta%v1.0.7-1 1.0-ea%v1.0.6-4 1.0-stable%v1.0.6-4 1.0-rock-solid%v1.0.6-4'
export ROOT_VERSION='v1.0.6-4'

നിങ്ങൾക്ക് അത്തരം ഒരു സ്ക്രിപ്റ്റിന്റെ ഔട്ട്പുട്ട് ഉപയോഗിക്കാം, ഉദാഹരണത്തിന്, ബാഷ് ഫംഗ്ഷൻ ഉപയോഗിച്ച് source.

ഇപ്പോൾ രസകരമായ ഭാഗം വരുന്നു. ആപ്ലിക്കേഷന്റെ നിർമ്മാണവും വിന്യാസവും ശരിയായി പ്രവർത്തിക്കുന്നതിന്, അത് ഉറപ്പാക്കേണ്ടത് ആവശ്യമാണ് werf.yaml ആയിരുന്നു അതുതന്നെ കുറഞ്ഞത് ഒരു പൈപ്പ് ലൈനിനുള്ളിൽ. ഈ വ്യവസ്ഥ പാലിച്ചില്ലെങ്കിൽ, അസംബ്ലി സമയത്ത് വെർഫ് കണക്കാക്കുന്ന ഘട്ടങ്ങളുടെ ഒപ്പുകൾ വ്യത്യസ്തമായിരിക്കും, ഉദാഹരണത്തിന്, വിന്യാസം. ഇത് ഒരു വിന്യാസ പിശകിലേക്ക് നയിക്കും, കാരണം... വിന്യാസത്തിന് ആവശ്യമായ ചിത്രം കാണില്ല.

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

തലമുറ എങ്കിൽ werf.yaml ബാഹ്യ ഡാറ്റയെ ആശ്രയിച്ചിരിക്കുന്നു (ഉദാഹരണത്തിന്, നിലവിലെ പതിപ്പുകളുടെ ഒരു ലിസ്റ്റ്, ഞങ്ങളുടെ കാര്യത്തിലെന്നപോലെ), അത്തരം ഡാറ്റയുടെ ഘടനയും മൂല്യങ്ങളും പൈപ്പ്ലൈനിനുള്ളിൽ രേഖപ്പെടുത്തണം. ബാഹ്യ പാരാമീറ്ററുകൾ ഇടയ്ക്കിടെ മാറുകയാണെങ്കിൽ ഇത് വളരെ പ്രധാനമാണ്.

ഞങ്ങൾ ചെയ്യും ബാഹ്യ ഡാറ്റ സ്വീകരിക്കുകയും രേഖപ്പെടുത്തുകയും ചെയ്യുക GitLab-ലെ പൈപ്പ്ലൈനിന്റെ ആദ്യ ഘട്ടത്തിൽ (പ്രീബിൽഡ്) കൂടാതെ അവ ഫോമിൽ കൂടുതൽ കൈമാറുക GitLab CI ആർട്ടിഫാക്റ്റ്. ഇതേ കോൺഫിഗറേഷനിൽ പൈപ്പ്‌ലൈൻ ജോലികൾ (ബിൽഡ്, ഡിപ്ലോയ്, ക്ലീനപ്പ്) പ്രവർത്തിപ്പിക്കാനും പുനരാരംഭിക്കാനും ഇത് നിങ്ങളെ അനുവദിക്കും. werf.yaml.

സ്റ്റേജിന്റെ ഉള്ളടക്കം പ്രീബിൽഡ് ഫയൽ .gitlab-ci.yml:

Prebuild:
  stage: prebuild
  script:
    - bash ./generate_artifacts 1> common_envs.sh
    - cat ./common_envs.sh
  artifacts:
    paths:
      - releases.yml
      - common_envs.sh
    expire_in: 2 week

ആർട്ടിഫാക്‌റ്റിലെ ബാഹ്യ ഡാറ്റ ക്യാപ്‌ചർ ചെയ്‌ത ശേഷം, നിങ്ങൾക്ക് സ്റ്റാൻഡേർഡ് GitLab CI പൈപ്പ്‌ലൈൻ ഘട്ടങ്ങൾ ഉപയോഗിച്ച് നിർമ്മിക്കാനും വിന്യസിക്കാനും കഴിയും: നിർമ്മിക്കുകയും വിന്യസിക്കുകയും ചെയ്യുക. GitHub werf റിപ്പോസിറ്ററിയിൽ നിന്നുള്ള കൊളുത്തുകൾ ഉപയോഗിച്ച് ഞങ്ങൾ പൈപ്പ്ലൈൻ തന്നെ സമാരംഭിക്കുന്നു (അതായത്, GitHub-ലെ റിപ്പോസിറ്ററിയിൽ മാറ്റങ്ങൾ വരുമ്പോൾ). വിഭാഗത്തിലെ GitLab പ്രോജക്റ്റ് പ്രോപ്പർട്ടികളിൽ അവയ്ക്കുള്ള ഡാറ്റ കണ്ടെത്താനാകും CI/CD ക്രമീകരണങ്ങൾ -> പൈപ്പ്ലൈൻ ട്രിഗറുകൾ, തുടർന്ന് GitHub-ൽ അനുബന്ധ Webhook സൃഷ്ടിക്കുക (ക്രമീകരണങ്ങൾ -> Webhooks).

നിർമ്മാണ ഘട്ടം ഇതുപോലെ കാണപ്പെടും:

Build:
  stage: build
  script:
    - type multiwerf && . $(multiwerf use 1.0 alpha --as-file)
    - type werf && source <(werf ci-env gitlab --tagging-strategy tag-or-branch --verbose)
    - source common_envs.sh
    - werf build-and-publish --stages-storage :local
  except:
    refs:
      - schedules
  dependencies:
    - Prebuild

സ്റ്റേജിൽ നിന്ന് നിർമ്മാണ ഘട്ടത്തിലേക്ക് GitLab രണ്ട് പുരാവസ്തുക്കൾ ചേർക്കും പ്രീബിൽഡ്, അതിനാൽ ഞങ്ങൾ കൺസ്ട്രക്‌റ്റ് ഉപയോഗിച്ച് തയ്യാറാക്കിയ ഇൻപുട്ട് ഡാറ്റ ഉപയോഗിച്ച് വേരിയബിളുകൾ എക്‌സ്‌പോർട്ട് ചെയ്യുന്നു source common_envs.sh. ഒരു ഷെഡ്യൂൾ അനുസരിച്ച് പൈപ്പ്ലൈൻ സമാരംഭിക്കുന്നത് ഒഴികെ എല്ലാ സാഹചര്യങ്ങളിലും ഞങ്ങൾ നിർമ്മാണ ഘട്ടം ആരംഭിക്കുന്നു. ഷെഡ്യൂൾ അനുസരിച്ച്, വൃത്തിയാക്കലിനായി ഞങ്ങൾ ഒരു പൈപ്പ്ലൈൻ പ്രവർത്തിപ്പിക്കും - ഈ സാഹചര്യത്തിൽ അസംബ്ലി നടത്തേണ്ട ആവശ്യമില്ല.

വിന്യാസ ഘട്ടത്തിൽ, ഞങ്ങൾ രണ്ട് ജോലികൾ വിവരിക്കും - ഒരു YAML ടെംപ്ലേറ്റ് ഉപയോഗിച്ച് പ്രൊഡക്ഷൻ, ഡെവ് സർക്യൂട്ടുകൾ എന്നിവയിലേക്ക് വിന്യാസത്തിനായി വെവ്വേറെ:

.base_deploy: &base_deploy
  stage: deploy
  script:
    - type multiwerf && . $(multiwerf use 1.0 alpha --as-file)
    - type werf && source <(werf ci-env gitlab --tagging-strategy tag-or-branch --verbose)
    - source common_envs.sh
    - werf deploy --stages-storage :local
  dependencies:
    - Prebuild
  except:
    refs:
      - schedules

Deploy to Production:
  <<: *base_deploy
  variables:
    WERF_KUBE_CONTEXT: prod
  environment:
    name: production
    url: werf.io
  only:
    refs:
      - master
  except:
    variables:
      - $REVIEW_SHA
    refs:
      - schedules

Deploy to Test:
  <<: *base_deploy
  variables:
    WERF_KUBE_CONTEXT: dev
  environment:
    name: test
    url: werf.test.flant.com
  except:
    refs:
      - schedules
  only:
    variables:
      - $REVIEW_SHA

വെർഫ് വിന്യാസം നടത്തേണ്ട ക്ലസ്റ്റർ സന്ദർഭം സൂചിപ്പിക്കുന്നതിൽ മാത്രമാണ് ടാസ്‌ക്കുകൾ വ്യത്യാസപ്പെട്ടിരിക്കുന്നത് (WERF_KUBE_CONTEXT), കൂടാതെ ലൂപ്പ് എൻവയോൺമെന്റ് വേരിയബിളുകൾ ക്രമീകരിക്കുക (environment.name и environment.url), അത് പിന്നീട് ഹെൽം ചാർട്ട് ടെംപ്ലേറ്റുകളിൽ ഉപയോഗിക്കുന്നു. ടെംപ്ലേറ്റുകളുടെ ഉള്ളടക്കം ഞങ്ങൾ നൽകില്ല, കാരണം... പ്രസ്തുത വിഷയത്തിൽ രസകരമായി ഒന്നുമില്ല, എന്നാൽ നിങ്ങൾക്ക് അവ കണ്ടെത്താനാകും ലേഖനത്തിനായുള്ള ശേഖരങ്ങൾ.

അന്തിമ സ്‌പർശനം

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

നടപ്പിലാക്കാൻ നിങ്ങൾക്ക് ഇത് ആവശ്യമാണ്:

• ഒരു ക്ലീനിംഗ് ഘട്ടം ചേർക്കുക .gitlab-ci.yml;
• ഒരു ക്ലീനിംഗ് ടാസ്ക്കിന്റെ ആനുകാലിക നിർവ്വഹണം ചേർക്കുക;
• ഒരു റൈറ്റ് ആക്സസ് ടോക്കൺ ഉപയോഗിച്ച് ഒരു പരിസ്ഥിതി വേരിയബിൾ സജ്ജീകരിക്കുക.

ഒരു ക്ലീനിംഗ് സ്റ്റേജ് ചേർക്കുന്നു .gitlab-ci.yml:

Cleanup:
  stage: cleanup
  script:
    - type multiwerf && . $(multiwerf use 1.0 alpha --as-file)
    - type werf && source <(werf ci-env gitlab --tagging-strategy tag-or-branch --verbose)
    - source common_envs.sh
    - docker login -u nobody -p ${WERF_IMAGES_CLEANUP_PASSWORD} ${WERF_IMAGES_REPO}
    - werf cleanup --stages-storage :local
  only:
    refs:
      - schedules

ഇതെല്ലാം ഞങ്ങൾ ഇതിനകം തന്നെ അൽപ്പം ഉയർന്നതായി കണ്ടിട്ടുണ്ട് - ഇത് വൃത്തിയാക്കാൻ മാത്രം നിങ്ങൾ ആദ്യം ഡോക്കർ രജിസ്ട്രിയിലെ ചിത്രങ്ങൾ ഇല്ലാതാക്കാൻ അവകാശമുള്ള ഒരു ടോക്കൺ ഉപയോഗിച്ച് ഡോക്കർ രജിസ്ട്രിയിലേക്ക് ലോഗിൻ ചെയ്യേണ്ടതുണ്ട് (സ്വയമേവ നൽകുന്ന GitLab CI ടാസ്‌ക് ടോക്കൺ അങ്ങനെയല്ല. അത്തരം അവകാശങ്ങൾ ഉണ്ട്). ടോക്കൺ മുൻകൂട്ടി GitLab-ൽ സൃഷ്ടിക്കുകയും അതിന്റെ മൂല്യം പരിസ്ഥിതി വേരിയബിളിൽ വ്യക്തമാക്കുകയും വേണം. WERF_IMAGES_CLEANUP_PASSWORD പദ്ധതി (CI/CD ക്രമീകരണങ്ങൾ -> വേരിയബിളുകൾ).

ആവശ്യമായ ഷെഡ്യൂളിനൊപ്പം ഒരു ക്ലീനിംഗ് ടാസ്‌ക് ചേർക്കുന്നത് പൂർത്തിയായി CI/CD ->
ഷെഡ്യൂൾ.

അത്രയേയുള്ളൂ: ഡോക്കർ രജിസ്ട്രിയിലെ ഒരു പ്രോജക്റ്റ് ഉപയോഗിക്കാത്ത ചിത്രങ്ങളിൽ നിന്ന് നിരന്തരം വളരുകയില്ല.

പ്രായോഗിക ഭാഗത്തിന്റെ അവസാനം, ലേഖനത്തിൽ നിന്നുള്ള മുഴുവൻ ലിസ്റ്റിംഗുകളും ലഭ്യമാണ് എന്ന് ഞാൻ നിങ്ങളെ ഓർമ്മിപ്പിക്കട്ടെ Git:

• .gitlab-ci.yml;
• werf.yaml.

ഫലം

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

കണ്ടെത്തലുകൾ

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

പി.എസ്

ഞങ്ങളുടെ ബ്ലോഗിലും വായിക്കുക:

• «Kubernetes-ലേക്ക് ഒരു പുതിയ ആപ്ലിക്കേഷൻ റിലീസ് നൽകുമ്പോൾ കമാൻഡുകൾ പ്രവർത്തിപ്പിക്കുന്നു";
• «werf, GitLab CI എന്നിവ ഉപയോഗിച്ച് ഒരേ തരത്തിലുള്ള മൈക്രോസർവീസുകൾ നിർമ്മിക്കുകയും വിന്യസിക്കുകയും ചെയ്യുക";
• «സങ്കീർണ്ണമായ ഹെൽം ചാർട്ടുകൾ പുറത്തിറക്കാൻ വെർഫ് ഉപയോഗിക്കുന്നു";
• «werf 1.0 സ്റ്റേബിൾ അവതരിപ്പിക്കുന്നു: GitOps-ന് എന്താണ്, സ്റ്റാറ്റസും പ്ലാനുകളും".

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