🥇ओपनशिफ्ट पर आधुनिक अनुप्रयोग, भाग 3: एक विकास परिवेश और ओपनशिफ्ट पाइपलाइन के रूप में ओपनशिफ्ट

इस ब्लॉग पर सभी को नमस्कार! यह श्रृंखला की तीसरी पोस्ट है जिसमें हम दिखाते हैं कि Red Hat OpenShift पर आधुनिक वेब एप्लिकेशन कैसे तैनात करें।

पिछली दो पोस्टों में, हमने दिखाया था कि कुछ ही चरणों में आधुनिक वेब अनुप्रयोगों को कैसे तैनात किया जाए और उत्पादन परिनियोजन को व्यवस्थित करने के लिए चेन बिल्ड का उपयोग करके एनजीआईएनएक्स जैसी ऑफ-द-शेल्फ HTTP सर्वर छवि के साथ एक नई S2I छवि का उपयोग कैसे किया जाए। .

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

एक विकास परिवेश के रूप में ओपनशिफ्ट

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

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

अधिकांश आधुनिक ढाँचों में, ऐसा "विकास सर्वर" संबंधित कमांड लाइन टूल में बनाया जाता है।

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

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

$ npm run start

फिर टर्मिनल विंडो में हम कुछ इस तरह देखेंगे:

और हमारा एप्लिकेशन डिफ़ॉल्ट ब्राउज़र में खुल जाएगा:

अब, यदि हम फ़ाइल में परिवर्तन करते हैं, तो एप्लिकेशन को ब्राउज़र में अपडेट होना चाहिए।

ठीक है, स्थानीय मोड में विकास के साथ सब कुछ स्पष्ट है, लेकिन ओपनशिफ्ट पर इसे कैसे हासिल किया जाए?

OpenShift पर विकास सर्वर

यदि आपको याद हो तो, में पिछला पद, हमने S2I छवि के तथाकथित रन चरण को देखा और देखा कि डिफ़ॉल्ट रूप से, सर्व मॉड्यूल हमारे वेब एप्लिकेशन की सर्विसिंग के लिए जिम्मेदार है।

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

उदाहरण के लिए, हम अपने एप्लिकेशन को तैनात करने के लिए नोडशिफ्ट मॉड्यूल का उपयोग कर सकते हैं:

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

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

यहां हमने अपने परिनियोजन में NPM_RUN पर्यावरण चर जोड़ा है, जो यार्न स्टार्ट कमांड को चलाने के लिए रनटाइम बताता है, जो हमारे ओपनशिफ्ट पॉड के अंदर रिएक्ट डेवलपमेंट सर्वर शुरू करता है।

यदि आप रनिंग पॉड के लॉग को देखेंगे, तो यह कुछ इस तरह दिखेगा:

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

दूरस्थ और स्थानीय कोड को सिंक्रनाइज़ करना

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

इसलिए हमारे एप्लिकेशन के लिए डेवलपमेंट सर्वर को तैनात करने के लिए कमांड चलाने के बाद, हम सुरक्षित रूप से निम्नलिखित कमांड का उपयोग कर सकते हैं:

$ 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 पर्यावरण चर सेट करें।

ओपनशिफ्ट पाइपलाइनें

आगे हम ओपनशिफ्ट पाइपलाइन जैसे टूल के बारे में बात करेंगे और इसे चेन्ड बिल्ड के विकल्प के रूप में कैसे इस्तेमाल किया जा सकता है।

ओपनशिफ्ट पाइपलाइन क्या हैं?

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

इस लेख को समझने के लिए पाइपलाइनों के कुछ ज्ञान की आवश्यकता है, इसलिए हम दृढ़ता से अनुशंसा करते हैं कि आप पहले पढ़ें आधिकारिक पाठ्यपुस्तक.

अपना कार्य वातावरण स्थापित करना

इस आलेख में उदाहरणों के साथ खेलने के लिए, आपको सबसे पहले अपना कामकाजी माहौल तैयार करना होगा:

