werf 1.1 റിലീസ്: ഇന്ന് ബിൽഡർക്കുള്ള മെച്ചപ്പെടുത്തലുകളും ഭാവിയിലേക്കുള്ള പദ്ധതികളും

വെർഫ് Kubernetes-ലേക്ക് ആപ്ലിക്കേഷനുകൾ നിർമ്മിക്കുന്നതിനും വിതരണം ചെയ്യുന്നതിനുമുള്ള ഞങ്ങളുടെ ഓപ്പൺ സോഴ്‌സ് GitOps CLI യൂട്ടിലിറ്റിയാണ്. വാഗ്ദാനപ്രകാരം, പതിപ്പ് v1.0 റിലീസ് werf-ലേക്ക് പുതിയ സവിശേഷതകൾ ചേർക്കുന്നതിനും പരമ്പരാഗത സമീപനങ്ങൾ പരിഷ്കരിക്കുന്നതിനും തുടക്കം കുറിച്ചു. ഇപ്പോൾ റിലീസ് v1.1 അവതരിപ്പിക്കുന്നതിൽ ഞങ്ങൾക്ക് സന്തോഷമുണ്ട്, ഇത് വികസനത്തിലെ ഒരു വലിയ ചുവടുവയ്പ്പും ഭാവിയിലേക്കുള്ള അടിത്തറയുമാണ് കളക്ടർ വെർഫ്. പതിപ്പ് നിലവിൽ ലഭ്യമാണ് ചാനൽ 1.1 EA.

റിലീസിൻ്റെ അടിസ്ഥാനം സ്റ്റേജ് സ്റ്റോറേജിൻ്റെ പുതിയ ആർക്കിടെക്ചറും രണ്ട് കളക്ടർമാരുടെ പ്രവർത്തനത്തിൻ്റെ ഒപ്റ്റിമൈസേഷനുമാണ് (സ്റ്റേപ്പലിനും ഡോക്കർഫൈലിനും). ഒന്നിലധികം ഹോസ്റ്റുകളിൽ നിന്നും ഒരേ ഹോസ്റ്റിൽ സമാന്തര അസംബ്ലികളിൽ നിന്നും വിതരണം ചെയ്ത അസംബ്ലികൾ നടപ്പിലാക്കുന്നതിനുള്ള സാധ്യത പുതിയ സ്റ്റോറേജ് ആർക്കിടെക്ചർ തുറക്കുന്നു.

ജോലിയുടെ ഒപ്റ്റിമൈസേഷനിൽ സ്റ്റേജ് സിഗ്നേച്ചറുകൾ കണക്കാക്കുന്ന ഘട്ടത്തിൽ അനാവശ്യ കണക്കുകൂട്ടലുകൾ ഒഴിവാക്കുന്നതും കൂടുതൽ കാര്യക്ഷമമായവയിലേക്ക് ഫയൽ ചെക്ക്സം കണക്കാക്കുന്നതിനുള്ള സംവിധാനങ്ങൾ മാറ്റുന്നതും ഉൾപ്പെടുന്നു. ഈ ഒപ്റ്റിമൈസേഷൻ വെർഫ് ഉപയോഗിച്ച് പ്രൊജക്റ്റ് ബിൽഡിൻ്റെ ശരാശരി സമയം കുറയ്ക്കുന്നു. കാഷെയിൽ എല്ലാ ഘട്ടങ്ങളും നിലനിൽക്കുമ്പോൾ നിഷ്‌ക്രിയ ബിൽഡുകൾ ഘട്ടങ്ങൾ-സംഭരണം, ഇപ്പോൾ വളരെ വേഗത്തിലാണ്. മിക്ക സാഹചര്യങ്ങളിലും, ബിൽഡ് പുനരാരംഭിക്കുന്നതിന് 1 സെക്കൻഡിൽ താഴെ സമയമെടുക്കും! ടീമുകളുടെ പ്രവർത്തന പ്രക്രിയയിലെ ഘട്ടങ്ങൾ പരിശോധിക്കുന്നതിനുള്ള നടപടിക്രമങ്ങൾക്കും ഇത് ബാധകമാണ്. werf deploy и werf run.

ഈ റിലീസിൽ, ഉള്ളടക്കം അനുസരിച്ച് ചിത്രങ്ങൾ ടാഗുചെയ്യുന്നതിനുള്ള ഒരു തന്ത്രം പ്രത്യക്ഷപ്പെട്ടു - ഉള്ളടക്കം അടിസ്ഥാനമാക്കിയുള്ള ടാഗിംഗ്, ഇപ്പോൾ ഡിഫോൾട്ടായി പ്രവർത്തനക്ഷമമാക്കിയതും ഒരേയൊരു ശുപാർശ ചെയ്യപ്പെടുന്നതുമാണ്.

werf v1.1-ലെ പ്രധാന കണ്ടുപിടിത്തങ്ങൾ നമുക്ക് സൂക്ഷ്മമായി പരിശോധിക്കാം, അതേ സമയം ഭാവിയിലേക്കുള്ള പദ്ധതികളെക്കുറിച്ചും പറയാം.

werf v1.1-ൽ എന്താണ് മാറിയത്?

കാഷെയിൽ നിന്ന് ഘട്ടങ്ങൾ തിരഞ്ഞെടുക്കുന്നതിനുള്ള പുതിയ സ്റ്റേജ് നാമകരണ ഫോർമാറ്റും അൽഗോരിതവും

പുതിയ സ്റ്റേജ് നാമം ജനറേഷൻ നിയമം. ഇപ്പോൾ ഓരോ സ്റ്റേജ് ബിൽഡും ഒരു അദ്വിതീയ സ്റ്റേജ് നാമം സൃഷ്ടിക്കുന്നു, അതിൽ 2 ഭാഗങ്ങൾ ഉൾപ്പെടുന്നു: ഒരു ഒപ്പ് (അത് v1.0-ൽ ഉള്ളത് പോലെ) കൂടാതെ ഒരു അദ്വിതീയ താൽക്കാലിക ഐഡൻ്റിഫയറും.

ഉദാഹരണത്തിന്, മുഴുവൻ സ്റ്റേജ് ചിത്രത്തിൻ്റെ പേര് ഇതുപോലെയാകാം:

werf-stages-storage/myproject:d2c5ad3d2c9fcd9e57b50edd9cb26c32d156165eb355318cebc3412b-1582656767835

...അല്ലെങ്കിൽ പൊതുവായി:

werf-stages-storage/PROJECT:SIGNATURE-TIMESTAMP_MILLISEC

ഇവിടെ:

