સતત એકીકરણ માટે ડોકરમાં માઇક્રોસર્વિસિસનું સ્વચાલિત પરીક્ષણ

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

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

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

આ અભિગમનું ઓટોમેશન અસંખ્ય સમસ્યાઓ રજૂ કરે છે, જેનો ઉકેલ નીચે વર્ણવવામાં આવશે:

• સમાન ડોકર હોસ્ટમાં સમાંતર કાર્યોનો સંઘર્ષ;
• પરીક્ષણ પુનરાવર્તન દરમિયાન ડેટાબેઝમાં ઓળખકર્તા તકરાર;
• માઇક્રોસર્વિસિસ તૈયાર થવાની રાહ જોવી;
• બાહ્ય સિસ્ટમોમાં લૉગને મર્જ કરવું અને આઉટપુટ કરવું;
• આઉટગોઇંગ HTTP વિનંતીઓનું પરીક્ષણ;
• વેબ સોકેટ પરીક્ષણ (સિગ્નલઆરનો ઉપયોગ કરીને);
• OAuth પ્રમાણીકરણ અને અધિકૃતતાનું પરીક્ષણ કરી રહ્યું છે.

આ લેખ પર આધારિત છે મારું ભાષણ SECR 2019 પર. તેથી જેઓ વાંચવામાં ખૂબ આળસુ છે તેમના માટે, અહીં ભાષણનું રેકોર્ડિંગ છે.

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

સમાન સ્ક્રિપ્ટ વિકાસકર્તાઓ દ્વારા તેમના Windows ડેસ્કટોપ પર અને Linux હેઠળ Gitlab CI સર્વર બંને દ્વારા ચલાવવામાં આવે છે.

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

નીચેના કારણોસર પરીક્ષણ સ્થાનિક સર્વર પર ચાલવું આવશ્યક છે:

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

વધુમાં, સ્ટેન્ડનો ઉપયોગ કરવો અનિચ્છનીય છે કારણ કે:

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

પ્રોજેક્ટ અને પ્રક્રિયા સંસ્થા વિશે

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

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

પ્રોજેક્ટ આર્કિટેક્ચર

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

SQS અને SNS

SQS તમને સંદેશાઓને કતારમાં મૂકવા અને HTTPS પ્રોટોકોલનો ઉપયોગ કરીને કતારમાંથી સંદેશાઓ વાંચવાની મંજૂરી આપે છે.

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

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

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

API ગેટવે

મોટાભાગની સેવાઓ ઈન્ટરનેટથી સીધી સુલભ નથી. ઍક્સેસ API ગેટવે દ્વારા થાય છે, જે ઍક્સેસ અધિકારો તપાસે છે. આ અમારી સેવા પણ છે, અને તેના માટે પરીક્ષણો પણ છે.

રીઅલ-ટાઇમ સૂચનાઓ

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

જાણીતા પરીક્ષણ અભિગમ

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

В માઈક્રોસોફ્ટ તરફથી લેખ ઇન-મેમરી ડેટાબેઝનો ઉપયોગ કરવાનો અને મોક ઑબ્જેક્ટ્સનો અમલ કરવાનો પ્રસ્તાવ છે.

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

મોક ઑબ્જેક્ટ્સ તે વર્ગનું મોડેલ બનાવે છે જે તેઓ માત્ર એટલી હદે બદલી રહ્યા છે કે ટેસ્ટ ડેવલપર તે કેવી રીતે કાર્ય કરે છે તે સમજે છે.

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

ચાલો ઉકેલ તરફ આગળ વધીએ

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

પરીક્ષણ વાતાવરણ સુયોજિત કરી રહ્યા છીએ

પ્રથમ કાર્ય પરીક્ષણ વાતાવરણ જમાવવાનું છે. માઇક્રોસર્વિસ ચલાવવા માટે જરૂરી પગલાં:

• સ્થાનિક પર્યાવરણ માટે પરીક્ષણ હેઠળ સેવાને ગોઠવો, પર્યાવરણ ચલોમાં ડેટાબેઝ અને AWS સાથે કનેક્ટ કરવા માટેની વિગતોનો ઉલ્લેખ કરો;
• Postgres શરૂ કરો અને Liquibase ચલાવીને સ્થળાંતર કરો.
  રિલેશનલ ડીબીએમએસમાં, ડેટાબેઝમાં ડેટા લખતા પહેલા, તમારે ડેટા સ્કીમા બનાવવાની જરૂર છે, બીજા શબ્દોમાં, કોષ્ટકો. એપ્લિકેશન અપડેટ કરતી વખતે, કોષ્ટકોને નવા સંસ્કરણ દ્વારા ઉપયોગમાં લેવાતા ફોર્મમાં લાવવામાં આવે છે, અને પ્રાધાન્યમાં, ડેટા ગુમાવ્યા વિના. આ સ્થળાંતર કહેવાય છે. શરૂઆતમાં ખાલી ડેટાબેઝમાં કોષ્ટકો બનાવવી એ સ્થળાંતરનો વિશેષ કેસ છે. સ્થળાંતર એપ્લિકેશનમાં જ બનાવી શકાય છે. .NET અને NodeJS બંનેમાં સ્થળાંતર ફ્રેમવર્ક છે. અમારા કિસ્સામાં, સુરક્ષાના કારણોસર, માઇક્રોસર્વિસિસને ડેટા સ્કીમા બદલવાના અધિકારથી વંચિત રાખવામાં આવે છે, અને લિક્વિબેઝનો ઉપયોગ કરીને સ્થળાંતર કરવામાં આવે છે.
