ડોકર અને ગિટલેબ સીઆઈ સાથે વિકાસ અને પરીક્ષણ પ્રક્રિયા

હું સૂચન કરું છું કે તમે Inventos "Docker + Gitlab CI સાથે વિકાસ અને પરીક્ષણ પ્રક્રિયા" ના એલેક્ઝાન્ડર સિગાચેવ દ્વારા અહેવાલની ટ્રાન્સક્રિપ્ટ વાંચો.

જેઓ ડોકર + ગિટલેબ સીઆઈ પર આધારિત વિકાસ અને પરીક્ષણ પ્રક્રિયાને અમલમાં મૂકવાનું શરૂ કરી રહ્યા છે તેઓ ઘણીવાર મૂળભૂત પ્રશ્નો પૂછે છે. ક્યાંથી શરૂઆત કરવી? કેવી રીતે ગોઠવવું? કેવી રીતે પરીક્ષણ કરવું?

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

કોણ ધ્યાન રાખે છે, કૃપા કરીને બિલાડીની નીચે.

મારું નામ એલેક્ઝાન્ડર સિગાચેવ છે. હું Inventos માટે કામ કરું છું. હું તમને ડોકરનો ઉપયોગ કરવાના મારા અનુભવ વિશે અને કંપનીના પ્રોજેક્ટ્સ પર અમે તેને ધીમે-ધીમે કેવી રીતે લાગુ કરી રહ્યા છીએ તે વિશે જણાવીશ.

રિપોર્ટનો વિષય: ડોકર અને ગિટલેબ સીઆઈનો ઉપયોગ કરીને વિકાસ પ્રક્રિયા.

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

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

અમારું ધ્યેય: આપણે જે કંઈપણ હાથમાં લઈએ છીએ તેને ડોકરાઈઝ કરો.

આપણે કઈ સમસ્યાઓ હલ કરીએ છીએ?

જ્યારે કોઈ કંપનીમાં ઘણી ટીમો હોય છે, ત્યારે પ્રોગ્રામર એક વહેંચાયેલ સંસાધન છે. એવા તબક્કાઓ છે જ્યારે પ્રોગ્રામરને એક પ્રોજેક્ટમાંથી બહાર કાઢવામાં આવે છે અને અમુક સમય માટે બીજા પ્રોજેક્ટને આપવામાં આવે છે.

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

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

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

જ્યારે સિસ્ટમ વધે છે અને આ ડોમેન નામો રૂપરેખાંકનમાં શામેલ થવાનું શરૂ કરે છે, ત્યારે વિકાસ વાતાવરણમાં સંઘર્ષ ઊભો થાય છે અને સાઇટ પાથ ફરીથી લખવામાં આવે છે.

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

બીજી સમસ્યા પુસ્તકાલયોની વિવિધ આવૃત્તિઓ છે. તે ઘણીવાર થાય છે કે વિકાસકર્તા વિવિધ પ્રોજેક્ટ્સ પર કામ કરે છે. એક લેગસી પ્રોજેક્ટ છે, જે પાંચ વર્ષ પહેલા શરૂ થયો હતો (2017 થી - સંપાદકની નોંધ). શરૂઆતમાં અમે MySQL 5.5 થી શરૂઆત કરી. એવા આધુનિક પ્રોજેક્ટ્સ પણ છે જ્યાં અમે MySQL ના વધુ આધુનિક સંસ્કરણો અમલમાં મૂકવાનો પ્રયાસ કરી રહ્યા છીએ, ઉદાહરણ તરીકે 5.7 અથવા તેથી વધુ જૂના (2017 માં - સંપાદકની નોંધ)

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

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

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

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

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

સાધનો. આપણે શું વાપરીએ છીએ?

• ડોકર પોતે. એક ડોકરફાઇલ એક એપ્લિકેશનની નિર્ભરતાનું વર્ણન કરે છે.
• ડોકર-કંપોઝ એ એક બંડલ છે જે અમારી ઘણી ડોકર એપ્લિકેશનોને એકસાથે લાવે છે.
• અમે સોર્સ કોડ સ્ટોર કરવા માટે GitLab નો ઉપયોગ કરીએ છીએ.
• અમે સિસ્ટમ એકીકરણ માટે GitLab-CI નો ઉપયોગ કરીએ છીએ.

અહેવાલમાં બે ભાગોનો સમાવેશ થાય છે.

પ્રથમ ભાગ તમને જણાવશે કે વિકાસકર્તાઓની મશીનો પર ડોકર કેવી રીતે ચલાવવું.

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

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

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

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

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

