🥇 OpenShift मा आधुनिक अनुप्रयोगहरू, भाग 3: विकास वातावरण र OpenShift पाइपलाइनहरूको रूपमा OpenShift

यस ब्लगमा सबैलाई नमस्कार! यो शृङ्खलाको तेस्रो पोष्ट हो जसमा हामीले Red Hat OpenShift मा आधुनिक वेब अनुप्रयोगहरू कसरी डिप्लोय गर्ने भनेर देखाउँछौं।

अघिल्ला दुई पोष्टहरूमा, हामीले केही चरणहरूमा आधुनिक वेब अनुप्रयोगहरू कसरी डिप्लोय गर्ने र कसरी नयाँ S2I छवि प्रयोग गर्ने भनेर देख्यौं, जस्तै NGINX, उत्पादन डिप्लोयमेन्टहरू अर्केस्ट्रेट गर्न चेन बिल्डहरू प्रयोग गरेर अफ-द-शेल्फ HTTP सर्भर छविको साथ। ।

आज हामी OpenShift प्लेटफर्ममा तपाइँको अनुप्रयोगको लागि विकास सर्भर कसरी चलाउने र यसलाई स्थानीय फाइल प्रणालीसँग सिङ्क्रोनाइज गर्ने भनेर देखाउनेछौं, र OpenShift पाइपलाइनहरू के हुन् र उनीहरूलाई लिङ्क गरिएको एसेम्बलीहरूको विकल्पको रूपमा कसरी प्रयोग गर्न सकिन्छ भन्ने बारे पनि कुरा गर्नेछौं।

विकास वातावरणको रूपमा OpenShift

विकास कार्यप्रवाह

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

धेरैजसो आधुनिक फ्रेमवर्कहरूमा, यस्तो "विकास सर्भर" सम्बन्धित कमाण्ड लाइन उपकरणहरूमा निर्मित हुन्छ।

स्थानीय उदाहरण

पहिले, स्थानीय रूपमा अनुप्रयोगहरू चलाउँदा यसले कसरी काम गर्छ हेरौं। एउटा उदाहरणको रूपमा आवेदन लिनुहोस् प्रतिक्रिया अघिल्लो लेखहरूबाट, यद्यपि लगभग समान कार्यप्रवाह अवधारणाहरू अन्य सबै आधुनिक फ्रेमवर्कहरूमा लागू हुन्छन्।
त्यसोभए, हाम्रो प्रतिक्रिया उदाहरणमा "देव सर्भर" सुरु गर्न, हामी निम्न आदेश प्रविष्ट गर्नेछौं:

$ npm run start

त्यसपछि टर्मिनल विन्डोमा हामी यो जस्तै केहि देख्नेछौं:

र हाम्रो अनुप्रयोग पूर्वनिर्धारित ब्राउजरमा खुल्नेछ:

अब, यदि हामीले फाइलमा परिवर्तन गर्छौं भने, अनुप्रयोग ब्राउजरमा अद्यावधिक हुनुपर्छ।

ठीक छ, स्थानीय मोडमा विकासको साथ सबै कुरा स्पष्ट छ, तर OpenShift मा कसरी प्राप्त गर्ने?

OpenShift मा विकास सर्भर

यदि तपाइँ सम्झनुहुन्छ भने, मा अघिल्लो पोस्ट, हामीले S2I छविको तथाकथित रन चरणमा हेर्यौं र देख्यौं कि पूर्वनिर्धारित रूपमा, सर्भ मोड्युल हाम्रो वेब अनुप्रयोगको सेवाको लागि जिम्मेवार छ।

यद्यपि, यदि तपाइँ नजिकबाट हेर्नुभयो भने लिपि चलाउनुहोस् त्यो उदाहरणबाट, यसले $NPM_RUN वातावरण चर समावेश गर्दछ, जसले तपाइँलाई तपाइँको आदेश कार्यान्वयन गर्न अनुमति दिन्छ।

उदाहरण को लागी, हामी हाम्रो अनुप्रयोग तैनात गर्न nodeshift मोड्युल प्रयोग गर्न सक्छौं:

$ npx nodeshift --deploy.env NPM_RUN="yarn start" --dockerImage=nodeshift/ubi8-s2i-web-app

नोट: माथिको उदाहरण सामान्य विचार चित्रण गर्न संक्षिप्त छ।

