Kaixo guztioi! Red Hat OpenShift-en web aplikazio modernoak nola zabaldu erakusten duen gure serieko bigarren argitalpena da.
Aurreko mezuan, apur bat ukitu genituen S2I (iturburutik irudira) eraikitzaile-irudi berriaren gaitasunak, OpenShift plataforman web aplikazio modernoak eraikitzeko eta zabaltzeko diseinatuta dagoena. Orduan aplikazio bat azkar hedatzearen gaia interesatzen zitzaigun, eta gaur S2I irudi bat eraikitzaile-irudi "puru" gisa nola erabili eta erlazionatutako OpenShift muntaketarekin konbinatu aztertuko dugu.
Garbitu eraikitzaileen irudia
XNUMX. zatian aipatu dugun bezala, web-aplikazio moderno gehienek eraikitze-fase bat dute, normalean kode-transpilazioa, hainbat fitxategi kateatzea eta minifikazioa bezalako eragiketak egiten dituena. Eragiketa horien ondorioz lortutako fitxategiak -eta hau HTML, JavaScript eta CSS estatikoa da- irteerako karpetan gordetzen dira. Karpeta honen kokapena, normalean, zer eraikitze-tresnaren araberakoa da, eta React-erako hau ./build karpeta izango da (behean xehetasun gehiagorekin itzuliko gara).
Iturburutik irudira (S2I)
Post honetan ez dugu "zer da S2I eta nola erabili" gaia ukitzen (horri buruz gehiago irakur dezakezu ), baina garrantzitsua da prozesu honetako bi urratsak argi izatea Web App Builder irudi batek zer egiten duen ulertzeko.
Muntaketa fasea
Muntatze fasea oso antzekoa da docker build exekutatzen duzunean eta Docker irudi berri batekin amaitzen duzunean gertatzen dena. Horren arabera, fase hau OpenShift plataforman eraikitzen hasten denean gertatzen da.
Web App Builder irudi baten kasuan, zure aplikazioaren menpekotasunak instalatzeaz eta eraikitzeaz arduratzen da. . Lehenespenez, eraikitzailearen irudiak npm run build eraikuntza erabiltzen du, baina hau NPM_BUILD ingurune-aldagaiaren bidez gainidatzi daiteke.
Lehen esan dugun bezala, amaitutako eta dagoeneko eraikitako aplikazioaren kokapena erabiltzen dituzun tresnen araberakoa da. Adibidez, React-en kasuan hau ./build karpeta izango da, eta Angular aplikazioetarako project_name/dist karpeta izango da. Eta, aurreko argitalpenean erakutsi bezala, irteerako direktorioaren kokapena, lehenespenez eraikitzeko ezarrita dagoena, OUTPUT_DIR ingurune-aldagaiaren bidez gainidatzi daiteke. Tira, irteera karpetaren kokapena esparru batetik bestera desberdina denez, sortutako irteera irudiko karpeta estandarrera kopiatu besterik ez duzu, hots, /opt/apt-root/output. Hau garrantzitsua da artikulu honen gainerako ulertzeko, baina oraingoz ikus diezaiogun azkar hurrengo faseari: exekuzio fasea.
korrika fasea
Etapa hau muntaketa fasean sortutako irudi berrian docker exekutatzeko deia egiten denean gertatzen da. Gauza bera gertatzen da OpenShift plataforman zabaltzean. Lehenetsia erabilerak goiko irteerako direktorio estandarrean kokatutako eduki estatikoa hornitzeko.
Metodo hau ona da aplikazioak azkar zabaltzeko, baina, oro har, ez da gomendagarria eduki estatikoa modu honetan hornitzea. Beno, errealitatean eduki estatikoa soilik zerbitzatzen dugunez, ez dugu Node.js instalatu behar gure irudiaren barruan - web zerbitzari bat nahikoa izango da.
Hau da, muntatzean gauza bat behar dugu, exekutatzen denean beste bat. Egoera honetan, kateatutako eraikuntzak ondo etortzen dira.
Eraikuntza kateatuak
Honetaz idazten dute OpenShift dokumentazioan:
"Bi asanblada elkarrekin lotu daitezke, batak konpilatutako entitate bat sortuz eta bestea entitate hori entitate hori exekutatzeko erabiltzen den irudi bereizi batean ostatatuta".
Beste era batera esanda, Web App Builder irudia erabil dezakegu gure eraikuntza exekutatzeko, eta gero web zerbitzariaren irudia, NGINX bera, gure edukia zerbitzatzeko.
Horrela, Web App Builder irudia eraikitzaile "puru" gisa erabil dezakegu eta, aldi berean, exekuzio denborako irudi txiki bat izan.
Ikus dezagun orain adibide zehatz batekin.
Prestakuntzarako erabiliko dugu , create-react-app komando lerroko tresna erabiliz sortua.
Dena bateratzen lagunduko digu .
Ikus dezagun xehetasun gehiago fitxategi hau, eta hasteko parametroen atalean.
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
Hemen dena nahiko argi dago, baina merezi du OUTPUT_DIR parametroari arreta jartzea. Gure adibideko React aplikaziorako, ez dago ezer kezkatu, React-ek balio lehenetsia erabiltzen baitu irteerako karpeta gisa, baina Angular-en edo beste zerbaiten kasuan, parametro hau aldatu beharko da beharrezkoa den moduan.
Ikus dezagun orain ImageStreams atalean.
- 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'
Begiratu hirugarren eta laugarren irudiei. Biak Docker irudi gisa definitzen dira, eta argi ikus dezakezu nondik datozen.
Hirugarren irudia web-app-builder da eta 8.x etiketatutako nodeshift/ubi2-s10i-web-app-etik dator. .
Laugarrena NGINX irudi bat da (1.12 bertsioa) azken etiketa aktibatuta duena .
Orain ikus ditzagun lehen bi irudiak. Hasieran hutsik daude biak eta eraikitze fasean soilik sortzen dira. Lehenengo irudia, react-web-app-builder, web-app-builder-runtime irudia eta gure iturburu-kodea konbinatuko dituen muntaketa-urrats baten emaitza izango da. Horregatik, irudi honen izenari β-builderβ gehitu diogu.
Bigarren irudia - react-web-app-runtime - nginx-image-runtime eta react-web-app-builder irudiko fitxategi batzuk konbinatzearen emaitza izango da. Irudi hau hedapenean ere erabiliko da eta gure aplikazioaren web zerbitzaria eta HTML estatikoa, JavaScript, CSS bakarrik edukiko ditu.
Nahasi? Orain ikus ditzagun eraikuntza-konfigurazioei eta pixka bat argiago geratuko da.
Gure txantiloiak bi konfigurazio ditu. Hona hemen lehenengoa, eta nahiko estandarra da:
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
Ikus dezakezunez, 1 etiketa duen lerroak dio eraikitze honen emaitza ImageStreams atalean apur bat lehenago ikusi dugun react-web-app-builder irudi berean jarriko dela.
2 etiketatutako lerroak kodea nondik atera behar duzun esaten dizu. Gure kasuan, hau git biltegi bat da, eta kokapena, erreferentzia eta testuinguru karpeta goian ikusi ditugun parametroek zehazten dute.
3 etiketatutako lerroa parametroen atalean lehendik ikusi duguna da. OUTPUT_DIR ingurune-aldagaia gehitzen du, gure adibidean eraikitzea dena.
4 etiketadun lerroak web-app-builder-runtime irudia erabiltzea dio, jadanik ImageStream atalean ikusi duguna.
5 etiketadun lerroak dio eraikuntza inkremental bat erabili nahi dugula S2I irudiak onartzen badu, eta Web App Builder irudiak bai. Lehenengo abiaraztean, muntaketa fasea amaitu ondoren, irudiak node_modules karpeta artxibo fitxategi batean gordeko du. Ondoren, hurrengo exekuzioetan, irudiak karpeta hau deskonprimituko du eraikitze-denbora murrizteko.
Eta azkenik, 6 etiketatutako lerroa abiarazle batzuk besterik ez dira eraikuntza automatikoki exekutatzeko, eskuz esku hartu gabe, zerbait aldatzen denean.
Orokorrean, konfigurazio konfigurazio nahiko estandarra da.
Orain, ikus dezagun bigarren konfigurazio konfigurazioari. Lehenaren oso antzekoa da, baina bada alde garrantzitsu bat.
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
Beraz, bigarren eraikuntza konfigurazioa react-web-app-runtime da, eta nahiko estandarra hasten da.
1 etiketatutako lerroa ez da berria; besterik gabe, eraikuntzaren emaitza react-web-app-runtime irudian jartzen dela esaten du.
2 etiketatutako lerroak, aurreko konfigurazioan bezala, iturburu kodea nondik atera behar den adierazten du. Baina konturatu hemen iruditik hartua dela esaten ari garela. Gainera, sortu berri dugun iruditik - react-web-app-builder-etik (3 etiketadun lerroan adierazita). Erabili nahi ditugun fitxategiak irudiaren barruan daude eta bertan 4 etiketadun lerroan dago kokatuta, gure kasuan /opt/app-root/output/ da. Gogoratzen baduzu, hemen gordetzen dira gure aplikazioa eraikitzearen emaitzetan oinarrituta sortutako fitxategiak.
5. etiketa duen terminoan zehaztutako helmuga karpeta uneko direktorioa besterik ez da (hau guztia da, gogoratu, OpenShift izeneko gauza magiko baten barruan exekutatzen da, eta ez zure ordenagailu lokalean).
Estrategia-atala - 6 etiketadun lerroa - lehen konfigurazio-konfigurazioaren antzekoa da. Oraingoan bakarrik nginx-image-runtime erabiliko dugu, jadanik ImageStream atalean ikusi genuena.
Azkenik, 7 etiketatutako lerroa erreakzio-web-app-builder irudia aldatzen den bakoitzean eraikitze hau aktibatuko duen abiarazleen atala da.
Bestela, txantiloi honek inplementazio-konfigurazio nahiko estandarra dauka, baita zerbitzu eta ibilbideekin zerikusia duten gauzak ere, baina ez dugu xehetasun gehiegitan sartuko. Kontuan izan zabalduko den irudia react-web-app-runtime irudia dela.
Aplikazioaren hedapena
Beraz, txantiloia aztertu dugunez, ikus dezagun nola erabili aplikazio bat zabaltzeko.
Oc izeneko OpenShift bezero tresna erabil dezakegu gure txantiloia zabaltzeko:
$ 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
Goiko pantaila-argazkiko lehen komandoa txantiloi bat aurkitzeko nahita egindako ingeniaritza modu bat da./openshiftio/application.yaml.
Bigarren komandoak txantiloi honetan oinarritutako aplikazio berri bat sortzen du.
Komando hauek funtzionatu ondoren, bi asanblada ditugula ikusiko dugu:
Eta Ikuspegiaren pantailara itzuliz, abiarazitako poda ikusiko dugu:
Egin klik estekan eta gure aplikaziora eramango gaituzte, hau da, React aplikazioaren orri lehenetsia:
1ko gehigarria
Angular maitaleentzat ere badugu .
Hemen eredua berdina da, OUTPUT_DIR aldagaia izan ezik.
2ko gehigarria
Artikulu honetan NGINX web zerbitzari gisa erabili dugu, baina nahiko erraza da Apache-rekin ordezkatzea, aldatu fitxategian txantiloia. on .
Ondorioa
Serie honen lehen zatian, OpenShift plataforman web aplikazio modernoak azkar nola zabaldu erakutsi genuen. Gaur Web App irudi batek zer egiten duen eta NGINX bezalako web zerbitzari huts batekin nola konbinatu daitekeen aztertu dugu kateatutako eraikuntzak erabiliz produkziorako prest dagoen aplikazioen eraikuntza sortzeko. Serie honetako hurrengo eta azken artikuluan, zure aplikaziorako garapen zerbitzari bat nola exekutatu OpenShift-en eta tokiko eta urruneko fitxategien sinkronizazioa nola bermatu erakutsiko dugu.
Artikulu sorta honen edukia
- Taldea 1: ;
- 2. zatia: Nola erabili S2I irudi berri bat lehendik dagoen HTTP zerbitzariaren irudi batekin, NGINX adibidez, lotutako OpenShift muntaiak erabiliz produkzioa zabaltzeko;
- 3. zatia: nola exekutatu zure aplikaziorako garapen zerbitzari bat OpenShift plataforman eta nola sinkronizatu fitxategi sistema lokalarekin.
Baliabide osagarriak
- Doako liburu elektronikoa .
- buruzko informazioa .
Iturria: www.habr.com