કુબરનેટ્સ વિશ્વનો કબજો લેશે. ક્યારે અને કેવી રીતે?

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

મૂળ ઇન્ટરવ્યુ DevOps Deflop પર પોડકાસ્ટ તરીકે સાંભળો - DevOps વિશે રશિયન ભાષાનું પોડકાસ્ટ, અને નીચે ટેક્સ્ટ વર્ઝન છે.

અહીં અને નીચે તે પ્રશ્નો પૂછે છે વિટાલી ખબરોવ એક્સપ્રેસ 42 થી એન્જિનિયર.

"ફ્લાન્ટ" વિશે

- હેલો દિમા. તમે તકનીકી નિર્દેશક છો "ચપટી" અને તેના સ્થાપક પણ. કૃપા કરીને અમને જણાવો કે કંપની શું કરે છે અને તમે તેમાં શું છો?

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




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

કુબરનેટ્સ વિશે

- તાજેતરમાં હું ફ્લેંટ અને તરફથી ઘણા બધા અહેવાલો જોઉં છું લેખો કુબરનેટ્સ વિશે. તમે તેની પાસે કેવી રીતે આવ્યા?

દિમિત્રી: મેં આ વિશે ઘણી વાર વાત કરી છે, પરંતુ મને તેનું પુનરાવર્તન કરવામાં વાંધો નથી. મને લાગે છે કે આ વિષયનું પુનરાવર્તન કરવું યોગ્ય છે કારણ કે કારણ અને અસર વચ્ચે મૂંઝવણ છે.

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

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

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

અમારી પાસે એવી કોઈ ક્ષણ નહોતી કે જ્યાં અમે કુબરનેટ્સનો ઉપયોગ કરવા વિશે વિચાર્યું હોય કે નહીં. તે દેખાય તે પહેલાં અમે તેની રાહ જોઈ રહ્યા હતા, અને આપણે જાતે એનાલોગ બનાવવાનો પ્રયાસ કર્યો.

કુબરનેટ્સ વિશે

- શું તમે કુબરનેટ્સના વિકાસમાં સીધા જ સામેલ છો?

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

— તે જ સમયે, શું તમે કુબરનેટ્સની આસપાસ તમારા ઘણા સાધનો વિકસાવો છો?

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

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

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

રસ્તો હંમેશા આવો હોય છે: અમે ખૂબ જ કાળજીપૂર્વક શોધીએ છીએ અને, જો અમને રોટલીમાંથી ટ્રોલીબસ કેવી રીતે બનાવવી તે અંગે કોઈ ઉકેલ ન મળે, તો અમે અમારી પોતાની રોટલી અને અમારી પોતાની ટ્રોલીબસ બનાવીએ છીએ.

ફ્લાન્ટા સાધનો

— હું જાણું છું કે ફ્લાન્ટ પાસે હવે એડન ઓપરેટર્સ, શેલ ઓપરેટર્સ અને ડીએપી/વેર્ફ ટૂલ્સ છે. જેમ હું સમજું છું તેમ, આ એક જ સાધન છે વિવિધ અવતારોમાં. હું એ પણ સમજું છું કે Flaunt ની અંદર ઘણા બધા જુદા જુદા સાધનો છે. આ સાચું છે?

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

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

ઇકોસિસ્ટમ ડેવલપમેન્ટ

"મને લાગે છે કે આ સાધન અને તેના ઉપયોગની પદ્ધતિઓના વિકાસમાં આ ખૂબ જ મોટું યોગદાન છે." શું તમે અંદાજો લગાવી શકો છો કે ઇકોસિસ્ટમના વિકાસમાં બીજું કોણ સમાન યોગદાન આપશે?

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

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

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

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