• SIGNATURE സ്റ്റേജ് ഉള്ളടക്കത്തിൻ്റെ ഐഡൻ്റിഫയറിനെ പ്രതിനിധീകരിക്കുന്ന ഒരു സ്റ്റേജ് സിഗ്നേച്ചർ ആണ്, ഈ ഉള്ളടക്കത്തിലേക്ക് നയിച്ച Git-ലെ എഡിറ്റുകളുടെ ചരിത്രത്തെ ആശ്രയിച്ചിരിക്കുന്നു;
• TIMESTAMP_MILLISEC ഒരു പുതിയ ഇമേജ് നിർമ്മിക്കുന്ന സമയത്ത് ജനറേറ്റ് ചെയ്യുന്ന ഒരു ഗ്യാരണ്ടീഡ് അദ്വിതീയ ഇമേജ് ഐഡൻ്റിഫയർ ആണ്.

കാഷെയിൽ നിന്ന് ഘട്ടങ്ങൾ തിരഞ്ഞെടുക്കുന്നതിനുള്ള അൽഗോരിതം Git കമ്മിറ്റുകളുടെ ബന്ധം പരിശോധിക്കുന്നതിനെ അടിസ്ഥാനമാക്കിയുള്ളതാണ്:

1. വെർഫ് ഒരു നിശ്ചിത ഘട്ടത്തിൻ്റെ ഒപ്പ് കണക്കാക്കുന്നു.
2. В ഘട്ടങ്ങൾ-സംഭരണം നൽകിയിരിക്കുന്ന ഒപ്പിന് നിരവധി ഘട്ടങ്ങളുണ്ടാകാം. ഒപ്പുമായി പൊരുത്തപ്പെടുന്ന എല്ലാ ഘട്ടങ്ങളും വെർഫ് തിരഞ്ഞെടുക്കുന്നു.
3. നിലവിലെ ഘട്ടം Git-ലേക്ക് ലിങ്ക് ചെയ്‌തിട്ടുണ്ടെങ്കിൽ (git-ആർക്കൈവ്, Git പാച്ചുകളുള്ള ഇഷ്‌ടാനുസൃത ഘട്ടം: install, beforeSetup, setup; അല്ലെങ്കിൽ git-latest-patch), തുടർന്ന് വെർഫ് നിലവിലെ കമ്മിറ്റിൻ്റെ പൂർവ്വികനായ ഒരു കമ്മിറ്റുമായി ബന്ധപ്പെട്ടിരിക്കുന്ന ഘട്ടങ്ങൾ മാത്രമേ തിരഞ്ഞെടുക്കൂ (ഇതിനായി ബിൽഡ് വിളിക്കുന്നു).
4. ശേഷിക്കുന്ന അനുയോജ്യമായ ഘട്ടങ്ങളിൽ നിന്ന്, ഒരെണ്ണം തിരഞ്ഞെടുത്തു - സൃഷ്ടിച്ച തീയതി പ്രകാരം ഏറ്റവും പഴയത്.

വ്യത്യസ്ത Git ശാഖകൾക്കുള്ള ഒരു ഘട്ടത്തിന് ഒരേ ഒപ്പ് ഉണ്ടായിരിക്കാം. എന്നാൽ സിഗ്നേച്ചറുകൾ പൊരുത്തപ്പെടുന്നുണ്ടെങ്കിലും, വ്യത്യസ്ത ശാഖകളുമായി ബന്ധപ്പെട്ട കാഷെ ഈ ബ്രാഞ്ചുകൾക്കിടയിൽ ഉപയോഗിക്കുന്നതിൽ നിന്ന് werf തടയും.

→ ഡോക്യുമെൻ്റേഷൻ.

സ്റ്റേജ് സ്റ്റോറേജിൽ സ്റ്റേജുകൾ സൃഷ്ടിക്കുന്നതിനും സംരക്ഷിക്കുന്നതിനുമുള്ള പുതിയ അൽഗോരിതം

കാഷെയിൽ നിന്ന് ഘട്ടങ്ങൾ തിരഞ്ഞെടുക്കുമ്പോൾ, വെർഫ് അനുയോജ്യമായ ഒരു ഘട്ടം കണ്ടെത്തിയില്ലെങ്കിൽ, ഒരു പുതിയ ഘട്ടം കൂട്ടിച്ചേർക്കുന്നതിനുള്ള പ്രക്രിയ ആരംഭിക്കുന്നു.

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

പുതുതായി കൂട്ടിച്ചേർത്ത ചിത്രത്തിന് ഒരു അദ്വിതീയ ഐഡൻ്റിഫയർ ഉണ്ടായിരിക്കുമെന്ന് ഉറപ്പുനൽകുന്നു TIMESTAMP_MILLISEC (പുതിയ സ്റ്റേജ് നാമകരണ ഫോർമാറ്റ് കാണുക). കേസിൽ ഘട്ടങ്ങൾ-സംഭരണം അനുയോജ്യമായ ഒരു ചിത്രം കണ്ടെത്തും, വെർഫ് പുതുതായി സമാഹരിച്ച ചിത്രം നിരസിക്കുകയും കാഷെയിൽ നിന്ന് ചിത്രം ഉപയോഗിക്കുകയും ചെയ്യും.

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

→ ഡോക്യുമെൻ്റേഷൻ.

മെച്ചപ്പെട്ട Dockerfile ബിൽഡർ പ്രകടനം

ഇപ്പോൾ, ഒരു ഡോക്കർഫയലിൽ നിന്ന് നിർമ്മിച്ച ഒരു ചിത്രത്തിനായുള്ള ഘട്ടങ്ങളുടെ പൈപ്പ്ലൈൻ ഒരു ഘട്ടം ഉൾക്കൊള്ളുന്നു - dockerfile. ഒപ്പ് കണക്കാക്കുമ്പോൾ, ഫയലുകളുടെ ചെക്ക്സം കണക്കാക്കുന്നു context, ഇത് അസംബ്ലി സമയത്ത് ഉപയോഗിക്കും. ഈ മെച്ചപ്പെടുത്തലിന് മുമ്പ്, വെർഫ് എല്ലാ ഫയലുകളിലൂടെയും ആവർത്തിച്ച് നടക്കുകയും ഓരോ ഫയലിൻ്റെയും സന്ദർഭവും മോഡും സംഗ്രഹിച്ച് ഒരു ചെക്ക്സം നേടുകയും ചെയ്തു. V1.1 മുതൽ, werf-ന് Git റിപ്പോസിറ്ററിയിൽ സംഭരിച്ചിരിക്കുന്ന കണക്കുകൂട്ടിയ ചെക്ക്സം ഉപയോഗിക്കാനാകും.

