🌳 🤜🏾 💩 GitLab CI में कस्टम वर्कफ़्लोज़ बनाने के लिए टिप्स 🆒 ⛹️ 😑

लगभग। ट्रांस। : मूल लेख Miłosz Smółka द्वारा लिखा गया था, जो कि छोटी पोलिश कंपनी थ्री डॉट्स लैब्स के संस्थापकों में से एक है, जो "उन्नत बैकेंड समाधान" में विशेषज्ञता रखता है। लेखक GitLab CI के सक्रिय उपयोग में अपने अनुभव पर आकर्षित करता है और इस ओपन सोर्स उत्पाद के अन्य उपयोगकर्ताओं के लिए संचित युक्तियाँ साझा करता है। उन्हें पढ़ने के बाद, हमने महसूस किया कि उनके द्वारा बताई गई समस्याएं हमारे कितने करीब हैं, इसलिए हमने प्रस्तावित समाधानों को व्यापक दर्शकों के साथ साझा करने का निर्णय लिया।

इस बार मैं GitLab CI में अधिक उन्नत विषयों को शामिल करूंगा। यहां एक सामान्य कार्य पाइपलाइन में गैर-मानक सुविधाओं को लागू करना है। अधिकांश युक्तियाँ GitLab के लिए विशिष्ट हैं, हालांकि उनमें से कुछ को अन्य CI सिस्टम पर लागू किया जा सकता है।

एकीकरण परीक्षण चलाएं

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

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

गिटलैब में, प्लग करने योग्य संसाधनों को चलाना आसान होता है क्योंकि डॉकटर कंटेनर से जुड़ा होता है जहाँ स्क्रिप्ट चल रही होती है। services उपयोग से इन निर्भरताओं को परिभाषित किया जा सकता है। वे छवि के नाम से या अपनी पसंद के नाम से उपलब्ध हैं, यदि आप इसे alias क्षेत्र में निर्दिष्ट करते हैं।

यहां MySQL के साथ प्लग करने योग्य कंटेनर का उपयोग करने का एक सरल उदाहरण है:

 integration_tests: stage: tests services: - name: mysql:8 alias: db script: - ./run_tests.sh db:3306

इस मामले में, परीक्षण स्क्रिप्ट में आपको db होस्ट से कनेक्ट करने की आवश्यकता होगी। एक उपनाम का उपयोग करना आमतौर पर एक अच्छा विचार है, क्योंकि यह आपको परीक्षण कोड को संशोधित करने की आवश्यकता के बिना छवियों को बदलने की अनुमति देता है। उदाहरण के लिए, आप mysql छवि को mariadb बदल सकते हैं, और स्क्रिप्ट अभी भी सही ढंग से काम करेगी।

कंटेनरों का इंतजार है

चूंकि प्लग-इन कंटेनर लोड होने में समय लेते हैं, इसलिए आपको कोई भी अनुरोध भेजने से पहले इंतजार करना पड़ सकता है। एक आसान तरीका है एक निर्धारित समय समाप्ति के साथ वेट-फॉर-it.sh स्क्रिप्ट।

Docker Compose का उपयोग करना

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

 version: '3' services: zookeeper: image: confluentinc/cp-zookeeper environment: ZOOKEEPER_CLIENT_PORT: 2181 kafka: image: confluentinc/cp-kafka environment: KAFKA_ZOOKEEPER_CONNECT: zookeeper:2181 KAFKA_ADVERTISED_LISTENERS: PLAINTEXT://kafka:9092 ports: - 9092:9092

यदि आप भरोसेमंद सर्वर पर GitLab धावकों के साथ अपने इंस्टॉलेशन का उपयोग करते हैं, तो आप शेल निष्पादक के माध्यम से डॉकर कम्पोजर चला सकते हैं। एक अन्य संभावित विकल्प डोकर ( dind ) dind में डॉकर है । लेकिन इस मामले में, पहले इस लेख को पढ़ें।

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

 docker-compose up -d ./run_tests.sh localhost:9092 docker-compose down

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

 version: '3' services: zookeeper: image: confluentinc/cp-zookeeper environment: ZOOKEEPER_CLIENT_PORT: 2181 kafka: image: confluentinc/cp-kafka environment: KAFKA_ZOOKEEPER_CONNECT: zookeeper:2181 KAFKA_ADVERTISED_LISTENERS: PLAINTEXT://kafka:9092 tests: image: registry.example.com/some-image command: ./run_tests.sh kafka:9092

ध्यान दें कि हमने बंदरगाहों को मैप करने की आवश्यकता को समाप्त कर दिया है। इस उदाहरण में, परीक्षण सभी सेवाओं के साथ सीधे बातचीत कर सकते हैं।

