Hallo elkenien op dizze blog! Dit is de tredde post yn in searje wêryn wy sjen litte hoe't jo moderne webapplikaasjes kinne ynsette op Red Hat OpenShift.
Yn 'e foargeande twa berjochten lieten wy sjen hoe't jo moderne webapplikaasjes yn mar in pear stappen kinne ynsette en hoe't jo in nije S2I-ôfbylding kinne brûke tegearre mei in off-the-shelf HTTP-tsjinnerôfbylding, lykas NGINX, mei keatling builds om produksje-ynset te orkestrearjen .
Hjoed sille wy sjen litte hoe't jo in ûntwikkelingsserver foar jo applikaasje útfiere op it OpenShift-platfoarm en syngronisearje mei it lokale bestânsysteem, en ek prate oer wat OpenShift Pipelines binne en hoe't se kinne wurde brûkt as alternatyf foar keppele assemblies.
OpenShift as ûntwikkelingsomjouwing
Untwikkeling workflow
Lykas al sein yn , it typyske ûntwikkelingsproses foar moderne webapplikaasjes is gewoan in soarte fan "ûntwikkelingstsjinner" dy't feroaringen nei lokale bestannen folget. As se foarkomme, wurdt de applikaasje-build ynskeakele en dan wurdt it bywurke nei de browser.
Yn de measte moderne kaders is sa'n "ûntwikkelingsserver" ynboud yn 'e oerienkommende kommandorigel-ark.
Lokaal foarbyld
Litte wy earst sjen hoe't dit wurket by it útfieren fan applikaasjes lokaal. Litte wy de applikaasje as foarbyld nimme út eardere artikels, hoewol't hast deselde workflow konsepten jilde yn alle oare moderne kaders.
Dat, om de "dev-server" te begjinnen yn ús React-foarbyld, sille wy it folgjende kommando ynfiere:
$ npm run start
Dan sille wy yn it terminalfinster sa'n ding sjen:
En ús applikaasje sil iepenje yn 'e standertbrowser:
No, as wy wizigingen meitsje yn it bestân, moat de applikaasje yn 'e browser bywurkje.
OK, alles is dúdlik mei ûntwikkeling yn lokale modus, mar hoe kinne jo itselde berikke op OpenShift?
Untwikkelingstsjinner op OpenShift
As jo ûnthâlde, yn , wy seagen nei de saneamde runfaze fan 'e S2I-ôfbylding en seagen dat standert de tsjinstmodule ferantwurdlik is foar it betsjinjen fan ús webapplikaasje.
Lykwols, as jo nimme in tichterby fan dat foarbyld befettet it de omjouwingsfariabele $NPM_RUN, wêrtroch jo jo kommando kinne útfiere.
Wy kinne bygelyks de nodeshift-module brûke om ús applikaasje yn te setten:
$ npx nodeshift --deploy.env NPM_RUN="yarn start" --dockerImage=nodeshift/ubi8-s2i-web-app
Opmerking: It boppesteande foarbyld is ôfkoarte om it algemiene idee te yllustrearjen.
Hjir hawwe wy de NPM_RUN-omjouwingsfariabele tafoege oan ús ynset, dy't de runtime fertelt om it yarn start-kommando út te fieren, dat de React-ûntwikkelingsserver yn ús OpenShift-pod begjint.
As jo nei it log fan in rinnende pod sjogge, sil it der sa útsjen:
Fansels sil dit alles neat wêze oant wy de lokale koade kinne syngronisearje mei de koade, dy't ek kontrolearre wurdt foar feroaringen, mar libbet op in tsjinner op ôfstân.
Syngronisearje op ôfstân en lokale koade
Gelokkich kin nodeshift maklik helpe mei syngronisaasje, en jo kinne it horloazjekommando brûke om feroarings te folgjen.
Dus nei't wy it kommando hawwe útfierd om de ûntwikkelingstsjinner foar ús applikaasje yn te setten, kinne wy it folgjende kommando feilich brûke:
$ npx nodeshift watch
As gefolch sil in ferbining makke wurde mei de rinnende pod dy't wy in bytsje earder makke hawwe, de syngronisaasje fan ús lokale bestannen mei it kluster op ôfstân wurdt aktivearre, en de bestannen op ús lokale systeem sille begjinne te kontrolearjen foar feroaringen.
Dêrom, as wy no it src/App.js-bestân bywurkje, sil it systeem reagearje op dizze wizigingen, kopiearje se nei it kluster op ôfstân en begjinne de ûntwikkelingstsjinner, dy't dan ús applikaasje yn 'e browser bywurkje.
Om de ôfbylding te foltôgjen, litte wy sjen hoe't dizze heule kommando's der útsjen:
$ 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
It horloazjekommando is in abstraksje boppe op it kommando oc rsync, jo kinne mear leare oer hoe't it wurket .
Dit wie in foarbyld foar React, mar krekt deselde metoade kin brûkt wurde mei oare kaders, set gewoan de NPM_RUN omjouwingsfariabele yn as nedich.
Openshift Pipelines
Folgjende sille wy prate oer in ark lykas OpenShift Pipelines en hoe't it kin wurde brûkt as alternatyf foar keatling builds.
Wat is OpenShift Pipelines
OpenShift Pipelines is in cloud-native CI / CD trochgeande yntegraasje- en leveringsysteem ûntworpen foar it organisearjen fan pipelines mei Tekton. Tekton is in fleksibel iepen-boarne Kubernetes-native CI / CD-ramt wêrmei jo de ynset op ferskate platfoarms (Kubernetes, serverless, firtuele masines, ensfh.) kinne automatisearje troch abstraksje fan 'e ûnderlizzende laach.
In begripe dit artikel fereasket wat kennis fan Pipelines, dus wy riede sterk oan dat jo earst lêze .
It ynstellen fan jo wurkomjouwing
Om te boartsjen mei de foarbylden yn dit artikel, moatte jo earst jo wurkomjouwing tariede:
- Ynstallearje en konfigurearje in OpenShift 4-kluster. Us foarbylden brûke hjirfoar CodeReady Containers (CRD), wêrfan ynstallaasje-ynstruksjes te finen binne .
- Nei't it kluster klear is, moatte jo Pipeline Operator derop ynstallearje. Wês net bang, it is maklik, ynstallaasje ynstruksjes .
- Download (tkn) .
- Rinne it create-react-app kommandorigelark út om in applikaasje te meitsjen dy't jo dan sille ynsette (dit is in ienfâldige applikaasje ).
- (Opsjoneel) Kloon it repository om de foarbyldapplikaasje lokaal út te fieren mei npm install en dan npm start.
De applikaasje-repository sil ek in k8s-map hawwe, dy't de Kubernetes/OpenShift YAML's sil befetsje dy't brûkt wurde om de applikaasje yn te setten. D'r sille Tasks, ClusterTasks, Resources en Pipelines wêze dy't wy hjiryn sille oanmeitsje .
Litte wy begjinne
De earste stap foar ús foarbyld is om in nij projekt te meitsjen yn it OpenShift-kluster. Litte wy dit projekt webapp-pipeline neame en it oanmeitsje mei it folgjende kommando:
$ oc new-project webapp-pipeline
Dizze projektnamme sil letter yn 'e koade ferskine, dus as jo beslute om it wat oars te neamen, ferjit dan net de foarbyldkoade dêrop te bewurkjen. Fanôf dit punt sille wy net fan boppen nei ûnderen gean, mar fan ûnderen nei boppen: dat is, wy sille earst alle komponinten fan 'e transportband meitsje, en pas dan de transportband sels.
Dus, earst fan alle ...
Taken
Litte wy in pear taken oanmeitsje, dy't dan sille helpe de applikaasje yn ús pipeline yn te setten. De earste taak - apply_manifests_task - is ferantwurdlik foar it tapassen fan de YAML fan dy Kubernetes-boarnen (tsjinst, ynset en rûte) dy't lizze yn 'e k8s-map fan ús applikaasje. De twadde taak - update_deployment_task - is ferantwurdlik foar it bywurkjen fan in al ynset ôfbylding nei de ien makke troch ús pipeline.
Meitsje jo gjin soargen as it noch net heul dúdlik is. Yn feite, dizze taken binne wat as nutsbedriuwen, en wy sille sjen nei se yn mear detail in bytsje letter. Foar no, litte wy se gewoan meitsje:
$ 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
Dan, mei it tkn CLI kommando, sille wy kontrolearje dat de taken binne makke:
$ tkn task ls
NAME AGE
apply-manifests 1 minute ago
update-deployment 1 minute ago
Opmerking: Dit binne lokale taken foar jo hjoeddeistige projekt.
Cluster taken
Clustertaken binne yn prinsipe itselde as ienfâldige taken. Dat is, it is in werbrûkbere kolleksje fan stappen dy't op ien of oare manier wurde kombineare by it útfieren fan in spesifike taak. It ferskil is dat in klustertaak oeral binnen it kluster beskikber is. Om de list mei klustertaken te sjen dy't automatysk wurde oanmakke by it tafoegjen fan Pipeline Operator, sille wy opnij it tkn CLI kommando brûke:
$ 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
Litte wy no twa klustertaken oanmeitsje. De earste sil it S2I-ôfbylding generearje en it stjoere nei it ynterne OpenShift-register; de twadde is om ús ôfbylding te bouwen basearre op NGINX, mei de applikaasje dy't wy al hawwe boud as ynhâld.
Meitsje en stjoer de ôfbylding
By it meitsjen fan de earste taak sille wy werhelje wat wy al dien hawwe yn it foarige artikel oer keppele gearkomsten. Tink derom dat wy de S2I-ôfbylding (ubi8-s2i-web-app) brûkten om ús applikaasje te "bouwen", en einige mei in ôfbylding opslein yn it ynterne register fan OpenShift. No sille wy dizze S2I-webappôfbylding brûke om in DockerFile foar ús app te meitsjen en dan Buildah brûke om de eigentlike build te dwaan en de resultearjende ôfbylding nei it OpenShift ynterne register te triuwen, om't dat krekt is wat OpenShift docht as jo jo applikaasjes ynsette mei NodeShift .
Hoe wisten wy dit alles, freegje jo? Fan , wy hawwe it gewoan kopieare en foar ússels oanpast.
Dat, litte wy no de s2i-web-app-klustertaak oanmeitsje:
$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/clustertasks/s2i-web-app-task.yaml
Wy sille dit net yn detail analysearje, mar sille allinich rjochtsje op 'e parameter OUTPUT_DIR:
params:
- name: OUTPUT_DIR
description: The location of the build output directory
default: build
Standert is dizze parameter gelyk oan build, dat is wêr't React de gearstalde ynhâld pleatst. Oare kaders brûke ferskillende paden, bygelyks, yn Ember is it dist. De útfier fan ús earste klustertaak sil in ôfbylding wêze mei de HTML, JavaScript en CSS dy't wy hawwe sammele.
Bou in ôfbylding basearre op NGINX
Wat ús twadde klustertaak oanbelanget, moat it in NGINX-basearre ôfbylding foar ús bouwe, mei de ynhâld fan 'e applikaasje dy't wy al hawwe boud. Yn essinsje is dit it diel fan 'e foarige seksje wêr't wy seagen nei keatlingbouwen.
Om dit te dwaan, sille wy - krekt itselde as krekt hjirboppe - in klustertaak meitsje webapp-build-runtime:
$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/clustertasks/webapp-build-runtime-task.yaml
As jo nei de koade foar dizze klustertaken sjogge, kinne jo sjen dat it it Git-repository net spesifisearret wêrmei wy wurkje of de nammen fan 'e ôfbyldings dy't wy meitsje. Wy spesifisearje allinich wat wy krekt oerdrage nei Git, as in bepaalde ôfbylding wêr't de definitive ôfbylding moat wurde útfierd. Dit is wêrom dizze klustertaken kinne wurde opnij brûkt by it wurkjen mei oare applikaasjes.
En hjir geane wy gracieus troch nei it folgjende punt ...
Resources
Dat, om't, lykas wy krekt sein hawwe, klustertaken sa algemien mooglik wêze moatte, moatte wy boarnen meitsje dy't sille wurde brûkt as ynfier (it Git-repository) en as útfier (de definitive ôfbyldings). De earste boarne dy't wy nedich binne is Git, wêr't ús applikaasje wennet, sa'n ding:
# 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
Hjir is PipelineResource fan type git. De url-kaai yn 'e params-seksje wiist nei in spesifyk repository en spesifisearret de mastertûke (dit is opsjoneel, mar wy skriuwe it foar folsleinens).
No moatte wy in boarne meitsje foar de ôfbylding wêr't de resultaten fan 'e s2i-web-app taak wurde opslein, dit wurdt dien sa:
# 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
Hjir is de PipelineResource fan it type ôfbylding, en de wearde fan 'e url-parameter wiist nei it ynterne OpenShift Image Registry, spesifyk de iene yn' e webapp-pipeline-nammeromte. Ferjit net dizze ynstelling te feroarjen as jo in oare nammeromte brûke.
En úteinlik sil de lêste boarne dy't wy nedich binne ek fan typeôfbylding wêze en dit sil de definitive NGINX-ôfbylding wêze dy't dan sil wurde brûkt tidens ynset:
# 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
Tink derom nochris dat dizze boarne de ôfbylding opslaat yn it ynterne OpenShift-register yn 'e webapp-pipeline-nammeromte.
Om al dizze boarnen tagelyk te meitsjen, brûke wy it kommando oanmeitsje:
$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/resources/resource.yaml
Jo kinne derfoar soargje dat de boarnen sa makke binne:
$ tkn resource ls
Conveyor pipeline
No't wy alle nedige komponinten hawwe, litte wy in pipeline fan har sammelje troch it te meitsjen mei it folgjende kommando:
$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/pipelines/build-and-deploy-react.yaml
Mar foardat wy dit kommando útfiere, litte wy nei dizze komponinten sjen. De earste is de namme:
apiVersion: tekton.dev/v1alpha1
kind: Pipeline
metadata:
name: build-and-deploy-react
Dan sjogge wy yn 'e spesifikaasjes in yndikaasje fan' e boarnen dy't wy earder makke hawwe:
spec:
resources:
- name: web-application-repo
type: git
- name: built-web-application-image
type: image
- name: runtime-web-application-image
type: image
Wy meitsje dan de taken dy't ús pipeline moat foltôgje. As earste moat it de s2i-web-app taak útfiere dy't wy al hawwe makke:
tasks:
- name: build-web-application
taskRef:
name: s2i-web-app
kind: ClusterTask
Dizze taak nimt input (gir boarne) en útfier (built-web-applikaasje-ôfbylding boarne) parameters. Wy jouwe it ek in spesjale parameter troch, sadat it TLS net ferifiearret, om't wy sels-ûndertekene sertifikaten brûke:
resources:
inputs:
- name: source
resource: web-application-repo
outputs:
- name: image
resource: built-web-application-image
params:
- name: TLSVERIFY
value: "false"
De folgjende taak is hast itselde, allinich hjir hjit de webapp-build-runtime-klustertaak dy't wy al makke hawwe:
name: build-runtime-image
taskRef:
name: webapp-build-runtime
kind: ClusterTask
Lykas by de foarige taak, passe wy in boarne troch, mar no is it boud-web-applikaasje-ôfbylding (de útfier fan ús foarige taak). En as útfier sette wy it byld wer yn. Sûnt dizze taak moat wurde útfierd nei de foarige, foegje wy it runAfter-fjild ta:
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
De folgjende twa taken binne ferantwurdlik foar it brûken fan de tsjinst, rûte en ynset YAML-bestannen dy't libje yn 'e k8s-map fan ús webapplikaasje, en ek foar it bywurkjen fan dizze ynset by it meitsjen fan nije ôfbyldings. Wy definieare dizze twa klustertaken oan it begjin fan it artikel.
Begjin fan de transportband
Dat, alle dielen fan ús pipeline wurde makke, en wy sille it útfiere mei it folgjende kommando:
$ tkn pipeline start build-and-deploy-react
Op dit stadium wurdt de kommandorigel ynteraktyf brûkt en jo moatte de passende boarnen selektearje yn antwurd op elk fan har oanfragen: foar de git-boarne, selektearje web-applikaasje-repo, dan foar de earste ôfbyldingsboarne, boud-web-applikaasje -ôfbylding, en as lêste, foar twadde ôfbyldingsboarne -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
Litte wy no de status fan 'e pipeline kontrolearje mei it folgjende kommando:
$ tkn pipeline logs -f
Sadree't de pipeline is begon en de applikaasje is ynset, kinne wy de publisearre rûte oanfreegje mei it folgjende kommando:
$ oc get route react-pipeline-example --template='http://{{.spec.host}}'
Foar gruttere fisualisaasje kinne jo ús pipeline besjen yn 'e Untwikkeldersmodus fan' e webkonsole yn 'e seksje Pipelines, lykas werjûn yn Fig. 1.
Fig.1. Oersjoch fan rinnende pipelines.
Klikje op in rinnende pipeline toant ekstra details, lykas werjûn yn figuer 2.
Rys. 2. Oanfoljende ynformaasje oer de pipeline.
Nei mear ynformaasje kinne jo rinnende applikaasjes sjen yn 'e werjefte Mjitkunde, lykas werjûn yn Fig.
Fig 3. Lansearre pod.
Klikje op 'e sirkel yn' e rjochter boppeste hoeke fan it byldkaike iepenet ús applikaasje, lykas werjûn yn Fig. 4.
Rys. 4. Running React applikaasje.
konklúzje
Dat, wy lieten sjen hoe't jo in ûntwikkelingstsjinner foar jo applikaasje op OpenShift kinne útfiere en it syngronisearje mei it lokale bestânsysteem. Wy hawwe ek sjoen nei hoe't jo in keatling-bouwsjabloan kinne simulearje mei OpenShift Pipelines. Alle foarbyldkoades út dit artikel kinne fûn wurde .
Oanfoljende boarnen (EN)
- Fergees e-book
- Oare artikels oer op de webside fan Red Hat
Oankundigings fan kommende webinars
Wy begjinne in searje freed webinars oer lânseigen ûnderfining mei it brûken fan Red Hat OpenShift Container Platform en Kubernetes:
Boarne: www.habr.com