આ અમારી dapp/werf સાથેની મોટી વ્યૂહરચનાનો એક ભાગ છે. મને યાદ નથી કે અમે તેને ક્યારે બનાવવાનું શરૂ કર્યું, તે 3 વર્ષ પહેલાં જેવું લાગે છે. શરૂઆતમાં, તે સામાન્ય રીતે શેલ પર હતું. તે ખ્યાલનો સુપર પ્રૂફ હતો, અમે અમારી કેટલીક ખાસ સમસ્યાઓ હલ કરી - તે કામ કર્યું! પરંતુ શેલ સાથે સમસ્યાઓ છે, તેને વધુ વિસ્તૃત કરવું અશક્ય છે, શેલ પર પ્રોગ્રામિંગ એ બીજું કાર્ય છે. અમને રૂબીમાં લખવાની આદત હતી, તે મુજબ, અમે રૂબીમાં કંઈક રીમેક કર્યું, વિકસિત કર્યું, વિકસિત કર્યું, વિકસિત કર્યું અને એ હકીકતમાં દોડ્યા કે સમુદાય, ભીડ જે કહેતી નથી કે “અમને તે જોઈએ છે કે આપણે તે નથી જોઈતા, ” રૂબી પર નાક ઉપર કરે છે, તે કેટલું રમુજી છે? અમને સમજાયું કે ચેકલિસ્ટ પરના પ્રથમ મુદ્દાને પહોંચી વળવા માટે અમારે ગોમાં આ બધી સામગ્રી લખવી જોઈએ: DevOps ટૂલ સ્ટેટિક બાઈનરી હોવું જોઈએ. ગો બનવું કે નહીં એ એટલું મહત્વનું નથી, પરંતુ ગોમાં લખેલી સ્ટેટિક બાઈનરી વધુ સારી છે.

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

Dapp શા માટે બનાવવામાં આવ્યું હતું?

— શું તમે અમને સંક્ષિપ્તમાં કહી શકો છો કે ડીએપી શા માટે બનાવવામાં આવી હતી, તે કઈ સમસ્યાઓ હલ કરે છે?

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

બીજું કારણ જમાવટ છે. હા, હેલ્મ છે, પરંતુ તે માત્ર કેટલીક સમસ્યાઓનું નિરાકરણ લાવે છે. રમુજી રીતે, તે લખ્યું છે કે "સુકાન કુબરનેટ્સ માટે પેકેજ મેનેજર છે." બરાબર શું “ધ”. "પેકેજ મેનેજર" શબ્દો પણ છે - પેકેજ મેનેજર પાસેથી સામાન્ય અપેક્ષા શું છે? અમે કહીએ છીએ: "પેકેજ મેનેજર - પેકેજ ઇન્સ્ટોલ કરો!" અને અમે અપેક્ષા રાખીએ છીએ કે તે અમને કહે: "પેકેજ વિતરિત કરવામાં આવ્યું છે."

તે રસપ્રદ છે કે અમે કહીએ છીએ: "હેલ્મ, પેકેજ ઇન્સ્ટોલ કરો," અને જ્યારે તે જવાબ આપે છે કે તેણે તેને ઇન્સ્ટોલ કર્યું છે, ત્યારે તે તારણ આપે છે કે તેણે હમણાં જ ઇન્સ્ટોલેશન શરૂ કર્યું છે - તેણે કુબરનેટ્સને સૂચવ્યું: "આ વસ્તુ લોંચ કરો!", અને તે શરૂ થયું કે નહીં. , ભલે તે કામ કરે કે ન કરે , હેલ્મ આ મુદ્દાને બિલકુલ હલ કરતું નથી.

તે તારણ આપે છે કે હેલ્મ માત્ર એક ટેક્સ્ટ પ્રીપ્રોસેસર છે જે કુબરનેટ્સમાં ડેટા લોડ કરે છે.

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

યોજનાઓ

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

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

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

આ આખી વાર્તાને સામ્યતા સાથે જોવાની બીજી રીત છે.

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

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

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

શું કુબરનેટ્સ જાળવવું મુશ્કેલ છે?

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

દિમિત્રી: આ એક ખૂબ જ મુશ્કેલ પ્રશ્ન છે અને તેનો જવાબ આપવા માટે, અમારે એ સમજવાની જરૂર છે કે સમર્થન શું છે અને અમને કુબરનેટ્સ પાસેથી શું જોઈએ છે. કદાચ તમે જાહેર કરી શકો છો?

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

દિમિત્રી: એવું છે.

— કુબરનેટ્સને શરૂઆતથી લેવું અને ઇન્સ્ટોલ કરવું કેટલું મુશ્કેલ છે જેથી તે ઉત્પાદન તૈયાર હોય?

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

કુબરનેટ્સ ઇન્સ્ટોલ કરવું અને તેને કામ પર લાવવાનું સરળ છે: ચિક! — ઇન્સ્ટોલ કરેલ છે, ત્યાં ઘણી બધી ઇન્સ્ટોલેશન પદ્ધતિઓ છે. પરંતુ જ્યારે સમસ્યાઓ ઊભી થાય ત્યારે શું થાય છે?

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

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

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

