3-વે મર્જ ટુ વર્ફ: હેલ્મ સાથે "સ્ટીરોઇડ્સ પર" કુબરનેટ્સ પર જમાવટ

આપણે (અને માત્ર આપણે જ નહીં) લાંબા સમયથી જેની રાહ જોઈ રહ્યા હતા તે થયું: વર્ફ, અમારી ઓપન સોર્સ યુટિલિટી એપ્લીકેશન બનાવવા અને તેને કુબરનેટ્સ સુધી પહોંચાડવા માટે, હવે 3-વે મર્જ પેચનો ઉપયોગ કરીને ફેરફારો લાગુ કરવાનું સમર્થન કરે છે! આ ઉપરાંત, આ સંસાધનોને પુનઃનિર્માણ કર્યા વિના હાલના K8s સંસાધનોને હેલ્મ રિલીઝમાં અપનાવવાનું શક્ય છે.

જો તે ખૂબ જ ટૂંકું છે, તો અમે મૂકીએ છીએ WERF_THREE_WAY_MERGE=enabled — અમને જમાવટ મળે છે “જેમ કે માં kubectl apply", હાલના હેલ્મ 2 ઇન્સ્ટોલેશન સાથે સુસંગત અને થોડી વધુ.

પરંતુ ચાલો થિયરીથી શરૂઆત કરીએ: 3-વે-મર્જ પેચ બરાબર શું છે, લોકો તેને જનરેટ કરવાના અભિગમ સાથે કેવી રીતે આવ્યા અને કુબરનેટ્સ-આધારિત ઈન્ફ્રાસ્ટ્રક્ચર સાથે CI/CD પ્રક્રિયાઓમાં શા માટે મહત્વપૂર્ણ છે? અને તે પછી, ચાલો જોઈએ કે વેર્ફમાં 3-વે-મર્જ શું છે, ડિફૉલ્ટ રૂપે કયા મોડ્સનો ઉપયોગ થાય છે અને તેનું સંચાલન કેવી રીતે કરવું.

3-વે-મર્જ પેચ શું છે?

તો, ચાલો YAML મેનિફેસ્ટમાં વર્ણવેલ સંસાધનોને કુબરનેટ્સમાં રોલઆઉટ કરવાના કાર્યથી શરૂ કરીએ.

સંસાધનો સાથે કામ કરવા માટે, Kubernetes API નીચેની મૂળભૂત કામગીરીઓ પ્રદાન કરે છે: બનાવો, પેચ કરો, બદલો અને કાઢી નાખો. એવું માનવામાં આવે છે કે તેમની સહાયથી ક્લસ્ટરમાં સંસાધનોના અનુકૂળ સતત રોલઆઉટનું નિર્માણ કરવું જરૂરી છે. કેવી રીતે?

kubectl હિતાવહ આદેશો

કુબરનેટ્સમાં ઑબ્જેક્ટ્સનું સંચાલન કરવા માટેનો પ્રથમ અભિગમ આ ઑબ્જેક્ટ્સ બનાવવા, સંશોધિત કરવા અને કાઢી નાખવા માટે kubectl હિતાવહ આદેશોનો ઉપયોગ કરવાનો છે. સરળ શબ્દોમાં કહીએ તો:

• ટીમ kubectl run તમે જમાવટ અથવા જોબ ચલાવી શકો છો:

  kubectl run --generator=deployment/apps.v1 DEPLOYMENT_NAME --image=IMAGE

• ટીમ kubectl scale - પ્રતિકૃતિઓની સંખ્યા બદલો:

  kubectl scale --replicas=3 deployment/mysql

• અને તેથી પર

આ અભિગમ પ્રથમ નજરમાં અનુકૂળ લાગે શકે છે. જો કે, ત્યાં સમસ્યાઓ છે:

1. તે મુશ્કેલ છે સ્વચાલિત.
2. કેવી રીતે રૂપરેખાંકન પ્રતિબિંબિત કરો Git માં? ક્લસ્ટરમાં થતા ફેરફારોની સમીક્ષા કેવી રીતે કરવી?
3. કેવી રીતે પ્રદાન કરવું પ્રજનનક્ષમતા પુનઃપ્રારંભ પર રૂપરેખાંકનો?
4. ...

