सतत एकत्रीकरणासाठी डॉकरमधील मायक्रोसर्व्हिसेसची स्वयंचलित चाचणी

मायक्रोसर्व्हिस आर्किटेक्चरच्या विकासाशी संबंधित प्रकल्पांमध्ये, सीआय/सीडी आनंददायी संधीच्या श्रेणीतून तातडीच्या गरजेच्या श्रेणीकडे सरकते. स्वयंचलित चाचणी हा सतत एकात्मतेचा अविभाज्य भाग आहे, एक सक्षम दृष्टीकोन ज्यामुळे संघाला कुटुंब आणि मित्रांसह अनेक आनंददायी संध्याकाळ मिळू शकतात. अन्यथा, प्रकल्प कधीही पूर्ण होण्याचा धोका नाही.

मॉक ऑब्जेक्ट्ससह युनिट चाचण्यांसह संपूर्ण मायक्रोसर्व्हिस कोड कव्हर करणे शक्य आहे, परंतु हे केवळ अंशतः समस्येचे निराकरण करते आणि बरेच प्रश्न आणि अडचणी सोडते, विशेषत: डेटासह कार्य चाचणी करताना. नेहमीप्रमाणेच, सर्वात जास्त दाबणारे म्हणजे रिलेशनल डेटाबेसमध्ये डेटा सुसंगतता तपासणे, क्लाउड सेवांसह कार्य तपासणे आणि नकली ऑब्जेक्ट्स लिहिताना चुकीचे गृहितक करणे.

डॉकर कंटेनरमध्ये संपूर्ण मायक्रोसर्व्हिसची चाचणी करून हे सर्व आणि थोडे अधिक सोडवले जाऊ शकते. चाचण्यांची वैधता सुनिश्चित करण्याचा एक निःसंशय फायदा म्हणजे उत्पादनात जाणार्‍या समान डॉकर प्रतिमांची चाचणी केली जाते.

या दृष्टिकोनाचे ऑटोमेशन अनेक समस्या सादर करते, ज्याचे निराकरण खाली वर्णन केले जाईल:

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

हा लेख यावर आधारित आहे माझे भाषण SECR 2019 वर. त्यामुळे जे वाचण्यात खूप आळशी आहेत त्यांच्यासाठी, येथे भाषणाचे रेकॉर्डिंग आहे.

या लेखात मी तुम्हाला चाचणी अंतर्गत सेवा, डॉकरमध्ये डेटाबेस आणि Amazon AWS सेवा चालविण्यासाठी स्क्रिप्ट कशी वापरायची ते सांगेन, नंतर पोस्टमनवर चाचण्या आणि ते पूर्ण झाल्यानंतर, तयार केलेले कंटेनर थांबवा आणि हटवा. प्रत्येक वेळी कोड बदलल्यावर चाचण्या केल्या जातात. अशा प्रकारे, प्रत्येक आवृत्ती AWS डेटाबेस आणि सेवांसह योग्यरित्या कार्य करते याची आम्ही खात्री करतो.

समान स्क्रिप्ट विकसक स्वतः त्यांच्या Windows डेस्कटॉपवर आणि Gitlab CI सर्व्हरद्वारे Linux अंतर्गत चालवतात.

न्याय्य होण्यासाठी, नवीन चाचण्या सादर करण्यासाठी डेव्हलपरच्या कॉम्प्युटरवर किंवा सर्व्हरवर जिथे चाचण्या कमिटवर चालवल्या जातात त्यावर अतिरिक्त साधने स्थापित करण्याची आवश्यकता नसावी. डॉकर या समस्येचे निराकरण करते.

खालील कारणांसाठी चाचणी स्थानिक सर्व्हरवर चालणे आवश्यक आहे:

• नेटवर्क कधीही पूर्णपणे विश्वासार्ह नसते. हजार विनंत्यांपैकी एक अयशस्वी होऊ शकते;
  या प्रकरणात, स्वयंचलित चाचणी कार्य करणार नाही, कार्य थांबेल आणि आपल्याला लॉगमध्ये कारण शोधावे लागेल;
