स्काला पर माइक्रोसर्विस का एकीकरण परीक्षण

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

RIT ++ में यूरी बैडलिंट्स ने बताया कि कैसे 2GIS बड़ी संख्या में सेवाओं और पूरी तकनीक चिड़ियाघर का एक समूह परीक्षण कर रहा है। कट के तहत, इस रिपोर्ट का एक संस्करण, स्पीकर के सावधानीपूर्वक पर्यवेक्षण के तहत पूरक और अद्यतन किया गया: आपने क्या विकल्प आज़माए, आप क्या लेकर आए हैं, अब आपको किन समस्याओं का समाधान नहीं करना है। यह Docker, Testcontainers, और Scala के बारे में भी होगा।


स्पीकर के बारे में: यूरी बैडलिंट्स (@ LMnet ) ने 2011 में एक वेब डेवलपर के रूप में अपना करियर शुरू किया, PHP, जावास्क्रिप्ट और जावा के साथ काम किया। अब वह 2GIS में स्काला पर लिखते हैं।

कैसिनो

2 जीआईएस 20 वर्षों से सुविधाजनक शहर के नक्शे और कंपनी निर्देशिका प्रदान कर रहा है, और हाल ही में हमारे पास रूस के असीमित नक्शे के साथ एक नया संस्करण है । मैंने आपको कैसीनो टीम में काम करने के दौरान प्राप्त अनुभव के बारे में बताया। यह टीम तीन मुख्य क्षेत्रों में शामिल है:

• विज्ञापन - कौन सा विज्ञापनदाताओं को दिखाना है, कौन सा छिपाना है, किसको उठाना है और कैसे रेटिंग कम करनी है।

• बिगडाटा विज्ञापन और इसके निजीकरण के साथ-साथ एनालिटिक्स और मेट्रिक्स बिल्डिंग से संबंधित है।
• क्रॉलर एक ऐसा प्रोग्राम है जो इंटरनेट पर संगठनों को डेटाबेस में स्वचालित रूप से जोड़ने के लिए खोज करता है।

ये तीन क्षेत्र मुख्य कार्य हैं, जो बदले में, बड़ी संख्या में उप-मुखौटे हैं। वर्तमान में, स्काला में 25 से अधिक माइक्रोसर्विस लिखे गए हैं। यह विशेष रूप से हमारा कोड है, हालांकि हम तीसरे पक्ष के सिस्टम का भी उपयोग करते हैं, उदाहरण के लिए, पोस्टग्रेसीक्यू, कैसेंड्रा और काफ्का। हम Hadoop में डेटा को स्टोर करते हैं और इसे स्पार्क में प्रोसेस करते हैं। इसके अलावा, हम डेटा साइंस टीम द्वारा दी गई मशीन लर्निंग के तरीकों का उपयोग करते हैं।

नतीजतन, हमारे पास बड़ी संख्या में सेवाएं और माइक्रोसॉर्फ़िस हैं, बड़ी संख्या में निर्भरताएं हैं, और निश्चित रूप से, इन सभी को किसी तरह से परीक्षण करने की आवश्यकता है।

बेशक, हम इकाई परीक्षण लिखते हैं। हालांकि, भले ही सभी परीक्षण हरे हों, इसका मतलब यह नहीं है कि सब कुछ काम करता है। घटकों या microservices के एकीकरण चरण के दौरान कुछ गलत हो सकता है। इसलिए, हम एकीकरण परीक्षण लिखते हैं।

एकीकरण परीक्षण

कसीनो टीम द्वारा विकसित प्रत्येक माइक्रोसर्विस अपनी व्यावसायिक समस्या को हल करता है और गिटलैब में एक अलग भंडार में स्थित है। यह लेख लॉक किए गए आश्रितों के साथ एक ऐसे रिपॉजिटरी (microservice) के भीतर एकीकरण परीक्षण पर ध्यान केंद्रित करेगा, जो स्वयं डेवलपर्स की जिम्मेदारी है। क्यूए टीम माइक्रोसर्विस की बातचीत का परीक्षण कर रही है, और मैं इस विषय पर नहीं छूऊंगा।

जब मैं पहली बार टीम में शामिल हुआ, 2016 के अंत में, लगभग निम्नलिखित एकीकरण परीक्षण योजना थी:

1. डेवलपर जीआईटी में अपने कोड को आगे बढ़ाता है, जिसके बाद माइक्रोसेवा कोड टीमसिटी में पहुंच जाता है। टीमसिटी कोड बनाना और परीक्षण चलाना शुरू करती है।
2. TeamCity, शेफ से कॉन्फ़िगरेशन फ़ाइल (कॉन्फ़िगरेशन) लेता है (Ansible के समान कॉन्फ़िगरेशन प्रबंधन प्रणाली, जो केवल रूबी में लिखी गई है)। शेफ भी तैनाती को स्वचालित करने के लिए कार्य करता है। जब मेरे पास 100 मशीनें होती हैं, तो मैं उनमें से प्रत्येक पर नहीं जाना चाहता हूं और एसएसएच पर मुझे जो कुछ भी चाहिए उसे स्थापित करना चाहिए, और बावर्ची मुझे इसे स्वचालित करने की अनुमति देता है।
3. टीमसिटी जार फ़ाइल को इकट्ठा करता है (जब से हम स्काला में लिखते हैं, जो कलाकृति हम प्रकाशित करते हैं वह जार है), फिर प्रोग्राम इसे सीआई के वातावरण में लोड करता है। हमारे आवेदन को वहां तैनात किया गया है, कुछ निर्भरताएं भी हैं। आरेख में, एक निर्भरता को डेटाबेस के रूप में दर्शाया गया है। संभव के रूप में इस तरह के कई निर्भरताएं हो सकती हैं, और शेफ के लिए धन्यवाद, हमारा आवेदन उनके बारे में जानता है और उनके साथ बातचीत करना शुरू करता है।
4. इसके बाद, टीमसिटी ने एसबीटी लॉन्च किया (यह हमारी बिल्ड सिस्टम है, जहां संकलन और परीक्षण चलाए जाते हैं) और परीक्षण खुद चलाते हैं। वे इकाई परीक्षणों के लिए अपेक्षाकृत समान हैं, लेकिन वे मुख्य रूप से इस सिद्धांत पर काम करते हैं: http के माध्यम से एक विशिष्ट पते पर जाएं, कुछ विधि की जांच करें और देखें कि यह क्या देता है; या कुछ तैयारी करते हैं, और फिर देखते हैं कि क्या जरूरत है वापस आ गया है।

