നിങ്ങൾക്ക് ഇപ്പോൾ ഒരു സാധാരണ ഡോക്കർ ഫയൽ ഉപയോഗിച്ച് വെർഫിൽ ഡോക്കർ ഇമേജുകൾ നിർമ്മിക്കാം

ഒരിക്കലും വൈകുന്നതിനേക്കാൾ നല്ലത്. അല്ലെങ്കിൽ ആപ്ലിക്കേഷൻ ഇമേജുകൾ നിർമ്മിക്കുന്നതിന് സാധാരണ ഡോക്കർഫയലുകൾക്ക് പിന്തുണയില്ലാതെ ഞങ്ങൾ എങ്ങനെയാണ് ഗുരുതരമായ തെറ്റ് വരുത്തിയത്.

നമ്മൾ സംസാരിക്കും വെർഫ് — GitOps യൂട്ടിലിറ്റി ഏതെങ്കിലും CI/CD സിസ്റ്റവുമായി സംയോജിപ്പിക്കുകയും മുഴുവൻ ആപ്ലിക്കേഷൻ ലൈഫ് സൈക്കിളിന്റെ മാനേജ്മെന്റ് നൽകുകയും ചെയ്യുന്നു, ഇത് അനുവദിക്കുന്നു:

• ചിത്രങ്ങൾ ശേഖരിക്കുകയും പ്രസിദ്ധീകരിക്കുകയും ചെയ്യുക,
• കുബർനെറ്റസിൽ ആപ്ലിക്കേഷനുകൾ വിന്യസിക്കുക,
• പ്രത്യേക നയങ്ങൾ ഉപയോഗിച്ച് ഉപയോഗിക്കാത്ത ചിത്രങ്ങൾ ഇല്ലാതാക്കുക.

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

പശ്ചാത്തലം: നിങ്ങളുടെ സ്വന്തം ഇമേജ് കളക്ടർ

വെർഫിലെ ഇമേജ് കളക്ടർക്ക് സംഭവിച്ചത് ഇതാണ്: സാധാരണ ഡോക്കർഫയൽ ഞങ്ങൾക്ക് മതിയായിരുന്നില്ല. നിങ്ങൾ പ്രോജക്റ്റിന്റെ ചരിത്രത്തിലേക്ക് പെട്ടെന്ന് നോക്കുകയാണെങ്കിൽ, ഈ പ്രശ്നം വെർഫിന്റെ ആദ്യ പതിപ്പുകളിൽ ഇതിനകം പ്രത്യക്ഷപ്പെട്ടു (എന്നിട്ട് ഇപ്പോഴും ഡാപ്പ് എന്നറിയപ്പെടുന്നു).

ഡോക്കർ ഇമേജുകളിലേക്ക് ആപ്ലിക്കേഷനുകൾ നിർമ്മിക്കുന്നതിനുള്ള ഒരു ഉപകരണം സൃഷ്ടിക്കുമ്പോൾ, ചില പ്രത്യേക ജോലികൾക്ക് ഡോക്കർഫയൽ ഞങ്ങൾക്ക് അനുയോജ്യമല്ലെന്ന് ഞങ്ങൾ പെട്ടെന്ന് മനസ്സിലാക്കി:

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

ഇന്ന് നമ്മുടെ കളക്ടർക്ക് മറ്റ് പല സാധ്യതകളും ഉണ്ട്, എന്നാൽ ഇത് ആദ്യകാല ആഗ്രഹങ്ങളും പ്രേരണകളുമായിരുന്നു.

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

റൂബിയിൽ ഡാപ്പിനുള്ള പഴയ കോൺഫിഗറേഷൻ

YAML-ൽ werf-നുള്ള നിലവിലെ കോൺഫിഗറേഷൻ

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

