निरन्तर एकीकरणको लागि डकरमा माइक्रो सेवाहरूको स्वचालित परीक्षण

माइक्रोसर्भिस आर्किटेक्चरको विकाससँग सम्बन्धित परियोजनाहरूमा, CI/CD एक सुखद अवसरको श्रेणीबाट अत्यावश्यक आवश्यकताको श्रेणीमा सर्छ। स्वचालित परीक्षण निरन्तर एकीकरणको अभिन्न अंग हो, एक सक्षम दृष्टिकोण जसले टोलीलाई परिवार र साथीहरूसँग धेरै रमाइलो साँझ दिन सक्छ। अन्यथा, परियोजना कहिल्यै पूरा नहुने जोखिम छ।

सम्पूर्ण माइक्रोसर्भिस कोडलाई नक्कली वस्तुहरूको साथ एकाइ परीक्षणको साथ कभर गर्न सम्भव छ, तर यसले आंशिक रूपमा समस्या समाधान गर्छ र धेरै प्रश्नहरू र कठिनाइहरू छोड्छ, विशेष गरी डाटासँग कामको परीक्षण गर्दा। सँधै जस्तै, सबैभन्दा थिच्नेहरू रिलेसनल डाटाबेसमा डाटा स्थिरता परीक्षण गर्दै छन्, क्लाउड सेवाहरूसँग कामको परीक्षण गर्दै, र नक्कली वस्तुहरू लेख्दा गलत धारणाहरू बनाउँदै।

यो सबै र अलि बढी डकर कन्टेनरमा सम्पूर्ण माइक्रोसर्भिस परीक्षण गरेर समाधान गर्न सकिन्छ। परीक्षणहरूको वैधता सुनिश्चित गर्नको लागि निस्सन्देह फाइदा भनेको उत्पादनमा जाने उही डकर छविहरू परीक्षण गरिन्छ।

यस दृष्टिकोणको स्वचालनले धेरै समस्याहरू प्रस्तुत गर्दछ, जसको समाधान तल वर्णन गरिनेछ:

• समान डकर होस्टमा समानान्तर कार्यहरूको द्वन्द्व;
• परीक्षण पुनरावृत्तिको समयमा डेटाबेसमा पहिचानकर्ता विवादहरू;
• माइक्रो सेवाहरू तयार हुनको लागि पर्खँदै;
• बाह्य प्रणालीहरूमा लगहरू मर्ज र आउटपुट गर्दै;
• बाहिर जाने HTTP अनुरोधहरू परीक्षण गर्दै;
• वेब सकेट परीक्षण (सिग्नलआर प्रयोग गरेर);
• OAuth प्रमाणीकरण र प्राधिकरण परीक्षण।

यो लेख आधारित छ मेरो बोली SECR 2019 मा। त्यसैले पढ्न धेरै अल्छी भएकाहरूका लागि, यहाँ भाषणको रेकर्डिङ छ.

यस लेखमा म तपाइँलाई कसरी परीक्षण अन्तर्गत सेवा चलाउनको लागि स्क्रिप्ट प्रयोग गर्ने भनेर बताउनेछु, डकरमा डाटाबेस र अमेजन AWS सेवाहरू, त्यसपछि पोस्टम्यानमा परीक्षणहरू र, तिनीहरू पूरा भएपछि, सिर्जना गरिएका कन्टेनरहरू रोक्नुहोस् र मेटाउनुहोस्। प्रत्येक पटक कोड परिवर्तन गर्दा परीक्षणहरू कार्यान्वयन गरिन्छ। यसरी, हामी सुनिश्चित गर्छौं कि प्रत्येक संस्करण AWS डाटाबेस र सेवाहरूसँग सही रूपमा काम गर्दछ।

एउटै स्क्रिप्ट दुबै विकासकर्ताहरूद्वारा तिनीहरूको विन्डोज डेस्कटपहरूमा र लिनक्स अन्तर्गत Gitlab CI सर्भरद्वारा चलाइएको छ।