അൽഗോരിതം അടിസ്ഥാനമാക്കിയുള്ളതാണ് git ls-tree. അൽഗോരിതം രേഖകൾ കണക്കിലെടുക്കുന്നു .dockerignore ആവശ്യമുള്ളപ്പോൾ മാത്രം ഫയൽ ട്രീയിലൂടെ ആവർത്തിച്ച് സഞ്ചരിക്കുന്നു. അതിനാൽ, ഫയൽ സിസ്റ്റം വായിക്കുന്നതിൽ നിന്നും അൽഗോരിതം വലുപ്പത്തെ ആശ്രയിക്കുന്നതിൽ നിന്നും ഞങ്ങൾ വേർപെടുത്തി. context കാര്യമായതല്ല.

അൽഗോരിതം ട്രാക്ക് ചെയ്യാത്ത ഫയലുകളും പരിശോധിക്കുന്നു, ആവശ്യമെങ്കിൽ അവ ചെക്ക്സത്തിൽ കണക്കിലെടുക്കുന്നു.

ഫയലുകൾ ഇറക്കുമതി ചെയ്യുമ്പോൾ മെച്ചപ്പെട്ട പ്രകടനം

werf v1.1-ൻ്റെ പതിപ്പുകൾ എപ്പോൾ ഒരു rsync സെർവർ ഉപയോഗിക്കുന്നു പുരാവസ്തുക്കളിൽ നിന്നും ചിത്രങ്ങളിൽ നിന്നും ഫയലുകൾ ഇറക്കുമതി ചെയ്യുന്നു. മുമ്പ്, ഹോസ്റ്റ് സിസ്റ്റത്തിൽ നിന്നുള്ള ഒരു ഡയറക്ടറി മൗണ്ട് ഉപയോഗിച്ച് രണ്ട് ഘട്ടങ്ങളിലായാണ് ഇറക്കുമതി ചെയ്തിരുന്നത്.

MacOS-ലെ ഇറക്കുമതി പ്രകടനം ഇനി ഡോക്കർ വോള്യങ്ങളാൽ പരിമിതപ്പെടുത്തിയിട്ടില്ല, കൂടാതെ Linux, Windows എന്നിവയുടെ അതേ സമയത്തിനുള്ളിൽ ഇറക്കുമതി പൂർത്തിയാക്കും.

ഉള്ളടക്കം അടിസ്ഥാനമാക്കിയുള്ള ടാഗിംഗ്

ഇമേജ് ഉള്ളടക്കം അനുസരിച്ച് ടാഗിംഗ് എന്ന് വിളിക്കപ്പെടുന്നതിനെ വെർഫ് v1.1 പിന്തുണയ്ക്കുന്നു - ഉള്ളടക്കം അടിസ്ഥാനമാക്കിയുള്ള ടാഗിംഗ്. തത്ഫലമായുണ്ടാകുന്ന ഡോക്കർ ചിത്രങ്ങളുടെ ടാഗുകൾ ഈ ചിത്രങ്ങളുടെ ഉള്ളടക്കത്തെ ആശ്രയിച്ചിരിക്കുന്നു.

കമാൻഡ് പ്രവർത്തിപ്പിക്കുമ്പോൾ werf publish --tags-by-stages-signature അഥവാ werf ci-env --tagging-strategy=stages-signature എന്ന് വിളിക്കപ്പെടുന്ന ചിത്രങ്ങൾ പ്രസിദ്ധീകരിച്ചു സ്റ്റേജ് ഒപ്പ് ചിത്രം. ഓരോ ചിത്രവും ഈ ചിത്രത്തിൻ്റെ ഘട്ടങ്ങളുടെ സ്വന്തം സിഗ്നേച്ചർ ഉപയോഗിച്ച് ടാഗ് ചെയ്‌തിരിക്കുന്നു, ഇത് ഓരോ ഘട്ടത്തിൻ്റെയും പതിവ് ഒപ്പിൻ്റെ അതേ നിയമങ്ങൾക്കനുസൃതമായി പ്രത്യേകം കണക്കാക്കുന്നു, പക്ഷേ ചിത്രത്തിൻ്റെ പൊതുവായ ഐഡൻ്റിഫയർ ആണ്.

ചിത്രത്തിൻ്റെ ഘട്ടങ്ങളുടെ ഒപ്പ് ഇനിപ്പറയുന്നവയെ ആശ്രയിച്ചിരിക്കുന്നു:

1. ഈ ചിത്രത്തിൻ്റെ ഉള്ളടക്കം;
2. ഈ ഉള്ളടക്കത്തിലേക്ക് നയിച്ച Git മാറ്റങ്ങളുടെ ചരിത്രങ്ങൾ.

ഒരു Git റിപ്പോസിറ്ററിയിൽ എല്ലായ്‌പ്പോഴും ഇമേജ് ഫയലുകളുടെ ഉള്ളടക്കം മാറ്റാത്ത ഡമ്മി കമ്മിറ്റുകൾ ഉണ്ട്. ഉദാഹരണത്തിന്, അഭിപ്രായങ്ങൾ മാത്രമുള്ള കമ്മിറ്റ് അല്ലെങ്കിൽ ലയന കമ്മിറ്റുകൾ, അല്ലെങ്കിൽ ഇമേജിലേക്ക് ഇറക്കുമതി ചെയ്യാത്ത ഫയലുകൾ Git-ലെ മാറ്റുന്ന കമ്മിറ്റ്.

ഉള്ളടക്ക അധിഷ്‌ഠിത ടാഗിംഗ് ഉപയോഗിക്കുമ്പോൾ, ചിത്രത്തിൻ്റെ ഉള്ളടക്കം മാറിയിട്ടില്ലെങ്കിലും, ചിത്രത്തിൻ്റെ പേരിലെ മാറ്റങ്ങൾ കാരണം കുബർനെറ്റിലെ ആപ്ലിക്കേഷൻ പോഡുകൾ അനാവശ്യമായി പുനരാരംഭിക്കുന്നതിൻ്റെ പ്രശ്‌നങ്ങൾ പരിഹരിക്കപ്പെടും. വഴിയിൽ, ഒരൊറ്റ Git റിപ്പോസിറ്ററിയിൽ ഒരു ആപ്ലിക്കേഷൻ്റെ നിരവധി മൈക്രോസർവീസുകൾ സംഭരിക്കുന്നത് തടയുന്നതിനുള്ള ഒരു കാരണമാണിത്.

കൂടാതെ, Git ശാഖകളിൽ ടാഗുചെയ്യുന്നതിനേക്കാൾ കൂടുതൽ വിശ്വസനീയമായ ടാഗിംഗ് രീതിയാണ് ഉള്ളടക്കം അടിസ്ഥാനമാക്കിയുള്ള ടാഗിംഗ്, കാരണം ഫലമായുണ്ടാകുന്ന ചിത്രങ്ങളുടെ ഉള്ളടക്കം ഒരേ ബ്രാഞ്ചിൻ്റെ ഒന്നിലധികം കമ്മിറ്റുകൾ കൂട്ടിച്ചേർക്കുന്നതിന് CI സിസ്റ്റത്തിൽ പൈപ്പ്ലൈനുകൾ നടപ്പിലാക്കുന്ന ക്രമത്തെ ആശ്രയിക്കുന്നില്ല.