यहाँ हामीले हाम्रो डिप्लोइमेन्टमा NPM_RUN वातावरण चर थपेका छौं, जसले रनटाइमलाई यार्न स्टार्ट कमाण्ड चलाउनको लागि बताउँछ, जसले हाम्रो OpenShift पोड भित्र प्रतिक्रिया विकास सर्भर सुरु गर्छ।

यदि तपाइँ चलिरहेको पोडको लग हेर्नुभयो भने, यो केहि यस्तो देखिन्छ:

निस्सन्देह, हामीले स्थानीय कोडलाई कोडसँग सिङ्क्रोनाइज गर्न नसकेसम्म यो सबै केहि हुनेछैन, जुन परिवर्तनहरूको लागि पनि निगरानी गरिन्छ, तर रिमोट सर्भरमा रहन्छ।

रिमोट र स्थानीय कोड सिङ्क्रोनाइज गर्दै

सौभाग्य देखि, nodeshift सजिलै संग सिंक्रोनाइजेसन मद्दत गर्न सक्छ, र तपाइँ परिवर्तनहरू ट्र्याक गर्न वाच आदेश प्रयोग गर्न सक्नुहुन्छ।

त्यसोभए हामीले हाम्रो अनुप्रयोगको लागि विकास सर्भर डिप्लोय गर्न आदेश चलाइसकेपछि, हामी सुरक्षित रूपमा निम्न आदेश प्रयोग गर्न सक्छौं:

$ npx nodeshift watch

नतिजाको रूपमा, हामीले अलि पहिले सिर्जना गरेको चलिरहेको पोडमा जडान बनाइनेछ, रिमोट क्लस्टरसँग हाम्रा स्थानीय फाइलहरूको सिङ्क्रोनाइजेसन सक्रिय हुनेछ, र हाम्रो स्थानीय प्रणालीमा भएका फाइलहरू परिवर्तनहरूको लागि निगरानी गर्न सुरु हुनेछ।

त्यसकारण, यदि हामीले अब src/App.js फाइल अद्यावधिक गर्छौं भने, प्रणालीले यी परिवर्तनहरूमा प्रतिक्रिया दिनेछ, तिनीहरूलाई टाढाको क्लस्टरमा प्रतिलिपि गर्नेछ र विकास सर्भर सुरु गर्नेछ, जसले ब्राउजरमा हाम्रो अनुप्रयोग अद्यावधिक गर्नेछ।

तस्विर पूरा गर्न, यी सम्पूर्ण आदेशहरू कस्तो देखिन्छ देखाउनुहोस्:

$ npx nodeshift --strictSSL=false --dockerImage=nodeshift/ubi8-s2i-web-app --build.env YARN_ENABLED=true --expose --deploy.env NPM_RUN="yarn start" --deploy.port 3000

$ npx nodeshift watch --strictSSL=false

वाच आदेश oc rsync कमाण्डको शीर्षमा रहेको एउटा एब्स्ट्र्याकसन हो, यसले कसरी काम गर्छ भन्ने बारे थप जान्न सक्नुहुन्छ। यहाँ.

यो प्रतिक्रिया को लागी एक उदाहरण थियो, तर ठ्याक्कै उही विधि अन्य फ्रेमवर्क संग प्रयोग गर्न सकिन्छ, आवश्यक अनुसार NPM_RUN वातावरण चर सेट गर्नुहोस्।

ओपनशिफ्ट पाइपलाइनहरू

अर्को हामी OpenShift Pipelines जस्तै उपकरणको बारेमा कुरा गर्नेछौं र यसलाई कसरी जंजीर निर्माणको विकल्पको रूपमा प्रयोग गर्न सकिन्छ।

OpenShift पाइपलाइनहरू के हुन्

OpenShift Pipelines Tekton प्रयोग गरेर पाइपलाइनहरू व्यवस्थित गर्न डिजाइन गरिएको क्लाउड-नेटिभ CI/CD निरन्तर एकीकरण र डेलिभरी प्रणाली हो। Tekton एक लचिलो खुला स्रोत Kubernetes-नेटिभ CI/CD फ्रेमवर्क हो जसले तपाईंलाई अन्तर्निहित तहबाट सार गरेर विभिन्न प्लेटफर्महरू (कुबर्नेट्स, सर्भरलेस, भर्चुअल मेसिनहरू, आदि) मा डिप्लोइमेन्ट स्वचालित गर्न अनुमति दिन्छ।

