Hoi allegearre! Dit is de twadde post yn ús searje wêryn wy sjen litte hoe't jo moderne webapplikaasjes kinne ynsette op Red Hat OpenShift.
Yn 'e foarige post hawwe wy wat oanrekke op' e mooglikheden fan 'e nije S2I (boarne-nei-ôfbylding) bouwerôfbylding, dy't is ûntworpen foar it bouwen en ynsetten fan moderne webapplikaasjes op it OpenShift-platfoarm. Doe wiene wy ynteressearre yn it ûnderwerp fan it fluch ynsetten fan in applikaasje, en hjoed sille wy sjen hoe't jo in S2I-ôfbylding brûke as in "suvere" bouwerôfbylding en kombinearje it mei relatearre OpenShift-assemblies.
Skjin bouwerôfbylding
Lykas wy yn diel XNUMX neamden, hawwe de measte moderne webapplikaasjes in saneamde build-poadium, dy't typysk operaasjes útfiert lykas koade-transpilaasje, meardere triem-konkatenaasje en minifikaasje. De bestannen krigen as gefolch fan dizze operaasjes - en dit is statyske HTML, JavaScript en CSS - wurde opslein yn 'e útfiermap. De lokaasje fan dizze map hinget meastentiids ôf fan hokker bou-ark wurde brûkt, en foar React sil dit de ./build-map wêze (wy komme hjir yn mear detail hjirûnder werom).
Boarne-nei-ôfbylding (S2I)
Yn dit berjocht komme wy net oan it ûnderwerp "wat is S2I en hoe't jo it brûke" (jo kinne mear lêze oer dit ), mar it is wichtich om dúdlik te wêzen oer de twa stappen yn dit proses om te begripen wat in Web App Builder-ôfbylding docht.
Gearstalling faze
De gearstallingsfaze is fan aard heul gelyk oan wat bart as jo docker-build útfiere en einigje mei in nije Docker-ôfbylding. Dêrtroch komt dit poadium foar by it starten fan in build op it OpenShift-platfoarm.
Yn it gefal fan in Web App Builder-ôfbylding is it ferantwurdlik foar it ynstallearjen fan de ôfhinklikens fan jo applikaasje en it útfieren fan de build. . Standert brûkt de bouwerôfbylding de npm run build konstruksje, mar dit kin oerskreaun wurde troch de NPM_BUILD omjouwingsfariabele.
Lykas wy earder sein hawwe, hinget de lokaasje fan 'e ôfmakke, al boude applikaasje ôf fan hokker ark jo brûke. Bygelyks, yn it gefal fan React sil dit de map ./build wêze, en foar Angular-applikaasjes sil it de map project_name/dist wêze. En, lykas al werjûn yn 'e foarige post, kin de lokaasje fan' e útfiermap, dy't standert is ynsteld om te bouwen, oerskreaun wurde fia de omjouwingsfariabele OUTPUT_DIR. No, om't de lokaasje fan 'e útfiermap ferskilt fan ramt nei ramt, kopiearje jo gewoan de generearre útfier nei de standertmap yn' e ôfbylding, nammentlik /opt/apt-root/output. Dit is wichtich foar it begripen fan 'e rest fan dit artikel, mar litte wy no gau nei de folgjende faze sjen - de runfaze.
run faze
Dit poadium komt foar as in oprop oan docker-run wurdt makke op 'e nije ôfbylding dy't makke is yn' e gearstalling. Itselde bart by ynset op it OpenShift-platfoarm. Standert brûkt om statyske ynhâld te tsjinjen yn 'e boppesteande standert útfiermap.
Dizze metoade is goed foar it fluch ynsetten fan applikaasjes, mar it is oer it algemien net oan te rieden om statyske ynhâld op dizze manier te tsjinjen. No, om't wy yn 'e realiteit allinich statyske ynhâld tsjinje, hawwe wy Node.js net nedich yn ús ôfbylding ynstalleare - in webserver sil genôch wêze.
Mei oare wurden, by it gearstallen hawwe wy ien ding nedich, by it útfieren hawwe wy in oar nedich. Yn dizze situaasje komme keatlingbouwen goed fan pas.
Ketting bouwurken
Dit is wêr't se oer skriuwe yn 'e OpenShift-dokumintaasje:
"Twa gearkomsten kinne mei-inoar keppele wurde, wêrby't ien in kompilearre entiteit genereart en de oare dy entiteit host yn in aparte ôfbylding dy't wurdt brûkt om dy entiteit út te fieren."
Mei oare wurden, wy kinne de Web App Builder-ôfbylding brûke om ús build út te fieren, en dan de webserverôfbylding, deselde NGINX, brûke om ús ynhâld te tsjinjen.
Sa kinne wy de Web App Builder-ôfbylding brûke as in "suvere" bouwer en tagelyk in lyts runtime-ôfbylding hawwe.
No litte wy dit sjen mei in spesifyk foarbyld.
Foar training sille wy brûke , makke mei it kommandorigelark create-react-app.
It sil ús helpe om alles byinoar te setten .
Litte wy nei dit bestân yn mear detail sjen, en begjinne mei de seksje parameters.
parameters:
- name: SOURCE_REPOSITORY_URL
description: The source URL for the application
displayName: Source URL
required: true
- name: SOURCE_REPOSITORY_REF
description: The branch name for the application
displayName: Source Branch
value: master
required: true
- name: SOURCE_REPOSITORY_DIR
description: The location within the source repo of the application
displayName: Source Directory
value: .
required: true
- name: OUTPUT_DIR
description: The location of the compiled static files from your web apps builder
displayName: Output Directory
value: build
required: false
Alles hjir is frij dúdlik, mar it is it wurdich omtinken te jaan oan de parameter OUTPUT_DIR. Foar de React-applikaasje yn ús foarbyld is d'r neat te soargen oer, om't React de standertwearde brûkt as de útfiermap, mar yn it gefal fan Angular as wat oars, sil dizze parameter moatte wurde wizige as nedich.
Litte wy no ris sjen nei de seksje ImageStreams.
- apiVersion: v1
kind: ImageStream
metadata:
name: react-web-app-builder // 1
spec: {}
- apiVersion: v1
kind: ImageStream
metadata:
name: react-web-app-runtime // 2
spec: {}
- apiVersion: v1
kind: ImageStream
metadata:
name: web-app-builder-runtime // 3
spec:
tags:
- name: latest
from:
kind: DockerImage
name: nodeshift/ubi8-s2i-web-app:10.x
- apiVersion: v1
kind: ImageStream
metadata:
name: nginx-image-runtime // 4
spec:
tags:
- name: latest
from:
kind: DockerImage
name: 'centos/nginx-112-centos7:latest'
Sjoch ris nei de tredde en fjirde ôfbyldings. Se wurde beide definieare as Docker-ôfbyldings, en jo kinne dúdlik sjen wêr't se wei komme.
De tredde ôfbylding is web-app-builder en it komt fan nodeshift/ubi8-s2i-web-app tagged 10.x op .
De fjirde is in NGINX-ôfbylding (ferzje 1.12) mei de lêste tag op .
Litte wy no nei de earste twa ôfbyldings sjen. Se binne beide leech by it begjin en wurde allinich makke yn 'e boufaze. De earste ôfbylding, react-web-app-builder, sil it resultaat wêze fan in assemblagestap dy't de web-app-builder-runtime-ôfbylding en ús boarnekoade kombinearje. Dêrom hawwe wy "-bouwer" tafoege oan de namme fan dizze ôfbylding.
De twadde ôfbylding - react-web-app-runtime - sil it resultaat wêze fan it kombinearjen fan nginx-image-runtime en guon bestannen fan 'e react-web-app-builder-ôfbylding. Dizze ôfbylding sil ek brûkt wurde by ynset en sil allinich de webserver en statyske HTML, JavaScript, CSS fan ús applikaasje befetsje.
Yn 'e war? Litte wy no ris sjen nei de boukonfiguraasjes en it sil in bytsje dúdliker wurde.
Us sjabloan hat twa boukonfiguraasjes. Hjir is de earste, en it is frij standert:
apiVersion: v1
kind: BuildConfig
metadata:
name: react-web-app-builder
spec:
output:
to:
kind: ImageStreamTag
name: react-web-app-builder:latest // 1
source: // 2
git:
uri: ${SOURCE_REPOSITORY_URL}
ref: ${SOURCE_REPOSITORY_REF}
contextDir: ${SOURCE_REPOSITORY_DIR}
type: Git
strategy:
sourceStrategy:
env:
- name: OUTPUT_DIR // 3
value: ${OUTPUT_DIR}
from:
kind: ImageStreamTag
name: web-app-builder-runtime:latest // 4
incremental: true // 5
type: Source
triggers: // 6
- github:
secret: ${GITHUB_WEBHOOK_SECRET}
type: GitHub
- type: ConfigChange
- imageChange: {}
type: ImageChange
Sa't jo sjen kinne, seit de line mei label 1 dat it resultaat fan dizze build sil wurde pleatst yn deselde react-web-app-builder-ôfbylding dy't wy in bytsje earder seagen yn 'e seksje ImageStreams.
De rigel bestimpele 2 fertelt jo wêr te krijen de koade út. Yn ús gefal is dit in git-repository, en de lokaasje, ref en kontekstmap wurde bepaald troch de parameters dy't wy hjirboppe al seagen.
De line markearre 3 is wat wy al seagen yn 'e seksje parameters. It foeget de omjouwingsfariabele OUTPUT_DIR ta, dy't yn ús foarbyld boud is.
De line mei it label 4 seit om it web-app-builder-runtime-ôfbylding te brûken, dat wy al seagen yn 'e seksje ImageStream.
Line label 5 seit dat wy in inkrementele build wolle brûke as de S2I-ôfbylding it stipet, en de Web App Builder-ôfbylding docht. By de earste lansearring, nei it foltôgjen fan it assemblagestadium, sil de ôfbylding de map node_modules opslaan yn in argyfbestân. Dan, by folgjende runs, sil de ôfbylding dizze map gewoan unzip om de boutiid te ferminderjen.
En as lêste is de line mei it label 6 mar in pear triggers om de build automatysk te meitsjen, sûnder manuele yntervinsje, as wat feroaret.
Oer it algemien is dit in aardich standert bouwkonfiguraasje.
Litte wy no sjen nei de twadde boukonfiguraasje. It is heul gelyk oan de earste, mar d'r is ien wichtich ferskil.
apiVersion: v1
kind: BuildConfig
metadata:
name: react-web-app-runtime
spec:
output:
to:
kind: ImageStreamTag
name: react-web-app-runtime:latest // 1
source: // 2
type: Image
images:
- from:
kind: ImageStreamTag
name: react-web-app-builder:latest // 3
paths:
- sourcePath: /opt/app-root/output/. // 4
destinationDir: . // 5
strategy: // 6
sourceStrategy:
from:
kind: ImageStreamTag
name: nginx-image-runtime:latest
incremental: true
type: Source
triggers:
- github:
secret: ${GITHUB_WEBHOOK_SECRET}
type: GitHub
- type: ConfigChange
- type: ImageChange
imageChange: {}
- type: ImageChange
imageChange:
from:
kind: ImageStreamTag
name: react-web-app-builder:latest // 7
Dat de twadde boukonfiguraasje is react-web-app-runtime, en it begjint frij standert.
De line mei it label 1 is neat nij - it seit gewoan dat it bouresultaat wurdt pleatst yn 'e react-web-app-runtime-ôfbylding.
De rigel bestimpele 2, lykas yn 'e foarige konfiguraasje, jout oan wêr't jo de boarnekoade krije. Mar merk op dat hjir wy sizze dat it is nommen út it byld. Boppedat, fan 'e ôfbylding dy't wy krekt makke hawwe - fan react-web-app-builder (oanjûn yn' e rigel bestimpele 3). De bestannen dy't wy wolle brûke binne yn 'e ôfbylding en har lokaasje is ynsteld yn' e rigel mei 4, yn ús gefal is it /opt/app-root/output/. As jo it ûnthâlde, is dit wêr't de bestannen genereare op basis fan 'e resultaten fan it bouwen fan ús applikaasje wurde opslein.
De bestimmingsmap spesifisearre yn 'e term mei label 5 is gewoan de aktuele map (dit is alles, tink derom, rint binnen in magysk ding neamd OpenShift, en net op jo lokale kompjûter).
De strategy seksje - line bestimpele 6 - is ek gelyk oan de earste build konfiguraasje. Allinnich dizze kear sille wy nginx-image-runtime brûke, dy't wy al seagen yn 'e ImageStream-seksje.
Uteinlik is de line mei it label 7 in seksje fan triggers dy't dizze build sil aktivearje elke kear as it react-web-app-builder-ôfbylding feroaret.
Oars, dit sjabloan befettet moaie standert ynset konfiguraasje, likegoed as dingen dy't relatearje oan tsjinsten en rûtes, mar wy sille net gean op dat te folle detail. Tink derom dat de ôfbylding dy't sil wurde ynset de react-web-app-runtime-ôfbylding is.
Applikaasje ynset
Dus no't wy nei it sjabloan hawwe sjoen, litte wy sjen hoe't jo it brûke om in applikaasje te ynsetten.
Wy kinne it OpenShift-kliïntark neamd oc brûke om ús sjabloan yn te setten:
$ find . | grep openshiftio | grep application | xargs -n 1 oc apply -f
$ oc new-app --template react-web-app -p SOURCE_REPOSITORY_URL=https://github.com/lholmquist/react-web-app
It earste kommando yn 'e skermôfbylding hjirboppe is in bewuste technysk manier om in sjabloan te finen./openshiftio/application.yaml.
It twadde kommando makket gewoan in nije applikaasje basearre op dit sjabloan.
Nei't dizze kommando's wurkje, sille wy sjen dat wy twa gearkomsten hawwe:
En werom nei it Oersjoch skerm, sille wy de lansearre pod sjen:
Klikje op de keppeling en wy wurde nei ús app brocht, dat is de standert React App-side:
Oanfolling 1
Foar Angular leafhawwers hawwe wy ek .
It patroan hjir is itselde, útsein foar de fariabele OUTPUT_DIR.
Oanfolling 2
Yn dit artikel hawwe wy NGINX brûkt as webserver, mar it is frij maklik om it te ferfangen mei Apache, feroarje gewoan it sjabloan yn it bestân op .
konklúzje
Yn it earste diel fan dizze searje lieten wy sjen hoe't jo moderne webapplikaasjes fluch kinne ynsette op it OpenShift-platfoarm. Hjoed hawwe wy sjoen nei wat in Web App-ôfbylding docht en hoe't it kin wurde kombinearre mei in suvere webserver lykas NGINX mei kettingbuilden om in mear produksje-ree applikaasje te meitsjen. Yn it folgjende en lêste artikel yn dizze searje sille wy sjen litte hoe't jo in ûntwikkelingstsjinner foar jo applikaasje kinne útfiere op OpenShift en soargje foar syngronisaasje fan lokale en bestannen op ôfstân.
Ynhâld fan dizze rige fan artikels
- Part fan 1: ;
- Diel 2: Hoe kinne jo in nije S2I-ôfbylding brûke mei in besteande HTTP-tsjinnerôfbylding, lykas NGINX, mei help fan assosjearre OpenShift-assemblies foar produksje-ynset;
- Diel 3: hoe't jo in ûntwikkelingstsjinner útfiere foar jo applikaasje op it OpenShift-platfoarm en syngronisearje mei it lokale bestânsysteem.
Oanfoljende boarnen
- Fergees e-book .
- Ynformaasje oer .
Boarne: www.habr.com