કન્ટેનરની છબીઓની "સ્માર્ટ" સફાઈની સમસ્યા અને વેર્ફમાં તેના ઉકેલ

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

પરિચય

કન્ટેનર રજિસ્ટ્રીમાં છબીઓની સંખ્યા ઝડપથી વધી શકે છે, વધુ સ્ટોરેજ સ્પેસ લે છે અને આમ તેની કિંમતમાં નોંધપાત્ર વધારો થાય છે. રજિસ્ટ્રીમાં કબજે કરેલી જગ્યાના સ્વીકાર્ય વૃદ્ધિને નિયંત્રિત કરવા, મર્યાદિત કરવા અથવા જાળવવા માટે, તે સ્વીકારવામાં આવે છે:

1. છબીઓ માટે નિશ્ચિત સંખ્યામાં ટૅગ્સનો ઉપયોગ કરો;
2. છબીઓને અમુક રીતે સાફ કરો.

પ્રથમ મર્યાદા કેટલીકવાર નાની ટીમો માટે સ્વીકાર્ય હોય છે. જો વિકાસકર્તા પાસે પર્યાપ્ત કાયમી ટૅગ્સ હોય (latest, main, test, boris વગેરે), રજિસ્ટ્રી કદમાં ફૂલશે નહીં અને લાંબા સમય સુધી તમારે તેને સાફ કરવા વિશે બિલકુલ વિચારવું પડશે નહીં. છેવટે, બધી અપ્રસ્તુત છબીઓ ભૂંસી નાખવામાં આવે છે, અને સફાઈ માટે કોઈ કામ બાકી નથી (બધું નિયમિત કચરો કલેક્ટર દ્વારા કરવામાં આવે છે).

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

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

પરંતુ તમે કેવી રીતે નક્કી કરશો કે કોઈ છબી સંબંધિત છે કે નહીં?

છબીની સુસંગતતા માટે માપદંડ

મોટા ભાગના કિસ્સાઓમાં, મુખ્ય માપદંડ હશે:

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

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

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

4. ચોથું - છબીઓ કે અમારી એપ્લિકેશનના સંસ્કરણોને અનુરૂપ છે, એટલે કે અંતિમ ઉત્પાદન છે: v1.0.0, 20.04.01/XNUMX/XNUMX, સિએરા, વગેરે.

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

પાત્રતા અને હાલના ઉકેલો

કન્ટેનર રજિસ્ટ્રી સાથેની લોકપ્રિય સેવાઓ, નિયમ તરીકે, તેમની પોતાની ઇમેજ ક્લિનઅપ નીતિઓ પ્રદાન કરે છે: તેમાં તમે તે શરતોને વ્યાખ્યાયિત કરી શકો છો કે જેના હેઠળ રજિસ્ટ્રીમાંથી ટેગ દૂર કરવામાં આવે છે. જો કે, આ શરતો નામો, બનાવટનો સમય અને ટૅગ્સની સંખ્યા* જેવા પરિમાણો દ્વારા મર્યાદિત છે*.

* ચોક્કસ કન્ટેનર રજિસ્ટ્રી અમલીકરણો પર આધાર રાખે છે. અમે નીચેના ઉકેલોની શક્યતાઓને ધ્યાનમાં લીધી: Azure CR, Docker Hub, ECR, GCR, GitHub પેકેજો, GitLab કન્ટેનર રજિસ્ટ્રી, હાર્બર રજિસ્ટ્રી, JFrog આર્ટિફેક્ટરી, Quay.io - સપ્ટેમ્બર'2020 સુધીમાં.

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

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

પ્રથમ બે માપદંડો સાથેની પરિસ્થિતિ સમાન છે: તેઓ બાહ્ય સિસ્ટમમાંથી ડેટા પ્રાપ્ત કર્યા વિના સંતુષ્ટ થઈ શકતા નથી - એક જ્યાં એપ્લિકેશનો જમાવવામાં આવે છે (અમારા કિસ્સામાં, કુબરનેટ્સ).

Git માં વર્કફ્લોનું ચિત્રણ

ચાલો કહીએ કે તમે Git માં આના જેવું કંઈક કામ કરી રહ્યાં છો:

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

જો સફાઈ નીતિઓ ફક્ત છબીઓને જાળવવાની મંજૂરી આપે તો શું થાય છે (કાઢી નાખવામાં આવતી નથી) આપેલ ટેગ નામો દ્વારા?

દેખીતી રીતે, આવા દૃશ્ય કોઈને ખુશ કરશે નહીં.

જો નીતિઓ છબીઓને કાઢી નાખવાની મંજૂરી ન આપે તો શું બદલાશે? આપેલ સમય અંતરાલ / છેલ્લા કમિટ્સની સંખ્યા અનુસાર?

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

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