• काही तृतीय-पक्ष सेवांद्वारे खूप वारंवार विनंत्या करण्याची परवानगी नाही.

याव्यतिरिक्त, स्टँड वापरणे अवांछित आहे कारण:

• स्टँड केवळ खराब कोडवर चालत नाही तर डेटाद्वारे देखील खंडित केला जाऊ शकतो ज्यावर योग्य कोड प्रक्रिया करू शकत नाही;
• चाचणी दरम्यान चाचणीद्वारे केलेले सर्व बदल परत करण्याचा आपण कितीही प्रयत्न केला तरीही काहीतरी चूक होऊ शकते (अन्यथा, चाचणी का?).

प्रकल्प आणि प्रक्रिया संस्थेबद्दल

आमच्‍या कंपनीने Amazon AWS क्लाउडमध्‍ये डॉकरमध्‍ये चालणारे मायक्रोसर्व्हिस वेब अॅप्लिकेशन विकसित केले आहे. प्रकल्पावर युनिट चाचण्या आधीच वापरल्या गेल्या होत्या, परंतु अनेकदा त्रुटी आढळल्या ज्या युनिट चाचण्यांमध्ये आढळल्या नाहीत. डेटाबेस आणि अॅमेझॉन सेवांसह संपूर्ण मायक्रोसेवेची चाचणी करणे आवश्यक होते.

प्रकल्प एक मानक सतत एकत्रीकरण प्रक्रिया वापरते, ज्यामध्ये प्रत्येक कमिटसह मायक्रोसर्व्हिसची चाचणी समाविष्ट असते. एखादे कार्य नियुक्त केल्यानंतर, विकासक मायक्रो सर्व्हिसमध्ये बदल करतो, त्याची व्यक्तिचलितपणे चाचणी करतो आणि सर्व उपलब्ध स्वयंचलित चाचण्या चालवतो. आवश्यक असल्यास, विकसक चाचण्या बदलतो. कोणतीही समस्या आढळली नाही तर, या समस्येच्या शाखेत एक कमिट केले जाते. प्रत्येक कमिटनंतर, सर्व्हरवर चाचण्या स्वयंचलितपणे चालवल्या जातात. सामान्य शाखेत विलीन होणे आणि त्यावर स्वयंचलित चाचण्या सुरू करणे यशस्वी पुनरावलोकनानंतर होते. सामायिक केलेल्या शाखेतील चाचण्या उत्तीर्ण झाल्यास, Amazon इलास्टिक कंटेनर सर्व्हिस (बेंच) वरील चाचणी वातावरणात सेवा स्वयंचलितपणे अद्यतनित केली जाते. स्टँड सर्व डेव्हलपर आणि परीक्षकांसाठी आवश्यक आहे आणि ते तोडणे उचित नाही. या वातावरणातील परीक्षक मॅन्युअल चाचण्या करून फिक्स किंवा नवीन वैशिष्ट्य तपासतात.

प्रकल्प आर्किटेक्चर

अनुप्रयोगात दहा पेक्षा जास्त सेवांचा समावेश आहे. त्यातील काही .NET Core मध्ये तर काही NodeJs मध्ये लिहिलेले आहेत. Amazon लवचिक कंटेनर सेवेमध्ये प्रत्येक सेवा डॉकर कंटेनरमध्ये चालते. प्रत्येकाचा स्वतःचा Postgres डेटाबेस असतो आणि काहींचा Redis देखील असतो. कोणतेही सामान्य डेटाबेस नाहीत. अनेक सेवांना समान डेटाची आवश्यकता असल्यास, हा डेटा, जेव्हा तो बदलतो तेव्हा, या प्रत्येक सेवेवर SNS (सिंपल नोटिफिकेशन सर्व्हिस) आणि SQS (Amazon Simple Queue Service) द्वारे प्रसारित केला जातो आणि सेवा त्यांच्या स्वतंत्र डेटाबेसमध्ये तो जतन करतात.

SQS आणि SNS

SQS तुम्हाला संदेश रांगेत ठेवण्याची आणि HTTPS प्रोटोकॉल वापरून रांगेतील संदेश वाचण्याची परवानगी देते.