• Amazon LocalStack લોંચ કરો. આ ઘર પર ચલાવવા માટે AWS સેવાઓનો અમલ છે. Docker Hub પર LocalStack માટે તૈયાર છબી છે.
• LocalStack માં જરૂરી એકમો બનાવવા માટે સ્ક્રિપ્ટ ચલાવો. શેલ સ્ક્રિપ્ટો AWS CLI નો ઉપયોગ કરે છે.

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

સ્વચાલિત પરીક્ષણ કેવી રીતે કાર્ય કરે છે?

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

ડોકર સંખ્યાબંધ સમસ્યાઓ હલ કરે છે:

• યજમાન રૂપરેખાંકનથી સ્વતંત્રતા;
• અવલંબન સ્થાપિત કરી રહ્યું છે: ડોકર ડોકર હબમાંથી છબીઓ ડાઉનલોડ કરે છે;
• સિસ્ટમને તેની મૂળ સ્થિતિમાં પરત કરવી: ફક્ત કન્ટેનરને દૂર કરવું.

ડોકર-કંપોઝ કન્ટેનરને ઇન્ટરનેટથી અલગ કરીને વર્ચ્યુઅલ નેટવર્કમાં જોડે છે, જેમાં કન્ટેનર ડોમેન નામો દ્વારા એકબીજાને શોધે છે.

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

સ્ક્રિપ્ટ નીચેના પગલાંઓ કરે છે:

• બિલ્ડીંગ ડોકર છબીઓ

  docker-compose build

• ડેટાબેઝ અને LocalStack લોન્ચ કરી રહ્યા છીએ

  docker-compose up -d <контейнер>

• ડેટાબેઝ સ્થળાંતર અને LocalStack ની તૈયારી

  docker-compose run <контейнер>

• પરીક્ષણ હેઠળ સેવા શરૂ કરી રહ્યા છીએ

  docker-compose up -d <сервис>

• પરીક્ષણ ચલાવવું (ન્યુમેન)
• બધા કન્ટેનર રોકે છે

  docker-compose down

• Slack માં પરિણામો પોસ્ટ કરો
  અમારી પાસે એક ચેટ છે જ્યાં લીલા ચેકમાર્ક અથવા લાલ ક્રોસ અને લોગની લિંક સાથેના સંદેશાઓ જાય છે.

નીચેની ડોકર છબીઓ આ પગલાઓમાં સામેલ છે:

• ચકાસાયેલ સેવા ઉત્પાદન માટે સમાન છબી છે. પરીક્ષણ માટેનું રૂપરેખાંકન પર્યાવરણ ચલો દ્વારા છે.
• Postgres, Redis અને LocalStack માટે, Docker Hub માંથી તૈયાર છબીઓનો ઉપયોગ કરવામાં આવે છે. લિક્વિબેઝ અને ન્યુમેન માટે તૈયાર કરેલી છબીઓ પણ છે. અમે તેમના હાડપિંજર પર અમારું નિર્માણ કરીએ છીએ, ત્યાં અમારી ફાઇલો ઉમેરીએ છીએ.
• LocalStack તૈયાર કરવા માટે, તમે તૈયાર AWS CLI ઇમેજનો ઉપયોગ કરો અને તેના આધારે સ્ક્રિપ્ટ ધરાવતી ઇમેજ બનાવો.

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

સમસ્યાઓ તમને આવી શકે છે

તૈયારીની રાહ જોવી

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

આ સમસ્યા ક્યારેક સ્ક્રિપ્ટનો ઉપયોગ કરીને ઉકેલી શકાય છે રાહ જુઓ, જે TCP કનેક્શન સ્થાપિત કરવાની તકની રાહ જુએ છે. જો કે, LocalStack 502 ખરાબ ગેટવે ભૂલ ફેંકી શકે છે. આ ઉપરાંત, તેમાં ઘણી સેવાઓનો સમાવેશ થાય છે, અને જો તેમાંથી એક તૈયાર હોય, તો આ અન્ય વિશે કશું કહેતું નથી.