ऐसी योजना के बारे में क्या कहा जा सकता है? सबसे महत्वपूर्ण बात, यह काम करता है। जब सब कुछ सेट हो जाता है, तो परीक्षण चलाना आसान होता है, क्योंकि वे इकाई परीक्षणों की तरह दिखते हैं। लेकिन प्लसस वहीं खत्म हो जाते हैं।

और अंत शुरू होता है। CI पर्यावरण हमेशा चालू रहता है , और यह संसाधनों की अतिरिक्त बर्बादी है। चूंकि शेफ एक स्थिर कॉन्फ़िगरेशन है, इसलिए आपको हमेशा किसी प्रकार की मशीन होनी चाहिए जहां सभी निर्भरताएं कॉन्फ़िगर की जाएंगी, जहां एप्लिकेशन स्वतंत्र रूप से तैनात किए जाएंगे। ऐसी मशीन अतिरिक्त संसाधनों का उपभोग करेगी, क्योंकि परीक्षण समय-समय पर चलाए जाते हैं, और मशीन को हर समय तैयार रहना चाहिए। इसके अलावा, सीआई वातावरण सभी निर्भरताओं के साथ शामिल है।

एक ही समय में दो शाखाओं पर परीक्षण चलाना संभव नहीं है । यह पिछले पैराग्राफ से इस प्रकार है: चूंकि हमारे पास एक वातावरण है, हम बस उन्हें समानांतर में नहीं चला सकते हैं।

स्टार्ट, स्टॉप और रीस्टार्ट करना संभव नहीं है । मैं समझाता हूं कि यह क्यों आवश्यक है: हमारे सभी अनुप्रयोग तथाकथित शटडाउन शटडाउन के तर्क का पालन करते हैं, अर्थात्, जब हम सिगारम प्राप्त करते हैं, तो हम प्रक्रिया को बीच में नहीं रोकते हैं, लेकिन इस संकेत को रोकते हैं और समझते हैं कि हमें कार्यक्रम को बंद करने की आवश्यकता है। इस बिंदु पर, कुछ तर्क चालू होते हैं, उदाहरण के लिए, उन HTTP अनुरोधों को "उड़ान में" संसाधित किया जाता है, या यदि हम काफ्का के साथ काम करते हैं, तो हम सभी बंदों को प्रतिबद्ध करते हैं - दूसरे शब्दों में, हम कुछ क्रियाएं करते हैं ताकि हम सुरक्षित रूप से काम पूरा कर सकें, और फिर, जब सब कुछ हो जाए, तो बंद कर दें।

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

अगला ऋण यह है कि यह सब स्थानीय रूप से कॉन्फ़िगर करना बहुत मुश्किल है । यही है, कई निर्भरताएं हैं, उनके पास अपने स्वयं के कॉन्फ़िगरेशन हैं, उन्हें स्थानीय मशीन पर उठाने की आवश्यकता है। एप्लिकेशन के पास स्वयं की कॉन्फ़िगरेशन फ़ाइल भी है, जिसमें कई मान हैं। परीक्षणों में स्वयं एक कॉन्फ़िगरेशन होता है जिसे एप्लिकेशन कॉन्फ़िगरेशन के साथ मिलान करने की आवश्यकता होती है, और एक से अधिक कॉन्फ़िगरेशन मान भी हो सकते हैं। ऐसा लगता है कि यह सब इतना डरावना नहीं है, जैसे "तीन स्थानों पर कॉन्फिग्स को जाना और ठीक करना", लेकिन वास्तव में नए कर्मचारियों को ऐसा करने में घंटों लग सकते हैं।

गिटलब सीआई + डॉकटर

समय के साथ, यह योजना दूसरे में बदल गई है: गिटलैब सीआई और डोकर । ऐसा इसलिए नहीं हुआ क्योंकि पिछली योजना आदर्श नहीं थी, बल्कि इसलिए कि कंपनी ने प्रशासनिक संगठन के संदर्भ में थोड़ा बदलाव किया।

इससे पहले, प्रत्येक टीम, और हमारे पास उनमें से बहुत कुछ है, जैसा कि हम चाहते थे या हम कैसे कर सकते थे, और इसके काम को तैनात कर सकते थे। उदाहरण के लिए, हमारे पास टीमसिटी, शेफ और अन्य टीमें जेनकिंस या एंसिबल का उपयोग कर सकती थीं।

अब हम स्थानीय क्लाउड और कुबेरनेट्स की ओर बढ़ रहे हैं, और एक अलग टीम है जो यह सब GitLab CI और Kubernetes दोनों का प्रबंधन करती है। अन्य टीमें इसे सेवा के रूप में उपयोग करती हैं। यह बहुत अधिक सुविधाजनक है क्योंकि आपको मैन्युअल रूप से यह सब करने की आवश्यकता नहीं है।

कुबेरनेट्स का उपयोग करते हुए, हमने निम्नलिखित योजना को तैनात किया:

