Tere kõigile! See on meie seeria teine postitus, milles näitame, kuidas Red Hat OpenShiftis kaasaegseid veebirakendusi juurutada.
Eelmises postituses puudutasime veidi uue S2I (source-to-image) ehitaja pildi võimalusi, mis on mõeldud OpenShift platvormil moodsate veebirakenduste ehitamiseks ja juurutamiseks. Seejärel huvitas meid rakenduse kiire juurutamise teema ja täna vaatame, kuidas kasutada S2I-pilti "puhta" ehitaja kujutisena ja kombineerida seda seotud OpenShift-koostidega.
Puhas ehitaja pilt
Nagu XNUMX. osas mainisime, on enamikul kaasaegsetest veebirakendustest nn ehitusetapp, mis tavaliselt teostab selliseid toiminguid nagu koodi transpilatsioon, mitme faili ühendamine ja minimeerimine. Nende toimingute tulemusena saadud failid - ja see on staatiline HTML, JavaScript ja CSS - salvestatakse väljundkausta. Selle kausta asukoht sõltub tavaliselt kasutatavatest ehitustööriistadest ja Reacti jaoks on see kaust ./build (selle juurde tuleme allpool üksikasjalikumalt tagasi).
Allikast pildiks (S2I)
Selles postituses me ei puuduta teemat "mis on S2I ja kuidas seda kasutada" (selle kohta saate rohkem lugeda ), kuid selle protsessi kaks etappi on oluline selgeks teha, et mõista, mida Web App Builderi kujutis teeb.
Montaažifaas
Montaažifaas on olemuselt väga sarnane sellega, mis juhtub siis, kui käivitate dockeri koostamise ja saate uue Dockeri pildi. Sellest tulenevalt toimub see etapp OpenShifti platvormil ehitamise käivitamisel.
Web App Builderi kujutise puhul vastutab see teie rakenduse sõltuvuste installimise ja järgu käitamise eest. . Vaikimisi kasutab koostaja pilt npm run buildi konstruktsiooni, kuid selle saab keskkonnamuutuja NPM_BUILD kaudu alistada.
Nagu varem ütlesime, sõltub valmis, juba ehitatud rakenduse asukoht sellest, milliseid tööriistu te kasutate. Näiteks Reacti puhul on selleks kaust ./build ja Angular rakenduste puhul projekti_nimi/dist kaust. Ja nagu juba eelmises postituses näidatud, saab väljundkataloogi asukohta, mis on vaikimisi ehitama seatud, keskkonnamuutuja OUTPUT_DIR kaudu alistada. Noh, kuna väljundkausta asukoht on raamistiku lõikes erinev, kopeerige loodud väljund lihtsalt pildil olevasse standardkausta, nimelt /opt/apt-root/output. See on oluline selle artikli ülejäänud osa mõistmiseks, kuid praegu vaatame kiiresti järgmist etappi – käitamisfaasi.
jooksufaas
See etapp toimub siis, kui koostamisetapis loodud uuele kujutisele tehakse kutse dokkeri käivitamisele. Sama juhtub ka OpenShifti platvormil juurutamisel. Vaikimisi kasutab ülaltoodud standardses väljundkataloogis asuva staatilise sisu teenindamiseks.
See meetod on hea rakenduste kiireks juurutamiseks, kuid üldiselt ei soovitata sel viisil staatilist sisu esitada. Kuna tegelikkuses pakume ainult staatilist sisu, ei pea me Node.js-i oma pildi sisse installima – piisab veebiserverist.
Teisisõnu, kokkupanemisel vajame ühte asja, teostamisel teist. Sellises olukorras tulevad kasuks aheldatud konstruktsioonid.
Aheldatud konstruktsioonid
Sellest nad kirjutavad OpenShifti dokumentatsioonis:
"Kaks komplekti saab omavahel linkida, millest üks genereerib kompileeritud olemi ja teine hostib seda olemit eraldi pildil, mida kasutatakse selle olemi käitamiseks."
Teisisõnu saame oma järgu käitamiseks kasutada Web App Builderi pilti ja seejärel kasutada oma sisu edastamiseks veebiserveri pilti, sama NGINX-i.
Seega saame Web App Builderi pilti kasutada "puhta" koostajana ja samal ajal omada väikest käitusaegset pilti.
Vaatame nüüd seda konkreetse näitega.
Treeninguteks kasutame , mis on loodud käsureatööriista create-react-app abil.
See aitab meil kõik kokku panna .
Vaatame seda faili üksikasjalikumalt ja alustame parameetrite jaotisega.
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
Siin on kõik üsna selge, kuid tasub pöörata tähelepanu parameetrile OUTPUT_DIR. Meie näites oleva rakenduse React puhul pole põhjust muretsemiseks, kuna React kasutab väljundkaustana vaikeväärtust, kuid Angulari või millegi muu puhul tuleb seda parameetrit vastavalt vajadusele muuta.
Nüüd vaatame jaotist 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'
Vaadake kolmandat ja neljandat pilti. Mõlemad on määratletud kui Dockeri kujutised ja näete selgelt, kust need pärinevad.
Kolmas pilt on web-app-builder ja see pärineb rakendusest nodeshift/ubi8-s2i-web-app, mille sildiga on 10.x .
Neljas on NGINX-pilt (versioon 1.12), millel on viimane silt sisse lülitatud .
Vaatame nüüd kahte esimest pilti. Mõlemad on alguses tühjad ja luuakse alles ehitamise etapis. Esimene pilt, react-web-app-builder, on koostamisetapi tulemus, mis ühendab veebirakenduse koostaja käitusaegse pildi ja meie lähtekoodi. Seetõttu lisasime selle pildi nimele “-builder”.
Teine pilt - react-web-app-runtime - on nginx-image-runtime ja mõnede react-web-app-builderi pildi failide kombineerimise tulemus. Seda pilti kasutatakse ka juurutamise ajal ja see sisaldab ainult meie rakenduse veebiserverit ja staatilist HTML-i, JavaScripti ja CSS-i.
Segaduses? Vaatame nüüd ehituse konfiguratsioone ja see muutub veidi selgemaks.
Meie mallil on kaks ehituskonfiguratsiooni. Siin on esimene ja see on üsna tavaline:
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
Nagu näete, ütleb 1. sildiga rida, et selle järgu tulemus paigutatakse samasse react-web-app-builderi kujutisse, mida nägime veidi varem jaotises ImageStreams.
Rida märgistusega 2 näitab, kust koodi hankida. Meie puhul on see git-hoidla ning asukoha, viite ja konteksti kausta määravad parameetrid, mida me juba eespool nägime.
Rida märgistusega 3 on see, mida me juba parameetrite jaotises nägime. See lisab keskkonnamuutuja OUTPUT_DIR, mis meie näites on ehitamine.
Rida märgistusega 4 ütleb, et tuleb kasutada veebirakenduse koostaja käitusaegset pilti, mida nägime juba jaotises ImageStream.
Rida sildiga 5 ütleb, et tahame kasutada järkjärgulist ehitamist, kui S2I-pilt seda toetab ja Web App Builderi pilt seda toetab. Esmakordsel käivitamisel, pärast montaažietapi lõpetamist, salvestab pilt kausta node_modules arhiivifaili. Seejärel pakib pilt järgmistel käitamistel selle kausta lihtsalt lahti, et lühendada koostamisaega.
Ja lõpuks, rida sildiga 6 on vaid mõned päästikud, mis panevad ehitamise automaatselt käima ilma käsitsi sekkumiseta, kui midagi muutub.
Üldiselt on see üsna tavaline ehituskonfiguratsioon.
Vaatame nüüd teist ehituse konfiguratsiooni. See on väga sarnane esimesele, kuid sellel on üks oluline erinevus.
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
Nii et teise järgu konfiguratsioon on react-web-app-runtime ja see algab üsna standardselt.
Rida sildiga 1 pole midagi uut – see lihtsalt ütleb, et ehitustulemus lisatakse react-web-app-runtime pildile.
Rida märgistusega 2, nagu ka eelmises konfiguratsioonis, näitab, kust lähtekoodi hankida. Kuid pange tähele, et siin me ütleme, et see on võetud pildist. Veelgi enam, äsja loodud pildi põhjal – react-web-app-builderist (tähistatud reale 3). Failid, mida soovime kasutada, on pildi sees ja nende asukoht on seal seatud reale sildiga 4, meie puhul on selleks /opt/app-root/output/. Kui mäletate, siis siin salvestatakse meie rakenduse koostamise tulemuste põhjal loodud failid.
Märgisega 5 määratletud sihtkaust on lihtsalt praegune kataloog (pidage meeles, et see on kõik, mis töötab mõnes maagilises asjas nimega OpenShift, mitte teie kohalikus arvutis).
Strateegia osa – rida sildiga 6 – on samuti sarnane esimese järgu konfiguratsiooniga. Ainult seekord kasutame nginx-image-runtime'i, mida nägime juba jaotises ImageStream.
Lõpuks on rida sildiga 7 päästikute jaotis, mis aktiveerib selle järgu iga kord, kui react-web-app-builderi kujutis muutub.
Muidu sisaldab see mall üsna standardset juurutamise konfiguratsiooni, aga ka asju, mis on seotud teenuste ja marsruutidega, kuid me ei lasku sellesse liiga üksikasjalikult. Pange tähele, et juurutav pilt on react-web-app-runtime pilt.
Rakenduse juurutamine
Nüüd, kui oleme malli vaadanud, vaatame, kuidas seda rakenduse juurutamiseks kasutada.
Malli juurutamiseks saame kasutada OpenShifti klienditööriista nimega oc:
$ 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
Esimene käsk ülaloleval ekraanipildil on tahtlikult konstrueeritud viis malli leidmiseks./openshiftio/application.yaml.
Teine käsk loob lihtsalt selle malli põhjal uue rakenduse.
Pärast nende käskude toimimist näeme, et meil on kaks komplekti:
Ja naastes ülevaateekraanile, näeme käivitatud pod:
Klõpsake lingil ja meid suunatakse meie rakendusse, mis on React Appi vaikeleht:
Täiendus 1
Nurga armastajatele on meil ka .
Siin on muster sama, välja arvatud muutuja OUTPUT_DIR.
Täiendus 2
Selles artiklis kasutasime veebiserverina NGINX-i, kuid selle asendamine Apache'iga on üsna lihtne, lihtsalt muutke failis malli edasi .
Järeldus
Selle seeria esimeses osas näitasime, kuidas OpenShifti platvormil moodsaid veebirakendusi kiiresti juurutada. Täna vaatasime, mida teeb veebirakenduse pilt ja kuidas saab seda kombineerida puhta veebiserveriga, nagu NGINX, kasutades aheldatud järge, et luua paremini tootmisvalmis rakenduse järg. Selle seeria järgmises ja viimases artiklis näitame, kuidas käivitada OpenShiftis oma rakenduse arendusserver ning tagada kohalike ja kaugfailide sünkroonimine.
Selle artiklisarja sisu
- 1i osa: ;
- 2. osa: kuidas kasutada uut S2I-pilti koos olemasoleva HTTP-serveri kujutisega (nt NGINX), kasutades tootmise juurutamiseks seotud OpenShift-kooste;
- 3. osa: kuidas käivitada oma rakenduse arendusserver OpenShift platvormil ja sünkroonida see kohaliku failisüsteemiga.
Lisaressursid
- Tasuta e-raamat .
- Teave kohta .
Allikas: www.habr.com