इस तथ्य के बावजूद कि हर कोई जानता है कि आपके सॉफ़्टवेयर का परीक्षण करना महत्वपूर्ण और आवश्यक है, और कई लंबे समय से स्वचालित रूप से कर रहे हैं, इस तरह के लोकप्रिय उत्पादों का एक गुच्छा स्थापित करने के लिए हैब के खुले स्थानों में एक भी नुस्खा नहीं है (हमारे पसंदीदा) GitLab और JUnit के रूप में । इस अंतर को भरें!
परिचयात्मक
सबसे पहले, मैं संदर्भ को रेखांकित करूंगा:
- चूंकि हमारे सभी एप्लिकेशन कुबेरनेट्स में काम करते हैं, इसलिए हम उचित बुनियादी ढांचे में परीक्षण चलाने पर विचार करेंगे।
- असेंबली और परिनियोजन के लिए हम वेयरफ़ का उपयोग करते हैं (बुनियादी ढांचे के घटकों के अर्थ में, यह भी स्वचालित रूप से इसका अर्थ है कि हेल्म शामिल है)।
- मैं सीधे परीक्षण बनाने के विवरण में नहीं गया: हमारे मामले में, ग्राहक स्वयं परीक्षण लिखता है, और हम केवल यह सुनिश्चित करते हैं कि वे चलाए जा रहे हैं (और संबंधित रिपोर्ट मर्ज अनुरोध में उपलब्ध है)।
क्रियाओं का समग्र क्रम कैसा दिखेगा?
- एप्लिकेशन असेंबली - हम इस चरण के विवरण को छोड़ देंगे।
- एक अलग कुबेरनेट क्लस्टर नामस्थान और लॉन्च परीक्षण के लिए एप्लिकेशन को तैनात करें।
- GitLab द्वारा एक JUnit रिपोर्ट को कलाकृतियों और पार्सिंग के लिए खोजें।
- पहले से बनाए गए नामस्थान हटाएं।
अब - कार्यान्वयन के लिए!
समायोजन
गिटलब सी.आई.
आइए आवेदन की तैनाती का वर्णन करने और परीक्षण चलाने के लिए
.gitlab-ci.yaml टुकड़े के साथ शुरू करें। लिस्टिंग बदले में नहीं निकली, इसलिए यह पूरी तरह से टिप्पणियों के साथ पूरक है:
variables:
Kubernetes
अब
.helm/templates निर्देशिका में, जॉब के साथ एक
tests-job.yaml -
tests-job.yaml - परीक्षण और कुबेरनेट्स संसाधनों को चलाने के लिए इसकी आवश्यकता है। लिस्टिंग के बाद स्पष्टीकरण देखें:
{{- if eq .Values.global.run_tests "yes" }} --- apiVersion: v1 kind: ConfigMap metadata: name: tests-script data: tests.sh: | echo "======================" echo "${APP_NAME} TESTS" echo "======================" cd /app npm run test:ci cp report.xml /app/test_results/${CI_COMMIT_REF_SLUG}/ echo "" echo "" echo "" chown -R 999:999 /app/test_results/${CI_COMMIT_REF_SLUG} --- apiVersion: batch/v1 kind: Job metadata: name: {{ .Chart.Name }}-test annotations: "helm.sh/hook": post-install,post-upgrade "helm.sh/hook-weight": "2" "werf/watch-logs": "true" spec: activeDeadlineSeconds: {{ .Values.global.ci_timeout }} backoffLimit: 1 template: metadata: name: {{ .Chart.Name }}-test spec: containers: - name: test command: ['bash', '-c', '/app/tests.sh'] {{ tuple "application" . | include "werf_container_image" | indent 8 }} env: - name: env value: {{ .Values.global.env }} - name: CI_COMMIT_REF_SLUG value: {{ .Values.global.commit_ref_slug }} - name: APP_NAME value: {{ .Chart.Name }} {{ tuple "application" . | include "werf_container_env" | indent 8 }} volumeMounts: - mountPath: /app/test_results/ name: data - mountPath: /app/tests.sh name: tests-script subPath: tests.sh tolerations: - key: dedicated operator: Exists - key: node-role.kubernetes.io/master operator: Exists restartPolicy: OnFailure volumes: - name: data persistentVolumeClaim: claimName: {{ .Chart.Name }}-pvc - name: tests-script configMap: name: tests-script --- apiVersion: v1 kind: PersistentVolumeClaim metadata: name: {{ .Chart.Name }}-pvc spec: accessModes: - ReadWriteOnce resources: requests: storage: 10Mi storageClassName: {{ .Chart.Name }}-{{ .Values.global.commit_ref_slug }} volumeName: {{ .Values.global.commit_ref_slug }} --- apiVersion: v1 kind: PersistentVolume metadata: name: {{ .Values.global.commit_ref_slug }} spec: accessModes: - ReadWriteOnce capacity: storage: 10Mi local: path: /mnt/tests/ nodeAffinity: required: nodeSelectorTerms: - matchExpressions: - key: kubernetes.io/hostname operator: In values: - kube-master persistentVolumeReclaimPolicy: Delete storageClassName: {{ .Chart.Name }}-{{ .Values.global.commit_ref_slug }} {{- end }}
इस कॉन्फ़िगरेशन में
कौन से संसाधन वर्णित
हैं ? परिनियोजित करते समय, प्रोजेक्ट के लिए एक अद्वितीय नामस्थान बनाएं (यह भी
.gitlab-ci.yaml -
tests-${CI_COMMIT_REF_SLUG} में इंगित किया गया है) और इसे इसमें रोल करें:
- एक परीक्षण स्क्रिप्ट के साथ कॉन्फ़िगर करें;
- फली और निर्दिष्ट
command निर्देश के विवरण के साथ नौकरी , जो सिर्फ परीक्षण चलाता है; - पीवी और पीवीसी , जो आपको परीक्षण डेटा संग्रहीत करने की अनुमति देता है।
प्रकट होने की शुरुआत में
if साथ परिचय की स्थिति पर ध्यान दें - तदनुसार, आवेदन के साथ हेल्म चार्ट की अन्य YAML फ़ाइलों को
रिवर्स निर्माण में लपेटा जाना चाहिए ताकि वे परीक्षण के दौरान तैनात न हों। वह है:
{{- if ne .Values.global.run_tests "yes" }} --- {{- end }}
हालाँकि, यदि परीक्षणों के
लिए कुछ बुनियादी ढाँचे की आवश्यकता होती है (उदाहरण के लिए, Redis, RabbitMQ, Mongo, PostgreSQL ...) - उनके YAML को बंद
किया जा
सकता है। उन्हें एक परीक्षा के माहौल में तैनात करें ... बेशक, जैसा चाहें वैसा ही ट्विक करें।
अंतिम स्पर्श
क्योंकि वेयरफ का उपयोग करके निर्माण और तैनाती अब तक
केवल बिल्ड सर्वर (गिटलैब-रनर के साथ) पर काम करता है, और परीक्षण के साथ पॉड विज़ार्ड पर चलता है, आपको विज़ार्ड पर
/mnt/tests निर्देशिका बनाने और धावक को इसे देने की आवश्यकता होगी,
उदाहरण के लिए, एनएफएस के माध्यम से । स्पष्टीकरण के साथ एक विस्तृत उदाहरण
K8s प्रलेखन में पाया जा सकता है।
परिणाम होगा:
user@kube-master:~$ cat /etc/exports | grep tests /mnt/tests IP_gitlab-builder/32(rw,nohide,insecure,no_subtree_check,sync,all_squash,anonuid=999,anongid=998) user@gitlab-runner:~$ cat /etc/fstab | grep tests IP_kube-master:/mnt/tests /mnt/tests nfs4 _netdev,auto 0 0
कोई भी GFSlab-runner पर सीधे NFS-बॉल बनाने से मना करता है, और फिर इसे पॉड्स में माउंट करता है।
टिप्पणी
आप पूछ सकते हैं, अय्यूब के निर्माण के साथ सब कुछ जटिल क्यों है, अगर आप सिर्फ शेल स्क्रिप्ट पर सीधे टेस्ट स्क्रिप्ट चला सकते हैं? जवाब काफी तुच्छ है ...
कुछ परीक्षणों को आधारभूत संरचना (MongoDB, RabbitMQ, PostgreSQL, आदि) तक पहुंच की आवश्यकता होती है ताकि उनके साथ काम करने की शुद्धता की जांच की जा सके। हम परीक्षण को एकीकृत करते हैं - इस दृष्टिकोण के साथ, इस तरह की अतिरिक्त संस्थाओं को शामिल करना आसान हो जाता है। इसके अलावा, हमें तैनाती में एक
मानक दृष्टिकोण मिलता है (भले ही एनएफएस का उपयोग करते हुए, अतिरिक्त निर्देशिका बढ़ते)।
परिणाम
जब हम तैयार कॉन्फ़िगरेशन लागू करेंगे तो हम क्या देखेंगे?
मर्ज अनुरोध, इसकी अंतिम पाइपलाइन में लॉन्च किए गए परीक्षणों पर सारांश आँकड़े दिखाएगा:
विवरण प्राप्त करने के लिए आप यहां प्रत्येक त्रुटि पर क्लिक कर सकते हैं:
NB : एक चौकस पाठक ध्यान देगा कि हम एक NodeJS एप्लिकेशन का परीक्षण कर रहे हैं, और स्क्रीनशॉट में - .NET ... आश्चर्यचकित न हों: लेख की तैयारी के हिस्से के रूप में, पहले आवेदन के परीक्षण में कोई त्रुटि नहीं थी, लेकिन वे दूसरे में पाए गए थे।निष्कर्ष
जाहिर है, कुछ भी जटिल नहीं है!
सिद्धांत रूप में, यदि आपके पास पहले से ही शेल-बिल्डर है और यह काम करता है, और आपको कुबेरनेट्स की आवश्यकता नहीं है, तो इसके लिए परीक्षण को खराब करना यहां वर्णित से भी अधिक सरल कार्य होगा। और
GitLab CI प्रलेखन में आपको रूबी, गो, ग्रैडल, मावेन और कुछ अन्य लोगों के उदाहरण मिलेंगे।
पुनश्च
हमारे ब्लॉग में भी पढ़ें: