🥇 OpenShift वरील आधुनिक ऍप्लिकेशन्स, भाग 3: विकास वातावरण आणि OpenShift पाइपलाइन म्हणून OpenShift

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

मागील दोन पोस्ट्समध्ये, आम्ही आधुनिक वेब ऍप्लिकेशन्स फक्त काही चरणांमध्ये कसे उपयोजित करायचे आणि उत्पादन उपयोजनेसाठी साखळीबद्ध बिल्ड वापरून NGINX सारख्या ऑफ-द-शेल्फ HTTP सर्व्हर इमेजसह नवीन S2I इमेज कशी वापरायची हे दाखवले. .

आज आम्ही ओपनशिफ्ट प्लॅटफॉर्मवर तुमच्या ऍप्लिकेशनसाठी डेव्हलपमेंट सर्व्हर कसा चालवायचा आणि स्थानिक फाइल सिस्टमशी सिंक्रोनाइझ कसा करायचा ते दाखवू आणि ओपनशिफ्ट पाइपलाइन काय आहेत आणि लिंक केलेल्या असेंब्लीला पर्याय म्हणून त्यांचा कसा वापर करता येईल याबद्दल देखील बोलू.

विकास वातावरण म्हणून OpenShift

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

आधीच नमूद केल्याप्रमाणे पहिली पोस्ट, आधुनिक वेब ऍप्लिकेशन्ससाठी ठराविक डेव्हलपमेंट प्रक्रिया ही काही प्रकारची "डेव्हलपमेंट सर्व्हर" आहे जी स्थानिक फाइल्समधील बदलांचा मागोवा घेते. जेव्हा ते होतात, तेव्हा अनुप्रयोग बिल्ड ट्रिगर केला जातो आणि नंतर तो ब्राउझरमध्ये अद्यतनित केला जातो.

बर्‍याच आधुनिक फ्रेमवर्कमध्ये, असा “डेव्हलपमेंट सर्व्हर” संबंधित कमांड लाइन टूल्समध्ये तयार केला जातो.

स्थानिक उदाहरण

प्रथम, स्थानिक पातळीवर अनुप्रयोग चालवताना हे कसे कार्य करते ते पाहू. उदाहरण म्हणून अर्ज घेऊ प्रतिक्रिया द्या मागील लेखांमधून, जरी जवळजवळ समान कार्यप्रवाह संकल्पना इतर सर्व आधुनिक फ्रेमवर्कमध्ये लागू होतात.
तर, आमच्या प्रतिक्रिया उदाहरणामध्ये "डेव्ह सर्व्हर" सुरू करण्यासाठी, आम्ही खालील आदेश प्रविष्ट करू:

$ npm run start

नंतर टर्मिनल विंडोमध्ये आपल्याला असे काहीतरी दिसेल:

आणि आमचा अनुप्रयोग डीफॉल्ट ब्राउझरमध्ये उघडेल:

आता, आम्ही फाइलमध्ये बदल केल्यास, अनुप्रयोग ब्राउझरमध्ये अद्यतनित झाला पाहिजे.

ठीक आहे, स्थानिक मोडमध्ये विकासासह सर्व काही स्पष्ट आहे, परंतु OpenShift वर ते कसे मिळवायचे?

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 कमांडच्या शीर्षस्थानी एक अमूर्तता आहे, ती कशी कार्य करते याबद्दल तुम्ही अधिक जाणून घेऊ शकता येथे.

हे React साठी एक उदाहरण होते, परंतु नेमकी तीच पद्धत इतर फ्रेमवर्कसह वापरली जाऊ शकते, फक्त आवश्यकतेनुसार NPM_RUN पर्यावरण व्हेरिएबल सेट करा.

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

पुढे आपण OpenShift Pipelines सारख्या साधनाबद्दल आणि साखळीबद्ध बिल्डला पर्याय म्हणून ते कसे वापरले जाऊ शकते याबद्दल बोलू.

OpenShift पाइपलाइन काय आहेत

OpenShift Pipelines ही क्लाउड-नेटिव्ह CI/CD सतत एकत्रीकरण आणि वितरण प्रणाली आहे जी Tekton वापरून पाइपलाइन आयोजित करण्यासाठी डिझाइन केलेली आहे. Tekton एक लवचिक मुक्त-स्रोत Kubernetes-नेटिव्ह CI/CD फ्रेमवर्क आहे जो तुम्हाला विविध प्लॅटफॉर्मवर (कुबर्नेट्स, सर्व्हरलेस, व्हर्च्युअल मशीन्स, इ.) अंतर्निहित लेयरमधून अॅब्स्ट्रॅक्ट करून स्वयंचलित तैनात करण्याची परवानगी देतो.

