GitOps: પુલ અને પુશ પદ્ધતિઓની સરખામણી

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

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

આ અભિગમના મુખ્ય ફાયદા નીચે મુજબ છે::

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

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

જમાવટ પદ્ધતિઓ

તાજેતરના વર્ષોમાં, કુબરનેટ્સમાં જમાવટ માટે વિવિધ પદ્ધતિઓ અને સાધનો સ્થાપિત થયા છે:

1. મૂળ કુબરનેટ્સ/કસ્ટમાઇઝ નમૂનાઓ પર આધારિત. કુબરનેટ્સ પર એપ્લિકેશનો જમાવવાનો આ સૌથી સહેલો રસ્તો છે. વિકાસકર્તા મૂળભૂત YAML ફાઇલો બનાવે છે અને તેને લાગુ કરે છે. સમાન નમૂનાઓને સતત ફરીથી લખવાથી છુટકારો મેળવવા માટે, Kustomize વિકસાવવામાં આવ્યું હતું (તે Kubernetes નમૂનાઓને મોડ્યુલમાં ફેરવે છે). નૉૅધ. અનુવાદ: Kustomize સાથે kubectl માં સંકલિત કરવામાં આવ્યું છે Kubernetes 1.14 નું પ્રકાશન.
2. સુકાન ચાર્ટ્સ. હેલ્મ ચાર્ટ તમને નમૂનાઓ, ઇનિટ કન્ટેનર, સાઇડકાર, વગેરેના સેટ બનાવવાની મંજૂરી આપે છે, જેનો ઉપયોગ નમૂના-આધારિત અભિગમ કરતાં વધુ લવચીક કસ્ટમાઇઝેશન વિકલ્પો સાથે એપ્લિકેશનને જમાવવા માટે થાય છે. આ પદ્ધતિ ટેમ્પલેટેડ YAML ફાઇલો પર આધારિત છે. હેલ્મ તેમને વિવિધ પરિમાણો સાથે ભરે છે અને પછી તેમને ટિલરને મોકલે છે, એક ક્લસ્ટર ઘટક જે તેમને ક્લસ્ટરમાં જમાવે છે અને અપડેટ્સ અને રોલબેકની મંજૂરી આપે છે. મહત્વની બાબત એ છે કે હેલ્મ આવશ્યકપણે ફક્ત ઇચ્છિત મૂલ્યોને ટેમ્પલેટ્સમાં દાખલ કરે છે અને પછી તેને તે જ રીતે લાગુ કરે છે જેમ તે પરંપરાગત અભિગમમાં કરવામાં આવે છે. (તે બધું કેવી રીતે કાર્ય કરે છે અને તમે તેનો ઉપયોગ કેવી રીતે કરી શકો તે વિશે વધુ વાંચો અમારા હેલ્મ દ્વારા લેખ - આશરે. અનુવાદ.). કાર્યોની વિશાળ શ્રેણીને આવરી લેતા તૈયાર હેલ્મ ચાર્ટની વિશાળ વિવિધતા છે.
3. વૈકલ્પિક સાધનો. ઘણા વૈકલ્પિક સાધનો છે. તેઓ બધામાં જે સામ્ય છે તે એ છે કે તેઓ કેટલીક ટેમ્પલેટ ફાઇલોને કુબરનેટ્સ-વાંચી શકાય તેવી YAML ફાઇલોમાં ફેરવે છે અને પછી તેનો ઉપયોગ કરે છે.

અમારા કાર્યમાં, અમે મહત્વપૂર્ણ સાધનો માટે સતત હેલ્મ ચાર્ટનો ઉપયોગ કરીએ છીએ (કારણ કે તેમની પાસે ઘણી બધી વસ્તુઓ પહેલેથી જ તૈયાર છે, જે જીવનને વધુ સરળ બનાવે છે) અને "શુદ્ધ" કુબરનેટસ YAML ફાઇલો અમારી પોતાની એપ્લિકેશનો ગોઠવવા માટે.