1. TeamCity के बजाय, Gitlab CI का अब उपयोग किया जाता है।
2. GitLab CI एक डॉक इमेज बनाता है और इसे कुबेरनेट्स में भेजता है। कॉन्फ़िगरेशन अब सीधे भंडार में संग्रहीत किया जाता है, और शेफ में अलग से नहीं, इसलिए परिनियोजन के लिए आपको तृतीय-पक्ष कॉन्फ़िगरेशन सेवा के साथ काम करने की आवश्यकता नहीं है।
3. निर्भरताएँ अग्रिम रूप से उठाई जाती हैं, कुबेरनेट्स में भी।
4. फिर GitLab CI ने SBT लॉन्च किया और एक अलग चरण में परीक्षण किया।

सब कुछ पिछली योजना के समान है और मूल रूप से इससे अलग नहीं है, अर्थात्, यहां तक ​​कि पेशेवरों और विपक्ष बिल्कुल समान होंगे, लेकिन डॉकर प्रकट होता है।

डॉकटर के साथ, आप अलग-अलग मज़ेदार चीजें कर सकते हैं और उनमें से एक डॉक-कंपोज़ है।

डोकर-लिखें

यह डॉकर पर एक प्रकार का "ओवरले" है, जो आपको एक इकाई के रूप में कई डॉकटर-चित्र चलाने की अनुमति देता है।

एक अच्छा उदाहरण जहां डॉकटर-कंपोज़ वास्तव में मदद करता है वह है काफ्का। उसे दौड़ने के लिए चिड़ियाघर कीपर की जरूरत है। यदि आप बिना कैसर-रचना के काफ्का और ज़ूकेपर को उठाते हैं, तो आपको डॉक में ज़ूकेर को अलग-अलग उठाने की ज़रूरत है, अलग-अलग - काफ्का, और इन दो डॉकटर कंटेनरों को लगातार बनाए रखें। यह बहुत सुविधाजनक नहीं है, और डॉकटर-कंपोज़ आपको दोनों कंटेनरों को एक डॉक-कंपोज़.आईएमएल फ़ाइल में वर्णन करने की अनुमति देता है और काफ्का और ज़ूकिपर docker-compose run Kafka उठाने के लिए सरल डॉक docker-compose run Kafka उपयोग करता है।

आप डॉकटर-कम्पोज़ पर एकीकरण परीक्षण बना सकते हैं। आइए देखें कि यह कैसा दिखेगा।

1. फिर, GitLab में सब कुछ धक्का।
2. GitLab CI ने डॉकटर-कम्पोज़ लॉन्च किया।
3. डॉकटर-कम्पोज़ में, एप्लिकेशन ऊपर जाता है, सभी निर्भरताएं और एसबीटी ऊपर जाते हैं, और एसबीटी इस एप्लिकेशन के लिए परीक्षण चलाता है - सब कुछ डॉकटर-कंपोज के अंदर होता है।

इस योजना के लिए धन्यवाद, एक अलग वातावरण और निर्भरता रखने की आवश्यकता नहीं है, क्योंकि सब कुछ सीधे गिटलब सीआई धावक के पास जाता है, जहां डॉकटर और डॉक-कंपोज को बस होना है। शुरुआत के दौरान, वह आवश्यक छवियों को पंप करेगा और उन्हें चलाएगा।

इसके अलावा, आप एक ही समय में विभिन्न शाखाओं का परीक्षण कर सकते हैं, क्योंकि सब कुछ धावक पर होता है।

अब स्थानीय रूप से पर्यावरण को कॉन्फ़िगर करना आसान है , लेकिन आपको अभी भी कई स्थानों पर समन्वय करना होगा। बात यह है कि अब, जब हम स्थानीय कॉन्फ़िगरेशन करते हैं, तो हमें सब कुछ स्थानीय मशीन पर डालने की आवश्यकता नहीं है, सब कुछ docker-compose.yml फ़ाइल में लिखा गया है। इस प्रकार, आपको दो अलग-अलग स्थानों में कॉन्फ़िगर करना होगा - यह docker-compose.yml और हमारे परीक्षणों का कॉन्फ़िगरेशन है।

के रूप में minuses के लिए, अभी भी परीक्षण शुरू करना, रोकना और पुनः आरंभ करना असंभव है , क्योंकि एसबीटी से, परीक्षणों से, हम एप्लिकेशन जीवन चक्र को नियंत्रित नहीं करते हैं। यह docker-compose द्वारा चलाया जाता है, यह SBT चलाता है और SBT के अंदर परीक्षण चलाए जाते हैं। इस प्रकार, आवेदन का कोई पूर्ण जीवन चक्र प्रबंधन नहीं है। लॉन्च के साथ मुश्किलें भी हैं, जिनके बारे में मैं और बात करना चाहूंगा।

docker- रचना २

Docker-compose 2 के दिनों में, docker-compose.yml फाइल इस तरह दिखती है:

 version: '2.1' services: web: build: . depends_on: db: condition: service_healthy redis: condition: service_started redis: image: redis db: image: db healthcheck: test: "some test here" 

यहां सेवाएं पंजीकृत हैं, अर्थात, हम इस डॉकटर-कंपोज के हिस्से के रूप में क्या बढ़ाएंगे। इस मामले में, मैंने सिर्फ डॉकटर-कंपोज़ डॉक्यूमेंटेशन से एक उदाहरण लिया है। तीन सेवाएं हैं: वेब, रेडिस और डीबी (डेटाबेस)।

वेब हमारा अनुप्रयोग है, और रेडिस और डीबी कुछ प्रकार की निर्भरताएं हैं।