न्यायोचित हुनको लागि, नयाँ परीक्षणहरू प्रस्तुत गर्नका लागि विकासकर्ताको कम्प्युटर वा सर्भरमा जहाँ परीक्षणहरू कमिटमा चलाइन्छ, थप उपकरणहरूको स्थापना आवश्यक पर्दैन। डकरले यो समस्या समाधान गर्दछ।

निम्न कारणहरूको लागि परीक्षण स्थानीय सर्भरमा चल्नु पर्छ:

• नेटवर्क कहिल्यै पूर्ण रूपमा विश्वसनीय हुँदैन। हजार अनुरोधहरू मध्ये, एक असफल हुन सक्छ;
  यस अवस्थामा, स्वचालित परीक्षणले काम गर्दैन, काम रोकिनेछ, र तपाईंले लगहरूमा कारण खोज्नुपर्नेछ;
• केहि तेस्रो-पक्ष सेवाहरू द्वारा धेरै बारम्बार अनुरोधहरूलाई अनुमति छैन।

थप रूपमा, स्ट्यान्ड प्रयोग गर्न अवांछनीय छ किनभने:

• एउटा स्ट्यान्डलाई खराब कोडले मात्र नभई सही कोडले प्रशोधन गर्न नसक्ने डेटाद्वारा पनि भाँच्न सकिन्छ;
• हामीले परीक्षणको क्रममा परीक्षणद्वारा गरिएका सबै परिवर्तनहरू फिर्ता गर्न जतिसुकै कडा प्रयास गरे पनि, केहि गलत हुन सक्छ (अन्यथा, किन परीक्षण?)।

परियोजना र प्रक्रिया संगठन बारे

हाम्रो कम्पनीले Amazon AWS क्लाउडमा डकरमा चलिरहेको माइक्रोसर्भिस वेब अनुप्रयोग विकास गरेको छ। एकाइ परीक्षणहरू परियोजनामा ​​पहिले नै प्रयोग गरिएको थियो, तर त्रुटिहरू प्रायः देखा पर्यो कि एकाइ परीक्षणहरूले पत्ता लगाएनन्। डाटाबेस र अमेजन सेवाहरूको साथमा सम्पूर्ण माइक्रोसर्भिस परीक्षण गर्न आवश्यक थियो।

परियोजनाले मानक निरन्तर एकीकरण प्रक्रिया प्रयोग गर्दछ, जसमा प्रत्येक प्रतिबद्धताको साथ माइक्रोसर्भिसको परीक्षण समावेश छ। कार्य तोकेपछि, विकासकर्ताले माइक्रोसर्भिसमा परिवर्तनहरू गर्छ, यसलाई म्यानुअल रूपमा परीक्षण गर्छ र उपलब्ध सबै स्वचालित परीक्षणहरू चलाउँछ। आवश्यक भएमा, विकासकर्ताले परीक्षणहरू परिवर्तन गर्दछ। यदि कुनै समस्याहरू फेला परेन भने, यस मुद्दाको शाखामा एक प्रतिबद्धता बनाइन्छ। प्रत्येक प्रतिबद्धता पछि, परीक्षणहरू स्वचालित रूपमा सर्भरमा चलाइन्छ। साझा शाखामा मर्ज गर्ने र यसमा स्वचालित परीक्षणहरू सुरु गर्ने सफल समीक्षा पछि हुन्छ। यदि साझा शाखामा परीक्षणहरू पास भएमा, अमेजन इलास्टिक कन्टेनर सेवा (बेन्च) मा परीक्षण वातावरणमा सेवा स्वचालित रूपमा अद्यावधिक हुन्छ। स्ट्यान्ड सबै विकासकर्ताहरू र परीक्षकहरूको लागि आवश्यक छ, र यसलाई तोड्न उचित छैन। यस वातावरणमा परीक्षकहरूले म्यानुअल परीक्षणहरू प्रदर्शन गरेर फिक्स वा नयाँ सुविधा जाँच गर्छन्।

