Sziasztok! Ez a második bejegyzés sorozatunkban, amelyben bemutatjuk, hogyan telepítsünk modern webes alkalmazásokat a Red Hat OpenShift rendszeren.
Az előző bejegyzésben kicsit érintettük az új S2I (source-to-image) builder image képességeit, amely modern webes alkalmazások OpenShift platformon történő építésére és telepítésére készült. Ezután az alkalmazás gyors telepítésének témája érdekelt, ma pedig azt nézzük meg, hogyan lehet egy S2I-képet „tiszta” építőképként használni, és hogyan lehet kombinálni a kapcsolódó OpenShift-összeállításokkal.
Tiszta építőkép
Ahogy az XNUMX. részben említettük, a legtöbb modern webalkalmazásnak van egy úgynevezett build szakasza, amely jellemzően olyan műveleteket hajt végre, mint a kódtranszpiláció, több fájl összefűzése és kicsinyítés. A műveletek eredményeként kapott fájlok - ez a statikus HTML, JavaScript és CSS - a kimeneti mappában tárolódnak. A mappa helye általában attól függ, hogy milyen összeállítási eszközöket használunk, és a React esetében ez lesz a ./build mappa (erre az alábbiakban részletesebben visszatérünk).
Forrás-kép (S2I)
Ebben a bejegyzésben nem érintjük a „mi az S2I és hogyan kell használni” témát (erről bővebben olvashat ), de fontos tisztában lenni a folyamat két lépésével, hogy megértsük, mire képes a Web App Builder kép.
Összeszerelési szakasz
Az összeállítási fázis természetében nagyon hasonló ahhoz, ami akkor történik, amikor a Docker buildet futtatja, és egy új Docker lemezkép készül. Ennek megfelelően ez a szakasz az OpenShift platformon történő build indításakor következik be.
Web App Builder lemezkép esetén ő felelős az alkalmazás függőségei telepítéséért és a build futtatásáért. . Alapértelmezés szerint az építőkészlet az npm run build konstrukciót használja, de ez felülbírálható az NPM_BUILD környezeti változóval.
Ahogy korábban említettük, a kész, már felépített alkalmazás helye attól függ, hogy milyen eszközöket használ. Például a React esetében ez a ./build mappa, az Angular alkalmazásoknál pedig a projekt_neve/dist mappa. És ahogy az előző bejegyzésben már látható volt, az alapértelmezés szerint buildre beállított kimeneti könyvtár helye felülírható az OUTPUT_DIR környezeti változón keresztül. Nos, mivel a kimeneti mappa helye keretrendszerenként eltérő, egyszerűen másolja a generált kimenetet a kép szabványos mappájába, nevezetesen az /opt/apt-root/output. Ez fontos a cikk további részeinek megértéséhez, de most nézzük gyorsan a következő szakaszt - a futtatási fázist.
futási fázis
Ez a szakasz akkor következik be, amikor az összeállítási szakaszban létrehozott új lemezképen a dokkolófuttatás hívása történik. Ugyanez történik az OpenShift platformon történő telepítéskor. Alapértelmezett felhasznál a fenti szabványos kimeneti könyvtárban található statikus tartalom kiszolgálására.
Ez a módszer jó az alkalmazások gyors üzembe helyezésére, de általában nem ajánlott statikus tartalmat ilyen módon kiszolgálni. Nos, mivel a valóságban csak statikus tartalmat szolgálunk ki, nem kell a Node.js-t telepíteni a képünkbe – elegendő egy webszerver.
Más szóval, összeszereléskor egy dologra van szükségünk, végrehajtáskor másra. Ebben a helyzetben jól jönnek a láncolt buildek.
Láncos építmények
Erről írnak az OpenShift dokumentációjában:
„Két összeállítás összekapcsolható, az egyik egy lefordított entitást generál, a másik pedig az entitást egy külön képen tárolja, amelyet az entitás futtatásához használnak.”
Más szavakkal, használhatjuk a Web App Builder lemezképet a build futtatásához, majd a webszerver lemezképet, ugyanazt az NGINX-et használhatjuk a tartalom kiszolgálására.
Így a Web App Builder lemezképet „tiszta” építőként használhatjuk, és ugyanakkor rendelkezhetünk egy kis futásidejű képpel.
Most nézzük meg ezt egy konkrét példával.
Edzésre használjuk , amelyet a create-react-app parancssori eszközzel hoztak létre.
Ez segít nekünk mindent összerakni .
Nézzük meg ezt a fájlt részletesebben, és kezdjük a paraméterekkel.
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
Itt minden elég világos, de érdemes odafigyelni az OUTPUT_DIR paraméterre. Példánkban a React alkalmazásnál nincs ok az aggodalomra, mivel a React az alapértelmezett értéket használja kimeneti mappaként, de Angular vagy valami más esetén ezt a paramétert szükség szerint módosítani kell.
Most pedig vessünk egy pillantást az ImageStreams szakaszra.
- 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'
Tekintse meg a harmadik és negyedik képet. Mindkettőt Docker-képként határozták meg, és jól láthatja, honnan származnak.
A harmadik kép a web-app-builder, és a 8.x címkével ellátott nodeshift/ubi2-s10i-web-appból származik. .
A negyedik egy NGINX-kép (1.12-es verzió), a legfrissebb címkével .
Most pedig nézzük az első két képet. Mindkettő üres az elején, és csak az építési fázisban jön létre. Az első kép, a react-web-app-builder, egy összeállítási lépés eredménye lesz, amely egyesíti a web-app-builder-runtime képet és a forráskódunkat. Ezért a kép nevéhez hozzáadtuk a „-builder”-t.
A második kép – a react-web-app-runtime – az nginx-image-runtime és a react-web-app-builder képfájl egyes fájljainak az eredménye lesz. Ezt a képet a telepítés során is használni fogják, és csak a webszervert, valamint az alkalmazásunk statikus HTML-jét, JavaScriptjét és CSS-jét tartalmazza.
Zavaros? Most vessünk egy pillantást az összeállítási konfigurációkra, és egy kicsit világosabb lesz.
Sablonunknak két összeállítási konfigurációja van. Íme az első, és meglehetősen szabványos:
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
Amint látható, az 1-es címkével ellátott sor azt mondja, hogy ennek az összeállításnak az eredménye ugyanabba a react-web-app-builder képbe kerül, amelyet egy kicsit korábban láttunk az ImageStreams részben.
A 2-es sor jelzi, hogy honnan szerezheti be a kódot. Esetünkben ez egy git repository, és a helyet, a ref és a kontextus mappát a fent már látott paraméterek határozzák meg.
A 3-as sor az, amit már láttunk a paraméterek részben. Hozzáadja az OUTPUT_DIR környezeti változót, amely példánkban a build.
A 4-es sor azt mondja, hogy a web-app-builder-runtime képet használjuk, amit már láttunk az ImageStream részben.
Az 5-ös sor azt mondja, hogy növekményes felépítést szeretnénk használni, ha az S2I lemezkép támogatja, és a Web App Builder lemezkép támogatja. Az első indításkor, miután az összeállítási szakasz befejeződött, a kép menti a node_modules mappát egy archív fájlba. Ezután a következő futtatások során a kép egyszerűen kicsomagolja ezt a mappát, hogy csökkentse a felépítési időt.
És végül, a 6-os sor csak néhány trigger, amellyel a build automatikusan, manuális beavatkozás nélkül fut, ha valami megváltozik.
Összességében ez egy meglehetősen szabványos összeállítási konfiguráció.
Most pedig vessünk egy pillantást a második összeállítási konfigurációra. Nagyon hasonlít az elsőhöz, de van egy lényeges különbség.
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
Tehát a második összeállítási konfiguráció react-web-app-runtime, és meglehetősen szabványosnak indul.
Az 1-es sor nem újdonság – egyszerűen azt mondja, hogy az összeállítás eredménye a react-web-app-runtime képfájlba kerül.
A 2-es sor az előző konfigurációhoz hasonlóan azt jelzi, hogy honnan szerezheti be a forráskódot. De vegyük észre, hogy itt azt mondjuk, hogy a képről van szó. Sőt, az imént létrehozott képből - a react-web-app-builderből (a 3-as sorban jelölve). A használni kívánt fájlok a képen belül vannak és ott a helyük a 4-es sorban van beállítva, esetünkben ez /opt/app-root/output/. Ha emlékszel, itt tárolódnak az alkalmazásunk elkészítésének eredményei alapján generált fájlok.
Az 5-ös címkével ellátott kifejezésben megadott célmappa egyszerűen az aktuális könyvtár (ez minden, ne feledje, valami OpenShift nevű varázslatos dologban fut, és nem a helyi számítógépen).
A stratégia szakasz – 6-os sor – szintén hasonló az első build konfigurációhoz. Csak ezúttal az nginx-image-runtime-ot fogjuk használni, amit már láttunk az ImageStream részben.
Végül a 7-es sor a triggerek egy része, amely minden alkalommal aktiválja ezt a buildet, amikor a react-web-app-builder kép megváltozik.
Egyébként ez a sablon meglehetősen szabványos telepítési konfigurációt tartalmaz, valamint a szolgáltatásokkal és útvonalakkal kapcsolatos dolgokat, de ezt nem részletezzük túlságosan. Kérjük, vegye figyelembe, hogy a telepített kép a react-web-app-runtime lemezkép.
Alkalmazások telepítése
Tehát most, hogy megnéztük a sablont, nézzük meg, hogyan használhatjuk egy alkalmazás üzembe helyezéséhez.
A sablonunk telepítéséhez használhatjuk az oc nevű OpenShift klienseszközt:
$ 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
A fenti képernyőképen az első parancs a sablon./openshiftio/application.yaml szándékos tervezési módja.
A második parancs egyszerűen létrehoz egy új alkalmazást a sablon alapján.
Miután ezek a parancsok működnek, látni fogjuk, hogy két szerelvényünk van:
És visszatérve az Áttekintés képernyőre, látni fogjuk az elindított pod:
Kattintson a linkre, és az alkalmazásunkra jutunk, amely az alapértelmezett React App oldal:
Kiegészítés 1
Az Angular szerelmeseinek is kínálunk .
A minta itt ugyanaz, kivéve az OUTPUT_DIR változót.
Kiegészítés 2
Ebben a cikkben az NGINX-et használtuk webszerverként, de meglehetősen könnyű lecserélni Apache-ra, csak módosítsa a sablont a fájlban on .
Következtetés
A sorozat első részében megmutattuk, hogyan lehet gyorsan telepíteni modern webes alkalmazásokat az OpenShift platformon. Ma megvizsgáltuk, hogy mit csinál egy Web App kép, és hogyan kombinálható egy tiszta webszerverrel, például az NGINX-szel láncolt buildek használatával, hogy termelésre készebb alkalmazás-felépítést hozzon létre. A sorozat következő és egyben utolsó cikkében bemutatjuk, hogyan futtathat fejlesztőkiszolgálót az alkalmazásához OpenShift-en, és hogyan biztosíthatja a helyi és távoli fájlok szinkronizálását.
A cikksorozat tartalma
- 1 rész: ;
- 2. rész: Új S2I lemezkép használata egy meglévő HTTP szerver lemezképpel, például NGINX-szel, a kapcsolódó OpenShift-szerelvények használatával az éles telepítéshez;
- 3. rész: Hogyan futtasson egy fejlesztőkiszolgálót az alkalmazásához az OpenShift platformon, és szinkronizálja azt a helyi fájlrendszerrel.
További források
- Ingyenes e-könyv .
- Információk a .
Forrás: will.com