વિકાસકર્તા, પહેલાની જેમ, કોઈપણ ઉપલબ્ધ IP સરનામાંને ઍક્સેસ કરી શકે છે, ઉદાહરણ તરીકે, મશીનનું 127.0.0.1 સ્થાનિક અથવા બાહ્ય IP સરનામું.

છેલ્લી લાઇન કહે છે કે વેબ કન્ટેનર ડીબી કન્ટેનર પર આધારિત છે. જ્યારે આપણે વેબ કન્ટેનરને લોન્ચ કરવા માટે કૉલ કરીએ છીએ, ત્યારે ડોકર-કંપોઝ પહેલા અમારા માટે ડેટાબેઝ લોન્ચ કરશે. ડેટાબેઝની શરૂઆત પહેલાથી જ (હકીકતમાં, કન્ટેનર લોંચ થયા પછી! આ ડેટાબેઝની તૈયારીની ખાતરી આપતું નથી) તે અમારી એપ્લિકેશન, અમારા બેકએન્ડને લોન્ચ કરશે.

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

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

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

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

છબી બનાવ્યા પછી, વિકાસ અને ઉત્પાદન બંનેમાં કન્ટેનર સમાન હશે. આ ખાસ કરીને મોટા સ્થાપનો માટે સાચું છે.

ફ્રન્ટએન્ડ પર આપણે JavaScipt અને NodeJS નો ઉપયોગ કરીએ છીએ.

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

આગળ, JavaScipt એસેમ્બલ કરવાનું કાર્ય શરૂ કરવામાં આવે છે અને સ્ટેટિકલી એસેમ્બલ કોડ nginx દ્વારા મોકલવામાં આવે છે, સંસાધનોની બચત કરે છે.

અહીં મેં અમારા નવીનતમ પ્રોજેક્ટનો આકૃતિ પ્રદાન કર્યો છે.

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

અમે આ માટે શું કર્યું છે?

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

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

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

પુશ સૂચનાઓ નોડજેએસમાં લાગુ કરાયેલા અન્ય ઘટક સાથે ક્રિયાપ્રતિક્રિયા કરે છે.

કતારો બનાવવામાં આવે છે અને સૂચનાઓ તેમની પોતાની પદ્ધતિ અનુસાર મોકલવામાં આવે છે.

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

સમાન વસ્તુ પરંતુ સંખ્યામાં. કોડ પુનઃઉપયોગ અહીં મહત્વપૂર્ણ છે.

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

તે સમયે અમે નોડજેએસના સંસ્કરણ 4 નો ઉપયોગ કરતા હતા. હવે (2017 માં - સંપાદકની નોંધ) અમારા નવીનતમ વિકાસમાં અમે NodeJS ના સંસ્કરણ 7 નો ઉપયોગ કરીએ છીએ. પુસ્તકાલયોના નવા સંસ્કરણોને સામેલ કરવા માટે નવા ઘટકોમાં કોઈ સમસ્યા નથી.

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

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

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

નવો પ્રોજેક્ટ બનાવતી વખતે, અમે એક Dockerfile બનાવીએ છીએ અને ઇચ્છિત ઇકોસિસ્ટમ (Python, Ruby, NodeJS)નું વર્ણન કરીએ છીએ. ડોકર-કંપોઝમાં, તે જરૂરી નિર્ભરતા - ડેટાબેઝનું વર્ણન કરે છે. અમે વર્ણન કરીએ છીએ કે અમને ત્યાં અને ત્યાં ડેટા સ્ટોર કરવા માટે આવા અને આવા સંસ્કરણના ડેટાબેઝની જરૂર છે.

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

nginx અને mysql રૂપરેખાંકન સંગ્રહિત કરવા માટે, અમે એક Docker ફોલ્ડર ઉમેર્યું છે જેમાં અમે જરૂરી રૂપરેખાઓ સંગ્રહિત કરીએ છીએ. જ્યારે ડેવલપર તેના મશીન પર રિપોઝીટરીનો ગિટ ક્લોન બનાવે છે, ત્યારે તેની પાસે પહેલેથી જ સ્થાનિક વિકાસ માટે એક પ્રોજેક્ટ તૈયાર હોય છે. કયા પોર્ટ અથવા કઈ સેટિંગ્સ લાગુ કરવી તે વિશે કોઈ પ્રશ્ન નથી.

આગળ અમારી પાસે ઘણા ઘટકો છે: એડમિન, માહિતી-API, પુશ સૂચનાઓ.

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

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

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

જો પુશ સૂચનાઓ સાથે એકીકરણની જરૂર હોય, તો પછી docker-compose.yaml અને docker-compose-push.yaml લોન્ચ કરવામાં આવે છે.

