વર્ફ બિલ્ડરમાં સામગ્રી-આધારિત ટેગિંગ: તે શા માટે અને કેવી રીતે કાર્ય કરે છે?

વર્ફ કુબરનેટ્સને એપ્લિકેશન બનાવવા અને પહોંચાડવા માટે અમારી ઓપન સોર્સ GitOps CLI યુટિલિટી છે. IN રિલીઝ v1.1 ઇમેજ કલેક્ટરમાં એક નવી સુવિધા રજૂ કરવામાં આવી હતી: સામગ્રી દ્વારા છબીઓને ટેગ કરવી અથવા સામગ્રી-આધારિત ટેગિંગ. અત્યાર સુધી, વર્ફમાં સામાન્ય ટેગીંગ સ્કીમમાં ગિટ ટેગ, ગિટ બ્રાન્ચ અથવા ગિટ કમિટ દ્વારા ડોકર ઈમેજીસને ટેગ કરવાનું સામેલ હતું. પરંતુ આ તમામ યોજનાઓમાં ગેરફાયદા છે જે નવી ટેગિંગ વ્યૂહરચના દ્વારા સંપૂર્ણપણે ઉકેલી દેવામાં આવી છે. તેના વિશેની વિગતો અને તે શા માટે ખૂબ સારું છે તે કટ હેઠળ છે.

એક Git રિપોઝીટરીમાંથી માઇક્રોસર્વિસિસનો સમૂહ રોલ આઉટ

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

એવી પરિસ્થિતિઓ છે જ્યારે સેવાઓ ખરેખર સ્વતંત્ર હોય છે અને એક એપ્લિકેશન સાથે સંકળાયેલી નથી. આ કિસ્સામાં, તેઓ અલગ-અલગ પ્રોજેક્ટ્સમાં સ્થિત હશે અને દરેક પ્રોજેક્ટમાં અલગ-અલગ CI/CD પ્રક્રિયાઓ દ્વારા તેમની રજૂઆત હાથ ધરવામાં આવશે.

જો કે, વાસ્તવમાં, વિકાસકર્તાઓ ઘણીવાર એક જ એપ્લિકેશનને અનેક માઇક્રોસર્વિસિસમાં વિભાજિત કરે છે, પરંતુ દરેક માટે એક અલગ રીપોઝીટરી અને પ્રોજેક્ટ બનાવવો... સ્પષ્ટ ઓવરકિલ છે. આ પરિસ્થિતિ છે જેની આગળ ચર્ચા કરવામાં આવશે: આવી ઘણી બધી માઇક્રોસર્વિસિસ એક જ પ્રોજેક્ટ રિપોઝીટરીમાં સ્થિત છે અને CI/CDમાં એક પ્રક્રિયા દ્વારા રિલીઝ થાય છે.

ગિટ શાખા અને ગિટ ટેગ દ્વારા ટેગિંગ

ચાલો કહીએ કે સૌથી સામાન્ય ટેગિંગ વ્યૂહરચનાનો ઉપયોગ થાય છે - ટેગ-અથવા-શાખા. Git શાખાઓ માટે, બ્રાન્ચના નામ સાથે ઈમેજો ટૅગ કરવામાં આવે છે, એક સમયે એક બ્રાન્ચ માટે તે બ્રાન્ચના નામ દ્વારા માત્ર એક જ પ્રકાશિત ઈમેજ હોય ​​છે. ગિટ ટૅગ્સ માટે, ટૅગના નામ પ્રમાણે છબીઓને ટૅગ કરવામાં આવે છે.

જ્યારે નવું ગિટ ટૅગ બનાવવામાં આવે છે-ઉદાહરણ તરીકે, જ્યારે નવું સંસ્કરણ બહાર પાડવામાં આવે છે-ડોકર રજિસ્ટ્રીમાં તમામ પ્રોજેક્ટ છબીઓ માટે એક નવું ડોકર ટેગ બનાવવામાં આવશે:

• myregistry.org/myproject/frontend:v1.1.10
• myregistry.org/myproject/myservice1:v1.1.10
• myregistry.org/myproject/myservice2:v1.1.10
• myregistry.org/myproject/myservice3:v1.1.10
• myregistry.org/myproject/myservice4:v1.1.10
• myregistry.org/myproject/myservice5:v1.1.10
• myregistry.org/myproject/database:v1.1.10

આ નવા ઇમેજ નામો હેલ્મ ટેમ્પ્લેટ્સ દ્વારા કુબરનેટ્સ કન્ફિગરેશનમાં પસાર થાય છે. આદેશ સાથે જમાવટ શરૂ કરતી વખતે werf deploy ક્ષેત્ર અપડેટ કરવામાં આવી રહ્યું છે image કુબરનેટ્સ રિસોર્સમાં બદલાયેલ ઈમેજના નામને કારણે લાગતાવળગતા સંસાધનો મેનિફેસ્ટ અને પુનઃપ્રારંભ કરે છે.

