werf 1.1 રિલીઝ: બિલ્ડર માટે આજે સુધારાઓ અને ભવિષ્ય માટેની યોજનાઓ

વર્ફ કુબરનેટ્સને એપ્લિકેશન બનાવવા અને પહોંચાડવા માટે અમારી ઓપન સોર્સ GitOps CLI યુટિલિટી છે. વચન મુજબ, સંસ્કરણ v1.0 નું પ્રકાશન werf માં નવી સુવિધાઓ ઉમેરવાની અને પરંપરાગત અભિગમોને સુધારવાની શરૂઆત તરીકે ચિહ્નિત કર્યું. હવે અમને રિલીઝ v1.1 રજૂ કરવામાં આનંદ થાય છે, જે વિકાસમાં એક મોટું પગલું છે અને ભવિષ્ય માટેનો પાયો છે કલેક્ટર વર્ફ સંસ્કરણ હાલમાં ઉપલબ્ધ છે ચેનલ 1.1 ea.

પ્રકાશનનો આધાર સ્ટેજ સ્ટોરેજનું નવું આર્કિટેક્ચર છે અને બંને કલેક્ટર્સ (સ્ટેપલ અને ડોકરફાઇલ માટે) ના કાર્યનું ઑપ્ટિમાઇઝેશન છે. નવી સ્ટોરેજ આર્કિટેક્ચર બહુવિધ યજમાનોમાંથી વિતરિત એસેમ્બલીઓ અને સમાન હોસ્ટ પર સમાંતર એસેમ્બલીઓને અમલમાં મૂકવાની શક્યતા ખોલે છે.

કાર્યના ઑપ્ટિમાઇઝેશનમાં સ્ટેજ સિગ્નેચરની ગણતરીના તબક્કે બિનજરૂરી ગણતરીઓથી છુટકારો મેળવવો અને ફાઇલ ચેકસમ્સની ગણતરી કરવાની પદ્ધતિને વધુ કાર્યક્ષમમાં બદલવાનો સમાવેશ થાય છે. આ ઑપ્ટિમાઇઝેશન werf નો ઉપયોગ કરીને પ્રોજેક્ટ બનાવવાનો સરેરાશ સમય ઘટાડે છે. અને નિષ્ક્રિય બિલ્ડ્સ, જ્યારે કેશમાં તમામ તબક્કાઓ અસ્તિત્વમાં છે સ્ટેજ-સ્ટોરેજ, હવે ખરેખર ઝડપી છે. મોટા ભાગના કિસ્સાઓમાં, બિલ્ડને પુનઃપ્રારંભ કરવામાં 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 એક ગેરંટીકૃત અનન્ય છબી ઓળખકર્તા છે જે નવી ઇમેજ બનાવતી વખતે જનરેટ થાય છે.

કેશમાંથી તબક્કાઓ પસંદ કરવા માટેનું અલ્ગોરિધમ ગિટ કમિટ્સના સંબંધને તપાસવા પર આધારિત છે:

1. Werf ચોક્કસ તબક્કાના હસ્તાક્ષરની ગણતરી કરે છે.
2. В સ્ટેજ-સ્ટોરેજ આપેલ હસ્તાક્ષર માટે ઘણા તબક્કાઓ હોઈ શકે છે. Werf સહી સાથે મેળ ખાતા તમામ તબક્કાઓ પસંદ કરે છે.
3. જો વર્તમાન તબક્કો ગિટ (ગિટ-આર્કાઇવ, ગિટ પેચો સાથે કસ્ટમ સ્ટેજ) સાથે જોડાયેલ હોય તો: install, beforeSetup, setup; અથવા git-latest-patch), પછી werf માત્ર તે જ તબક્કાઓ પસંદ કરે છે જે પ્રતિબદ્ધતા સાથે સંકળાયેલા છે જે વર્તમાન કમિટ (જેના માટે બિલ્ડ કહેવામાં આવે છે) ના પૂર્વજ છે.
4. બાકીના યોગ્ય તબક્કાઓમાંથી, એક પસંદ કરવામાં આવે છે - બનાવટની તારીખ દ્વારા સૌથી જૂની.