તે સ્પષ્ટ છે કે આ અભિગમ એપ્લિકેશન અને ઈન્ફ્રાસ્ટ્રક્ચરને કોડ (IaC; અથવા તો ગીટોપ્સ વધુ આધુનિક વિકલ્પ તરીકે, કુબરનેટીસ ઇકોસિસ્ટમમાં લોકપ્રિયતા મેળવી રહી છે). તેથી, આ આદેશોને kubectl માં વધુ વિકાસ પ્રાપ્ત થયો નથી.

ઓપરેશન્સ બનાવો, મેળવો, બદલો અને કાઢી નાખો

પ્રાથમિક સાથે બનાવટ તે સરળ છે: ઑપરેશનમાં મેનિફેસ્ટ મોકલો create kube api અને સંસાધન બનાવવામાં આવ્યું છે. મેનિફેસ્ટનું YAML પ્રતિનિધિત્વ Git માં સંગ્રહિત કરી શકાય છે અને આદેશનો ઉપયોગ કરીને બનાવી શકાય છે kubectl create -f manifest.yaml.

С દૂર કરી રહ્યા છીએ પણ સરળ: તે જ અવેજી manifest.yaml ગિટથી ટીમ સુધી kubectl delete -f manifest.yaml.

ઓપરેશન replace તમને સંસાધનને ફરીથી બનાવ્યા વિના, સંસાધન ગોઠવણીને સંપૂર્ણપણે નવા સાથે બદલવાની મંજૂરી આપે છે. આનો અર્થ એ છે કે સંસાધનમાં ફેરફાર કરતા પહેલા, ઓપરેશન સાથે વર્તમાન સંસ્કરણને ક્વેરી કરવી તાર્કિક છે get, તેને બદલો અને તેને ઓપરેશન સાથે અપડેટ કરો replace. kube apiserver બિલ્ટ ઇન છે આશાવાદી લોકીંગ અને, જો સર્જરી પછી get ઑબ્જેક્ટ બદલાઈ ગયો છે, પછી ઑપરેશન replace તે કામ કરશે નહીં.

Git માં રૂપરેખાંકન સંગ્રહિત કરવા અને તેને બદલીને અપડેટ કરવા માટે, તમારે ઓપરેશન કરવાની જરૂર છે get, અમને જે મળ્યું છે તેની સાથે Git માંથી રૂપરેખા મર્જ કરો અને એક્ઝિક્યુટ કરો replace. મૂળભૂત રીતે, kubectl તમને આદેશનો ઉપયોગ કરવાની પરવાનગી આપે છે kubectl replace -f manifest.yamlજ્યાં manifest.yaml — પહેલેથી જ સંપૂર્ણ રીતે તૈયાર (અમારા કિસ્સામાં, મર્જ કરેલ) મેનિફેસ્ટ જે ઇન્સ્ટોલ કરવાની જરૂર છે. તે તારણ આપે છે કે વપરાશકર્તાને મર્જ મેનિફેસ્ટ અમલમાં મૂકવાની જરૂર છે, અને આ મામૂલી બાબત નથી...

તે નોંધવું પણ યોગ્ય છે કે તેમ છતાં manifest.yaml અને Git માં સંગ્રહિત છે, અમે અગાઉથી જાણી શકતા નથી કે ઑબ્જેક્ટ બનાવવા અથવા તેને અપડેટ કરવું જરૂરી છે - આ વપરાશકર્તા સૉફ્ટવેર દ્વારા થવું આવશ્યક છે.

કુલ: શું આપણે સતત રોલઆઉટ બનાવી શકીએ છીએ માત્ર બનાવો, બદલો અને કાઢી નાખો, એ સુનિશ્ચિત કરીને કે ઈન્ફ્રાસ્ટ્રક્ચર રૂપરેખાંકન કોડ અને અનુકૂળ CI/CD સાથે Git માં સંગ્રહિત છે?