परियोजना वास्तुकला

अनुप्रयोगमा दस भन्दा बढी सेवाहरू छन्। ती मध्ये केही .NET Core मा र केहि NodeJs मा लेखिएका छन्। प्रत्येक सेवा अमेजन लोचदार कन्टेनर सेवामा डकर कन्टेनरमा चल्छ। प्रत्येकको आफ्नै Postgres डाटाबेस छ, र केहि पनि Redis छ। त्यहाँ कुनै साझा डेटाबेस छैन। यदि धेरै सेवाहरूलाई एउटै डाटा चाहिन्छ भने, तब यो डाटा, जब यो परिवर्तन हुन्छ, यी प्रत्येक सेवाहरूमा SNS (Simple Notification Service) र SQS (Amazon Simple Queue Service), र सेवाहरूले यसलाई आफ्नै छुट्टै डाटाबेसमा सुरक्षित गर्दछ।

SQS र SNS

SQS ले तपाईंलाई सन्देशहरूलाई लाममा राख्न र HTTPS प्रोटोकल प्रयोग गरेर लामबाट सन्देशहरू पढ्न अनुमति दिन्छ।

यदि धेरै सेवाहरूले एउटै लाम पढ्छन् भने, त्यसपछि प्रत्येक सन्देश तिनीहरूमध्ये एकमा मात्र पुग्छ। तिनीहरू बीच लोड वितरण गर्न एउटै सेवाको धेरै उदाहरणहरू चलाउँदा यो उपयोगी छ।

यदि तपाइँ प्रत्येक सन्देश धेरै सेवाहरूमा डेलिभर गर्न चाहनुहुन्छ भने, प्रत्येक प्राप्तकर्ताको आफ्नै लाम हुनुपर्छ, र धेरै लामहरूमा सन्देशहरू डुप्लिकेट गर्न SNS आवश्यक छ।

SNS मा तपाइँ एउटा विषय सिर्जना गर्नुहुन्छ र यसको सदस्यता लिनुहुन्छ, उदाहरणका लागि, SQS लाम। तपाईं विषय सन्देश पठाउन सक्नुहुन्छ। यस अवस्थामा, सन्देश यस विषयमा सदस्यता लिएको प्रत्येक लाममा पठाइन्छ। SNS सँग सन्देशहरू पढ्ने विधि छैन। यदि डिबगिङ वा परीक्षणको क्रममा तपाईंले SNS मा के पठाइएको छ भनेर पत्ता लगाउन आवश्यक छ भने, तपाईंले SQS लाम सिर्जना गर्न सक्नुहुन्छ, इच्छित शीर्षकमा सदस्यता लिनुहोस् र लाम पढ्न सक्नुहुन्छ।

API गेटवे

अधिकांश सेवाहरू इन्टरनेटबाट प्रत्यक्ष रूपमा पहुँचयोग्य छैनन्। पहुँच API गेटवे मार्फत हुन्छ, जसले पहुँच अधिकारहरू जाँच गर्दछ। यो हाम्रो सेवा पनि हो, र यसको लागि परीक्षणहरू पनि छन्।

वास्तविक समय सूचनाहरू

अनुप्रयोग प्रयोग गर्दछ सिग्नल आरप्रयोगकर्तालाई वास्तविक समय सूचनाहरू देखाउन। यो सूचना सेवा मा लागू गरिएको छ। यो इन्टरनेटबाट सिधै पहुँचयोग्य छ र आफैले OAuth सँग काम गर्दछ, किनभने यो OAuth र सूचना सेवालाई एकीकृत गर्ने तुलनामा, गेटवेमा वेब सकेटहरूको लागि समर्थन निर्माण गर्न अव्यावहारिक भयो।

प्रख्यात परीक्षण दृष्टिकोण