વિવિધ ગિટ શાખાઓ માટેના તબક્કામાં સમાન હસ્તાક્ષર હોઈ શકે છે. પરંતુ werf વિવિધ શાખાઓ સાથે સંકળાયેલ કેશને આ શાખાઓ વચ્ચે ઉપયોગમાં લેવાથી અટકાવશે, પછી ભલે સહીઓ મેળ ખાતી હોય.

→ દસ્તાવેજીકરણ.

સ્ટેજ સ્ટોરેજમાં સ્ટેજ બનાવવા અને બચાવવા માટે નવું અલ્ગોરિધમ

જો, કેશમાંથી સ્ટેજ પસંદ કરતી વખતે, વર્ફને યોગ્ય સ્ટેજ મળતો નથી, તો નવા સ્ટેજને એસેમ્બલ કરવાની પ્રક્રિયા શરૂ કરવામાં આવે છે.

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

તાજી રીતે એસેમ્બલ કરેલી છબીને અનન્ય ઓળખકર્તા દ્વારા ખાતરી આપવામાં આવે છે TIMESTAMP_MILLISEC (નવું સ્ટેજ નામકરણ ફોર્મેટ જુઓ). કિસ્સામાં સ્ટેજ-સ્ટોરેજ યોગ્ય ઇમેજ મળશે, werf તાજી કમ્પાઇલ કરેલી ઇમેજને કાઢી નાખશે અને કૅશમાંથી ઇમેજનો ઉપયોગ કરશે.

બીજા શબ્દોમાં કહીએ તો: ઇમેજ બનાવવાની પ્રથમ પ્રક્રિયા (સૌથી ઝડપી) તેને સ્ટેજ-સ્ટોરેજમાં સ્ટોર કરવાનો અધિકાર મેળવશે (અને પછી તે આ એક જ ઇમેજ છે જેનો ઉપયોગ તમામ બિલ્ડ્સ માટે કરવામાં આવશે). ધીમી બિલ્ડ પ્રક્રિયા વર્તમાન તબક્કાના બિલ્ડ પરિણામોને બચાવવા અને આગળના બિલ્ડ પર આગળ વધવાથી ઝડપી પ્રક્રિયાને ક્યારેય અવરોધિત કરશે નહીં.

→ દસ્તાવેજીકરણ.

બહેતર ડોકરફાઇલ બિલ્ડર કામગીરી

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

એલ્ગોરિધમ પર આધારિત છે git ls-ટ્રી. માં અલ્ગોરિધમ એકાઉન્ટ રેકોર્ડ્સ લે છે .dockerignore અને જ્યારે જરૂરી હોય ત્યારે જ ફાઇલ ટ્રીને પુનરાવર્તિત રીતે પસાર કરે છે. આમ, અમે ફાઇલ સિસ્ટમને વાંચવાથી અને કદ પર અલ્ગોરિધમની અવલંબનને અલગ કરી દીધી છે. context નોંધપાત્ર નથી.

અલ્ગોરિધમ અનટ્રેક કરેલી ફાઇલોને પણ તપાસે છે અને, જો જરૂરી હોય તો, તેમને ચેકસમમાં ધ્યાનમાં લે છે.

ફાઇલો આયાત કરતી વખતે બહેતર પ્રદર્શન

werf v1.1 ના સંસ્કરણો જ્યારે rsync સર્વરનો ઉપયોગ કરે છે કલાકૃતિઓ અને છબીઓમાંથી ફાઇલો આયાત કરવી. પહેલાં, હોસ્ટ સિસ્ટમમાંથી ડિરેક્ટરી માઉન્ટનો ઉપયોગ કરીને બે પગલામાં આયાત કરવામાં આવતું હતું.

MacOS પર આયાત પ્રદર્શન હવે ડોકર વોલ્યુમ્સ દ્વારા મર્યાદિત નથી, અને આયાત Linux અને Windows જેટલા જ સમયમાં પૂર્ણ થાય છે.