वेब ब्लॉक में एक आइटम है, जिसे depends_on कहा जाता है। इससे पता चलता है कि वेब एप्लिकेशन कुछ अन्य कंटेनरों पर निर्भर करता है, और नीचे वर्णित है जिस पर: डेटाबेस और रेडिस से।

इसके अलावा, एक condition है। रेडिस के लिए, यह सेवा_स्टार्ट है, जिसका अर्थ है कि जब तक रेडिस शुरू नहीं होता है, तब तक कंटेनर वेब एप्लिकेशन को शुरू करने की कोशिश नहीं करेगा।

डेटाबेस के रूप में, इसकी स्थिति service_healthy , और स्वास्थ्य जांच नीचे वर्णित है। यही है, हमें न केवल डॉकटर कंटेनर लॉन्च करने की आवश्यकता है, बल्कि एक निश्चित स्वास्थ्य परीक्षण को भी निष्पादित करना होगा। यह कोई भी कस्टम तर्क हो सकता है।

उदाहरण के लिए, हम PostgreSQL का उपयोग करते हैं, जो PostGIS एक्सटेंशन का उपयोग करता है, और इसे आरंभ करने के लिए कुछ समय चाहिए। जब हम डॉकटर कंटेनर लॉन्च करते हैं, तो हम तुरंत पोस्टगिस एक्सटेंशन के साथ काम नहीं कर सकते हैं - हमें इनिशियलाइजेशन के लिए इंतजार करना होगा। इसलिए, हम अभी SELECT PostGIS_Version(); लिए SELECT PostGIS_Version(); प्रश्नों को SELECT PostGIS_Version(); । जब तक एक्सटेंशन को इनिशियलाइज़ नहीं किया जाता है, तब तक रिक्वेस्ट में एरर आ जाएगी और जब एक्सटेंशन इनिशियलाइज़ हो जाएगा, तो वह वर्जन को वापस करना शुरू कर देगा। यह बहुत सुविधाजनक और तार्किक है - पहले हम सभी निर्भरताएं बढ़ाएंगे, और फिर आवेदन करेंगे ।

docker- रचना ३

जब डॉकटर-कंपोज 3 बाहर आया, तो हमने इसका उपयोग करना शुरू कर दिया।

लेकिन इसके लिए प्रलेखन में, एक आइटम depend_on तर्क को बदलने पर दिखाई दिया। डॉक डेवलपर्स ने तय किया कि निर्भरता ग्राफ का वर्णन पर्याप्त था। इसका मतलब यह है कि जब आप docker-compose run web शुरू करते हैं, तो एप्लिकेशन और डीबी जिस पर वह निर्भर करता है, दोनों एक साथ शुरू होंगे।



प्रलेखन में अगला पैराग्राफ कहता है कि depend_on अब कोई शर्त नहीं है।

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

नियंत्रण स्टार्टअप आदेश पृष्ठ कई समाधान प्रदान करता है। पहला विकल्प है कि वेट का उपयोग करें-for-it.sh ।

अब docker-compose.yml थोड़ा अलग दिखता है:

 version: '3' services: web: build: . depends_on: [ db, redis ] redis: image: redis command: [ "./wait-for-it.sh", ... ] db: image: redis command: [ "./wait-for-db.sh", ... ] 

depends_on सिर्फ एक सरणी है, कोई शर्तें नहीं हैं।

हमारी निर्भरता में, हम कमांड को फिर से परिभाषित करते हैं, अर्थात्, docker-compose में आप एक कमांड अटैच कर सकते हैं जिसके साथ डॉकटर कंटेनर शुरू होता है।

वहां हमें इंतजार करना चाहिए- for-it.sh, और कुछ और। ऊपर दिए गए उदाहरण में तीन बिंदुओं के बजाय, हमें लिखना चाहिए कि हमें प्रतीक्षा करने की क्या आवश्यकता है, साथ ही मूल आदेश जो डॉकटर कंटेनर को लॉन्च करता है।

ऐसा करने के लिए, आपको डॉक फ़ाइल खोजने की आवश्यकता है, वहां से रेडिस के लिए कमांड कॉपी करें और इसे पेस्ट करें, वही डेटाबेस के लिए जाता है। एक बहुत बड़ा ऋण यह है कि अमूर्त टूट जाता है - मैं यह नहीं जानना चाहता कि कौन सा कमांड डॉकटर कंटेनर लॉन्च करता है। ये आदेश नैशनल, काफी जटिल हो सकते हैं, लेकिन मैं परेशान नहीं करना चाहता, मैं सिर्फ docker run दर्ज करना चाहता हूं और यह है।

मैं व्यक्तिगत रूप से इस समाधान को पसंद नहीं करता हूं, लेकिन हमारे पास कुछ सेवाएं थीं जो इस तरह से काम करती हैं।

डॉकटर-कम्पोज के शीर्ष पर स्क्रिप्ट

तब मैंने फैसला किया कि "साइकिल निर्माण " का समय आ गया था, और मेरे पास docker-compose-run.sh था:

 version: '3' services: postgres: ... my_service: depends_on: [ postgres ] ... sbt: depends_on: [ my_service ] ... 

मैं एक अर्ध-यथार्थवादी उदाहरण देता हूं: docker-compose.yml में पोस्टग्रेज है, my_service एप्लिकेशन है, जो पोस्टग्रेज और SBT पर निर्भर करता है, जिसमें परीक्षण चलाए जाते हैं और जो मेरी सेवा पर निर्भर करता है।

मैं कार्यक्रम को डॉक docker run माध्यम से नहीं, बल्कि docker-compose-run.sh स्क्रिप्ट के माध्यम से चलाता हूं।