यस लेखलाई बुझ्न पाइपलाइनहरूको केही ज्ञान चाहिन्छ, त्यसैले हामी दृढताका साथ सिफारिस गर्दछौं कि तपाइँ पहिले पढ्नुहोस् आधिकारिक पाठ्यपुस्तक.

आफ्नो कार्य वातावरण सेट अप गर्दै

यस लेखमा भएका उदाहरणहरूसँग खेल्न, तपाईंले पहिले आफ्नो काम गर्ने वातावरण तयार गर्न आवश्यक छ:

OpenShift 4 क्लस्टर स्थापना र कन्फिगर गर्नुहोस्। हाम्रा उदाहरणहरूले यसको लागि कोडरेडी कन्टेनरहरू (CRD) प्रयोग गर्छन्, जसको लागि स्थापना निर्देशनहरू फेला पार्न सकिन्छ। यहाँ.
क्लस्टर तयार भएपछि, तपाईंले यसमा पाइपलाइन अपरेटर स्थापना गर्न आवश्यक छ। नडराउनुहोस्, यो सजिलो छ, स्थापना निर्देशनहरू यहाँ.
डाउनलोड गर्नुहोस् Tekton CLI (tkn) यहाँ.
सिर्जना-प्रतिक्रिया-एप कमाण्ड लाइन उपकरण चलाउनुहोस् एउटा एप्लिकेसन सिर्जना गर्नका लागि जुन तपाईंले डिप्लोय गर्नुहुनेछ (यो एक साधारण अनुप्रयोग हो। प्रतिक्रिया).
(वैकल्पिक) npm स्थापना र त्यसपछि npm स्टार्टको साथ स्थानीय रूपमा उदाहरण अनुप्रयोग चलाउन भण्डार क्लोन गर्नुहोस्।

एप्लिकेसन रिपोजिटरीमा k8s फोल्डर पनि हुनेछ, जसमा एप डिप्लोय गर्न प्रयोग गरिने Kubernetes/OpenShift YAMLs समावेश हुनेछ। त्यहाँ टास्कहरू, क्लस्टर टास्कहरू, संसाधनहरू र पाइपलाइनहरू हुनेछन् जुन हामीले यसमा सिर्जना गर्नेछौं भण्डारहरू.

सुरु गरौं

हाम्रो उदाहरणको लागि पहिलो चरण OpenShift क्लस्टरमा नयाँ परियोजना सिर्जना गर्नु हो। यो परियोजना webapp-pipeline लाई कल गरौं र यसलाई निम्न आदेशको साथ सिर्जना गरौं:

$ oc new-project webapp-pipeline

यो परियोजनाको नाम पछि कोडमा देखा पर्नेछ, त्यसैले यदि तपाइँ यसलाई अरू केहि नाम दिने निर्णय गर्नुहुन्छ भने, उदाहरण कोड तदनुसार सम्पादन गर्न नबिर्सनुहोस्। यस बिन्दुबाट सुरु गर्दै, हामी माथि-डाउन जाने छैनौं, तर तल-माथि: त्यो हो, हामी पहिले कन्वेयरको सबै घटकहरू सिर्जना गर्नेछौं, र त्यसपछि मात्र कन्वेयर आफैं।

त्यसैले, सबै भन्दा पहिले ...

कार्यहरू

केही कार्यहरू सिर्जना गरौं, जसले त्यसपछि हाम्रो पाइपलाइन भित्र अनुप्रयोग प्रयोग गर्न मद्दत गर्नेछ। पहिलो कार्य - apply_manifests_task - हाम्रो अनुप्रयोगको k8s फोल्डरमा अवस्थित Kubernetes स्रोतहरू (सेवा, डिप्लोइमेन्ट र मार्ग) को YAML लागू गर्न जिम्मेवार छ। दोस्रो कार्य - update_deployment_task - हाम्रो पाइपलाइन द्वारा सिर्जना गरिएको छविमा पहिले नै तैनाथ गरिएको छवि अद्यावधिक गर्न जिम्मेवार छ।