સામગ્રી-આધારિત ટેગિંગ

Werf v1.1 ઇમેજ સામગ્રી દ્વારા કહેવાતા ટેગિંગને સપોર્ટ કરે છે - સામગ્રી-આધારિત ટેગિંગ. પરિણામી ડોકર ઈમેજોના ટૅગ્સ તે ઈમેજોની સામગ્રી પર આધાર રાખે છે.

આદેશ ચલાવતી વખતે werf publish --tags-by-stages-signature અથવા werf ci-env --tagging-strategy=stages-signature કહેવાતા ની પ્રકાશિત છબીઓ સ્ટેજ હસ્તાક્ષર છબી દરેક ઇમેજને આ ઇમેજના સ્ટેજની પોતાની હસ્તાક્ષર સાથે ટૅગ કરવામાં આવે છે, જે દરેક સ્ટેજના નિયમિત હસ્તાક્ષરના સમાન નિયમો અનુસાર અલગથી ગણવામાં આવે છે, પરંતુ તે ઇમેજની સામાન્ય ઓળખકર્તા છે.

છબીના તબક્કાઓની સહી આના પર નિર્ભર છે:

1. આ છબીની સામગ્રી;
2. ગિટ ફેરફારોનો ઇતિહાસ જે આ સામગ્રી તરફ દોરી ગયો.

ગિટ રીપોઝીટરીમાં હંમેશા ડમી કમિટ હોય છે જે ઈમેજ ફાઈલોની સામગ્રીને બદલતા નથી. ઉદાહરણ તરીકે, માત્ર ટિપ્પણીઓ સાથે કમિટ કરે છે અથવા મર્જ કમિટ કરે છે, અથવા કમિટ કરે છે જે ગિટમાં તે ફાઇલોને બદલી દે છે જે છબીમાં આયાત કરવામાં આવશે નહીં.

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

ઉપરાંત, સામગ્રી-આધારિત ટેગિંગ એ Git શાખાઓ પર ટેગિંગ કરતાં વધુ વિશ્વસનીય ટેગિંગ પદ્ધતિ છે, કારણ કે પરિણામી છબીઓની સામગ્રી એક જ શાખાના બહુવિધ કમિટ્સને એસેમ્બલ કરવા માટે CI સિસ્ટમમાં પાઇપલાઇન્સ ચલાવવાના ક્રમ પર આધારિત નથી.

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

→ દસ્તાવેજીકરણ. આ સુવિધા માટે એક અલગ પ્રકાશન પણ સમર્પિત કરવામાં આવશે. અપડેટ કરેલ (3 એપ્રિલ): વિગતો સાથેનો લેખ પ્રકાશિત.

લોગીંગ સ્તરો

વપરાશકર્તા પાસે હવે આઉટપુટને નિયંત્રિત કરવાની, લોગીંગ લેવલ સેટ કરવાની અને ડીબગીંગ માહિતી સાથે કામ કરવાની તક છે. વિકલ્પો ઉમેર્યા --log-quiet, --log-verbose, --log-debug.

મૂળભૂત રીતે, આઉટપુટમાં ન્યૂનતમ માહિતી શામેલ છે:

વર્બોઝ આઉટપુટનો ઉપયોગ કરતી વખતે (--log-verbose) તમે જોઈ શકો છો કે werf કેવી રીતે કામ કરે છે:

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

ભવિષ્ય ની યોજનાઓ

સાવધાન નીચે વર્ણવેલ વિકલ્પો ચિહ્નિત થયેલ છે v1.1 આ સંસ્કરણમાં ઉપલબ્ધ થશે, તેમાંના ઘણા નજીકના ભવિષ્યમાં. અપડેટ્સ ઓટો-અપડેટ્સ દ્વારા આવશે multiwerf નો ઉપયોગ કરતી વખતે. આ સુવિધાઓ v1.1 કાર્યોના સ્થિર ભાગને અસર કરતી નથી; તેમના દેખાવને હાલના રૂપરેખાંકનોમાં મેન્યુઅલ વપરાશકર્તા હસ્તક્ષેપની જરૂર રહેશે નહીં.

