Kamusta kayong lahat! Ito ang pangalawang post sa aming serye kung saan ipinapakita namin kung paano mag-deploy ng mga modernong web application sa Red Hat OpenShift.
Sa nakaraang post, bahagyang hinawakan namin ang mga kakayahan ng bagong S2I (source-to-image) builder image, na idinisenyo para sa pagbuo at pag-deploy ng mga modernong web application sa OpenShift platform. Pagkatapos ay interesado kami sa paksa ng mabilis na pag-deploy ng isang application, at ngayon ay titingnan namin kung paano gumamit ng isang S2I na imahe bilang isang "purong" builder na imahe at pagsamahin ito sa mga nauugnay na OpenShift assemblies.
Malinis na imahe ng tagabuo
Tulad ng nabanggit namin sa Bahagi XNUMX, karamihan sa mga modernong web application ay may tinatawag na yugto ng pagbuo, na karaniwang nagsasagawa ng mga operasyon tulad ng transpilation ng code, maramihang pagsasama-sama ng file, at minification. Ang mga file na nakuha bilang resulta ng mga operasyong ito - at ito ay static na HTML, JavaScript at CSS - ay naka-imbak sa output folder. Ang lokasyon ng folder na ito ay kadalasang nakadepende sa kung anong mga build tool ang ginagamit, at para sa React ito ang ./build folder (babalikan namin ito nang mas detalyado sa ibaba).
Source-to-Image (S2I)
Sa post na ito hindi namin hinawakan ang paksang "ano ang S2I at kung paano gamitin ito" (maaari kang magbasa nang higit pa tungkol dito ), ngunit mahalagang maging malinaw tungkol sa dalawang hakbang sa prosesong ito upang maunawaan kung ano ang ginagawa ng imahe ng Web App Builder.
Yugto ng pagpupulong
Ang yugto ng pagpupulong ay halos kapareho sa kung ano ang mangyayari kapag nagpatakbo ka ng docker build at nagtatapos sa isang bagong imahe ng Docker. Alinsunod dito, ang yugtong ito ay nangyayari kapag nagsisimula ng isang build sa OpenShift platform.
Sa kaso ng isang imahe ng Web App Builder, responsable ito sa pag-install ng mga dependency ng iyong application at pagpapatakbo ng build. . Bilang default, ginagamit ng builder image ang npm run build construct, ngunit maaari itong ma-override sa pamamagitan ng NPM_BUILD environment variable.
Tulad ng sinabi namin kanina, ang lokasyon ng natapos, na binuo na application ay depende sa kung anong mga tool ang iyong ginagamit. Halimbawa, sa kaso ng React ito ang magiging ./build folder, at para sa mga Angular na application ito ang project_name/dist folder. At, tulad ng ipinakita sa nakaraang post, ang lokasyon ng direktoryo ng output, na nakatakdang buuin bilang default, ay maaaring ma-override sa pamamagitan ng OUTPUT_DIR environment variable. Well, dahil ang lokasyon ng output folder ay naiiba mula sa framework sa framework, kopyahin mo lang ang nabuong output sa karaniwang folder sa imahe, ibig sabihin /opt/apt-root/output. Ito ay mahalaga para sa pag-unawa sa natitirang bahagi ng artikulong ito, ngunit sa ngayon ay mabilis nating tingnan ang susunod na yugto - ang yugto ng pagtakbo.
yugto ng pagtakbo
Ang yugtong ito ay nangyayari kapag ang isang tawag sa docker run ay ginawa sa bagong larawang ginawa sa yugto ng pagpupulong. Ang parehong nangyayari kapag nagde-deploy sa OpenShift platform. Default gumagamit upang maghatid ng static na nilalaman na matatagpuan sa itaas na karaniwang direktoryo ng output.
Ang pamamaraang ito ay mabuti para sa mabilis na pag-deploy ng mga application, ngunit sa pangkalahatan ay hindi inirerekomenda na maghatid ng static na nilalaman sa ganitong paraan. Well, dahil sa katotohanan ay naghahatid lamang kami ng static na nilalaman, hindi namin kailangan na naka-install ang Node.js sa loob ng aming imahe - sapat na ang isang web server.
Sa madaling salita, kapag nag-assemble kailangan namin ng isang bagay, kapag nag-execute kailangan namin ng isa pa. Sa sitwasyong ito, madaling gamitin ang mga nakakadena na build.
Mga nakakadena na build
Ito ang kanilang isinusulat sa dokumentasyon ng OpenShift:
"Maaaring iugnay ang dalawang assemblies, na ang isa ay bumubuo ng isang pinagsama-samang entity at ang isa pang nagho-host ng entity na iyon sa isang hiwalay na larawan na ginagamit upang patakbuhin ang entity na iyon."
Sa madaling salita, maaari naming gamitin ang imahe ng Web App Builder upang patakbuhin ang aming build, at pagkatapos ay gamitin ang imahe ng web server, ang parehong NGINX, upang ihatid ang aming nilalaman.
Kaya, maaari naming gamitin ang imahe ng Tagabuo ng Web App bilang isang "purong" tagabuo at sa parehong oras ay may isang maliit na imahe ng runtime.
Ngayon tingnan natin ito sa isang tiyak na halimbawa.
Para sa pagsasanay ang gagamitin namin , na ginawa gamit ang create-react-app command line tool.
Makakatulong ito sa amin na pagsamahin ang lahat .
Tingnan natin ang file na ito nang mas detalyado, at magsimula sa seksyon ng mga parameter.
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
Ang lahat dito ay medyo malinaw, ngunit ito ay nagkakahalaga ng pagbibigay pansin sa OUTPUT_DIR parameter. Para sa React application sa aming halimbawa, walang dapat ipag-alala, dahil ginagamit ng React ang default na halaga bilang output folder, ngunit sa kaso ng Angular o iba pa, ang parameter na ito ay kailangang baguhin kung kinakailangan.
Ngayon tingnan natin ang seksyon ng Mga ImageStream.
- 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'
Tingnan ang ikatlo at ikaapat na larawan. Pareho silang tinukoy bilang mga imahe ng Docker, at malinaw mong makikita kung saan sila nanggaling.
Ang pangatlong larawan ay web-app-builder at nagmula ito sa nodeshift/ubi8-s2i-web-app na may tag na 10.x sa .
Ang ikaapat ay isang NGINX na imahe (bersyon 1.12) na may pinakabagong tag na naka-on .
Ngayon tingnan natin ang unang dalawang larawan. Pareho silang walang laman sa simula at nilikha lamang sa yugto ng pagbuo. Ang unang larawan, react-web-app-builder, ay magiging resulta ng isang hakbang sa pagpupulong na pagsasama-samahin ang web-app-builder-runtime na imahe at ang aming source code. Kaya naman nagdagdag kami ng "-builder" sa pangalan ng larawang ito.
Ang pangalawang larawan - react-web-app-runtime - ay magiging resulta ng pagsasama-sama ng nginx-image-runtime at ilang file mula sa react-web-app-builder na imahe. Gagamitin din ang larawang ito sa panahon ng deployment at maglalaman lamang ng web server at static na HTML, JavaScript, CSS ng aming application.
nalilito? Ngayon tingnan natin ang mga configuration ng build at magiging mas malinaw ito.
Ang aming template ay may dalawang build configuration. Narito ang una, at medyo karaniwan ito:
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
Gaya ng nakikita mo, ang linyang may label na 1 ay nagsasabing ang resulta ng build na ito ay ilalagay sa parehong react-web-app-builder na imahe na nakita namin kanina sa seksyong ImageStreams.
Ang linyang may label na 2 ay nagsasabi sa iyo kung saan kukuha ng code. Sa aming kaso, ito ay isang git repository, at ang lokasyon, ref at folder ng konteksto ay tinutukoy ng mga parameter na nakita na natin sa itaas.
Ang linya na may label na 3 ay kung ano ang nakita na namin sa seksyon ng mga parameter. Ito ay nagdaragdag ng OUTPUT_DIR environment variable, na sa aming halimbawa ay build.
Ang linyang may label na 4 ay nagsasabing gamitin ang web-app-builder-runtime na imahe, na nakita na namin sa seksyong ImageStream.
Sinasabi ng linyang may label na 5 na gusto naming gumamit ng incremental build kung sinusuportahan ito ng S2I image, at ang imahe ng Web App Builder. Sa unang paglulunsad, pagkatapos makumpleto ang yugto ng pagpupulong, ise-save ng imahe ang folder ng node_modules sa isang archive file. Pagkatapos, sa mga kasunod na pagtakbo, i-unzip lang ng imahe ang folder na ito upang bawasan ang oras ng pagbuo.
At sa wakas, ang linyang may label na 6 ay ilan lamang sa mga trigger para awtomatikong tumakbo ang build, nang walang manu-manong interbensyon, kapag may nagbago.
Sa pangkalahatan ito ay isang medyo karaniwang configuration ng build.
Ngayon tingnan natin ang pangalawang configuration ng build. Ito ay halos kapareho sa una, ngunit may isang mahalagang pagkakaiba.
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
Kaya ang pangalawang build configuration ay react-web-app-runtime, at ito ay nagsisimula sa medyo standard.
Ang linyang may label na 1 ay hindi bago - sinasabi lang nito na ang resulta ng pagbuo ay inilalagay sa react-web-app-runtime na imahe.
Ang linyang may label na 2, tulad ng sa nakaraang configuration, ay nagpapahiwatig kung saan kukuha ng source code. Ngunit pansinin na dito sinasabi namin na ito ay kinuha mula sa imahe. Bukod dito, mula sa larawan na kakalikha lang namin - mula sa react-web-app-builder (ipinahiwatig sa linya na may label na 3). Ang mga file na gusto naming gamitin ay nasa loob ng imahe at ang kanilang lokasyon doon ay nakatakda sa linya na may label na 4, sa aming kaso ito ay /opt/app-root/output/. Kung naaalala mo, dito nakaimbak ang mga file na nabuo batay sa mga resulta ng pagbuo ng aming application.
Ang patutunguhang folder na tinukoy sa terminong may label na 5 ay ang kasalukuyang direktoryo lamang (ito lang, tandaan, tumatakbo sa loob ng ilang mahiwagang bagay na tinatawag na OpenShift, at hindi sa iyong lokal na computer).
Ang seksyon ng diskarte - linya na may label na 6 - ay katulad din sa unang configuration ng build. Sa pagkakataong ito lamang gagamit tayo ng nginx-image-runtime, na nakita na natin sa seksyong ImageStream.
Panghuli, ang linyang may label na 7 ay isang seksyon ng mga trigger na mag-a-activate sa build na ito sa tuwing nagbabago ang react-web-app-builder na imahe.
Kung hindi, ang template na ito ay naglalaman ng medyo karaniwang configuration ng deployment, pati na rin ang mga bagay na nauugnay sa mga serbisyo at ruta, ngunit hindi na namin isasaalang-alang ang napakaraming detalyeng iyon. Pakitandaan na ang imaheng idi-deploy ay ang react-web-app-runtime na larawan.
Pag-deploy ng Application
Kaya ngayong tiningnan na natin ang template, tingnan natin kung paano ito gamitin para mag-deploy ng application.
Maaari naming gamitin ang OpenShift client tool na tinatawag na oc para i-deploy ang aming template:
$ 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
Ang unang command sa screenshot sa itaas ay isang sadyang inhinyero na paraan upang makahanap ng template./openshiftio/application.yaml.
Ang pangalawang command ay lumilikha lamang ng isang bagong application batay sa template na ito.
Matapos gumana ang mga utos na ito, makikita natin na mayroon tayong dalawang pagtitipon:
At pagbalik sa screen ng Pangkalahatang-ideya, makikita natin ang inilunsad na pod:
I-click ang link at dadalhin kami sa aming app, na siyang default na page ng React App:
Supplement 1
Para sa mga Angular lover meron din kami .
Ang pattern dito ay pareho, maliban sa OUTPUT_DIR variable.
Supplement 2
Sa artikulong ito ginamit namin ang NGINX bilang isang web server, ngunit medyo madali itong palitan ng Apache, baguhin lamang ang template sa file sa .
Konklusyon
Sa unang bahagi ng seryeng ito, ipinakita namin kung paano mabilis na mag-deploy ng mga modernong web application sa OpenShift platform. Ngayon ay tiningnan namin kung ano ang nagagawa ng isang imahe sa Web App at kung paano ito maisasama sa isang purong web server tulad ng NGINX gamit ang mga chained build upang lumikha ng isang mas handa na produksyon na pagbuo ng application. Sa susunod at huling artikulo sa seryeng ito, ipapakita namin kung paano magpatakbo ng development server para sa iyong application sa OpenShift at tiyakin ang pag-synchronize ng mga lokal at malayuang file.
Mga nilalaman ng seryeng ito ng mga artikulo
- Bahagi 1: ;
- Bahagi 2: Paano gumamit ng bagong larawan ng S2I na may kasalukuyang imahe ng HTTP server, gaya ng NGINX, gamit ang nauugnay na mga pagtitipon ng OpenShift para sa pag-deploy ng produksyon;
- Part 3: kung paano magpatakbo ng development server para sa iyong application sa OpenShift platform at i-synchronize ito sa lokal na file system.
Karagdagang Mga Mapagkukunan
- Libreng e-book .
- Impormasyon sa .
Pinagmulan: www.habr.com