चिन्ता नगर्नुहोस् यदि यो अझै धेरै स्पष्ट छैन भने। वास्तवमा, यी कार्यहरू उपयोगिताहरू जस्तै छन्, र हामी तिनीहरूलाई केही पछि थप विस्तारमा हेर्नेछौं। अहिलेको लागि, तिनीहरूलाई सिर्जना गरौं:

$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/tasks/update_deployment_task.yaml
$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/tasks/apply_manifests_task.yaml

त्यसपछि, tkn CLI आदेश प्रयोग गरेर, हामी कार्यहरू सिर्जना गरिएको छ भनेर जाँच गर्नेछौं:

$ tkn task ls

NAME                AGE
apply-manifests     1 minute ago
update-deployment   1 minute ago

नोट: यी तपाईंको हालको परियोजनाका लागि स्थानीय कार्यहरू हुन्।

क्लस्टर कार्यहरू

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

$ tkn clustertask ls

NAME                       AGE
buildah                    1 day ago
buildah-v0-10-0            1 day ago
jib-maven                  1 day ago
kn                         1 day ago
maven                      1 day ago
openshift-client           1 day ago
openshift-client-v0-10-0   1 day ago
s2i                        1 day ago
s2i-go                     1 day ago
s2i-go-v0-10-0             1 day ago
s2i-java-11                1 day ago
s2i-java-11-v0-10-0        1 day ago
s2i-java-8                 1 day ago
s2i-java-8-v0-10-0         1 day ago
s2i-nodejs                 1 day ago
s2i-nodejs-v0-10-0         1 day ago
s2i-perl                   1 day ago
s2i-perl-v0-10-0           1 day ago
s2i-php                    1 day ago
s2i-php-v0-10-0            1 day ago
s2i-python-3               1 day ago
s2i-python-3-v0-10-0       1 day ago
s2i-ruby                   1 day ago
s2i-ruby-v0-10-0           1 day ago
s2i-v0-10-0                1 day ago

अब दुई क्लस्टर कार्यहरू सिर्जना गरौं। पहिलोले S2I छवि उत्पन्न गर्नेछ र यसलाई आन्तरिक OpenShift रजिस्ट्रीमा पठाउनेछ; दोस्रो भनेको हामीले सामग्रीको रूपमा निर्माण गरिसकेका अनुप्रयोग प्रयोग गरेर NGINX मा आधारित हाम्रो छवि निर्माण गर्नु हो।

छवि सिर्जना गर्नुहोस् र पठाउनुहोस्

पहिलो कार्य सिर्जना गर्दा, हामी जोडिएको एसेम्बलीहरूको बारेमा अघिल्लो लेखमा हामीले पहिले नै गरेको कुरा दोहोर्याउनेछौं। सम्झनुहोस् कि हामीले हाम्रो अनुप्रयोग "निर्माण" गर्न S2I छवि (ubi8-s2i-web-app) प्रयोग गर्यौं, र OpenShift आन्तरिक रजिस्ट्रीमा भण्डारण गरिएको छविको साथ समाप्त भयो। अब हामी हाम्रो एपको लागि डकरफाइल सिर्जना गर्नको लागि यो S2I वेब एप छवि प्रयोग गर्नेछौं र त्यसपछि वास्तविक निर्माण गर्न Buildah प्रयोग गर्नेछौं र नतिजाको छविलाई OpenShift आन्तरिक रजिस्ट्रीमा पुश गर्नेछौं, किनकि तपाईंले NodeShift प्रयोग गरेर आफ्नो अनुप्रयोगहरू प्रयोग गर्दा OpenShift ले गर्छ। ।

हामीलाई यो सबै कसरी थाहा भयो, तपाइँ सोध्नुहुन्छ? बाट आधिकारिक Node.js को आधिकारिक संस्करण, हामीले भर्खर यसलाई प्रतिलिपि गर्यौं र यसलाई आफ्नै लागि परिमार्जन गर्यौं।

त्यसोभए, अब s2i-web-app क्लस्टर कार्य सिर्जना गरौं:

$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/clustertasks/s2i-web-app-task.yaml

हामी यसलाई विस्तृत रूपमा विश्लेषण गर्दैनौं, तर OUTPUT_DIR प्यारामिटरमा मात्र ध्यान केन्द्रित गर्नेछौं:

params:
      - name: OUTPUT_DIR
        description: The location of the build output directory
        default: build