പ്രധാനപ്പെട്ട: ഇപ്പോൾ മുതൽ ആരംഭിക്കുന്നു ഘട്ടങ്ങൾ-ഒപ്പ് ആണ് ശുപാർശ ചെയ്യുന്ന ഒരേയൊരു ടാഗിംഗ് തന്ത്രം. ഇത് കമാൻഡിൽ സ്ഥിരസ്ഥിതിയായി ഉപയോഗിക്കും werf ci-env (നിങ്ങൾ മറ്റൊരു ടാഗിംഗ് സ്കീം വ്യക്തമായി വ്യക്തമാക്കിയില്ലെങ്കിൽ).

→ ഡോക്യുമെൻ്റേഷൻ. ഈ സവിശേഷതയ്ക്കായി ഒരു പ്രത്യേക പ്രസിദ്ധീകരണവും നീക്കിവയ്ക്കും. അപ്ഡേറ്റ് ചെയ്തു (ഏപ്രിൽ 3): വിശദാംശങ്ങളുള്ള ലേഖനം പ്രസിദ്ധീകരിച്ചു.

ലോഗിംഗ് ലെവലുകൾ

ഔട്ട്‌പുട്ട് നിയന്ത്രിക്കാനും ലോഗിംഗ് ലെവൽ സജ്ജീകരിക്കാനും ഡീബഗ്ഗിംഗ് വിവരങ്ങളുമായി പ്രവർത്തിക്കാനും ഉപയോക്താവിന് ഇപ്പോൾ അവസരമുണ്ട്. ഓപ്ഷനുകൾ ചേർത്തു --log-quiet, --log-verbose, --log-debug.

സ്ഥിരസ്ഥിതിയായി, ഔട്ട്പുട്ടിൽ ഏറ്റവും കുറഞ്ഞ വിവരങ്ങൾ അടങ്ങിയിരിക്കുന്നു:

വെർബോസ് ഔട്ട്പുട്ട് ഉപയോഗിക്കുമ്പോൾ (--log-verbose) വെർഫ് എങ്ങനെ പ്രവർത്തിക്കുന്നുവെന്ന് നിങ്ങൾക്ക് കാണാൻ കഴിയും:

വിശദമായ ഔട്ട്പുട്ട് (--log-debug), വെർഫ് ഡീബഗ്ഗിംഗ് വിവരങ്ങൾക്ക് പുറമേ, ഉപയോഗിച്ച ലൈബ്രറികളുടെ ലോഗുകളും അടങ്ങിയിരിക്കുന്നു. ഉദാഹരണത്തിന്, ഡോക്കർ രജിസ്ട്രിയുമായുള്ള ഇടപെടൽ എങ്ങനെ സംഭവിക്കുന്നുവെന്ന് നിങ്ങൾക്ക് കാണാനാകും, കൂടാതെ ഗണ്യമായ സമയം ചെലവഴിക്കുന്ന സ്ഥലങ്ങളും രേഖപ്പെടുത്തുക:

ഭാവി പരിപാടികള്

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

വിവിധ ഡോക്കർ രജിസ്ട്രി നടപ്പിലാക്കലുകൾക്കുള്ള പൂർണ്ണ പിന്തുണ (പുതിയത്)

• പതിപ്പ്: v1.1
• തീയതി: മാർച്ച്
• ഇഷ്യൂ

വെർഫ് ഉപയോഗിക്കുമ്പോൾ ഉപയോക്താവിന് നിയന്ത്രണങ്ങളില്ലാതെ ഒരു ഇഷ്‌ടാനുസൃത നടപ്പാക്കൽ ഉപയോഗിക്കുക എന്നതാണ് ലക്ഷ്യം.

നിലവിൽ, ഞങ്ങൾ പൂർണ്ണ പിന്തുണ ഉറപ്പ് നൽകാൻ പോകുന്ന ഇനിപ്പറയുന്ന പരിഹാരങ്ങളുടെ ഒരു കൂട്ടം തിരിച്ചറിഞ്ഞു:

• ഡിഫോൾട്ട് (ലൈബ്രറി/രജിസ്ട്രി)*,
• AWS ECR
• അസുർ*,
• ഡോക്കർ ഹബ്
• GCR*,
• GitHub പാക്കേജുകൾ
• GitLab രജിസ്ട്രി*,
• തുറമുഖം*,
• കടവ.

നിലവിൽ വെർഫ് പൂർണ്ണമായി പിന്തുണയ്ക്കുന്ന പരിഹാരങ്ങൾ ഒരു നക്ഷത്രചിഹ്നത്താൽ അടയാളപ്പെടുത്തിയിരിക്കുന്നു. മറ്റുള്ളവർക്ക് പിന്തുണയുണ്ട്, പക്ഷേ പരിമിതികളോടെ.

രണ്ട് പ്രധാന പ്രശ്നങ്ങൾ തിരിച്ചറിയാൻ കഴിയും:

• ചില പരിഹാരങ്ങൾ ഡോക്കർ രജിസ്ട്രി API ഉപയോഗിച്ച് ടാഗ് നീക്കംചെയ്യലിനെ പിന്തുണയ്ക്കുന്നില്ല, ഇത് werf-ൻ്റെ ഓട്ടോമാറ്റിക് ക്ലീനപ്പ് ഉപയോഗിക്കുന്നതിൽ നിന്ന് ഉപയോക്താക്കളെ തടയുന്നു. AWS ECR, Docker Hub, GitHub പാക്കേജുകൾക്ക് ഇത് ശരിയാണ്.
• ചില സൊല്യൂഷനുകൾ നെസ്റ്റഡ് റിപ്പോസിറ്ററികൾ (ഡോക്കർ ഹബ്, ഗിറ്റ്ഹബ് പാക്കേജുകൾ, ക്വേ) എന്ന് വിളിക്കപ്പെടുന്നതിനെ പിന്തുണയ്ക്കുന്നില്ല അല്ലെങ്കിൽ ചെയ്യുന്നു, എന്നാൽ ഉപയോക്താവ് അവ യുഐ അല്ലെങ്കിൽ എപിഐ (എഡബ്ല്യുഎസ് ഇസിആർ) ഉപയോഗിച്ച് സ്വമേധയാ സൃഷ്ടിക്കണം.