વિવિધ ડોકર રજિસ્ટ્રી અમલીકરણો માટે સંપૂર્ણ સમર્થન (નવું)

• સંસ્કરણ: v1.1
• તારીખો: માર્ચ
• મુદ્દો

ધ્યેય એ છે કે વપરાશકર્તા જ્યારે werf નો ઉપયોગ કરે ત્યારે પ્રતિબંધો વિના કસ્ટમ અમલીકરણનો ઉપયોગ કરે.

હાલમાં, અમે નીચેના ઉકેલોના સમૂહને ઓળખી કાઢ્યા છે જેના માટે અમે સંપૂર્ણ સમર્થનની ખાતરી આપવા જઈ રહ્યા છીએ:

• ડિફૉલ્ટ (લાઇબ્રેરી/રજિસ્ટ્રી)*,
• AWS ECR
• નીલમ*,
• ડોકર હબ
• GCR*,
• GitHub પેકેજો
• ગિટલેબ રજિસ્ટ્રી*,
• હાર્બર*,
• ક્વે.

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

બે મુખ્ય સમસ્યાઓ ઓળખી શકાય છે:

• કેટલાક સોલ્યુશન્સ ડોકર રજિસ્ટ્રી API નો ઉપયોગ કરીને ટેગ દૂર કરવાનું સમર્થન કરતા નથી, વપરાશકર્તાઓને werf ના સ્વચાલિત સફાઈનો ઉપયોગ કરતા અટકાવે છે. આ AWS ECR, Docker Hub અને GitHub પેકેજો માટે સાચું છે.
• કેટલાક સોલ્યુશન્સ કહેવાતા નેસ્ટેડ રિપોઝીટરીઝ (ડોકર હબ, ગિટહબ પેકેજીસ અને ક્વે) ને સમર્થન આપતા નથી અથવા કરે છે, પરંતુ વપરાશકર્તાએ તેને UI અથવા API (AWS ECR) નો ઉપયોગ કરીને મેન્યુઅલી બનાવવું આવશ્યક છે.

અમે ઉકેલોના મૂળ API નો ઉપયોગ કરીને આ અને અન્ય સમસ્યાઓ ઉકેલવા જઈ રહ્યા છીએ. આ કાર્યમાં દરેક માટે પરીક્ષણો સાથે વર્ફ ઓપરેશનના સંપૂર્ણ ચક્રને આવરી લેવાનો પણ સમાવેશ થાય છે.

વિતરિત ઈમેજ બિલ્ડ (↑)

• સંસ્કરણ: v1.2 v1.1 (આ સુવિધાને અમલમાં મૂકવાની પ્રાથમિકતા વધારવામાં આવી છે)
• તારીખો: માર્ચ-એપ્રિલ માર્ચ
• મુદ્દો

આ ક્ષણે, werf v1.0 અને v1.1 નો ઉપયોગ ફક્ત એક જ સમર્પિત હોસ્ટ પર ઈમેજીસ બનાવવા અને પ્રકાશિત કરવા અને કુબરનેટ્સ પર એપ્લિકેશનને જમાવવા માટે થઈ શકે છે.

વર્ફના વિતરિત કાર્યની શક્યતાઓ ખોલવા માટે, જ્યારે કુબરનેટ્સમાં એપ્લિકેશનનું નિર્માણ અને જમાવટ કેટલાક મનસ્વી યજમાનો પર શરૂ કરવામાં આવે છે અને આ યજમાનો તેમની સ્થિતિને બિલ્ડ્સ (અસ્થાયી દોડવીરો) વચ્ચે સાચવતા નથી, ત્યારે વર્ફને ઉપયોગ કરવાની ક્ષમતાને અમલમાં મૂકવાની જરૂર છે. સ્ટેજ સ્ટોર તરીકે ડોકર રજિસ્ટ્રી.