NB: ഇപ്പോൾ, സ്വന്തം കോൺഫിഗറേഷനിൽ (YAML-ൽ) പ്രവർത്തിക്കുന്ന, സ്റ്റാപ്പൽ കളക്ടർ എന്ന് വിളിക്കപ്പെടുന്ന ഞങ്ങളുടെ കളക്ടർ, ഇതിനകം തന്നെ വളരെ ശക്തമായ ഒരു ടൂളായി വികസിപ്പിച്ചെടുത്തിട്ടുണ്ട്. അതിന്റെ വിശദമായ വിവരണം പ്രത്യേക ലേഖനങ്ങൾക്ക് അർഹമാണ്, കൂടാതെ അടിസ്ഥാന വിശദാംശങ്ങൾ കണ്ടെത്താനാകും പ്രമാണീകരണം.

പ്രശ്നത്തെക്കുറിച്ചുള്ള അവബോധം

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

ഈ ചോദ്യത്തിന് ഉത്തരം നൽകുന്നതിനുപകരം, ഞങ്ങൾ ഒരു പരിഹാരം വാഗ്ദാനം ചെയ്യുന്നു. നിങ്ങൾക്ക് ഇതിനകം ഒരു Dockerfile (അല്ലെങ്കിൽ ഒരു കൂട്ടം Dockerfiles) ഉണ്ടെങ്കിൽ വെർഫ് ഉപയോഗിക്കാൻ ആഗ്രഹിക്കുന്നുവെങ്കിൽ?

NB: എന്തായാലും, നിങ്ങൾ എന്തിനാണ് വെർഫ് ഉപയോഗിക്കാൻ ആഗ്രഹിക്കുന്നത്? പ്രധാന സവിശേഷതകൾ ഇനിപ്പറയുന്നവയിലേക്ക് വരുന്നു:

• ഇമേജ് ക്ലീനിംഗ് ഉൾപ്പെടെ പൂർണ്ണ ആപ്ലിക്കേഷൻ മാനേജ്മെന്റ് സൈക്കിൾ;
• ഒരു കോൺഫിഗറേഷനിൽ നിന്ന് ഒരേസമയം നിരവധി ചിത്രങ്ങളുടെ അസംബ്ലി കൈകാര്യം ചെയ്യാനുള്ള കഴിവ്;
• ഹെൽമിന് അനുയോജ്യമായ ചാർട്ടുകൾക്കായുള്ള മെച്ചപ്പെട്ട വിന്യാസ പ്രക്രിയ.

അവയുടെ കൂടുതൽ പൂർണ്ണമായ ലിസ്റ്റ് ഇവിടെ കാണാം പദ്ധതി പേജ്.

അതിനാൽ, ഞങ്ങളുടെ കോൺഫിഗറേഷനിൽ ഡോക്കർഫയൽ വീണ്ടും എഴുതാൻ ഞങ്ങൾ നേരത്തെ വാഗ്ദാനം ചെയ്തിരുന്നെങ്കിൽ, ഇപ്പോൾ ഞങ്ങൾ സന്തോഷത്തോടെ പറയും: "നിങ്ങളുടെ ഡോക്കർഫയലുകൾ നിർമ്മിക്കാൻ വെർഫിനെ അനുവദിക്കുക!"

എങ്ങനെ ഉപയോഗിക്കാം?

ഈ സവിശേഷതയുടെ പൂർണ്ണമായ നടപ്പാക്കൽ റിലീസിൽ പ്രത്യക്ഷപ്പെട്ടു werf v1.0.3-beta.1. പൊതുവായ തത്വം ലളിതമാണ്: ഉപയോക്താവ് വെർഫ് കോൺഫിഗറേഷനിൽ നിലവിലുള്ള ഡോക്കർഫയലിലേക്കുള്ള പാത വ്യക്തമാക്കുന്നു, തുടർന്ന് കമാൻഡ് പ്രവർത്തിപ്പിക്കുന്നു. werf build... അത്രമാത്രം - വെർഫ് ചിത്രം കൂട്ടിച്ചേർക്കും. ഒരു അമൂർത്ത ഉദാഹരണം നോക്കാം.

അടുത്തത് അറിയിക്കാം Dockerfile പ്രോജക്റ്റ് റൂട്ടിൽ:

FROM ubuntu:18.04
RUN echo Building ...

ഞങ്ങൾ പ്രഖ്യാപിക്കുകയും ചെയ്യും werf.yamlഇത് ഉപയോഗിക്കുന്നത് Dockerfile:

configVersion: 1
project: dockerfile-example
---
image: ~
dockerfile: ./Dockerfile

എല്ലാം! ഇടത്തെ പ്രവർത്തിപ്പിക്കുക werf build:

കൂടാതെ, നിങ്ങൾക്ക് ഇനിപ്പറയുന്നവ പ്രഖ്യാപിക്കാം werf.yaml വ്യത്യസ്ത ഡോക്കർ ഫയലുകളിൽ നിന്ന് ഒരേസമയം നിരവധി ചിത്രങ്ങൾ നിർമ്മിക്കാൻ:

configVersion: 1
project: dockerfile-example
---
image: backend
dockerfile: ./dockerfiles/Dockerfile-backend
---
image: frontend
dockerfile: ./dockerfiles/Dockerfile-frontend

അവസാനമായി, ഇതുപോലുള്ള അധിക ബിൽഡ് പാരാമീറ്ററുകൾ കൈമാറുന്നതിനെയും ഇത് പിന്തുണയ്ക്കുന്നു --build-arg и --add-host - വെർഫ് കോൺഫിഗറേഷൻ വഴി. ഡോക്കർഫയൽ ഇമേജ് കോൺഫിഗറേഷന്റെ പൂർണ്ണമായ വിവരണം ഇവിടെ ലഭ്യമാണ് ഡോക്യുമെന്റേഷൻ പേജ്.

ഇത് എങ്ങനെ പ്രവർത്തിക്കുന്നു?

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

1. ഒരു ഡോക്കർഫയലിൽ നിന്ന് നിർമ്മിച്ച ഓരോ ചിത്രവും വിളിക്കപ്പെടുന്ന ഒരു ഘട്ടം ഉൾക്കൊള്ളുന്നു dockerfile (വേർഫിൽ ഏതൊക്കെ ഘട്ടങ്ങളാണുള്ളത് എന്നതിനെക്കുറിച്ച് നിങ്ങൾക്ക് കൂടുതൽ വായിക്കാം ഇവിടെ).
2. സ്റ്റേജിനായി dockerfile Dockerfile കോൺഫിഗറേഷന്റെ ഉള്ളടക്കത്തെ ആശ്രയിച്ചുള്ള ഒരു ഒപ്പ് werf കണക്കാക്കുന്നു. Dockerfile കോൺഫിഗറേഷൻ മാറുമ്പോൾ, സ്റ്റേജ് സിഗ്നേച്ചർ മാറുന്നു dockerfile ഒരു പുതിയ ഡോക്കർഫയൽ കോൺഫിഗറേഷൻ ഉപയോഗിച്ച് werf ഈ ഘട്ടത്തിന്റെ പുനർനിർമ്മാണം ആരംഭിക്കുന്നു. ഒപ്പ് മാറുന്നില്ലെങ്കിൽ, വെർഫ് കാഷെയിൽ നിന്ന് ചിത്രം എടുക്കുന്നു (വേർഫിലെ ഒപ്പുകളുടെ ഉപയോഗത്തെക്കുറിച്ചുള്ള കൂടുതൽ വിശദാംശങ്ങൾ ഇതിൽ വിവരിച്ചിട്ടുണ്ട് ഈ റിപ്പോർട്ട്).
3. അടുത്തതായി, ശേഖരിച്ച ചിത്രങ്ങൾ കമാൻഡ് ഉപയോഗിച്ച് പ്രസിദ്ധീകരിക്കാം werf publish (അല്ലെങ്കിൽ werf build-and-publish) കുബെർനെറ്റസിലേക്കുള്ള വിന്യാസത്തിനായി ഇത് ഉപയോഗിക്കുക. ഡോക്കർ രജിസ്ട്രിയിലേക്ക് പ്രസിദ്ധീകരിച്ച ചിത്രങ്ങൾ സാധാരണ വെർഫ് ക്ലീനപ്പ് ടൂളുകൾ ഉപയോഗിച്ച് വൃത്തിയാക്കും, അതായത്. പഴയ ചിത്രങ്ങൾ (N ദിവസത്തേക്കാൾ പഴയത്), നിലവിലില്ലാത്ത Git ശാഖകളുമായി ബന്ധപ്പെട്ട ചിത്രങ്ങൾ, മറ്റ് നയങ്ങൾ എന്നിവ സ്വയമേവ വൃത്തിയാക്കപ്പെടും.

