Баарына салам! Бул Red Hat OpenShiftте заманбап веб-тиркемелерди кантип жайгаштырууну көрсөткөн сериябыздагы экинчи пост.
Мурунку постто биз OpenShift платформасында заманбап веб-тиркемелерди куруу жана жайылтуу үчүн иштелип чыккан жаңы S2I (булактан сүрөт) куруучу сүрөтүнүн мүмкүнчүлүктөрүнө бир аз токтолдук. Андан кийин биз тиркемени тез жайылтуу темасына кызыкканбыз жана бүгүн биз S2I сүрөтүн "таза" куруучу сүрөтү катары кантип колдонууну жана аны OpenShift менен байланышкан жыйындар менен айкалыштырууну карап чыгабыз.
Таза куруучунун сүрөтү
XNUMX-бөлүктө айтылгандай, заманбап веб-тиркемелердин көпчүлүгүн куруу баскычы деп аталат, ал адатта кодду которуу, бир нече файлды бириктирүү жана кичирейтүү сыяктуу операцияларды аткарат. Бул операциялардын натыйжасында алынган файлдар - бул статикалык HTML, JavaScript жана CSS - чыгаруу папкасында сакталат. Бул папканын жайгашкан жери көбүнчө кандай куруу куралдары колдонулуп жатканына жараша болот, ал эми React үчүн бул ./build папкасы болот (биз буга төмөндө кененирээк кайрылып келебиз).
Булактан сүрөткө (S2I)
Бул постто биз "S2I деген эмне жана аны кантип колдонуу керек" деген темага токтолбойбуз (бул тууралуу кененирээк окуй аласыз ), бирок Web App Builder сүрөтү эмне кыларын түшүнүү үчүн бул процесстин эки кадамын так билүү маанилүү.
Чогултуу фазасы
Монтаж фазасы табияты боюнча сиз докер курууну иштетип, жаңы Docker сүрөтү менен аяктаганыңызга абдан окшош. Демек, бул этап OpenShift платформасында курууну баштаганда пайда болот.
Web App Builder сүрөтү болгон учурда, ал колдонмоңуздун көз карандылыктарын орнотуу жана курууну иштетүү үчүн жооптуу. . Демейки боюнча, куруучунун сүрөтү npm run build конструкциясын колдонот, бирок муну NPM_BUILD чөйрө өзгөрмөсү аркылуу жокко чыгарууга болот.
Жогоруда айтылгандай, даяр, мурунтан эле курулган тиркеменин жайгашкан жери сиз колдонгон куралдардан көз каранды. Мисалы, React учурда бул ./build папкасы болот, ал эми Angular колдонмолору үчүн бул project_name/dist папкасы болот. Ал эми, мурунку постто көрсөтүлгөндөй, демейки боюнча курууга коюлган чыгаруу каталогунун орду OUTPUT_DIR чөйрө өзгөрмөсү аркылуу жокко чыгарылат. Ооба, чыгаруу папкасынын жайгашкан жери алкактан алкактарга айырмалангандыктан, сиз жөн гана өндүрүлгөн чыгарууну сүрөттөгү стандарттуу папкага көчүрөсүз, тактап айтканда /opt/apt-root/output. Бул макаланын калган бөлүгүн түшүнүү үчүн маанилүү, бирок азыр кийинки этапты - чуркоо фазасын карап көрөлү.
иштетүү фазасы
Бул этап монтаж стадиясында түзүлгөн жаңы сүрөттөлүштө докерди иштетүүгө чакыруу жасалганда пайда болот. OpenShift платформасында жайылтууда да ушундай болот. Демейки колдонуу жогорудагы стандарттык чыгаруу каталогунда жайгашкан статикалык мазмунду тейлөө үчүн.
Бул ыкма колдонмолорду тез жайылтуу үчүн жакшы, бирок статикалык мазмунду ушундай жол менен тейлөө сунушталбайт. Чындыгында биз статикалык мазмунду гана тейлегендиктен, сүрөтүбүзгө орнотулган Node.js кереги жок - веб-сервер жетиштүү болот.
Башкача айтканда, монтаждоодо бир нерсе керек, аткарууда башка нерсе керек. Бул жагдайда, чынжырчалуу курулуштар жардамга келет.
Чынжырланган курулуштар
Бул тууралуу алар жазышат OpenShift документтеринде:
"Эки ассамблеяны бириктирсе болот, алардын бири компиляцияланган объектти түзсө, экинчиси ошол объектти иштетүү үчүн колдонулган өзүнчө сүрөттөлүштө жайгашкан."
Башкача айтканда, биз түзмөгүбүздү иштетүү үчүн Web App Builder сүрөтүн колдонсок болот, андан кийин мазмунубузду тейлөө үчүн ошол эле NGINX веб-серверинин сүрөтүн колдоно алабыз.
Ошентип, биз Web App Builder сүрөтүн "таза" куруучу катары колдоно алабыз жана ошол эле учурда кичинекей иштөө убактысынын сүрөтүнө ээ болобуз.
Эми муну конкреттүү мисал менен карап көрөлү.
Тренинг үчүн биз колдонобуз , create-react-app буйрук сабынын куралы аркылуу түзүлгөн.
Бул бизге бардыгын бириктирүүгө жардам берет .
Келгиле, бул файлды кененирээк карап көрөлү жана параметрлер бөлүмү менен баштайлы.
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
Бул жерде баары түшүнүктүү, бирок OUTPUT_DIR параметрине көңүл буруш керек. Биздин мисалдагы React тиркемеси үчүн тынчсыздана турган эч нерсе жок, анткени React чыгуучу папка катары демейки маанини колдонот, бирок Angular же башка бир нерсе болсо, бул параметрди зарылчылыкка жараша өзгөртүү керек болот.
Эми 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'
Үчүнчү жана төртүнчү сүрөттөрдү карап көрүңүз. Экөө тең Docker сүрөттөрү катары аныкталган жана алардын кайдан келгенин так көрө аласыз.
Үчүнчү сүрөт веб-колдонмо куруучу жана ал nodeshift/ubi8-s2i-web-app 10.x тегинен келет .
Төртүнчүсү - акыркы теги менен NGINX сүрөтү (1.12 версиясы). .
Эми биринчи эки сүрөттү карап көрөлү. Башында экөө тең бош жана куруу баскычында гана түзүлөт. Биринчи сүрөт, react-web-app-builder, веб-колдонмо куруучу-иш убагы сүрөтүн жана биздин баштапкы кодду бириктирген жыйын кадамынын натыйжасы болот. Ошондуктан бул сүрөттүн атына “-Builder” дегенди коштук.
Экинчи сүрөт - react-web-app-runtime - nginx-image-runtime жана react-web-app-Builder сүрөтүндөгү кээ бир файлдарды бириктирүүнүн натыйжасы болот. Бул сүрөт жайгаштыруу учурунда да колдонулат жана биздин колдонмонун веб-серверин жана статикалык HTML, JavaScript, CSS'ти гана камтыйт.
Чаташып калдыңызбы? Эми куруу конфигурацияларын карап көрөлү жана ал бир аз айкыныраак болот.
Биздин шаблондо эки конфигурация бар. Бул жерде биринчиси жана ал абдан стандарттуу:
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
Көрүнүп тургандай, 1 энбелгиси бар сызык бул куруунун натыйжасы ImageStreams бөлүмүндө биз бир аз мурда көргөн реактивдүү веб-тиркеме куруучу сүрөтүндө жайгаштырылат деп айтылат.
2 деп белгиленген сызык кодду кайдан алуу керектигин айтат. Биздин учурда, бул git репозиторий жана жайгашкан жери, рефлекси жана контексттик папка биз жогоруда көргөн параметрлер менен аныкталат.
3 деп белгиленген сызык - бул биз параметрлер бөлүмүндө көргөн нерсе. Ал OUTPUT_DIR чөйрө өзгөрмөсүн кошот, ал биздин мисалда түзүлөт.
4 деп белгиленген сызык биз ImageStream бөлүмүндө көргөн web-app-builder-runtime сүрөтүн колдонууну айтат.
5 деп белгиленген сапта S2I сүрөтү аны колдосо жана Web App Builder сүрөтү колдосо, биз кошумча түзүүнү колдонгубуз келет деп айтылат. Биринчи ишке киргизүүдө, чогултуу баскычы аяктагандан кийин, сүрөт node_modules папкасын архивдик файлга сактайт. Андан кийин, кийинки иштетүүдө, сүрөт куруу убактысын кыскартуу үчүн бул папканы ачып берет.
Акыр-аягы, 6 деп белгиленген сызык бир нерсе өзгөргөндө кол менен кийлигишүүсүз автоматтык түрдө түзүүнү ишке ашыруу үчүн бир нече триггерлер.
Жалпысынан алганда, бул абдан стандарттуу куруу конфигурациясы.
Эми экинчи куруу конфигурациясын карап көрөлү. Бул биринчи бирине абдан окшош, бирок бир маанилүү айырма бар.
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
Ошентип, экинчи куруу конфигурациясы реакция-web-app-runtime болуп саналат жана ал абдан стандарттуу башталат.
1 деп белгиленген сызык жаңы эч нерсе эмес - ал жөн гана куруунун натыйжасы react-web-app-runtime сүрөтүнө коюларын айтат.
Мурунку конфигурациядагыдай 2 деп белгиленген сап баштапкы кодду кайдан алуу керектигин көрсөтөт. Бирок байкасаңыз, бул жерде сүрөттөн алынган деп айтып жатабыз. Мындан тышкары, биз жаңы эле жараткан сүрөттөн - react-web-app-builder'ден (3 деп белгиленген сапта көрсөтүлгөн). Биз колдонгубуз келген файлдар сүрөттүн ичинде жана алардын жайгашкан жери 4 деп белгиленген сапта белгиленген, биздин учурда бул /opt/app-root/output/. Эсиңизде болсо, бул жерде биздин тиркемени куруунун натыйжалары боюнча түзүлгөн файлдар сакталат.
Терминде көрсөтүлгөн көздөгөн папка 5 энбелгиси менен жөн гана учурдагы каталог (бул баары, эсиңизде болсун, OpenShift деп аталган сыйкырдуу нерсенин ичинде иштейт, ал эми жергиликтүү компьютериңизде эмес).
Стратегия бөлүмү - 6 деп белгиленген сызык - ошондой эле биринчи куруу конфигурациясына окшош. Бул жолу гана биз ImageStream бөлүмүндө көргөн nginx-image-runtime колдонобуз.
Акыр-аягы, 7 деп белгиленген сызык триггерлердин бир бөлүгү болуп саналат, ал реактивдүү веб-тиркеме куруучунун сүрөтү өзгөргөн сайын бул түзүүнү активдештирет.
Болбосо, бул шаблондо абдан стандарттуу жайгаштыруу конфигурациялары, ошондой эле кызматтарга жана маршруттарга тиешелүү нерселер камтылган, бирок биз анчалык деле майда-чүйдөсүнө чейин кирбейбиз. Жайгаштырыла турган сүрөт реакция-веб-колдонмо-иш убактысынын сүрөтү экенин эске алыңыз.
Колдонмону жайылтуу
Эми биз шаблонду карап чыккандан кийин, аны тиркемени жайылтуу үчүн кантип колдонсо болорун карап көрөлү.
Биз шаблонубузду жайгаштыруу үчүн oc деп аталган OpenShift кардар куралын колдоно алабыз:
$ 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
Жогорудагы скриншоттогу биринчи буйрук шаблонду табуу үчүн атайын инженердик ыкма./openshiftio/application.yaml.
Экинчи буйрук жөн гана ушул шаблондун негизинде жаңы тиркемени түзөт.
Бул буйруктар иштегенден кийин, бизде эки ассамблея бар экенин көрөбүз:
Жана Обзор экранына кайтып келгенде, биз ишке киргизилген подкукту көрөбүз:
Шилтемени чыкылдатыңыз жана биз биздин колдонмобузга өтөбүз, бул демейки React App бети:
Кошумча 1
Бурчтук сүйүүчүлөр үчүн бизде да бар .
Бул жерде үлгү OUTPUT_DIR өзгөрмөсүнөн башкасы бирдей.
Кошумча 2
Бул макалада биз NGINXти веб-сервер катары колдондук, бирок аны Apache менен алмаштыруу оңой, жөн гана файлдагы шаблонду өзгөртүңүз боюнча .
жыйынтыктоо
Бул сериянын биринчи бөлүгүндө биз OpenShift платформасында заманбап веб-тиркемелерди кантип тез жайгаштырууну көрсөттүк. Бүгүн биз Web App сүрөтү эмне кыларын жана аны NGINX сыяктуу таза веб-сервер менен кантип айкалыштырса болорун карап чыктык, бул өндүрүшкө даяр тиркеме түзүмүн түзүү үчүн чынжырланган түзүлүштөрдү колдонуу менен. Бул сериядагы кийинки жана акыркы макалада биз OpenShiftдеги тиркемеңиз үчүн иштеп чыгуу серверин кантип иштетүүнү жана жергиликтүү жана алыскы файлдарды синхрондоштурууну камсыз кылууну көрсөтөбүз.
Бул макалалар сериясынын мазмуну
- 1 бөлүк: ;
- 2-бөлүк: Өндүрүштү жайылтуу үчүн байланышкан OpenShift жыйындарын колдонуу менен NGINX сыяктуу болгон HTTP сервер сүрөтү менен жаңы S2I сүрөтүн кантип колдонуу керек;
- 3-бөлүк: OpenShift платформасында колдонмоңуз үчүн иштеп чыгуу серверин кантип иштетүү жана аны жергиликтүү файл системасы менен синхрондоштуруу.
Кошумча ресурстар
- Акысыз электрондук китеп .
- Маалымат .
Source: www.habr.com