સમસ્યા: એવા કિસ્સામાં જ્યારે, હકીકતમાં, અગાઉના રોલઆઉટ (ગિટ ટેગ) થી ઇમેજની સામગ્રી બદલાઈ નથી, પરંતુ માત્ર તેના ડોકર ટેગમાં, આવું થાય છે વધારાનું આ એપ્લિકેશનને પુનઃપ્રારંભ કરી રહ્યા છીએ અને તે મુજબ, થોડો ડાઉનટાઇમ શક્ય છે. જો કે આ પુનઃપ્રારંભ કરવા માટે કોઈ વાસ્તવિક કારણ નહોતું.

પરિણામે, વર્તમાન ટૅગિંગ સ્કીમ સાથે ઘણી અલગ ગિટ રિપોઝીટરીઝને વાડ કરવી જરૂરી છે અને આ અનેક રીપોઝીટરીઝના રોલઆઉટને ગોઠવવામાં સમસ્યા ઊભી થાય છે. સામાન્ય રીતે, આવી યોજના ઓવરલોડ અને જટિલ હોય છે. એક જ રીપોઝીટરીમાં ઘણી સેવાઓને જોડવી અને ડોકર ટૅગ્સ બનાવવાનું વધુ સારું છે જેથી કરીને કોઈ બિનજરૂરી પુનઃપ્રારંભ ન થાય.

ગિટ કમિટ દ્વારા ટેગિંગ

werf પાસે ગિટ કમિટ્સ સાથે સંકળાયેલ ટેગિંગ વ્યૂહરચના પણ છે.

Git-commit એ Git રિપોઝીટરીના સમાવિષ્ટો માટે એક ઓળખકર્તા છે અને Git રિપોઝીટરીમાં ફાઇલોના સંપાદન ઇતિહાસ પર આધાર રાખે છે, તેથી ડોકર રજિસ્ટ્રીમાં છબીઓને ટેગ કરવા માટે તેનો ઉપયોગ કરવો તાર્કિક લાગે છે.

જો કે, ગિટ કમિટ દ્વારા ટેગિંગમાં ગિટ શાખાઓ અથવા ગિટ ટૅગ્સ દ્વારા ટેગિંગ જેવા જ ગેરફાયદા છે:

• એક ખાલી કમિટ બનાવી શકાય છે જે કોઈપણ ફાઈલોને બદલતી નથી, પરંતુ ઈમેજનો ડોકર ટેગ બદલવામાં આવશે.
• એક મર્જ કમિટ બનાવી શકાય છે જે ફાઈલોને બદલતું નથી, પરંતુ ઈમેજનું ડોકર ટેગ બદલાશે.
• એક પ્રતિબદ્ધતા કરી શકાય છે જે Git માં તે ફાઇલોને બદલી શકે છે જે છબીમાં આયાત કરવામાં આવી નથી, અને છબીનો ડોકર ટેગ ફરીથી બદલવામાં આવશે.

Git શાખાના નામને ટૅગ કરવાથી ઇમેજ વર્ઝન પ્રતિબિંબિત થતું નથી

ગિટ શાખાઓ માટે ટેગિંગ વ્યૂહરચના સાથે સંકળાયેલ બીજી સમસ્યા છે.

શાખાના નામ દ્વારા ટેગીંગ ત્યાં સુધી કામ કરે છે જ્યાં સુધી તે શાખા પરના કમિટ્સને ક્રમિક ક્રમમાં એકત્રિત કરવામાં આવે છે.

જો વર્તમાન સ્કીમમાં વપરાશકર્તા ચોક્કસ શાખા સાથે સંકળાયેલ જૂની કમિટને ફરીથી બનાવવાનું શરૂ કરે છે, તો werf જૂના કમિટ માટે ઇમેજના નવા બિલ્ટ વર્ઝન સાથે સંબંધિત ડોકર ટૅગનો ઉપયોગ કરીને ઇમેજને ફરીથી લખશે. હવેથી આ ટેગનો ઉપયોગ કરીને પોડ્સ પુનઃપ્રારંભ કરતી વખતે ઇમેજના અલગ સંસ્કરણને ખેંચી લેવાનું જોખમ રહેલું છે, જેના પરિણામે અમારી એપ્લિકેશન CI સિસ્ટમ સાથેનું જોડાણ ગુમાવશે અને ડિસિંક્રોનાઇઝ થઈ જશે.