docker-compose.yaml અને docker-compose-push.yaml ફોલ્ડરમાં હોવાથી, એક વર્ચ્યુઅલ નેટવર્ક આપમેળે બને છે.

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

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

વિકાસ પર્યાવરણ માટે અમે .dev ડોમેન - api.informer.dev નો ઉપયોગ કરીએ છીએ. .dev ડોમેન સાથેની એપ્લિકેશનો વિકાસકર્તાના સ્થાનિક મશીન પર ઉપલબ્ધ છે.

પછી રૂપરેખાઓ દરેક પ્રોજેક્ટમાં સ્થાનાંતરિત થાય છે અને બધા પ્રોજેક્ટ્સ એક જ સમયે એકસાથે શરૂ થાય છે.

જો આપણે તેને ગ્રાફિકલી ચિત્રિત કરીએ છીએ, તો તે તારણ આપે છે કે ક્લાયંટ અમારું બ્રાઉઝર છે અથવા કોઈ પ્રકારનું સાધન છે જેની સાથે અમે બેલેન્સરને વિનંતી કરીએ છીએ.

બેલેન્સર નક્કી કરે છે કે ડોમેન નામના આધારે કયા કન્ટેનરને ઍક્સેસ કરવાની જરૂર છે.

આ nginx હોઈ શકે છે, જે એડમિન પેનલને JS પ્રદાન કરે છે. આ nginx માંથી હોઈ શકે છે, જે API પ્રદાન કરે છે, અથવા સ્થિર ફાઈલો, જે nginx ને ઈમેજીસ લોડ કરવાના સ્વરૂપમાં પ્રદાન કરવામાં આવે છે.

આકૃતિ બતાવે છે કે કન્ટેનર વર્ચ્યુઅલ નેટવર્ક સાથે જોડાયેલા છે અને પ્રોક્સીની પાછળ છુપાયેલા છે.

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

મારી અરજીને ડોકરાઇઝ કરવા માટે મારે કયું ઉદાહરણ જોવું જોઈએ? મારા મતે, એક સારું ઉદાહરણ MySQL માટે સત્તાવાર ડોકર ઇમેજ છે.

તે તદ્દન જટિલ છે. ત્યાં ઘણી આવૃત્તિઓ છે. પરંતુ તેની કાર્યક્ષમતા તમને ઘણી જરૂરિયાતોને આવરી લેવાની મંજૂરી આપે છે જે વધુ વિકાસની પ્રક્રિયામાં ઊભી થઈ શકે છે. જો તમે સમય કાઢો અને સમજો કે આ બધું કેવી રીતે ક્રિયાપ્રતિક્રિયા કરે છે, તો મને લાગે છે કે તમને તેને જાતે અમલમાં લાવવામાં કોઈ સમસ્યા નહીં હોય.

Hub.docker.com સામાન્ય રીતે github.com ની લિંક્સ ધરાવે છે, જ્યાં કાચો ડેટા સીધો પ્રદાન કરવામાં આવે છે જેમાંથી તમે તમારી જાતે એક છબી બનાવી શકો છો.

આગળ આ રિપોઝીટરીમાં એક સ્ક્રિપ્ટ docker-endpoint.sh છે, જે એપ્લિકેશન લોન્ચની પ્રારંભિક શરૂઆત અને આગળની પ્રક્રિયા માટે જવાબદાર છે.

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

રેન્ડમ પાસવર્ડ બનાવવાનો વિકલ્પ છે. અમે કહીએ છીએ કે અમને વપરાશકર્તાની જરૂર છે, અમારે વપરાશકર્તા માટે પાસવર્ડ સેટ કરવાની જરૂર છે, અને અમારે ડેટાબેઝ બનાવવાની જરૂર છે.

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

github.com પર MySQL નું વિશિષ્ટ સંસ્કરણ કેવું દેખાય છે તેનું આ એક ઉદાહરણ છે. તમે ડોકરફાઇલ ખોલી શકો છો અને ત્યાં ઇન્સ્ટોલેશન કેવી રીતે થાય છે તે જોઈ શકો છો.

docker-endpoint.sh સ્ક્રિપ્ટ એન્ટ્રી પોઈન્ટ માટે જવાબદાર છે. પ્રારંભિક પ્રારંભ દરમિયાન, કેટલીક તૈયારી ક્રિયાઓ જરૂરી છે અને આ બધી ક્રિયાઓ પ્રારંભિક સ્ક્રિપ્ટમાં શામેલ છે.

ચાલો બીજા ભાગ તરફ આગળ વધીએ.

