Përshëndetje të gjithëve në këtë blog! Ky është postimi i tretë në një seri në të cilën ne tregojmë se si të vendosim aplikacione moderne në internet në Red Hat OpenShift.
Në dy postimet e mëparshme, ne treguam se si të vendosim aplikacione moderne në internet në vetëm disa hapa dhe si të përdorim një imazh të ri S2I së bashku me një imazh të serverit HTTP jashtë raftit, siç është NGINX, duke përdorur ndërtime të lidhura me zinxhir për të orkestruar vendosjet e prodhimit .
Sot do të tregojmë se si të ekzekutoni një server zhvillimi për aplikacionin tuaj në platformën OpenShift dhe ta sinkronizoni atë me sistemin lokal të skedarëve, dhe gjithashtu do të flasim për atë që janë tubacionet OpenShift dhe si mund të përdoren si një alternativë ndaj asambleve të lidhura.
OpenShift si një mjedis zhvillimi
Rrjedha e punës së zhvillimit
Siç është thënë tashmë në , procesi tipik i zhvillimit për aplikacionet moderne në internet është thjesht një lloj "serveri zhvillimi" që gjurmon ndryshimet në skedarët lokalë. Kur ato ndodhin, ndërtimi i aplikacionit aktivizohet dhe më pas përditësohet në shfletues.
Në shumicën e kornizave moderne, një "server zhvillimi" i tillë është ndërtuar në mjetet përkatëse të linjës së komandës.
Shembull lokal
Së pari, le të shohim se si funksionon kjo kur ekzekutohen aplikacionet në nivel lokal. Le të marrim aplikacionin si shembull nga artikujt e mëparshëm, megjithëse pothuajse të njëjtat koncepte të rrjedhës së punës zbatohen në të gjitha kornizat e tjera moderne.
Pra, për të nisur "serverin dev" në shembullin tonë React, ne do të futim komandën e mëposhtme:
$ npm run start
Pastaj në dritaren e terminalit do të shohim diçka të tillë:
Dhe aplikacioni ynë do të hapet në shfletuesin e paracaktuar:
Tani, nëse bëjmë ndryshime në skedar, aplikacioni duhet të përditësohet në shfletues.
OK, gjithçka është e qartë me zhvillimin në modalitetin lokal, por si ta arrijmë të njëjtën gjë në OpenShift?
Serveri i zhvillimit në OpenShift
Nëse ju kujtohet, në , ne shikuam të ashtuquajturën fazë të ekzekutimit të imazhit S2I dhe pamë që si parazgjedhje, moduli i shërbimit është përgjegjës për shërbimin e aplikacionit tonë në ueb.
Megjithatë, nëse shikoni më nga afër nga ai shembull, ai përmban ndryshoren e mjedisit $NPM_RUN, e cila ju lejon të ekzekutoni komandën tuaj.
Për shembull, ne mund të përdorim modulin nodeshift për të vendosur aplikacionin tonë:
$ npx nodeshift --deploy.env NPM_RUN="yarn start" --dockerImage=nodeshift/ubi8-s2i-web-app
Shënim: Shembulli i mësipërm është shkurtuar për të ilustruar idenë e përgjithshme.
Këtu kemi shtuar variablin e mjedisit NPM_RUN në vendosjen tonë, i cili i tregon kohës së ekzekutimit të ekzekutojë komandën e fillimit të fillit, e cila fillon serverin e zhvillimit React brenda pod tonë të OpenShift.
Nëse shikoni regjistrin e një pod vrapimi, do të duket diçka si kjo:
Natyrisht, e gjithë kjo nuk do të jetë asgjë derisa të mund të sinkronizojmë kodin lokal me kodin, i cili gjithashtu monitorohet për ndryshime, por jeton në një server të largët.
Sinkronizimi i kodit në distancë dhe atij lokal
Për fat të mirë, nodeshift mund të ndihmojë lehtësisht me sinkronizimin dhe ju mund të përdorni komandën e orës për të gjurmuar ndryshimet.
Pra, pasi të kemi ekzekutuar komandën për të vendosur serverin e zhvillimit për aplikacionin tonë, ne mund të përdorim me siguri komandën e mëposhtme:
$ npx nodeshift watch
Si rezultat, do të bëhet një lidhje me podin e ekzekutimit që krijuam pak më herët, do të aktivizohet sinkronizimi i skedarëve tanë lokalë me grupin në distancë dhe skedarët në sistemin tonë lokal do të fillojnë të monitorohen për ndryshime.
Prandaj, nëse tani përditësojmë skedarin src/App.js, sistemi do të reagojë ndaj këtyre ndryshimeve, do t'i kopjojë ato në grupin e largët dhe do të nisë serverin e zhvillimit, i cili më pas do të përditësojë aplikacionin tonë në shfletues.
Për të përfunduar figurën, le të tregojmë se si duken të gjitha këto komanda:
$ npx nodeshift --strictSSL=false --dockerImage=nodeshift/ubi8-s2i-web-app --build.env YARN_ENABLED=true --expose --deploy.env NPM_RUN="yarn start" --deploy.port 3000
$ npx nodeshift watch --strictSSL=false
Komanda e orës është një abstraksion në krye të komandës oc rsync, mund të mësoni më shumë se si funksionon .
Ky ishte një shembull për React, por saktësisht e njëjta metodë mund të përdoret me korniza të tjera, thjesht vendosni ndryshoren e mjedisit NPM_RUN sipas nevojës.
Tubacionet Openshift
Më pas do të flasim për një mjet si OpenShift Pipelines dhe se si mund të përdoret si një alternativë ndaj ndërtimeve me zinxhirë.
Çfarë janë tubacionet OpenShift
OpenShift Pipelines është një sistem integrimi dhe dërgimi i vazhdueshëm CI/CD i bazuar në cloud i krijuar për organizimin e tubacioneve duke përdorur Tekton. Tekton është një kornizë fleksibël CI/CD me burim të hapur Kubernetes që ju lejon të automatizoni vendosjen në platforma të ndryshme (Kubernetes, pa server, makina virtuale, etj.) duke abstraguar nga shtresa bazë.
Kuptimi i këtij artikulli kërkon disa njohuri për Pipelines, kështu që ju rekomandojmë fuqimisht që së pari të lexoni .
Vendosja e mjedisit tuaj të punës
Për të luajtur me shembujt në këtë artikull, së pari duhet të përgatisni mjedisin tuaj të punës:
- Instaloni dhe konfiguroni një grup OpenShift 4. Shembujt tanë përdorin CodeReady Containers (CRD) për këtë, udhëzimet e instalimit për të cilat mund të gjenden .
- Pasi grupi të jetë gati, duhet të instaloni Operatorin e tubacionit në të. Mos kini frikë, është e lehtë, udhëzime instalimi .
- Shkarko (tkn) .
- Ekzekutoni mjetin e linjës së komandës Creative-react-app për të krijuar një aplikacion që do ta vendosni më pas (ky është një aplikacion i thjeshtë ).
- (Opsionale) Klononi depon për të ekzekutuar aplikacionin shembull në nivel lokal me instalimin npm dhe më pas fillimin npm.
Depoja e aplikacionit do të ketë gjithashtu një dosje k8s, e cila do të përmbajë Kubernetes/OpenShift YAML të përdorura për të vendosur aplikacionin. Do të ketë Tasks, ClusterTasks, Resources dhe Pipelines të cilat ne do t'i krijojmë në këtë .
Le të fillojmë
Hapi i parë për shembullin tonë është krijimi i një projekti të ri në grupin OpenShift. Le ta quajmë këtë projekt webapp-pipeline dhe ta krijojmë atë me komandën e mëposhtme:
$ oc new-project webapp-pipeline
Ky emër projekti do të shfaqet në kod më vonë, kështu që nëse vendosni ta emërtoni diçka tjetër, mos harroni të modifikoni kodin e shembullit në përputhje me rrethanat. Duke u nisur nga kjo pikë, ne nuk do të shkojmë nga lart-poshtë, por nga poshtë-lart: domethënë, së pari do të krijojmë të gjithë përbërësit e transportuesit dhe vetëm më pas vetë transportuesin.
Pra, para së gjithash...
Detyrat
Le të krijojmë disa detyra, të cilat më pas do të ndihmojnë në vendosjen e aplikacionit brenda tubacionit tonë. Detyra e parë - apply_manifests_task - është përgjegjëse për aplikimin e YAML të atyre burimeve të Kubernetes (shërbim, vendosje dhe rrugë) që ndodhen në dosjen k8s të aplikacionit tonë. Detyra e dytë - update_deployment_task - është përgjegjëse për përditësimin e një imazhi tashmë të vendosur në atë të krijuar nga tubacioni ynë.
Mos u shqetësoni nëse nuk është ende shumë e qartë. Në fakt, këto detyra janë diçka si shërbime, dhe ne do t'i shikojmë ato në mënyrë më të detajuar pak më vonë. Tani për tani, le t'i krijojmë ato:
$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/tasks/update_deployment_task.yaml
$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/tasks/apply_manifests_task.yaml
Pastaj, duke përdorur komandën tkn CLI, do të kontrollojmë që detyrat janë krijuar:
$ tkn task ls
NAME AGE
apply-manifests 1 minute ago
update-deployment 1 minute ago
Shënim: Këto janë detyra lokale për projektin tuaj aktual.
Detyrat e grupit
Detyrat e grupit janë në thelb të njëjta me detyrat e thjeshta. Kjo do të thotë, është një koleksion hapash i ripërdorshëm që kombinohen në një mënyrë ose në një tjetër gjatë ekzekutimit të një detyre specifike. Dallimi është se një detyrë e grupit është e disponueshme kudo brenda grupit. Për të parë listën e detyrave të grupimit që krijohen automatikisht kur shtojmë Operatorin e tubacionit, ne do të përdorim përsëri komandën 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
Tani le të krijojmë dy detyra grupore. E para do të gjenerojë imazhin S2I dhe do ta dërgojë atë në regjistrin e brendshëm të OpenShift; e dyta është të ndërtojmë imazhin tonë bazuar në NGINX, duke përdorur aplikacionin që kemi ndërtuar tashmë si përmbajtje.
Krijoni dhe dërgoni imazhin
Kur krijojmë detyrën e parë, ne do të përsërisim atë që kemi bërë tashmë në artikullin e mëparshëm në lidhje me asambletë e lidhura. Kujtoni që ne përdorëm imazhin S2I (ubi8-s2i-web-app) për të "ndërtuar" aplikacionin tonë dhe përfunduam me një imazh të ruajtur në regjistrin e brendshëm OpenShift. Tani ne do të përdorim këtë imazh të aplikacionit në internet S2I për të krijuar një DockerFile për aplikacionin tonë dhe më pas do të përdorim Buildah për të bërë ndërtimin aktual dhe për të shtyrë imazhin që rezulton në regjistrin e brendshëm OpenShift, pasi kjo është pikërisht ajo që bën OpenShift kur vendosni aplikacionet tuaja duke përdorur NodeShift. .
Si i dinim të gjitha këto, ju pyesni? Nga , thjesht e kopjuam dhe e modifikuam për vete.
Pra, tani le të krijojmë detyrën e grupit të aplikacioneve s2i-web:
$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/clustertasks/s2i-web-app-task.yaml
Ne nuk do ta analizojmë këtë në detaje, por do të fokusohemi vetëm në parametrin OUTPUT_DIR:
params:
- name: OUTPUT_DIR
description: The location of the build output directory
default: build
Si parazgjedhje, ky parametër është i barabartë me ndërtimin, ku React vendos përmbajtjen e mbledhur. Korniza të tjera përdorin shtigje të ndryshme, për shembull, në Ember është dist. Rezultati i detyrës sonë të parë të grupimit do të jetë një imazh që përmban HTML, JavaScript dhe CSS që kemi mbledhur.
Ndërtoni një imazh të bazuar në NGINX
Sa i përket detyrës sonë të dytë të grupimit, ajo duhet të ndërtojë një imazh të bazuar në NGINX për ne, duke përdorur përmbajtjen e aplikacionit që kemi ndërtuar tashmë. Në thelb, kjo është pjesa e seksionit të mëparshëm ku ne shikuam ndërtimet me zinxhirë.
Për ta bërë këtë, ne - saktësisht njësoj si më lart - do të krijojmë një detyrë grupi webapp-build-runtime:
$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/clustertasks/webapp-build-runtime-task.yaml
Nëse shikoni kodin e këtyre detyrave të grupimit, mund të shihni se ai nuk specifikon depon e Git me të cilën po punojmë ose emrat e imazheve që po krijojmë. Ne vetëm specifikojmë se çfarë saktësisht po transferojmë në Git, ose një imazh të caktuar ku duhet të dalë imazhi përfundimtar. Kjo është arsyeja pse këto detyra grupore mund të ripërdoren kur punoni me aplikacione të tjera.
Dhe këtu kalojmë me hijeshi në pikën tjetër...
burime
Pra, meqenëse, siç thamë sapo, detyrat e grupimeve duhet të jenë sa më të përgjithshme të jetë e mundur, ne duhet të krijojmë burime që do të përdoren si hyrje (depo Git) dhe si dalje (imazhet përfundimtare). Burimi i parë që na nevojitet është Git, ku ndodhet aplikacioni ynë, diçka si kjo:
# 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
Këtu PipelineResource është i llojit git. Tasti url në seksionin e parametrave tregon një depo specifike dhe specifikon degën kryesore (kjo është opsionale, por ne e shkruajmë për plotësi).
Tani duhet të krijojmë një burim për imazhin ku do të ruhen rezultatet e detyrës s2i-web-app, kjo bëhet si kjo:
# 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
Këtu, PipelineResource është i tipit imazh dhe vlera e parametrit url tregon në Regjistrin e brendshëm të imazheve OpenShift, veçanërisht atë që ndodhet në hapësirën e emrave të aplikacionit të uebit. Mos harroni ta ndryshoni këtë cilësim nëse jeni duke përdorur një hapësirë tjetër emri.
Dhe së fundi, burimi i fundit që na nevojitet do të jetë gjithashtu i llojit imazh dhe ky do të jetë imazhi përfundimtar NGINX që më pas do të përdoret gjatë vendosjes:
# 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
Përsëri, vini re se ky burim ruan imazhin në regjistrin e brendshëm të OpenShift në hapësirën e emrave të uebapp-pipeline.
Për të krijuar të gjitha këto burime menjëherë, ne përdorim komandën krijimin:
$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/resources/resource.yaml
Mund të siguroheni që burimet janë krijuar si kjo:
$ tkn resource ls
Tubacioni transportues
Tani që kemi të gjithë komponentët e nevojshëm, le të mbledhim një tubacion prej tyre duke e krijuar atë me komandën e mëposhtme:
$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/pipelines/build-and-deploy-react.yaml
Por përpara se të ekzekutojmë këtë komandë, le të shohim këta komponentë. E para është emri:
apiVersion: tekton.dev/v1alpha1
kind: Pipeline
metadata:
name: build-and-deploy-react
Pastaj në seksionin e specifikimeve shohim një tregues të burimeve që krijuam më herët:
spec:
resources:
- name: web-application-repo
type: git
- name: built-web-application-image
type: image
- name: runtime-web-application-image
type: image
Më pas ne krijojmë detyrat që tubacioni ynë duhet të përfundojë. Para së gjithash, duhet të ekzekutojë detyrën s2i-web-app që kemi krijuar tashmë:
tasks:
- name: build-web-application
taskRef:
name: s2i-web-app
kind: ClusterTask
Kjo detyrë merr parametrat hyrës (burim gir) dhe dalje (burim i ndërtuar-web-application-imazh). Ne i kalojmë gjithashtu një parametër të veçantë në mënyrë që të mos verifikojë TLS pasi ne përdorim certifikata të vetë-nënshkruara:
resources:
inputs:
- name: source
resource: web-application-repo
outputs:
- name: image
resource: built-web-application-image
params:
- name: TLSVERIFY
value: "false"
Detyra tjetër është pothuajse e njëjtë, vetëm këtu detyra e grupit webapp-build-runtime që kemi krijuar tashmë quhet:
name: build-runtime-image
taskRef:
name: webapp-build-runtime
kind: ClusterTask
Ashtu si me detyrën e mëparshme, ne kalojmë në një burim, por tani është ndërtuar-web-application-image (dalja e detyrës sonë të mëparshme). Dhe si rezultat ne vendosëm përsëri imazhin. Meqenëse kjo detyrë duhet të ekzekutohet pas asaj të mëparshme, ne shtojmë fushën runAfter:
resources:
inputs:
- name: image
resource: built-web-application-image
outputs:
- name: image
resource: runtime-web-application-image
params:
- name: TLSVERIFY
value: "false"
runAfter:
- build-web-application
Dy detyrat e ardhshme janë përgjegjëse për përdorimin e shërbimit, rrugës dhe vendosjes së skedarëve YAML që jetojnë në drejtorinë k8s të aplikacionit tonë në ueb, si dhe për përditësimin e kësaj vendosjeje kur krijoni imazhe të reja. Ne përcaktuam këto dy detyra grupore në fillim të artikullit.
Nisja e transportuesit
Pra, të gjitha pjesët e tubacionit tonë janë krijuar dhe ne do ta ekzekutojmë atë me komandën e mëposhtme:
$ tkn pipeline start build-and-deploy-react
Në këtë fazë, linja e komandës përdoret në mënyrë interaktive dhe ju duhet të zgjidhni burimet e duhura në përgjigje të secilës prej kërkesave të saj: për burimin git, zgjidhni web-application-repo, pastaj për burimin e parë të imazhit, aplikacionin e ndërtuar në internet. -image, dhe së fundi, për burimin e dytë të imazhit –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
Tani le të kontrollojmë statusin e tubacionit duke përdorur komandën e mëposhtme:
$ tkn pipeline logs -f
Pasi të ketë filluar tubacioni dhe aplikacioni të jetë vendosur, ne mund të kërkojmë rrugën e publikuar me komandën e mëposhtme:
$ oc get route react-pipeline-example --template='http://{{.spec.host}}'
Për vizualizim më të madh, mund të shikoni tubacionin tonë në modalitetin Zhvillues të konsolës së uebit në seksion tubacionet, siç tregohet në Fig. 1.
Fig.1. Rishikimi i tubacioneve rrjedhëse.
Duke klikuar në një tubacion që funksionon, shfaqen detaje shtesë, siç tregohet në Figurën 2.
Oriz. 2. Informacion shtesë rreth tubacionit.
Pas më shumë informacioneve, mund të shihni aplikacionet që ekzekutohen në pamje Topologji, siç tregohet në Fig.3.
Fig 3. Pod i nisur.
Duke klikuar në rrethin në këndin e sipërm djathtas të ikonës hapet aplikacioni ynë, siç tregohet në Fig. 4.
Oriz. 4. Ekzekutimi i aplikacionit React.
Përfundim
Pra, ne treguam se si të ekzekutoni një server zhvillimi për aplikacionin tuaj në OpenShift dhe ta sinkronizoni atë me sistemin lokal të skedarëve. Ne shikuam gjithashtu se si të simulojmë një shabllon të ndërtuar me zinxhirë duke përdorur OpenShift Pipelines. Të gjitha kodet e shembujve nga ky artikull mund të gjenden .
Burime shtesë (EN)
- Libër elektronik falas
- Artikuj të tjerë në në faqen e internetit të Red Hat
Njoftimet për webinarët e ardhshëm
Ne po fillojmë një seri uebinaresh të së premtes rreth përvojës vendase duke përdorur platformën e kontejnerëve të Red Hat OpenShift dhe Kubernetes:
Burimi: www.habr.com