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

પ્રથમ, થોડો સિદ્ધાંત. શું થયું છે બાર-પરિબળ એપ્લિકેશન?

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

દસ્તાવેજ Heroku પ્લેટફોર્મના વિકાસકર્તાઓ દ્વારા બનાવવામાં આવ્યો હતો.

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

સંક્ષિપ્તમાં પરિબળો વિશે કે જેના પર આ પદ્ધતિ આધારિત છે:

1. કોડબેઝ - વર્ઝન કંટ્રોલમાં ટ્રેક કરાયેલ એક કોડબેઝ - બહુવિધ જમાવટ
2. અવલંબન - નિર્ભરતાઓને સ્પષ્ટપણે જાહેર કરો અને અલગ કરો
3. રૂપરેખાંકન - રનટાઇમમાં રૂપરેખાંકન સાચવો
4. બેકિંગ સેવાઓ - બેકિંગ સેવાઓને પ્લગ-ઇન સંસાધનો તરીકે ધ્યાનમાં લો
5. બનાવો, છોડો, ચલાવો - એસેમ્બલી અને અમલના તબક્કાઓને સખત રીતે અલગ કરો
6. પ્રક્રિયાઓ - એપ્લિકેશનને એક અથવા વધુ સ્ટેટલેસ પ્રક્રિયાઓ તરીકે ચલાવો
7. પોર્ટ બંધનકર્તા - પોર્ટ બાઈન્ડીંગ દ્વારા સેવાઓ નિકાસ કરો
8. સમન્વય - પ્રક્રિયાઓનો ઉપયોગ કરીને તમારી એપ્લિકેશનને સ્કેલ કરો
9. નિકાલક્ષમતા - ઝડપી સ્ટાર્ટઅપ અને સ્વચ્છ શટડાઉન સાથે મહત્તમ વિશ્વસનીયતા
10. એપ્લિકેશન ડેવલપમેન્ટ/ઓપરેશન પેરિટી - તમારા વિકાસ, સ્ટેજીંગ અને ઉત્પાદન વાતાવરણને શક્ય તેટલું સમાન રાખો
11. લોગીંગ - ઘટનાઓના પ્રવાહ તરીકે લોગને જુઓ
12. વહીવટી કાર્યો - એડહૉક પ્રક્રિયાઓનો ઉપયોગ કરીને વહીવટ/વ્યવસ્થાપન કાર્યો કરો

તમે નીચેના સંસાધનોમાંથી 12 પરિબળો વિશે વધુ માહિતી મેળવી શકો છો:

• સત્તાવાર સ્ત્રોત - વાંચવું જ જોઈએ
• habr પર લેખ. બાર-પરિબળ એપ્લિકેશન - સત્તાવાર અનુવાદ
• habr પર લેખ. 7 ફેક્ટર એપ્લિકેશનમાં 12 ખૂટે છે - તેમને સુધારવાના ઉદ્દેશ્ય સાથે 12 પરિબળો પર એક નવો દેખાવ.

બ્લુ-ગ્રીન ડિપ્લોયમેન્ટ શું છે?

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

ક્લાસિક BG ડિપ્લોય સ્કીમ નીચેની ઈમેજમાં બતાવેલ જેવી દેખાય છે.

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

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

ખરાબ અને સારી સલાહ

જવાબદારીનો ઇનકાર: નીચેના ઉદાહરણો હું ઉપયોગ કરું છું તે ઉપયોગિતાઓ/પદ્ધતિઓ દર્શાવે છે, તમે સમાન કાર્યો સાથે સંપૂર્ણપણે કોઈપણ વિકલ્પોનો ઉપયોગ કરી શકો છો.

મોટાભાગનાં ઉદાહરણો PHP અને Docker સાથે વેબ ડેવલપમેન્ટ (આ આશ્ચર્યની વાત છે) સાથે એક અથવા બીજી રીતે છેદશે.

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

1. કોડબેઝ

સર્વર પર એક સમયે ફાઇલો અપલોડ કરવા માટે FTP અને FileZilla નો ઉપયોગ કરો, કોડને પ્રોડક્શન સર્વર સિવાય બીજે ક્યાંય સ્ટોર કરશો નહીં.

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

2. અવલંબન

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

પ્રોજેક્ટમાં હંમેશા નિર્ભરતાની સ્પષ્ટ રીતે સમજી શકાય તેવી સૂચિ હોવી જોઈએ (નિર્ભરતા દ્વારા મારો અર્થ પર્યાવરણ પણ છે). બધી અવલંબન સ્પષ્ટપણે વ્યાખ્યાયિત અને અલગ હોવી જોઈએ.
ચાલો ઉદાહરણ તરીકે લઈએ રચયિતા и Docker.

