ProHoster > Blog > башкаруу > OpenShift боюнча заманбап тиркемелер, 3-бөлүк: OpenShift өнүктүрүү чөйрөсү жана OpenShift Pipelines катары
OpenShift боюнча заманбап тиркемелер, 3-бөлүк: OpenShift өнүктүрүү чөйрөсү жана OpenShift Pipelines катары
Бул блогдогу баарына салам! Бул Red Hat OpenShiftте заманбап веб-тиркемелерди кантип жайгаштырууну көрсөткөн катардагы үчүнчү пост.
Мурунку эки постто биз заманбап веб-тиркемелерди кантип бир нече кадам менен жайгаштырууну жана жаңы S2I сүрөтүн жана NGINX сыяктуу текчеден тышкаркы HTTP сервер сүрөтүн кантип колдонууну көрсөттүк. .
Бүгүн биз OpenShift платформасында тиркемеңиз үчүн иштеп чыгуу серверин кантип иштетүүнү жана аны локалдык файл системасы менен синхрондоштурууну көрсөтөбүз, ошондой эле OpenShift куурлары деген эмне жана аларды кантип байланышкан ассамблеяларга альтернатива катары колдонсо болору жөнүндө сүйлөшөбүз.
OpenShift өнүктүрүү чөйрөсү катары
Иштеп чыгуу процесси
Буга чейин айтылгандай биринчи пост, Заманбап веб-тиркемелерди иштеп чыгуунун типтүү процесси бул жөн гана жергиликтүү файлдардагы өзгөрүүлөргө көз салган кандайдыр бир “иштеп чыгуу сервери”. Алар пайда болгондо, тиркеменин түзүлүшү ишке киргизилет, андан кийин ал браузерге жаңыртылат.
Көпчүлүк заманбап алкактарда мындай "иштеп чыгуу сервери" тиешелүү буйрук сабынын куралдарына орнотулган.
Жергиликтүү мисал
Биринчиден, жергиликтүү тиркемелерди иштеткенде бул кандай иштээрин карап көрөлү. Мисал катары тиркемени алалы иш-аракет кылгыла мурунку макалалардан, бирок дээрлик бирдей иш процессинин түшүнүктөрү бардык башка заманбап алкактарда колдонулат.
Ошентип, биздин React мисалында "дев серверин" баштоо үчүн, биз төмөнкү буйрукту киргизебиз:
$ npm run start
Андан кийин терминал терезесинде биз бул сыяктуу нерсени көрөбүз:
Ал эми биздин колдонмо демейки браузерде ачылат:
Эми файлга өзгөртүүлөрдү киргизсек, колдонмо браузерде жаңыртылышы керек.
Макул, локалдык режимде иштеп чыгууда баары түшүнүктүү, бирок OpenShiftте ушундай нерсеге кантип жетсе болот?
OpenShift'те иштеп чыгуу сервери
Эсиңизде болсо, в мурунку пост, биз S2I сүрөтүнүн иштетүү фазасын карап көрдүк жана демейки боюнча тейлөө модулу биздин веб тиркемени тейлөө үчүн жооптуу экенин көрдүк.
Бирок, жакшылап карасаңыз скрипт иштетүү бул мисалдан, ал буйрукуңузду аткарууга мүмкүндүк берген $NPM_RUN чөйрө өзгөрмөсүн камтыйт.
Мисалы, биз колдонмону жайылтуу үчүн nodeshift модулун колдоно алабыз:
Эскертүү: Жогорудагы мисал жалпы ойду көрсөтүү үчүн кыскартылган.
Бул жерде биз жайылтуубузга NPM_RUN чөйрө өзгөрмөсүн коштук, ал биздин OpenShift подъездибиздин ичиндеги React иштеп чыгуу серверин иштете турган жипти баштоо буйругун иштетүү убактысын айтат.
Эгер сиз иштеп жаткан поддондун журналын карасаңыз, ал төмөнкүдөй көрүнөт:
Албетте, мунун баары биз локалдык кодду код менен синхрондоштурууга чейин эч нерсе болбойт, ал да өзгөртүүлөр үчүн көзөмөлдөнөт, бирок алыскы серверде жашайт.
Алыскы жана жергиликтүү кодду синхрондоштуруу
Бактыга жараша, nodeshift синхрондоштурууга оңой жардам берет жана өзгөрүүлөргө көз салуу үчүн саат буйругун колдоно аласыз.
Ошентип, биз колдонмобуз үчүн иштеп чыгуу серверин жайылтуу буйругун аткаргандан кийин, биз төмөнкү буйрукту коопсуз колдоно алабыз:
$ npx nodeshift watch
Натыйжада, биз бир аз мурун түзүлгөн иштеп жаткан подколь менен байланыш түзүлөт, биздин локалдык файлдарыбызды алыскы кластер менен синхрондоштуруу иштетилет жана биздин локалдык системабыздагы файлдар өзгөрүүлөргө көзөмөлгө алынат.
Ошондуктан, эгерде биз азыр src/App.js файлын жаңырта турган болсок, система бул өзгөрүүлөргө реакция кылып, аларды алыскы кластерге көчүрүп, иштеп чыгуу серверин ишке киргизет, андан кийин браузерде биздин тиркемени жаңылайт.
Сүрөттү толуктоо үчүн, келгиле, бул буйруктардын баары кандай экенин көрсөтөлү:
Саат буйругу бул oc rsync буйругунун үстүндөгү абстракция, анын кантип иштээри жөнүндө көбүрөөк биле аласыз бул жерде.
Бул React үчүн үлгү болгон, бирок так эле ыкманы башка алкактар менен колдонсо болот, жөн гана NPM_RUN чөйрө өзгөрмөсүн зарылчылыкка жараша коюңуз.
Openshift куурлары
Андан кийин биз OpenShift Pipelines сыяктуу курал жөнүндө жана аны чынжырланган курулуштарга альтернатива катары кантип колдонсо болору жөнүндө сүйлөшөбүз.
OpenShift куурлары деген эмне
OpenShift Pipelines - бул Tekton аркылуу түтүктөрдү уюштуруу үчүн иштелип чыккан CI/CD үзгүлтүксүз интеграциялоо жана жеткирүү системасы. Tekton ийкемдүү ачык булактуу Kubernetes CI/CD фреймворк болуп саналат, ал негизги катмардан абстракциялоо менен ар кандай платформаларда (Кубернетес, серверсиз, виртуалдык машиналар ж.б.) жайылтууну автоматташтырууга мүмкүндүк берет.
Бул макаланы түшүнүү үчүн Pipelines жөнүндө бир аз билим талап кылынат, андыктан алгач окууну сунуштайбыз расмий окуу китеби.
Жумуш чөйрөңүздү орнотуу
Бул макаладагы мисалдар менен ойноо үчүн, адегенде иш чөйрөңүздү даярдашыңыз керек:
OpenShift 4 кластерин орнотуңуз жана конфигурациялаңыз. Биздин мисалдар бул үчүн CodeReady Контейнерлерин (CRD) колдонушат, орнотуу нускамаларын табууга болот. бул жерде.
Кластер даяр болгондон кийин, ага Pipeline операторун орнотуу керек. Коркпоңуз, бул оңой, орнотуу көрсөтмөлөрү бул жерде.
Андан кийин орното турган тиркемени түзүү үчүн create-react-app буйрук сабын иштетиңиз (бул жөнөкөй колдонмо иш-аракет кылгыла).
(Милдеттүү эмес) npm орнотуу жана андан кийин npm баштоо менен жергиликтүү үлгү тиркемесин иштетүү үчүн репозиторийди клондоңуз.
Колдонмо репозиторийинде ошондой эле k8s папкасы болот, анда тиркемени жайылтуу үчүн колдонулган Kubernetes/OpenShift YAMLs камтылат. Бул жерде биз түзө турган тапшырмалар, кластердик тапшырмалар, ресурстар жана түтүктөр болот репозиторийлер.
Келиңиз баштайлы
Биздин мисал үчүн биринчи кадам OpenShift кластеринде жаңы долбоорду түзүү болуп саналат. Келгиле, бул долбоорду webapp-pipeline деп атайлы жана аны төмөнкү буйрук менен түзөлү:
$ oc new-project webapp-pipeline
Бул долбоордун аталышы кийинчерээк коддо пайда болот, андыктан эгер сиз аны башка нерсе деп атасаңыз, мисал кодду ошого жараша түзөтүүнү унутпаңыз. Ушул жерден баштап, биз жогортон ылдый эмес, теменден жогору карай баратабыз: башкача айтканда, биз адегенде конвейердин бардык тетиктерин, андан кийин гана конвейердин езун тузебуз.
Ошентип, биринчи кезекте ...
Tasks
Келгиле, бир-эки тапшырманы түзөлү, алар андан кийин колдонмону биздин түтүктө жайгаштырууга жардам берет. Биринчи тапшырма - apply_manifests_task - биздин тиркеменин k8s папкасында жайгашкан Kubernetes ресурстарынын (кызмат, жайылтуу жана маршрут) YAML колдонуу үчүн жооптуу. Экинчи милдет – update_deployment_task – мурунтан эле орнотулган сүрөттү биздин куур аркылуу түзүлгөн сүрөткө жаңыртуу үчүн жооптуу.
Эгер ал азырынча так эмес болсо, кабатыр болбоңуз. Чынында, бул милдеттер коммуналдык сыяктуу бир нерсе, жана биз аларды бир аз кийинчерээк кененирээк карап чыгабыз. Азырынча аларды түзөлү:
Андан кийин, tkn CLI буйругун колдонуп, биз тапшырмалар түзүлгөнүн текшеребиз:
$ tkn task ls
NAME AGE
apply-manifests 1 minute ago
update-deployment 1 minute ago
Эскертүү: Бул сиздин учурдагы долбооруңуз үчүн жергиликтүү тапшырмалар.
Кластердик тапшырмалар
Кластердик тапшырмалар негизинен жөнөкөй тапшырмалар менен бирдей. Башкача айтканда, бул белгилүү бир тапшырманы аткарууда тигил же бул жол менен айкалышкан кадамдардын көп жолу колдонулуучу жыйындысы. Айырмачылыгы кластердин тапшырмасы кластердин бардык жеринде жеткиликтүү. Түтүк операторун кошууда автоматтык түрдө түзүлгөн кластердик тапшырмалардын тизмесин көрүү үчүн биз tkn CLI буйругун кайра колдонобуз:
$ tkn clustertask ls
NAME AGE
buildah 1 day ago
buildah-v0-10-0 1 day ago
jib-maven 1 day ago
kn 1 day ago
maven 1 day ago
openshift-client 1 day ago
openshift-client-v0-10-0 1 day ago
s2i 1 day ago
s2i-go 1 day ago
s2i-go-v0-10-0 1 day ago
s2i-java-11 1 day ago
s2i-java-11-v0-10-0 1 day ago
s2i-java-8 1 day ago
s2i-java-8-v0-10-0 1 day ago
s2i-nodejs 1 day ago
s2i-nodejs-v0-10-0 1 day ago
s2i-perl 1 day ago
s2i-perl-v0-10-0 1 day ago
s2i-php 1 day ago
s2i-php-v0-10-0 1 day ago
s2i-python-3 1 day ago
s2i-python-3-v0-10-0 1 day ago
s2i-ruby 1 day ago
s2i-ruby-v0-10-0 1 day ago
s2i-v0-10-0 1 day ago
Эми эки кластер тапшырмасын түзөлү. Биринчиси S2I сүрөтүн жаратат жана аны ички OpenShift реестрине жөнөтөт; экинчиси, биз мазмун катары курган тиркемени колдонуп, NGINX негизинде имиджин түзүү.
Сүрөттү түзүп, жөнөтүңүз
Биринчи тапшырманы түзүп жатканда, биз мурунку макалада байланышкан ассамблеялар жөнүндө кылганыбызды кайталайбыз. Эсиңиздерге сала кетсек, биз S2I сүрөтүн (ubi8-s2i-web-app) тиркемени "куруу" үчүн колдонгон жана OpenShift ички реестринде сакталган сүрөт менен аяктаганбыз. Эми биз бул S2I веб колдонмосунун сүрөтүн колдонмобуз үчүн DockerFile түзүү үчүн колдонобуз, андан кийин анык түзүүнү аткаруу үчүн Buildah колдонобуз жана алынган сүрөттү OpenShift ички реестрине түртөбүз, анткени сиз NodeShift аркылуу тиркемелериңизди жайгаштырганда OpenShift дал ушундай кылат. .
Мунун баарын биз кайдан билдик, деп сурайсыңбы? From расмий Node.js расмий версиясы, биз аны жөн эле көчүрүп, өзүбүз үчүн өзгөрттүк.
Биз муну майда-чүйдөсүнө чейин талдабайбыз, бирок OUTPUT_DIR параметрине гана көңүл бурабыз:
params:
- name: OUTPUT_DIR
description: The location of the build output directory
default: build
Демейки боюнча, бул параметр курууга барабар, ал жерде React чогулган мазмунду коёт. Башка алкактар ар кандай жолдорду колдонушат, мисалы, Emberде ал dist. Биринчи кластердик тапшырмабыздын жыйынтыгы биз чогулткан HTML, JavaScript жана CSS камтыган сүрөт болот.
NGINX негизинде сүрөт түзүңүз
Экинчи кластердик тапшырмабызга келсек, ал биз үчүн мурунтан эле курган тиркеменин мазмунун колдонуп, NGINX негизиндеги сүрөттү түзүшү керек. Негизинен, бул биз чынжырланган курулуштарды караган мурунку бөлүмдүн бөлүгү.
Бул үчүн, биз - жогорудагыдай эле - кластердик тапшырманы түзөбүз webapp-build-runtime:
Бул кластердик тапшырмалардын кодун карасаңыз, анда биз иштеп жаткан Git репозиторий же биз түзүп жаткан сүрөттөрдүн аталыштары көрсөтүлбөгөнүн көрө аласыз. Биз Gitке так эмнени өткөрүп жатканыбызды же акыркы сүрөт чыгышы керек болгон белгилүү бир сүрөттү гана көрсөтөбүз. Ошондуктан бул кластердик тапшырмаларды башка тиркемелер менен иштөөдө кайра колдонсо болот.
Мына, биз акырындык менен кийинки пунктка өтөбүз ...
ресурстары
Ошентип, биз айтып өткөндөй, кластердик тапшырмалар мүмкүн болушунча жалпы болушу керек, биз кириш (Git репозиторий) жана чыгаруу (акыркы сүрөттөр) катары колдонула турган ресурстарды түзүшүбүз керек. Бизге керек болгон биринчи ресурс бул биздин тиркеме жайгашкан Git, мисалы:
# This resource is the location of the git repo with the web application source
apiVersion: tekton.dev/v1alpha1
kind: PipelineResource
metadata:
name: web-application-repo
spec:
type: git
params:
- name: url
value: https://github.com/nodeshift-starters/react-pipeline-example
- name: revision
value: master
Бул жерде PipelineResource git түрү. Params бөлүмүндөгү url ачкычы белгилүү бир репозиторийди көрсөтүп, башкы бутагын көрсөтөт (бул милдеттүү эмес, бирок биз аны толуктоо үчүн жазабыз).
Эми биз s2i-web-app тапшырмасынын натыйжалары сактала турган сүрөт үчүн ресурсту түзүшүбүз керек, бул төмөнкүдөй жасалат:
# This resource is the result of running "npm run build", the resulting built files will be located in /opt/app-root/output
apiVersion: tekton.dev/v1alpha1
kind: PipelineResource
metadata:
name: built-web-application-image
spec:
type: image
params:
- name: url
value: image-registry.openshift-image-registry.svc:5000/webapp-pipeline/built-web-application:latest
Бул жерде PipelineResource сүрөт түрү жана url параметринин мааниси ички OpenShift Сүрөт реестрине, атап айтканда, webapp-труба аттар мейкиндигинде жайгашканга ишарат кылат. Башка ат мейкиндигин колдонуп жатсаңыз, бул жөндөөнү өзгөртүүнү унутпаңыз.
Акыр-аягы, бизге керек болгон акыркы ресурс дагы типтеги сүрөт болот жана бул жайгаштыруу учурунда колдонула турган акыркы NGINX сүрөтү болот:
# This resource is the image that will be just the static html, css, js files being run with nginx
apiVersion: tekton.dev/v1alpha1
kind: PipelineResource
metadata:
name: runtime-web-application-image
spec:
type: image
params:
- name: url
value: image-registry.openshift-image-registry.svc:5000/webapp-pipeline/runtime-web-application:latest
Дагы бир жолу, бул ресурс сүрөттү webapp-түтүк мейкиндигинде ички OpenShift реестринде сактай турганын эске алыңыз.
Бардык бул ресурстарды бир эле учурда түзүү үчүн, биз түзүү буйругун колдонобуз:
Андан кийин биз куурубуз аягына чыгышы керек болгон тапшырмаларды түзөбүз. Биринчиден, ал биз буга чейин түзгөн s2i-web-app тапшырмасын аткарышы керек:
Бул тапшырма киргизүү (gir ресурсу) жана чыгаруу (курулган веб-тиркеме-сүрөт ресурсу) параметрлерин алат. Ошондой эле биз ага атайын параметрди өткөрүп беребиз, андыктан ал TLSти текшербейт, анткени биз өз алдынча кол коюлган сертификаттарды колдонуп жатабыз:
Мурунку тапшырмадагыдай эле, биз ресурста өтөбүз, бирок азыр ал курулган веб-тиркеме-сүрөт (мурунку тапшырмабыздын жыйынтыгы). Жана чыгаруу катары биз кайрадан сүрөттү орноттук. Бул тапшырма мурункудан кийин аткарылышы керек болгондуктан, биз runAfter талаасын кошобуз:
Кийинки эки тапшырма биздин веб-тиркемебиздин k8s каталогунда жашаган кызматты, маршрутту жана жайылтуу YAML файлдарын колдонууга, ошондой эле жаңы сүрөттөрдү түзүүдө бул жайгаштырууну жаңылоого жооптуу. Бул эки кластердик тапшырманы макаланын башында аныктадык.
Конвейерди ишке киргизүү
Ошентип, биздин түтүктүн бардык бөлүктөрү түзүлдү жана биз аны төмөнкү буйрук менен иштетебиз:
$ tkn pipeline start build-and-deploy-react
Бул этапта, буйрук сабы интерактивдүү колдонулат жана анын ар бир суроосуна жооп катары тиешелүү ресурстарды тандоо керек: git ресурсу үчүн web-application-repo, анан биринчи сүрөт ресурсу үчүн, курулган веб-тиркеме тандаңыз. -сүрөт, жана акырында, экинчи сүрөт булагы үчүн - runtime-web-application-image:
? Choose the git resource to use for web-application-repo: web-application-repo (https://github.com/nodeshift-starters/react-pipeline-example)
? Choose the image resource to use for built-web-application-image: built-web-application-image (image-registry.openshift-image-registry.svc:5000/webapp-pipeline/built-web-
application:latest)
? Choose the image resource to use for runtime-web-application-image: runtime-web-application-image (image-registry.openshift-image-registry.svc:5000/webapp-pipeline/runtim
e-web-application:latest)
Pipelinerun started: build-and-deploy-react-run-4xwsr
Эми төмөнкү буйрукту колдонуу менен түтүктүн абалын текшерип көрөлү:
$ tkn pipeline logs -f
Түтүк ишке киргизилгенден кийин жана колдонмо орнотулгандан кийин, биз төмөнкү буйрук менен жарыяланган маршрутту сурай алабыз:
$ oc get route react-pipeline-example --template='http://{{.spec.host}}'
Көбүрөөк визуалдаштыруу үчүн, бөлүмдөгү веб консолдун Иштеп чыгуучу режиминде биздин түтүктү көрө аласыз түтүктөр, Сүрөттө көрсөтүлгөндөй. 1.
Fig.1. Иштеп жаткан түтүктөрдү карап чыгуу.
Иштеп жаткан түтүктү чыкылдатуу 2-сүрөттө көрсөтүлгөндөй кошумча маалыматтарды көрсөтөт.
Райс. 2. Түтүк өткөргүч жөнүндө кошумча маалымат.
Көбүрөөк маалымат алгандан кийин, көрүнүштө иштеп жаткан колдонмолорду көрө аласыз топология, Fig.3 көрсөтүлгөндөй.
Fig 3. Ишке киргизилген поддон.
Пиктограмманын жогорку оң бурчундагы тегерекчеге чыкылдатуу 4-сүрөттө көрсөтүлгөндөй биздин тиркемени ачат.
Райс. 4. React тиркемесин иштетүү.
жыйынтыктоо
Ошентип, биз OpenShiftдеги тиркемеңиз үчүн иштеп чыгуу серверин кантип иштетип, аны жергиликтүү файл системасы менен синхрондоштурууну көрсөттүк. Биз ошондой эле OpenShift Pipelines аркылуу чынжырланган куруу шаблонуна окшоштурууну карап чыктык. Бул макаладагы бардык мисал коддору тапса болот бул жерде.