Բարև բոլորին այս բլոգում: Սա շարքի երրորդ գրառումն է, որտեղ մենք ցույց ենք տալիս, թե ինչպես կարելի է տեղադրել ժամանակակից վեբ հավելվածներ Red Hat OpenShift-ում:
Նախորդ երկու հաղորդագրություններում մենք ցույց տվեցինք, թե ինչպես կարելի է տեղակայել ժամանակակից վեբ հավելվածները ընդամենը մի քանի քայլով և ինչպես օգտագործել նոր S2I պատկերը HTTP սերվերի պատկերի հետ միասին, ինչպիսին է NGINX-ը, օգտագործելով շղթայված կառուցվածքներ՝ արտադրության տեղակայումը կազմակերպելու համար: .
Այսօր մենք ցույց կտանք, թե ինչպես գործարկել զարգացման սերվերը ձեր հավելվածի համար OpenShift հարթակում և համաժամացնել այն տեղական ֆայլային համակարգի հետ, ինչպես նաև կխոսենք այն մասին, թե ինչ են OpenShift խողովակաշարերը և ինչպես դրանք կարող են օգտագործվել որպես այլընտրանք կապակցված հավաքների:
OpenShift-ը որպես զարգացման միջավայր
Մշակման աշխատանքային հոսք
Ինչպես արդեն ասվել է , ժամանակակից վեբ հավելվածների զարգացման բնորոշ գործընթացը պարզապես ինչ-որ «զարգացման սերվեր» է, որը հետևում է տեղական ֆայլերի փոփոխություններին: Երբ դրանք հայտնվում են, հավելվածի կառուցումը գործարկվում է, այնուհետև այն թարմացվում է դիտարկիչում:
Ժամանակակից շրջանակների մեծ մասում նման «զարգացման սերվերը» ներկառուցված է համապատասխան հրամանի տող գործիքների մեջ:
Տեղական օրինակ
Նախ, եկեք տեսնենք, թե ինչպես է դա աշխատում տեղական հավելվածները գործարկելիս: Որպես օրինակ վերցնենք դիմումը նախորդ հոդվածներից, չնայած գրեթե նույն աշխատանքային հոսքի հասկացությունները կիրառվում են բոլոր մյուս ժամանակակից շրջանակներում:
Այսպիսով, մեր React օրինակում «dev server» սկսելու համար մենք մուտքագրելու ենք հետևյալ հրամանը.
$ 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 միջավայրի փոփոխականը մեր տեղակայմանը, որը գործարկման ժամանակին ասում է, որ գործարկի yarn start հրամանը, որը գործարկում է React մշակման սերվերը մեր 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 հրամանի վերևում, կարող եք ավելին իմանալ, թե ինչպես է այն աշխատում: .
Սա օրինակ էր React-ի համար, բայց ճիշտ նույն մեթոդը կարող է օգտագործվել այլ շրջանակների հետ, պարզապես անհրաժեշտության դեպքում սահմանեք NPM_RUN միջավայրի փոփոխականը:
Openshift խողովակաշարեր
Հաջորդիվ մենք կխոսենք այնպիսի գործիքի մասին, ինչպիսին է OpenShift Pipelines-ը, և թե ինչպես այն կարող է օգտագործվել որպես շղթայական շինությունների այլընտրանք:
Որոնք են OpenShift խողովակաշարերը
OpenShift Pipelines-ը ամպային CI/CD շարունակական ինտեգրման և առաքման համակարգ է, որը նախատեսված է Tekton-ի միջոցով խողովակաշարերի կազմակերպման համար: Tekton-ը ճկուն բաց կոդով Kubernetes-ի բնիկ CI/CD շրջանակ է, որը թույլ է տալիս ավտոմատացնել տեղաբաշխումը տարբեր հարթակներում (Kubernetes, առանց սերվերի, վիրտուալ մեքենաներ և այլն)՝ վերացարկելով հիմքում ընկած շերտից:
Այս հոդվածը հասկանալու համար պահանջվում է խողովակաշարերի մասին որոշակի գիտելիքներ, ուստի խորհուրդ ենք տալիս նախ կարդալ .
Ստեղծեք ձեր աշխատանքային միջավայրը
Այս հոդվածի օրինակների հետ խաղալու համար նախ պետք է նախապատրաստեք ձեր աշխատանքային միջավայրը.
- Տեղադրեք և կազմաձևեք OpenShift 4 կլաստերը: Մեր օրինակները դրա համար օգտագործում են CodeReady Containers (CRD), որոնց տեղադրման հրահանգները կարող եք գտնել: .
- Կլաստերը պատրաստ լինելուց հետո դրա վրա պետք է տեղադրել Pipeline Operator: Մի վախեցեք, դա հեշտ է, տեղադրման հրահանգներ .
- Բեռնել (tkn) .
- Գործարկեք create-react-app հրամանի տող գործիքը, որպեսզի ստեղծեք ծրագիր, որը դուք կտեղակայեք (սա պարզ ծրագիր է ).
- (Ըստ ցանկության) Կլոնավորեք պահոցը՝ օրինակ հավելվածը տեղում գործարկելու համար npm install-ով, այնուհետև npm մեկնարկով:
Հավելվածի պահոցը կունենա նաև k8s թղթապանակ, որը կպարունակի Kubernetes/OpenShift YAML-ները, որոնք օգտագործվում են հավելվածը տեղակայելու համար: Կլինեն առաջադրանքներ, կլաստերային առաջադրանքներ, ռեսուրսներ և խողովակաշարեր, որոնք մենք կստեղծենք դրանում .
Եկեք սկսենք
Մեր օրինակի առաջին քայլը OpenShift կլաստերում նոր նախագիծ ստեղծելն է: Եկեք այս նախագիծը անվանենք webapp-pipeline և ստեղծենք այն հետևյալ հրամանով.
$ oc new-project webapp-pipeline
Այս նախագծի անունը կհայտնվի կոդի մեջ ավելի ուշ, այնպես որ, եթե որոշեք այն անվանել այլ կերպ, մի մոռացեք համապատասխանաբար խմբագրել օրինակի կոդը: Սկսած այս կետից՝ մենք չենք գնալու վերևից վար, այլ ներքևից վեր, այսինքն՝ նախ կստեղծենք փոխակրիչի բոլոր բաղադրիչները, և միայն դրանից հետո՝ հենց ինքը փոխակրիչը։
Այսպիսով, առաջին հերթին...
Առաջադրանքներ
Եկեք ստեղծենք մի քանի առաջադրանք, որոնք այնուհետև կօգնեն տեղակայել հավելվածը մեր խողովակաշարում: Առաջին առաջադրանքը՝ application_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
Նշում. սրանք տեղական առաջադրանքներ են ձեր ընթացիկ նախագծի համար:
Կլաստերային առաջադրանքներ
Կլաստերային առաջադրանքները հիմնականում նույնն են, ինչ պարզ առաջադրանքները: Այսինքն՝ այն քայլերի բազմակի օգտագործման հավաքածու է, որոնք այս կամ այն կերպ համակցվում են կոնկրետ առաջադրանք կատարելիս։ Տարբերությունն այն է, որ կլաստերի առաջադրանքը հասանելի է կլաստերի ներսում ամենուր: Կլաստերային առաջադրանքների ցանկը տեսնելու համար, որոնք ավտոմատ կերպով ստեղծվում են Pipeline Operator-ը ավելացնելիս, մենք կրկին կօգտագործենք 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 վեբ հավելվածի պատկերը՝ մեր հավելվածի համար DockerFile ստեղծելու համար, այնուհետև կօգտագործենք Buildah՝ իրական կառուցումը կատարելու և ստացված պատկերը մղելու OpenShift ներքին ռեգիստր, քանի որ դա հենց այն է, ինչ անում է OpenShift-ը, երբ դուք տեղակայում եք ձեր հավելվածները՝ օգտագործելով NodeShift-ը: .
Ինչպե՞ս մենք իմացանք այս ամենը, հարցնում եք: Սկսած , մենք պարզապես պատճենեցինք այն և ձևափոխեցինք մեզ համար։
Այսպիսով, հիմա եկեք ստեղծենք 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
Լռելյայնորեն, այս պարամետրը հավասար է build-ին, որտեղ React-ը տեղադրում է հավաքված բովանդակությունը: Այլ շրջանակներ օգտագործում են տարբեր ուղիներ, օրինակ, Ember-ում այն հեռավոր է: Մեր առաջին կլաստերային առաջադրանքի արդյունքը կլինի մեր հավաքած 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 պահեստ) և որպես ելք (վերջնական պատկերներ): Առաջին ռեսուրսը, որը մեզ անհրաժեշտ է, 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-pipeline անվանումների տարածքում: Մի մոռացեք փոխել այս կարգավորումը, եթե դուք օգտագործում եք այլ անվանատարածք:
Եվ վերջապես, մեզ անհրաժեշտ վերջին ռեսուրսը նույնպես կլինի պատկերի տիպի, և սա կլինի վերջնական 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 ռեգիստրում՝ webapp-pipeline անվանումների տարածքում:
Այս բոլոր ռեսուրսները միանգամից ստեղծելու համար մենք օգտագործում ենք ստեղծել հրամանը.
$ 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
Այս առաջադրանքը վերցնում է մուտքային (gir ռեսուրս) և ելքային (կառուցված-վեբ-հավելված-պատկեր ռեսուրս) պարամետրեր: Մենք նաև փոխանցում ենք այն հատուկ պարամետր, որպեսզի այն չստուգի 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
Հաջորդ երկու առաջադրանքները պատասխանատու են ծառայության, երթուղու և տեղակայման YAML ֆայլերի օգտագործման համար, որոնք ապրում են մեր վեբ հավելվածի k8s գրացուցակում, ինչպես նաև նոր պատկերներ ստեղծելիս այս տեղակայումը թարմացնելու համար: Այս երկու կլաստերի առաջադրանքները մենք սահմանեցինք հոդվածի սկզբում:
Փոխակրիչի գործարկում
Այսպիսով, մեր խողովակաշարի բոլոր մասերը ստեղծվել են, և մենք այն կաշխատենք հետևյալ հրամանով.
$ tkn pipeline start build-and-deploy-react
Այս փուլում հրամանի տողը օգտագործվում է ինտերակտիվ կերպով, և դուք պետք է ընտրեք համապատասխան ռեսուրսներ՝ ի պատասխան դրա յուրաքանչյուր խնդրանքի. git ռեսուրսի համար ընտրեք web-application-repo, ապա առաջին պատկերի ռեսուրսի համար, ներկառուցված վեբ հավելված: -image, և վերջապես, երկրորդ պատկերի ռեսուրսի համար –runtime-web-application-image:
? 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. Լրացուցիչ տեղեկություններ խողովակաշարի մասին:
Լրացուցիչ տեղեկություններից հետո տեսադաշտում կարող եք տեսնել գործարկվող հավելվածները topology, ինչպես ցույց է տրված Նկ.3-ում:
Նկ 3. Գործարկված պատիճ:
Սրբապատկերի վերին աջ անկյունում գտնվող շրջանագծի վրա սեղմելով բացվում է մեր հավելվածը, ինչպես ցույց է տրված Նկար 4-ում:
Բրինձ. 4. Running React հավելվածը:
Ամփոփում
Այսպիսով, մենք ցույց տվեցինք, թե ինչպես աշխատեցնել OpenShift-ում ձեր հավելվածի զարգացման սերվերը և համաժամացնել այն տեղական ֆայլային համակարգի հետ: Մենք նաև նայեցինք, թե ինչպես կարելի է մոդելավորել շղթայական կառուցման ձևանմուշ՝ օգտագործելով OpenShift Pipelines: Այս հոդվածի բոլոր օրինակելի կոդերը կարելի է գտնել .
Լրացուցիչ ռեսուրսներ (EN)
- Անվճար էլեկտրոնային գիրք
- Այլ հոդվածներ Red Hat կայքում
Առաջիկա վեբինարների հայտարարություններ
Մենք սկսում ենք ուրբաթօրյա վեբինարների շարք հայրենի փորձի մասին՝ օգտագործելով Red Hat OpenShift Container Platform-ը և Kubernetes-ը:
Source: www.habr.com