एकाइ परीक्षणहरूले डाटाबेस जस्ता चीजहरूलाई नक्कली वस्तुहरूसँग प्रतिस्थापन गर्दछ। यदि माइक्रोसर्भिस, उदाहरणका लागि, विदेशी कुञ्जीसँग तालिकामा रेकर्ड सिर्जना गर्ने प्रयास गर्छ, र त्यो कुञ्जीद्वारा सन्दर्भ गरिएको रेकर्ड अवस्थित छैन भने, अनुरोध पूरा गर्न सकिँदैन। एकाइ परीक्षणहरूले यो पत्ता लगाउन सक्दैन।

В Microsoft बाट लेख यो इन-मेमोरी डाटाबेस प्रयोग गर्न र नक्कली वस्तुहरू लागू गर्न प्रस्ताव गरिएको छ।

इन-मेमोरी डाटाबेस निकाय फ्रेमवर्क द्वारा समर्थित DBMS हरू मध्ये एक हो। यो विशेष गरी परीक्षणको लागि सिर्जना गरिएको थियो। यस्तो डाटाबेसमा डाटा भण्डारण गरिन्छ जबसम्म यसलाई प्रयोग गर्ने प्रक्रिया समाप्त हुँदैन। यसले तालिकाहरू सिर्जना गर्न आवश्यक पर्दैन र डेटा अखण्डता जाँच गर्दैन।

नक्कली वस्तुहरूले तिनीहरूले प्रतिस्थापन गर्ने वर्गलाई परीक्षण विकासकर्ताले कसरी काम गर्छ भन्ने बुझेको हदसम्म मोडेल गर्छन्।

कसरी पोस्टग्रेस प्राप्त गर्ने स्वचालित रूपमा सुरु गर्न र माइग्रेसनहरू प्रदर्शन गर्दा परीक्षण चलाउँदा Microsoft लेखमा निर्दिष्ट गरिएको छैन। मेरो समाधानले यो गर्छ र यसको अतिरिक्त, माइक्रोसर्भिसमा परीक्षणको लागि विशेष रूपमा कुनै कोड थप्दैन।

समाधानतिर लागौं

विकास प्रक्रियाको क्रममा, यो स्पष्ट भयो कि एकाइ परीक्षणहरू समयमै सबै समस्याहरू पत्ता लगाउन पर्याप्त थिएनन्, त्यसैले यो मुद्दालाई फरक कोणबाट हेर्ने निर्णय गरियो।

परीक्षण वातावरण सेट अप गर्दै

पहिलो काम भनेको परीक्षण वातावरण निर्माण गर्नु हो। माइक्रो सर्भिस चलाउन आवश्यक चरणहरू:

• स्थानीय वातावरणको लागि परीक्षण अन्तर्गत सेवा कन्फिगर गर्नुहोस्, डाटाबेस र वातावरण चरहरूमा AWS जडान गर्नका लागि विवरणहरू निर्दिष्ट गर्नुहोस्;
• Postgres सुरु गर्नुहोस् र Liquibase चलाएर माइग्रेसन गर्नुहोस्।
  रिलेशनल DBMSs मा, डाटाबेसमा डाटा लेख्नु अघि, तपाईंले डाटा स्कीमा सिर्जना गर्न आवश्यक छ, अन्य शब्दहरूमा, तालिकाहरू। एप्लिकेसन अपडेट गर्दा, तालिकाहरू नयाँ संस्करणले प्रयोग गरेको फारममा ल्याइनुपर्छ, र, प्राथमिकतामा, डाटा नगुमाईकन। यसलाई प्रवास भनिन्छ। प्रारम्भिक रूपमा खाली डाटाबेसमा तालिकाहरू सिर्जना गर्नु माइग्रेसनको विशेष मामला हो। माइग्रेसन अनुप्रयोगमा निर्माण गर्न सकिन्छ। .NET र NodeJS दुवै माइग्रेसन फ्रेमवर्कहरू छन्। हाम्रो अवस्थामा, सुरक्षा कारणहरूका लागि, माइक्रोसर्भिसेसहरू डेटा स्किमा परिवर्तन गर्ने अधिकारबाट वञ्चित छन्, र माइग्रेसन Liquibase प्रयोग गरी गरिन्छ।