સૈદ્ધાંતિક રીતે, અમે આ માટે... તમારે મર્જ ઓપરેશનને અમલમાં મૂકવાની જરૂર પડશે મેનિફેસ્ટો અને અમુક પ્રકારનું બંધનકર્તા જે:

• ક્લસ્ટરમાં ઑબ્જેક્ટની હાજરી તપાસે છે,
• પ્રારંભિક સંસાધન નિર્માણ કરે છે,
• તેને અપડેટ કરે છે અથવા કાઢી નાખે છે.

અપડેટ કરતી વખતે, કૃપા કરીને તેની નોંધ લો સંસાધન બદલાયેલ હોઈ શકે છે છેલ્લા સમયથી get અને આશાવાદી લોકીંગના કેસને આપમેળે હેન્ડલ કરો - વારંવાર અપડેટ કરવાનો પ્રયાસ કરો.

જો કે, જ્યારે કુબે-એપીસર્વર સંસાધનોને અપડેટ કરવાની બીજી રીત પ્રદાન કરે છે ત્યારે વ્હીલને શા માટે ફરીથી શોધો: ઓપરેશન patch, જે વર્ણવેલ કેટલીક સમસ્યાઓમાંથી વપરાશકર્તાને રાહત આપે છે?

પેચ

હવે આપણે પેચો પર જઈએ છીએ.

કુબરનેટ્સમાં અસ્તિત્વમાં છે તે ઑબ્જેક્ટમાં ફેરફારો લાગુ કરવાની પ્રાથમિક રીત પેચો છે. ઓપરેશન patch તે આની જેમ કામ કરે છે:

• kube-apiserver વપરાશકર્તાને JSON ફોર્મમાં પેચ મોકલવાની અને ઑબ્જેક્ટનો ઉલ્લેખ કરવાની જરૂર છે,
• અને apiserver પોતે ઑબ્જેક્ટની વર્તમાન સ્થિતિ સાથે કામ કરશે અને તેને જરૂરી સ્વરૂપમાં લાવશે.

આ કિસ્સામાં આશાવાદી લોકીંગ જરૂરી નથી. આ ઑપરેશન રિપ્લેસ કરતાં વધુ ઘોષણાત્મક છે, જો કે શરૂઆતમાં તે બીજી રીતે લાગે છે.

આ રીતે:

• ઓપરેશનનો ઉપયોગ કરીને create અમે Git ના મેનિફેસ્ટ અનુસાર ઑબ્જેક્ટ બનાવીએ છીએ,
• ની મદદ સાથે delete - જો ઑબ્જેક્ટની જરૂર ન હોય તો કાઢી નાખો,
• ની મદદ સાથે patch - અમે ઑબ્જેક્ટ બદલીએ છીએ, તેને ગિટમાં વર્ણવેલ ફોર્મમાં લાવીએ છીએ.

જો કે, આ કરવા માટે, તમારે બનાવવાની જરૂર છે યોગ્ય પેચ!

હેલ્મ 2: 2-વે-મર્જમાં પેચો કેવી રીતે કાર્ય કરે છે

જ્યારે તમે પ્રથમ રીલીઝ ઇન્સ્ટોલ કરો છો, ત્યારે હેલ્મ ઓપરેશન કરે છે create ચાર્ટ સંસાધનો માટે.

દરેક સંસાધન માટે હેલ્મ રિલીઝ અપડેટ કરતી વખતે:

• પાછલા ચાર્ટમાંથી સંસાધન સંસ્કરણ અને વર્તમાન ચાર્ટ સંસ્કરણ વચ્ચેના પેચને ધ્યાનમાં લે છે,
• આ પેચ લાગુ કરે છે.

અમે આ પેચને કૉલ કરીશું 2-વે મર્જ પેચ, કારણ કે તેની રચનામાં 2 મેનિફેસ્ટો સામેલ છે:

• અગાઉના પ્રકાશનમાંથી સંસાધન મેનિફેસ્ટ,
• વર્તમાન સંસાધનમાંથી સંસાધન મેનિફેસ્ટ.