सबसे पहले, यह सबसे गहरी निर्भरता शुरू करता है सबसे पहले, मेरे मामले में यह पोस्टग्रेज है। स्क्रिप्ट "डेमॉन" मोड में निर्भरता शुरू करती है, अर्थात, यह टर्मिनल को ब्लॉक नहीं करती है:

 docker-compose up -d postgres 

फिर मैं प्रतीक्षा के लिए प्रतीक्षा कर रहा था कि हालत के लिए प्रतीक्षा करें। यह लगभग वैसा ही है जैसे प्रतीक्षा- for-it.sh, केवल, इतना बोलने के लिए, एक अनिवार्य शैली में। जबकि PostGIS आरंभ कर रहा है, टर्मिनल अवरुद्ध है, अर्थात, प्रोग्राम भी प्रतीक्षा करता है, और अगर यह इंतजार नहीं करता है, तो एक त्रुटि फेंक दी जाती है और परीक्षण काम करना बंद कर देते हैं।

 wait_until 10 2 docker-compose exec -T postgres psql 

जब PostGIS आरंभीकृत होता है, तो अगले चरण पर आगे बढ़ें और सेवा के साथ भी ऐसा ही करें। उसके लिए, परीक्षण थोड़ा सरल है: पोर्ट 80 को बाध्य किया जाना चाहिए।

 docker-compose up -d my_service wait_until 10 2 docker-compose exec -T \ my_service sh -c "netstat -ntlp | grep 80 || exit 1" 

अंतिम चरण रन कमांड के माध्यम से एसबीटी को चलाना है, जिसमें परीक्षण चलाए जाते हैं।

 docker-compose run sbt down $? 

इस प्रकार, सब कुछ सही क्रम में उठाया जाता है, लेकिन मैन्युअल रूप से।

अंत में, down फंक्शन को कहा जाता है, जो पिछले कमांड के परिणाम को स्वीकार करता है। यदि यह "0" है, तो परीक्षण पास हो गए हैं, और हम सिर्फ डॉकटर-कंपोज को बंद कर देते हैं; अन्यथा, हम पहले यह पता लगाते हैं कि क्या गलत हुआ, यह पता लगाने के लिए लॉग्स को बंद करें और उसके बाद ही डॉकटर-कंपोज को बंद करें।

 function down { echo "Exiting with code $1" if [[ $1 -eq 0 ]]; then docker-compose down exit $1 else docker-compose logs -t postgres my_service docker-compose down exit $1 fi } 

इस तरह की योजना काम करती है, लेकिन अच्छी तरह से पैमाना नहीं है। प्रत्येक सेवा को अपने तर्क के साथ अपने docker-compose-run.sh का वर्णन करना होगा। इसके अलावा, लॉन्च कॉन्फ़िगरेशन docker-compose-run.sh और docker-compose.yml के बीच फैली हुई है। खैर, सामान्य तौर पर, ऐसा लगता है कि हम डॉकटर-कंपोज़ का उपयोग नहीं कर रहे हैं, लेकिन इसकी कमियों से जूझ रहे हैं।

कोड से चल रहा है

जब पिछली योजना बनाई गई थी, तो मैंने सोचा: अगर मेरे पास पहले से ही डॉकटर में सब कुछ है, तो इसे कोड से क्यों न चलाया जाए। मैंने एक समाधान की तलाश शुरू की और कई विकल्प पाए।

पहला विकल्प केवल डॉक क्लाइंट का उपयोग करना है । JVM की दुनिया में दो मुख्य docker क्लाइंट हैं: docker-java और Spotify docker-client ।

Docker क्लाइंट आपको API का उपयोग करके कोड से सीधे docker कमांड चलाने की अनुमति देता है। यानी, `docker run ...` जैसे कमांड बनाने के लिए स्ट्रिंग्स को कॉन्टेक्ट करने के बजाय, आप कोड में इस तरह की कमांड बना सकते हैं और उसे चला सकते हैं। यह बहुत अधिक सुविधाजनक है।

यह विधि अच्छी तरह से काम करती है, और, निश्चित रूप से, वे सब कुछ कर सकते हैं, हालांकि, यह बहुत निम्न स्तर है। मुझे अपना खुद का डॉक्यू-कंपोज़ एनालॉग बनाना होगा, जो एक बहुत बड़ा काम है।

अगला विकल्प डॉकटर-इट-स्काला लाइब्रेरी है , जो इन दोनों क्लाइंट को लपेटता है और आपको यह चुनने की अनुमति देता है कि किस बैकेंड का उपयोग करना है। वह आपके द्वारा आवश्यक कंटेनरों को चला सकता है।

लेकिन इस लाइब्रेरी का माइनस यह है कि इसमें बहुत लचीला एपीआई नहीं है और जीवन चक्र नियंत्रण नहीं है।

मुझे यह विकल्प पसंद नहीं था, मैंने खोज जारी रखी और टेस्टकोनटेनर्स पाया। मैं आपको इसके बारे में और बताना चाहूंगा।

Testcontainers

यह डॉक कंटेनर को लॉन्च करने और परीक्षण करने के लिए एक प्रकार का जावा पुस्तकालय है। एक स्काला मुखौटा, वृषण-शिलालेख है। बॉक्स से बाहर, कई लोकप्रिय सेवाएं हैं, उदाहरण के लिए, PostgreSQL, MySQL, Nginx, Kafka, Selenium। आप किसी भी अन्य कंटेनरों को चला सकते हैं। लाइब्रेरी में काफी सरल और लचीला एपीआई है, जिसे मैं अधिक विस्तार से बताऊंगा।

पूर्वनिर्धारित कंटेनर