जर अनेक सेवांनी एक रांग वाचली, तर प्रत्येक संदेश त्यापैकी फक्त एकावरच पोहोचतो. त्‍यांच्‍यामध्‍ये लोड वितरीत करण्‍यासाठी समान सेवेची अनेक उदाहरणे चालवताना हे उपयोगी ठरते.

तुम्हाला प्रत्येक संदेश एकाधिक सेवांवर वितरित करायचा असल्यास, प्रत्येक प्राप्तकर्त्याची स्वतःची रांग असणे आवश्यक आहे आणि संदेशांना एकाधिक रांगांमध्ये डुप्लिकेट करण्यासाठी SNS आवश्यक आहे.

SNS मध्ये तुम्ही एक विषय तयार करता आणि त्याचे सदस्यत्व घ्या, उदाहरणार्थ, SQS रांग. तुम्ही विषयावर संदेश पाठवू शकता. या प्रकरणात, या विषयाची सदस्यता घेतलेल्या प्रत्येक रांगेला संदेश पाठविला जातो. SNS कडे संदेश वाचण्याची पद्धत नाही. डीबगिंग किंवा चाचणी दरम्यान तुम्हाला SNS वर काय पाठवले आहे हे शोधण्याची आवश्यकता असल्यास, तुम्ही एक SQS रांग तयार करू शकता, इच्छित विषयाची सदस्यता घेऊ शकता आणि रांग वाचू शकता.

API गेटवे

बहुतांश सेवा इंटरनेटवरून थेट उपलब्ध नसतात. प्रवेश API गेटवे द्वारे आहे, जो प्रवेश अधिकार तपासतो. ही देखील आमची सेवा आहे आणि त्यासाठी चाचण्या देखील आहेत.

रिअल-टाइम सूचना

अनुप्रयोग वापरतो सिग्नलआरवापरकर्त्याला रिअल-टाइम सूचना दाखवण्यासाठी. हे अधिसूचना सेवेमध्ये लागू केले आहे. हे थेट इंटरनेटवरून प्रवेश करण्यायोग्य आहे आणि स्वतः OAuth सह कार्य करते, कारण OAuth आणि अधिसूचना सेवा एकत्रित करण्याच्या तुलनेत गेटवेमध्ये वेब सॉकेटसाठी समर्थन तयार करणे अव्यवहार्य असल्याचे दिसून आले.

सुप्रसिद्ध चाचणी दृष्टीकोन

युनिट चाचण्या डेटाबेससारख्या गोष्टी नकली ऑब्जेक्ट्ससह बदलतात. मायक्रोसर्व्हिस, उदाहरणार्थ, एखाद्या टेबलमध्ये परदेशी कीसह रेकॉर्ड तयार करण्याचा प्रयत्न करत असल्यास आणि त्या की द्वारे संदर्भित रेकॉर्ड अस्तित्वात नसल्यास, विनंती पूर्ण केली जाऊ शकत नाही. युनिट चाचण्या हे शोधू शकत नाहीत.

В मायक्रोसॉफ्ट कडून लेख इन-मेमरी डेटाबेस वापरणे आणि मॉक ऑब्जेक्ट्स लागू करण्याचा प्रस्ताव आहे.

इन-मेमरी डेटाबेस एंटिटी फ्रेमवर्कद्वारे समर्थित DBMS पैकी एक आहे. हे विशेषतः चाचणीसाठी तयार केले गेले आहे. अशा डेटाबेसमधील डेटा केवळ तो वापरण्याची प्रक्रिया संपेपर्यंत संग्रहित केला जातो. यासाठी टेबल तयार करण्याची आवश्यकता नाही आणि डेटा अखंडता तपासत नाही.

मॉक ऑब्‍जेक्‍ट ते बदलत असलेल्‍या वर्गाचे मॉडेल बनवतात जेव्‍हा चाचणी विकसकाला ते कसे कार्य करते हे समजते.

जेव्हा तुम्ही चाचणी चालवता तेव्हा पोस्टग्रेस स्वयंचलितपणे सुरू करण्यासाठी आणि स्थलांतर कसे करावे हे Microsoft लेखात निर्दिष्ट केलेले नाही. माझे समाधान हे करते आणि याव्यतिरिक्त, मायक्रोसर्व्हिसमध्येच चाचणीसाठी विशेषत: कोणताही कोड जोडत नाही.