ઓપરેશન દૂર કરતી વખતે delete in kube apiserver ને એવા સંસાધનો માટે બોલાવવામાં આવે છે જે અગાઉના પ્રકાશનમાં જાહેર કરવામાં આવ્યા હતા, પરંતુ વર્તમાનમાં જાહેર કરાયા નથી.

2-વે મર્જ પેચ અભિગમમાં સમસ્યા છે: તે તરફ દોરી જાય છે ક્લસ્ટરમાંના સંસાધનની વાસ્તવિક સ્થિતિ અને Git માં મેનિફેસ્ટ સાથે સમન્વયની બહાર.

ઉદાહરણ સાથે સમસ્યાનું ચિત્રણ

• Git માં, એક ચાર્ટ એક મેનિફેસ્ટ સંગ્રહિત કરે છે જેમાં ક્ષેત્ર છે image જમાવટ બાબતો ubuntu:18.04.
• દ્વારા વપરાશકર્તા kubectl edit આ ક્ષેત્રની કિંમતમાં બદલી ubuntu:19.04.
• જ્યારે સુકાન ચાર્ટ ફરીથી જમાવવામાં આવે છે પેચ જનરેટ કરતું નથી, કારણ કે ક્ષેત્ર image પ્રકાશનના પાછલા સંસ્કરણમાં અને વર્તમાન ચાર્ટમાં સમાન છે.
• પુનઃ જમાવટ પછી image અવશેષો ubuntu:19.04, જોકે ચાર્ટ કહે છે ubuntu:18.04.

અમને ડિસિંક્રોનાઇઝેશન મળ્યું અને ઘોષણાત્મકતા ગુમાવી દીધી.

સમન્વયિત સંસાધન શું છે?

સામાન્ય રીતે કહીએ તો, પૂર્ણ ચાલી રહેલ ક્લસ્ટરમાં રિસોર્સ મેનિફેસ્ટ અને ગિટમાંથી મેનિફેસ્ટ વચ્ચે મેળ મેળવવો અશક્ય છે. કારણ કે વાસ્તવિક મેનિફેસ્ટમાં સેવા એનોટેશન/લેબલ્સ, વધારાના કન્ટેનર અને અન્ય ડેટા હોઈ શકે છે જે કેટલાક નિયંત્રકો દ્વારા ગતિશીલ રીતે સંસાધનમાંથી ઉમેરવામાં અને દૂર કરવામાં આવે છે. અમે આ ડેટાને Git માં રાખી શકતા નથી અને નથી ઈચ્છતા. જો કે, અમે ઇચ્છીએ છીએ કે અમે Git માં સ્પષ્ટપણે ઉલ્લેખિત ક્ષેત્રો રોલઆઉટ પર યોગ્ય મૂલ્યો લેવા.

તે ખૂબ સામાન્ય બહાર વળે છે સમન્વયિત સંસાધન નિયમ: સંસાધનને રોલઆઉટ કરતી વખતે, તમે ફક્ત તે ફીલ્ડ્સને બદલી અથવા કાઢી શકો છો કે જે Git ના મેનિફેસ્ટમાં સ્પષ્ટપણે ઉલ્લેખિત છે (અથવા અગાઉના સંસ્કરણમાં ઉલ્લેખિત હતા અને હવે કાઢી નાખવામાં આવ્યા છે).

3-વે મર્જ પેચ

મુખ્ય વિચાર 3-વે મર્જ પેચ: અમે ચાલી રહેલા ક્લસ્ટરમાંથી મેનિફેસ્ટના વર્તમાન સંસ્કરણને ધ્યાનમાં લઈને, Git તરફથી મેનિફેસ્ટના છેલ્લા લાગુ કરેલ સંસ્કરણ અને Gitમાંથી મેનિફેસ્ટના લક્ષ્ય સંસ્કરણ વચ્ચે એક પેચ જનરેટ કરીએ છીએ. પરિણામી પેચ સિંક્રનાઇઝ્ડ સંસાધન નિયમનું પાલન કરવું આવશ્યક છે:

• લક્ષ્ય સંસ્કરણમાં ઉમેરાયેલ નવા ક્ષેત્રો પેચનો ઉપયોગ કરીને ઉમેરવામાં આવે છે;
• છેલ્લા લાગુ કરેલ સંસ્કરણમાં અગાઉ અસ્તિત્વમાં છે અને લક્ષ્ય સંસ્કરણમાં અસ્તિત્વમાં નથી તે પેચનો ઉપયોગ કરીને ફરીથી સેટ કરવામાં આવે છે;
• ઑબ્જેક્ટના વર્તમાન સંસ્કરણમાં ફીલ્ડ્સ કે જે મેનિફેસ્ટના લક્ષ્ય સંસ્કરણથી અલગ છે તે પેચનો ઉપયોગ કરીને અપડેટ કરવામાં આવે છે.

તે આ સિદ્ધાંત પર છે કે તે પેચો પેદા કરે છે kubectl apply:

• મેનિફેસ્ટનું છેલ્લું લાગુ વર્ઝન ઑબ્જેક્ટની જ ટીકામાં સંગ્રહિત છે,
• લક્ષ્ય - ઉલ્લેખિત YAML ફાઇલમાંથી લેવામાં આવે છે,
• વર્તમાન એક ચાલી રહેલ ક્લસ્ટરમાંથી છે.

હવે જ્યારે અમે સિદ્ધાંતને ઉકેલી લીધો છે, તે તમને કહેવાનો સમય છે કે અમે વર્ફમાં શું કર્યું.

werf માં ફેરફારો લાગુ કરી રહ્યા છીએ

અગાઉ, હેલ્મ 2 ની જેમ werf, 2-વે-મર્જ પેચનો ઉપયોગ કરતું હતું.

સમારકામ પેચ

નવા પ્રકારના પેચો પર સ્વિચ કરવા માટે - 3-વે-મર્જ - પ્રથમ પગલું અમે કહેવાતા સમારકામ પેચો.

જમાવટ કરતી વખતે, સ્ટાન્ડર્ડ 2-વે-મર્જ પેચનો ઉપયોગ કરવામાં આવે છે, પરંતુ werf વધુમાં એક પેચ જનરેટ કરે છે જે સંસાધનની વાસ્તવિક સ્થિતિને ગિટમાં લખેલી વસ્તુ સાથે સિંક્રનાઇઝ કરશે (આવા પેચ ઉપર વર્ણવેલ સમાન સિંક્રનાઇઝ્ડ રિસોર્સ નિયમનો ઉપયોગ કરીને બનાવવામાં આવે છે) .

જો ડિસિંક્રોનાઇઝેશન થાય છે, ડિપ્લોયમેન્ટના અંતે વપરાશકર્તાને અનુરૂપ સંદેશ અને પેચ સાથે ચેતવણી પ્રાપ્ત થાય છે જે સંસાધનને સિંક્રનાઇઝ્ડ સ્વરૂપમાં લાવવા માટે લાગુ કરવું આવશ્યક છે. આ પેચ ખાસ ટીકામાં પણ નોંધાયેલ છે werf.io/repair-patch. એવું માનવામાં આવે છે કે વપરાશકર્તાના હાથ сам આ પેચ લાગુ કરશે: werf તેને બિલકુલ લાગુ કરશે નહીં.

રિપેર પેચ જનરેટ કરવું એ એક અસ્થાયી માપ છે જે તમને 3-વે-મર્જ સિદ્ધાંતના આધારે પેચો બનાવવાનું ખરેખર પરીક્ષણ કરવાની મંજૂરી આપે છે, પરંતુ આ પેચોને આપમેળે લાગુ કરશો નહીં. આ ક્ષણે, આ ઑપરેટિંગ મોડ ડિફૉલ્ટ રૂપે સક્ષમ છે.

ફક્ત નવા પ્રકાશનો માટે 3-વે-મર્જ પેચ

