🔸 🧚🏼 👨‍👩‍👧‍👧 Kubernetes पर जेनकिन्स का उपयोग करते हुए सीआई / सीडी 🕛 👨🏾‍🎨 🔲

शुभ दोपहर

जेनकींस, ci / cd और kubernetes के बारे में Habré पर पहले से ही कई लेख हैं, लेकिन इसमें मैं इन प्रौद्योगिकियों की क्षमताओं का विश्लेषण करने पर ध्यान केंद्रित नहीं करना चाहता, लेकिन ci / dd पाइपलाइन के निर्माण के लिए उनके सरलतम विन्यास पर।

मेरा मतलब है कि पाठक को डॉकटर की बुनियादी समझ है, और मैं कुबेरनेट को स्थापित करने और कॉन्फ़िगर करने के विषयों पर ध्यान केंद्रित नहीं करूंगा। सभी उदाहरण मिनीक्यूब पर दिखाए जाएंगे, लेकिन ईकेएस, जीकेके, या जैसे महत्वपूर्ण परिवर्तनों के बिना भी लागू किया जा सकता है।

प्रतिवेश

मैं निम्नलिखित वातावरण का उपयोग करने का सुझाव देता हूं:

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

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

इस उदाहरण में, प्रत्येक नेमस्पेस में इस वातावरण के विन्यास के साथ कॉन्फ़िगरमैप का एक ही सेट होगा:

apiVersion: v1 kind: Namespace metadata: name: production --- apiVersion: v1 kind: ConfigMap metadata: name: environment.properties namespace: production data: environment.properties: | env=production

पतवार

हेल्म एक एप्लिकेशन है जो कुबेरनेट पर स्थापित संसाधनों को प्रबंधित करने में मदद करता है।
स्थापना निर्देश यहां देखे जा सकते हैं ।
आरंभ करने के लिए, आपको क्लस्टर के साथ पतवार का उपयोग करने के लिए टिलर पॉड को इनिशियलाइज़ करना होगा:

 helm init

जेनकींस

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

 helm install --name jenkins --namespace jenkins -f jenkins/demo-values.yaml stable/jenkins

Demo-values.yaml में जेनकिंस संस्करण, पूर्व-स्थापित प्लगइन्स का एक सेट, एक डोमेन नाम और अन्य कॉन्फ़िगरेशन शामिल हैं

डेमो values.yaml

 Master: Name: jenkins-master Image: "jenkins/jenkins" ImageTag: "2.163-slim" OverwriteConfig: true AdminUser: admin AdminPassword: admin InstallPlugins: - kubernetes:1.14.3 - workflow-aggregator:2.6 - workflow-job:2.31 - credentials-binding:1.17 - git:3.9.3 - greenballs:1.15 - google-login:1.4 - role-strategy:2.9.0 - locale:1.4 ServicePort: 8080 ServiceType: NodePort HostName: jenkins.192.168.99.100.nip.io Ingress: Path: / Agent: Enabled: true Image: "jenkins/jnlp-slave" ImageTag: "3.27-1" #autoadjust agent resources limits resources: requests: cpu: null memory: null limits: cpu: null memory: null #to allow jenkins create slave pods rbac: install: true

यह कॉन्फ़िगरेशन लॉगिन के लिए उपयोगकर्ता नाम और पासवर्ड के रूप में व्यवस्थापक / व्यवस्थापक का उपयोग करता है, और बाद में पुन: कॉन्फ़िगर किया जा सकता है। संभावित विकल्पों में से एक google SSO है (इसके लिए google-login plugin की आवश्यकता है, इसकी सेटिंग Jenkins> Manage Jenkins> Configure Global Security> Access Control> Security Realm> Login with Google) में स्थित हैं।

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

बॉक्स से बाहर भी, PersistenceVolume को पुनः आरंभ या अद्यतन करते समय पाइपलाइनों को बचाने के लिए कॉन्फ़िगर किया गया है।

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

 kubectl create clusterrolebinding jenkins --clusterrole cluster-admin --serviceaccount=jenkins:default

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

 helm upgrade jenkins stable/jenkins -f jenkins/demo-values.yaml

यह जेनकिंस के इंटरफ़ेस के माध्यम से ही किया जा सकता है, लेकिन पतवार के साथ आपको पिछले संशोधनों का उपयोग करने के लिए वापस रोल करने का अवसर मिलेगा:

 helm history jenkins helm rollback jenkins ${revision}