• Amazon LocalStack सुरु गर्नुहोस्। यो घरमा चलाउनको लागि AWS सेवाहरूको कार्यान्वयन हो। त्यहाँ डकर हबमा LocalStack को लागि तयार-निर्मित छवि छ।
• LocalStack मा आवश्यक संस्थाहरू सिर्जना गर्न स्क्रिप्ट चलाउनुहोस्। शेल स्क्रिप्टहरूले AWS CLI प्रयोग गर्दछ।

परियोजनामा ​​परीक्षणको लागि प्रयोग गरियो हुलाकी। यो पहिले अवस्थित थियो, तर यो म्यानुअल रूपमा सुरू गरिएको थियो र स्ट्यान्डमा पहिले नै तैनाथ गरिएको अनुप्रयोगको परीक्षण गरियो। यो उपकरणले तपाईंलाई मनमानी HTTP(S) अनुरोधहरू गर्न र प्रतिक्रियाहरू अपेक्षाहरूसँग मेल खान्छ कि भनेर जाँच गर्न अनुमति दिन्छ। प्रश्नहरू सङ्कलनमा जोडिएका छन्, र सम्पूर्ण सङ्ग्रह चलाउन सकिन्छ।

स्वचालित परीक्षण कसरी काम गर्छ?

परीक्षणको क्रममा, सबै कुरा डकरमा काम गर्दछ: परीक्षण अन्तर्गत सेवा, पोस्टग्रेस, माइग्रेसन उपकरण, र पोस्टम्यान, वा यसको कन्सोल संस्करण - न्यूम्यान।

डकरले धेरै समस्याहरू समाधान गर्दछ:

• होस्ट कन्फिगरेसनबाट स्वतन्त्रता;
• निर्भरताहरू स्थापना गर्दै: डकरले डकर हबबाट छविहरू डाउनलोड गर्दछ;
• प्रणालीलाई यसको मूल अवस्थामा फर्काउँदै: केवल कन्टेनरहरू हटाउँदै।

डकर - रचना कन्टेनरहरूलाई एक भर्चुअल नेटवर्कमा एकताबद्ध गर्दछ, इन्टरनेटबाट अलग, जसमा कन्टेनरहरूले डोमेन नामहरूद्वारा एकअर्कालाई भेट्टाउँछन्।

परीक्षण शेल लिपि द्वारा नियन्त्रित छ। Windows मा परीक्षण चलाउन हामी git-bash प्रयोग गर्छौं। यसरी, विन्डोज र लिनक्स दुवैको लागि एउटै स्क्रिप्ट पर्याप्त छ। Git र Docker परियोजना मा सबै विकासकर्ता द्वारा स्थापित छन्। विन्डोजमा Git स्थापना गर्दा, git-bash स्थापना हुन्छ, त्यसैले सबैसँग त्यो पनि हुन्छ।

लिपिले निम्न चरणहरू प्रदर्शन गर्दछ:

• डकर छविहरू निर्माण गर्दै

  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 बाट तयार तस्बिरहरू प्रयोग गरिन्छ। त्यहाँ Liquibase र Newman को लागि तयार तस्बिरहरू पनि छन्। हामी तिनीहरूको कंकालमा हाम्रो निर्माण गर्छौं, त्यहाँ हाम्रा फाइलहरू थप्छौं।
• LocalStack तयार गर्न, तपाईंले तयार AWS CLI छवि प्रयोग गर्नुहोस् र त्यसमा आधारित स्क्रिप्ट भएको छवि सिर्जना गर्नुहोस्।