1 ડિસેમ્બર, 2019 થી, werf ના બીટા અને આલ્ફા વર્ઝન શરૂ થાય છે મૂળભૂત ફક્ત werf દ્વારા બહાર પાડવામાં આવેલ નવા હેલ્મ રીલીઝમાં ફેરફારો લાગુ કરવા માટે સંપૂર્ણ 3-વે-મર્જ પેચનો ઉપયોગ કરો. હાલના પ્રકાશનો 2-વે-મર્જ + રિપેર પેચ અભિગમનો ઉપયોગ કરવાનું ચાલુ રાખશે.

આ ઓપરેટિંગ મોડને સેટિંગ દ્વારા સ્પષ્ટ રીતે સક્ષમ કરી શકાય છે WERF_THREE_WAY_MERGE_MODE=onlyNewReleases હવે

નોંધણી: આ ફીચર અનેક રીલીઝમાં વર્ફમાં દેખાયું: આલ્ફા ચેનલમાં તે વર્ઝન સાથે તૈયાર થઈ ગયું v1.0.5-આલ્ફા.19, અને બીટા ચેનલમાં - સાથે v1.0.4-બીટા.20.

તમામ પ્રકાશનો માટે 3-વે-મર્જ પેચ

15 ડિસેમ્બર, 2019 થી, werf ના બીટા અને આલ્ફા વર્ઝન તમામ રીલીઝમાં ફેરફારો લાગુ કરવા માટે મૂળભૂત રીતે સંપૂર્ણ 3-વે-મર્જ પેચનો ઉપયોગ કરવાનું શરૂ કરે છે.

આ ઓપરેટિંગ મોડને સેટિંગ દ્વારા સ્પષ્ટ રીતે સક્ષમ કરી શકાય છે WERF_THREE_WAY_MERGE_MODE=enabled હવે

સંસાધન ઓટોસ્કેલિંગ સાથે શું કરવું?

કુબરનેટ્સમાં 2 પ્રકારના ઓટોસ્કેલિંગ છે: એચપીએ (હોરીઝોન્ટલ) અને વીપીએ (વર્ટિકલ).

આડું આપોઆપ પ્રતિકૃતિઓની સંખ્યા પસંદ કરે છે, ઊભી - સંસાધનોની સંખ્યા. પ્રતિકૃતિઓની સંખ્યા અને સંસાધન આવશ્યકતાઓ બંને સંસાધન મેનિફેસ્ટમાં ઉલ્લેખિત છે (સંસાધન મેનિફેસ્ટ જુઓ). spec.replicas અથવા spec.containers[].resources.limits.cpu, spec.containers[].resources.limits.memory и другие).

સમસ્યા: જો વપરાશકર્તા ચાર્ટમાં કોઈ સંસાધનને ગોઠવે છે જેથી તે સંસાધન માટે ચોક્કસ મૂલ્યોનો ઉલ્લેખ કરે અથવા આ સંસાધન માટે પ્રતિકૃતિઓ અને ઑટોસ્કેલર્સ સક્ષમ હોય, તો પછી દરેક જમાવટ સાથે werf આ મૂલ્યોને ચાર્ટ મેનિફેસ્ટમાં લખેલા પર ફરીથી સેટ કરશે. .

સમસ્યાના બે ઉકેલો છે. શરૂ કરવા માટે, ચાર્ટ મેનિફેસ્ટમાં સ્વતઃ-સ્કેલ કરેલ મૂલ્યોનો સ્પષ્ટ ઉલ્લેખ કરવાનું ટાળવું શ્રેષ્ઠ છે. જો આ વિકલ્પ કોઈ કારણસર યોગ્ય ન હોય (ઉદાહરણ તરીકે, કારણ કે પ્રારંભિક સંસાધન મર્યાદા અને ચાર્ટમાં પ્રતિકૃતિઓની સંખ્યા સેટ કરવી અનુકૂળ છે), તો werf નીચેની ટીકાઓ ઓફર કરે છે:

• werf.io/set-replicas-only-on-creation=true
• werf.io/set-resources-only-on-creation=true

જો આવી ટીકા હાજર હોય, તો werf દરેક જમાવટ પર અનુરૂપ મૂલ્યોને ફરીથી સેટ કરશે નહીં, પરંતુ જ્યારે સંસાધન શરૂઆતમાં બનાવવામાં આવે ત્યારે જ તેને સેટ કરશે.