പരിഹാരങ്ങളുടെ നേറ്റീവ് API-കൾ ഉപയോഗിച്ച് ഇവയും മറ്റ് പ്രശ്നങ്ങളും ഞങ്ങൾ പരിഹരിക്കാൻ പോകുന്നു. ഈ ടാസ്‌ക്കിൽ വെർഫ് പ്രവർത്തനത്തിൻ്റെ മുഴുവൻ ചക്രവും അവയിൽ ഓരോന്നിനും വേണ്ടിയുള്ള പരിശോധനകൾ ഉൾക്കൊള്ളുന്നു.

വിതരണം ചെയ്ത ഇമേജ് ബിൽഡ് (↑)

• പതിപ്പ്: v1.2 v1.1 (ഈ സവിശേഷത നടപ്പിലാക്കുന്നതിനുള്ള മുൻഗണന വർദ്ധിപ്പിച്ചു)
• തീയതികൾ: മാർച്ച്-ഏപ്രിൽ മാർച്ച്
• ഇഷ്യൂ

നിലവിൽ, ഇമേജുകൾ നിർമ്മിക്കുന്നതിനും പ്രസിദ്ധീകരിക്കുന്നതിനും ആപ്ലിക്കേഷൻ കുബർനെറ്റസിലേക്ക് വിന്യസിക്കുന്നതിനുമുള്ള പ്രവർത്തനങ്ങൾക്കായി ഒരു സമർപ്പിത ഹോസ്റ്റിൽ മാത്രമേ werf v1.0, v1.1 എന്നിവ ഉപയോഗിക്കാൻ കഴിയൂ.

നിരവധി അനിയന്ത്രിതമായ ഹോസ്റ്റുകളിൽ കുബെർനെറ്റസിലെ ആപ്ലിക്കേഷനുകളുടെ നിർമ്മാണവും വിന്യാസവും സമാരംഭിക്കുമ്പോൾ, ഈ ഹോസ്റ്റുകൾ ബിൽഡുകൾക്കിടയിൽ (താൽക്കാലിക റണ്ണർമാർ) അവരുടെ അവസ്ഥ സംരക്ഷിക്കാതിരിക്കുമ്പോൾ, വെർഫിൻ്റെ വിതരണം ചെയ്ത ജോലിയുടെ സാധ്യതകൾ തുറക്കുന്നതിന്, ഉപയോഗിക്കാനുള്ള കഴിവ് നടപ്പിലാക്കാൻ വെർഫ് ആവശ്യമാണ്. ഒരു സ്റ്റേജ് സ്റ്റോറായി ഡോക്കർ രജിസ്ട്രി.

മുമ്പ്, വെർഫ് പ്രോജക്റ്റ് ഇപ്പോഴും ഡാപ്പ് എന്ന് വിളിച്ചിരുന്നപ്പോൾ, അതിന് അത്തരമൊരു അവസരം ഉണ്ടായിരുന്നു. എന്നിരുന്നാലും, വെർഫിൽ ഈ പ്രവർത്തനം നടപ്പിലാക്കുമ്പോൾ കണക്കിലെടുക്കേണ്ട നിരവധി പ്രശ്നങ്ങൾ ഞങ്ങൾ നേരിട്ടിട്ടുണ്ട്.

അഭിപായപ്പെടുക. ഈ സവിശേഷതയ്ക്ക് കളക്ടർ കുബർനെറ്റസ് പോഡുകൾക്കുള്ളിൽ പ്രവർത്തിക്കേണ്ട ആവശ്യമില്ല, കാരണം ഇത് ചെയ്യുന്നതിന്, നിങ്ങൾ പ്രാദേശിക ഡോക്കർ സെർവറിനെ ആശ്രയിക്കുന്നതിൽ നിന്ന് മുക്തി നേടേണ്ടതുണ്ട് (കുബർനെറ്റസ് പോഡിൽ ലോക്കൽ ഡോക്കർ സെർവറിലേക്ക് പ്രവേശനമില്ല, കാരണം പ്രക്രിയ തന്നെ ഒരു കണ്ടെയ്‌നറിൽ പ്രവർത്തിക്കുന്നു, കൂടാതെ വെർഫ് പിന്തുണയ്‌ക്കില്ല, പിന്തുണയ്‌ക്കുകയുമില്ല. നെറ്റ്‌വർക്കിൽ ഡോക്കർ സെർവറുമായി പ്രവർത്തിക്കുന്നു). Kubernetes പ്രവർത്തിപ്പിക്കുന്നതിനുള്ള പിന്തുണ പ്രത്യേകം നടപ്പിലാക്കും.

GitHub പ്രവർത്തനങ്ങൾക്കുള്ള ഔദ്യോഗിക പിന്തുണ (പുതിയത്)

• പതിപ്പ്: v1.1
• തീയതി: മാർച്ച്
• ഇഷ്യൂ

വെർഫ് ഡോക്യുമെൻ്റേഷൻ ഉൾപ്പെടുന്നു (വിഭാഗങ്ങൾ സൂചന и വഴികാട്ടി), വെർഫുമായി പ്രവർത്തിക്കുന്നതിനുള്ള ഔദ്യോഗിക GitHub ആക്ഷൻ.

കൂടാതെ, എഫിമെറൽ റണ്ണറുകളിൽ പ്രവർത്തിക്കാൻ ഇത് വെർഫിനെ അനുവദിക്കും.

CI സിസ്റ്റവുമായുള്ള ഉപയോക്തൃ ഇടപെടലിൻ്റെ മെക്കാനിക്‌സ്, ആപ്ലിക്കേഷൻ നിർമ്മിക്കുന്നതിനോ പുറത്തുവിടുന്നതിനോ ചില പ്രവർത്തനങ്ങൾ ആരംഭിക്കുന്നതിന് പുൾ അഭ്യർത്ഥനകളിൽ ലേബലുകൾ സ്ഥാപിക്കുന്നതിനെ അടിസ്ഥാനമാക്കിയുള്ളതാണ്.

വെർഫ് (↓) ഉപയോഗിച്ചുള്ള ആപ്ലിക്കേഷനുകളുടെ പ്രാദേശിക വികസനവും വിന്യാസവും

• പതിപ്പ്: v1.1
• തീയതി: ജനുവരി-ഫെബ്രുവരി ഏപ്രിൽ
• ഇഷ്യൂ

സങ്കീർണ്ണമായ പ്രവർത്തനങ്ങളില്ലാതെ, പ്രാദേശികമായും ഉൽപ്പാദനത്തിലും ആപ്ലിക്കേഷനുകൾ വിന്യസിക്കുന്നതിന് ഒരൊറ്റ ഏകീകൃത കോൺഫിഗറേഷൻ നേടുക എന്നതാണ് പ്രധാന ലക്ഷ്യം.