प्रयोग गर्दै भोल्युमहरू, तपाईंले कन्टेनरमा फाइलहरू थप्नको लागि डकर छवि निर्माण गर्नुपर्दैन। यद्यपि, भोल्युमहरू हाम्रो वातावरणको लागि उपयुक्त छैनन् किनभने Gitlab CI कार्यहरू आफैं कन्टेनरहरूमा चल्छन्। तपाईंले यस्तो कन्टेनरबाट डकर नियन्त्रण गर्न सक्नुहुन्छ, तर भोल्युमहरूले होस्ट प्रणालीबाट फोल्डरहरू मात्र माउन्ट गर्दछ, र अर्को कन्टेनरबाट होइन।

तपाईंले सामना गर्न सक्ने समस्याहरू

तयारीको प्रतिक्षामा

जब सेवा भएको कन्टेनर चलिरहेको छ, यसको मतलब यो जडानहरू स्वीकार गर्न तयार छ भन्ने होइन। तपाईंले जडान जारी राख्नको लागि कुर्नु पर्छ।

यो समस्या कहिलेकाहीँ स्क्रिप्ट प्रयोग गरेर हल गरिन्छ पर्खनुहोस्, जसले TCP जडान स्थापना गर्ने अवसरको लागि पर्खिरहेको छ। यद्यपि, LocalStack ले 502 खराब गेटवे त्रुटि फाल्न सक्छ। थप रूपमा, यसमा धेरै सेवाहरू समावेश छन्, र यदि तिनीहरू मध्ये एक तयार छ भने, यसले अरूको बारेमा केही बोल्दैन।

निर्णय: LocalStack प्रावधान स्क्रिप्टहरू जुन SQS र SNS दुवैबाट 200 प्रतिक्रियाको लागि पर्खन्छ।

समानान्तर कार्य द्वन्द्वहरू

धेरै परीक्षणहरू एउटै डकर होस्टमा एकैसाथ चल्न सक्छन्, त्यसैले कन्टेनर र नेटवर्क नामहरू अद्वितीय हुनुपर्छ। यसबाहेक, एउटै सेवाका विभिन्न शाखाहरूबाट परीक्षणहरू पनि एकैसाथ चल्न सक्छन्, त्यसैले प्रत्येक रचना फाइलमा तिनीहरूको नाम लेख्न पर्याप्त छैन।

निर्णय: स्क्रिप्टले COMPOSE_PROJECT_NAME चरलाई अद्वितीय मानमा सेट गर्छ।

विन्डोज सुविधाहरू

त्यहाँ धेरै चीजहरू छन् जुन म विन्डोजमा डकर प्रयोग गर्दा औंल्याउन चाहन्छु, किनकि त्रुटिहरू किन देखा पर्दछ भनेर बुझ्नको लागि यी अनुभवहरू महत्त्वपूर्ण छन्।

1. कन्टेनरमा शेल स्क्रिप्टहरू लिनक्स लाइनको अन्त्य हुनुपर्छ।
   शेल CR प्रतीक वाक्यविन्यास त्रुटि हो। त्रुटि सन्देशबाट यो कुरा हो भनेर भन्न गाह्रो छ। Windows मा त्यस्ता स्क्रिप्टहरू सम्पादन गर्दा, तपाईंलाई उचित पाठ सम्पादक चाहिन्छ। थप रूपमा, संस्करण नियन्त्रण प्रणाली ठीकसँग कन्फिगर हुनुपर्छ।

यो कसरी git कन्फिगर गरिएको छ:

git config core.autocrlf input

1. Git-bash ले मानक लिनक्स फोल्डरहरू अनुकरण गर्दछ र, exe फाइल (docker.exe सहित) कल गर्दा, Windows पथहरूसँग निरपेक्ष लिनक्स पथहरू प्रतिस्थापन गर्दछ। यद्यपि, यसले स्थानीय मेसिन (वा कन्टेनरमा पथहरू) मा नभएका मार्गहरूको लागि अर्थ राख्दैन। यो व्यवहार असक्षम हुन सक्दैन।