વધુમાં, તેમની વચ્ચેના ટૂંકા ગાળા સાથે એક શાખામાં ક્રમિક દબાણ સાથે, જૂની પ્રતિબદ્ધતા નવી કરતાં પાછળથી સંકલિત થઈ શકે છે: છબીનું જૂનું સંસ્કરણ ગિટ બ્રાન્ચ ટૅગનો ઉપયોગ કરીને નવાને ઓવરરાઈટ કરશે. આવી સમસ્યાઓ CI/CD સિસ્ટમ દ્વારા ઉકેલી શકાય છે (ઉદાહરણ તરીકે, GitLab CI માં બાદમાંની પાઇપલાઇન કમિટ્સની શ્રેણી માટે શરૂ કરવામાં આવે છે). જો કે, બધી સિસ્ટમો આને સમર્થન આપતી નથી અને આવી મૂળભૂત સમસ્યાને રોકવા માટે વધુ વિશ્વસનીય માર્ગ હોવો જોઈએ.

સામગ્રી-આધારિત ટેગિંગ શું છે?

તેથી, સામગ્રી-આધારિત ટેગિંગ શું છે - સામગ્રી દ્વારા છબીઓને ટેગ કરવું.

ડોકર ટૅગ્સ બનાવવા માટે, તે ગિટ પ્રિમિટિવ્સ (ગિટ શાખા, ગિટ ટૅગ...) નથી જેનો ઉપયોગ કરવામાં આવે છે, પરંતુ તેની સાથે સંકળાયેલ ચેકસમ છે:

• છબીની સામગ્રી. ઇમેજ ID ટૅગ તેની સામગ્રીને પ્રતિબિંબિત કરે છે. નવું સંસ્કરણ બનાવતી વખતે, આ ઓળખકર્તા બદલાશે નહીં જો ઈમેજમાંની ફાઈલો બદલાઈ ન હોય;
• Git માં આ છબી બનાવવાનો ઇતિહાસ. વિવિધ Git શાખાઓ સાથે સંકળાયેલી છબીઓ અને werf દ્વારા અલગ બિલ્ડ ઇતિહાસમાં અલગ ID ટૅગ્સ હશે.

આવા ઓળખકર્તા ટેગ કહેવાતા છે છબી સ્ટેજ હસ્તાક્ષર.

દરેક છબીમાં તબક્કાઓના સમૂહનો સમાવેશ થાય છે: from, before-install, git-archive, install, imports-after-install, before-setup... git-latest-patch વગેરે દરેક તબક્કામાં એક ઓળખકર્તા હોય છે જે તેના સમાવિષ્ટોને પ્રતિબિંબિત કરે છે - સ્ટેજ હસ્તાક્ષર (સ્ટેજ સહી).

આ તબક્કાઓનો સમાવેશ કરતી અંતિમ છબી, આ તબક્કાઓના સમૂહના કહેવાતા હસ્તાક્ષર સાથે ટૅગ કરેલી છે - તબક્કાવાર હસ્તાક્ષર, - જે છબીના તમામ તબક્કાઓ માટે સામાન્યીકરણ છે.

રૂપરેખાંકનમાંથી દરેક છબી માટે werf.yaml સામાન્ય કિસ્સામાં, તેની પોતાની હસ્તાક્ષર હશે અને તે મુજબ, ડોકર ટેગ હશે.

સ્ટેજ હસ્તાક્ષર આ બધી સમસ્યાઓ હલ કરે છે:

• ખાલી ગિટ કમિટ માટે પ્રતિરોધક.
• Git પ્રતિરોધક પ્રતિરોધક એ ફાઈલોને બદલી નાખે છે જે ઈમેજ સાથે સંબંધિત નથી.
• બ્રાન્ચના જૂના ગિટ કમિટ માટે બિલ્ડ્સને ફરીથી પ્રારંભ કરતી વખતે છબીના વર્તમાન સંસ્કરણને ઓવરહોલ કરવાની સમસ્યા તરફ દોરી જતું નથી.

આ હવે ભલામણ કરેલ ટેગીંગ વ્યૂહરચના છે અને તમામ CI સિસ્ટમો માટે werf માં ડિફોલ્ટ છે.

વર્ફમાં કેવી રીતે સક્ષમ અને ઉપયોગ કરવો

આદેશ પાસે હવે અનુરૂપ વિકલ્પ છે werf publish: --tag-by-stages-signature=true|false

