एकता परीक्षण नोट कुबेरनेट्स पर जेनकींस का उपयोग करना

शुभ दोपहर

पिछले पोस्ट के निर्देशों के अनुसार CI / CD को स्थापित करने और कॉन्फ़िगर करने के लगभग तुरंत बाद, टीम के पास एक सवाल था कि एकीकरण परीक्षण को कैसे ठीक से किया जाए। हमारे पास पहले से ही डॉकटर कंटेनरों में परीक्षण निर्भरता चलाने का अनुभव था, लेकिन यह समस्याग्रस्त हो गया है क्योंकि असेंबली को अब कंटेनर में लॉन्च किया गया था। इस लेख में, मैं कंटेनर के अंदर एकीकरण परीक्षण के दो संभावित तरीकों का वर्णन करना चाहूंगा जो मेरी टीम के अनुकूल हैं।

एकीकरण परीक्षण आवश्यकताएँ

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

परीक्षण के भाग के रूप में, हम चाहते थे:

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

इन आवश्यकताओं के आधार पर, हमने असेंबली के बीच साझा संसाधनों के साथ समस्याओं और इस बुनियादी ढांचे को बनाए रखने और बदलने की कठिनाई के कारण परीक्षण डेटाबेस और कतार के स्थायी सामान्य प्रतिष्ठानों के विचार को तुरंत त्याग दिया।

विकल्प 1: एंबेडेड समाधान

जावा पारिस्थितिकी तंत्र में काफी कुछ पुस्तकालय हैं जो एक परीक्षण के लिए एक निर्भरता चलाते हैं:

• kafka: https://github.com/chbatey/kafka-unit / https://github.com/spring-projects/spring-kafka / https://github.com/manub/scalatest-emded-kafka
• कैसेंड्रा
• postgres
• बाकी आपी

यह दृष्टिकोण जितना संभव हो उतना सरल है और पहले बताई गई अधिकांश आवश्यकताओं को पूरा करता है, लेकिन नई परीक्षण निर्भरता (mysql?) को जोड़ने या निर्भरता के विशिष्ट या कई संस्करणों का उपयोग करने के मामले में सार्वभौमिक नहीं है।

अच्छी तरह से 1-2 निर्भरता के साथ सरल सेवाओं के लिए उपयुक्त है।

विकल्प 2: परीक्षणकर्ता

डॉकर पिछले दृष्टिकोण की कमियों को हल करने का एक तार्किक तरीका है: आप किसी भी संस्करण के साथ किसी भी निर्भरता के लिए (या डॉकर छवि बना सकते हैं) पा सकते हैं। संभवतः उत्पादन में कुछ निर्भरताएँ समान छवियों का उपयोग करके चल रही हैं।

यदि स्थानीय रूप से छवि को लॉन्च करना (या डॉकटर-कंपोज़ का उपयोग करके) कोई समस्या नहीं है, तो सीआई पर मुश्किलें आएंगी क्योंकि असेंबली खुद कंटेनर में जगह लेती है। हालांकि docker में docker को चलाना संभव है, यह dind निर्माता द्वारा अनुशंसित नहीं है । इस समस्या के आसपास आने का पसंदीदा तरीका पहले से चल रही डॉकटर प्रक्रिया का पुन: उपयोग करना है, जिसे अक्सर सिबलिंग डॉकटर कहा जाता है। ऐसा करने के लिए, आपको माता-पिता से /var/run/docker.sock का उपयोग करने के लिए /var/run/docker.sock प्रक्रिया की आवश्यकता है। पिछले पोस्ट में, यह पहले से ही संकलित एप्लिकेशन के साथ docker की छवियों को प्रकाशित करने के लिए उपयोग किया गया था।

यह परीक्षण करने वाले पुस्तकालय का उपयोग करने का निर्णय लिया गया था क्योंकि यह:

• एक अच्छी निर्भरता प्रबंधन एपीआई प्रदान करता है
• सबसे लोकप्रिय डेटाबेस और कतारों के साथ एकीकरण है
• कंटेनर में चलने पर सिबलिंग डॉक दृष्टिकोण का उपयोग करता है
• स्थानीय स्तर पर और ci पर समान कार्य करता है
• विधानसभा के बाद कंटेनरों को रोकता है

अच्छी तरह से अधिक जटिल सेवाओं के लिए या विशेष निर्भरता आवश्यकताओं के साथ सेवाओं के लिए उपयुक्त है।

संसाधन प्रबंधन

अगला, आपको प्रोजेक्ट असेंबली द्वारा संसाधन खपत पर ध्यान देना चाहिए (जो एकीकरण परीक्षणों को जोड़ने के बाद काफी बढ़ सकता है)।

फिलहाल, मेमोरी और सीपीयू शेयरों की आवश्यक मात्रा को इंगित नहीं करता है, जो दो संभावित समस्याएं हो सकती हैं:

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

आप निर्माण का उपयोग करके चूल्हा में कंटेनर के संसाधनों को सीमित कर सकते हैं:

  resources: requests: cpu: 1 memory: 512Mi limits: cpu: 1 memory: 512Mi 

Jdk9 और उससे ऊपर के पास पहले से ही एक कंटेनर में काम करने के लिए समर्थन है (-XX: + UseContainerSupport (डिफ़ॉल्ट रूप से सक्षम), -XX के साथ संयोजन में काम करता है: InitialRAMPercentage / -XX: MaxRAMPercentage)

इसका पूरा उदाहरण यहां देखा जा सकता है ।

Jdk8 को सही तरीके से काम करने के लिए, या तो अपडेट करना है या -XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap साथ 131 या उच्चतर की आवश्यकता है -XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap cgroup से उपलब्ध मेमोरी पढ़ने के लिए और होस्ट मशीन से नहीं, या हर बार उपलब्ध ढेर आकार को मैन्युअल रूप से Xmx का उपयोग करते हुए पढ़ने के लिए -XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap है।
एक उदाहरण यहाँ उपलब्ध है ।

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

निष्कर्ष

एक कंटेनर में एक निर्माण शुरू करते समय एकीकरण परीक्षण संभव है और मुश्किल काम नहीं है।

Testcontainers का उपयोग करके एकीकरण परीक्षणों के साथ एक उदाहरण एप्लिकेशन यहां आप पा सकते हैं और यहां कुबेरनेट्स पर जेनकिंस को चलाने के लिए कॉन्फ़िगरेशन।