ഇവിടെ വിവരിച്ചിരിക്കുന്ന പോയിന്റുകളെക്കുറിച്ചുള്ള കൂടുതൽ വിശദാംശങ്ങൾ ഡോക്യുമെന്റേഷനിൽ കാണാം:

• പ്രസിദ്ധീകരണ പ്രക്രിയ;
• കുബർനെറ്റസ് വിന്യാസ പ്രക്രിയയുമായുള്ള സംയോജനം;
• വൃത്തിയാക്കൽ പ്രക്രിയ.

കുറിപ്പുകളും മുൻകരുതലുകളും

1. ADD-ൽ ബാഹ്യ URL പിന്തുണയ്ക്കുന്നില്ല

നിലവിൽ ഒരു നിർദ്ദേശത്തിൽ ഒരു ബാഹ്യ URL ഉപയോഗിക്കുന്നതിന് പിന്തുണയില്ല ADD. നിർദ്ദിഷ്‌ട URL-ലെ ഉറവിടം മാറുമ്പോൾ വെർഫ് ഒരു പുനർനിർമ്മാണം ആരംഭിക്കില്ല. ഈ ഫീച്ചർ ഉടൻ ചേർക്കാൻ ഞങ്ങൾ പദ്ധതിയിടുന്നു.

2. നിങ്ങൾക്ക് ചിത്രത്തിലേക്ക് .git ചേർക്കാൻ കഴിയില്ല

പൊതുവായി പറഞ്ഞാൽ, ഒരു ഡയറക്ടറി ചേർക്കുന്നു .git ചിത്രത്തിൽ - ഒരു ദുഷിച്ച മോശം ശീലം, എന്തുകൊണ്ടെന്ന് ഇതാ:

1. ആണെങ്കിൽ .git അന്തിമ ചിത്രത്തിൽ അവശേഷിക്കുന്നു, ഇത് തത്വങ്ങൾ ലംഘിക്കുന്നു 12 ഫാക്ടർ ആപ്പ്: അന്തിമ ചിത്രം ഒരൊറ്റ പ്രതിബദ്ധതയുമായി ബന്ധിപ്പിച്ചിരിക്കേണ്ടതിനാൽ, അത് ചെയ്യാൻ കഴിയില്ല git checkout ഏകപക്ഷീയമായ പ്രതിബദ്ധത.
2. .git ചിത്രത്തിന്റെ വലുപ്പം വർദ്ധിപ്പിക്കുന്നു (വലിയ ഫയലുകൾ ഒരിക്കൽ അതിൽ ചേർക്കുകയും പിന്നീട് ഇല്ലാതാക്കുകയും ചെയ്തതിനാൽ ശേഖരം വലുതായിരിക്കും). ഒരു നിർദ്ദിഷ്ട പ്രതിബദ്ധതയുമായി മാത്രം ബന്ധപ്പെട്ടിരിക്കുന്ന ഒരു വർക്ക് ട്രീയുടെ വലുപ്പം Git-ലെ പ്രവർത്തനങ്ങളുടെ ചരിത്രത്തെ ആശ്രയിക്കില്ല. ഈ സാഹചര്യത്തിൽ, കൂട്ടിച്ചേർക്കലും തുടർന്നുള്ള നീക്കം ചെയ്യലും .git അവസാന ചിത്രത്തിൽ നിന്ന് പ്രവർത്തിക്കില്ല: ചിത്രം ഇപ്പോഴും ഒരു അധിക ലെയർ നേടും - ഇങ്ങനെയാണ് ഡോക്കർ പ്രവർത്തിക്കുന്നത്.
3. ഡോക്കറിന് അനാവശ്യമായ പുനർനിർമ്മാണം ആരംഭിക്കാൻ കഴിയും, ഒരേ പ്രതിബദ്ധതയാണ് നിർമ്മിക്കുന്നതെങ്കിൽപ്പോലും, വ്യത്യസ്ത വർക്ക്-ട്രീകളിൽ നിന്ന്. ഉദാഹരണത്തിന്, GitLab പ്രത്യേകം ക്ലോൺ ചെയ്ത ഡയറക്ടറികൾ സൃഷ്ടിക്കുന്നു /home/gitlab-runner/builds/HASH/[0-N]/yourproject സമാന്തര അസംബ്ലി പ്രവർത്തനക്ഷമമാക്കുമ്പോൾ. അധിക പുനഃസംയോജനം ഡയറക്‌ടറി ആയതിനാൽ ആയിരിക്കും .git ഒരേ പ്രതിബദ്ധത നിർമ്മിച്ചതാണെങ്കിലും, ഒരേ സംഭരണിയുടെ വ്യത്യസ്ത ക്ലോൺ ചെയ്ത പതിപ്പുകളിൽ വ്യത്യസ്തമാണ്.

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