Linux કર્નલમાં ઐતિહાસિક રીતે ip રુટ, ઓવરફિલ્ટર, બ્રિજ અને ઘણાં વિવિધ જૂના ઘટકો છે જે 15, 20, 30 વર્ષ જૂના છે. સામાન્ય રીતે, તેઓ કામ કરે છે, બધું સરસ છે, પરંતુ હવે તેઓએ કન્ટેનરનો ઢગલો કરી દીધો છે, અને તે એકબીજાની ટોચ પર 15 ઇંટોના ટાવર જેવું લાગે છે, અને તમે તેના પર એક પગ પર ઊભા છો - એક વિચિત્ર લાગણી. આ સિસ્ટમ ઐતિહાસિક રીતે ઘણી ઘોંઘાટ સાથે વિકસિત થઈ છે, જેમ કે શરીરમાં પરિશિષ્ટ. કેટલીક પરિસ્થિતિઓમાં પ્રદર્શન સમસ્યાઓ છે, ઉદાહરણ તરીકે.

ત્યાં એક અદ્ભુત BPF અને કર્નલ માટે હુક્સ લખવાની ક્ષમતા છે - લોકોએ કર્નલ માટે તેમના પોતાના હુક્સ લખ્યા. પેકેજ લિનક્સ કર્નલમાં આવે છે, તેઓ તેને ઇનપુટ પર જ બહાર કાઢે છે, પુલ વિના, TCP વિના, IP સ્ટેક વિના તેની જાતે પ્રક્રિયા કરે છે - ટૂંકમાં, Linux કર્નલમાં લખેલી દરેક વસ્તુને બાયપાસ કરીને, અને પછી થૂંકવું. તેને કન્ટેનરમાં બહાર કાઢો.

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

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

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

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

જ્યારે આપણે કહીએ છીએ કે કુબરનેટ્સને જાળવી રાખવું મુશ્કેલ છે - ના, તે ખૂબ જ સરળ છે, અને હા, તે અતિ મુશ્કેલ છે. કુબરનેટ્સ તેના પોતાના પર મહાન કામ કરે છે, પરંતુ એક અબજ ઘોંઘાટ સાથે.

"હું નસીબદાર રહીશ" અભિગમ વિશે

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

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

મારી પાસે ઉબુન્ટુ 16.04 છે. તમે કહી શકો છો કે આ એક જૂનું સંસ્કરણ છે, પરંતુ અમે હજી પણ તેના પર છીએ કારણ કે તે LTS છે. ત્યાં સિસ્ટમડ છે, જેનો ઘોંઘાટ એ છે કે તે C-જૂથોને સાફ કરતું નથી. કુબરનેટ્સ પોડ્સ લોન્ચ કરે છે, સી-ગ્રુપ બનાવે છે, પછી પોડ્સ કાઢી નાખે છે, અને કોઈક રીતે તે બહાર આવ્યું છે - મને વિગતો યાદ નથી, માફ કરશો - તે સિસ્ટમ્ડ સ્લાઇસેસ બાકી છે. આ હકીકત તરફ દોરી જાય છે કે સમય જતાં, કોઈપણ કાર મજબૂત રીતે ધીમું થવાનું શરૂ કરે છે. આ હાઇલોડ વિશેનો પ્રશ્ન પણ નથી. જો કાયમી પોડ્સ લોન્ચ કરવામાં આવે, ઉદાહરણ તરીકે, જો ત્યાં કોઈ ક્રોન જોબ હોય જે સતત પોડ્સ જનરેટ કરે છે, તો ઉબુન્ટુ 16.04 સાથેનું મશીન એક અઠવાડિયા પછી ધીમું થવાનું શરૂ કરશે. સી-ગ્રુપનો સમૂહ બનાવવામાં આવ્યો હોવાને કારણે સતત ઊંચી લોડ એવરેજ રહેશે. આ તે સમસ્યા છે જે કોઈપણ વ્યક્તિ જે ફક્ત ઉબુન્ટુ 16 અને કુબરનેટ્સને ટોચ પર ઇન્સ્ટોલ કરે છે તેનો સામનો કરવો પડશે.