રચયિતા — પેકેજ મેનેજર જે તમને PHP માં લાઈબ્રેરીઓ ઈન્સ્ટોલ કરવાની પરવાનગી આપે છે. કંપોઝર તમને વર્ઝનને કડક અથવા ઢીલી રીતે સ્પષ્ટ કરવા અને તેમને સ્પષ્ટ રીતે વ્યાખ્યાયિત કરવાની મંજૂરી આપે છે. સર્વર પર 20 જુદા જુદા પ્રોજેક્ટ્સ હોઈ શકે છે અને દરેક પાસે પેકેજો અને પુસ્તકાલયોની વ્યક્તિગત સૂચિ અન્યથી સ્વતંત્ર હશે.

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

3. રૂપરેખાંકન

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

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

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

4. તૃતીય પક્ષ સેવાઓ

પર્યાવરણ સાથે સખત રીતે જોડાયેલા રહો, ચોક્કસ વાતાવરણમાં સમાન સેવાઓ માટે વિવિધ જોડાણોનો ઉપયોગ કરો.

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

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

5. બિલ્ડ, રિલીઝ, એક્ઝિક્યુટ

સર્વર પર કોડનું માત્ર અંતિમ સંસ્કરણ રાખો, રિલીઝને પાછું લાવવાની કોઈ શક્યતા નથી. ડિસ્ક જગ્યા ભરવાની જરૂર નથી. કોઈપણ જે વિચારે છે કે તેઓ કોડને પ્રોડક્શનમાં ભૂલ સાથે રિલીઝ કરી શકે છે તે ખરાબ પ્રોગ્રામર છે!

જમાવટના તમામ તબક્કાઓ એકબીજાથી અલગ હોવા જોઈએ.

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

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

6. પ્રક્રિયાઓ

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

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

7. પોર્ટ બંધનકર્તા

ફક્ત વેબ સર્વરને તૃતીય-પક્ષ સેવાઓ સાથે કેવી રીતે કાર્ય કરવું તે જાણવું જોઈએ. અથવા હજી વધુ સારું, તૃતીય-પક્ષ સેવાઓ સીધા વેબ સર્વરની અંદર ઇન્સ્ટોલ કરો. ઉદાહરણ તરીકે, અપાચેમાં PHP મોડ્યુલ તરીકે.
તમારી બધી સેવાઓ અમુક સરનામાં અને પોર્ટ (localgost:5432, localhost:3000, nginx:80, php-fpm:9000), એટલે કે, nginx થી હું php-fpm અને બંનેને ઍક્સેસ કરી શકું છું. postgres, અને php-fpm થી postgres અને nginx અને વાસ્તવમાં દરેક સેવામાંથી હું બીજી સેવાને ઍક્સેસ કરી શકું છું. આ રીતે, સેવાની સદ્ધરતા બીજી સેવાની સદ્ધરતા સાથે જોડાયેલી નથી.

8. સમાંતરવાદ

એક પ્રક્રિયા સાથે કામ કરો, અન્યથા ઘણી પ્રક્રિયાઓ એકબીજા સાથે મળી શકશે નહીં!

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

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

9. નિકાલક્ષમતા

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

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

10. એપ્લિકેશન ડેવલપમેન્ટ/ઓપરેશન પેરિટી

એપ્લિકેશનનું ઉત્પાદન, સ્ટેજીંગ અને સ્થાનિક સંસ્કરણ અલગ હોવું આવશ્યક છે. ઉત્પાદનમાં અમે Yii Lite ફ્રેમવર્કનો ઉપયોગ કરીએ છીએ, અને સ્થાનિક રીતે Yii, જેથી તે ઉત્પાદનમાં ઝડપથી કામ કરે!

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

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

11. લોગ્સ

અમે ફાઇલો અને ડેટાબેસેસ પર લોગ લખીએ છીએ! અમે લોગમાંથી ફાઇલો અને ડેટાબેસેસ સાફ કરતા નથી. ચાલો ફક્ત 9000 પેટા બાઈટ સાથેની હાર્ડ ડ્રાઈવ ખરીદીએ અને તે સારું છે.

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

12. વહીવટી કાર્યો

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

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

PHP, Laravel, Laradock, Docker-compose માં ઉદાહરણ અમલીકરણ

PS બધા ઉદાહરણો MacOS પર બનાવવામાં આવ્યા હતા. તેમાંના મોટાભાગના Linux માટે પણ યોગ્ય છે. Windows વપરાશકર્તાઓ, મને માફ કરો, પરંતુ મેં લાંબા સમયથી Windows સાથે કામ કર્યું નથી.