વધુ વિગતો માટે, માટે પ્રોજેક્ટ દસ્તાવેજીકરણ જુઓ એચપીએ и VPA.

3-વે-મર્જ પેચનો ઉપયોગ પ્રતિબંધિત કરો

વપરાશકર્તા હાલમાં પર્યાવરણ વેરીએબલનો ઉપયોગ કરીને werf માં નવા પેચોના ઉપયોગને પ્રતિબંધિત કરી શકે છે WERF_THREE_WAY_MERGE_MODE=disabled. જો કે, શરૂ 1 માર્ચ, 2020 થી, આ પ્રતિબંધ લાગુ થશે નહીં. અને માત્ર 3-વે-મર્જ પેચનો ઉપયોગ કરવો શક્ય બનશે.

વર્ફમાં સંસાધનોનો દત્તક લેવો

3-વે-મર્જ પેચ સાથે ફેરફારો લાગુ કરવાની પદ્ધતિમાં નિપુણતાથી અમને હેલ્મ રિલીઝમાં ક્લસ્ટરમાં અસ્તિત્વમાં રહેલા સંસાધનોને અપનાવવા જેવી સુવિધાને તાત્કાલિક અમલમાં મૂકવાની મંજૂરી મળી.

હેલ્મ 2 માં સમસ્યા છે: તમે શરૂઆતથી આ સંસાધનને ફરીથી બનાવ્યા વિના ચાર્ટ મેનિફેસ્ટમાં સંસાધન ઉમેરી શકતા નથી કે જે પહેલાથી જ ક્લસ્ટરમાં અસ્તિત્વમાં છે (જુઓ. #6031, #3275). અમે પ્રકાશન માટે વર્તમાન સંસાધનોને સ્વીકારવાનું શીખવ્યું. આ કરવા માટે, તમારે ચાલી રહેલ ક્લસ્ટરમાંથી સંસાધનના વર્તમાન સંસ્કરણ પર એનોટેશન ઇન્સ્ટોલ કરવાની જરૂર છે (ઉદાહરણ તરીકે, ઉપયોગ કરીને kubectl edit):

"werf.io/allow-adoption-by-release": RELEASE_NAME

હવે સંસાધનને ચાર્ટમાં વર્ણવવાની જરૂર છે અને આગલી વખતે જ્યારે werf યોગ્ય નામ સાથે પ્રકાશન જમાવશે, ત્યારે હાલના સંસાધનને આ પ્રકાશનમાં સ્વીકારવામાં આવશે અને તેના નિયંત્રણ હેઠળ રહેશે. વધુમાં, રીલીઝ માટે સંસાધન સ્વીકારવાની પ્રક્રિયામાં, werf એ જ 3-વે-મર્જ પેચ અને સિંક્રનાઇઝ કરેલ સંસાધન નિયમનો ઉપયોગ કરીને, ચાલતા ક્લસ્ટરમાંથી સંસાધનની વર્તમાન સ્થિતિને ચાર્ટમાં વર્ણવેલ રાજ્યમાં લાવશે.

નોંધણી: સેટિંગ WERF_THREE_WAY_MERGE_MODE સંસાધનોના દત્તકને અસર કરતું નથી - દત્તક લેવાના કિસ્સામાં, 3-વે-મર્જ પેચનો હંમેશા ઉપયોગ થાય છે.

વિગતો - માં દસ્તાવેજીકરણ.

તારણો અને ભાવિ યોજનાઓ

હું આશા રાખું છું કે આ લેખ પછી તે સ્પષ્ટ થઈ ગયું છે કે 3-વે-મર્જ પેચ શું છે અને તેઓ શા માટે આવ્યા છે. વર્ફ પ્રોજેક્ટના વિકાસના વ્યવહારિક દૃષ્ટિકોણથી, તેનું અમલીકરણ એ હેલ્મ જેવી જમાવટને સુધારવા તરફનું બીજું પગલું હતું. હવે તમે રૂપરેખાંકન સિંક્રનાઇઝેશનની સમસ્યાઓ વિશે ભૂલી શકો છો, જે ઘણીવાર હેલ્મ 2 નો ઉપયોગ કરતી વખતે ઉદ્ભવે છે. તે જ સમયે, હેલ્મ રિલીઝમાં પહેલેથી જ ડાઉનલોડ કરેલ કુબરનેટ્સ સંસાધનોને અપનાવવાની નવી ઉપયોગી સુવિધા ઉમેરવામાં આવી હતી.

ગો ટેમ્પ્લેટ્સનો ઉપયોગ જેવી હેલ્મ જેવી ડિપ્લોયમેન્ટમાં હજુ પણ કેટલીક સમસ્યાઓ અને પડકારો છે, જેને અમે સંબોધવાનું ચાલુ રાખીશું.

સંસાધન અપડેટ પદ્ધતિઓ અને અપનાવવા વિશેની માહિતી પણ અહીં મળી શકે છે આ દસ્તાવેજીકરણ પૃષ્ઠ.

સુકાન 3

ખાસ નોંધ લેવા લાયક પ્રકાશિત બીજા દિવસે હેલ્મનું નવું મુખ્ય સંસ્કરણ - v3 - જે 3-વે-મર્જ પેચનો પણ ઉપયોગ કરે છે અને ટિલરથી છૂટકારો મેળવે છે. હેલ્મના નવા સંસ્કરણની જરૂર છે સ્થળાંતર વર્તમાન સ્થાપનોને નવા પ્રકાશન સંગ્રહ ફોર્મેટમાં રૂપાંતરિત કરવા માટે.

વેર્ફ, તેના ભાગ માટે, હાલમાં ટિલરનો ઉપયોગ કરવાથી છૂટકારો મેળવ્યો છે, 3-વે-મર્જ પર સ્વિચ કર્યું અને ઉમેર્યું ઘણું વધારે, જ્યારે હાલના હેલ્મ 2 સ્થાપનો સાથે સુસંગત રહે છે (કોઈ સ્થળાંતર સ્ક્રિપ્ટ ચલાવવાની જરૂર નથી). તેથી, જ્યાં સુધી werf હેલ્મ 3 પર સ્વિચ ન કરે ત્યાં સુધી, werf વપરાશકર્તાઓ Helm 3 કરતાં Helm 2 ના મુખ્ય ફાયદાઓ ગુમાવતા નથી (werf પણ તેમાં છે).

જો કે, હેલ્મ 3 કોડબેઝમાં વેર્ફનું સ્વિચ અનિવાર્ય છે અને નજીકના ભવિષ્યમાં થશે. સંભવતઃ આ werf 1.1 અથવા werf 1.2 હશે (આ ક્ષણે, werf નું મુખ્ય સંસ્કરણ 1.0 છે; werf સંસ્કરણિંગ ઉપકરણ વિશે વધુ માહિતી માટે, જુઓ અહીં). આ સમય દરમિયાન હેલ્મ 3 પાસે સ્થિર થવાનો સમય હશે.

PS

અમારા બ્લોગ પર પણ વાંચો:

• werf માં નવીનતાઓ વિશે નોંધોની શ્રેણી:
  • «જટિલ હેલ્મ ચાર્ટ બનાવવા માટે werf નો ઉપયોગ કરવો»;
  • «વર્ફમાં મોનોરેપો અને મલ્ટિરેપો માટે સપોર્ટ અને ડોકર રજિસ્ટ્રીને તેની સાથે શું કરવું છે»;
  • «તમે હવે નિયમિત ડોકરફાઇલનો ઉપયોગ કરીને werf માં ડોકર છબીઓ બનાવી શકો છો».
• «werf - કુબરનેટ્સમાં CI/CD માટે અમારું સાધન (વિહંગાવલોકન અને વિડિયો રિપોર્ટ)»;
• «werf અને GitLab CI સાથે સમાન પ્રકારની માઇક્રોસર્વિસિસ બનાવો અને તેનો ઉપયોગ કરો»;
• «સુકાન 3 નો પરિચય».

સોર્સ: www.habr.com