Hej alla! Detta är det andra inlägget i vår serie där vi visar hur man distribuerar moderna webbapplikationer på Red Hat OpenShift.
I det förra inlägget berörde vi en aning möjligheterna hos den nya S2I (källa-till-bild)-byggarbilden, som är designad för att bygga och distribuera moderna webbapplikationer på OpenShift-plattformen. Sedan var vi intresserade av ämnet att snabbt distribuera en applikation, och idag ska vi titta på hur man använder en S2I-avbildning som en "ren" byggarbild och kombinerar den med relaterade OpenShift-sammansättningar.
Ren byggarbild
Som vi nämnde i del XNUMX har de flesta moderna webbapplikationer ett så kallat byggsteg, som vanligtvis utför operationer som kodtranspilering, sammanlänkning av flera filer och minifiering. Filerna som erhålls som ett resultat av dessa operationer - och detta är statisk HTML, JavaScript och CSS - lagras i utdatamappen. Placeringen av den här mappen beror vanligtvis på vilka byggverktyg som används, och för React kommer detta att vara mappen ./build (vi återkommer till detta mer i detalj nedan).
Källa-till-bild (S2I)
I det här inlägget berör vi inte ämnet "vad är S2I och hur man använder det" (du kan läsa mer om detta ), men det är viktigt att vara tydlig med de två stegen i den här processen för att förstå vad en Web App Builder-bild gör.
Monteringsfas
Monteringsfasen är mycket lik vad som händer när du kör docker build och får en ny Docker-bild. Följaktligen inträffar detta steg när man startar en build på OpenShift-plattformen.
I fallet med en Web App Builder-avbildning ansvarar den för att installera din applikations beroenden och köra bygget. . Som standard använder byggarbilden byggkonstruktionen npm run, men detta kan åsidosättas genom miljövariabeln NPM_BUILD.
Som vi sa tidigare beror platsen för den färdiga, redan byggda applikationen på vilka verktyg du använder. Till exempel, i fallet med React kommer detta att vara mappen ./build, och för Angular-applikationer kommer det att vara mappen project_name/dist. Och, som redan visats i föregående inlägg, kan platsen för utdatakatalogen, som är inställd på att byggas som standard, åsidosättas genom miljövariabeln OUTPUT_DIR. Tja, eftersom platsen för utdatamappen skiljer sig från ramverk till ramverk kopierar du helt enkelt den genererade utdata till standardmappen i bilden, nämligen /opt/apt-root/output. Detta är viktigt för att förstå resten av den här artikeln, men låt oss nu snabbt titta på nästa steg - körfasen.
körfas
Detta steg inträffar när ett anrop till dockerkörning görs på den nya bilden som skapades under monteringsfasen. Samma sak händer när du distribuerar på OpenShift-plattformen. Standard användningsområden för att visa statiskt innehåll som finns i ovanstående standardutdatakatalog.
Den här metoden är bra för att snabbt distribuera applikationer, men det rekommenderas i allmänhet inte att visa statiskt innehåll på detta sätt. Tja, eftersom vi i verkligheten bara serverar statiskt innehåll, behöver vi inte Node.js installerat i vår bild - en webbserver räcker.
Med andra ord, när vi monterar behöver vi en sak, när vi utför behöver vi en annan. I den här situationen kommer kedjade konstruktioner väl till pass.
Kedjebyggen
Detta är vad de skriver om i OpenShift-dokumentationen:
"Två sammansättningar kan länkas samman, där den ena genererar en kompilerad enhet och den andra är värd för den enheten i en separat bild som används för att köra den enheten."
Med andra ord kan vi använda Web App Builder-bilden för att köra vår build, och sedan använda webbserverbilden, samma NGINX, för att servera vårt innehåll.
Således kan vi använda Web App Builder-bilden som en "ren" byggare och samtidigt ha en liten runtime-bild.
Låt oss nu titta på detta med ett specifikt exempel.
För träning kommer vi att använda , skapad med kommandoradsverktyget create-react-app.
Det kommer att hjälpa oss att få ihop allt .
Låt oss titta på den här filen mer i detalj och börja med parametrarna.
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
Allt här är ganska tydligt, men det är värt att uppmärksamma parametern OUTPUT_DIR. För React-applikationen i vårt exempel finns det inget att oroa sig för, eftersom React använder standardvärdet som utdatamapp, men i fallet med Angular eller något annat kommer denna parameter att behöva ändras vid behov.
Låt oss nu ta en titt på avsnittet 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'
Ta en titt på den tredje och fjärde bilden. De är båda definierade som Docker-bilder, och du kan tydligt se var de kommer ifrån.
Den tredje bilden är web-app-builder och den kommer från nodeshift/ubi8-s2i-web-app taggad 10.x på .
Den fjärde är en NGINX-bild (version 1.12) med den senaste taggen på .
Låt oss nu titta på de två första bilderna. De är båda tomma vid start och skapas endast under byggfasen. Den första bilden, react-web-app-builder, kommer att vara resultatet av ett monteringssteg som kommer att kombinera webb-app-builder-runtime-bilden och vår källkod. Det är därför vi lade till "-byggare" till namnet på denna bild.
Den andra bilden - react-web-app-runtime - kommer att vara resultatet av att kombinera nginx-image-runtime och några filer från react-web-app-builder-bilden. Den här bilden kommer också att användas under distributionen och kommer endast att innehålla webbservern och statisk HTML, JavaScript, CSS för vår applikation.
Förvirrad? Låt oss nu ta en titt på byggkonfigurationerna så kommer det att bli lite tydligare.
Vår mall har två byggkonfigurationer. Här är den första, och den är ganska 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 säger raden med etikett 1 att resultatet av detta bygge kommer att placeras i samma react-web-app-builder-bild som vi såg lite tidigare i avsnittet ImageStreams.
Raden märkt 2 talar om var du kan hämta koden ifrån. I vårt fall är detta ett git-förråd, och platsen, ref och kontextmappen bestäms av parametrarna vi redan såg ovan.
Raden märkt 3 är vad vi redan såg i parametrarnas avsnitt. Den lägger till miljövariabeln OUTPUT_DIR, som i vårt exempel är build.
Raden märkt 4 säger att man ska använda web-app-builder-runtime-bilden, som vi redan såg i ImageStream-sektionen.
Rad märkt 5 säger att vi vill använda en inkrementell konstruktion om S2I-bilden stöder det, och Web App Builder-bilden gör det. Vid den första lanseringen, efter att ha slutfört monteringsstadiet, kommer bilden att spara mappen node_modules i en arkivfil. Sedan, vid efterföljande körningar, kommer bilden helt enkelt att packa upp den här mappen för att minska byggtiden.
Och slutligen, raden märkt 6 är bara några triggers för att få bygget att köras automatiskt, utan manuellt ingripande, när något ändras.
Sammantaget är detta en ganska standardbyggkonfiguration.
Låt oss nu ta en titt på den andra byggkonfigurationen. Den är väldigt lik den första, men det finns en viktig skillnad.
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 andra byggkonfigurationen är react-web-app-runtime, och den börjar ganska standard.
Raden märkt 1 är inget nytt - den säger helt enkelt att byggresultatet läggs in i react-web-app-runtime-bilden.
Raden märkt 2, som i den tidigare konfigurationen, indikerar var källkoden ska hämtas ifrån. Men notera att vi här säger att det är taget från bilden. Dessutom, från bilden som vi just skapade - från react-web-app-builder (anges på rad märkt 3). Filerna vi vill använda finns inuti bilden och deras plats där är inställd på rad märkt 4, i vårt fall är det /opt/app-root/output/. Om du kommer ihåg är det här de filer som genereras baserat på resultaten av att bygga vår applikation lagras.
Målmappen som anges i termen med etikett 5 är helt enkelt den aktuella katalogen (det här är allt, kom ihåg, körs i någon magisk sak som heter OpenShift, och inte på din lokala dator).
Strategisektionen – rad märkt 6 – liknar också den första byggkonfigurationen. Bara den här gången kommer vi att använda nginx-image-runtime, som vi redan såg i ImageStream-sektionen.
Slutligen är raden märkt 7 en sektion av triggers som kommer att aktivera denna build varje gång react-web-app-builder-bilden ändras.
Annars innehåller den här mallen ganska standardinstallationskonfigurationer, såväl som saker som relaterar till tjänster och rutter, men vi kommer inte att gå in på det för mycket i detalj. Observera att bilden som kommer att distribueras är react-web-app-runtime-bilden.
Applikationsdistribution
Så nu när vi har tittat på mallen, låt oss se hur man använder den för att distribuera en applikation.
Vi kan använda OpenShift-klientverktyget oc för att distribuera vår mall:
$ 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
Det första kommandot i skärmdumpen ovan är ett medvetet tekniskt sätt att hitta en mall./openshiftio/application.yaml.
Det andra kommandot skapar helt enkelt en ny applikation baserat på denna mall.
När dessa kommandon har fungerat kommer vi att se att vi har två sammansättningar:
Och återvänder vi till översiktsskärmen kommer vi att se den lanserade podden:
Klicka på länken så kommer vi till vår app, som är standardsidan för React-appen:
Uppdatering 1/XNUMX/XNUMX
För Angular älskare har vi också .
Mönstret här är detsamma, förutom variabeln OUTPUT_DIR.
Uppdatering 2/XNUMX/XNUMX
I den här artikeln använde vi NGINX som webbserver, men det är ganska enkelt att ersätta den med Apache, bara ändra mallen i filen på .
Slutsats
I den första delen av den här serien visade vi hur man snabbt kan distribuera moderna webbapplikationer på OpenShift-plattformen. Idag har vi tittat på vad en webbappbild gör och hur den kan kombineras med en ren webbserver som NGINX med hjälp av kedjade builds för att skapa en mer produktionsklar applikationsbyggnad. I nästa och sista artikel i denna serie kommer vi att visa hur du kör en utvecklingsserver för din applikation på OpenShift och säkerställer synkronisering av lokala och fjärrfiler.
Innehållet i denna artikelserie
- Del 1: ;
- Del 2: Hur man använder en ny S2I-avbildning med en befintlig HTTP-serveravbildning, såsom NGINX, med associerade OpenShift-sammansättningar för produktionsinstallation;
- Del 3: hur man kör en utvecklingsserver för din applikation på OpenShift-plattformen och synkroniserar den med det lokala filsystemet.
Ytterligare resurser
- Gratis e-bok .
- Information om .
Källa: will.com