ચાલો એવી પરિસ્થિતિની કલ્પના કરીએ કે જ્યાં અમારી પાસે અમારા PC પર PHP નું કોઈપણ સંસ્કરણ ઇન્સ્ટોલ કરેલ નથી અને કંઈપણ નથી.
ડોકર અને ડોકર-કંપોઝના નવીનતમ સંસ્કરણો ઇન્સ્ટોલ કરો. (આ ઇન્ટરનેટ પર મળી શકે છે)

docker -v && 
docker-compose -v

1. અમે મૂકીએ છીએ લારાડોક

git clone https://github.com/Laradock/laradock.git && 
ls

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

2. અમારી એપ્લિકેશન ચલાવવા માટે લારાડોકને ગોઠવો.

cd laradock && 
cp env-example .env

2.1. અમુક એડિટરમાં habr ડિરેક્ટરી (પેરેન્ટ ફોલ્ડર કે જેમાં લેરાડોક ક્લોન થયેલ છે) ખોલો. (મારા PHPStorm કેસમાં)

આ તબક્કે અમે ફક્ત પ્રોજેક્ટને નામ આપીએ છીએ.

2.2. વર્કસ્પેસ ઇમેજ લોંચ કરો. (તમારા કિસ્સામાં, છબીઓ બનાવવામાં થોડો સમય લાગશે)
વર્કસ્પેસ એ ડેવલપર વતી ફ્રેમવર્ક સાથે કામ કરવા માટે ખાસ તૈયાર કરેલી છબી છે.

અમે ઉપયોગ કરીને કન્ટેનર અંદર જાઓ

docker-compose up -d workspace && 
docker-compose exec workspace bash

2.3. લારાવેલ ઇન્સ્ટોલ કરી રહ્યું છે

composer create-project --prefer-dist laravel/laravel application

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

ls
exit
docker-compose down

2.5. ચાલો PHPStorm પર પાછા જઈએ અને .env ફાઈલમાં આપણી laravel એપ્લિકેશનનો સાચો રસ્તો સેટ કરીએ.

3. Git માં બધા કોડ ઉમેરો.

આ કરવા માટે, અમે ગીથબ (અથવા બીજે ક્યાંય) પર રીપોઝીટરી બનાવીશું. ચાલો ટર્મિનલમાં habr ડિરેક્ટરી પર જઈએ અને નીચેના કોડને એક્ઝિક્યુટ કરીએ.

echo "# habr-12factor" >> README.md
git init
git add README.md
git commit -m "first commit"
git remote add origin [email protected]:nzulfigarov/habr-12factor.git # здесь будет ссылка на ваш репо
git push -u origin master
git status

ચાલો તપાસીએ કે બધું ક્રમમાં છે કે નહીં.

સગવડ માટે, હું ગિટ માટે કેટલાક વિઝ્યુઅલ ઇન્ટરફેસનો ઉપયોગ કરવાની ભલામણ કરું છું, મારા કિસ્સામાં તે છે ગિટક્રેકન. (અહીં એક રેફરલ લિંક છે)

4. ચાલો લોન્ચ કરીએ!

શરૂ કરતા પહેલા, ખાતરી કરો કે પોર્ટ 80 અને 443 પર કંઈપણ અટકી નથી.

docker-compose up -d nginx php-fpm

આમ, અમારા પ્રોજેક્ટમાં 3 અલગ સેવાઓનો સમાવેશ થાય છે:

• nginx - વેબ સર્વર
• php-fpm - વેબ સર્વર તરફથી વિનંતીઓ પ્રાપ્ત કરવા માટે php
• વર્કસ્પેસ - વિકાસકર્તાઓ માટે php

આ ક્ષણે, અમે હાંસલ કર્યું છે કે અમે એક એપ્લિકેશન બનાવી છે જે 4 માંથી 12 પોઈન્ટને પૂર્ણ કરે છે, એટલે કે:

1. કોડબેઝ — બધા કોડ એક રીપોઝીટરીમાં છે (નાની નોંધ: લારેવેલ પ્રોજેક્ટની અંદર ડોકર ઉમેરવું યોગ્ય હોઈ શકે છે, પરંતુ આ મહત્વપૂર્ણ નથી).

2. અવલંબન - અમારી તમામ અવલંબન અરજી/composer.json અને દરેક કન્ટેનરની દરેક ડોકરફાઈલમાં સ્પષ્ટપણે લખેલી છે.