werf-ന് ഒരു ഓപ്പറേറ്റിംഗ് മോഡ് ആവശ്യമാണ്, അതിൽ ആപ്ലിക്കേഷൻ കോഡ് എഡിറ്റുചെയ്യാനും ഡീബഗ്ഗിംഗിനായി പ്രവർത്തിക്കുന്ന ആപ്ലിക്കേഷനിൽ നിന്ന് ഫീഡ്‌ബാക്ക് തൽക്ഷണം സ്വീകരിക്കാനും സൗകര്യപ്രദമായിരിക്കും.

പുതിയ ക്ലീനിംഗ് അൽഗോരിതം (പുതിയ)

• പതിപ്പ്: v1.1
• തീയതി: ഏപ്രിൽ
• ഇഷ്യൂ

നടപടിക്രമത്തിൽ werf v1.1 ൻ്റെ നിലവിലെ പതിപ്പിൽ cleanup ഉള്ളടക്കം അടിസ്ഥാനമാക്കിയുള്ള ടാഗിംഗ് സ്കീമിനായി ചിത്രങ്ങൾ വൃത്തിയാക്കുന്നതിനുള്ള വ്യവസ്ഥകളൊന്നുമില്ല - ഈ ചിത്രങ്ങൾ കുമിഞ്ഞുകൂടും.

കൂടാതെ, വെർഫിൻ്റെ നിലവിലെ പതിപ്പ് (v1.0, v1.1) ടാഗിംഗ് സ്കീമുകൾക്ക് കീഴിൽ പ്രസിദ്ധീകരിച്ച ചിത്രങ്ങൾക്കായി വ്യത്യസ്ത ക്ലീനപ്പ് നയങ്ങൾ ഉപയോഗിക്കുന്നു: Git ബ്രാഞ്ച്, Git ടാഗ് അല്ലെങ്കിൽ Git commit.

എല്ലാ ടാഗിംഗ് സ്കീമുകൾക്കും ഏകീകൃതമായ Git-ലെ കമ്മിറ്റുകളുടെ ചരിത്രത്തെ അടിസ്ഥാനമാക്കി ചിത്രങ്ങൾ വൃത്തിയാക്കുന്നതിനുള്ള ഒരു പുതിയ അൽഗോരിതം കണ്ടുപിടിച്ചു:

• ഓരോ git HEAD-നും (ശാഖകളും ടാഗുകളും) N1 ഏറ്റവും പുതിയ കമ്മിറ്റുകളുമായി ബന്ധപ്പെട്ട N2 ഇമേജുകളിൽ കൂടുതൽ സൂക്ഷിക്കരുത്.
• ഓരോ git HEAD-നും (ശാഖകളും ടാഗുകളും) N1 ഏറ്റവും പുതിയ കമ്മിറ്റുകളുമായി ബന്ധപ്പെട്ട N2 ഘട്ടത്തിൽ കൂടുതൽ ചിത്രങ്ങൾ സംഭരിക്കുക.
• ഏതെങ്കിലും Kubernetes ക്ലസ്റ്റർ ഉറവിടങ്ങളിൽ ഉപയോഗിക്കുന്ന എല്ലാ ചിത്രങ്ങളും സംഭരിക്കുക (കോൺഫിഗറേഷൻ ഫയലിൻ്റെയും നെയിംസ്‌പെയ്‌സിൻ്റെയും എല്ലാ kube സന്ദർഭങ്ങളും സ്കാൻ ചെയ്‌തിരിക്കുന്നു; പ്രത്യേക ഓപ്ഷനുകൾ ഉപയോഗിച്ച് നിങ്ങൾക്ക് ഈ സ്വഭാവം പരിമിതപ്പെടുത്താം).
• ഹെൽം റിലീസുകളിൽ സംരക്ഷിച്ചിരിക്കുന്ന റിസോഴ്സ് കോൺഫിഗറേഷൻ മാനിഫെസ്റ്റുകളിൽ ഉപയോഗിക്കുന്ന എല്ലാ ചിത്രങ്ങളും സംഭരിക്കുക.
• ഒരു ഇമേജ് git-ൽ നിന്നുള്ള ഏതെങ്കിലും HEAD-മായി ബന്ധപ്പെടുത്തിയിട്ടില്ലെങ്കിൽ (ഉദാഹരണത്തിന്, അനുബന്ധ HEAD തന്നെ ഇല്ലാതാക്കിയതിനാൽ) കുബർനെറ്റസ് ക്ലസ്റ്ററിലും ഹെൽം റിലീസുകളിലും ഒരു മാനിഫെസ്റ്റിലും ഉപയോഗിച്ചിട്ടില്ലെങ്കിൽ അത് ഇല്ലാതാക്കാം.

സമാന്തര ഇമേജ് ബിൽഡിംഗ് (↓)

• പതിപ്പ്: v1.1
• തീയതി: ജനുവരി-ഫെബ്രുവരി ഏപ്രിൽ*

വെർഫിൻ്റെ നിലവിലെ പതിപ്പ് വിവരിച്ചിരിക്കുന്ന ചിത്രങ്ങളും പുരാവസ്തുക്കളും ശേഖരിക്കുന്നു werf.yaml, തുടർച്ചയായി. ചിത്രങ്ങളുടെയും പുരാവസ്തുക്കളുടെയും സ്വതന്ത്ര ഘട്ടങ്ങൾ കൂട്ടിച്ചേർക്കുന്ന പ്രക്രിയ സമാന്തരമാക്കേണ്ടത് ആവശ്യമാണ്, അതുപോലെ തന്നെ സൗകര്യപ്രദവും വിവരദായകവുമായ ഔട്ട്പുട്ട് നൽകണം.

* കുറിപ്പ്: വിതരണം ചെയ്‌ത അസംബ്ലി നടപ്പിലാക്കുന്നതിനുള്ള മുൻഗണന വർധിച്ചതിനാൽ സമയപരിധി മാറ്റി, ഇത് കൂടുതൽ തിരശ്ചീന സ്കെയിലിംഗ് കഴിവുകളും GitHub പ്രവർത്തനങ്ങളുള്ള വെർഫിൻ്റെ ഉപയോഗവും ചേർക്കും. സമാന്തര അസംബ്ലി അടുത്ത ഒപ്റ്റിമൈസേഷൻ ഘട്ടമാണ്, ഒരു പ്രോജക്റ്റ് കൂട്ടിച്ചേർക്കുമ്പോൾ ലംബമായ സ്കേലബിളിറ്റി നൽകുന്നു.

ഹെൽം 3 ലേക്കുള്ള മാറ്റം (↓)

• പതിപ്പ്: v1.2
• തീയതി: ഫെബ്രുവരി-മാർച്ച് മെയ്*