CI સિસ્ટમમાં, ટેગીંગ વ્યૂહરચના આદેશ દ્વારા નિર્દિષ્ટ કરવામાં આવે છે werf ci-env. અગાઉ, તેના માટે પરિમાણ વ્યાખ્યાયિત કરવામાં આવ્યું હતું werf ci-env --tagging-strategy=tag-or-branch. હવે, જો તમે સ્પષ્ટ કરો werf ci-env --tagging-strategy=stages-signature અથવા આ વિકલ્પનો ઉલ્લેખ કરશો નહીં, werf મૂળભૂત રીતે ટેગિંગ વ્યૂહરચનાનો ઉપયોગ કરશે stages-signature. ટીમ werf ci-env આદેશ માટે આપમેળે જરૂરી ફ્લેગ સેટ કરશે werf build-and-publish (અથવા werf publish), તેથી આ આદેશો માટે કોઈ વધારાના વિકલ્પોનો ઉલ્લેખ કરવાની જરૂર નથી.

ઉદાહરણ તરીકે, આદેશ:

werf publish --stages-storage :local --images-repo registry.hello.com/web/core/system --tag-by-stages-signature

... નીચેની છબીઓ બનાવી શકો છો:

• registry.hello.com/web/core/system/backend:4ef339f84ca22247f01fb335bb19f46c4434014d8daa3d5d6f0e386d
• registry.hello.com/web/core/system/frontend:f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6

તે 4ef339f84ca22247f01fb335bb19f46c4434014d8daa3d5d6f0e386d છબીના તબક્કાઓની સહી છે backendઅને f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6 - છબીના તબક્કાઓની સહી frontend.

વિશિષ્ટ કાર્યોનો ઉપયોગ કરતી વખતે werf_container_image и werf_container_env હેલ્મ ટેમ્પલેટ્સમાં કંઈપણ બદલવાની જરૂર નથી: આ કાર્યો આપમેળે સાચા ઇમેજ નામો જનરેટ કરશે.

CI સિસ્ટમમાં રૂપરેખાંકનનું ઉદાહરણ:

type multiwerf && source <(multiwerf use 1.1 beta)
type werf && source <(werf ci-env gitlab)
werf build-and-publish|deploy

રૂપરેખાંકન પર વધુ માહિતી દસ્તાવેજીકરણમાં ઉપલબ્ધ છે:

• ડિરેક્ટરી → પ્રકાશન (પ્રકાશિત);
• CI/CD સાથે કામ કરવું → સામાન્ય માહિતી → સ્ટેજ-સહી;
• GitLab CI/CD સાથે એકીકરણ → .gitlab-ci.yml.

કુલ

• નવો વિકલ્પ werf publish --tag-by-stages-signature=true|false.
• નવા વિકલ્પ મૂલ્ય werf ci-env --tagging-strategy=stages-signature|tag-or-branch (જો ઉલ્લેખિત ન હોય, તો ડિફોલ્ટ હશે stages-signature).
• જો તમે અગાઉ ગિટ કમિટ માટે ટેગીંગ વિકલ્પોનો ઉપયોગ કર્યો હોય (WERF_TAG_GIT_COMMIT અથવા વિકલ્પ werf publish --tag-git-commit COMMIT), તો પછી ટેગિંગ વ્યૂહરચના પર સ્વિચ કરવાની ખાતરી કરો તબક્કાઓ - સહી.
• નવા પ્રોજેક્ટ્સને નવી ટેગિંગ સ્કીમમાં તરત જ સ્વિચ કરવું વધુ સારું છે.
• werf 1.1 માં ટ્રાન્સફર કરતી વખતે, જૂના પ્રોજેક્ટ્સને નવી ટેગિંગ સ્કીમમાં સ્વિચ કરવાની સલાહ આપવામાં આવે છે, પરંતુ જૂના ટેગ-અથવા-શાખા હજુ પણ આધારભૂત છે.

સામગ્રી-આધારિત ટેગિંગ લેખમાં આવરી લેવામાં આવેલી તમામ સમસ્યાઓનું નિરાકરણ કરે છે:

• ખાલી ગિટ કમિટ માટે ડોકર ટેગ નામનો પ્રતિકાર.
• ગિટમાં ડોકર ટેગ નામની સ્થિતિસ્થાપકતા પ્રતિબદ્ધતા આપે છે જે ઇમેજ માટે અપ્રસ્તુત ફાઇલોને બદલે છે.
• ગિટ શાખાઓ માટે જૂના ગિટ કમિટ માટે બિલ્ડ્સને પુનઃપ્રારંભ કરતી વખતે છબીના વર્તમાન સંસ્કરણને ઓવરહોલ કરવાની સમસ્યા તરફ દોરી જતું નથી.

તેનો ઉપયોગ! અને અમારી મુલાકાત લેવાનું ભૂલશો નહીં GitHubસમસ્યા બનાવવા અથવા અસ્તિત્વમાં છે તે શોધવા માટે, પ્લસ આપો, PR બનાવો અથવા ફક્ત પ્રોજેક્ટના વિકાસને જુઓ.

PS

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

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

સોર્સ: www.habr.com