3. બેકિંગ સેવાઓ — દરેક સેવા (php-fom, nignx, વર્કસ્પેસ) તેનું પોતાનું જીવન જીવે છે અને બહારથી જોડાયેલ છે અને જ્યારે એક સેવા સાથે કામ કરે છે, ત્યારે બીજીને અસર થશે નહીં.

4. પ્રક્રિયાઓ - દરેક સેવા એક પ્રક્રિયા છે. દરેક સેવાઓ આંતરિક સ્થિતિ જાળવી શકતી નથી.

5. પોર્ટ બંધનકર્તા

docker ps

જેમ આપણે જોઈ શકીએ છીએ, દરેક સેવા તેના પોતાના પોર્ટ પર ચાલે છે અને અન્ય તમામ સેવાઓ માટે સુલભ છે.

6. સમન્વય

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

ચાલો કન્ટેનર બંધ કરીએ અને તેમને ધ્વજ દ્વારા ચલાવીએ --સ્કેલ

docker-compose down && 
docker-compose up -d --scale php-fpm=3 nginx php-fpm

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

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

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

9. લોગીંગ — આ કન્ટેનરમાંના તમામ લોગ સ્ટ્રીમમાં જાય છે અને ડોકર કન્સોલમાં દેખાય છે. (આ કિસ્સામાં, હકીકતમાં, અન્ય હોમમેઇડ કન્ટેનર સાથે, જો તમે તેની કાળજી ન લો તો આ કેસ ન હોઈ શકે)

 docker-compose logs -f

પરંતુ તેમાં એક કેચ છે કે PHP અને Nginx માં ડિફોલ્ટ મૂલ્યો પણ ફાઇલમાં લોગ લખે છે. 12 પરિબળોને પહોંચી વળવા માટે, તે જરૂરી છે ડિસ્કનેક્ટ દરેક કન્ટેનરના રૂપરેખાંકનમાં અલગથી ફાઇલમાં લોગ લખવા.

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

10. વહીવટી કાર્યો — 12 ફેક્ટર એપ્લિકેશનના નિર્માતાઓ ઇચ્છે છે તે રીતે કારીગર ટૂલને આભારી તમામ વહીવટી કાર્યો લારાવેલ દ્વારા ઉકેલવામાં આવે છે.

ઉદાહરણ તરીકે, હું બતાવીશ કે કેટલાક આદેશો કેવી રીતે ચલાવવામાં આવે છે.
અમે કન્ટેનરમાં જઈએ છીએ.

 
docker-compose exec workspace bash
php artisan list

હવે આપણે કોઈપણ આદેશનો ઉપયોગ કરી શકીએ છીએ. (કૃપા કરીને નોંધ કરો કે અમે ડેટાબેઝ અને કેશને ગોઠવ્યા નથી, તેથી અડધા આદેશો યોગ્ય રીતે ચલાવવામાં આવશે નહીં, કારણ કે તે કેશ અને ડેટાબેઝ સાથે કામ કરવા માટે રચાયેલ છે).

11. કોન્ફીગ્યુરાસી અને 12. બનાવો, છોડો, ચલાવો

હું આ ભાગ બ્લુ-ગ્રીન ડિપ્લોયમેન્ટને સમર્પિત કરવા માંગતો હતો, પરંતુ તે આ લેખ માટે ખૂબ વ્યાપક હોવાનું બહાર આવ્યું. હું આ વિશે એક અલગ લેખ લખીશ.

ટૂંકમાં, ખ્યાલ CI/CD સિસ્ટમો પર આધારિત છે જેમ કે જેનકિન્સ и Gitlab CI. બંનેમાં, તમે ચોક્કસ પર્યાવરણ સાથે સંકળાયેલ પર્યાવરણ ચલો સેટ કરી શકો છો. તદનુસાર, આ પરિસ્થિતિમાં, બિંદુ c પૂર્ણ થશે રૂપરેખાંકનો.

અને મુદ્દા વિશે બનાવો, છોડો, ચલાવો નામ સાથે બિલ્ટ-ઇન ફંક્શન દ્વારા ઉકેલવામાં આવે છે પાઇપલાઇન.

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

એપ્લિકેશન કોડ પર છે Github.
આ રીપોઝીટરીનું ક્લોનિંગ કરતી વખતે સબમોડ્યુલ શરૂ કરવાનું ભૂલશો નહીં.

PS: આ તમામ અભિગમોનો ઉપયોગ અન્ય કોઈપણ ઉપયોગિતાઓ અને પ્રોગ્રામિંગ ભાષાઓ સાથે થઈ શકે છે. મુખ્ય વસ્તુ એ છે કે સાર અલગ નથી.

સોર્સ: www.habr.com