Pozdravljeni vsi skupaj! To je druga objava v naši seriji, v kateri prikazujemo, kako razmestiti sodobne spletne aplikacije na Red Hat OpenShift.
V prejšnjem prispevku smo se nekoliko dotaknili zmožnosti nove S2I (source-to-image) graditeljske slike, ki je namenjena gradnji in postavitvi sodobnih spletnih aplikacij na platformi OpenShift. Potem nas je zanimala tema o hitri postavitvi aplikacije, danes pa si bomo pogledali, kako sliko S2I uporabiti kot »čisto« sliko graditelja in jo kombinirati s sorodnimi sklopi OpenShift.
Čista slika graditelja
Kot smo omenili v XNUMX. delu, ima večina sodobnih spletnih aplikacij tako imenovano stopnjo gradnje, ki običajno izvaja operacije, kot so transpilacija kode, združevanje več datotek in pomanjševanje. Datoteke, pridobljene kot rezultat teh operacij - in to je statični HTML, JavaScript in CSS - so shranjene v izhodni mapi. Lokacija te mape je običajno odvisna od uporabljenih orodij za gradnjo, za React pa bo to mapa ./build (k temu se bomo podrobneje vrnili spodaj).
Od vira do slike (S2I)
V tem prispevku se ne dotikamo teme “kaj je S2I in kako ga uporabljati” (več o tem si lahko preberete ), vendar je pomembno, da ste jasni glede dveh korakov v tem procesu, da razumete, kaj naredi slika Web App Builder.
Montažna faza
Faza sestavljanja je po naravi zelo podobna tistemu, kar se zgodi, ko zaženete gradnjo dockerja in končate z novo sliko Dockerja. V skladu s tem se ta stopnja pojavi, ko začnete gradnjo na platformi OpenShift.
V primeru slike Web App Builder je ta odgovoren za namestitev odvisnosti vaše aplikacije in izvajanje gradnje. . Slika graditelja privzeto uporablja gradbeni konstrukt npm run, vendar je to mogoče preglasiti s spremenljivko okolja NPM_BUILD.
Kot smo že povedali, je lokacija končane, že izdelane aplikacije odvisna od orodij, ki jih uporabljate. Na primer, v primeru Reacta bo to mapa ./build, za aplikacije Angular pa mapa project_name/dist. In kot je bilo že prikazano v prejšnji objavi, lahko lokacijo izhodnega imenika, ki je privzeto nastavljen za gradnjo, preglasite s spremenljivko okolja OUTPUT_DIR. No, ker se lokacija izhodne mape razlikuje od ogrodja do ogrodja, preprosto kopirate ustvarjeni izhod v standardno mapo na sliki, in sicer /opt/apt-root/output. To je pomembno za razumevanje preostalega dela tega članka, a za zdaj si na hitro poglejmo naslednjo fazo – fazo teka.
faza teka
Ta stopnja se pojavi, ko se na novi sliki, ki je bila ustvarjena v fazi sestavljanja, izvede klic docker run. Enako se zgodi pri uvajanju na platformo OpenShift. Privzeto uporablja služiti statični vsebini, ki se nahaja v zgornjem standardnem izhodnem imeniku.
Ta metoda je dobra za hitro uvajanje aplikacij, vendar na splošno ni priporočljivo servirati statične vsebine na ta način. No, ker v resnici strežemo samo statično vsebino, ne potrebujemo Node.js nameščenega znotraj naše slike - zadostuje spletni strežnik.
Z drugimi besedami, pri sestavljanju potrebujemo eno, pri izvajanju pa drugo. V tej situaciji pridejo prav verižne gradnje.
Verižne gradnje
O tem pišejo v dokumentaciji OpenShift:
"Dva sklopa je mogoče povezati skupaj, pri čemer eden ustvari prevedeno entiteto, drugi pa gosti to entiteto v ločeni podobi, ki se uporablja za izvajanje te entitete."
Z drugimi besedami, lahko uporabimo sliko Web App Builder za zagon naše gradnje in nato uporabimo sliko spletnega strežnika, isti NGINX, za serviranje naše vsebine.
Tako lahko sliko Web App Builder uporabljamo kot »čisti« builder in imamo hkrati majhno izvajalno sliko.
Zdaj pa poglejmo to s konkretnim primerom.
Za trening bomo uporabili , ustvarjen z orodjem ukazne vrstice create-react-app.
Pomagal nam bo vse skupaj sestaviti .
Oglejmo si to datoteko podrobneje in začnimo z razdelkom parametrov.
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
Tukaj je vse precej jasno, vendar je vredno biti pozoren na parameter OUTPUT_DIR. Za aplikacijo React v našem primeru ni razloga za skrb, saj React uporablja privzeto vrednost kot izhodno mapo, toda v primeru Angular ali česa drugega bo treba ta parameter po potrebi spremeniti.
Zdaj pa si poglejmo razdelek 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'
Oglejte si tretjo in četrto sliko. Obe sta definirani kot Dockerjevi sliki in jasno lahko vidite, od kod prihajata.
Tretja slika je web-app-builder in prihaja iz nodeshift/ubi8-s2i-web-app z oznako 10.x na .
Četrta je slika NGINX (različica 1.12) z najnovejšo oznako .
Zdaj pa poglejmo prvi dve sliki. Oba sta na začetku prazna in se ustvarita samo med fazo gradnje. Prva slika, react-web-app-builder, bo rezultat koraka sestavljanja, ki bo združil sliko izvajalnega okolja web-app-builderja in našo izvorno kodo. Zato smo imenu te slike dodali »-builder«.
Druga slika - react-web-app-runtime - bo rezultat kombinacije izvajalnega okolja nginx-image-runtime in nekaterih datotek iz slike react-web-app-builder. Ta slika bo uporabljena tudi med uvajanjem in bo vsebovala le spletni strežnik in statični HTML, JavaScript, CSS naše aplikacije.
Zmedeni? Zdaj pa si oglejmo konfiguracije gradnje in postalo bo malo bolj jasno.
Naša predloga ima dve konfiguraciji gradnje. Tukaj je prvi in je precej standarden:
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
Kot lahko vidite, vrstica z oznako 1 pravi, da bo rezultat te gradnje postavljen v isto sliko graditelja spletnih aplikacij react-web-app, ki smo jo videli malo prej v razdelku ImageStreams.
Vrstica z oznako 2 vam pove, od kod lahko dobite kodo. V našem primeru je to repozitorij git, lokacija, ref in kontekstna mapa pa so določeni s parametri, ki smo jih že videli zgoraj.
Vrstica z oznako 3 je tisto, kar smo že videli v razdelku s parametri. Doda spremenljivko okolja OUTPUT_DIR, ki je v našem primeru build.
Vrstica, označena s 4, pravi uporabo izvajalne slike graditelja spletnih aplikacij, ki smo jo že videli v razdelku ImageStream.
Vrstica z oznako 5 pravi, da želimo uporabiti inkrementalno gradnjo, če jo podpira slika S2I, slika Web App Builder pa podpira. Ob prvem zagonu, po zaključku faze sestavljanja, bo slika shranila mapo node_modules v arhivsko datoteko. Nato bo slika pri naslednjih zagonih preprosto razpakirala to mapo, da skrajša čas gradnje.
In končno, vrstica, označena s 6, je le nekaj sprožilcev, da se gradnja samodejno izvaja brez ročnega posredovanja, ko se kaj spremeni.
Na splošno je to precej standardna konfiguracija gradnje.
Zdaj pa si oglejmo drugo konfiguracijo gradnje. Zelo je podoben prvemu, vendar obstaja ena pomembna razlika.
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
Torej je druga konfiguracija gradnje react-web-app-runtime in se začne precej standardno.
Vrstica z oznako 1 ni nič novega - preprosto pravi, da je rezultat gradnje vstavljen v sliko izvajalnega okolja spletne aplikacije react-web-app.
Vrstica z oznako 2, kot v prejšnji konfiguraciji, označuje, od kod dobiti izvorno kodo. Vendar upoštevajte, da tukaj pravimo, da je vzeto iz slike. Še več, iz slike, ki smo jo pravkar ustvarili - iz react-web-app-builderja (navedeno v vrstici z oznako 3). Datoteke, ki jih želimo uporabiti, so znotraj slike in njihova lokacija tam je nastavljena v vrstici z oznako 4, v našem primeru je to /opt/app-root/output/. Če se spomnite, so tukaj shranjene datoteke, ustvarjene na podlagi rezultatov gradnje naše aplikacije.
Ciljna mapa, določena v izrazu z oznako 5, je preprosto trenutni imenik (ne pozabite, da se vse to izvaja v neki čarobni stvari, imenovani OpenShift, in ne v vašem lokalnem računalniku).
Strateški razdelek – vrstica z oznako 6 – je prav tako podoben prvi konfiguraciji gradnje. Samo tokrat bomo uporabili nginx-image-runtime, ki smo ga že videli v razdelku ImageStream.
Končno je vrstica z oznako 7 del sprožilcev, ki bodo aktivirali to gradnjo vsakič, ko se spremeni slika graditelja spletnih aplikacij react-web-app.
Sicer ta predloga vsebuje precej standardno konfiguracijo uvajanja, pa tudi stvari, ki se nanašajo na storitve in poti, vendar se ne bomo spuščali v preveč podrobnosti. Upoštevajte, da je slika, ki bo uvedena, slika izvajalnega okolja spletne aplikacije react-web-app.
Namestitev aplikacije
Zdaj, ko smo si ogledali predlogo, si poglejmo, kako jo uporabiti za uvedbo aplikacije.
Za uvedbo naše predloge lahko uporabimo odjemalsko orodje OpenShift, imenovano 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
Prvi ukaz na zgornjem posnetku zaslona je namenoma inženirski način za iskanje predloge./openshiftio/application.yaml.
Drugi ukaz preprosto ustvari novo aplikacijo na podlagi te predloge.
Ko ti ukazi delujejo, bomo videli, da imamo dva sklopa:
In ko se vrnemo na zaslon Pregled, bomo videli zagnani pod:
Kliknite povezavo in preusmerjeni bomo v našo aplikacijo, ki je privzeta stran aplikacije React:
Dodatek 1
Za ljubitelje Angular imamo tudi .
Tu je vzorec enak, razen spremenljivke OUTPUT_DIR.
Dodatek 2
V tem članku smo uporabili NGINX kot spletni strežnik, vendar ga je precej enostavno zamenjati z Apacheom, samo spremenite predlogo v datoteki o .
Zaključek
V prvem delu te serije smo pokazali, kako hitro namestiti sodobne spletne aplikacije na platformi OpenShift. Danes smo pogledali, kaj naredi slika spletne aplikacije in kako jo je mogoče kombinirati s čistim spletnim strežnikom, kot je NGINX, z uporabo verižnih gradenj, da ustvarimo gradnjo aplikacije, ki je bolj pripravljena na proizvodnjo. V naslednjem in zadnjem članku v tej seriji bomo pokazali, kako zagnati razvojni strežnik za vašo aplikacijo na OpenShift in zagotoviti sinhronizacijo lokalnih in oddaljenih datotek.
Vsebina te serije člankov
- Del 1: ;
- 2. del: Kako uporabiti novo sliko S2I z obstoječo sliko strežnika HTTP, kot je NGINX, z uporabo povezanih sklopov OpenShift za produkcijsko uvajanje;
- 3. del: kako zagnati razvojni strežnik za svojo aplikacijo na platformi OpenShift in ga sinhronizirati z lokalnim datotečnim sistemom.
Dodatni viri
- Brezplačna e-knjiga .
- Informacije o .
Vir: www.habr.com