પહેલાં, જ્યારે werf પ્રોજેક્ટને હજુ પણ dapp કહેવામાં આવતું હતું, ત્યારે તેને આવી તક મળી હતી. જો કે, અમે અસંખ્ય સમસ્યાઓનો સામનો કર્યો છે જેને વર્ફમાં આ કાર્યક્ષમતાને અમલમાં મૂકતી વખતે ધ્યાનમાં લેવાની જરૂર છે.

નોંધણી. આ સુવિધા માટે કલેક્ટરને કુબરનેટ્સ પોડ્સની અંદર કામ કરવાની જરૂર નથી, કારણ કે આ કરવા માટે, તમારે સ્થાનિક ડોકર સર્વર પરની અવલંબનમાંથી છૂટકારો મેળવવાની જરૂર છે (કુબરનેટસ પોડમાં સ્થાનિક ડોકર સર્વરની કોઈ ઍક્સેસ નથી, કારણ કે પ્રક્રિયા પોતે કન્ટેનરમાં ચાલી રહી છે, અને વર્ફ સપોર્ટ કરતું નથી અને કરશે નહીં. નેટવર્ક પર ડોકર સર્વર સાથે કામ કરવું). કુબરનેટ્સ ચલાવવા માટેનો આધાર અલગથી લાગુ કરવામાં આવશે.

GitHub ક્રિયાઓ માટે સત્તાવાર સમર્થન (નવું)

• સંસ્કરણ: v1.1
• તારીખો: માર્ચ
• મુદ્દો

વર્ફ દસ્તાવેજીકરણનો સમાવેશ થાય છે (વિભાગો સંદર્ભ и માર્ગદર્શન), તેમજ werf સાથે કામ કરવા માટે સત્તાવાર GitHub ક્રિયા.

વધુમાં, તે વેર્ફને ક્ષણિક દોડવીરો પર કામ કરવાની મંજૂરી આપશે.

સીઆઈ સિસ્ટમ સાથે વપરાશકર્તાની ક્રિયાપ્રતિક્રિયાના મિકેનિક્સ એપ્લિકેશનને બિલ્ડ/રોલ આઉટ કરવા માટે ચોક્કસ ક્રિયાઓ શરૂ કરવા માટે પુલ વિનંતીઓ પર લેબલ મૂકવા પર આધારિત હશે.

werf (↓) સાથે એપ્લિકેશનનો સ્થાનિક વિકાસ અને જમાવટ

• સંસ્કરણ: v1.1
• તારીખો: જાન્યુઆરી-ફેબ્રુઆરી એપ્રિલ
• મુદ્દો

મુખ્ય ધ્યેય એ બૉક્સની બહાર, જટિલ ક્રિયાઓ વિના, સ્થાનિક રીતે અને ઉત્પાદનમાં એપ્લિકેશનને જમાવટ કરવા માટે એક એકીકૃત રૂપરેખા હાંસલ કરવાનો છે.

werf પાસે ઓપરેટિંગ મોડ હોવો જરૂરી છે જેમાં તે એપ્લિકેશન કોડને સંપાદિત કરવા અને ડિબગીંગ માટે ચાલી રહેલ એપ્લિકેશનમાંથી તરત જ પ્રતિસાદ પ્રાપ્ત કરવા માટે અનુકૂળ રહેશે.

નવી સફાઈ અલ્ગોરિધમ (નવી)

• સંસ્કરણ: v1.1
• તારીખો: એપ્રિલ
• મુદ્દો

પ્રક્રિયામાં werf v1.1 ના વર્તમાન સંસ્કરણમાં cleanup સામગ્રી-આધારિત ટેગિંગ યોજના માટે છબીઓને સાફ કરવાની કોઈ જોગવાઈ નથી - આ છબીઓ એકઠા થશે.