ચાલો કહીએ કે તે કોઈક રીતે systemd અથવા બીજું કંઈક અપડેટ કરે છે, પરંતુ Linux કર્નલમાં 4.16 સુધી તે વધુ રમુજી છે - જ્યારે તમે C-જૂથો કાઢી નાખો છો, ત્યારે તે કર્નલમાં લીક થાય છે અને ખરેખર કાઢી નાખવામાં આવતા નથી. તેથી, આ મશીન પર કામ કર્યાના એક મહિના પછી, હર્થ માટે મેમરીના આંકડા જોવાનું અશક્ય બનશે. અમે એક ફાઇલ કાઢીએ છીએ, તેને પ્રોગ્રામમાં રોલ કરીએ છીએ, અને એક ફાઇલ 15 સેકન્ડ માટે રોલ કરે છે, કારણ કે કર્નલ પોતાની અંદર એક મિલિયન સી-ગ્રુપની ગણતરી કરવામાં ઘણો સમય લે છે, જે કાઢી નાખવામાં આવે તેવું લાગે છે, પરંતુ ના - તે લીક થઈ રહ્યા છે. .

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

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

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

IT માં, મને લાગે છે કે, "હું નસીબદાર બનીશ" ઘણા બધા અભિગમો છે. ઘણા લોકો સૉફ્ટવેર ઇન્સ્ટોલ કરે છે અને સૉફ્ટવેર લાઇબ્રેરીઓનો ઉપયોગ કરે છે કે તેઓ નસીબદાર હશે. સામાન્ય રીતે, ઘણા લોકો નસીબદાર છે. તે કદાચ શા માટે કામ કરે છે.

— મારા નિરાશાવાદી મૂલ્યાંકનથી, તે આના જેવું લાગે છે: જ્યારે જોખમો વધુ હોય, અને એપ્લિકેશને કામ કરવું જ જોઈએ, ત્યારે ફ્લોન્ટ તરફથી સપોર્ટની જરૂર છે, કદાચ Red Hat તરફથી, અથવા તમારે તમારી પોતાની આંતરિક ટીમની જરૂર છે જે ખાસ કરીને કુબરનેટ્સને સમર્પિત છે, જે તૈયાર છે. તેને ખેંચવા માટે.

દિમિત્રી: ઉદ્દેશ્યથી, આ આવું છે. તમારી જાતે એક નાની ટીમ માટે કુબરનેટ્સ વાર્તામાં પ્રવેશવા માટે ઘણા જોખમો શામેલ છે.

શું આપણને કન્ટેનરની જરૂર છે?

- શું તમે અમને કહી શકો છો કે રશિયામાં કુબરનેટ્સ કેટલો વ્યાપક છે?

દિમિત્રી: મારી પાસે આ ડેટા નથી, અને મને ખાતરી નથી કે તે અન્ય કોઈ પાસે છે. અમે કહીએ છીએ: "કુબરનેટ્સ, કુબરનેટ્સ," પરંતુ આ મુદ્દાને જોવાની બીજી રીત છે. મને એ પણ ખબર નથી કે કન્ટેનર કેટલા વ્યાપક છે, પરંતુ હું ઇન્ટરનેટ પરના અહેવાલોમાંથી એક આંકડો જાણું છું કે 70% કન્ટેનર કુબરનેટ્સ દ્વારા ગોઠવવામાં આવે છે. તે સમગ્ર વિશ્વમાં એકદમ મોટા નમૂના માટે વિશ્વસનીય સ્ત્રોત હતો.

પછી બીજો પ્રશ્ન - શું આપણને કન્ટેનરની જરૂર છે? મારી અંગત લાગણી અને ફ્લાન્ટ કંપનીની એકંદર સ્થિતિ એ છે કે કુબરનેટ્સ એ વાસ્તવિક ધોરણ છે.

કુબરનેટ્સ સિવાય બીજું કંઈ હશે નહીં.

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

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

— એટલે કે, તે કંપનીઓ કે જેણે હજી સુધી કુબરનેટ્સ પર સ્વિચ કર્યું નથી તે ચોક્કસપણે તેના પર સ્વિચ કરશે અથવા વિસ્મૃતિમાં રહેશે. હું તમને બરાબર સમજી ગયો?