ખેંચો અને દબાણ કરો

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

એનબી! GitOps નો ઉપયોગ કરવાના તમામ લાભો બંને અભિગમો માટે સમાન રહે છે.

પુલ આધારિત અભિગમ

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

ગુણ:

1. કોઈપણ બાહ્ય ક્લાયન્ટને ક્લસ્ટરમાં ફેરફાર કરવાનો અધિકાર નથી; બધા અપડેટ્સ અંદરથી રોલઆઉટ કરવામાં આવે છે.
2. કેટલાક ટૂલ્સ તમને હેલ્મ ચાર્ટ અપડેટ્સને સિંક્રનાઇઝ કરવાની અને તેને ક્લસ્ટર સાથે લિંક કરવાની પણ મંજૂરી આપે છે.
3. ડોકર રજિસ્ટ્રીને નવા સંસ્કરણો માટે સ્કેન કરી શકાય છે. જો નવી ઈમેજ ઉપલબ્ધ હોય, તો ગિટ રીપોઝીટરી અને જમાવટને નવા વર્ઝનમાં અપડેટ કરવામાં આવે છે.
4. પુલ ટૂલ્સ વિવિધ ગિટ રિપોઝીટરીઝ અને પરવાનગીઓ સાથે વિવિધ નેમસ્પેસમાં વિતરિત કરી શકાય છે. આનો આભાર, મલ્ટિટેનન્ટ મોડેલનો ઉપયોગ કરી શકાય છે. ઉદાહરણ તરીકે, ટીમ A નેમસ્પેસ A નો ઉપયોગ કરી શકે છે, ટીમ B નેમસ્પેસ B નો ઉપયોગ કરી શકે છે અને ઇન્ફ્રાસ્ટ્રક્ચર ટીમ વૈશ્વિક જગ્યાનો ઉપયોગ કરી શકે છે.
5. એક નિયમ તરીકે, સાધનો ખૂબ ઓછા વજનવાળા છે.
6. ઓપરેટર જેવા સાધનો સાથે સંયુક્ત Bitnami સીલબંધ રહસ્યો, રહસ્યોને ગિટ રિપોઝીટરીમાં એન્ક્રિપ્ટેડ સંગ્રહિત કરી શકાય છે અને ક્લસ્ટરમાં પુનઃપ્રાપ્ત કરી શકાય છે.
7. CD પાઇપલાઇન્સ સાથે કોઈ જોડાણ નથી કારણ કે જમાવટ ક્લસ્ટરની અંદર થાય છે.

મિનિસી:

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

દબાણ આધારિત અભિગમ

પુશ અભિગમમાં, બાહ્ય સિસ્ટમ (મુખ્યત્વે CD પાઇપલાઇન્સ) ગિટ રિપોઝીટરીને પ્રતિબદ્ધ કર્યા પછી અથવા જો અગાઉની CI પાઇપલાઇન સફળ હોય તો ક્લસ્ટરમાં જમાવટ શરૂ કરે છે. આ અભિગમમાં, સિસ્ટમ પાસે ક્લસ્ટરની ઍક્સેસ છે.

Плюсы:

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

મિનિસી:

1. ક્લસ્ટર એક્સેસ ડેટા બિલ્ડ સિસ્ટમની અંદર છે.
2. પુલ પ્રક્રિયા સાથે જમાવટ કન્ટેનરને અપડેટ કરવું હજી પણ સરળ છે.
3. CD સિસ્ટમ પર ભારે અવલંબન, કારણ કે અમને જે પાઇપલાઇનની જરૂર છે તે મૂળ રૂપે ગિટલેબ રનર્સ માટે લખવામાં આવી હશે, અને પછી ટીમ Azure DevOps અથવા Jenkins પર જવાનું નક્કી કરે છે... અને મોટી સંખ્યામાં બિલ્ડ પાઇપલાઇન્સનું સ્થળાંતર કરવું પડશે.