ओपनशिफ्ट 4 क्लस्टर को स्थापित और कॉन्फ़िगर करें। हमारे उदाहरण इसके लिए कोडरेडी कंटेनर (सीआरडी) का उपयोग करते हैं, जिसके लिए इंस्टॉलेशन निर्देश पाए जा सकते हैं यहां.
क्लस्टर तैयार होने के बाद आपको उस पर पाइपलाइन ऑपरेटर इंस्टॉल करना होगा। डरो मत, यह आसान है, इंस्टॉलेशन निर्देश यहां.
डाउनलोड टेक्टन सीएलआई (tkn) यहां.
एक एप्लिकेशन बनाने के लिए create-react-app कमांड लाइन टूल चलाएं जिसे आप फिर तैनात करेंगे (यह एक सरल एप्लिकेशन है प्रतिक्रिया).
(वैकल्पिक) एनपीएम इंस्टॉल और फिर एनपीएम स्टार्ट के साथ स्थानीय रूप से नमूना एप्लिकेशन चलाने के लिए रिपॉजिटरी को क्लोन करें।

एप्लिकेशन रिपॉजिटरी में एक k8s फ़ोल्डर भी होगा, जिसमें एप्लिकेशन को तैनात करने के लिए उपयोग किए जाने वाले Kubernetes/OpenShift YAMLs होंगे। इसमें कार्य, क्लस्टर कार्य, संसाधन और पाइपलाइन होंगे जो हम बनाएंगे खजाने.

शुरू करना

हमारे उदाहरण के लिए पहला कदम ओपनशिफ्ट क्लस्टर में एक नया प्रोजेक्ट बनाना है। चलिए इस प्रोजेक्ट को वेबएप-पाइपलाइन कहते हैं और इसे निम्नलिखित कमांड के साथ बनाते हैं:

$ oc new-project webapp-pipeline

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

तो, सबसे पहले...

कार्य

आइए कुछ कार्य बनाएं, जो एप्लिकेशन को हमारी पाइपलाइन में तैनात करने में मदद करेंगे। पहला कार्य - apply_manifests_task - उन Kubernetes संसाधनों (सेवा, परिनियोजन और मार्ग) के YAML को लागू करने के लिए जिम्मेदार है जो हमारे एप्लिकेशन के k8s फ़ोल्डर में स्थित हैं। दूसरा कार्य - 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 छवि उत्पन्न करेगा और इसे आंतरिक ओपनशिफ्ट रजिस्ट्री में भेजेगा; दूसरा, एनजीआईएनएक्स के आधार पर हमारी छवि का निर्माण करना है, उस एप्लिकेशन का उपयोग करना जो हमने पहले ही सामग्री के रूप में बनाया है।

छवि बनाएं और भेजें

पहला कार्य बनाते समय, हम वही दोहराएंगे जो हमने लिंक्ड असेंबली के बारे में पिछले लेख में पहले ही किया था। याद रखें कि हमने अपने एप्लिकेशन को "बनाने" के लिए S2I छवि (ubi8-s2i-वेब-ऐप) का उपयोग किया था, और ओपनशिफ्ट आंतरिक रजिस्ट्री में संग्रहीत एक छवि के साथ समाप्त हुआ। अब हम अपने ऐप के लिए DockerFile बनाने के लिए इस S2I वेब ऐप छवि का उपयोग करेंगे और फिर वास्तविक निर्माण करने के लिए Buildah का उपयोग करेंगे और परिणामी छवि को OpenShift आंतरिक रजिस्ट्री में धकेल देंगे, क्योंकि जब आप NodeShift का उपयोग करके अपने एप्लिकेशन को तैनात करते हैं तो OpenShift ठीक यही करता है। .

आप पूछें, हमें यह सब कैसे पता चला? से आधिकारिक Node.js का आधिकारिक संस्करण, हमने बस इसे कॉपी किया और इसे अपने लिए संशोधित किया।

तो, अब s2i-वेब-ऐप क्लस्टर कार्य बनाएं:

$ 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

डिफ़ॉल्ट रूप से, यह पैरामीटर बिल्ड के बराबर है, जहां रिएक्ट एकत्रित सामग्री डालता है। अन्य ढाँचे विभिन्न पथों का उपयोग करते हैं, उदाहरण के लिए, एम्बर में यह dist है। हमारे पहले क्लस्टर कार्य का आउटपुट एक छवि होगी जिसमें हमारे द्वारा एकत्र किए गए HTML, जावास्क्रिप्ट और सीएसएस शामिल होंगे।