દિમિત્રી: આ પણ સંપૂર્ણપણે સાચું નથી. ઉદાહરણ તરીકે, જો આપણી પાસે DNS સર્વર ચલાવવાનું કાર્ય છે, તો તે FreeBSD 4.10 પર ચલાવી શકાય છે અને તે 20 વર્ષ સુધી સંપૂર્ણ રીતે કામ કરી શકે છે. બસ કામ કરો અને બસ. કદાચ 20 વર્ષમાં કંઈક એકવાર અપડેટ કરવાની જરૂર પડશે. જો આપણે ફોર્મેટમાં સોફ્ટવેર વિશે વાત કરી રહ્યા છીએ જે અમે લોન્ચ કર્યું છે અને તે ખરેખર ઘણા વર્ષો સુધી કોઈપણ અપડેટ્સ વિના, ફેરફારો કર્યા વિના કાર્ય કરે છે, તો પછી, અલબત્ત, ત્યાં કોઈ કુબરનેટ્સ હશે નહીં. તેની ત્યાં જરૂર નથી.

CI/CD ને લગતી દરેક વસ્તુ - જ્યાં પણ સતત ડિલિવરીની જરૂર હોય, જ્યાં તમારે વર્ઝન અપડેટ કરવાની જરૂર હોય, સક્રિય ફેરફારો કરવાની જરૂર હોય, જ્યાં તમારે ફોલ્ટ ટોલરન્સ બનાવવાની જરૂર હોય ત્યાં - માત્ર કુબરનેટ્સ.

માઇક્રોસર્વિસિસ વિશે

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

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

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

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

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

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

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

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

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

એમેઝોન અને ગૂગલ વિશે

— શું એમેઝોન અથવા ગૂગલના સોલ્યુશનમાંથી હોસ્ટને આઉટસોર્સ તરીકે ગણી શકાય?

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

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

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

તેથી, જવાબ હા છે, પરંતુ, હકીકતમાં, ત્યાં ઘણા બધા પરિપક્વ હોસ્ટેડ ઉકેલો નથી.

કોને કુબરનેટ્સની જરૂર છે?

- અને હજુ સુધી, કોને કુબરનેટ્સની જરૂર છે? કોણે પહેલાથી જ કુબરનેટ્સ પર સ્વિચ કરવું જોઈએ, જે વિશિષ્ટ ફ્લોન્ટ ક્લાયન્ટ છે જે ખાસ કરીને કુબરનેટ્સ માટે આવે છે?

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

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

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

કોને કુબરનેટ્સની જરૂર છે તે પ્રશ્નનો જવાબ - કોઈને કુબરનેટ્સની જરૂર નથી.

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

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

અમને અથવા બીજા કોઈને કુબરનેટ્સની જરૂર છે તે શબ્દ ખોટો છે.

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

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

અંતિમ જવાબ છે: તમારે કુબરનેટ્સની જરૂર નથી. તમારે તમારી સમસ્યાઓ હલ કરવાની જરૂર છે.

તમે જે પ્રાપ્ત કરી શકો છો તે છે:

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

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

સર્વરલેસ વિશે

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

દિમિત્રી: અહીં આપણે ફરી એક ટીકા કરવાની જરૂર છે કે હું કોઈ દ્રષ્ટા નથી જે આગળ જોઈને કહે છે - તે આવું હશે! જો કે મેં ફક્ત તે જ કર્યું. હું મારા પગ તરફ જોઉં છું અને ત્યાં સમસ્યાઓનો સમૂહ જોઉં છું, ઉદાહરણ તરીકે, કમ્પ્યુટરમાં ટ્રાંઝિસ્ટર કેવી રીતે કાર્ય કરે છે. તે રમુજી છે, અધિકાર? અમે CPU માં કેટલીક ભૂલોનો સામનો કરી રહ્યા છીએ.

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

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

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

કુબરનેટ્સ કેવી રીતે વિકસિત થશે

— જેમ જેમ આપણે આ સંભવિત અદ્ભુત દૂરના ભવિષ્ય તરફ આગળ વધીએ છીએ, તમે કેવી રીતે વિચારો છો કે કુબરનેટ્સ અને તેની આસપાસની ઇકોસિસ્ટમનો વિકાસ થશે?

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

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

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

એક યા બીજા સ્વરૂપે ઓપરેટરના વિકાસની આ વાર્તા આગામી બે-ત્રણ વર્ષોમાં મહત્વની બની રહેશે.