और उनका प्रक्षेपण एक आदेश द्वारा किया जाता है:

 docker-compose up --exit-code-from tests

--exit-code-from --abort-on-container-exit तात्पर्य है --abort-on-container-exit , जिसका अर्थ है: --abort-on-container-exit द्वारा शुरू किया गया पूरा वातावरण कंटेनरों के पूरा होने के बाद बंद हो जाएगा। इस कमांड के लिए पूरा होने वाला कोड चयनित सेवा के निकास कोड के बराबर होगा (यानी ये ऊपर के उदाहरण में tests हैं)। यदि आदेश जो परीक्षण शुरू करता है वह गैर-शून्य कोड के साथ पूरा होता है, तो संपूर्ण docker-compose up इसके साथ बाहर निकल जाएगा।

CI टैग के रूप में लेबल का उपयोग करना

चेतावनी : यह एक असामान्य विचार है, लेकिन यह मुझे बहुत उपयोगी और लचीला लग रहा था।

जैसा कि आप जानते हैं, GitLab में परियोजना और समूह स्तर पर एक लेबल सुविधा उपलब्ध है। लेबल टिकट और मर्ज अनुरोध पर सेट किए जा सकते हैं। हालांकि, पाइपलाइनों के साथ उनका कोई संबंध नहीं है।

थोड़ा शोधन आपको जॉब स्क्रिप्ट में मर्ज अनुरोध के लेबल तक पहुंचने की अनुमति देगा। GitLab 11.6 में, सब कुछ आसान हो गया है, क्योंकि CI_MERGE_REQUEST_IID पर्यावरण चर दिखाई दिया है (हाँ, यह IID साथ है, ID नहीं), यदि पाइपलाइन only: merge_requests उपयोग करती है only: merge_requests ।

यदि only: merge_requests उपयोग नहीं किया गया है या आप GitLab के पुराने संस्करण के साथ काम कर रहे हैं, तो MR को अभी भी प्राप्त किया जा सकता है - API कॉल का उपयोग करके:

 curl "$CI_API_V4_URL/projects/$CI_PROJECT_ID/repository/commits/$CI_COMMIT_SHA/merge_requests?private_token=$GITLAB_TOKEN"

हमें जिस क्षेत्र की आवश्यकता है वह है iid । हालांकि, याद रखें कि कई एमआर दिए गए कमिट के लिए वापस आ सकते हैं।

जब MR IID प्राप्त होता है, तो यह केवल मर्ज अनुरोध API को चालू करने और उत्तर से labels फ़ील्ड का उपयोग करने के लिए रहता है:

 curl "$CI_API_V4_URL/projects/$CI_PROJECT_ID/merge_requests/$CI_MERGE_REQUEST_IID?private_token=$GITLAB_TOKEN"

प्राधिकरण

दुर्भाग्य से, इस समय परियोजना एपीआई तक पहुँचने के लिए $CI_JOB_TOKEN का उपयोग करना संभव नहीं है (कम से कम अगर परियोजना सार्वजनिक नहीं है)। यदि प्रोजेक्ट में सीमित पहुंच (आंतरिक या निजी) है, तो GitLab API में प्राधिकरण के लिए आपको एक व्यक्तिगत API टोकन जनरेट करना होगा।

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

आपके चर कितने सुरक्षित हैं?

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

किसी भी चर को जोड़ते समय इसे ध्यान में रखें और रहस्यों को अधिक सुरक्षित समाधानों में रखने पर विचार करें (उदाहरण के लिए, होशियारपुर से वॉल्ट )।

मामलों का उपयोग करें

लेबल की सूचियों के साथ क्या करना है आप पर निर्भर है। यहाँ कुछ विचार हैं:

उन्हें सेगमेंट टेस्ट के लिए उपयोग करें।
एक विभाजक के रूप में एक बृहदान्त्र के साथ कुंजी-मूल्य शब्दार्थ का उपयोग करें (जैसे tests:auth जैसे लेबल tests:auth , tests:user )
नौकरियों के लिए कुछ सुविधाएँ शामिल करें।
यदि लेबल मौजूद है तो विशिष्ट नौकरियों के डिबगिंग की अनुमति दें।

बाहरी एपीआई कॉलिंग

यद्यपि गिटलैब पहले से ही उपलब्ध सुविधाओं की एक श्रृंखला के साथ आता है, यह बहुत संभावना है कि आप अन्य उपयोगिताओं का उपयोग करना चाहेंगे जो पाइपलाइनों के साथ एकीकृत हो सकते हैं। इसे लागू करने का सबसे सरल तरीका, निश्चित रूप से, अच्छे पुराने curl कॉल करना है।

