ક્લાઉડ-નેટિવ એપ્સ બનાવવા માટે 5 કોમન સેન્સ સિદ્ધાંતો

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

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

સોફ્ટવેર ડિઝાઇન સિદ્ધાંતો

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

• ચુંબન (તેને સરળ, મૂર્ખ રાખો) - તેને જટિલ ન બનાવો;
• સૂકા (પોતાને પુનરાવર્તન કરશો નહીં) - તમારી જાતને પુનરાવર્તન કરશો નહીં;
• યાગ્નિ (તમને તેની જરૂર નથી) – એવી કોઈ વસ્તુ ન બનાવો જેની તાત્કાલિક જરૂર ન હોય;
• સોસાયટી ચિંતાઓનું વિભાજન - જવાબદારીઓ વહેંચો.

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

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

ક્લાઉડ-નેટિવ કન્ટેનર: Red Hat અભિગમ

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

સિંગલ કન્સર્ન પ્રિન્સિપલ (SCP)

આ સિદ્ધાંત ઘણી રીતે સિંગલ રિસ્પોન્સિબિલિટી પ્રિન્સિપલ જેવો જ છે. એસઆરપી), જે SOLID સેટનો ભાગ છે અને જણાવે છે કે દરેક ઑબ્જેક્ટની એક જવાબદારી હોવી જોઈએ, અને તે જવાબદારી સંપૂર્ણપણે વર્ગમાં સમાવિષ્ટ હોવી જોઈએ. એસઆરપીનો મુદ્દો એ છે કે દરેક જવાબદારી પરિવર્તન માટેનું કારણ છે, અને વર્ગમાં પરિવર્તનનું એક અને માત્ર એક જ કારણ હોવું જોઈએ.

SCP માં, અમે OOP વર્ગની તુલનામાં કન્ટેનરના ઉચ્ચ સ્તરના અમૂર્તતા અને વ્યાપક હેતુને દર્શાવવા માટે "જવાબદારી" શબ્દને બદલે "ચિંતા" શબ્દનો ઉપયોગ કરીએ છીએ. અને જો SRP નો ધ્યેય પરિવર્તન માટે માત્ર એક જ કારણ હોય, તો SCP પાછળ કન્ટેનરનો પુનઃઉપયોગ અને બદલવાની ક્ષમતાને વિસ્તૃત કરવાની ઇચ્છા છે. SRP ને અનુસરીને અને એક કન્ટેનર બનાવીને જે એક સમસ્યાનું નિરાકરણ કરે છે અને તેને કાર્યાત્મક રીતે સંપૂર્ણ રીતે કરે છે, તમે વિવિધ એપ્લિકેશન સંદર્ભોમાં તે કન્ટેનરની છબીનો પુનઃઉપયોગ કરવાની તકો વધારશો.

SCP સિદ્ધાંત જણાવે છે કે દરેક કન્ટેનરએ એક જ સમસ્યા હલ કરવી જોઈએ અને તેને સારી રીતે કરવું જોઈએ. તદુપરાંત, કન્ટેનર વિશ્વમાં SCP એ OOP વિશ્વમાં SRP કરતા વધુ સરળ છે, કારણ કે કન્ટેનર સામાન્ય રીતે એક જ પ્રક્રિયા ચલાવે છે, અને મોટાભાગે આ પ્રક્રિયા એક જ કાર્યને હલ કરે છે.

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

ઉચ્ચ અવલોકનક્ષમતા સિદ્ધાંત (HOP)

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

વ્યવહારમાં, કન્ટેનરાઇઝ્ડ એપ્લિકેશનમાં, ઓછામાં ઓછા, વિવિધ પ્રકારની આરોગ્ય તપાસ માટે API હોવી જોઈએ: જીવંતતા પરીક્ષણો અને તૈયારી પરીક્ષણો. જો એપ્લિકેશન વધુ કરવા માટે દાવો કરે છે, તો તેણે તેના રાજ્ય પર દેખરેખ રાખવાના અન્ય માધ્યમો પ્રદાન કરવા આવશ્યક છે. ઉદાહરણ તરીકે, Fluentd, Logstash અને અન્ય સમાન સાધનોનો ઉપયોગ કરીને લોગ એકત્રીકરણ માટે STDERR અને STDOUT દ્વારા મહત્વપૂર્ણ ઇવેન્ટ્સ લોગિંગ. તેમજ ટ્રેસિંગ અને મેટ્રિક્સ કલેક્શન લાઇબ્રેરીઓ સાથે એકીકરણ, જેમ કે ઓપનટ્રેસિંગ, પ્રોમિથિયસ, વગેરે.

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

જીવન ચક્ર અનુરૂપતા સિદ્ધાંત (LCP)

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

કન્ટેનરના જીવનચક્રનું સંચાલન કરવામાં મદદ કરવા માટે પ્લેટફોર્મમાં વિવિધ પ્રકારની ઇવેન્ટ્સ હોય છે. પરંતુ તેમાંથી કોને સમજવું અને કેવી રીતે પ્રતિક્રિયા આપવી તે નક્કી કરવાનું એ એપ્લિકેશન પર જ નિર્ભર છે.

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

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

ઇમેજ ઇમ્યુટેબિલિટી પ્રિન્સિપલ (IIP)

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

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

પ્રક્રિયા નિકાલક્ષમતા સિદ્ધાંત (PDP)

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

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

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

સ્વ-નિયંત્રણ સિદ્ધાંત (S-CP)

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