आवेदन का निर्माण

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

विधानसभा निम्नलिखित अनुक्रम में होगी:

जांच
संकलन
इकाई परीक्षण
एकीकरण परीक्षण
विरूपण साक्ष्य विधानसभा
डॉकटर रजिस्ट्री में विरूपण साक्ष्य तैनाती
मंचन के लिए कलाकृतियों की तैनाती (केवल मास्टर शाखा के लिए)

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

जांच

Bitbucket या github संगठन के मामले में, आप Jenkins को समय-समय पर Jenkinsfile के साथ रिपॉजिटरी के लिए पूरे खाते को स्कैन करने के लिए कॉन्फ़िगर कर सकते हैं और स्वचालित रूप से उनके लिए असेंबली बना सकते हैं। जेनकिंस मास्टर और शाखाओं दोनों को इकट्ठा करेगा। खींचे गए अनुरोधों को एक अलग टैब में प्रदर्शित किया जाएगा। एक सरल विकल्प है - एक अलग गिट रिपॉजिटरी जोड़ें, जहां यह होस्ट किया गया है, चाहे। इस उदाहरण में, मैं बस यही करूँगा। जेनकिंस> नई आइटम> मल्टीब्रांच पाइपलाइन मेन्यू में सभी आवश्यक है, असेंबली नाम का चयन करें और गिट रिपॉजिटरी को बांधें।

संकलन

चूंकि जेनकिन्स प्रत्येक विधानसभा के लिए एक नया पॉड बनाता है, मावेन या समान कलेक्टरों का उपयोग करने के मामले में, निर्भरताएं हर बार फिर से डाउनलोड की जाएंगी। इससे बचने के लिए, आप .m2 या समान कैश के लिए PersistenceVolume आवंटित कर सकते हैं और इसे पॉड में माउंट कर सकते हैं जो प्रोजेक्ट बनाता है।

 apiVersion: "v1" kind: "PersistentVolumeClaim" metadata: name: "repository" namespace: "jenkins" spec: accessModes: - ReadWriteMany resources: requests: storage: 10Gi

मेरे मामले में, इसने पाइपलाइन को लगभग 4 से 1 मिनट तक गति देने की अनुमति दी।

वर्ज़निंग

CI / CD के सही ढंग से काम करने के लिए, प्रत्येक बिल्ड को एक विशिष्ट संस्करण की आवश्यकता होती है।

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

इस उदाहरण में, मैं आईडी और कमिट की तारीख से एक संस्करण उत्पन्न करूंगा, साथ ही शाखा का नाम, अगर यह मास्टर नहीं है। उदाहरण के लिए 56e0fbdc-201802231623 या b3d3c143-201802231548-PR-18 ।

इस दृष्टिकोण के लाभ:

स्वचालन में आसानी
स्रोत कोड और इसके निर्माण का समय संस्करण से प्राप्त करना आसान है
नेत्रहीन, आप उम्मीदवार के रिलीज़ संस्करण (विज़ार्ड से) या प्रयोगात्मक (शाखा से) को अलग कर सकते हैं
लेकिन:
यह संस्करण मौखिक संचार में उपयोग करना कठिन है
यह स्पष्ट नहीं है कि क्या असंगत परिवर्तन थे।

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

कलाकृतियों

विधानसभा का परिणाम होगा:

एक आवेदन के साथ docker की छवि जो संग्रह और docker रजिस्ट्री से लोड की जाएगी। उदाहरण मिनीक्यूब से अंतर्निहित रजिस्ट्री का उपयोग करेगा, जिसे डॉकटर हब या अमेज़ॅन (ईक्र) या Google से एक निजी रजिस्ट्री से बदला जा सकता है (withCredentials निर्माण का उपयोग करके उन्हें क्रेडेंशियल्स प्रदान करना न भूलें)।
पतवार निर्देशिका में अनुप्रयोग की तैनाती (तैनाती, सेवा, आदि) के वर्णन के साथ पतवार चार्ट। आदर्श रूप से, उन्हें कलाकृतियों के एक अलग भंडार पर संग्रहित किया जाना चाहिए, लेकिन, सरलीकरण के लिए, उन्हें आवश्यक प्रतिबद्ध से बाहर की जाँच करके इस्तेमाल किया जा सकता है।

Jenkinsfile

नतीजतन, आवेदन निम्नलिखित जेनकिंसफाइल का उपयोग करके बनाया जाएगा:

Jenkinsfile

 def branch def revision def registryIp pipeline { agent { kubernetes { label 'build-service-pod' defaultContainer 'jnlp' yaml """ apiVersion: v1 kind: Pod metadata: labels: job: build-service spec: containers: - name: maven image: maven:3.6.0-jdk-11-slim command: ["cat"] tty: true volumeMounts: - name: repository mountPath: /root/.m2/repository - name: docker image: docker:18.09.2 command: ["cat"] tty: true volumeMounts: - name: docker-sock mountPath: /var/run/docker.sock volumes: - name: repository persistentVolumeClaim: claimName: repository - name: docker-sock hostPath: path: /var/run/docker.sock """ } } options { skipDefaultCheckout true } stages { stage ('checkout') { steps { script { def repo = checkout scm revision = sh(script: 'git log -1 --format=\'%h.%ad\' --date=format:%Y%m%d-%H%M | cat', returnStdout: true).trim() branch = repo.GIT_BRANCH.take(20).replaceAll('/', '_') if (branch != 'master') { revision += "-${branch}" } sh "echo 'Building revision: ${revision}'" } } } stage ('compile') { steps { container('maven') { sh 'mvn clean compile test-compile' } } } stage ('unit test') { steps { container('maven') { sh 'mvn test' } } } stage ('integration test') { steps { container ('maven') { sh 'mvn verify' } } } stage ('build artifact') { steps { container('maven') { sh "mvn package -Dmaven.test.skip -Drevision=${revision}" } container('docker') { script { registryIp = sh(script: 'getent hosts registry.kube-system | awk \'{ print $1 ; exit }\'', returnStdout: true).trim() sh "docker build . -t ${registryIp}/demo/app:${revision} --build-arg REVISION=${revision}" } } } } stage ('publish artifact') { when { expression { branch == 'master' } } steps { container('docker') { sh "docker push ${registryIp}/demo/app:${revision}" } } } } }

आवेदन जीवन चक्र प्रबंधन के लिए अतिरिक्त जेनकींस पाइपलाइन

मान लीजिए कि रिपॉजिटरी का आयोजन किया जाता है ताकि:

डॉकटर छवि के रूप में एक अलग एप्लिकेशन रखें
पतवार निर्देशिका में स्थित पतवार फ़ाइलों का उपयोग करके तैनात किया जा सकता है
एक ही दृष्टिकोण का उपयोग करके संस्करणबद्ध किया गया है और पतवार चार्ट में संशोधन सेट करने के लिए एक helm / setVersion.sh फ़ाइल है

तो हम आवेदन जीवन चक्र का प्रबंधन करने के लिए कई जेनकिंसफाइल पाइपलाइनों का निर्माण कर सकते हैं, अर्थात्:

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

जेनकींस ने पाइप लाइन कॉल की तैनाती की

 ... stage ('deploy to env') { when { expression { branch == 'master' || params.DEPLOY_BRANCH_TO_TST } } steps { build job: './../Deploy', parameters: [ [$class: 'StringParameterValue', name: 'GIT_REPO', value: 'habr-demo-app'], [$class: 'StringParameterValue', name: 'VERSION', value: revision], [$class: 'StringParameterValue', name: 'ENV', value: branch == 'master' ? 'staging' : 'test'] ], wait: false } } ...

यहां आप सभी चरणों के साथ जेनकिंसफाइल पा सकते हैं।

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

निष्कर्ष

Jenkinsfile और helm का उपयोग करके, आप बस अपने आवेदन के लिए ci / cd बना सकते हैं। यह विधि उन छोटी टीमों के लिए सबसे अधिक प्रासंगिक हो सकती है जिन्होंने हाल ही में कुबेरनेट का उपयोग करना शुरू किया है और ऐसी सेवाओं का उपयोग करने में असमर्थ (कारण की परवाह किए बिना) हैं जो बॉक्स से बाहर इस तरह की कार्यक्षमता प्रदान कर सकते हैं।

आप यहां के जीवन चक्र के प्रबंधन के लिए वातावरण, जेनकिंस और पाइपलाइन के लिए कॉन्फ़िगरेशन उदाहरण और यहां जेनकिंसफाइल के साथ एक उदाहरण आवेदन पा सकते हैं ।

Kubernetes पर जेनकिन्स का उपयोग करते हुए सीआई / सीडी