पूर्वनिर्धारित रूपमा, यो प्यारामिटर निर्माणको बराबर हुन्छ, जहाँ प्रतिक्रियाले एसेम्बल गरिएको सामग्री राख्छ। अन्य फ्रेमवर्कहरूले विभिन्न मार्गहरू प्रयोग गर्छन्, उदाहरणका लागि, एम्बरमा यो डिस्ट हो। हाम्रो पहिलो क्लस्टर कार्यको आउटपुट हामीले सङ्कलन गरेको HTML, JavaScript र CSS समावेश भएको छवि हुनेछ।

NGINX मा आधारित छवि बनाउनुहोस्

हाम्रो दोस्रो क्लस्टर कार्यको लागि, यसले हाम्रो लागि NGINX-आधारित छवि निर्माण गर्नुपर्छ, हामीले पहिले नै बनाएको अनुप्रयोगको सामग्री प्रयोग गरेर। अनिवार्य रूपमा, यो अघिल्लो खण्डको अंश हो जहाँ हामीले जंजीर निर्माणहरू हेर्यौं।

यो गर्नको लागि, हामी - ठ्याक्कै माथि जस्तै - एउटा क्लस्टर कार्य webapp-build-runtime सिर्जना गर्नेछौं:

$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/clustertasks/webapp-build-runtime-task.yaml

यदि तपाईंले यी क्लस्टर कार्यहरूको लागि कोड हेर्नुभयो भने, तपाईंले देख्न सक्नुहुन्छ कि यसले हामीले काम गरिरहेका Git भण्डार वा हामीले सिर्जना गरिरहेका छविहरूको नाम निर्दिष्ट गर्दैन। हामी केवल Git मा स्थानान्तरण गर्दैछौं वा निश्चित छवि जहाँ अन्तिम छवि आउटपुट हुनुपर्छ भनेर निर्दिष्ट गर्दछौं। यसैले अन्य अनुप्रयोगहरूसँग काम गर्दा यी क्लस्टर कार्यहरू पुन: प्रयोग गर्न सकिन्छ।

र यहाँ हामी कृपापूर्वक अर्को बिन्दुमा जान्छौं ...

Ресурсы

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

# This resource is the location of the git repo with the web application source
apiVersion: tekton.dev/v1alpha1
kind: PipelineResource
metadata:
  name: web-application-repo
spec:
  type: git
  params:
    - name: url
      value: https://github.com/nodeshift-starters/react-pipeline-example
    - name: revision
      value: master

यहाँ PipelineResource प्रकार git को छ। प्याराम खण्डमा रहेको url कुञ्जीले एक विशिष्ट भण्डारमा देखाउँछ र मास्टर शाखा निर्दिष्ट गर्दछ (यो वैकल्पिक हो, तर हामी यसलाई पूर्णताको लागि लेख्छौं)।

अब हामीले छविको लागि एउटा स्रोत सिर्जना गर्न आवश्यक छ जहाँ s2i-web-app कार्यको परिणामहरू बचत गरिनेछ, यो यसरी गरिन्छ:

# This resource is the result of running "npm run build",  the resulting built files will be located in /opt/app-root/output
apiVersion: tekton.dev/v1alpha1
kind: PipelineResource
metadata:
  name: built-web-application-image
spec:
  type: image
  params:
    - name: url
      value: image-registry.openshift-image-registry.svc:5000/webapp-pipeline/built-web-application:latest

यहाँ PipelineResource छवि प्रकारको हो, र url प्यारामिटरको मानले आन्तरिक OpenShift छवि रजिस्ट्रीलाई पोइन्ट गर्छ, विशेष गरी webapp-पाइपलाइन नेमस्पेसमा अवस्थित एउटा। यदि तपाइँ फरक नेमस्पेस प्रयोग गर्दै हुनुहुन्छ भने यो सेटिङ परिवर्तन गर्न नबिर्सनुहोस्।

र अन्तमा, हामीलाई चाहिने अन्तिम स्रोत पनि प्रकारको छविको हुनेछ र यो अन्तिम NGINX छवि हुनेछ जुन त्यसपछि प्रयोगको समयमा प्रयोग गरिनेछ:

# This resource is the image that will be just the static html, css, js files being run with nginx
apiVersion: tekton.dev/v1alpha1
kind: PipelineResource
metadata:
  name: runtime-web-application-image