यदि आप अपने स्वयं के उपकरण बनाते हैं, तो आप उन्हें GitLab Webhooks (परियोजना सेटिंग्स में एकीकरण टैब देखें) सुनने के लिए सिखा सकते हैं। हालांकि, यदि आप उन्हें किसी भी महत्वपूर्ण प्रणाली के साथ उपयोग करने का इरादा रखते हैं, तो सुनिश्चित करें कि वे उच्च उपलब्धता आवश्यकताओं को पूरा करते हैं।

उदाहरण: ग्राफाना एनोटेशन

यदि आप ग्राफ्टाना के साथ काम करते हैं, तो एनोटेशन चार्ट पर समय के साथ होने वाली घटनाओं को चिह्नित करने का एक शानदार तरीका है। उन्हें न केवल मैन्युअल रूप से GUI में क्लिक करके जोड़ा जा सकता है, बल्कि Grafana REST API को कॉल करके भी जोड़ा जा सकता है :

एपीआई का उपयोग करने के लिए, आपको एक एपीआई कुंजी उत्पन्न करनी होगी। सीमित पहुंच के साथ एक अलग उपयोगकर्ता बनाने पर विचार करें:

परियोजना सेटिंग्स में दो चर को परिभाषित करें:

GRAFANA_URL - Grafana स्थापना का URL (उदाहरण के लिए, https://grafana.example.com );
GRAFANA_APIKEY - API के लिए कुंजी बनाई गई।

इसे पुन: उपयोग करने में सक्षम होने के लिए, स्क्रिप्ट को सामान्य स्क्रिप्ट के साथ भंडार में रखें :

 #!/bin/bash set -e if [ $# -lt 2 ]; then echo "Usage: $0 <text> <tag>" exit 1 fi readonly text="$1" readonly tag="$2" readonly time="$(date +%s)000" cat >./payload.json <<EOF { "text": "$text", "tags": ["$tag"], "time": $time, "timeEnd": $time } EOF curl -X POST "$GRAFANA_URL/api/annotations" \ -H "Authorization: Bearer $GRAFANA_APIKEY" \ -H "content-type: application/json" \ -d @./payload.json

अब आप सीआई कॉल को आवश्यक मापदंडों के साथ जोड़ सकते हैं:

 deploy: stage: deploy script: - $SCRIPTS_DIR/deploy.sh production - $SCRIPTS_DIR/grafana-annotation.sh "$VERSION deployed to production" deploy-production

ये कॉल CI कॉन्फ़िगरेशन को आसान बनाने के लिए deploy.sh स्क्रिप्ट में रखा जा सकता है।

बोनस: त्वरित सुझाव

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

केवल / को छोड़कर का उन्नत उपयोग

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

 only: refs: - branches variables: - $CI_COMMIT_REF_NAME =~ /^hotfix/

GitLab के पास प्रत्येक CI जॉब में कई पूर्वनिर्धारित चर हैं - उनका उपयोग करें।

यमल लंगर

नकल से बचने के लिए उनका उपयोग करें।

संस्करण 11.3 से, आप विस्तारित कीवर्ड का उपयोग भी कर सकते हैं:

 .common_before_script: &common_before_script before_script: - ... - ... deploy: <<: *common_before_script

विरूपण साक्ष्य बहिष्करण

डिफ़ॉल्ट रूप से, पाइपलाइन में एकत्रित सभी कलाकृतियों को बाद की सभी नौकरियों में स्थानांतरित कर दिया जाएगा। यदि आप स्पष्ट रूप से उन कलाकृतियों को सूचीबद्ध करते हैं जिन पर नौकरियां निर्भर करती हैं, तो आप समय और डिस्क स्थान बचा सकते हैं:

 dependencies: - build

या - इसके विपरीत - पूरी तरह से सब कुछ छोड़ दें यदि उनमें से कोई भी आवश्यक नहीं है:

 dependencies: []

गिट रणनीति

यदि रिपॉजिटरी क्लोनिंग छोड़ें तो नौकरी इन फाइलों का उपयोग नहीं करेगी:

 variables: GIT_STRATEGY: none

वह सब है!

पढ़ने के लिए धन्यवाद! प्रतिक्रिया और सवालों के लिए, मुझसे ट्विटर या रेडिट पर संपर्क करें।

अधिक GitLab युक्तियां पिछले पदों में पाई जा सकती हैं:

अनुवादक से पी.एस.

हमारे ब्लॉग में भी पढ़ें:

GitLab CI में कस्टम वर्कफ़्लोज़ बनाने के लिए टिप्स