જો કે, અમે એક સાર્વત્રિક ઉકેલ શોધી રહ્યા હતા જે વિવિધ રજિસ્ટ્રીનો ઉપયોગ કરીને વિવિધ ટીમો માટે ઇમેજ ક્લિનઅપને સ્વચાલિત કરશે...

સાર્વત્રિક છબી સફાઈ માટે અમારો માર્ગ

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

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

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

જો કે અમે ઉદાહરણ અમલીકરણ તરીકે werf નો ઉપયોગ કરી રહ્યા છીએ, અમે આશા રાખીએ છીએ કે ઉપયોગમાં લેવાતા અભિગમો સમાન મુશ્કેલીઓનો સામનો કરતી અન્ય ટીમો માટે ઉપયોગી થશે.

તેથી અમે વ્યસ્ત થઈ ગયા બાહ્ય ઈમેજીસ સાફ કરવા માટેની મિકેનિઝમનો અમલ - તે ક્ષમતાઓને બદલે જે કન્ટેનર માટેની રજિસ્ટ્રીમાં પહેલેથી જ બિલ્ટ છે. પ્રથમ પગલું ડોકર રજિસ્ટ્રી API નો ઉપયોગ ટૅગ્સની સંખ્યા અને તેમની રચનાના સમય (ઉપર ઉલ્લેખિત) માટે સમાન આદિમ નીતિઓ બનાવવાનું હતું. તેમને ઉમેર્યા તૈનાત ઈન્ફ્રાસ્ટ્રક્ચરમાં વપરાતી છબીઓના આધારે સૂચિને મંજૂરી આપો, એટલે કે કુબરનેટ્સ. બાદમાં માટે, બધા તૈનાત સંસાધનોને પુનરાવર્તિત કરવા અને મૂલ્યોની સૂચિ મેળવવા માટે Kubernetes API નો ઉપયોગ કરવા માટે તે પૂરતું હતું. image.

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

ટેગીંગ યોજનાઓ

શરૂ કરવા માટે, અમે એક અભિગમ પસંદ કર્યો જેમાં અંતિમ ઈમેજમાં સફાઈ માટે જરૂરી માહિતી સંગ્રહિત કરવી જોઈએ અને ટેગિંગ સ્કીમ્સ પર પ્રક્રિયા તૈયાર કરવી જોઈએ. છબી પ્રકાશિત કરતી વખતે, વપરાશકર્તાએ ચોક્કસ ટેગિંગ વિકલ્પ પસંદ કર્યો (git-branch, git-commit અથવા git-tag) અને અનુરૂપ મૂલ્યનો ઉપયોગ કર્યો. CI સિસ્ટમ્સમાં, આ મૂલ્યો પર્યાવરણ ચલોના આધારે આપમેળે સેટ કરવામાં આવ્યા હતા. હકિકતમાં અંતિમ છબી ચોક્કસ ગિટ આદિમ સાથે સંકળાયેલી હતી, લેબલોમાં સફાઈ માટે જરૂરી ડેટા સ્ટોર કરે છે.

આ અભિગમના પરિણામે નીતિઓના સમૂહમાં પરિણમ્યું જેણે ગિટને સત્યના એકમાત્ર સ્ત્રોત તરીકે ઉપયોગમાં લેવાની મંજૂરી આપી:

• Git માં શાખા/ટેગ કાઢી નાખતી વખતે, રજિસ્ટ્રીમાં સંકળાયેલી છબીઓ આપમેળે કાઢી નાખવામાં આવી હતી.
• ગિટ ટૅગ્સ અને કમિટ સાથે સંકળાયેલ છબીઓની સંખ્યા પસંદ કરેલ સ્કીમમાં ઉપયોગમાં લેવાતા ટૅગ્સની સંખ્યા અને સંબંધિત કમિટ બનાવવામાં આવી હતી તે સમય દ્વારા નિયંત્રિત કરી શકાય છે.

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

નવું અલ્ગોરિધમ

શા માટે? સામગ્રી-આધારિત ટેગિંગ સાથે, દરેક ટેગ Git માં બહુવિધ કમિટ્સને સંતોષી શકે છે. છબીઓ સાફ કરતી વખતે, તમે લાંબા સમય સુધી ધારી શકતા નથી માત્ર કમિટમાંથી જ્યાં નવું ટેગ રજિસ્ટ્રીમાં ઉમેરવામાં આવ્યું હતું.

નવા સફાઈ અલ્ગોરિધમ માટે, ટેગિંગ સ્કીમ્સ અને બિલ્ડથી દૂર જવાનું નક્કી કરવામાં આવ્યું હતું મેટા-ઇમેજ પ્રક્રિયા, જેમાંથી દરેક આનો સમૂહ સંગ્રહિત કરે છે:

• પ્રતિબદ્ધતા કે જેના પર પ્રકાશન કરવામાં આવ્યું હતું (તે વાંધો નથી કે શું છબી ઉમેરવામાં આવી હતી, બદલાઈ હતી અથવા કન્ટેનર રજિસ્ટ્રીમાં સમાન રહી હતી);
• અને એસેમ્બલ કરેલી છબીને અનુરૂપ અમારું આંતરિક ઓળખકર્તા.

બીજા શબ્દોમાં કહીએ તો, તે પ્રદાન કરવામાં આવ્યું હતું Git માં કમિટ સાથે પ્રકાશિત ટૅગ્સને લિંક કરવું.

અંતિમ રૂપરેખાંકન અને સામાન્ય અલ્ગોરિધમ

સફાઈને ગોઠવતી વખતે, વપરાશકર્તાઓ પાસે વર્તમાન છબીઓ પસંદ કરતી નીતિઓની ઍક્સેસ હોય છે. આવી દરેક નીતિ વ્યાખ્યાયિત કરવામાં આવી છે:

• ઘણા સંદર્ભો, એટલે કે. ગિટ ટૅગ્સ અથવા ગિટ શાખાઓ જેનો ઉપયોગ સ્કેનિંગ દરમિયાન થાય છે;
• અને સેટમાંથી દરેક સંદર્ભ માટે શોધેલી છબીઓની મર્યાદા.

સમજાવવા માટે, ડિફૉલ્ટ નીતિ રૂપરેખાંકન આના જેવું દેખાવાનું શરૂ થયું:

cleanup:
  keepPolicies:
  - references:
      tag: /.*/
      limit:
        last: 10
  - references:
      branch: /.*/
      limit:
        last: 10
        in: 168h
        operator: And
    imagesPerReference:
      last: 2
      in: 168h
      operator: And
  - references:  
      branch: /^(main|staging|production)$/
    imagesPerReference:
      last: 10

આ ગોઠવણીમાં ત્રણ નીતિઓ છે જે નીચેના નિયમોનું પાલન કરે છે:

1. છેલ્લા 10 ગિટ ટૅગ્સ (ટેગ બનાવવાની તારીખ દ્વારા) માટે છબી સાચવો.
2. છેલ્લા અઠવાડિયે પ્રસિદ્ધ થયેલી 2 થી વધુ છબીઓને છેલ્લા અઠવાડિયામાં પ્રવૃત્તિ સાથે 10 થી વધુ થ્રેડો માટે સાચવો નહીં.
3. શાખાઓ માટે 10 છબીઓ સાચવો main, staging и production.

અંતિમ અલ્ગોરિધમ નીચેના પગલાઓ પર ઉકળે છે:

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

અમારા દૃષ્ટાંત પર પાછા ફરવું, આ werf સાથે થાય છે:

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

નિષ્કર્ષ

• વહેલા અથવા પછીના સમયમાં, મોટાભાગની ટીમો રજિસ્ટ્રી ઓવરફ્લોની સમસ્યાનો સામનો કરે છે.
• ઉકેલો શોધતી વખતે, છબીની સુસંગતતા માટે માપદંડ નક્કી કરવા માટે સૌ પ્રથમ જરૂરી છે.
• લોકપ્રિય કન્ટેનર રજિસ્ટ્રી સેવાઓ દ્વારા ઓફર કરવામાં આવતા સાધનો તમને ખૂબ જ સરળ સફાઈનું આયોજન કરવાની મંજૂરી આપે છે જે "બહારની દુનિયા" ને ધ્યાનમાં લેતું નથી: કુબરનેટ્સમાં વપરાતી છબીઓ અને ટીમના વર્કફ્લોની વિશિષ્ટતાઓ.
• લવચીક અને કાર્યક્ષમ અલ્ગોરિધમમાં CI/CD પ્રક્રિયાઓની સમજ હોવી આવશ્યક છે અને માત્ર ડોકર ઇમેજ ડેટા સાથે જ નહીં.

PS

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

• «વર્ફ બિલ્ડરમાં સામગ્રી-આધારિત ટેગિંગ: તે શા માટે અને કેવી રીતે કાર્ય કરે છે?»;
• «3-વે મર્જ ટુ વર્ફ: હેલ્મ સાથે "સ્ટીરોઇડ્સ પર" કુબરનેટ્સ પર જમાવટ»;
• «વર્ફમાં મોનોરેપો અને મલ્ટિરેપો માટે સપોર્ટ અને ડોકર રજિસ્ટ્રીને તેની સાથે શું કરવું છે»;
• «werf 1.1 રિલીઝ: બિલ્ડર માટે આજે સુધારાઓ અને ભવિષ્ય માટેની યોજનાઓ».

સોર્સ: www.habr.com