പൊതുവേ ആവശ്യമായ ചില ഫയലുകൾ മാത്രം ചേർക്കുന്നു നിർദ്ദേശങ്ങളിലൂടെ ADD ഏത് സാഹചര്യത്തിലും എഴുതിയതിന്റെ കാര്യക്ഷമതയും വിശ്വാസ്യതയും വർദ്ധിപ്പിക്കുന്നു Dockerfile, കൂടാതെ ഇതിനായി ശേഖരിച്ച കാഷെയുടെ സ്ഥിരത മെച്ചപ്പെടുത്തുകയും ചെയ്യുന്നു Dockerfile, Git-ലെ അപ്രസക്തമായ മാറ്റങ്ങളിലേക്ക്.

ഫലം

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

എന്നിരുന്നാലും, ഞങ്ങളുടെ സ്വന്തം ബിൽഡർ എഴുതുന്ന പ്രക്രിയയിൽ, നിലവിലുള്ള ഡോക്കർഫയലുകൾക്കുള്ള പിന്തുണ ഞങ്ങൾക്ക് നഷ്ടമായി. ഈ പോരായ്മ ഇപ്പോൾ പരിഹരിച്ചു, ഭാവിയിൽ ഞങ്ങളുടെ ഇഷ്‌ടാനുസൃത സ്റ്റാപ്പൽ ബിൽഡറിനൊപ്പം വിതരണം ചെയ്‌ത ബിൽഡുകൾക്കും കുബർനെറ്റസ് (അതായത് കനിക്കോയിൽ ചെയ്‌തിരിക്കുന്നതു പോലെ കുബെർനെറ്റസ് ഉള്ളിലെ റണ്ണേഴ്‌സിൽ നിർമ്മിക്കുന്നു) എന്നിവയ്‌ക്കും വേണ്ടി ഡോക്കർഫയൽ പിന്തുണ വികസിപ്പിക്കാൻ ഞങ്ങൾ പദ്ധതിയിടുന്നു.

അതിനാൽ, നിങ്ങൾക്ക് പെട്ടെന്ന് രണ്ട് ഡോക്കർഫയലുകൾ കിടക്കുന്നുണ്ടെങ്കിൽ... ശ്രമിക്കൂ വെർഫ്!

വിഷയത്തെക്കുറിച്ചുള്ള ഡോക്യുമെന്റേഷന്റെ PS ലിസ്റ്റ്

• പെട്ടെന്നുള്ള തുടക്കത്തിനുള്ള മാർഗ്ഗനിർദ്ദേശങ്ങൾ;
• dockerfile ബിൽഡർ കോൺഫിഗറേഷനുകൾ;
• വെർഫിലെ സ്റ്റേജ് ഉപകരണം;
• ചിത്രം പ്രസിദ്ധീകരിക്കൽ പ്രക്രിയ;
• കുബർനെറ്റസ് വിന്യാസ പ്രക്രിയയുമായുള്ള സംയോജനം;
• വൃത്തിയാക്കൽ പ്രക്രിയ;
• ഡോക്കർഫയലിന് പകരമായി സ്റ്റാപ്പൽ ബിൽഡർ.

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

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