Zdravo svima! Ovo je drugi post u našoj seriji u kojem pokazujemo kako implementirati moderne web aplikacije na Red Hat OpenShift.
U prethodnom postu malo smo se dotakli mogućnosti novog S2I (source-to-image) builder slike, koji je dizajniran za izgradnju i implementaciju modernih web aplikacija na OpenShift platformi. Zatim nas je zanimala tema brzog postavljanja aplikacije, a danas ćemo pogledati kako koristiti S2I sliku kao “čistu” sliku graditelja i kombinirati je sa srodnim OpenShift sklopovima.
Čista slika graditelja
Kao što smo spomenuli u prvom dijelu, većina modernih web aplikacija ima takozvanu fazu izrade, koja tipično izvodi operacije kao što su transpilacija koda, konkatenacija više datoteka i minifikacija. Fajlovi dobijeni kao rezultat ovih operacija - a to je statički HTML, JavaScript i CSS - pohranjuju se u izlaznu mapu. Lokacija ove fascikle obično zavisi od toga koji alati za pravljenje se koriste, a za React to će biti ./build folder (na to ćemo se vratiti detaljnije u nastavku).
Od izvora do slike (S2I)
U ovom postu se ne dotičemo teme „šta je S2I i kako ga koristiti“ (više o tome možete pročitati ), ali važno je biti jasni u vezi sa dva koraka u ovom procesu da biste razumjeli šta radi slika Web App Builder-a.
Faza montaže
Faza montaže je po prirodi vrlo slična onome što se dešava kada pokrenete docker build i završite sa novom Docker slikom. Shodno tome, ova faza se javlja prilikom pokretanja gradnje na OpenShift platformi.
U slučaju slike Web App Builder, ona je odgovorna za instaliranje zavisnosti vaše aplikacije i pokretanje izgradnje. . Podrazumevano, slika graditelja koristi konstrukciju izgradnje npm run, ali to se može nadjačati kroz varijablu okruženja NPM_BUILD.
Kao što smo ranije rekli, lokacija gotove, već izgrađene aplikacije ovisi o tome koje alate koristite. Na primjer, u slučaju React-a ovo će biti ./build folder, a za Angular aplikacije to će biti project_name/dist folder. I, kao što je već prikazano u prethodnom postu, lokacija izlaznog direktorija, koja je po defaultu postavljena za izgradnju, može se nadjačati kroz varijablu okruženja OUTPUT_DIR. Pa, pošto se lokacija izlazne mape razlikuje od okvira do okvira, jednostavno kopirate generirani izlaz u standardni folder na slici, odnosno /opt/apt-root/output. Ovo je važno za razumijevanje ostatka ovog članka, ali za sada pogledajmo na brzinu sljedeću fazu - fazu pokretanja.
run faza
Ova faza se događa kada se izvrši poziv docker run-u na novoj slici kreiranoj tokom faze sklapanja. Isto se dešava kada se implementira na OpenShift platformi. Default koristi za posluživanje statičkog sadržaja koji se nalazi u gornjem standardnom izlaznom direktoriju.
Ova metoda je dobra za brzo postavljanje aplikacija, ali se općenito ne preporučuje posluživanje statičnog sadržaja na ovaj način. Pa, pošto u stvarnosti opslužujemo samo statički sadržaj, ne trebamo Node.js instaliran unutar naše slike - web server će biti dovoljan.
Drugim riječima, pri sklapanju nam je potrebna jedna stvar, pri izvođenju nam je potrebna druga. U ovoj situaciji, lančane konstrukcije dobro dolaze.
Lančane gradnje
O tome pišu u OpenShift dokumentaciji:
"Dva sklopa mogu biti povezana zajedno, pri čemu jedan generiše kompajlirani entitet, a drugi hostuje taj entitet u zasebnoj slici koja se koristi za pokretanje tog entiteta."
Drugim riječima, možemo koristiti sliku Web App Builder-a za pokretanje naše izrade, a zatim koristiti sliku web servera, isti NGINX, za posluživanje našeg sadržaja.
Dakle, sliku Web App Builder-a možemo koristiti kao „čist“ graditelj i istovremeno imati malu runtime sliku.
Pogledajmo sada ovo na konkretnom primjeru.
Za obuku ćemo koristiti , kreiran pomoću alata komandne linije create-react-app.
To će nam pomoći da sve spojimo .
Pogledajmo ovu datoteku detaljnije i počnimo s odjeljkom parametara.
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
Ovdje je sve prilično jasno, ali vrijedi obratiti pažnju na parametar OUTPUT_DIR. Za React aplikaciju u našem primjeru, nema razloga za brigu, budući da React koristi zadanu vrijednost kao izlaznu mapu, ali u slučaju Angulara ili nečeg drugog, ovaj parametar će se morati promijeniti po potrebi.
Sada pogledajmo odjeljak 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'
Pogledajte treću i četvrtu sliku. Obje su definirane kao Docker slike i možete jasno vidjeti odakle dolaze.
Treća slika je web-app-builder i dolazi iz nodeshift/ubi8-s2i-web-app označene 10.x na .
Četvrta je NGINX slika (verzija 1.12) sa najnovijom uključenom oznakom .
Pogledajmo sada prve dvije slike. Oba su prazna na početku i kreiraju se samo tokom faze izgradnje. Prva slika, react-web-app-builder, bit će rezultat koraka sastavljanja koji će kombinirati web-app-builder-runtime sliku i naš izvorni kod. Zato smo nazivu ove slike dodali "-builder".
Druga slika - react-web-app-runtime - će biti rezultat kombinovanja nginx-image-runtime i nekih datoteka sa slike react-web-app-builder. Ova slika će se također koristiti tokom implementacije i sadržavat će samo web server i statički HTML, JavaScript, CSS naše aplikacije.
Zbunjen? Sada pogledajmo konfiguracije izgradnje i biće malo jasnije.
Naš predložak ima dvije konfiguracije izrade. Evo prvog, i prilično je standardan:
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
Kao što možete vidjeti, linija s oznakom 1 kaže da će rezultat ove izrade biti smješten u istu sliku react-web-app-builder koju smo vidjeli malo ranije u odjeljku ImageStreams.
Linija označena sa 2 govori vam odakle da dobijete kod. U našem slučaju, ovo je git spremište, a lokacija, ref i kontekst folder su određeni parametrima koje smo već vidjeli gore.
Linija označena sa 3 je ono što smo već vidjeli u odjeljku parametara. Dodaje varijablu okruženja OUTPUT_DIR, koja je u našem primjeru build.
Linija označena sa 4 kaže da se koristi slika vremena izvođenja web-app-builder-a, koju smo već vidjeli u odjeljku ImageStream.
Linija označena 5 kaže da želimo da koristimo inkrementalnu gradnju ako je podržava S2I slika, a slika Web App Builder podržava. Prilikom prvog pokretanja, nakon što je faza sklapanja završena, slika će sačuvati fasciklu node_modules u arhivsku datoteku. Zatim, prilikom narednih pokretanja, slika će jednostavno raspakovati ovu fasciklu kako bi se smanjilo vreme izrade.
I na kraju, linija označena 6 je samo nekoliko pokretača za automatsko pokretanje izrade, bez ručne intervencije, kada se nešto promijeni.
Sve u svemu, ovo je prilično standardna konfiguracija izrade.
Sada pogledajmo drugu konfiguraciju izgradnje. Vrlo je sličan prvom, ali postoji jedna bitna 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
Dakle, druga konfiguracija izgradnje je react-web-app-runtime, i počinje prilično standardno.
Linija označena sa 1 nije ništa novo - ona jednostavno kaže da se rezultat izgradnje stavlja u react-web-app-runtime sliku.
Linija označena sa 2, kao iu prethodnoj konfiguraciji, označava odakle dobiti izvorni kod. Ali primijetite da ovdje govorimo da je preuzeto sa slike. Štaviše, sa slike koju smo upravo kreirali - iz react-web-app-builder (naznačenog u redu označenom 3). Datoteke koje želimo da koristimo nalaze se unutar slike i njihova lokacija je postavljena u liniji označenoj sa 4, u našem slučaju to je /opt/app-root/output/. Ako se sjećate, ovdje se pohranjuju datoteke generirane na osnovu rezultata izgradnje naše aplikacije.
Odredišni folder naveden u terminu sa oznakom 5 je jednostavno trenutni direktorijum (ovo je sve, zapamtite, radi unutar neke magične stvari koja se zove OpenShift, a ne na vašem lokalnom računaru).
Odjeljak strategije – linija označena 6 – također je sličan prvoj konfiguraciji izgradnje. Samo ovaj put ćemo koristiti nginx-image-runtime, što smo već vidjeli u odjeljku ImageStream.
Konačno, linija označena 7 je dio okidača koji će aktivirati ovu konstrukciju svaki put kada se promijeni slika react-web-app-builder.
Inače, ovaj predložak sadrži prilično standardnu konfiguraciju implementacije, kao i stvari koje se odnose na usluge i rute, ali nećemo ulaziti previše u detalje. Imajte na umu da je slika koja će biti raspoređena slika react-web-app-runtime.
Primena aplikacije
Sada kada smo pogledali predložak, hajde da vidimo kako ga koristiti za implementaciju aplikacije.
Možemo koristiti OpenShift klijentski alat koji se zove oc za implementaciju našeg predloška:
$ 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
Prva komanda na slici iznad je namjerno inženjerski način za pronalaženje šablona./openshiftio/application.yaml.
Druga naredba jednostavno kreira novu aplikaciju na osnovu ovog predloška.
Nakon što ove komande rade, vidjet ćemo da imamo dva sklopa:
I vraćajući se na ekran Pregled, vidjet ćemo pokrenutu pod:
Kliknite na link i bit ćemo odvedeni na našu aplikaciju, koja je zadana stranica React aplikacije:
Dodatak 1
Za ljubitelje uglova imamo i .
Uzorak je ovdje isti, osim varijable OUTPUT_DIR.
Dodatak 2
U ovom članku smo koristili NGINX kao web server, ali ga je prilično lako zamijeniti Apacheom, samo promijenite predložak u datoteci na .
zaključak
U prvom dijelu ove serije pokazali smo kako brzo implementirati moderne web aplikacije na OpenShift platformi. Danas smo pogledali šta radi slika Web aplikacije i kako se može kombinovati sa čistim veb serverom kao što je NGINX koristeći ulančane verzije da bi se napravila aplikacija koja je spremnija za proizvodnju. U sljedećem i posljednjem članku u ovoj seriji, pokazat ćemo kako pokrenuti razvojni server za vašu aplikaciju na OpenShift-u i osigurati sinhronizaciju lokalnih i udaljenih datoteka.
Sadržaj ove serije članaka
- Dio 1: ;
- Dio 2: Kako koristiti novu S2I sliku sa postojećom slikom HTTP servera, kao što je NGINX, koristeći pridružene OpenShift sklopove za primenu u proizvodnji;
- Dio 3: kako pokrenuti razvojni server za vašu aplikaciju na OpenShift platformi i sinkronizirati ga s lokalnim sistemom datoteka.
Dodatni resursi
- Besplatna e-knjiga .
- Informacije o .
izvor: www.habr.com