निर्णय: पथको सुरुमा थप स्ल्याश थप्नुहोस्: //bin को सट्टा //bin। लिनक्सले त्यस्ता मार्गहरू बुझ्दछ; यसको लागि, धेरै स्ल्याशहरू एउटै हुन्। तर git-bash ले त्यस्ता मार्गहरू पहिचान गर्दैन र तिनीहरूलाई रूपान्तरण गर्ने प्रयास गर्दैन।

लग आउटपुट

परीक्षणहरू चलाउँदा, म न्युम्यान र सेवा परीक्षण भइरहेको दुवैबाट लगहरू हेर्न चाहन्छु। यी लगहरूको घटनाहरू आपसमा जोडिएको हुनाले, तिनीहरूलाई एक कन्सोलमा संयोजन गर्न दुई अलग फाइलहरू भन्दा धेरै सुविधाजनक छ। Newman मार्फत सुरु हुन्छ डकर-कम्पोज रन, र त्यसैले यसको आउटपुट कन्सोलमा समाप्त हुन्छ। सेवाको आउटपुट पनि त्यहाँ जान्छ भनेर सुनिश्चित गर्न बाँकी रहेको छ।

मौलिक समाधान गर्ने नै थियो डककर-रचना गर्नुहोस् झण्डा छैन -d, तर शेल क्षमताहरू प्रयोग गरेर, यो प्रक्रियालाई पृष्ठभूमिमा पठाउनुहोस्:

docker-compose up <service> &

डकरबाट तेस्रो-पक्ष सेवामा लगहरू पठाउन आवश्यक नभएसम्म यसले काम गर्‍यो। डककर-रचना गर्नुहोस् कन्सोलमा लगहरू आउटपुट गर्न रोकियो। तर, टोलीले काम गर्यो डकर संलग्न.

निर्णय:

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

परीक्षण पुनरावृत्तिको समयमा पहिचानकर्ता विवाद

परीक्षणहरू धेरै पुनरावृत्तिहरूमा चलाइन्छ। डाटाबेस खाली छैन। डाटाबेसमा रेकर्डहरू अद्वितीय आईडीहरू छन्। यदि हामीले अनुरोधहरूमा निर्दिष्ट आईडीहरू लेख्यौं भने, हामीले दोस्रो पुनरावृत्तिमा द्वन्द्व प्राप्त गर्नेछौं।

यसबाट बच्नको लागि, या त आईडीहरू अद्वितीय हुनुपर्छ, वा परीक्षणद्वारा सिर्जना गरिएका सबै वस्तुहरू मेटाइनुपर्छ। केही वस्तुहरू आवश्यकताहरूको कारणले मेटाउन सकिँदैन।

निर्णय: पोस्टम्यान लिपिहरू प्रयोग गरेर 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 मा लागू गरिएको छैन।

निर्णय: यी अवस्थामा यसले मद्दत गर्न सक्छ MockServer, जसमा रेडिमेड छवि छ डकर हब। अपेक्षित अनुरोधहरू र तिनीहरूका प्रतिक्रियाहरू HTTP अनुरोधद्वारा कन्फिगर गरिएका छन्। API कागजात गरिएको छ, त्यसैले हामी पोस्टम्यानबाट अनुरोधहरू गर्छौं।

OAuth प्रमाणीकरण र प्राधिकरण परीक्षण

हामी OAuth र प्रयोग गर्दछौं JSON वेब टोकन (JWT)। परीक्षणको लागि हामीले स्थानीय रूपमा चलाउन सक्ने OAuth प्रदायक चाहिन्छ।

सेवा र OAuth प्रदायक बीचको सबै अन्तरक्रिया दुई अनुरोधहरूमा आउँछ: पहिलो, कन्फिगरेसन अनुरोध गरिएको छ। /.well-known/openid-configuration, र त्यसपछि सार्वजनिक कुञ्जी (JWKS) कन्फिगरेसनबाट ठेगानामा अनुरोध गरिएको छ। यो सबै स्थिर सामग्री हो।