तो, पूर्वनिर्धारित कंटेनरों के साथ कैसे काम करें, जो पुस्तकालय में हैं: वास्तव में, सब कुछ काफी सरल है, क्योंकि कंटेनर वस्तुओं के रूप में प्रस्तुत किए जाते हैं:

 val pgContainer: PostgreSQLContainer = PostgreSQLContainer("postgres:9.6") pgContainer.start() val pgUrl: String = pgContainer.jdbcUrl val pgPort: Int = pgContainer.mappedPort(5432) pgContainer.stop() 

इस मामले में, हम PostgreSQLContainer बनाते हैं, हम इसे शुरू कर सकते हैं और इसके साथ काम करना शुरू कर सकते हैं। इसके बाद, हमें jbdcUrl मिलता है, जिसके साथ आप PostgreSQL से जुड़ सकते हैं। उसके बाद हमें mappedPort ।

इसका मतलब यह है कि PostgreSQL डॉक पोर्ट 5432 से चिपक जाता है, और Testcontainers इस पोर्ट को देखते हैं और स्वचालित रूप से कुछ यादृच्छिक पोर्ट को असाइन करते हैं। अर्थात्, हम जो परीक्षण देखते हैं, उदाहरण के लिए, 32422। असाइनमेंट स्वचालित रूप से होता है।

कस्टम कंटेनर

निम्नलिखित दृश्य, तथाकथित कस्टम कंटेनर भी काफी सरल है:

 class GenericContainer( imageName: String, exposedPorts: Seq[Int] = Seq(), env: Map[String, String] = Map(), command: Seq[String] = Seq(), classpathResourceMapping: Seq[(String, String, BindMode)] = Seq(), waitStrategy: Option[WaitStrategy] = None ) ... 

एक GenericContainer है जिसमें से आपको कई क्षेत्रों को इनहेरिट और ओवरराइड करना होगा। केवल imageName सेट करना सुनिश्चित करें - यह उस कंटेनर का नाम है जिसे हम बनाना चाहते हैं।

आप exposedPorts सेट कर सकते हैं: वे पोर्ट जो कंटेनर से चिपक जाएंगे। Env में, आप पर्यावरण चर सेट कर सकते हैं, आप चलाने के लिए command भी सेट कर सकते हैं।

classpathResourceMapping आपको classpathResourceMapping से संसाधनों को डॉकटर कंटेनर में फेंकने की अनुमति देता है। यह बहुत सुविधाजनक है, उदाहरण के लिए, यदि एप्लिकेशन कॉन्फ़िगरेशन सीधे परीक्षण संसाधनों में है। आप बस अंदर का नक्शा बनाते हैं, और डॉकटर के अंदर का एप्लिकेशन इस कॉन्फिग को एक्सेस करता है।

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

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

परीक्षण चल रहा है