NGINX पर आधारित एक छवि बनाएं

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

ऐसा करने के लिए, हम - बिल्कुल ऊपर जैसा ही - एक क्लस्टर कार्य वेबएप-बिल्ड-रनटाइम बनाएंगे:

$ 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 प्रकार का है। पैराम्स अनुभाग में यूआरएल कुंजी एक विशिष्ट रिपॉजिटरी को इंगित करती है और मास्टर शाखा को निर्दिष्ट करती है (यह वैकल्पिक है, लेकिन हम इसे पूर्णता के लिए लिखते हैं)।

अब हमें छवि के लिए एक संसाधन बनाने की आवश्यकता है जहां s2i-वेब-ऐप कार्य के परिणाम सहेजे जाएंगे, यह इस प्रकार किया जाता है:

# 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

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

और अंत में, हमें जिस अंतिम संसाधन की आवश्यकता होगी वह भी छवि प्रकार का होगा और यह अंतिम एनजीआईएनएक्स छवि होगी जिसका उपयोग तैनाती के दौरान किया जाएगा:

# 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

दोबारा, ध्यान दें कि यह संसाधन छवि को वेबएप-पाइपलाइन नेमस्पेस में आंतरिक ओपनशिफ्ट रजिस्ट्री में संग्रहीत करता है।

इन सभी संसाधनों को एक साथ बनाने के लिए, हम create कमांड का उपयोग करते हैं:

$ 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-वेब-ऐप कार्य को निष्पादित करना होगा:

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

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

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

अगला कार्य लगभग वैसा ही है, केवल यहां वेबएप-बिल्ड-रनटाइम क्लस्टर कार्य जो हमने पहले ही बनाया है उसे कहा जाता है:

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

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

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

अगले दो कार्य सेवा, मार्ग और परिनियोजन YAML फ़ाइलों का उपयोग करने के लिए जिम्मेदार हैं जो हमारे वेब एप्लिकेशन की k8s निर्देशिका में रहते हैं, और नई छवियां बनाते समय इस परिनियोजन को अद्यतन करने के लिए भी जिम्मेदार हैं। हमने लेख की शुरुआत में इन दो क्लस्टर कार्यों को परिभाषित किया है।

कन्वेयर शुरू करना

तो, हमारी पाइपलाइन के सभी हिस्से बन गए हैं, और हम इसे निम्नलिखित कमांड के साथ चलाएंगे:

$ tkn pipeline start build-and-deploy-react

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

? 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}}'

बेहतर विज़ुअलाइज़ेशन के लिए, आप अनुभाग में वेब कंसोल के डेवलपर मोड में हमारी पाइपलाइन देख सकते हैं पाइप लाइनें, जैसा कि चित्र में दिखाया गया है। 1.

चित्र .1। चल रही पाइपलाइनों की समीक्षा.

चल रही पाइपलाइन पर क्लिक करने से अतिरिक्त विवरण प्रदर्शित होता है, जैसा चित्र 2 में दिखाया गया है।

चावल। 2. पाइपलाइन के बारे में अतिरिक्त जानकारी.

अधिक जानकारी के बाद, आप दृश्य में चल रहे एप्लिकेशन देख सकते हैं टोपोलॉजी, जैसा कि चित्र 3 में दिखाया गया है।

चित्र 3. लॉन्च किया गया पॉड।

आइकन के ऊपरी दाएं कोने में वृत्त पर क्लिक करने से हमारा एप्लिकेशन खुल जाता है, जैसा चित्र 4 में दिखाया गया है।

चावल। 4. रिएक्ट एप्लिकेशन चलाना।

निष्कर्ष

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

अतिरिक्त संसाधन (EN)

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

हम Red Hat OpenShift कंटेनर प्लेटफ़ॉर्म और कुबेरनेट्स का उपयोग करके मूल अनुभव के बारे में शुक्रवार के वेबिनार की एक श्रृंखला शुरू कर रहे हैं:

स्रोत: www.habr.com

ओपनशिफ्ट पर आधुनिक अनुप्रयोग, भाग 3: एक विकास परिवेश और ओपनशिफ्ट पाइपलाइन के रूप में ओपनशिफ्ट