ઉપરાંત, werf નું વર્તમાન સંસ્કરણ (v1.0 અને v1.1) ટેગિંગ યોજનાઓ હેઠળ પ્રકાશિત છબીઓ માટે વિવિધ સફાઈ નીતિઓનો ઉપયોગ કરે છે: Git બ્રાન્ચ, Git ટેગ અથવા Git કમિટ.

Git માં કમિટ્સના ઈતિહાસના આધારે ઈમેજીસ સાફ કરવા માટે એક નવું અલ્ગોરિધમ, તમામ ટેગીંગ સ્કીમ્સ માટે એકીકૃત, શોધ કરવામાં આવી છે:

• દરેક ગિટ હેડ (શાખાઓ અને ટૅગ્સ) માટે N1 સૌથી તાજેતરના કમિટ સાથે સંકળાયેલ N2 કરતાં વધુ છબીઓ ન રાખો.
• દરેક ગિટ હેડ (શાખાઓ અને ટૅગ્સ) માટે N1 સૌથી તાજેતરના કમિટ સાથે સંકળાયેલ N2 સ્ટેજની છબીઓ કરતાં વધુ સ્ટોર કરશો નહીં.
• કોઈપણ કુબરનેટ્સ ક્લસ્ટર સંસાધનોમાં ઉપયોગમાં લેવાતી તમામ છબીઓને સંગ્રહિત કરો (રૂપરેખાંકન ફાઇલના તમામ ક્યૂબ સંદર્ભો અને નેમસ્પેસ સ્કેન કરવામાં આવ્યા છે; તમે વિશિષ્ટ વિકલ્પો સાથે આ વર્તનને મર્યાદિત કરી શકો છો).
• હેલ્મ રીલીઝમાં સાચવેલ રિસોર્સ કન્ફિગરેશન મેનિફેસ્ટમાં ઉપયોગમાં લેવાતી તમામ ઈમેજો સ્ટોર કરો.
• ઇમેજ ડિલીટ કરી શકાય છે જો તે ગિટમાંથી કોઈપણ HEAD સાથે સંકળાયેલી ન હોય (ઉદાહરણ તરીકે, કારણ કે સંબંધિત HEAD પોતે કાઢી નાખવામાં આવ્યું હતું) અને કુબરનેટ્સ ક્લસ્ટર અને હેલ્મ રિલીઝમાં કોઈપણ મેનિફેસ્ટમાં તેનો ઉપયોગ થતો નથી.

સમાંતર ઇમેજ બિલ્ડિંગ (↓)

• સંસ્કરણ: v1.1
• તારીખો: જાન્યુઆરી-ફેબ્રુઆરી એપ્રિલ*

વર્ફનું વર્તમાન સંસ્કરણ તેમાં વર્ણવેલ છબીઓ અને કલાકૃતિઓને એકત્રિત કરે છે werf.yaml, અનુક્રમે. છબીઓ અને કલાકૃતિઓના સ્વતંત્ર તબક્કાઓને એસેમ્બલ કરવાની પ્રક્રિયાને સમાંતર બનાવવી જરૂરી છે, તેમજ અનુકૂળ અને માહિતીપ્રદ આઉટપુટ પ્રદાન કરવું જરૂરી છે.

* નોંધ: વિતરિત એસેમ્બલીને અમલમાં મૂકવાની અગ્રતા વધારવાને કારણે સમયમર્યાદા ખસેડવામાં આવી છે, જે વધુ આડી સ્કેલિંગ ક્ષમતાઓ ઉમેરશે, તેમજ GitHub ક્રિયાઓ સાથે werf નો ઉપયોગ કરશે. સમાંતર એસેમ્બલી એ આગલું ઑપ્ટિમાઇઝેશન પગલું છે, જે એક પ્રોજેક્ટને એસેમ્બલ કરતી વખતે ઊભી માપનીયતા પ્રદાન કરે છે.

હેલ્મ 3 (↓) માં સંક્રમણ

• સંસ્કરણ: v1.2
• તારીખો: ફેબ્રુઆરી-માર્ચ મે*