સોર્સ કોડ સ્ટોર કરવા માટે અમે ગિટલેબ પર સ્વિચ કર્યું. આ એકદમ શક્તિશાળી સિસ્ટમ છે જેમાં વિઝ્યુઅલ ઇન્ટરફેસ છે.

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

Gitlab CI 2 પર અહેવાલ https://goo.gl/uohKjI — રૂબી રશિયા ક્લબનો અહેવાલ ખૂબ વિગતવાર છે અને તે તમારા માટે રસપ્રદ હોઈ શકે છે.

હવે આપણે Gitlab CI ને સક્રિય કરવા માટે શું જરૂરી છે તે જોઈશું. Gitlab CI શરૂ કરવા માટે, આપણે ફક્ત .gitlab-ci.yml ફાઇલને પ્રોજેક્ટના રૂટમાં મૂકવાની જરૂર છે.

અહીં અમે વર્ણન કરીએ છીએ કે અમે પરીક્ષણ, જમાવટ જેવા રાજ્યોનો ક્રમ કરવા માંગીએ છીએ.

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

આગળ આપણે કહીએ છીએ કે ડેટાબેઝ બદલવા અને પરીક્ષણો ચલાવવા માટે સ્થળાંતર ચલાવવું જરૂરી છે.

જો સ્ક્રિપ્ટો યોગ્ય રીતે ચલાવવામાં આવે છે અને ભૂલ કોડ પરત કરતા નથી, તો સિસ્ટમ જમાવટના બીજા તબક્કામાં આગળ વધે છે.

ડિપ્લોયમેન્ટ સ્ટેજ હાલમાં સ્ટેજીંગ માટે અમલમાં છે. અમે નો-ડાઉનટાઇમ પુનઃપ્રારંભનું આયોજન કર્યું નથી.

અમે બળજબરીથી બધા કન્ટેનર ઓલવીએ છીએ, અને પછી અમે પરીક્ષણ દરમિયાન પ્રથમ તબક્કે એકત્રિત કરાયેલા તમામ કન્ટેનરને ફરીથી ઉભા કરીએ છીએ.

ચાલો ડેટાબેઝ સ્થળાંતર ચલાવીએ જે વિકાસકર્તાઓ દ્વારા વર્તમાન ચલ પર્યાવરણ માટે લખવામાં આવ્યા હતા.

એક નોંધ છે કે આ માત્ર માસ્ટર બ્રાન્ચ પર જ લાગુ થવી જોઈએ.

અન્ય શાખાઓ બદલતી વખતે કામ કરતું નથી.

શાખાઓ સાથે રોલઆઉટ ગોઠવવાનું શક્ય છે.

આને વધુ ગોઠવવા માટે, અમારે ગિટલેબ રનર ઇન્સ્ટોલ કરવાની જરૂર છે.

આ ઉપયોગિતા ગોલાંગમાં લખાયેલ છે. તે એક જ ફાઇલ છે જે ગોલાંગ વિશ્વમાં સામાન્ય છે, જેને કોઈ નિર્ભરતાની જરૂર નથી.

સ્ટાર્ટઅપ વખતે અમે ગિટલેબ રનરને રજીસ્ટર કરીએ છીએ.

અમે Gitlab વેબ ઈન્ટરફેસમાં કી પ્રાપ્ત કરીએ છીએ.

પછી આપણે આદેશ વાક્ય પર પ્રારંભિક આદેશને કૉલ કરીએ છીએ.

ડાયલોગ મોડમાં ગિટલેબ રનરને ગોઠવી રહ્યું છે (શેલ, ડોકર, વર્ચ્યુઅલબોક્સ, SSH)

ગિટલેબ રનર પરનો કોડ .gitlab-ci.yml સેટિંગના આધારે દરેક કમિટ પર એક્ઝિક્યુટ થશે.

વેબ ઈન્ટરફેસમાં Gitlab માં તે કેવી રીતે દૃષ્ટિની દેખાય છે. GItlab CI ને કનેક્ટ કર્યા પછી, અમારી પાસે એક ધ્વજ છે જે દર્શાવે છે કે બિલ્ડ અત્યારે કઈ સ્થિતિમાં છે.

અમે જોઈએ છીએ કે 4 મિનિટ પહેલા એક પ્રતિબદ્ધતા કરવામાં આવી હતી જેણે તમામ પરીક્ષણો પાસ કર્યા હતા અને કોઈ સમસ્યા ઊભી કરી ન હતી.

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

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

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