spec:
  type: image
  params:
    - name: url
      value: image-registry.openshift-image-registry.svc:5000/webapp-pipeline/runtime-web-application:latest

फेरि, ध्यान दिनुहोस् कि यो स्रोतले छविलाई webapp-पाइपलाइन नेमस्पेसको आन्तरिक OpenShift रजिस्ट्रीमा भण्डारण गर्छ।

यी सबै स्रोतहरू एकैचोटि सिर्जना गर्न, हामी सिर्जना आदेश प्रयोग गर्छौं:

$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/resources/resource.yaml

तपाईं सुनिश्चित गर्न सक्नुहुन्छ कि स्रोतहरू यसरी सिर्जना गरिएको छ:

$ tkn resource ls

कन्वेयर पाइपलाइन

अब हामीसँग सबै आवश्यक कम्पोनेन्टहरू छन्, निम्न आदेशको साथ सिर्जना गरेर तिनीहरूबाट पाइपलाइन जम्मा गरौं:

$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/pipelines/build-and-deploy-react.yaml

तर हामीले यो आदेश चलाउनु अघि, यी कम्पोनेन्टहरू हेरौं। पहिलो नाम हो:

apiVersion: tekton.dev/v1alpha1
kind: Pipeline
metadata:
  name: build-and-deploy-react

त्यसपछि विशिष्ट खण्डमा हामीले पहिले सिर्जना गरेका स्रोतहरूको सङ्केत देख्छौं:

spec:
  resources:
    - name: web-application-repo
      type: git
    - name: built-web-application-image
      type: image
    - name: runtime-web-application-image
      type: image

त्यसपछि हामी हाम्रो पाइपलाइन पूरा गर्न आवश्यक कार्यहरू सिर्जना गर्छौं। सबैभन्दा पहिले, यसले हामीले पहिले नै सिर्जना गरिसकेका s2i-web-app कार्य कार्यान्वयन गर्नुपर्छ:

tasks:
    - name: build-web-application
      taskRef:
        name: s2i-web-app
        kind: ClusterTask

यो कार्यले इनपुट (गिर रिसोर्स) र आउटपुट (बिल्ट-वेब-एप्लिकेशन-इमेज रिसोर्स) प्यारामिटरहरू लिन्छ। हामी यसलाई एक विशेष प्यारामिटर पनि पास गर्छौं ताकि यसले TLS प्रमाणित गर्दैन किनकि हामीले स्व-हस्ताक्षरित प्रमाणपत्रहरू प्रयोग गरिरहेका छौं:

resources:
        inputs:
          - name: source
            resource: web-application-repo
        outputs:
          - name: image
            resource: built-web-application-image
      params:
        - name: TLSVERIFY
          value: "false"

अर्को कार्य लगभग उस्तै छ, केवल यहाँ हामीले पहिले नै सिर्जना गरेको webapp-build-runtime क्लस्टर कार्य भनिन्छ:

name: build-runtime-image
    taskRef:
      name: webapp-build-runtime
      kind: ClusterTask

अघिल्लो कार्यको रूपमा, हामी स्रोतमा पास गर्छौं, तर अब यो निर्मित-वेब-एप्लिकेशन-छवि (हाम्रो अघिल्लो कार्यको आउटपुट) हो। र आउटपुटको रूपमा हामीले फेरि छवि सेट गर्यौं। यो कार्य अघिल्लो एक पछि कार्यान्वयन हुनुपर्छ, हामी runAfter फिल्ड थप्छौं:

resources:
        inputs:
          - name: image
            resource: built-web-application-image
        outputs:
          - name: image
            resource: runtime-web-application-image
        params:
        - name: TLSVERIFY
          value: "false"
      runAfter:
        - build-web-application

अर्को दुई कार्यहरू हाम्रो वेब अनुप्रयोगको k8s डाइरेक्टरीमा रहने सेवा, मार्ग र डिप्लोइमेन्ट YAML फाइलहरू प्रयोग गर्नका लागि जिम्मेवार छन्, र नयाँ छविहरू सिर्जना गर्दा यो डिप्लोयमेन्ट अद्यावधिक गर्नका लागि पनि। हामीले लेखको सुरुमा यी दुई क्लस्टर कार्यहरू परिभाषित गरेका छौं।