പുതിയ കോഡ്ബേസിലേക്കുള്ള മൈഗ്രേഷൻ ഉൾപ്പെടുന്നു ഹെൽം 3 നിലവിലുള്ള ഇൻസ്റ്റാളേഷനുകൾ മൈഗ്രേറ്റ് ചെയ്യുന്നതിനുള്ള തെളിയിക്കപ്പെട്ടതും സൗകര്യപ്രദവുമായ മാർഗ്ഗവും.

* ശ്രദ്ധിക്കുക: Helm 3-ലേക്ക് മാറുന്നത് verf-ലേക്ക് കാര്യമായ ഫീച്ചറുകൾ ചേർക്കില്ല, കാരണം Helm 3-ൻ്റെ എല്ലാ പ്രധാന സവിശേഷതകളും (3-way-merge and no tiller) വെർഫിൽ ഇതിനകം തന്നെ നടപ്പിലാക്കിയിട്ടുണ്ട്. മാത്രമല്ല, വെർഫിന് ഉണ്ട് അധിക സവിശേഷതകൾ സൂചിപ്പിച്ചവ കൂടാതെ. എന്നിരുന്നാലും, ഈ പരിവർത്തനം ഞങ്ങളുടെ പദ്ധതികളിൽ നിലനിൽക്കുന്നു, അത് നടപ്പിലാക്കും.

Kubernetes കോൺഫിഗറേഷൻ വിവരിക്കുന്നതിനുള്ള Jsonnet (↓)

• പതിപ്പ്: v1.2
• തീയതി: ജനുവരി-ഫെബ്രുവരി ഏപ്രിൽ-മെയ്

Jsonnet ഫോർമാറ്റിൽ Kubernetes-നുള്ള കോൺഫിഗറേഷൻ വിവരണങ്ങളെ വെർഫ് പിന്തുണയ്ക്കും. അതേ സമയം, വെർഫ് ഹെൽമുമായി പൊരുത്തപ്പെടും കൂടാതെ വിവരണ ഫോർമാറ്റിൻ്റെ ഒരു തിരഞ്ഞെടുപ്പും ഉണ്ടായിരിക്കും.

കാരണം, ഗോ ടെംപ്ലേറ്റുകൾക്ക്, പലരുടെയും അഭിപ്രായത്തിൽ, ഉയർന്ന പ്രവേശന തടസ്സമുണ്ട്, മാത്രമല്ല ഈ ടെംപ്ലേറ്റുകളുടെ കോഡിൻ്റെ മനസ്സിലാക്കലും ബുദ്ധിമുട്ടാണ്.

മറ്റ് Kubernetes കോൺഫിഗറേഷൻ വിവരണ സംവിധാനങ്ങൾ (ഉദാഹരണത്തിന്, Kustomize) അവതരിപ്പിക്കുന്നതിനുള്ള സാധ്യതയും പരിഗണിക്കുന്നു.

കുബർനെറ്റസിനുള്ളിൽ പ്രവർത്തിക്കുന്നു (↓)

• പതിപ്പ്: v1.2
• തീയതികൾ: ഏപ്രിൽ-മെയ് മെയ്-ജൂൺ

ലക്ഷ്യം: കുബെർനെറ്റസിലെ റണ്ണേഴ്‌സ് ഉപയോഗിച്ചാണ് ചിത്രങ്ങൾ നിർമ്മിച്ചിരിക്കുന്നതെന്നും ആപ്ലിക്കേഷൻ ഡെലിവർ ചെയ്തിട്ടുണ്ടെന്നും ഉറപ്പാക്കുക. ആ. കുബർനെറ്റസ് പോഡുകളിൽ നിന്ന് നേരിട്ട് പുതിയ ചിത്രങ്ങൾ നിർമ്മിക്കാനും പ്രസിദ്ധീകരിക്കാനും വൃത്തിയാക്കാനും വിന്യസിക്കാനും കഴിയും.

ഈ കഴിവ് നടപ്പിലാക്കാൻ, നിങ്ങൾ ആദ്യം വിതരണം ചെയ്ത ചിത്രങ്ങൾ നിർമ്മിക്കേണ്ടതുണ്ട് (മുകളിലുള്ള പോയിൻ്റ് കാണുക).

ഒരു ഡോക്കർ സെർവർ (അതായത് കനിക്കോ പോലുള്ള ബിൽഡ് അല്ലെങ്കിൽ ബിൽഡ് ഇൻ യൂസർസ്‌പേസ്) ഇല്ലാതെ ബിൽഡറുടെ ഓപ്പറേറ്റിംഗ് മോഡിനുള്ള പിന്തുണയും ഇതിന് ആവശ്യമാണ്.

ഡോക്കർഫയലിനൊപ്പം മാത്രമല്ല, വർദ്ധനയുള്ള പുനർനിർമ്മാണങ്ങളും അൻസിബിളും ഉള്ള അതിൻ്റെ സ്റ്റാപ്പൽ ബിൽഡറിനൊപ്പം കുബർനെറ്റസിൽ നിർമ്മിക്കുന്നതിനെ വെർഫ് പിന്തുണയ്ക്കും.

തുറന്ന വികസനത്തിലേക്കുള്ള ചുവടുവെപ്പ്

ഞങ്ങൾ ഞങ്ങളുടെ സമൂഹത്തെ സ്നേഹിക്കുന്നു (സാമൂഹികം, കന്വിസന്ദേശം) കൂടാതെ കൂടുതൽ കൂടുതൽ ആളുകൾ വെർഫിനെ മികച്ചതാക്കാനും ഞങ്ങൾ നീങ്ങുന്ന ദിശ മനസ്സിലാക്കാനും വികസനത്തിൽ പങ്കെടുക്കാനും സഹായിക്കണമെന്ന് ഞങ്ങൾ ആഗ്രഹിക്കുന്നു.

ലേക്ക് മാറാൻ അടുത്തിടെ തീരുമാനിച്ചിരുന്നു GitHub പ്രോജക്റ്റ് ബോർഡുകൾ ഞങ്ങളുടെ ടീമിൻ്റെ പ്രവർത്തന പ്രക്രിയ വെളിപ്പെടുത്തുന്നതിന്. ഇപ്പോൾ നിങ്ങൾക്ക് ഉടനടിയുള്ള പദ്ധതികളും ഇനിപ്പറയുന്ന മേഖലകളിലെ നിലവിലെ പ്രവർത്തനങ്ങളും കാണാൻ കഴിയും:

• ഡോക്യുമെൻ്റേഷനും സൈറ്റും;
• ടെസ്റ്റിംഗ്;
• ബഗുകളും മോശം UX ഉം;
• 1.1.

പ്രശ്നങ്ങളുമായി ഒരുപാട് ജോലികൾ ചെയ്തു:

