Hi almal! Dit is die tweede pos in ons reeks waarin ons wys hoe om moderne webtoepassings op Red Hat OpenShift te ontplooi.
In die vorige pos het ons die vermoëns van die nuwe S2I (bron-na-beeld)-bouerbeeld effens aangeraak, wat ontwerp is om moderne webtoepassings op die OpenShift-platform te bou en te ontplooi. Toe was ons geïnteresseerd in die onderwerp om 'n toepassing vinnig te ontplooi, en vandag sal ons kyk hoe om 'n S2I-beeld as 'n "suiwer" bouerbeeld te gebruik en dit met verwante OpenShift-samestellings te kombineer.
Skoon bouer-beeld
Soos ons in Deel XNUMX genoem het, het die meeste moderne webtoepassings 'n sogenaamde boustadium, wat tipies bewerkings uitvoer soos kodetranspilasie, veelvuldige lêeraaneenskakeling en minifikasie. Die lêers wat as gevolg van hierdie bewerkings verkry is - en dit is statiese HTML, JavaScript en CSS - word in die uitvoerlêergids gestoor. Die ligging van hierdie vouer hang gewoonlik af van watter bouhulpmiddels gebruik word, en vir React sal dit die ./build-lêergids wees (ons sal hieronder in meer besonderhede terugkom).
Bron-na-Beeld (S2I)
In hierdie pos raak ons nie aan die onderwerp "wat is S2I en hoe om dit te gebruik" nie (jy kan meer hieroor lees ), maar dit is belangrik om duidelik te wees oor die twee stappe in hierdie proses om te verstaan wat 'n Web App Builder-prent doen.
Vergadering fase
Die samestellingsfase is baie soortgelyk van aard aan wat gebeur wanneer jy docker-bou uitvoer en eindig met 'n nuwe Docker-beeld. Gevolglik vind hierdie stadium plaas wanneer 'n bou op die OpenShift-platform begin word.
In die geval van 'n Web App Builder-prent, is dit verantwoordelik vir die installering van jou toepassing se afhanklikhede en die uitvoering van die bou. . By verstek gebruik die bouer-beeld die npm run-boukonstruksie, maar dit kan deur die NPM_BUILD-omgewingsveranderlike oorskryf word.
Soos ons vroeër gesê het, hang die ligging van die voltooide, reeds geboude toepassing af van watter gereedskap u gebruik. Byvoorbeeld, in die geval van React sal dit die ./build-lêergids wees, en vir Angular-toepassings sal dit die project_name/dist-lêergids wees. En, soos reeds in die vorige pos getoon, kan die ligging van die uitvoergids, wat by verstek gestel is om te bou, deur die OUTPUT_DIR omgewingsveranderlike oorskryf word. Wel, aangesien die ligging van die uitvoerlêer van raamwerk tot raamwerk verskil, kopieer jy eenvoudig die gegenereerde uitvoer na die standaardlêergids in die prent, naamlik /opt/apt-root/output. Dit is belangrik om die res van hierdie artikel te verstaan, maar kom ons kyk vir eers vinnig na die volgende fase – die hardloopfase.
hardloop fase
Hierdie stadium vind plaas wanneer 'n oproep na docker run gemaak word op die nuwe beeld wat tydens die monteerfase geskep is. Dieselfde gebeur wanneer dit op die OpenShift-platform ontplooi word. Verstek gebruike om statiese inhoud te bedien wat in die bogenoemde standaard uitvoergids geleë is.
Hierdie metode is goed om toepassings vinnig te ontplooi, maar dit word gewoonlik nie aanbeveel om statiese inhoud op hierdie manier te bedien nie. Wel, aangesien ons in werklikheid slegs statiese inhoud bedien, het ons nie Node.js nodig wat binne ons beeld geïnstalleer is nie - 'n webbediener sal voldoende wees.
Met ander woorde, wanneer ons saamstel, het ons een ding nodig, wanneer ons uitgevoer word, het ons 'n ander nodig. In hierdie situasie kom vasgekettings handig te pas.
Geketting bouwerk
Dit is waaroor hulle skryf in die OpenShift-dokumentasie:
"Twee samestellings kan aan mekaar gekoppel word, met een wat 'n saamgestelde entiteit genereer en die ander huisves daardie entiteit in 'n aparte prent wat gebruik word om daardie entiteit te bestuur."
Met ander woorde, ons kan die Web App Builder-beeld gebruik om ons bou te laat loop, en dan die webbediener-beeld, dieselfde NGINX, gebruik om ons inhoud te bedien.
Ons kan dus die Web App Builder-beeld as 'n "suiwer" bouer gebruik en terselfdertyd 'n klein runtime-beeld hê.
Kom ons kyk nou hierna met 'n spesifieke voorbeeld.
Vir opleiding sal ons gebruik , geskep met behulp van die create-react-app-opdragreëlnutsding.
Dit sal ons help om alles bymekaar te sit .
Kom ons kyk na hierdie lêer in meer detail, en begin met die parameters afdeling.
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 hier is redelik duidelik, maar dit is die moeite werd om aandag te skenk aan die OUTPUT_DIR-parameter. Vir die React-toepassing in ons voorbeeld is daar niks om oor bekommerd te wees nie, aangesien React die verstekwaarde as die uitvoerlêergids gebruik, maar in die geval van Angular of iets anders, sal hierdie parameter verander moet word soos nodig.
Kom ons kyk nou na die ImageStreams-afdeling.
- 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'
Kyk na die derde en vierde beelde. Hulle word albei gedefinieer as Docker-beelde, en jy kan duidelik sien waar hulle vandaan kom.
Die derde prent is web-app-bouer en dit kom van nodeshift/ubi8-s2i-web-app gemerk 10.x op .
Die vierde is 'n NGINX-beeld (weergawe 1.12) met die nuutste merker aan .
Kom ons kyk nou na die eerste twee beelde. Hulle is albei leeg aan die begin en word slegs tydens die boufase geskep. Die eerste prent, reageer-web-app-bouer, sal die resultaat wees van 'n samestellingstap wat die web-app-bouer-looptydbeeld en ons bronkode sal kombineer. Daarom het ons "-bouer" by die naam van hierdie prent gevoeg.
Die tweede prent - react-web-app-runtime - sal die resultaat wees van die kombinasie van nginx-image-runtime en sommige lêers vanaf die react-web-app-builder-prent. Hierdie prent sal ook tydens ontplooiing gebruik word en sal slegs die webbediener en statiese HTML, JavaScript, CSS van ons toepassing bevat.
Verward? Kom ons kyk nou na die boukonfigurasies en dit sal 'n bietjie duideliker word.
Ons sjabloon het twee boukonfigurasies. Hier is die eerste een, en dit is redelik standaard:
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
Soos u kan sien, sê die reël met etiket 1 dat die resultaat van hierdie bou in dieselfde react-web-app-builder-beeld geplaas sal word wat ons 'n bietjie vroeër in die ImageStreams-afdeling gesien het.
Die reël gemerk 2 vertel jou waar om die kode vandaan te kry. In ons geval is dit 'n git-bewaarplek, en die ligging, ref en kontekslêer word bepaal deur die parameters wat ons reeds hierbo gesien het.
Die lyn gemerk 3 is wat ons reeds in die parameters-afdeling gesien het. Dit voeg die OUTPUT_DIR omgewingsveranderlike by, wat in ons voorbeeld gebou is.
Die reël gemerk 4 sê om die web-app-builder-runtime-beeld te gebruik, wat ons reeds in die ImageStream-afdeling gesien het.
Reël gemerk 5 sê dat ons 'n inkrementele bou wil gebruik as die S2I-beeld dit ondersteun, en die Web App Builder-prent wel. By die eerste bekendstelling, nadat die samestellingfase voltooi is, sal die prent die node_modules-lêergids in 'n argieflêer stoor. Dan, met daaropvolgende lopies, sal die prent eenvoudig hierdie vouer uitpak om boutyd te verminder.
En ten slotte, die lyn gemerk 6 is net 'n paar snellers om die bou outomaties te laat loop, sonder handmatige ingryping, wanneer iets verander.
In die algemeen is dit 'n redelik standaard boukonfigurasie.
Kom ons kyk nou na die tweede boukonfigurasie. Dit is baie soortgelyk aan die eerste een, maar daar is een belangrike verskil.
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
Die tweede boukonfigurasie is dus react-web-app-runtime, en dit begin redelik standaard.
Die reël gemerk 1 is niks nuuts nie - dit sê eenvoudig dat die bouresultaat in die react-web-app-runtime-beeld geplaas word.
Die reël gemerk 2, soos in die vorige konfigurasie, dui aan waar om die bronkode vandaan te kry. Maar let op dat ons hier sê dat dit uit die beeld geneem is. Boonop, van die beeld wat ons sopas geskep het - van react-web-app-builder (aangedui in reël gemerk 3). Die lêers wat ons wil gebruik, is binne die prent en hul ligging daar is in lyn gemerk 4, in ons geval is dit /opt/app-root/output/. As jy onthou, dit is waar die lêers wat gegenereer word op grond van die resultate van die bou van ons toepassing gestoor word.
Die bestemmingslêergids wat in die term met etiket 5 gespesifiseer word, is bloot die huidige gids (dit is alles, onthou, dit loop binne 'n magiese ding genaamd OpenShift, en nie op jou plaaslike rekenaar nie).
Die strategie-afdeling – reël gemerk 6 – is ook soortgelyk aan die eerste bou-konfigurasie. Slegs hierdie keer gaan ons nginx-image-runtime gebruik, wat ons reeds in die ImageStream-afdeling gesien het.
Laastens, die lyn gemerk 7 is 'n gedeelte van snellers wat hierdie bou sal aktiveer elke keer as die reageer-web-app-bouer-beeld verander.
Andersins bevat hierdie sjabloon redelik standaard ontplooiingskonfigurasie, sowel as dinge wat verband hou met dienste en roetes, maar ons sal nie te veel in daardie besonderhede ingaan nie. Neem asseblief kennis dat die prent wat ontplooi sal word die react-web-app-runtime-prent is.
Toepassing ontplooiing
So nou dat ons na die sjabloon gekyk het, kom ons kyk hoe om dit te gebruik om 'n toepassing te ontplooi.
Ons kan die OpenShift-kliëntinstrument genaamd oc gebruik om ons sjabloon te implementeer:
$ 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
Die eerste opdrag in die skermkiekie hierbo is 'n doelbewuste ingenieurswyse om 'n sjabloon te vind./openshiftio/application.yaml.
Die tweede opdrag skep eenvoudig 'n nuwe toepassing gebaseer op hierdie sjabloon.
Nadat hierdie opdragte gewerk het, sal ons sien dat ons twee samestellings het:
En om terug te keer na die Oorsig-skerm, sal ons die bekendgestelde pod sien:
Klik op die skakel en ons sal na ons toepassing geneem word, wat die verstek React App-bladsy is:
Bylaag 1
Vir Angular liefhebbers het ons ook .
Die patroon hier is dieselfde, behalwe vir die OUTPUT_DIR veranderlike.
Bylaag 2
In hierdie artikel het ons NGINX as 'n webbediener gebruik, maar dit is redelik maklik om dit met Apache te vervang, verander net die sjabloon in die lêer op .
Gevolgtrekking
In die eerste deel van hierdie reeks het ons gewys hoe om moderne webtoepassings vinnig op die OpenShift-platform te ontplooi. Vandag het ons gekyk na wat 'n Web App-beeld doen en hoe dit gekombineer kan word met 'n suiwer webbediener soos NGINX deur gebruik te maak van gekettingde bouwerk om 'n meer produksiegereed-toepassingsbou te skep. In die volgende en laaste artikel in hierdie reeks sal ons wys hoe om 'n ontwikkelingsbediener vir jou toepassing op OpenShift te laat loop en sinchronisasie van plaaslike en afgeleë lêers te verseker.
Inhoud van hierdie reeks artikels
- Deel 1: ;
- Deel 2: Hoe om 'n nuwe S2I-beeld te gebruik met 'n bestaande HTTP-bedienerbeeld, soos NGINX, met geassosieerde OpenShift-samestellings vir produksie-ontplooiing;
- Deel 3: hoe om 'n ontwikkelingsbediener vir jou toepassing op die OpenShift-platform te laat loop en dit met die plaaslike lêerstelsel te sinchroniseer.
Bykomende hulpbronne
- Gratis e-boek .
- Inligting oor .
Bron: will.com