નવા કોડબેઝમાં સ્થળાંતરનો સમાવેશ થાય છે સુકાન 3 અને હાલના સ્થાપનોને સ્થાનાંતરિત કરવાની સાબિત, અનુકૂળ રીત.

* નોંધ: હેલ્મ 3 પર સ્વિચ કરવાથી વેર્ફમાં નોંધપાત્ર લક્ષણો ઉમેરાશે નહીં, કારણ કે હેલ્મ 3 (3-વે-મર્જ અને કોઈ ટીલર નહીં) ની તમામ મુખ્ય વિશેષતાઓ પહેલેથી જ વર્ફમાં લાગુ કરવામાં આવી છે. તદુપરાંત, વર્ફ પાસે છે વધારાની વિશેષતાઓ દર્શાવેલ ઉપરાંત. જો કે, આ સંક્રમણ અમારી યોજનાઓમાં રહે છે અને તેનો અમલ કરવામાં આવશે.

કુબરનેટ્સ કન્ફિગરેશન (↓) નું વર્ણન કરવા માટે Jsonnet

• સંસ્કરણ: v1.2
• તારીખો: જાન્યુઆરી-ફેબ્રુઆરી એપ્રિલ-મે

Werf Jsonnet ફોર્મેટમાં Kubernetes માટે રૂપરેખાંકન વર્ણનોને સમર્થન આપશે. તે જ સમયે, werf હેલ્મ સાથે સુસંગત રહેશે અને વર્ણન ફોર્મેટની પસંદગી હશે.

કારણ એ છે કે ગો ટેમ્પ્લેટ્સ, ઘણા લોકોના મતે, ઉચ્ચ પ્રવેશ અવરોધ ધરાવે છે, અને આ નમૂનાઓના કોડની સમજશક્તિ પણ પીડાય છે.

અન્ય Kubernetes રૂપરેખાંકન વર્ણન સિસ્ટમો (ઉદાહરણ તરીકે, Kustomize) રજૂ કરવાની શક્યતા પણ ધ્યાનમાં લેવામાં આવી રહી છે.

કુબરનેટ્સની અંદર કામ કરવું (↓)

• સંસ્કરણ: v1.2
• તારીખો: એપ્રિલ-મે મે-જૂન

ધ્યેય: સુનિશ્ચિત કરો કે છબીઓ બનાવવામાં આવી છે અને કુબરનેટ્સમાં દોડવીરોનો ઉપયોગ કરીને એપ્લિકેશન વિતરિત કરવામાં આવી છે. તે. નવી છબીઓ કુબરનેટસ પોડ્સમાંથી સીધી બનાવી, પ્રકાશિત, સાફ અને ગોઠવી શકાય છે.

આ ક્ષમતાને અમલમાં મૂકવા માટે, તમારે પ્રથમ વિતરિત છબીઓ બનાવવા માટે સક્ષમ બનવાની જરૂર છે (ઉપર બિંદુ જુઓ).

તેને ડોકર સર્વર વિના બિલ્ડરના ઓપરેટિંગ મોડ માટે સપોર્ટની પણ જરૂર છે (એટલે ​​​​કે કનિકો જેવી બિલ્ડ અથવા યુઝરસ્પેસમાં બિલ્ડ).

Werf માત્ર Dockerfile સાથે જ નહીં, પરંતુ તેના સ્ટેપલ બિલ્ડર સાથે પણ ઇન્ક્રીમેન્ટલ રિબિલ્ડ્સ અને એન્સિબલ સાથે કુબરનેટ્સ પર બિલ્ડિંગને સમર્થન આપશે.

ખુલ્લા વિકાસ તરફ એક પગલું

અમે અમારા સમુદાયને પ્રેમ કરીએ છીએ (GitHub, Telegram) અને અમે ઇચ્છીએ છીએ કે વધુને વધુ લોકો વર્ફને બહેતર બનાવવામાં મદદ કરે, અમે જે દિશામાં આગળ વધી રહ્યા છીએ તે સમજવામાં અને વિકાસમાં ભાગ લે.