निर्णय: हाम्रो परीक्षण OAuth प्रदायक एक स्थिर सामग्री सर्भर र यसमा दुई फाइलहरू छन्। टोकन एक पटक उत्पन्न हुन्छ र Git मा प्रतिबद्ध छ।

SignalR परीक्षण को विशेषताहरु

पोस्टम्यानले वेबसकेटहरूसँग काम गर्दैन। SignalR परीक्षण गर्न एक विशेष उपकरण सिर्जना गरिएको थियो।

सिग्नलआर क्लाइन्ट केवल ब्राउजर भन्दा बढी हुन सक्छ। .NET कोर अन्तर्गत यसको लागि ग्राहक पुस्तकालय छ। .NET Core मा लेखिएको क्लाइन्टले जडान स्थापना गर्छ, प्रमाणीकरण गर्छ, र सन्देशहरूको निश्चित अनुक्रमको लागि पर्खन्छ। यदि अप्रत्याशित सन्देश प्राप्त भयो वा जडान हरायो भने, ग्राहक 1 को कोडको साथ बाहिर निस्कन्छ। यदि अन्तिम अपेक्षित सन्देश प्राप्त भयो भने, ग्राहक 0 को कोडको साथ बाहिर निस्कन्छ।

Newman ग्राहक संग एक साथ काम गर्दछ। धेरै ग्राहकहरूलाई सन्देशहरू आवश्यक पर्ने सबैलाई डेलिभर गरिएको छ भनी जाँच गर्न सुरु गरिएको छ।

धेरै ग्राहकहरू चलाउन विकल्प प्रयोग गर्नुहोस् -- मापन डकर-कम्पोज कमाण्ड लाइनमा।

चल्नु अघि, पोस्टम्यान स्क्रिप्टले जडानहरू स्थापना गर्न सबै ग्राहकहरूको लागि पर्खन्छ।
हामीले पहिले नै जडानको लागि पर्खने समस्याको सामना गरिसकेका छौं। तर त्यहाँ सर्भरहरू थिए, र यहाँ ग्राहक छ। फरक दृष्टिकोण चाहिन्छ।

निर्णय: कन्टेनरमा ग्राहकले मेकानिज्म प्रयोग गर्दछ स्वास्थ्य जाँचहोस्टमा लिपिलाई यसको स्थिति बारे जानकारी गराउन। क्लाइन्टले एक विशेष मार्गमा फाइल सिर्जना गर्दछ, भन्नुहोस् /हेल्थचेक, जडान स्थापित हुने बित्तिकै। डकर फाइलमा HealthCheck स्क्रिप्ट यस्तो देखिन्छ:

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

टोली डकर निरीक्षण कन्टेनरको लागि सामान्य स्थिति, स्वास्थ्य स्थिति र बाहिर निस्कने कोड देखाउँछ।

न्यूम्यानले पूरा गरेपछि, स्क्रिप्टले कोड ० को साथ, क्लाइन्टसँग भएका सबै कन्टेनरहरू समाप्त भएको जाँच गर्दछ।

Happinnes अवस्थित छ

हामीले माथि वर्णन गरिएका कठिनाइहरू पार गरेपछि, हामीसँग स्थिर चलिरहेको परीक्षणहरूको सेट थियो। परीक्षणहरूमा, प्रत्येक सेवाले एकल इकाईको रूपमा काम गर्दछ, डाटाबेस र Amazon LocalStack सँग अन्तरक्रिया गर्दै।

यी परीक्षणहरूले 30+ विकासकर्ताहरूको टोलीलाई एप्लिकेसनमा त्रुटिहरूबाट 10+ माइक्रोसर्भिसेसहरूको जटिल अन्तरक्रियाको साथ बारम्बार तैनातीहरूबाट जोगाउँछ।

स्रोत: www.habr.com