મને લાગે છે કે ઉપયોગમાં સરળતા મોટા પ્રમાણમાં વધવી જોઈએ - બૉક્સ વધુને વધુ કાળો બનશે, વધુ અને વધુ વિશ્વસનીય, વધુ અને વધુ સરળ knobs સાથે.

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

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

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

મને લાગે છે કે કુબરનેટ્સ અને ઈન્ફ્રાસ્ટ્રક્ચર સાથે ઉપયોગમાં સરળતામાં પણ ઘણો વધારો થશે. આ, મારા મતે, સ્પષ્ટ છે - તે સપાટી પર આવેલું છે.

ઇજનેરોનું શું કરવું?

— તો પછી કુબરનેટ્સને ટેકો આપતા એન્જિનિયરો અને સિસ્ટમ એડમિનિસ્ટ્રેટર્સનું શું થશે?

દિમિત્રી: 1C ના આગમન પછી એકાઉન્ટન્ટનું શું થયું? એ જ વિશે. આ પહેલા, તેઓ કાગળ પર ગણતરી કરે છે - હવે પ્રોગ્રામમાં. શ્રમ ઉત્પાદકતા તીવ્રતાના ઓર્ડર દ્વારા વધી છે, પરંતુ શ્રમ પોતે અદૃશ્ય થઈ નથી. જો અગાઉ લાઇટ બલ્બમાં સ્ક્રૂ કરવા માટે 10 ઇજનેર લેતા હતા, તો હવે એક પૂરતું હશે.

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

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

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

DevOps અથવા સિસ્ટમ એન્જિનિયરિંગ દૂર થશે નહીં - ઉચ્ચ-સ્તરનું કાર્ય અને કાર્યક્ષમતા વધશે.

- મેં એક રસપ્રદ વિચાર પણ સાંભળ્યો કે કાર્ય ખરેખર વધશે.

દિમિત્રી: અલબત્ત, સો ટકા! કારણ કે આપણે લખીએ છીએ તે સોફ્ટવેરની માત્રા સતત વધી રહી છે. અમે સોફ્ટવેર વડે હલ કરીએ છીએ તે સમસ્યાઓની સંખ્યા સતત વધી રહી છે. કામનું પ્રમાણ વધી રહ્યું છે. હવે DevOps માર્કેટ ભયંકર રીતે ગરમ થઈ ગયું છે. આ પગારની અપેક્ષાઓમાં જોઈ શકાય છે. સારી રીતે, વિગતોમાં ગયા વિના, એવા જુનિયર્સ હોવા જોઈએ જેમને X જોઈએ છે, મિડલ જેઓ 1,5X ઈચ્છે છે અને વરિષ્ઠ જેઓ 2X ઈચ્છે છે. અને હવે, જો તમે Moscow DevOps સેલરી માર્કેટ પર નજર નાખો, તો એક જુનિયર X થી 3X સુધી અને સિનિયર X થી 3X સુધી માંગે છે.

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

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

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

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

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

શુભેચ્છાઓ અને જાહેરાતની એક મિનિટ

- શું તમારી કોઈ ઈચ્છા છે?

દિમિત્રી: હા, મારી ઘણી ઈચ્છાઓ છે.

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

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

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

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

- ખુબ ખુબ આભાર!

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

ઇન્ટરવ્યુમાં, દિમિત્રીએ વર્ફના મુદ્દા પર સ્પર્શ કર્યો. હવે આ એક સાર્વત્રિક સ્વિસ છરી છે જે લગભગ તમામ સમસ્યાઓ હલ કરે છે. પરંતુ તે હંમેશા એવું નહોતું. ચાલુ DevOpsConf  તહેવાર પર RIT++ દિમિત્રી સ્ટોલ્યારોવ તમને આ સાધન વિશે વિગતવાર જણાવશે. અહેવાલમાં "werf એ કુબરનેટ્સમાં CI/CD માટે અમારું સાધન છે" ત્યાં બધું જ હશે: કુબરનેટ્સની સમસ્યાઓ અને છુપાયેલા ઘોંઘાટ, આ મુશ્કેલીઓને હલ કરવાના વિકલ્પો અને વેર્ફના વર્તમાન અમલીકરણની વિગતવાર. 27 અને 28 મેના રોજ અમારી સાથે જોડાઓ, અમે પરફેક્ટ ટૂલ્સ બનાવીશું.

સોર્સ: www.habr.com