તદ્દન તાજેતરમાં તે પર સ્વિચ કરવાનો નિર્ણય લેવામાં આવ્યો હતો GitHub પ્રોજેક્ટ બોર્ડ અમારી ટીમની કાર્ય પ્રક્રિયાને જાહેર કરવા માટે. હવે તમે નીચેના ક્ષેત્રોમાં તાત્કાલિક યોજનાઓ તેમજ વર્તમાન કાર્ય જોઈ શકો છો:

• દસ્તાવેજીકરણ અને સાઇટ;
• પરીક્ષણ;
• બગ્સ અને ખરાબ UX;
• 1.1.

મુદ્દાઓ સાથે ઘણું કામ કરવામાં આવ્યું છે:

• અપ્રસ્તુત દૂર કર્યા.
• અસ્તિત્વમાં છે તે એક જ ફોર્મેટમાં લાવવામાં આવે છે, જેમાં પૂરતી સંખ્યામાં વિગતો અને વિગતો હોય છે.
• વિચારો અને સૂચનો સાથે નવા મુદ્દા ઉમેરવામાં આવ્યા છે.

સંસ્કરણ v1.1 કેવી રીતે સક્ષમ કરવું

સંસ્કરણ હાલમાં ઉપલબ્ધ છે ચેનલ 1.1 ea (ચેનલોમાં સ્થિર и ખડક-નક્કર જો કે, સ્થિરીકરણ થાય તેમ પ્રકાશનો દેખાશે ea પોતે પહેલેથી જ ઉપયોગ માટે પૂરતી સ્થિર છે, કારણ કે ચેનલોમાંથી પસાર થઈ આલ્ફા и બીટા). સક્રિય multiwerf દ્વારા નીચેની રીતે:

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

નિષ્કર્ષ

સ્ટેપલ અને ડોકરફાઈલ બિલ્ડરો માટે નવા સ્ટેજનું સ્ટોરેજ આર્કિટેક્ચર અને બિલ્ડર ઑપ્ટિમાઇઝેશન વેર્ફમાં વિતરિત અને સમાંતર બિલ્ડ્સને અમલમાં મૂકવાની શક્યતા ખોલે છે. આ સુવિધાઓ ટૂંક સમયમાં સમાન v1.1 રિલીઝમાં દેખાશે અને ઓટો-અપડેટ મિકેનિઝમ (વપરાશકર્તાઓ માટે) દ્વારા આપમેળે ઉપલબ્ધ થશે multiwerf).

આ પ્રકાશનમાં, ઇમેજ સામગ્રી પર આધારિત ટેગિંગ વ્યૂહરચના ઉમેરવામાં આવી છે - સામગ્રી-આધારિત ટેગિંગ, જે ડિફોલ્ટ વ્યૂહરચના બની ગઈ છે. મુખ્ય આદેશ લોગ પણ પુનઃકાર્ય કરવામાં આવ્યો છે: werf build, werf publish, werf deploy, werf dismiss, werf cleanup.

આગલું નોંધપાત્ર પગલું વિતરિત એસેમ્બલી ઉમેરવાનું છે. વિતરિત બિલ્ડ્સ v1.0 થી સમાંતર બિલ્ડ્સ કરતાં ઉચ્ચ અગ્રતા બની ગયા છે કારણ કે તેઓ વર્ફમાં વધુ મૂલ્ય ઉમેરે છે: બિલ્ડરોનું વર્ટિકલ સ્કેલિંગ અને વિવિધ CI/CD સિસ્ટમ્સમાં ક્ષણિક બિલ્ડરો માટે સમર્થન, તેમજ GitHub ક્રિયાઓ માટે સત્તાવાર સમર્થન કરવાની ક્ષમતા. . તેથી, સમાંતર એસેમ્બલી માટે અમલીકરણની સમયમર્યાદા ખસેડવામાં આવી હતી. જો કે, અમે બંને શક્યતાઓને વહેલી તકે લાગુ કરવા માટે કામ કરી રહ્યા છીએ.

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

PS

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

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

સોર્સ: www.habr.com