Hei alle sammen! Dette er det andre innlegget i serien vår der vi viser hvordan du distribuerer moderne webapplikasjoner på Red Hat OpenShift.
I forrige innlegg berørte vi litt mulighetene til det nye S2I (kilde-til-bilde)-byggerbildet, som er designet for å bygge og distribuere moderne nettapplikasjoner på OpenShift-plattformen. Deretter var vi interessert i temaet raskt å distribuere en applikasjon, og i dag skal vi se på hvordan du bruker et S2I-bilde som et "rent" byggebilde og kombinerer det med relaterte OpenShift-sammenstillinger.
Rent byggherrebilde
Som vi nevnte i del XNUMX, har de fleste moderne webapplikasjoner et såkalt byggestadium, som typisk utfører operasjoner som kodetranspilering, sammenkobling av flere filer og minifisering. Filene oppnådd som et resultat av disse operasjonene - og dette er statisk HTML, JavaScript og CSS - lagres i utdatamappen. Plasseringen av denne mappen avhenger vanligvis av hvilke byggeverktøy som brukes, og for React vil dette være ./build-mappen (vi kommer tilbake til dette mer detaljert nedenfor).
Kilde-til-bilde (S2I)
I dette innlegget berører vi ikke temaet "hva er S2I og hvordan du bruker det" (du kan lese mer om dette ), men det er viktig å være klar over de to trinnene i denne prosessen for å forstå hva et Web App Builder-bilde gjør.
Monteringsfase
Monteringsfasen er veldig lik det som skjer når du kjører docker build og ender opp med et nytt Docker-bilde. Følgelig oppstår dette stadiet når du starter en build på OpenShift-plattformen.
Når det gjelder et Web App Builder-bilde, er det ansvarlig for å installere programmets avhengigheter og kjøre bygget. . Som standard bruker byggherrebildet npm run build-konstruksjonen, men denne kan overstyres gjennom NPM_BUILD miljøvariabelen.
Som vi sa tidligere, avhenger plasseringen av den ferdige, allerede bygde applikasjonen av hvilke verktøy du bruker. For eksempel, i tilfelle av React vil dette være ./build-mappen, og for Angular-applikasjoner vil det være project_name/dist-mappen. Og, som allerede vist i forrige innlegg, kan plasseringen av utdatakatalogen, som er satt til å bygge som standard, overstyres gjennom miljøvariabelen OUTPUT_DIR. Vel, siden plasseringen av utdatamappen er forskjellig fra rammeverk til rammeverk, kopierer du ganske enkelt den genererte utdata til standardmappen i bildet, nemlig /opt/apt-root/output. Dette er viktig for å forstå resten av denne artikkelen, men la oss foreløpig raskt se på neste trinn – løpsfasen.
kjøre fase
Dette stadiet oppstår når et kall til docker-kjøring gjøres på det nye bildet som ble opprettet under monteringsfasen. Det samme skjer når du distribuerer på OpenShift-plattformen. Misligholde bruker for å betjene statisk innhold som ligger i standardutdatakatalogen ovenfor.
Denne metoden er god for å raskt distribuere applikasjoner, men det anbefales generelt ikke å vise statisk innhold på denne måten. Vel, siden vi i virkeligheten bare serverer statisk innhold, trenger vi ikke Node.js installert i bildet vårt - en nettserver vil være tilstrekkelig.
Med andre ord, når vi monterer trenger vi en ting, når vi utfører trenger vi en annen. I denne situasjonen kommer lenkede bygg godt med.
Lenket bygger
Det er dette de skriver om i OpenShift-dokumentasjonen:
"To sammenstillinger kan kobles sammen, hvor den ene genererer en kompilert enhet og den andre er vert for den enheten i et separat bilde som brukes til å kjøre den enheten."
Med andre ord kan vi bruke Web App Builder-bildet til å kjøre bygget vårt, og deretter bruke webserverbildet, samme NGINX, for å tjene innholdet vårt.
Dermed kan vi bruke Web App Builder-bildet som en "ren" bygger og samtidig ha et lite kjøretidsbilde.
La oss nå se på dette med et spesifikt eksempel.
Til trening vil vi bruke , opprettet ved hjelp av kommandolinjeverktøyet create-react-app.
Det vil hjelpe oss å sette alt sammen .
La oss se på denne filen mer detaljert, og starte med parameterdelen.
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
Alt her er ganske klart, men det er verdt å ta hensyn til OUTPUT_DIR-parameteren. For React-applikasjonen i vårt eksempel er det ingenting å bekymre seg for, siden React bruker standardverdien som utdatamappen, men i tilfelle Angular eller noe annet, må denne parameteren endres etter behov.
La oss nå ta en titt på ImageStreams-delen.
- 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'
Ta en titt på det tredje og fjerde bildet. De er begge definert som Docker-bilder, og du kan tydelig se hvor de kommer fra.
Det tredje bildet er web-app-builder og det kommer fra nodeshift/ubi8-s2i-web-app merket 10.x på .
Det fjerde er et NGINX-bilde (versjon 1.12) med den siste taggen på .
La oss nå se på de to første bildene. De er begge tomme ved oppstart og opprettes kun under byggefasen. Det første bildet, react-web-app-builder, vil være resultatet av et monteringstrinn som vil kombinere web-app-builder-runtime-bildet og kildekoden vår. Det er derfor vi la til "-builder" i navnet på dette bildet.
Det andre bildet - react-web-app-runtime - vil være resultatet av å kombinere nginx-image-runtime og noen filer fra react-web-app-builder-bildet. Dette bildet vil også bli brukt under distribusjon og vil kun inneholde webserveren og statisk HTML, JavaScript, CSS for applikasjonen vår.
Forvirret? La oss nå ta en titt på byggekonfigurasjonene, og det vil bli litt klarere.
Malen vår har to byggekonfigurasjoner. Her er den første, og den er ganske standard:
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
Som du kan se, sier linjen med etikett 1 at resultatet av denne byggingen vil bli plassert i det samme react-web-app-builder-bildet som vi så litt tidligere i ImageStreams-delen.
Linjen merket 2 forteller deg hvor du skal hente koden fra. I vårt tilfelle er dette et git-lager, og plasseringen, ref og kontekstmappen bestemmes av parameterne vi allerede har sett ovenfor.
Linjen merket 3 er det vi allerede så i parameterdelen. Den legger til miljøvariabelen OUTPUT_DIR, som i vårt eksempel er build.
Linjen merket 4 sier å bruke web-app-builder-runtime-bildet, som vi allerede så i ImageStream-delen.
Linje merket 5 sier at vi ønsker å bruke en inkrementell build hvis S2I-bildet støtter det, og Web App Builder-bildet gjør det. Ved første lansering, etter å ha fullført monteringsfasen, vil bildet lagre node_modules-mappen i en arkivfil. Deretter, ved påfølgende kjøringer, vil bildet ganske enkelt pakke ut denne mappen for å redusere byggetiden.
Og til slutt, linjen merket 6 er bare noen få triggere for å få bygget til å kjøre automatisk, uten manuell inngripen, når noe endres.
Totalt sett er dette en ganske standard byggekonfigurasjon.
La oss nå ta en titt på den andre byggekonfigurasjonen. Den er veldig lik den første, men det er en viktig forskjell.
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
Så den andre byggekonfigurasjonen er react-web-app-runtime, og den starter ganske standard.
Linjen merket 1 er ikke noe nytt - den sier ganske enkelt at byggeresultatet legges inn i react-web-app-runtime-bildet.
Linjen merket 2, som i forrige konfigurasjon, indikerer hvor kildekoden skal hentes fra. Men legg merke til at her sier vi at det er tatt fra bildet. Dessuten, fra bildet vi nettopp opprettet - fra react-web-app-builder (angitt på linje merket 3). Filene vi ønsker å bruke er inne i bildet og deres plassering der er satt på linje merket 4, i vårt tilfelle er det /opt/app-root/output/. Hvis du husker det, er det her filene som er generert basert på resultatene fra byggingen av applikasjonen vår lagres.
Destinasjonsmappen som er spesifisert i begrepet med etikett 5, er ganske enkelt den gjeldende katalogen (dette er alt, husk, kjører inne i en magisk ting kalt OpenShift, og ikke på din lokale datamaskin).
Strategidelen – linje merket 6 – ligner også på den første byggekonfigurasjonen. Bare denne gangen skal vi bruke nginx-image-runtime, som vi allerede så i ImageStream-delen.
Til slutt er linjen merket 7 en del av triggere som vil aktivere denne konstruksjonen hver gang react-web-app-builder-bildet endres.
Ellers inneholder denne malen ganske standard distribusjonskonfigurasjon, samt ting som er relatert til tjenester og ruter, men vi vil ikke gå for mye i detalj. Vær oppmerksom på at bildet som vil bli distribuert er react-web-app-runtime-bildet.
Applikasjonsimplementering
Så nå som vi har sett på malen, la oss se hvordan du bruker den til å distribuere en applikasjon.
Vi kan bruke OpenShift-klientverktøyet kalt oc for å distribuere malen vår:
$ 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
Den første kommandoen i skjermbildet ovenfor er en bevisst teknisk måte å finne en mal på./openshiftio/application.yaml.
Den andre kommandoen oppretter ganske enkelt en ny applikasjon basert på denne malen.
Etter at disse kommandoene fungerer, vil vi se at vi har to sammenstillinger:
Og tilbake til Oversikt-skjermen vil vi se den lanserte poden:
Klikk på koblingen og vi blir ført til appen vår, som er standard React App-side:
Tillegg 1
For Angular elskere har vi også .
Mønsteret her er det samme, bortsett fra OUTPUT_DIR-variabelen.
Tillegg 2
I denne artikkelen brukte vi NGINX som en webserver, men det er ganske enkelt å erstatte den med Apache, bare endre malen i filen på .
Konklusjon
I den første delen av denne serien viste vi hvordan du raskt kan distribuere moderne webapplikasjoner på OpenShift-plattformen. I dag har vi sett på hva et Web App-bilde gjør og hvordan det kan kombineres med en ren webserver som NGINX ved å bruke kjedede bygg for å lage en mer produksjonsklar applikasjonsbygging. I den neste og siste artikkelen i denne serien vil vi vise hvordan du kjører en utviklingsserver for applikasjonen din på OpenShift og sikrer synkronisering av lokale og eksterne filer.
Innholdet i denne artikkelserien
- Del 1: ;
- Del 2: Hvordan bruke et nytt S2I-bilde med et eksisterende HTTP-serverbilde, for eksempel NGINX, ved å bruke tilknyttede OpenShift-sammenstillinger for produksjonsdistribusjon;
- Del 3: hvordan kjøre en utviklingsserver for applikasjonen din på OpenShift-plattformen og synkronisere den med det lokale filsystemet.
Tilleggsressurser
- Gratis e-bok .
- Informasjon på .
Kilde: www.habr.com