चला समाधानाकडे वळूया

विकास प्रक्रियेदरम्यान, हे स्पष्ट झाले की सर्व समस्या वेळेवर शोधण्यासाठी युनिट चाचण्या पुरेशा नाहीत, म्हणून वेगळ्या कोनातून या समस्येकडे जाण्याचा निर्णय घेण्यात आला.

चाचणी वातावरण सेट करणे

प्रथम कार्य चाचणी वातावरण तैनात करणे आहे. मायक्रोसर्व्हिस चालवण्यासाठी आवश्यक पायऱ्या:

• स्थानिक वातावरणासाठी चाचणी अंतर्गत सेवा कॉन्फिगर करा, डेटाबेसशी कनेक्ट करण्यासाठी तपशील निर्दिष्ट करा आणि पर्यावरण व्हेरिएबल्समध्ये AWS;
• Postgres सुरू करा आणि Liquibase चालवून स्थलांतर करा.
  रिलेशनल डीबीएमएसमध्ये, डेटाबेसमध्ये डेटा लिहिण्यापूर्वी, तुम्हाला डेटा स्कीमा तयार करणे आवश्यक आहे, दुसऱ्या शब्दांत, टेबल्स. अनुप्रयोग अद्यतनित करताना, टेबल्स नवीन आवृत्तीद्वारे वापरल्या जाणार्‍या फॉर्ममध्ये आणणे आवश्यक आहे आणि शक्यतो डेटा न गमावता. याला स्थलांतर म्हणतात. सुरुवातीला रिकाम्या डेटाबेसमध्ये टेबल तयार करणे ही स्थलांतराची एक विशेष बाब आहे. स्थलांतर अनुप्रयोगातच तयार केले जाऊ शकते. .NET आणि NodeJS दोन्हीकडे स्थलांतर फ्रेमवर्क आहेत. आमच्या बाबतीत, सुरक्षेच्या कारणास्तव, मायक्रोसर्व्हिसेस डेटा स्कीमा बदलण्याच्या अधिकारापासून वंचित आहेत आणि स्थलांतर Liquibase वापरून केले जाते.
• Amazon LocalStack लाँच करा. घरबसल्या चालवण्यासाठी AWS सेवांची ही अंमलबजावणी आहे. डॉकर हबवर लोकलस्टॅकसाठी तयार प्रतिमा आहे.
• LocalStack मध्ये आवश्यक घटक तयार करण्यासाठी स्क्रिप्ट चालवा. शेल स्क्रिप्ट्स AWS CLI वापरतात.

प्रकल्पावरील चाचणीसाठी वापरला जातो पोस्टमन. हे आधी अस्तित्वात होते, परंतु ते व्यक्तिचलितपणे लाँच केले गेले आणि स्टँडवर आधीच तैनात केलेल्या अनुप्रयोगाची चाचणी केली. हे साधन तुम्हाला अनियंत्रित HTTP(S) विनंत्या करण्याची आणि प्रतिसाद अपेक्षांशी जुळतात की नाही हे तपासण्याची परवानगी देते. क्वेरी एका संग्रहात एकत्रित केल्या जातात आणि संपूर्ण संग्रह चालवता येतो.

स्वयंचलित चाचणी कशी कार्य करते?

चाचणी दरम्यान, सर्व काही डॉकरमध्ये कार्य करते: चाचणी अंतर्गत सेवा, पोस्टग्रेस, स्थलांतर साधन आणि पोस्टमन किंवा त्याऐवजी त्याची कन्सोल आवृत्ती - न्यूमन.

डॉकर अनेक समस्यांचे निराकरण करते:

• होस्ट कॉन्फिगरेशनपासून स्वातंत्र्य;
• अवलंबित्व स्थापित करणे: डॉकर डॉकर हबवरून प्रतिमा डाउनलोड करतो;
• सिस्टमला त्याच्या मूळ स्थितीत परत करणे: फक्त कंटेनर काढून टाकणे.

