Hej alle! Dette er det andet indlæg i vores serie, hvor vi viser, hvordan man implementerer moderne webapplikationer på Red Hat OpenShift.
I det forrige indlæg kom vi lidt ind på mulighederne i det nye S2I (kilde-til-billede) builder-image, som er designet til at bygge og implementere moderne webapplikationer på OpenShift-platformen. Så var vi interesserede i emnet hurtig implementering af en applikation, og i dag vil vi se på, hvordan man bruger et S2I-billede som et "rent" builderbillede og kombinerer det med relaterede OpenShift-samlinger.
Rent builderbillede
Som vi nævnte i del XNUMX, har de fleste moderne webapplikationer et såkaldt build-stadium, som typisk udfører operationer som kodetranspilering, multipel filsammenkædning og minifikation. Filerne opnået som et resultat af disse operationer - og dette er statisk HTML, JavaScript og CSS - gemmes i outputmappen. Placeringen af denne mappe afhænger normalt af, hvilke byggeværktøjer der bruges, og for React vil dette være ./build-mappen (vi kommer mere detaljeret tilbage til dette nedenfor).
Kilde-til-billede (S2I)
I dette indlæg kommer vi ikke ind på emnet "hvad er S2I og hvordan man bruger det" (du kan læse mere om dette ), men det er vigtigt at være klar over de to trin i denne proces for at forstå, hvad et Web App Builder-billede gør.
Monteringsfase
Monteringsfasen minder meget om, hvad der sker, når du kører docker build og ender med et nyt Docker image. Derfor opstår dette trin, når du starter en build på OpenShift-platformen.
I tilfælde af et Web App Builder-billede er det ansvarligt for at installere din applikations afhængigheder og køre buildet. . Som standard bruger builder-billedet npm run build-konstruktionen, men denne kan tilsidesættes gennem NPM_BUILD miljøvariablen.
Som vi sagde tidligere, afhænger placeringen af den færdige, allerede bygget applikation af, hvilke værktøjer du bruger. For eksempel, i tilfælde af React vil dette være mappen ./build, og for Angular-applikationer vil det være mappen project_name/dist. Og som allerede vist i det forrige indlæg, kan placeringen af output-mappen, som er indstillet til at bygge som standard, tilsidesættes gennem miljøvariablen OUTPUT_DIR. Nå, da placeringen af outputmappen er forskellig fra framework til framework, kopierer du blot det genererede output til standardmappen i billedet, nemlig /opt/apt-root/output. Dette er vigtigt for at forstå resten af denne artikel, men lad os nu hurtigt se på næste fase - løbefasen.
køre fase
Dette trin opstår, når der foretages et kald til docker-kørsel på det nye billede, der er oprettet under monteringsfasen. Det samme sker ved implementering på OpenShift-platformen. Standard bruger for at betjene statisk indhold, der er placeret i ovenstående standardoutputmappe.
Denne metode er god til hurtigt at implementere applikationer, men det anbefales generelt ikke at vise statisk indhold på denne måde. Nå, da vi i virkeligheden kun serverer statisk indhold, behøver vi ikke Node.js installeret inde i vores image - en webserver vil være tilstrækkelig.
Med andre ord, når vi samler, har vi brug for én ting, når vi udfører, har vi brug for en anden. I denne situation er lænkede builds nyttige.
Lænkede byggerier
Det er det, de skriver om i OpenShift-dokumentationen:
"To samlinger kan linkes sammen, hvor den ene genererer en kompileret enhed, og den anden hoster den enhed i et separat billede, der bruges til at køre denne enhed."
Med andre ord kan vi bruge Web App Builder-billedet til at køre vores build og derefter bruge webserverbilledet, det samme NGINX, til at tjene vores indhold.
Vi kan således bruge Web App Builder-billedet som en "ren" builder og samtidig have et lille runtime-billede.
Lad os nu se på dette med et specifikt eksempel.
Til træning vil vi bruge , oprettet ved hjælp af kommandolinjeværktøjet create-react-app.
Det vil hjælpe os med at samle alt .
Lad os se på denne fil mere detaljeret, og start med parametersektionen.
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 ret klart, men det er værd at være opmærksom på parameteren OUTPUT_DIR. For React-applikationen i vores eksempel er der intet at bekymre sig om, da React bruger standardværdien som output-mappen, men i tilfælde af Angular eller noget andet, skal denne parameter ændres efter behov.
Lad os nu tage et kig på ImageStreams-sektionen.
- 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'
Tag et kig på det tredje og fjerde billede. De er begge defineret som Docker-billeder, og du kan tydeligt se, hvor de kommer fra.
Det tredje billede er web-app-builder, og det kommer fra nodeshift/ubi8-s2i-web-app tagget 10.x på .
Det fjerde er et NGINX-billede (version 1.12) med det seneste tag på .
Lad os nu se på de to første billeder. De er begge tomme ved start og oprettes kun i byggefasen. Det første billede, react-web-app-builder, vil være resultatet af et monteringstrin, der vil kombinere web-app-builder-runtime-billedet og vores kildekode. Det er derfor, vi tilføjede "-builder" til navnet på dette billede.
Det andet billede - react-web-app-runtime - vil være resultatet af at kombinere nginx-image-runtime og nogle filer fra react-web-app-builder-billedet. Dette billede vil også blive brugt under implementeringen og vil kun indeholde webserveren og statisk HTML, JavaScript, CSS fra vores applikation.
Forvirret? Lad os nu tage et kig på build-konfigurationerne, og det vil blive lidt klarere.
Vores skabelon har to byggekonfigurationer. Her er den første, og den er ret 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, siger linjen med label 1, at resultatet af denne build vil blive placeret i det samme react-web-app-builder-billede, som vi så lidt tidligere i ImageStreams-sektionen.
Linjen mærket 2 fortæller dig, hvor du skal hente koden fra. I vores tilfælde er dette et git-lager, og placeringen, ref og kontekstmappen bestemmes af de parametre, vi allerede har set ovenfor.
Linjen mærket 3 er, hvad vi allerede så i parametersektionen. Den tilføjer miljøvariablen OUTPUT_DIR, som i vores eksempel er build.
Linjen mærket 4 siger, at man skal bruge web-app-builder-runtime-billedet, som vi allerede så i ImageStream-sektionen.
Linje mærket 5 siger, at vi ønsker at bruge en inkrementel build, hvis S2I-billedet understøtter det, og Web App Builder-billedet gør det. Ved den første lancering, efter monteringsfasen er afsluttet, gemmer billedet node_modules-mappen i en arkivfil. Derefter, ved efterfølgende kørsler, vil billedet blot udpakke denne mappe for at reducere byggetiden.
Og endelig er linjen mærket 6 blot nogle få triggere til at få bygningen til at køre automatisk, uden manuel indgriben, når noget ændrer sig.
Alt i alt er dette en ret standard build-konfiguration.
Lad os nu tage et kig på den anden build-konfiguration. Den minder meget om den første, men der er en vigtig forskel.
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 anden build-konfiguration er react-web-app-runtime, og den starter ret standard.
Linjen mærket 1 er ikke noget nyt - den siger blot, at byggeresultatet sættes ind i react-web-app-runtime-billedet.
Linjen mærket 2, som i den forrige konfiguration, angiver, hvor kildekoden skal hentes fra. Men læg mærke til, at her siger vi, at det er taget fra billedet. Desuden fra det billede, vi lige har oprettet - fra react-web-app-builder (angivet i linje mærket 3). De filer, vi ønsker at bruge, er inde i billedet, og deres placering der er angivet på linje mærket 4, i vores tilfælde er det /opt/app-root/output/. Hvis du husker det, er det her de filer, der er genereret baseret på resultaterne af opbygningen af vores applikation, gemmes.
Destinationsmappen, der er angivet i udtrykket med etiket 5, er simpelthen den aktuelle mappe (det er alt, husk, at det kører inde i en magisk ting kaldet OpenShift, og ikke på din lokale computer).
Strategisektionen – linje mærket 6 – ligner også den første build-konfiguration. Kun denne gang skal vi bruge nginx-image-runtime, som vi allerede så i ImageStream-sektionen.
Endelig er linjen mærket 7 en sektion af triggere, der vil aktivere denne build, hver gang react-web-app-builder-billedet ændres.
Ellers indeholder denne skabelon en ret standard installationskonfiguration samt ting, der relaterer til tjenester og ruter, men vi vil ikke gå for meget i detaljer. Bemærk venligst, at billedet, der vil blive implementeret, er react-web-app-runtime-billedet.
Applikationsimplementering
Så nu hvor vi har set på skabelonen, lad os se, hvordan man bruger den til at implementere en applikation.
Vi kan bruge OpenShift-klientværktøjet kaldet oc til at implementere vores skabelon:
$ 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 kommando i skærmbilledet ovenfor er en bevidst teknisk måde at finde en skabelon på./openshiftio/application.yaml.
Den anden kommando opretter simpelthen en ny applikation baseret på denne skabelon.
Når disse kommandoer virker, vil vi se, at vi har to samlinger:
Og vender vi tilbage til oversigtsskærmen, vil vi se den lancerede pod:
Klik på linket, og vi bliver ført til vores app, som er standardsiden for React App:
Tillæg 1
For Angular elskere har vi også .
Mønstret her er det samme, bortset fra variablen OUTPUT_DIR.
Tillæg 2
I denne artikel brugte vi NGINX som webserver, men det er ret nemt at erstatte det med Apache, bare skift skabelonen i filen på .
Konklusion
I den første del af denne serie viste vi, hvordan man hurtigt kan implementere moderne webapplikationer på OpenShift-platformen. I dag har vi set på, hvad et Web App-billede gør, og hvordan det kan kombineres med en ren webserver som NGINX ved hjælp af kædede builds for at skabe en mere produktionsklar applikationsopbygning. I den næste og sidste artikel i denne serie viser vi, hvordan du kører en udviklingsserver til din applikation på OpenShift og sikrer synkronisering af lokale og eksterne filer.
Indholdet af denne artikelserie
- Del 1: ;
- Del 2: Hvordan man bruger et nyt S2I-image med et eksisterende HTTP-serverbillede, såsom NGINX, ved hjælp af tilhørende OpenShift-samlinger til produktionsimplementering;
- Del 3: hvordan man kører en udviklingsserver til din applikation på OpenShift-platformen og synkroniserer den med det lokale filsystem.
Yderligere ressourcer
- Gratis e-bog .
- Oplysninger vedr .
Kilde: www.habr.com