પરિણામો: દબાણ અથવા ખેંચો?

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

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

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

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

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

અનુવાદક તરફથી પીએસ નોંધ

પુલ મૉડલનું નુકસાન એ છે કે ગિટમાં રેન્ડરેડ મેનિફેસ્ટ મૂકવું મુશ્કેલ છે, પરંતુ પુલ મૉડલમાં સીડી પાઇપલાઇન રોલઆઉટથી અલગ રહે છે અને આવશ્યકપણે કૅટેગરી પાઇપલાઇન બની જાય છે એવું કોઈ નુકસાન નથી. સતત અરજી કરો. તેથી, તમામ જમાવટમાંથી તેમની સ્થિતિ એકત્રિત કરવા અને કોઈક રીતે લોગ/સ્ટેટસની ઍક્સેસ પ્રદાન કરવા માટે વધુ પ્રયત્નોની જરૂર પડશે, પ્રાધાન્ય CD સિસ્ટમના સંદર્ભમાં.

આ અર્થમાં, પુશ મોડેલ અમને રોલઆઉટની ઓછામાં ઓછી કેટલીક ગેરંટી પૂરી પાડવાની મંજૂરી આપે છે, કારણ કે પાઇપલાઇનનું જીવનકાળ રોલઆઉટના જીવનકાળની બરાબર બનાવી શકાય છે.

અમે બંને મોડલ અજમાવ્યા અને લેખના લેખક જેવા જ નિષ્કર્ષ પર આવ્યા:

1. પુલ મોડેલ અમારા માટે મોટી સંખ્યામાં ક્લસ્ટરો પર સિસ્ટમ ઘટકોના અપડેટ્સ ગોઠવવા માટે યોગ્ય છે (જુઓ. એડઓન-ઓપરેટર વિશે લેખ).
2. GitLab CI પર આધારિત પુશ મોડલ હેલ્મ ચાર્ટનો ઉપયોગ કરીને એપ્લીકેશનો રોલઆઉટ કરવા માટે યોગ્ય છે. તે જ સમયે, સાધનનો ઉપયોગ કરીને પાઇપલાઇન્સમાં જમાવટના રોલઆઉટનું નિરીક્ષણ કરવામાં આવે છે વર્ફ. બાય ધ વે, અમારા આ પ્રોજેક્ટના સંદર્ભમાં, જ્યારે અમે KubeCon Europe'19 ખાતે અમારા સ્ટેન્ડ પર DevOps એન્જિનિયરોની અગ્રેસર સમસ્યાઓની ચર્ચા કરી ત્યારે અમે સતત “GitOps” સાંભળ્યા.

અનુવાદક તરફથી PPS

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

• «કુબરનેટ્સ ટીપ્સ અને યુક્તિઓ: ક્લસ્ટરમાં ચાલતા સંસાધનોને હેલ્મ 2 મેનેજમેન્ટમાં સ્થાનાંતરિત કરવું»;
• «કુબેડોગનો પરિચય, કુબરનેટ્સ સંસાધનોને ટ્રેક કરવા માટેની લાઇબ્રેરી»;
• «કુબરનેટ્સનું વિસ્તરણ અને પૂરક (વિહંગાવલોકન અને વિડિયો રિપોર્ટ)»;
• «GitLab CI માં કસ્ટમ વર્કફ્લો બનાવવા માટેની ટિપ્સ».

ફક્ત નોંધાયેલા વપરાશકર્તાઓ જ સર્વેમાં ભાગ લઈ શકે છે. સાઇન ઇન કરો, મહેરબાની કરીને.

શું તમે GitOps નો ઉપયોગ કરો છો?

• હા, ખેંચવાનો અભિગમ

• હા, દબાણ કરો

• હા, ખેંચો + દબાણ કરો

• હા, બીજું કંઈક

• કોઈ

30 વપરાશકર્તાઓએ મતદાન કર્યું. 10 વપરાશકર્તાઓ દૂર રહ્યા.

સોર્સ: www.habr.com