डॉकर-कंपोज कंटेनर्सना एका आभासी नेटवर्कमध्ये एकत्र करते, इंटरनेटपासून वेगळे केले जाते, ज्यामध्ये कंटेनर डोमेन नावांद्वारे एकमेकांना शोधतात.

चाचणी शेल स्क्रिप्टद्वारे नियंत्रित केली जाते. विंडोजवर चाचणी चालवण्यासाठी आम्ही git-bash वापरतो. अशा प्रकारे, विंडोज आणि लिनक्स दोन्हीसाठी एक स्क्रिप्ट पुरेशी आहे. Git आणि Docker प्रकल्पावरील सर्व विकासकांनी स्थापित केले आहेत. विंडोजवर गिट इन्स्टॉल करताना, गिट-बॅश इन्स्टॉल केले जाते, त्यामुळे प्रत्येकाकडे तेही असते.

स्क्रिप्ट खालील पायऱ्या पार पाडते:

• डॉकर प्रतिमा तयार करणे

  docker-compose build

• डेटाबेस आणि लोकलस्टॅक लाँच करत आहे

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

• डेटाबेस स्थलांतर आणि लोकलस्टॅकची तयारी

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

• चाचणी अंतर्गत सेवा सुरू करत आहे

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

• चाचणी चालवणे (न्यूमॅन)
• सर्व कंटेनर थांबवत आहे

  docker-compose down

• स्लॅकमध्ये परिणाम पोस्ट करणे
  आमच्याकडे चॅट आहे जिथे हिरवा चेकमार्क किंवा लाल क्रॉस असलेले संदेश आणि लॉगची लिंक जाते.

खालील डॉकर प्रतिमा या चरणांमध्ये सामील आहेत:

• चाचणी केली जात असलेली सेवा उत्पादनासाठी समान प्रतिमा आहे. चाचणीचे कॉन्फिगरेशन हे पर्यावरणीय व्हेरिएबल्सद्वारे केले जाते.
• Postgres, Redis आणि LocalStack साठी, Docker Hub मधील तयार प्रतिमा वापरल्या जातात. Liquibase आणि Newman साठी तयार प्रतिमा देखील आहेत. त्यांच्या सांगाड्यावर आम्ही आमच्या फाईल्स जोडतो.
• LocalStack तयार करण्यासाठी, तुम्ही तयार AWS CLI प्रतिमा वापरता आणि त्यावर आधारित स्क्रिप्ट असलेली प्रतिमा तयार करा.

वापरत आहे खंड, कंटेनरमध्ये फाइल्स जोडण्यासाठी तुम्हाला डॉकर इमेज तयार करण्याची गरज नाही. तथापि, आमच्या वातावरणासाठी व्हॉल्यूम योग्य नाहीत कारण Gitlab CI कार्ये स्वतः कंटेनरमध्ये चालतात. तुम्ही अशा कंटेनरमधून डॉकर नियंत्रित करू शकता, परंतु व्हॉल्यूम्स फक्त होस्ट सिस्टममधून फोल्डर माउंट करतात, आणि दुसर्या कंटेनरमधून नाही.

समस्या तुम्हाला येऊ शकतात

तयारीची वाट पाहत आहे

सेवेसह कंटेनर चालू असताना, याचा अर्थ असा नाही की तो कनेक्शन स्वीकारण्यास तयार आहे. आपण कनेक्शन सुरू ठेवण्यासाठी प्रतीक्षा करणे आवश्यक आहे.

ही समस्या कधीकधी स्क्रिप्ट वापरून सोडवली जाते प्रतीक्षा करा, जे TCP कनेक्शन स्थापित करण्याच्या संधीची प्रतीक्षा करते. तथापि, लोकलस्टॅक 502 खराब गेटवे त्रुटी टाकू शकते. याव्यतिरिक्त, यात बर्‍याच सेवांचा समावेश आहे आणि त्यापैकी एक तयार असल्यास, हे इतरांबद्दल काहीही बोलत नाही.

निर्णय: LocalStack प्रोव्हिजनिंग स्क्रिप्ट्स ज्या SQS आणि SNS दोन्हीकडून 200 प्रतिसादाची प्रतीक्षा करतात.