રૂપરેખાંકનો માટે અપવાદો બનાવવામાં આવે છે જે પર્યાવરણથી પર્યાવરણમાં બદલાય છે અને રનટાઇમ પર પ્રદાન કરવું આવશ્યક છે, ઉદાહરણ તરીકે Kubernetes ConfigMap દ્વારા.

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

રનટાઇમ કન્ફાઇનમેન્ટ પ્રિન્સિપલ (RCP)

S-CP સિદ્ધાંત વ્યાખ્યાયિત કરે છે કે કન્ટેનર કેવી રીતે બાંધવું જોઈએ અને ઇમેજ બાઈનરીમાં શું હોવું જોઈએ. પરંતુ કન્ટેનર એ ફક્ત "બ્લેક બોક્સ" નથી કે જેમાં ફક્ત એક જ લાક્ષણિકતા હોય છે - ફાઇલનું કદ. એક્ઝેક્યુશન દરમિયાન, કન્ટેનર અન્ય પરિમાણો લે છે: વપરાયેલ મેમરીનો જથ્થો, CPU સમય અને અન્ય સિસ્ટમ સંસાધનો.

અને અહીં RCP સિદ્ધાંત કામમાં આવે છે, જે મુજબ કન્ટેનરએ સિસ્ટમ સંસાધનોની તેની જરૂરિયાતોને શિરચ્છેદ કરવી જોઈએ અને તેને પ્લેટફોર્મ પર સ્થાનાંતરિત કરવી જોઈએ. દરેક કન્ટેનરની સંસાધન પ્રોફાઇલ્સ સાથે (તેને કેટલી CPU, મેમરી, નેટવર્ક અને ડિસ્ક સંસાધનોની જરૂર છે), પ્લેટફોર્મ શ્રેષ્ઠ રીતે શેડ્યૂલિંગ અને ઓટોસ્કેલિંગ કરી શકે છે, IT ક્ષમતાનું સંચાલન કરી શકે છે અને કન્ટેનર માટે SLA સ્તર જાળવી શકે છે.

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

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

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

• છબીઓનું કદ ઘટાડવાનો પ્રયાસ કરો: અસ્થાયી ફાઇલો કાઢી નાખો અને બિનજરૂરી પેકેજો ઇન્સ્ટોલ કરશો નહીં - કન્ટેનરનું કદ જેટલું નાનું છે, તે નેટવર્ક પર લક્ષ્ય હોસ્ટ પર એસેમ્બલ અને કૉપિ કરવામાં આવે છે.
• મનસ્વી યુઝર-આઈડી પર ફોકસ કરો: તમારા કન્ટેનર લોંચ કરવા માટે સુડો કમાન્ડ અથવા કોઈ વિશિષ્ટ યુઝરઆઈડીનો ઉપયોગ કરશો નહીં.
• મહત્વપૂર્ણ બંદરોને ચિહ્નિત કરો: તમે રનટાઇમ પર પોર્ટ નંબરો સેટ કરી શકો છો, પરંતુ EXPOSE આદેશનો ઉપયોગ કરીને તેનો ઉલ્લેખ કરવો વધુ સારું છે - તે અન્ય લોકો અને પ્રોગ્રામ્સ માટે તમારી છબીઓનો ઉપયોગ કરવાનું સરળ બનાવશે.
• વોલ્યુમ્સ પર સતત ડેટા સંગ્રહિત કરો: કન્ટેનરનો નાશ થયા પછી જે ડેટા રહેવો જોઈએ તે વોલ્યુમમાં લખવો જોઈએ.
• ઇમેજ મેટાડેટા લખો: ટૅગ્સ, લેબલ્સ અને ટીકાઓ ઇમેજને ઉપયોગમાં સરળ બનાવે છે - અન્ય ડેવલપર્સ તમારો આભાર માનશે.
• હોસ્ટ અને ઇમેજને સિંક્રનાઇઝ કરો: કેટલીક કન્ટેનરાઇઝ્ડ એપ્લીકેશન માટે કન્ટેનરને અમુક વિશેષતાઓ પર હોસ્ટ સાથે સમન્વયિત કરવાની જરૂર પડે છે, જેમ કે સમય અથવા મશીન ID.
• નિષ્કર્ષમાં, અમે નમૂનાઓ અને શ્રેષ્ઠ પ્રથાઓ શેર કરીએ છીએ જે તમને ઉપર સૂચિબદ્ધ સિદ્ધાંતોને વધુ અસરકારક રીતે લાગુ કરવામાં મદદ કરશે:
  www.slideshare.net/luebken/container-patterns
  docs.docker.com/engine/userguide/eng-image/dockerfile_best-practices
  docs.projectatomic.io/container-best-practices
  docs.openshift.com/enterprise/3.0/creating_images/guidelines.html
  www.usenix.org/system/files/conference/hotcloud16/hotcloud16_burns.pdf
  leanpub.com/k8spatterns
  12factor.net

ઓપનશિફ્ટ કન્ટેનર પ્લેટફોર્મ - 4 ના નવા સંસ્કરણ પર વેબિનાર
11 જૂન 11.00 વાગ્યે

તમે શું શીખશો:

• અપરિવર્તનશીલ Red Hat Enterprise Linux CoreOS
• OpenShift સેવા મેશ
• ઓપરેટર ફ્રેમવર્ક
• નેટીવ ફ્રેમવર્ક

સોર્સ: www.habr.com