જ્યારે અમે ડોકરનો અમલ કર્યો ત્યારે અમે સ્ટેજિંગમાં કઈ સમસ્યાઓ હલ કરી? અમારી સિસ્ટમમાં ઘટકોનો સમાવેશ થાય છે અને અમારે રીપોઝીટરીમાં અપડેટ કરાયેલા કેટલાક ઘટકોને જ પુનઃપ્રારંભ કરવાની જરૂર હતી, સમગ્ર સિસ્ટમને નહીં.

આ કરવા માટે, અમારે દરેક વસ્તુને અલગ ફોલ્ડરમાં અલગ કરવાની હતી.

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

આસપાસ જવા માટે, અમે ડોકરમાં મેન્યુઅલી નેટવર્ક બનાવ્યું છે. ડોકર-કંપોઝમાં લખ્યું હતું કે તમારે આ પ્રોજેક્ટ માટે આવા નેટવર્કનો ઉપયોગ કરવો જોઈએ.

આમ, આ મેશથી શરૂ થતા દરેક ઘટક સિસ્ટમના અન્ય ભાગોમાં ઘટકો જુએ છે.

આગળની સમસ્યા ઘણા પ્રોજેક્ટ્સ વચ્ચે સ્ટેજિંગને વિભાજિત કરવાની છે.

આ બધું સુંદર દેખાવા માટે અને ઉત્પાદનની શક્ય તેટલી નજીક હોવાથી, પોર્ટ 80 અથવા 443 નો ઉપયોગ કરવો સારું છે, જેનો ઉપયોગ WEB માં દરેક જગ્યાએ થાય છે.

અમે આ કેવી રીતે હલ કર્યું? અમે તમામ મોટા પ્રોજેક્ટ માટે એક ગિટલેબ રનરને સોંપ્યો છે.

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

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

અમે nginx-proxy ને એક અલગ લૉન્ચ સ્ક્રિપ્ટમાં ખસેડ્યું અને તેમાં તમામ પ્રોજેક્ટ્સની ગ્રીડ લખી.

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

અમારી વિનંતીઓ પોર્ટ 80 પરના ડોમેન દ્વારા આવે છે અને કન્ટેનરના જૂથને ઉકેલવામાં આવે છે જે આ ડોમેનને સેવા આપે છે.

બીજી કઈ સમસ્યાઓ હતી? આ તે છે જે બધા કન્ટેનર મૂળભૂત રીતે રૂટ તરીકે ચાલે છે. આ સિસ્ટમનું રુટ અસમાન રુટ હોસ્ટ છે.

જો કે, જો તમે કન્ટેનર દાખલ કરો છો, તો તે રૂટ હશે અને અમે આ કન્ટેનરમાં જે ફાઇલ બનાવીએ છીએ તે રૂટ અધિકારો મેળવે છે.

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

આ કેવી રીતે ઉકેલી શકાય? તમે એવા વપરાશકર્તાઓને ઉમેરી શકો છો જે કન્ટેનરમાં હશે.

જ્યારે અમે વપરાશકર્તાને ઉમેર્યા ત્યારે કઈ સમસ્યાઓ ઊભી થઈ?

વપરાશકર્તા બનાવતી વખતે, જૂથ ID (UID) અને વપરાશકર્તા ID (GID) ઘણીવાર મેળ ખાતા નથી.

કન્ટેનરમાં આ સમસ્યાને ઉકેલવા માટે અમે ID 1000 ધરાવતા વપરાશકર્તાઓનો ઉપયોગ કરીએ છીએ.

અમારા કિસ્સામાં, આ એ હકીકત સાથે સુસંગત છે કે લગભગ તમામ વિકાસકર્તાઓ ઉબુન્ટુ ઓએસનો ઉપયોગ કરે છે. અને Ubuntu OS માં પ્રથમ વપરાશકર્તા પાસે ID 1000 છે.

શું અમારી પાસે યોજનાઓ છે?

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

કેટલીક સમસ્યાઓ કે જે અમે ઉકેલી છે તે પ્રમાણભૂત માધ્યમો દ્વારા પહેલાથી જ હલ થઈ ગઈ હશે.

હું ખરેખર આગળ વધવા માંગુ છું અને સીધા ઓર્કેસ્ટ્રેશનમાં જવા માંગુ છું.

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

સ્પાવિંગ કન્ટેનર લોગ સાથે કામ અસુવિધાજનક બનાવે છે. હવે લોગ અલગ છે. તેઓ કન્ટેનરમાં વેરવિખેર છે. વેબ ઈન્ટરફેસ દ્વારા લોગની સુવિધાજનક ઍક્સેસ બનાવવાનું એક કાર્ય છે.

સોર્સ: www.habr.com