समांतर कार्य संघर्ष

एकाच डॉकर होस्टवर अनेक चाचण्या एकाच वेळी चालू शकतात, त्यामुळे कंटेनर आणि नेटवर्कची नावे युनिक असणे आवश्यक आहे. शिवाय, एकाच सेवेच्या वेगवेगळ्या शाखांमधील चाचण्या एकाच वेळी चालवल्या जाऊ शकतात, त्यामुळे प्रत्येक कंपोझ फाइलमध्ये त्यांची नावे लिहिणे पुरेसे नाही.

निर्णय: स्क्रिप्ट COMPOSE_PROJECT_NAME व्हेरिएबल अनन्य मूल्यावर सेट करते.

विंडोज वैशिष्ट्ये

विंडोजवर डॉकर वापरताना मला बर्‍याच गोष्टी सांगायच्या आहेत कारण त्रुटी का येतात हे समजून घेण्यासाठी हे अनुभव महत्त्वाचे आहेत.

1. कंटेनरमधील शेल स्क्रिप्टमध्ये लिनक्स लाइन एंडिंग असणे आवश्यक आहे.
   शेल सीआर चिन्ह एक वाक्यरचना त्रुटी आहे. त्रुटी संदेशावरून हे सांगणे कठीण आहे की हे प्रकरण आहे. विंडोजवर अशा स्क्रिप्ट संपादित करताना, तुम्हाला योग्य मजकूर संपादक आवश्यक आहे. याव्यतिरिक्त, आवृत्ती नियंत्रण प्रणाली योग्यरित्या कॉन्फिगर करणे आवश्यक आहे.

अशा प्रकारे git कॉन्फिगर केले आहे:

git config core.autocrlf input

1. Git-bash मानक लिनक्स फोल्डर्सचे अनुकरण करते आणि exe फाईल (docker.exe सह) कॉल करताना, Windows पथांसह परिपूर्ण Linux पथ बदलते. तथापि, स्थानिक मशीनवर नसलेल्या पथांसाठी (किंवा कंटेनरमधील पथ) याचा अर्थ नाही. हे वर्तन अक्षम केले जाऊ शकत नाही.

निर्णय: पथाच्या सुरुवातीला अतिरिक्त स्लॅश जोडा: /bin ऐवजी //bin. लिनक्सला असे मार्ग समजतात; त्यासाठी अनेक स्लॅश एकसारखे असतात. परंतु git-bash असे मार्ग ओळखत नाही आणि त्यांचे रूपांतर करण्याचा प्रयत्न करत नाही.

लॉग आउटपुट

चाचण्या चालवताना, मला न्यूमन आणि सेवेची चाचणी होत असलेले लॉग पहायचे आहेत. या लॉगचे इव्हेंट एकमेकांशी जोडलेले असल्याने, त्यांना एका कन्सोलमध्ये एकत्र करणे दोन स्वतंत्र फाइल्सपेक्षा अधिक सोयीचे आहे. न्यूमन द्वारे लाँच करते डॉकर-कंपोज रन, आणि त्यामुळे त्याचे आउटपुट कन्सोलमध्ये संपते. सेवेचे आउटपुट देखील तेथे जाईल याची खात्री करणे एवढेच शिल्लक आहे.

मूळ उपाय करायचा होता डॉकर-तयार करा ध्वज नाही -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 मध्ये लागू केलेली नाहीत.

निर्णय: या प्रकरणांमध्ये ते मदत करू शकते मॉकसर्व्हर, ज्यामध्ये तयार प्रतिमा आहे डॉकर हब. अपेक्षित विनंत्या आणि त्यांना प्रतिसाद HTTP विनंतीद्वारे कॉन्फिगर केले जातात. API दस्तऐवजीकरण केलेले आहे, म्हणून आम्ही पोस्टमनकडून विनंती करतो.

OAuth प्रमाणीकरण आणि अधिकृतता चाचणी करत आहे

आम्ही OAuth वापरतो आणि JSON वेब टोकन (JWT). चाचणीसाठी OAuth प्रदाता आवश्यक आहे जो आम्ही स्थानिक पातळीवर चालवू शकतो.