और अब थोड़ा परीक्षण चलाने के बारे में:

 class PostgresqlSpec extends FlatSpec with ForAllTestContainer { override val container = PostgreSQLContainer() "PostgreSQL container" should "be started" in { Class.forName(container.driverClassName) val connection = DriverManager .getConnection(container.jdbcUrl, container.username, container.password) // test some stuff } } 

मैं ScalaTest के बारे में बात करूंगा , Scala दुनिया में परीक्षण के लिए वास्तविक मानक।

उदाहरण के लिए, हम पोस्टग्रेज के लिए परीक्षण लिखना चाहते हैं। एक PostgresqlSpec परीक्षण बनाएं और इसे ForAllTestContainer से ForAllTestContainer । यह पुस्तकालय द्वारा प्रदान की गई विशेषता है। यह सभी परीक्षणों से पहले आवश्यक कंटेनरों को शुरू करेगा और सभी परीक्षणों के बाद उन्हें रोक देगा। या आप ForeachTestContainer उपयोग कर सकते हैं, फिर कंटेनर प्रत्येक परीक्षण से पहले शुरू होते हैं और उनमें से प्रत्येक के बाद बंद हो जाते हैं।

फिर आपको कंटेनर को फिर से परिभाषित करने की आवश्यकता है। यह container संपत्ति को ओवरराइड करके किया जा सकता है। मेरे मामले में, मैं PostgreSQLContainer का उपयोग कर रहा हूं।

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

आमतौर पर, एकीकरण परीक्षणों में कई कंटेनरों की आवश्यकता होती है। मैं उन्हें MultipleContainers का उपयोग कर बना सकते हैं:

 val pgContainer = PostgreSQLContainer() val myContainer = MyContainer() override val container = MultipleContainers(pgContainer, myContainer) 

यही है, मैं कंटेनरों का निर्माण करता हूं, उन्हें मल्टीपलटेनर में जोड़ता हूं, और container रूप में उपयोग करता हूं।

Testcontainers के साथ परीक्षण चलाने की योजना इस प्रकार है:

1. GitLa में कोड पुश करें।
2. GitLab CI धावक ने SBT को लॉन्च किया।
3. SBT परीक्षण चलाता है। परीक्षणों के अंदर, हमारे आवेदन और निर्भरताएं लॉन्च की जाती हैं।

इस योजना के लाभ:

• एक अलग वातावरण और निर्भरता रखने की आवश्यकता नहीं है, सब कुछ धावक पर होता है।
• आप एक ही समय में विभिन्न शाखाओं का परीक्षण कर सकते हैं।
• आप स्टार्ट, स्टॉप और रिस्टार्ट का परीक्षण कर सकते हैं, क्योंकि हम एप्लिकेशन के जीवन चक्र को नियंत्रित कर सकते हैं (परीक्षण कोड में सब कुछ सही शुरू होता है)।
• वहाँ लचीले HealthChecks हैं जिनमें संभवतः कमी थी।
• रिपॉजिटरी में कोई * .sh फाइलें नहीं हैं, आप चाहें तो लचीलेपन से एप्लिकेशन में परीक्षण कॉन्फ़िगर कर सकते हैं।
• ClasspathResource मैपिंग के लिए धन्यवाद, आप परीक्षण और एप्लिकेशन दोनों के साथ एक ही कॉन्फ़िगरेशन का उपयोग कर सकते हैं।
• आप कोड से परीक्षण कॉन्फ़िगर कर सकते हैं।
• यह सब सीआई और स्थानीय रूप से दोनों पर समान रूप से आसानी से चलता है, क्योंकि ये केवल परीक्षण हैं जो इकाई परीक्षणों के रूप में दिखते हैं और चलते हैं, केवल डॉकटर कंटेनर में सब कुछ ऊपर जाता है।

यह पता चला है कि सब कुछ संदिग्ध रूप से चिकनी और अच्छा है, लेकिन यह केवल पहली नज़र में है, वास्तव में, हमने कई समस्याओं का सामना किया।

आश्रित कंटेनर

हमने जो पहली समस्या का सामना किया है वह आश्रित कंटेनर है । मान लीजिए कि किसी प्रकार की परीक्षा है:

 class MySpec extends FlatSpec with ForAllTestContainer { val pgCont = PostgreSQLContainer() val appCont = AppContainer(pgCont.jdbcUrl, pgCont.username, pgCont.password) override val container = MultipleContainers(appCont, pgCont) // tests here } 

यह पोस्टग्रांट्स और AppContainer चलाता है। कनेक्शन के लिए पोस्टग्रैस से appContainer jdbcUrl, उपयोगकर्ता नाम और पासवर्ड पारित किया गया है। इसके बाद, मल्टीपलरटेनर्स बनाए जाते हैं और परीक्षण का वर्णन किया जाता है।

मैं कार्यक्रम चलाता हूं और एक त्रुटि देखता हूं:

 Exception encountered when invoking run on a nested suite - Mapped port can only be obtained after the container is started 

मुद्दा यह है कि कंटेनर शुरू होने तक निर्दिष्ट पोर्ट नहीं लिया जा सकता है। ऐसा क्यों हो रहा है?

तथ्य यह है कि ForAllTestContainer या ForEachTestContainer परीक्षणों से ठीक पहले कंटेनरों को शुरू करते हैं, और उस समय नहीं जब मैं कंटेनर उदाहरण बनाता हूं। यह पता चला है कि जिस समय मैं AppContainer बनाता हूं, मेरे पास अभी तक PostgreSQLContainer चालू नहीं है, जिसका अर्थ है कि मुझे इसमें से निर्दिष्ट पोर्ट नहीं मिल सकता है, और इसे jdbcUrl बनाने की jdbcUrl ।

समस्या यह है कि कंटेनर का सार परिवर्तनशील है: इसमें कई राज्य हैं। उदाहरण के लिए, इसे बंद और चालू किया जा सकता है।

इस समस्या को कैसे हल करें? पहली विधि मैं "आलसी" कहूंगा।

 class MyTest extends FreeSpec with BeforeAndAfterAll { lazy val pgCont = PostgreSQLContainer() lazy val appCont = AppContainer(pgCont.jdbcUrl, pgCont.username, pgCont.password) override def beforeAll(): Unit = { super.beforeAll() pgCont.start() appCont.start() } override def afterAll(): Unit = { super.afterAll() appCont.stop() pgCont.stop() } // tests here } 

मुख्य विचार आलसी घाटी का उपयोग करके कंटेनर बनाना है। फिर उन्हें परीक्षण निर्माता में तुरंत आरंभ नहीं किया जाएगा, लेकिन पहले कॉल की प्रतीक्षा करेंगे। हम beforeAll और afterAll में इनिशियलाइज़ करेंगे, जो कि स्कैलेस्ट से पहले केAAndAfterAll BeforeAndAfterAll प्रदान करता है। पहले beforeAll कंटेनर शुरू होते हैं, और बाद में, वे बंद हो जाते हैं। चूंकि कंटेनरों को आलसी घोषित किया जाता है, उस समय प्रारंभ विधि को पहले सभी में बुलाया जाता है, उन्हें बनाया जाएगा, आरंभ किया जाएगा, और शुरू किया जाएगा।

हालाँकि, एक त्रुटि अभी भी होती है कि मैं लोकलहोस्ट में शामिल नहीं हो सकता: 32787:

 org.postgresql.util.PSQLException: Connection to localhost:32787 refused. Check that the hostname and port are correct and that the postmaster is accepting TCP/IP connections. 

ऐसा लगता है कि हमने jdbcUrl का उपयोग किया है, लोकलहोस्ट क्यों दिखाई देता है? आइए देखें कि jdbcUrl कैसे काम करता है:

 @Override public String getJdbcUrl() { return "jdbc:postgresql://" + getContainerIpAddress() + ":" + getMappedPort(POSTGRESQL_PORT) + "/" + databaseName; } 

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

Testcontainers डेवलपर की सिफारिश: इंटर-कंटेनर संचार के लिए एक कस्टम नेटवर्क बनाएं । डॉकर-रचना कुछ इस तरह से काम करती है: यह एक नेटवर्क बनाती है और अपने आप ही सब कुछ हल करती है।

इसलिए आपको एक नेटवर्क बनाने की आवश्यकता है।

 class MyTest extends FreeSpec with BeforeAndAfterAll { val network: Network = Network.newNetwork() val dbName = "some_db" val pgContainerAlias = "postgres" val jdbcUrl = s"jdbc:postgresql://$pgContainerAlias:5432/$dbName" lazy val pgCont = { val c = PostgreSQLContainer("postgres:9.6") c.container.withNetwork(network) c.container.withNetworkAliases(pgContainerAlias) c.container.withDatabaseName(dbName) c } lazy val appCont = { val c = AppContainer(jdbcUrl, pgCont.username, pgCont.password) c.container.withNetwork(network) c } override def beforeAll(): Unit = { super.beforeAll() pgCont.start() appCont.start() } override def afterAll(): Unit = { super.afterAll() appCont.stop() pgCont.stop() network.close() } // tests here } 

अब हमें अपने jdbcUrl को मैन्युअल रूप से कॉन्फ़िगर करना होगा। हमें अपने कंटेनरों को नेटवर्क में सक्षम करने की भी आवश्यकता है, और PostgreSQLContainer के लिए अन्य नाम सेट करें ताकि यह नेटवर्क के भीतर कुछ डोमेन नाम से सुलभ हो। अंत में, आपको नेटवर्क को "मार" करना याद रखना चाहिए।

अंत में, ऐसा कार्यक्रम काम करेगा।

Testcontainers-scala के हाल के संस्करणों में, आलसी कंटेनर इनिशियलाइज़ेशन बॉक्स से बाहर समर्थित है:

 class MyTest extends FreeSpec with ForAllTestContainer with BeforeAndAfterAll { val network: Network = Network.newNetwork() val dbName = "some_db" val pgContainerAlias = "postgres" val jdbcUrl = s"jdbc:postgresql://$pgContainerAlias:5432/$dbName" lazy val pgCont = { val c = PostgreSQLContainer("postgres:9.6") c.container.withNetwork(network) c.container.withNetworkAliases(pgContainerAlias) c.container.withDatabaseName(dbName) c } lazy val appCont = { val c = AppContainer(jdbcUrl, pgCont.username, pgCont.password) c.container.withNetwork(network) c } override val container = MultipleContainers(pgCont, appCont) override def afterAll(): Unit = { super.afterAll() network.close() } // tests here } 

आप ForAllTestContainer और MultipleContainers फिर से उपयोग कर सकते हैं। पहले beforeAll प्रारंभ आदेश को मैन्युअल रूप से beforeAll करने की आवश्यकता नहीं है। अब मल्टीपलरटेनर आलसी वैल के साथ काम कर सकते हैं और उन्हें सही क्रम में चला सकते हैं, और निर्माण पर तुरंत सख्त आरंभीकरण नहीं करते हैं। इसी समय, कस्टम नेटवर्क और jdbcUrl के साथ हेरफेर भी मैन्युअल रूप से करने की आवश्यकता है।

mocks

हालांकि, अभी भी समस्याएं हैं। उदाहरण के लिए मोकी। कभी-कभी डॉकटर कंटेनर में किसी प्रकार की निर्भरता बनाने के लिए यह बहुत सुविधाजनक नहीं होता है। हम स्पार्क जॉबसर्वर का उपयोग करते हैं, जो स्पार्क नौकरियां बनाता है और स्पार्क में उनके जीवन चक्र को नियंत्रित करता है। हम इसके दो तरीकों का उपयोग करते हैं: "बनाएँ" और "स्थिति दें"।

डॉक के अंदर स्पार्क जोबसेवर चलाने के लिए। स्पार्क को उठाना आवश्यक है, और हाल ही में जब तक, इसमें डॉक कंटेनर नहीं था और इसे स्वयं इकट्ठा करना आवश्यक था। इसके अलावा, स्पार्क जॉबसेवर राज्यों को स्टोर करने के लिए PostgreSQL का उपयोग करता है। नतीजतन, आपको बहुत मुश्किल काम करना पड़ता है जब आपको वास्तव में एक साधारण एपीआई के साथ केवल दो तरीकों की आवश्यकता होती है।

लेकिन आप स्पार्क जोबसेवर के कार्यान्वयन में झाँक सकते हैं और एक ऐसा मॉक बना सकते हैं जो समान व्यवहार करता है, लेकिन मूल स्पार्क जोबसेवर की निर्भरता की आवश्यकता नहीं है।

यह इस तरह दिखता है (उदाहरण में, एक सरल छद्म कोड):

 val hostIp = ??? AppContainer(sparkJobServerMockHost = hostIp) val sparkJobServerMock = new SparkJobServerMock() sparkJobServerMock.init(someData) val apiResult = appApi.callMethod() assert(apiResult == someData) 

http- API Spark JobServer. - , . , , , mock.

- , . : «» config; , host.

SparkJobServerMock , host-, docker-, , , docker-.

? docker-, , gateway , docker-.

, Testcontainers API. , Testcontainers docker-java-, . «» docker-:

 val client: com.github.dockerjava.api.DockerClient = DockerClientFactory .instance .client val networkInfo: com.github.dockerjava.api.model.Network = client .inspectNetworkCmd() .withNetworkId(network.getId) .exec() val hostIp: String = networkInfo .getIpam .getConfig .get(0) .getGateway 

-, DockerClient . Testcontainers DockerClientFactory . c inspectNetworkCmd . , info, gateway.

, , .

— . Docker : Windows, Mac, . Linux. , , Linux .

, Testcontainers . , docker-. :

 Testcontainers.exposeHostPorts(sparkJobServerMockPort) 

, . docker-. `host.testcontainers.internal` .

, :

 val sparkJobServerMockHost = "host.testcontainers.internal" val sparkJobServerMockPort = 33333 Testcontainers.exposeHostPorts(sparkJobServerPort) AppContainer(sparkJobServerMockHost, sparkJobServerMockPort) 

Testcontainers

, , Testcontainers , . Java-, Scala-. :

• . , testcontainers-java JUnit, testcontainers-scala ScalaTest, testcontainers-java . Scala- .
• Scala . . , . , predefined Java-. , .
• API . API, . , . , , .

परिणाम

. Docker , , , , network gateway.

Testcontainers — , . API , .

Java-, . — . .

, docker-, .

Scala – ScalaConf . – HighLoad++ 7-8 .

, , , , .