નિર્ણય: LocalStack પ્રોવિઝનીંગ સ્ક્રિપ્ટો જે SQS અને SNS બંને તરફથી 200 પ્રતિસાદની રાહ જુએ છે.

સમાંતર કાર્ય વિરોધાભાસ

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

નિર્ણય: સ્ક્રિપ્ટ COMPOSE_PROJECT_NAME ચલને અનન્ય મૂલ્ય પર સેટ કરે છે.

વિન્ડોઝ સુવિધાઓ

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

1. કન્ટેનરમાં શેલ સ્ક્રિપ્ટમાં Linux લાઇનના અંત હોવા આવશ્યક છે.
   શેલ CR પ્રતીક એ સિન્ટેક્સ ભૂલ છે. ભૂલ સંદેશામાંથી તે કહેવું મુશ્કેલ છે કે આ કેસ છે. Windows પર આવી સ્ક્રિપ્ટો સંપાદિત કરતી વખતે, તમારે યોગ્ય ટેક્સ્ટ એડિટરની જરૂર છે. વધુમાં, વર્ઝન કંટ્રોલ સિસ્ટમ યોગ્ય રીતે ગોઠવેલી હોવી જોઈએ.

આ રીતે git રૂપરેખાંકિત થયેલ છે:

git config core.autocrlf input

1. Git-bash પ્રમાણભૂત Linux ફોલ્ડર્સનું અનુકરણ કરે છે અને, જ્યારે exe ફાઇલ (docker.exe સહિત) કૉલ કરે છે, ત્યારે Windows પાથ સાથે સંપૂર્ણ Linux પાથને બદલે છે. જો કે, સ્થાનિક મશીન (અથવા કન્ટેનરમાંના પાથ) પર ન હોય તેવા પાથ માટે આનો અર્થ નથી. આ વર્તન અક્ષમ કરી શકાતું નથી.

નિર્ણય: પાથની શરૂઆતમાં વધારાનો સ્લેશ ઉમેરો: /bin ને બદલે //bin. Linux આવા પાથને સમજે છે, તેના માટે ઘણા સ્લેશ એક જેવા જ છે. પરંતુ git-bash આવા પાથને ઓળખતું નથી અને તેમને કન્વર્ટ કરવાનો પ્રયાસ કરતું નથી.

લોગ આઉટપુટ

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

મૂળ ઉકેલ કરવાનો હતો ડોકર-કંપોઝ ધ્વજ નથી -d, પરંતુ શેલ ક્ષમતાઓનો ઉપયોગ કરીને, આ પ્રક્રિયાને પૃષ્ઠભૂમિ પર મોકલો:

docker-compose up <service> &

ડોકરમાંથી તૃતીય-પક્ષ સેવાને લોગ મોકલવા જરૂરી ન હોય ત્યાં સુધી આ કામ કરતું હતું. ડોકર-કંપોઝ કન્સોલ પર લોગ આઉટપુટ કરવાનું બંધ કર્યું. જોકે ટીમે કામ કર્યું હતું ડોકર જોડે છે.

નિર્ણય:

docker attach --no-stdin ${COMPOSE_PROJECT_NAME}_<сервис>_1 &

પરીક્ષણ પુનરાવર્તન દરમિયાન ઓળખકર્તા સંઘર્ષ

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

તેને ટાળવા માટે, ક્યાં તો ID અનન્ય હોવા જોઈએ, અથવા પરીક્ષણ દ્વારા બનાવેલ તમામ ઑબ્જેક્ટ કાઢી નાખવા જોઈએ. અમુક ઑબ્જેક્ટ આવશ્યકતાઓને કારણે કાઢી શકાતા નથી.

નિર્ણય: પોસ્ટમેન સ્ક્રિપ્ટનો ઉપયોગ કરીને GUID જનરેટ કરો.

var uuid = require('uuid');
var myid = uuid.v4();
pm.environment.set('myUUID', myid);

પછી પ્રશ્નમાં પ્રતીકનો ઉપયોગ કરો {{myUUID}}, જે ચલની કિંમત સાથે બદલવામાં આવશે.

LocalStack દ્વારા સહયોગ

જો પરીક્ષણ કરવામાં આવી રહેલી સેવા SQS કતારમાં વાંચે છે અથવા લખે છે, તો આને ચકાસવા માટે, પરીક્ષણ પોતે પણ આ કતાર સાથે કામ કરે છે.

નિર્ણય: પોસ્ટમેનથી લોકલસ્ટેક માટે વિનંતીઓ.

AWS સેવાઓ API દસ્તાવેજીકૃત છે, જે SDK વગર ક્વેરી કરવાની મંજૂરી આપે છે.

