Përshëndetje! Ky është postimi i dytë në serinë tonë, ku tregojmë si të zhvilloni aplikacione moderne web në Red Hat OpenShift.
Në postimin e mëparshëm, ne përmëndëm në mënyrë të lehtë mundësitë e reja të builder-image S2I (source-to-image), i cili është i destinuar për ndërtimin dhe zhvillimin e aplikacioneve moderne web në platformën OpenShift. Atëherë na interesonte tema e zhvillimit të shpejtë të aplikacioneve, ndërsa sot do të shqyrtojmë si ta përdorim S2I-image si një 'builder' të pastër dhe ta kombinojmë me ndërlidhjet OpenShift.
Builder-i i pastër
Siç e pĂ«rmĂ«ndĂ«m nĂ« pjesĂ«n e parĂ«, shumica e aplikacioneve moderne web kanĂ« njĂ« fazĂ« ndĂ«rtimi, ku zakonisht kryhen operacione tĂ« tilla si transpiling i kodit, konkatencionimi i disa skedave dhe minimizimi. SkedarĂ«t e marrĂ« nga kĂ«to operacione â qĂ« pĂ«rfshijnĂ« HTML statik, JavaScript dhe CSS â vendosen nĂ« folderin output. Lokacioni i kĂ«tij folderi zakonisht varet nga mjetet e ndĂ«rtimit qĂ« pĂ«rdoren, dhe pĂ«r React do tĂ« jetĂ« folderi ./build (do tĂ« kthehemi nĂ« kĂ«tĂ« çështje mĂ« poshtĂ«).
Source-to-Image (S2I)
Në këtë postim ne nuk do të flasim fare për temën 'çfarë është S2I dhe si ta përdorim' (për më shumë mund të lexoni ), por është e rëndësishme që të kuptoni qartë dy fazat e këtij procesi, për të kuptuar se çfarë bën imazhi Web App Builder.
Faza e asamblesë (assemble phase)
Faza e asamblesë, në thelb, është shumë e ngjashme me atë që ndodh kur ju bëni docker build dhe si rezultat merrni një Docker-image të ri. Prandaj, kjo fazë ndodh kur nisni një ndërtim në platformën OpenShift.
Në rastin e imazhit Web App Builder, përgjegjësia për instalimin e varësive të aplikacionit tuaj dhe nisjen e ndërtimit i takon . Si parazgjedhje, builder-image përdor strukturën npm run build, por kjo mund të anulohet përmes variablit të mjedisit NPM_BUILD.
Siç e thamĂ« mĂ« parĂ«, vendndodhja e aplikacionit tĂ« gatshĂ«m, tashmĂ« tĂ« ndĂ«rtuar, varet nga cilat mjete pĂ«rdoren. PĂ«r shembull, nĂ« rastin e React, do tĂ« jetĂ« dosja /build, ndĂ«rsa pĂ«r aplikacionet Angular â dosja project_name/dist. Dhe, siç u tregua nĂ« postimin e kaluar, vendndodhja e katalogut tĂ« output-it, i cili nĂ« mĂ«nyrĂ« default Ă«shtĂ« caktuar si build, mund tĂ« ndryshohet pĂ«rmes variablit tĂ« mjedisit OUTPUT_DIR. Dhe pĂ«r shkak se vendndodhja e dosjes sĂ« output-it ndryshon nga njĂ« framework nĂ« njĂ« tjetĂ«r, thjesht e kopjoni output-in e gjeneruar nĂ« dosjen standarde nĂ« imazh, pra nĂ« /opt/apt-root/output. Kjo Ă«shtĂ« e rĂ«ndĂ«sishme pĂ«r tĂ« kuptuar pjesĂ«n tjetĂ«r tĂ« kĂ«tij artikulli, ndĂ«rkohĂ«, le tĂ« shikojmĂ« shpejt fazĂ«n tjetĂ«r â fazĂ«n e ekzekutimit (run phase).
Faza e ekzekutimit (run phase)
Kjo fazë ndodh kur bëhet thirrje docker run për një imazh të ri, të krijuar në fazën e ndërtimit. Ajo ndodh gjithashtu gjatë implementimit në platformën OpenShift. Në mënyrë default përdor për shërbimin e përmbajtjes statike që ndodhet në katalogun e output-it standard të përmendur më lart.
Ky metod Ă«shtĂ« i mirĂ« pĂ«r implementimin e shpejtĂ« tĂ« aplikacioneve, por nĂ« tĂ« vĂ«rtetĂ«, nuk rekomandohet tĂ« shĂ«rbehet pĂ«rmbajtje statike nĂ« kĂ«tĂ« mĂ«nyrĂ«. Duke qenĂ« se ne nĂ« tĂ« vĂ«rtetĂ« po shĂ«rbejmĂ« vetĂ«m pĂ«rmbajtje statike, Node.js i instaluar brenda imazhit tonĂ« nuk Ă«shtĂ« i nevojshĂ«m â njĂ« server web do tĂ« ishte mjaft.
Me fjalĂ« tĂ« tjera, gjatĂ« ndĂ«rtimit na nevojitet njĂ« gjĂ«, ndĂ«rsa gjatĂ« ekzekutimit â diçka tjetĂ«r. NĂ« njĂ« situatĂ« tĂ« tillĂ« do tĂ« dobishen ndĂ«rtimet e lidhura (chained builds).
Ndërtime të lidhura (chained builds)
Ja çfarë thonë për në dokumentacionin e OpenShift:
«Dy ndërtimet mund të lidhen me njëra-tjetrën, ku njëra gjeneron një entitet të përpiluar dhe tjetra vendos këtë entitet në një imazh të veçantë, i cili përdoret për të ekzekutuar këtë entitet».
Me fjalë të tjera, ne mund të përdorim imazhin Web App Builder për të ekzekutuar ndërtimin tonë, dhe pastaj të përdorim imazhin e serverit web, të njëjtin NGINX, për të shërbyer përmbajtjen tonë.
KĂ«shtu, ne mund tĂ« aplikojmĂ« imazhin Web App Builder si njĂ« âtĂ« pastĂ«râ builder dhe nĂ« tĂ« njĂ«jtĂ«n kohĂ« tĂ« kemi njĂ« imazh runtime tĂ« vogĂ«l.
Tani le të analizojmë këtë me një shembull konkret.
Për stërvitje do të përdorim , të krijuar me ndihmën e mjetit të komandës create-react-app.
Të gjitha së bashku do të na ndihmojë .
Le të analizojmë më në detaje këtë skedar dhe të fillojmë me seksionin e parametrave.
parametrat:
- emri: SOURCE_REPOSITORY_URL
përshkrimi: URL-ja burimore për aplikacionin
emri i shfaqjes: URL Burimor
e kërkuar: e vërtetë
- emri: SOURCE_REPOSITORY_REF
përshkrimi: Emri i degës për aplikacionin
emri i shfaqjes: Dega Burimore
vlera: master
e kërkuar: e vërtetë
- emri: SOURCE_REPOSITORY_DIR
përshkrimi: Lokacioni brenda repo-s burimore të aplikacionit
emri i shfaqjes: Dosja Burimore
vlera: .
e kërkuar: e vërtetë
- emri: OUTPUT_DIR
përshkrimi: Lokacioni i skedave statike të kompiluar nga ndërtuesi i aplikacioneve tuaja
emri i shfaqjes: Dosja e Daljes
vlera: ndërtim
e kërkuar: e gabuar
Këtu gjithçka është mjaft e qartë, por duhen kushtuar vëmendje parametrave OUTPUT_DIR. Për aplikacionin React nga shembulli ynë nuk ka çfarë të shqetësohemi, pasi React përdor si vlerë të daljes dosjen standarde, ndërsa në rastin e Angular ose ndonjë gjëje tjetër, ky parametër do të duhet të ndryshohet në mënyrë të duhur.
Tani le të shohim seksionin e ImageStream-ëve.
- apiVersion: v1
lloji: ImageStream
metadata:
emri: react-web-app-builder // 1
spec: {}
- apiVersion: v1
lloji: ImageStream
metadata:
emri: react-web-app-runtime // 2
spec: {}
- apiVersion: v1
lloji: ImageStream
metadata:
emri: web-app-builder-runtime // 3
spec:
etiketat:
- emri: latest
nga:
lloji: DockerImage
emri: nodeshift/ubi8-s2i-web-app:10.x
- apiVersion: v1
lloji: ImageStream
metadata:
emri: nginx-image-runtime // 4
spec:
etiketat:
- emri: latest
nga:
lloji: DockerImage
emri: 'centos/nginx-112-centos7:latest'
Shikoni imazhet e tretë dhe të katërt. Të dy janë të përcaktuar si imazhe Docker dhe është qartë se nga po vijnë.
Imazhi i tretĂ« â Ă«shtĂ« web-app-builder, dhe ai vjen nga nodeshift/ubi8-s2i-web-app me etiketĂ« 10.x nĂ« .
I katĂ«rti â Ă«shtĂ« imazhi NGINX (versioni 1.12) me etiketĂ« latest nĂ« .
Tani le tĂ« shohim dy imazhet e para. TĂ« dy janĂ« bosh nĂ« fillim dhe krijohen vetĂ«m gjatĂ« fazĂ«s sĂ« ndĂ«rtimit. Imazhi i parĂ« â react-web-app-builder â do tĂ« jetĂ« rezultati i fazĂ«s sĂ« assemblimit, e cila do tĂ« bashkojĂ« imazhin web-app-builder-runtime dhe kodin tonĂ« burimor. Kjo Ă«shtĂ« arsyeja pse e kemi pĂ«rfshirĂ« '-builder' nĂ« emrin e kĂ«tij imazhi.
Imazhi i dytĂ« â react-web-app-runtime â do tĂ« jetĂ« rezultat i bashkimit tĂ« nginx-image-runtime dhe disa skedave nga imazhi react-web-app-builder. Ky imazh gjithashtu do tĂ« pĂ«rdoret gjatĂ« implementimit dhe do tĂ« pĂ«rmbajĂ« vetĂ«m serverin web dhe HTML statik, JavaScript, CSS tĂ« aplikacionit tonĂ«.
E ngatërruar? Tani le të shohim konfigurimet e ndërtimit dhe do të bëhet pak më e qartë.
Në shabllonin tonë ka dy konfigurime të ndërtimit. Ja e para, dhe është mjaft standarde:
apiVersion: v1
kind: BuildConfig
metadata:
name: react-web-app-builder
spec:
output:
to:
kind: ImageStreamTag
name: react-web-app-builder:latest
source:
git:
uri: ${SOURCE_REPOSITORY_URL}
ref: ${SOURCE_REPOSITORY_REF}
contextDir: ${SOURCE_REPOSITORY_DIR}
type: Git
strategy:
sourceStrategy:
env:
- name: OUTPUT_DIR
value: ${OUTPUT_DIR}
from:
kind: ImageStreamTag
name: web-app-builder-runtime:latest
incremental: true
type: Source
triggers:
- github:
secret: ${GITHUB_WEBHOOK_SECRET}
type: GitHub
- type: ConfigChange
- imageChange: {}
type: ImageChange
Si e shohim, rreshti me etiketen 1 tregon se rezultati i kësaj ndërtese do të vendoset në atë imazh react-web-app-builder, të cilin e pamë më parë në seksionin e ImageStream-eve.
Rreshti me etiketen 2 tregon nga ku të merrni kodin. Në rastin tonë, kjo është një depo git, dhe vendndodhja, ref dhe dosja e kontekstit janë të përcaktuara nga parametrat që i pamë më lart.
Rreshti me etiketen 3 â e kemi parĂ« tashmĂ« nĂ« seksionin e parametrave. Ajo shton njĂ« variabĂ«l ambienti OUTPUT_DIR, qĂ« nĂ« shembullin tonĂ« Ă«shtĂ« e barabartĂ« me build.
Rreshti me etiketen 4 tregon të përdoret imazhi web-app-builder-runtime, që e kemi parë më parë në seksionin e ImageStream.
Rreshti me etiketen 5 tregon se ne duam të përdorim ndërtimin inkremental, nëse imazhi S2I e mbështet atë, dhe imazhi Web App Builder e mbështet. Në fillim, pas përfundimit të fazës së asamblesë, imazhi do të ruajë dosjen node_modules në një skedar zip. Pastaj, në startet pasuese, imazhi do të thjesht deshifrojë këtë dosje për të shkurtuar kohën e ndërtimit.
Dhe, pĂ«rfundimisht, rreshti me etiketen 6 â janĂ« thjesht disa triggera, qĂ« ndĂ«rtimi tĂ« fillojĂ« automatikisht, pa ndĂ«rhyrje manuale, kur ndonjĂ« gjĂ« ndryshon.
Në përgjithësi, kjo është një konfigurim ndërtimi mjaft standard.
Tani le të shohim konfigurimin e dytë të ndërtimit. Ai është shumë i ngjashëm me të parin, por ka një ndryshim të rëndësishëm.
apiVersion: v1
kind: BuildConfig
metadata:
name: react-web-app-runtime
spec:
output:
to:
kind: ImageStreamTag
name: react-web-app-runtime:latest
source:
type: Image
images:
- from:
kind: ImageStreamTag
name: react-web-app-builder:latest
paths:
- sourcePath: /opt/app-root/output/.
destinationDir: .
strategy:
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
Pra ndaj, konfigurimi i dytĂ« i ndĂ«rtimit â react-web-app-runtime, fillon mjaft standardisht.
NĂ« vargun me etiketĂ«n 1 nuk ka asgjĂ« tĂ« re â thjesht thotĂ« qĂ« rezultati i ndĂ«rtimit vendoset nĂ« imazhin react-web-app-runtime.
Vargu me etiketĂ«n 2, si nĂ« konfigurimin e mĂ«parshĂ«m, tregon nga ku do tĂ« merret kodi burimor. Por vini re se kĂ«tu po themi se merret nga imazhi. Pra, nga imazhi qĂ« sapo krijuam â nga react-web-app-builder (i cituar nĂ« vargun me etiketĂ«n 3). SkedarĂ«t qĂ« duam tĂ« pĂ«rdorim ndodhen brenda imazhit dhe vendndodhja e tyre atje Ă«shtĂ« caktuar nĂ« vargun me etiketĂ«n 4, nĂ« rastin tonĂ« Ă«shtĂ« /opt/app-root/output/. Po tĂ« kujtoni, pikĂ«risht aty vendosen skedarĂ«t e gjeneruar nga rezultatet e ndĂ«rtimit tĂ« aplikacionit tonĂ«.
Folderi i destinacionit, i caktuar nĂ« afatin me etiketĂ«n 5 â Ă«shtĂ« thjesht katalogu aktual (kjo Ă«shtĂ« gjithçka, kujtojmĂ«, qĂ« rrotullohet brenda njĂ« gjĂ«je magjike tĂ« quajtur OpenShift, dhe jo nĂ« kompjuterin tuaj lokal).
Sekcioni strategy â vargu me etiketĂ«n 6 â Ă«shtĂ« gjithashtu i ngjashĂ«m me konfigurimin e parĂ« tĂ« ndĂ«rtimit. VetĂ«m kĂ«tĂ« herĂ« do tĂ« pĂ«rdorim nginx-image-runtime, i cili Ă«shtĂ« parĂ« tashmĂ« nĂ« seksionin ImageStream.
NĂ« fund, vargu me etiketĂ«n 7 â Ă«shtĂ« seksioni i triggers, i cili aktivizon kĂ«tĂ« ndĂ«rtim çdo herĂ« kur ndryshon imazhi react-web-app-builder.
PĂ«rndryshe, ky shabllon pĂ«rmban njĂ« konfigurim mjaft standard tĂ« shpĂ«rndarjes, si dhe gjĂ«ra qĂ« lidhen me shĂ«rbimet dhe rrugĂ«t, por ne nuk do tĂ« thellohemi nĂ« kĂ«tĂ«. Vini re se imazhi qĂ« do tĂ« shpĂ«rndahet â Ă«shtĂ« imazhi react-web-app-runtime.
Zbatimi i aplikacionit
Pra, pasi kemi hedhur një vështrim në shabllon, le të shohim se si ta përdorim atë për të shpërndarë aplikacionin.
Mund të përdorim mjetin klient OpenShift të quajtur oc, për të shpërndarë shabllonin tonë:
$ 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
Komanda e parĂ« nĂ« skrinin e mĂ«sipĂ«rm â Ă«shtĂ« njĂ« mĂ«nyrĂ« e qĂ«llimshme inxhinierike pĂ«r tĂ« gjetur shabllonin ./openshiftio/application.yaml.
Komanda e dytë thjesht krijon një aplikacion të ri mbi bazën e këtij shablloni.
Pas përfundimit të këtyre komandave, do të shohim se kemi dy ndërtime:
Dhe duke u kthyer në ekranin Overview, do të shohim pod-in që është nisur:
NjĂ« klikim nĂ« lidhje â dhe ne do tĂ« kalojmĂ« nĂ« aplikacionin tonĂ«, i cili pĂ«rbĂ«n njĂ« faqe aplikacioni React App sipas parazgjedhjes:
Shtesa 1
PĂ«r adhuruesit e Angular kemi gjithashtu .
Shablloni këtu është i njëjtë, përveç variablës OUTPUT_DIR.
Shtesa 2
Në këtë artikull ne përdorëm si server web NGINX, por është mjaft e lehtë ta zëvendësoni me Apache, thjesht ndryshoni në skedarin e shabllonit në .
PĂ«rfundim
Në pjesën e parë të kësaj serie ne treguam se si të shpërndajmë shpejt aplikacione moderne web në platformën OpenShift. Sot ne shqyrtuam se çfarë bën imazhi Web App dhe si mund të kombinohet me një server web të pastër si NGINX me ndihmën e ndërtimeve të lidhura (chained build) për të krijuar një ndërtim më të përshtatshëm për kushte prodhimi. Në artikullin tjetër, përfundimtar të kësaj serie, ne do të tregojmë se si të drejtoni një server zhvillimi për aplikacionin tuaj në OpenShift dhe të sigurojmë sinkronizimin e skedarëve lokalë dhe atyre të largët.
Përmbajtja e kësaj serie artikujsh
- Pjesa 1: ;
- Pjesa 2: si të aplikoni imazhin e ri S2I së bashku me imazhin ekzistues të serverit HTTP, si NGINX, duke përdorur ndërtimet e lidhura OpenShift, për të organizuar shpërndarjen në prodhim;
- Pjesa 3: si të drejtoni një server zhvillimi në platformën OpenShift për aplikacionin tuaj dhe të sinkronizoni me sistemin e skedarëve lokal.
Burime të tjera
- Libri elektronik falas .
- Informacion në lidhje me .
Burimi: habr.com
