ఈ బ్లాగులో అందరికీ నమస్కారం! Red Hat OpenShiftలో ఆధునిక వెబ్ అప్లికేషన్‌లను ఎలా అమర్చాలో మేము చూపించే సిరీస్‌లో ఇది మూడవ పోస్ట్.
మునుపటి రెండు పోస్ట్‌లలో, మేము ఆధునిక వెబ్ అప్లికేషన్‌లను కొన్ని దశల్లో ఎలా అమర్చాలో మరియు ఉత్పత్తి విస్తరణలను ఆర్కెస్ట్రేట్ చేయడానికి చైన్డ్ బిల్డ్‌లను ఉపయోగించి NGINX వంటి ఆఫ్-ది-షెల్ఫ్ HTTP సర్వర్ ఇమేజ్‌తో పాటు కొత్త S2I చిత్రాన్ని ఎలా ఉపయోగించాలో చూపించాము. .
ఈ రోజు మేము OpenShift ప్లాట్‌ఫారమ్‌లో మీ అప్లికేషన్ కోసం డెవలప్‌మెంట్ సర్వర్‌ను ఎలా అమలు చేయాలో చూపుతాము మరియు దానిని స్థానిక ఫైల్ సిస్టమ్‌తో సమకాలీకరించండి మరియు ఓపెన్‌షిఫ్ట్ పైప్‌లైన్‌లు అంటే ఏమిటి మరియు వాటిని లింక్డ్ అసెంబ్లీలకు ప్రత్యామ్నాయంగా ఎలా ఉపయోగించవచ్చో కూడా మాట్లాడుతాము.
అభివృద్ధి వాతావరణంగా OpenShift
అభివృద్ధి వర్క్‌ఫ్లో
లో ఇప్పటికే చెప్పినట్లు , ఆధునిక వెబ్ అప్లికేషన్‌ల కోసం విలక్షణమైన డెవలప్‌మెంట్ ప్రక్రియ కేవలం ఒక రకమైన "డెవలప్‌మెంట్ సర్వర్", ఇది స్థానిక ఫైల్‌లకు మార్పులను ట్రాక్ చేస్తుంది. అవి సంభవించినప్పుడు, అప్లికేషన్ బిల్డ్ ట్రిగ్గర్ చేయబడుతుంది మరియు అది బ్రౌజర్‌కి నవీకరించబడుతుంది.
చాలా ఆధునిక ఫ్రేమ్‌వర్క్‌లలో, అటువంటి “డెవలప్‌మెంట్ సర్వర్” సంబంధిత కమాండ్ లైన్ సాధనాలలో నిర్మించబడింది.
స్థానిక ఉదాహరణ
ముందుగా, అప్లికేషన్‌లను స్థానికంగా అమలు చేస్తున్నప్పుడు ఇది ఎలా పని చేస్తుందో చూద్దాం. అప్లికేషన్‌ను ఉదాహరణగా తీసుకుందాం మునుపటి కథనాల నుండి, అన్ని ఇతర ఆధునిక ఫ్రేమ్‌వర్క్‌లలో దాదాపు ఒకే విధమైన వర్క్‌ఫ్లో భావనలు వర్తిస్తాయి.
కాబట్టి, మా రియాక్ట్ ఉదాహరణలో "dev సర్వర్"ని ప్రారంభించడానికి, మేము ఈ క్రింది ఆదేశాన్ని నమోదు చేస్తాము:
$ 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 ఎన్విరాన్మెంట్ వేరియబుల్‌ను సెట్ చేయండి.
ఓపెన్‌షిఫ్ట్ పైప్‌లైన్స్
తర్వాత మనం ఓపెన్‌షిఫ్ట్ పైప్‌లైన్‌ల వంటి సాధనం గురించి మాట్లాడుతాము మరియు చైన్డ్ బిల్డ్‌లకు ప్రత్యామ్నాయంగా దీనిని ఎలా ఉపయోగించవచ్చు.
ఓపెన్‌షిఫ్ట్ పైప్‌లైన్స్ అంటే ఏమిటి
ఓపెన్‌షిఫ్ట్ పైప్‌లైన్స్ అనేది క్లౌడ్-నేటివ్ CI/CD నిరంతర ఏకీకరణ మరియు డెలివరీ సిస్టమ్, ఇది టెక్టన్‌ని ఉపయోగించి పైప్‌లైన్‌లను నిర్వహించడానికి రూపొందించబడింది. Tekton అనేది ఒక సౌకర్యవంతమైన ఓపెన్ సోర్స్ Kubernetes-స్థానిక CI/CD ఫ్రేమ్‌వర్క్, ఇది అంతర్లీన లేయర్ నుండి సంగ్రహించడం ద్వారా వివిధ ప్లాట్‌ఫారమ్‌లలో (కుబెర్నెట్స్, సర్వర్‌లెస్, వర్చువల్ మెషీన్‌లు మొదలైనవి) ఆటోమేట్ చేయడానికి మిమ్మల్ని అనుమతిస్తుంది.
ఈ కథనాన్ని అర్థం చేసుకోవడానికి పైప్‌లైన్‌ల గురించి కొంత జ్ఞానం అవసరం, కాబట్టి మీరు మొదట చదవాలని మేము గట్టిగా సిఫార్సు చేస్తున్నాము .
మీ పని వాతావరణాన్ని ఏర్పాటు చేస్తోంది
ఈ కథనంలోని ఉదాహరణలతో ఆడటానికి, మీరు ముందుగా మీ పని వాతావరణాన్ని సిద్ధం చేసుకోవాలి:
- OpenShift 4 క్లస్టర్‌ను ఇన్‌స్టాల్ చేయండి మరియు కాన్ఫిగర్ చేయండి. మా ఉదాహరణలు దీని కోసం CodeReady కంటైనర్‌లను (CRD) ఉపయోగిస్తాయి, దీని కోసం ఇన్‌స్టాలేషన్ సూచనలను కనుగొనవచ్చు .
- క్లస్టర్ సిద్ధమైన తర్వాత, మీరు దానిపై పైప్లైన్ ఆపరేటర్‌ను ఇన్‌స్టాల్ చేయాలి. బయపడకండి, ఇది సులభం, ఇన్‌స్టాలేషన్ సూచనలు .
- డౌన్‌లోడ్ చేయండి (tkn) .
- మీరు అమలు చేసే అప్లికేషన్‌ను సృష్టించడానికి create-react-app కమాండ్ లైన్ సాధనాన్ని అమలు చేయండి (ఇది ఒక సాధారణ అప్లికేషన్ ).
- (ఐచ్ఛికం) npm ఇన్‌స్టాల్ చేసి, ఆపై npm ప్రారంభంతో ఉదాహరణ అప్లికేషన్‌ను స్థానికంగా అమలు చేయడానికి రిపోజిటరీని క్లోన్ చేయండి.
అప్లికేషన్ రిపోజిటరీ కూడా k8s ఫోల్డర్‌ను కలిగి ఉంటుంది, ఇది అప్లికేషన్‌ను అమలు చేయడానికి ఉపయోగించే Kubernetes/OpenShift YAMLలను కలిగి ఉంటుంది. మేము ఇందులో సృష్టించే టాస్క్‌లు, క్లస్టర్‌టాస్క్‌లు, వనరులు మరియు పైప్‌లైన్‌లు ఉంటాయి. .
ప్రారంభిద్దాం
మా ఉదాహరణ కోసం మొదటి దశ OpenShift క్లస్టర్‌లో కొత్త ప్రాజెక్ట్‌ను సృష్టించడం. ఈ ప్రాజెక్ట్‌ను webapp-pipeline అని పిలుద్దాం మరియు కింది ఆదేశంతో దీన్ని సృష్టించండి:
$ oc new-project webapp-pipeline
ఈ ప్రాజెక్ట్ పేరు తర్వాత కోడ్‌లో కనిపిస్తుంది, కాబట్టి మీరు దీనికి వేరే పేరు పెట్టాలని నిర్ణయించుకుంటే, తదనుగుణంగా ఉదాహరణ కోడ్‌ను సవరించడం మర్చిపోవద్దు. ఈ పాయింట్ నుండి ప్రారంభించి, మేము పై నుండి క్రిందికి వెళ్ళము, కానీ దిగువ నుండి పైకి వెళ్ళము: అనగా, మేము మొదట కన్వేయర్ యొక్క అన్ని భాగాలను సృష్టిస్తాము మరియు అప్పుడు మాత్రమే కన్వేయర్ కూడా.
కాబట్టి, ముందుగా...
పనులు
రెండు టాస్క్‌లను క్రియేట్ చేద్దాం, ఇది మా పైప్‌లైన్‌లో అప్లికేషన్‌ని అమలు చేయడంలో సహాయపడుతుంది. మొదటి పని - apply_manifests_task - మా అప్లికేషన్ యొక్క k8s ఫోల్డర్‌లో ఉన్న కుబెర్నెట్స్ వనరుల (సేవ, విస్తరణ మరియు మార్గం) యొక్క 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 ఇమేజ్‌ని ఉత్పత్తి చేస్తుంది మరియు దానిని అంతర్గత ఓపెన్‌షిఫ్ట్ రిజిస్ట్రీకి పంపుతుంది; రెండవది, మేము ఇప్పటికే కంటెంట్‌గా రూపొందించిన అప్లికేషన్‌ను ఉపయోగించి NGINX ఆధారంగా మా చిత్రాన్ని నిర్మించడం.
చిత్రాన్ని సృష్టించండి మరియు పంపండి
మొదటి పనిని సృష్టిస్తున్నప్పుడు, లింక్డ్ అసెంబ్లీల గురించి మునుపటి కథనంలో మేము ఇప్పటికే చేసిన వాటిని పునరావృతం చేస్తాము. మేము మా అప్లికేషన్‌ను "బిల్డ్" చేయడానికి S2I ఇమేజ్ (ubi8-s2i-web-app)ని ఉపయోగించామని మరియు OpenShift అంతర్గత రిజిస్ట్రీలో నిల్వ చేయబడిన చిత్రంతో ముగించామని గుర్తుచేసుకోండి. ఇప్పుడు మేము మా యాప్ కోసం డాకర్‌ఫైల్‌ని సృష్టించడానికి ఈ S2I వెబ్ యాప్ ఇమేజ్‌ని ఉపయోగిస్తాము, ఆపై అసలు బిల్డ్ చేయడానికి Buildahని ఉపయోగిస్తాము మరియు ఫలిత చిత్రాన్ని OpenShift అంతర్గత రిజిస్ట్రీకి పుష్ చేస్తాము, ఎందుకంటే మీరు NodeShiftని ఉపయోగించి మీ అప్లికేషన్‌లను అమలు చేసినప్పుడు OpenShift సరిగ్గా అదే చేస్తుంది. .
ఇదంతా మాకు ఎలా తెలిసింది, మీరు అడగండి? నుండి , మేము దానిని కాపీ చేసి, మా కోసం సవరించాము.
కాబట్టి, ఇప్పుడు 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-ఆధారిత చిత్రాన్ని రూపొందించాలి. ముఖ్యంగా, ఇది మేము చైన్డ్ బిల్డ్‌లను చూసే మునుపటి విభాగంలోని భాగం.
దీన్ని చేయడానికి, మేము - సరిగ్గా పైన పేర్కొన్న విధంగానే - క్లస్టర్ టాస్క్ వెబ్‌యాప్-బిల్డ్-రన్‌టైమ్‌ను సృష్టిస్తాము:
$ 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-పైప్లైన్ నేమ్‌స్పేస్‌లో ఉన్నది. మీరు వేరే నేమ్‌స్పేస్‌ని ఉపయోగిస్తుంటే ఈ సెట్టింగ్‌ని మార్చడం మర్చిపోవద్దు.
చివరగా, మనకు అవసరమైన చివరి వనరు కూడా టైప్ ఇమేజ్‌గా ఉంటుంది మరియు ఇది చివరి 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
మళ్ళీ, ఈ వనరు వెబ్‌యాప్-పైప్లైన్ నేమ్‌స్పేస్‌లోని అంతర్గత ఓపెన్‌షిఫ్ట్ రిజిస్ట్రీలో చిత్రాన్ని నిల్వ చేస్తుందని గమనించండి.
ఈ వనరులన్నింటినీ ఒకేసారి సృష్టించడానికి, మేము సృష్టించు ఆదేశాన్ని ఉపయోగిస్తాము:
$ 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 cluster task అంటారు:
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}}'
ఎక్కువ విజువలైజేషన్ కోసం, మీరు విభాగంలోని వెబ్ కన్సోల్ డెవలపర్ మోడ్‌లో మా పైప్‌లైన్‌ని వీక్షించవచ్చు పైపులైన్ల, అంజీర్లో చూపిన విధంగా. 1.
చిత్రం 1. నడుస్తున్న పైప్‌లైన్‌ల సమీక్ష.
నడుస్తున్న పైప్‌లైన్‌పై క్లిక్ చేయడం ద్వారా మూర్తి 2లో చూపిన విధంగా అదనపు వివరాలు కనిపిస్తాయి.
అన్నం. 2. పైప్లైన్ గురించి అదనపు సమాచారం.
మరింత సమాచారం తర్వాత, మీరు వీక్షణలో నడుస్తున్న అప్లికేషన్‌లను చూడవచ్చు టోపాలజీ, Fig.3 లో చూపిన విధంగా.
అంజీర్ 3. పాడ్ ప్రారంభించబడింది.
చిహ్నం యొక్క కుడి ఎగువ మూలలో ఉన్న సర్కిల్‌పై క్లిక్ చేయడం ద్వారా, అంజీర్ 4లో చూపిన విధంగా మా అప్లికేషన్ తెరవబడుతుంది.
అన్నం. 4. రియాక్ట్ అప్లికేషన్ రన్ అవుతోంది.
తీర్మానం
కాబట్టి, OpenShiftలో మీ అప్లికేషన్ కోసం డెవలప్‌మెంట్ సర్వర్‌ని ఎలా అమలు చేయాలో మరియు దానిని స్థానిక ఫైల్ సిస్టమ్‌తో సమకాలీకరించడం ఎలాగో మేము చూపించాము. ఓపెన్‌షిఫ్ట్ పైప్‌లైన్‌లను ఉపయోగించి చైన్డ్-బిల్డ్ టెంప్లేట్‌ను ఎలా అనుకరించాలో కూడా మేము చూశాము. ఈ కథనం నుండి అన్ని ఉదాహరణ కోడ్‌లను కనుగొనవచ్చు .
అదనపు వనరులు (EN)
- ఉచిత ఇ-బుక్
- ఇతర వ్యాసాలు Red Hat వెబ్‌సైట్‌లో
రాబోయే వెబ్‌నార్ల ప్రకటనలు
మేము Red Hat OpenShift కంటైనర్ ప్లాట్‌ఫారమ్ మరియు Kubernetes ఉపయోగించి స్థానిక అనుభవం గురించి శుక్రవారం వెబ్‌నార్ల శ్రేణిని ప్రారంభిస్తున్నాము:
మూలం: www.habr.com