सेवा आणि OAuth प्रदाता यांच्यातील सर्व परस्परसंवाद दोन विनंत्यांवर येतो: प्रथम, कॉन्फिगरेशनची विनंती केली जाते /.well-known/openid-configuration, आणि नंतर कॉन्फिगरेशनमधील पत्त्यावर सार्वजनिक की (JWKS) ची विनंती केली जाते. हे सर्व स्थिर सामग्री आहे.

निर्णय: आमचा चाचणी OAuth प्रदाता एक स्थिर सामग्री सर्व्हर आहे आणि त्यावर दोन फाइल्स आहेत. टोकन एकदा व्युत्पन्न केले जाते आणि Git ला वचनबद्ध केले जाते.

सिग्नलआर चाचणीची वैशिष्ट्ये

पोस्टमन वेबसॉकेटसह काम करत नाही. सिग्नलआर चाचणी करण्यासाठी एक विशेष साधन तयार केले गेले.

सिग्नलआर क्लायंट फक्त ब्राउझरपेक्षा जास्त असू शकतो. त्यासाठी .NET Core अंतर्गत क्लायंट लायब्ररी आहे. .NET Core मध्ये लिहिलेला क्लायंट, कनेक्शन स्थापित करतो, प्रमाणीकृत केला जातो आणि संदेशांच्या विशिष्ट क्रमाची वाट पाहतो. अनपेक्षित संदेश प्राप्त झाल्यास किंवा कनेक्शन तुटल्यास, क्लायंट 1 च्या कोडसह बाहेर पडतो. शेवटचा अपेक्षित संदेश प्राप्त झाल्यास, क्लायंट 0 च्या कोडसह बाहेर पडतो.

न्यूमन क्लायंटसह एकाच वेळी कार्य करतो. ज्यांना त्यांची गरज आहे अशा प्रत्येकाला संदेश वितरित केले जातात हे तपासण्यासाठी अनेक क्लायंट लॉन्च केले जातात.

एकाधिक क्लायंट चालविण्यासाठी पर्याय वापरा --स्केल डॉकर-कंपोज कमांड लाइनवर.

चालण्यापूर्वी, पोस्टमन स्क्रिप्ट सर्व क्लायंट कनेक्शन स्थापित करण्यासाठी प्रतीक्षा करते.
आम्हाला कनेक्शनची वाट पाहण्याची समस्या आधीच आली आहे. पण सर्व्हर होते, आणि येथे क्लायंट आहे. वेगळ्या दृष्टिकोनाची गरज आहे.

निर्णय: कंटेनरमधील क्लायंट यंत्रणा वापरतो आरोग्य तपासणीहोस्टवरील स्क्रिप्टला त्याच्या स्थितीबद्दल माहिती देण्यासाठी. कनेक्शन स्थापित होताच क्लायंट विशिष्ट मार्गावर फाइल तयार करतो, म्हणा /आरोग्य तपासणी. डॉकर फाइलमधील हेल्थचेक स्क्रिप्ट असे दिसते:

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

संघ डॉकर तपासणी कंटेनरसाठी सामान्य स्थिती, आरोग्य स्थिती आणि निर्गमन कोड दर्शविते.

न्यूमन पूर्ण झाल्यानंतर, स्क्रिप्ट तपासते की क्लायंटसह सर्व कंटेनर 0 कोडसह संपुष्टात आले आहेत.

हॅपिनेस अस्तित्वात आहे

आम्ही वर वर्णन केलेल्या अडचणींवर मात केल्यानंतर, आमच्याकडे स्थिर चालू चाचण्यांचा संच होता. चाचण्यांमध्ये, प्रत्येक सेवा डेटाबेस आणि Amazon LocalStack सह संवाद साधून, एकल युनिट म्हणून कार्य करते.

या चाचण्या 30+ विकासकांच्या टीमला वारंवार उपयोजनांसह 10+ मायक्रोसर्व्हिसेसच्या जटिल परस्परसंवादासह अनुप्रयोगातील त्रुटींपासून संरक्षण करतात.

स्त्रोत: www.habr.com