• അപ്രസക്തമായവ നീക്കം ചെയ്തു.
• മതിയായ എണ്ണം വിശദാംശങ്ങളും വിശദാംശങ്ങളും സഹിതം നിലവിലുള്ളവ ഒരൊറ്റ ഫോർമാറ്റിലേക്ക് കൊണ്ടുവരുന്നു.
• ആശയങ്ങളും നിർദ്ദേശങ്ങളുമുള്ള പുതിയ പ്രശ്നങ്ങൾ ചേർത്തു.

പതിപ്പ് v1.1 എങ്ങനെ പ്രവർത്തനക്ഷമമാക്കാം

പതിപ്പ് നിലവിൽ ലഭ്യമാണ് ചാനൽ 1.1 EA (ചാനലുകളിൽ സുസ്ഥിരം и പാറ-ഖര എന്നിരുന്നാലും, സ്റ്റെബിലൈസേഷൻ സംഭവിക്കുമ്പോൾ റിലീസുകൾ ദൃശ്യമാകും ea ഉപയോഗത്തിന് ഇതിനകം തന്നെ സ്ഥിരതയുള്ളതാണ്, കാരണം ചാനലുകളിലൂടെ കടന്നുപോയി ആൽഫ и ബീറ്റ). സജീവമാക്കി മൾട്ടിവെർഫ് വഴി ഇനിപ്പറയുന്ന രീതിയിൽ:

source $(multiwerf use 1.1 ea)
werf COMMAND ...

തീരുമാനം

Stapel, Dockerfile ബിൽഡർമാർക്കുള്ള പുതിയ സ്റ്റേജ് സ്റ്റോറേജ് ആർക്കിടെക്ചറും ബിൽഡർ ഒപ്റ്റിമൈസേഷനുകളും വെർഫിൽ വിതരണം ചെയ്തതും സമാന്തരവുമായ ബിൽഡുകൾ നടപ്പിലാക്കുന്നതിനുള്ള സാധ്യത തുറക്കുന്നു. ഈ ഫീച്ചറുകൾ ഉടൻ തന്നെ അതേ v1.1 റിലീസിൽ ദൃശ്യമാകും കൂടാതെ സ്വയമേവയുള്ള അപ്‌ഡേറ്റ് സംവിധാനത്തിലൂടെ (ഉപയോക്താക്കൾക്കായി) സ്വയമേവ ലഭ്യമാകും. മൾട്ടിവർഫ്).

ഈ റിലീസിൽ, ചിത്രത്തിൻ്റെ ഉള്ളടക്കത്തെ അടിസ്ഥാനമാക്കിയുള്ള ഒരു ടാഗിംഗ് തന്ത്രം ചേർത്തിരിക്കുന്നു - ഉള്ളടക്കം അടിസ്ഥാനമാക്കിയുള്ള ടാഗിംഗ്, ഇത് സ്ഥിരസ്ഥിതി തന്ത്രമായി മാറിയിരിക്കുന്നു. പ്രധാന കമാൻഡ് ലോഗും പുനർനിർമ്മിച്ചു: werf build, werf publish, werf deploy, werf dismiss, werf cleanup.

അടുത്ത സുപ്രധാന ഘട്ടം വിതരണം ചെയ്ത അസംബ്ലികൾ കൂട്ടിച്ചേർക്കുക എന്നതാണ്. വി1.0 മുതൽ സമാന്തര ബിൽഡുകളേക്കാൾ ഉയർന്ന മുൻഗണനയായി ഡിസ്ട്രിബ്യൂട്ടഡ് ബിൽഡുകൾ മാറിയിരിക്കുന്നു, കാരണം അവ werf-ന് കൂടുതൽ മൂല്യം നൽകുന്നു: ബിൽഡർമാരുടെ വെർട്ടിക്കൽ സ്കെയിലിംഗും വിവിധ CI/CD സിസ്റ്റങ്ങളിലെ എഫെമെറൽ ബിൽഡറുകൾക്കുള്ള പിന്തുണയും GitHub പ്രവർത്തനങ്ങൾക്ക് ഔദ്യോഗിക പിന്തുണ നൽകാനുള്ള കഴിവും. . അതിനാൽ, സമാന്തര അസംബ്ലികൾ നടപ്പിലാക്കുന്നതിനുള്ള സമയപരിധി മാറ്റി. എന്നിരുന്നാലും, രണ്ട് സാധ്യതകളും എത്രയും വേഗം നടപ്പിലാക്കാൻ ഞങ്ങൾ പ്രവർത്തിക്കുന്നു.

വാർത്ത പിന്തുടരുക! ഒപ്പം ഞങ്ങളെ സന്ദർശിക്കാൻ മറക്കരുത് സാമൂഹികംഒരു പ്രശ്‌നം സൃഷ്‌ടിക്കാൻ, നിലവിലുള്ള ഒരെണ്ണം കണ്ടെത്തി പ്ലസ് ചേർക്കുക, ഒരു PR സൃഷ്‌ടിക്കുക, അല്ലെങ്കിൽ പ്രോജക്‌റ്റിൻ്റെ വികസനം കാണുക.

പി.എസ്

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

• «werf 1.0 സ്റ്റേബിൾ അവതരിപ്പിക്കുന്നു: GitOps-ന് എന്താണ്, സ്റ്റാറ്റസും പ്ലാനുകളും»
• «werf - കുബർനെറ്റസിലെ CI / CD-യ്ക്കുള്ള ഞങ്ങളുടെ ഉപകരണം (അവലോകനവും വീഡിയോ റിപ്പോർട്ടും)";
• വെർഫിലെ പുതുമകളെക്കുറിച്ചുള്ള കുറിപ്പുകളുടെ ഒരു പരമ്പര:
  • «വെർഫിലേക്കുള്ള 3-വേ ലയനം: "സ്റ്റിറോയിഡുകളിൽ" ഹെൽമിനൊപ്പം കുബർനെറ്റസിലേക്ക് വിന്യാസം";
  • «സങ്കീർണ്ണമായ ഹെൽം ചാർട്ടുകൾ പുറത്തിറക്കാൻ വെർഫ് ഉപയോഗിക്കുന്നു";
  • «വെർഫിലെ മോണോറെപ്പോ, മൾട്ടിറെപ്പോ എന്നിവയ്ക്കുള്ള പിന്തുണയും ഡോക്കർ രജിസ്ട്രിയും ഇതുമായി എന്താണ് ചെയ്യേണ്ടത്";
  • «നിങ്ങൾക്ക് ഇപ്പോൾ ഒരു സാധാരണ ഡോക്കർ ഫയൽ ഉപയോഗിച്ച് വെർഫിൽ ഡോക്കർ ഇമേജുകൾ നിർമ്മിക്കാം".

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