कन्वेयर सुरु गर्दै

त्यसोभए, हाम्रो पाइपलाइनका सबै भागहरू सिर्जना गरिएका छन्, र हामी यसलाई निम्न आदेशको साथ चलाउनेछौं:

$ tkn pipeline start build-and-deploy-react

यस चरणमा, कमाण्ड लाइन अन्तरक्रियात्मक रूपमा प्रयोग गरिन्छ र तपाईंले यसको प्रत्येक अनुरोधको जवाफमा उपयुक्त स्रोतहरू चयन गर्न आवश्यक छ: git संसाधनको लागि, वेब-एप्लिकेशन-रिपो चयन गर्नुहोस्, त्यसपछि पहिलो छवि स्रोतको लागि, निर्मित-वेब-अनुप्रयोग। -छवि, र अन्तमा, दोस्रो छवि स्रोतको लागि -रनटाइम-वेब-एप्लिकेशन-छवि:

? Choose the git resource to use for web-application-repo: web-application-repo (https://github.com/nodeshift-starters/react-pipeline-example)
? Choose the image resource to use for built-web-application-image: built-web-application-image (image-registry.openshift-image-registry.svc:5000/webapp-pipeline/built-web-
application:latest)
? Choose the image resource to use for runtime-web-application-image: runtime-web-application-image (image-registry.openshift-image-registry.svc:5000/webapp-pipeline/runtim
e-web-application:latest)
Pipelinerun started: build-and-deploy-react-run-4xwsr

अब निम्न आदेश प्रयोग गरेर पाइपलाइनको स्थिति जाँच गरौं:

$ tkn pipeline logs -f

एक पटक पाइपलाइन सुरु भएपछि र अनुप्रयोग तैनात गरिसकेपछि, हामी निम्न आदेशको साथ प्रकाशित मार्ग अनुरोध गर्न सक्छौं:

$ oc get route react-pipeline-example --template='http://{{.spec.host}}'

थप दृश्यका लागि, तपाईंले सेक्सनमा रहेको वेब कन्सोलको विकासकर्ता मोडमा हाम्रो पाइपलाइन हेर्न सक्नुहुन्छ। पाइपलाइनहरू, चित्र मा देखाइएको रूपमा। १.

चित्र १। चलिरहेको पाइपलाइनहरूको समीक्षा।

चलिरहेको पाइपलाइनमा क्लिक गर्दा चित्र २ मा देखाइए अनुसार थप विवरणहरू देखाउँछ।

चामल। 2. पाइपलाइन बारे थप जानकारी।

थप जानकारी पछि, तपाइँ दृश्यमा चलिरहेको अनुप्रयोगहरू हेर्न सक्नुहुन्छ टोपोलोजी, चित्र 3 मा देखाइएको छ।

चित्र 3. सुरु गरिएको पोड।

प्रतिमाको माथिल्लो दायाँ कुनामा रहेको सर्कलमा क्लिक गर्दा चित्र 4 मा देखाइए अनुसार हाम्रो अनुप्रयोग खोल्छ।

चामल। 4. प्रतिक्रिया अनुप्रयोग चलिरहेको छ।

निष्कर्षमा

त्यसोभए, हामीले OpenShift मा तपाइँको अनुप्रयोगको लागि विकास सर्भर कसरी चलाउने र यसलाई स्थानीय फाइल प्रणालीसँग सिङ्क्रोनाइज गर्ने भनेर देखायौं। हामीले OpenShift पाइपलाइनहरू प्रयोग गरेर चेन-बिल्ड टेम्प्लेट कसरी सिमुलेट गर्ने भनेर पनि हेर्यौं। यस लेखबाट सबै उदाहरण कोडहरू फेला पार्न सकिन्छ यहाँ.

अतिरिक्त स्रोतहरू (EN)

आगामी वेबिनारहरूको घोषणा

हामी Red Hat OpenShift कन्टेनर प्लेटफर्म र Kubernetes प्रयोग गरेर नेटिभ अनुभवको बारेमा शुक्रबार वेबिनारहरूको श्रृंखला सुरु गर्दैछौं:

स्रोत: www.habr.com

OpenShift मा आधुनिक अनुप्रयोगहरू, भाग 3: विकास वातावरण र OpenShift पाइपलाइनहरूको रूपमा OpenShift