વર્ફમાં મોનોરેપો અને મલ્ટિરેપો માટે સપોર્ટ અને ડોકર રજિસ્ટ્રીને તેની સાથે શું કરવું છે

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

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

મુદ્દાઓ

ચાલો આવી પરિસ્થિતિની કલ્પના કરીએ. કંપની પાસે ઘણી ડેવલપમેન્ટ ટીમો છે જે સ્વતંત્ર પ્રોજેક્ટ્સ પર કામ કરે છે. મોટાભાગની એપ્લિકેશનો કુબરનેટ્સ પર ચાલે છે અને તેથી કન્ટેનરાઇઝ્ડ છે. કન્ટેનર, છબીઓ સ્ટોર કરવા માટે, તમારે રજિસ્ટ્રી (રજિસ્ટ્રી) ની જરૂર છે. આવી રજિસ્ટ્રી તરીકે, કંપની એક એકાઉન્ટ સાથે ડોકર હબનો ઉપયોગ કરે છે COMPANY. મોટાભાગની સોર્સ કોડ સ્ટોરેજ સિસ્ટમ્સની જેમ, ડોકર હબ નેસ્ટેડ રિપોઝીટરી હાયરાર્કીને મંજૂરી આપતું નથી, જેમ કે COMPANY/PROJECT/IMAGE. તે કિસ્સામાં… તમે દરેક પ્રોજેક્ટ માટે અલગ એકાઉન્ટ બનાવ્યા વિના આ મર્યાદા સાથે રજિસ્ટ્રીમાં નોન-મોનોલિથિક એપ્લિકેશન કેવી રીતે સ્ટોર કરી શકો છો?

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

ઉકેલો

જો અરજી મોનોલિથિક, એક છબીમાં આવે છે, પછી કોઈ પ્રશ્નો નથી અને અમે ફક્ત છબીઓને પ્રોજેક્ટના કન્ટેનર રજિસ્ટ્રીમાં સાચવીએ છીએ.

જ્યારે એપ્લિકેશનને બહુવિધ ઘટકો તરીકે રજૂ કરવામાં આવે છે, સૂક્ષ્મ સેવાઓ, પછી ચોક્કસ અભિગમ જરૂરી છે. બે ઈમેજો ધરાવતી લાક્ષણિક વેબ એપ્લિકેશનના ઉદાહરણ પર: frontend и backend - સંભવિત વિકલ્પો છે:

1. અલગ નેસ્ટેડ રિપોઝીટરીઝમાં છબીઓ સ્ટોર કરો:

   

2. દરેક વસ્તુને એક રીપોઝીટરીમાં સંગ્રહિત કરો, અને ટેગમાં ઇમેજ નામને ધ્યાનમાં લો, ઉદાહરણ તરીકે, નીચે પ્રમાણે:

   

NB: વાસ્તવમાં, અલગ-અલગ રિપોઝીટરીઝમાં બચત સાથેનો બીજો વિકલ્પ છે, PROJECT-frontend и PROJECT-backend, પરંતુ અમે સમર્થન, સંગઠન અને વપરાશકર્તાઓ વચ્ચેના અધિકારોના વિતરણની જટિલતાને કારણે તેને ધ્યાનમાં લઈશું નહીં.

werf આધાર

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

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

કારણ કે મોટાભાગના werf વિકલ્પો સેટ કરી શકાય છે પર્યાવરણીય ચલો, CI / CD સિસ્ટમ્સમાં, સ્ટોરેજ મોડ સામાન્ય રીતે સમગ્ર પ્રોજેક્ટ માટે વૈશ્વિક સ્તરે સેટ કરવા માટે સરળ છે. દાખ્લા તરીકે, ગિટલેબના કિસ્સામાં ફક્ત પ્રોજેક્ટ સેટિંગ્સમાં પર્યાવરણ ચલ ઉમેરો: સેટિંગ્સ -> CI / CD -> ચલ: WERF_IMAGES_REPO_MODE: multirepo|monorepo.

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

શેતાન વિગતોમાં છે

નવી સ્ટોરેજ પદ્ધતિ ઉમેરતી વખતે તફાવત અને મુખ્ય મુશ્કેલી એ રજિસ્ટ્રીને સાફ કરવાની પ્રક્રિયામાં છે (વેરફ દ્વારા સપોર્ટેડ શુદ્ધિકરણ સુવિધાઓ માટે, જુઓ સફાઇ પ્રક્રિયા).

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

1. ટૅગ, બ્રાન્ચ અને કમિટ જેવી ગિટ પ્રિમિટિવ્સ દ્વારા જોડાયેલી 3 વ્યૂહરચનાઓ;
2. મનસ્વી કસ્ટમ ટૅગ્સ માટે 1 વ્યૂહરચના.

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

જ્યારે એક રીપોઝીટરીમાં સાચવવામાં આવે છે (monorepo), ઇમેજ ટેગમાં, મેટા ટેગ ઉપરાંત, ઇમેજનું નામ પણ સ્ટોર કરી શકાય છે: PROJECT:frontend-META-TAG. તેમને અલગ કરવા માટે, અમે કોઈ વિશિષ્ટ વિભાજક રજૂ કર્યું નથી, પરંતુ પ્રકાશિત કરતી વખતે અંતિમ છબીના લેબલમાં જરૂરી મૂલ્ય ઉમેર્યું છે.

NB: જો તમને werf સ્ત્રોત કોડમાં વર્ણવેલ દરેક વસ્તુ જોવામાં રસ હોય, તો પછી પ્રારંભિક બિંદુ હોઈ શકે છે પીઆર 1684.

આ લેખમાં, અમે અમારા અભિગમની સમસ્યાઓ અને વાજબીતા પર વધુ ધ્યાન આપીશું નહીં: ટેગિંગ વ્યૂહરચનાઓ વિશે, લેબલ્સમાં ડેટા સંગ્રહિત કરવા અને સમગ્ર પ્રકાશન પ્રક્રિયા વિશે - આ બધું દિમિત્રી સ્ટોલ્યારોવ દ્વારા તાજેતરના અહેવાલમાં વિગતવાર વર્ણવેલ છે: “werf એ Kubernetes માં CI/CD માટે અમારું સાધન છે».

સારાંશ માટે

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

અમારી સાથે રહો અને ટૂંક સમયમાં અમે તમને અન્ય નવીનતાઓ વિશે જણાવીશું વર્ફ!

PS

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

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

સોર્સ: www.habr.com