हा लेख समजून घेण्यासाठी पाइपलाइनचे काही ज्ञान आवश्यक आहे, म्हणून आम्ही जोरदार शिफारस करतो की आपण प्रथम वाचा अधिकृत पाठ्यपुस्तक.

तुमचे कामाचे वातावरण सेट करणे

या लेखातील उदाहरणांसह खेळण्यासाठी, आपण प्रथम आपले कार्य वातावरण तयार करणे आवश्यक आहे:

OpenShift 4 क्लस्टर स्थापित आणि कॉन्फिगर करा. आमची उदाहरणे यासाठी CodeReady कंटेनर (CRD) वापरतात, ज्यासाठी इंस्टॉलेशन सूचना आढळू शकतात येथे.
क्लस्टर तयार झाल्यानंतर, तुम्हाला त्यावर पाइपलाइन ऑपरेटर स्थापित करणे आवश्यक आहे. घाबरू नका, हे सोपे आहे, स्थापना सूचना येथे.
डाउनलोड Tekton CLI (tkn) येथे.
तुम्ही नंतर उपयोजित कराल असा अॅप्लिकेशन तयार करण्यासाठी create-react-app कमांड लाइन टूल चालवा (हा एक साधा अॅप्लिकेशन आहे प्रतिक्रिया द्या).
(पर्यायी) npm install आणि नंतर npm start सह स्थानिकरित्या उदाहरण अनुप्रयोग चालविण्यासाठी रेपॉजिटरी क्लोन करा.

ऍप्लिकेशन रिपॉजिटरीमध्ये 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 वापरू, कारण जेव्हा तुम्ही 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

पुन्हा, लक्षात घ्या की हे संसाधन वेबअॅप-पाइपलाइन नेमस्पेसमधील अंतर्गत OpenShift रेजिस्ट्रीमध्ये प्रतिमा संग्रहित करते.

ही सर्व संसाधने एकाच वेळी तयार करण्यासाठी, आम्ही 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-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"

पुढील कार्य जवळजवळ सारखेच आहे, फक्त येथे आम्ही आधीच तयार केलेल्या वेबअॅप-बिल्ड-रनटाइम क्लस्टर टास्कला म्हणतात:

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

या टप्प्यावर, कमांड लाइन परस्परसंवादीपणे वापरली जाते आणि तुम्हाला तिच्या प्रत्येक विनंतीला प्रतिसाद म्हणून योग्य संसाधने निवडण्याची आवश्यकता आहे: गिट संसाधनासाठी, वेब-अनुप्रयोग-रेपो निवडा, नंतर प्रथम प्रतिमा संसाधनासाठी, बिल्ट-वेब-अनुप्रयोग -इमेज, आणि शेवटी, दुसऱ्या इमेज रिसोर्ससाठी -रनटाइम-वेब-ऍप्लिकेशन-इमेज:

? 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. चालू असलेल्या पाइपलाइनचा आढावा.

आकृती 2 मध्ये दर्शविल्याप्रमाणे, चालू असलेल्या पाइपलाइनवर क्लिक केल्याने अतिरिक्त तपशील प्रदर्शित होतात.

तांदूळ. 2. पाइपलाइनबद्दल अतिरिक्त माहिती.

अधिक माहितीनंतर, आपण दृश्यामध्ये चालू असलेले अनुप्रयोग पाहू शकता टोपोलॉजी, Fig.3 मध्ये दाखवल्याप्रमाणे.

अंजीर 3. लाँच केलेले पॉड.

चिन्हाच्या वरच्या उजव्या कोपऱ्यात असलेल्या वर्तुळावर क्लिक केल्याने आमचा अनुप्रयोग उघडतो, आकृती 4 मध्ये दर्शविल्याप्रमाणे.

तांदूळ. 4. रनिंग रिअॅक्ट ऍप्लिकेशन.

निष्कर्ष

म्हणून, आम्ही OpenShift वर तुमच्या ऍप्लिकेशनसाठी डेव्हलपमेंट सर्व्हर कसा चालवायचा आणि ते स्थानिक फाइल सिस्टमसह सिंक्रोनाइझ कसे करायचे ते दाखवले. OpenShift Pipelines वापरून चेन-बिल्ड टेम्प्लेटचे अनुकरण कसे करायचे ते देखील आम्ही पाहिले. या लेखातील सर्व उदाहरण कोड आढळू शकतात येथे.

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

आगामी वेबिनारच्या घोषणा

आम्ही Red Hat OpenShift कंटेनर प्लॅटफॉर्म आणि Kubernetes वापरून स्थानिक अनुभवाबद्दल शुक्रवार वेबिनारची मालिका सुरू करत आहोत:

स्त्रोत: www.habr.com

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