ડોકર સાથે સતત ડિલિવરી પ્રેક્ટિસ (સમીક્ષા અને વિડિયો)

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

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

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

ડોકર સાથે સતત ડિલિવરી

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

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

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

મુખ્ય રોલઆઉટ પેટર્ન

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

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

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

ચાલો સારાંશ આપીએ મુખ્ય રોલઆઉટ પેટર્ન નીચેના પરિબળોને ધ્યાનમાં લેતા નવા સંસ્કરણો:

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

એપ્લિકેશનના વિવિધ સંસ્કરણોને અલગ કન્ટેનરમાં જમાવવાનો આ અભિગમ બીજી સગવડ પૂરી પાડે છે - ઝડપી રોલબેક જૂના સંસ્કરણ પર (છેવટે, ટ્રાફિકને ઇચ્છિત કન્ટેનર પર સ્વિચ કરવા માટે તે પૂરતું છે).

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

પ્રજનનક્ષમતા

"પુનઃઉત્પાદનક્ષમતા" દ્વારા અમારો મતલબ એપ્લીકેશન ઓપરેટ કરતી વખતે આવતી સમસ્યાઓનો સામાન્યીકૃત સમૂહ છે. અમે આવા કિસ્સાઓ વિશે વાત કરી રહ્યા છીએ:

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

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

ઈન્ફ્રાસ્ટ્રક્ચર કોડ છે

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

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

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

ડોકર છબીઓ, ગિટ સાથે સંચાર

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

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

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

ડપ્પ

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

તેનો સોર્સ કોડ રુબીમાં લખાયેલ છે, ઓપન સોર્સ અને પ્રકાશિત થાય છે GitHub. કમનસીબે, દસ્તાવેજીકરણ હાલમાં સાધનનો સૌથી નબળો મુદ્દો છે, પરંતુ અમે તેના પર કામ કરી રહ્યા છીએ. અને અમે Dapp વિશે એક કરતા વધુ વાર લખીશું અને વાત કરીશું, કારણ કે... અમે સંપૂર્ણ રસ ધરાવતા સમુદાય સાથે તેની ક્ષમતાઓ શેર કરવા માટે નિષ્ઠાપૂર્વક રાહ જોઈ શકતા નથી, પરંતુ તે દરમિયાન, તમારી સમસ્યાઓ મોકલો અને વિનંતીઓ ખેંચો અને/અથવા GitHub પર પ્રોજેક્ટના વિકાસને અનુસરો.

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

ક્યુબર્નેટિસ

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

રોલઆઉટ માટે, Kubernetes ઑફર કરે છે:

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

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

અંતિમ ભલામણો

1. ડોકરનો ઉપયોગ કરો.
2. તમારી બધી જરૂરિયાતો માટે એપ્લિકેશનોની ડોકર છબીઓ બનાવો.
3. "ઇન્ફ્રાસ્ટ્રક્ચર એ કોડ છે" સિદ્ધાંતને અનુસરો.
4. ગિટને ડોકર સાથે લિંક કરો.
5. રોલઆઉટના ક્રમને નિયંત્રિત કરો.
6. તૈયાર પ્લેટફોર્મનો ઉપયોગ કરો (કુબરનેટ્સ અથવા અન્ય).

વિડિઓઝ અને સ્લાઇડ્સ

પ્રદર્શનમાંથી વિડિઓ (લગભગ એક કલાક) YouTube પર પ્રકાશિત (રિપોર્ટ પોતે 5મી મિનિટથી શરૂ થાય છે - આ ક્ષણથી રમવા માટે લિંકને અનુસરો).

અહેવાલની રજૂઆત:

PS

અમારા બ્લોગ પરના વિષય પરના અન્ય અહેવાલો:

• «werf - કુબરનેટ્સમાં CI/CD માટે અમારું સાધન (વિહંગાવલોકન અને વિડિયો રિપોર્ટ)» (Dmitry Stolyarov; DevOpsConf ખાતે 27 મે, 2019);
• «ડેટાબેસેસ અને કુબરનેટ્સ» (દિમિત્રી સ્ટોલ્યારોવ; હાઇલોડ++ પર નવેમ્બર 8, 2018);
• «કુબરનેટ્સ અને ગિટલેબ સાથે CI/CD શ્રેષ્ઠ વ્યવહારો» (દિમિત્રી સ્ટોલ્યારોવ; હાઇલોડ++ પર નવેમ્બર 7, 2017);
• «નાના પ્રોજેક્ટ્સમાં કુબરનેટ્સ સાથેનો અમારો અનુભવ» (દિમિત્રી સ્ટોલ્યારોવ; રૂટકોન્ફ ખાતે જૂન 6, 2017).

સોર્સ: www.habr.com