જો કોઈ સેવા કતારમાં લખે છે, તો અમે તેને વાંચીએ છીએ અને સંદેશની સામગ્રી તપાસીએ છીએ.

જો સેવા SNS ને સંદેશા મોકલે છે, તો તૈયારીના તબક્કે LocalStack પણ એક કતાર બનાવે છે અને આ SNS વિષય પર સબ્સ્ક્રાઇબ કરે છે. પછી તે બધા ઉપર વર્ણવેલ છે તે નીચે આવે છે.

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

પરીક્ષણ હેઠળ માઇક્રોસર્વિસમાંથી ઉદ્દભવતી HTTP વિનંતીઓનું પરીક્ષણ કરવું

કેટલીક સેવાઓ HTTP પર AWS સિવાય અન્ય કોઈ વસ્તુ સાથે કામ કરે છે, અને કેટલીક AWS સુવિધાઓ LocalStack માં લાગુ કરવામાં આવતી નથી.

નિર્ણય: આ કિસ્સાઓમાં તે મદદ કરી શકે છે મોકસર્વર, જેમાં તૈયાર છબી છે ડોકર હબ. અપેક્ષિત વિનંતીઓ અને તેમને પ્રતિસાદ HTTP વિનંતી દ્વારા ગોઠવવામાં આવે છે. API દસ્તાવેજીકૃત છે, તેથી અમે પોસ્ટમેન પાસેથી વિનંતીઓ કરીએ છીએ.

OAuth પ્રમાણીકરણ અને અધિકૃતતાનું પરીક્ષણ

અમે OAuth નો ઉપયોગ કરીએ છીએ અને JSON વેબ ટોકન્સ (JWT). પરીક્ષણ માટે OAuth પ્રદાતાની જરૂર છે જે અમે સ્થાનિક રીતે ચલાવી શકીએ.

સેવા અને OAuth પ્રદાતા વચ્ચેની તમામ ક્રિયાપ્રતિક્રિયા બે વિનંતીઓ પર આવે છે: પ્રથમ, ગોઠવણીની વિનંતી કરવામાં આવે છે /.well-known/openid-configuration, અને પછી રૂપરેખાંકનમાંથી સરનામાં પર જાહેર કી (JWKS) ની વિનંતી કરવામાં આવે છે. આ બધું સ્થિર સામગ્રી છે.

નિર્ણય: અમારું પરીક્ષણ OAuth પ્રદાતા એ એક સ્થિર સામગ્રી સર્વર છે અને તેના પર બે ફાઇલો છે. ટોકન એકવાર જનરેટ થાય છે અને Git માટે પ્રતિબદ્ધ છે.

સિગ્નલઆર પરીક્ષણની વિશેષતાઓ

પોસ્ટમેન વેબસોકેટ્સ સાથે કામ કરતું નથી. સિગ્નલઆર ચકાસવા માટે એક ખાસ સાધન બનાવવામાં આવ્યું હતું.

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

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

બહુવિધ ક્લાયંટ ચલાવવા માટે વિકલ્પનો ઉપયોગ કરો --સ્કેલ ડોકર-કંપોઝ કમાન્ડ લાઇન પર.

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

નિર્ણય: કન્ટેનરમાંનો ક્લાયન્ટ મિકેનિઝમનો ઉપયોગ કરે છે સ્વાસ્થ્ય તપાસહોસ્ટ પર સ્ક્રિપ્ટને તેની સ્થિતિ વિશે જાણ કરવા. ક્લાયંટ ચોક્કસ પાથ પર ફાઇલ બનાવે છે, જેમ કે કનેક્શન સ્થાપિત થાય કે તરત જ /હેલ્થચેક. ડોકર ફાઇલમાં હેલ્થચેક સ્ક્રિપ્ટ આના જેવી દેખાય છે:

HEALTHCHECK --interval=3s CMD if [ ! -e /healthcheck ]; then false; fi

ટીમ ડોકર તપાસ કરે છે કન્ટેનર માટે સામાન્ય સ્થિતિ, આરોગ્ય સ્થિતિ અને એક્ઝિટ કોડ બતાવે છે.

ન્યૂમેન પૂર્ણ થયા પછી, સ્ક્રિપ્ટ તપાસે છે કે ક્લાયંટ સાથેના તમામ કન્ટેનર કોડ 0 સાથે સમાપ્ત થઈ ગયા છે.

હેપીનેસ અસ્તિત્વમાં છે

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

આ પરીક્ષણો 30+ વિકાસકર્તાઓની ટીમને વારંવાર જમાવટ સાથે 10+ માઇક્રોસર્વિસિસની જટિલ ક્રિયાપ્રતિક્રિયા સાથે એપ્લિકેશનમાં ભૂલોથી સુરક્ષિત કરે છે.

સોર્સ: www.habr.com