Përshëndetje të gjithëve në këtë blog! Ky është postimi i tretë në seri, ku tregojmë se si të implementoni aplikacione web moderne në Red Hat OpenShift.
Në dy postimet e mëparshme, ne treguam se si të implementoni aplikacione web moderne në vetëm disa hapa dhe si të përdorni imazhin e ri S2I me një imazh të gatshëm të serverit HTTP, si NGINX me ndihmën e ndërlidhjeve të ndërlidhura për të organizuar implementimin në prodhim.
Sot do të tregojmë se si të lanconi një server zhvillimi për aplikacionin tuaj në platformën OpenShift dhe si ta sinkronizoni atë me sistemin tuaj lokal të skedarëve, si dhe do të flasim për çfarë është OpenShift Pipelines dhe si mund të përdoret si një alternativë ndaj ndërlidhjeve të ndërlidhura.
OpenShift si një ambient zhvillimi
Procesi i punës në zhvillim
Siç u tha në , procesi standard i zhvillimit për aplikacionet moderne web është thjesht një "server zhvillimi" që ndjek ndryshimet në skedarët lokalë. Kur ndodhin këto ndryshime, ndodh ndërtimi i aplikacionit dhe pastaj ato përditësohen në shfletues.
Në shumicën e frameworkeve moderne, një "server zhvillimi" është i përfshirë në veglat përkatëse të komandës.
Shembulli lokal
Fillimisht, le të shohim se si funksionon në rastin e ekzekutimit lokal të aplikacioneve. Si shembull, të marrim aplikacionin nga artikujt paraardhës, edhe pse pothuajse të njëjtat koncepte të procesit të punës zbatohen në të gjitha frameworket moderne.
Pra, për të nisur "serverin e zhvillimit" në shembullin tonë me React, do të shkruajmë komandën e mëposhtme:
$ npm run start
Në atë moment, në dritaren e terminalit do të kemi diçka të ngjashme:
Dhe aplikacioni ynë do të hapet në shfletuesin përkatës:
Tani, nëse bëjmë një ndryshim në skedarin, aplikacioni duhet të përditësohet në shfletues.
Mirë, për zhvillimin në modalitetin lokal është e qartë, por si ta arrijmë të njëjtën gjë në OpenShift?
Serveri i zhvillimit në OpenShift
Nëse e mbani mend, në , ne kemi diskutuar fazën e njohur si faza e nisjes (run phase) të imazhit S2I dhe kemi parë se në mënyrë të paracaktuar, mbajtja e aplikacionit tonë web kryhet nga moduli serve.
Megjithatë, nëse e shikoni më me kujdes nga ai shembull, ka një variabël ambienti $NPM_RUN, e cila lejon të ekzekutohet edhe komanda juaj.
Për shembull, 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
Vërejtje: shembulli më sipër jepet në një formë të shkurtuar për të ilustruar idenë e përgjithshme.
Këtu ne kemi shtuar në vendosjen tonë një variabël ambienti NPM_RUN, e cila i thotë fazës së ekzekutimit se duhet të nisë komandën yarn start, e cila nis serverin e zhvillimit React brenda pod-it tonë OpenShift.
Nëse shikoni log-un e pod-it që po punon, do të jetë diçka e tillë:
Sigurisht, gjithçka do të jetë e pavlerë deri sa të mund të sinkronizojmë kodin lokal me kodin, i cili gjithashtu kontrollohet për ndryshime, por jeton në një server të largët.
Sinkronizimi i kodit të largët dhe lokal
Fatkeqësisht, nodeshift ofron ndihmë të lehtë me sinkronizimin, dhe për të përcjellë ndryshimet, mund të përdorni komandën watch.
Prandaj, pas ekzekutimit të komandës për të dislokuar serverin e zhvillimit për aplikacionin tonë, mund ta përdorim me besim këtë komandë:
$ npx nodeshift watch
Si rezultat, do të lidhet me pod-in që krijuam pak më herët, aktivizohet sinkronizimi i skedarëve tanë lokalë me klasterin e largët, 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ë klasterin e largët dhe do të niste serverin e zhvillimit, i cili do të përditësojë aplikacionin tonë në shfletues.
Për të pasur një pamje të plotë, do të tregojmë si duken këto komanda në tërësi:
$ 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 watch është një abstraksion mbi komandën oc rsync, për t'u informuar më shumë se si funksionon, mund të mësoni. .
Ky ishte një shembull për React, por një metodë e tillë mund të përdoret po ashtu me frameworke të tjera, thjesht shkrini variablën e mjedisit NPM_RUN sipas nevojës.
â
Pipelinat Openshift Pipelines
Më pas do të flasim për një mjet të tillë si OpenShift Pipelines, dhe se si mund të përdoret si një alternativë për ndërlidhjet e ndërtimit chain build.
ĂfarĂ« Ă«shtĂ« OpenShift Pipelines
OpenShift Pipelines është një sistem CI/CD i orientuar drejt cloud-it për integrim dhe shpërndarje të vazhdueshme, i dedikuar për organizimin e pipelinave duke përdorur Tekton. Tekton është një framework CI/CD me kod të hapur, i natyrshëm për Kubernetes, që lejon automatizimin e publikimeve në platforma të ndryshme (Kubernetes, serverless, makina virtuale, etj.) duke e abstraktuar atë nga niveli i poshtëm.
Për të kuptuar këtë artikull janë të nevojshme disa njohuri mbi Pipelines, prandaj ju inkurajojmë që fillimisht të njiheni me .
Konfigurimi i ambientit të punës
Për t'u luajtur me shembujt nga ky artikull, së pari duhet të përgatitni ambientin e punës:
- Instaloni dhe konfiguroni një kluster OpenShift 4. Në shembujt tanë do të përdorim CodeReady Containers (CRD), për informacionin në lidhje me instalimin e të cilit mund të gjeni .
- Pasi klustri të jetë gati, duhet të instaloni Operatorin e Pipeline. Mos e keni frikë, është e lehtë, për udhëzimet e instalimit .
- Shkarko (tkn) .
- Startoni mjetin e komandës create-react-app për të krijuar një aplikacion, i cili më vonë do të implementohet (ky është një aplikacion i thjeshtë ).
- (Opcionale) Kloni repozitorin për të ekzekutuar lokalisht shembullin e aplikacionit me komandën npm install dhe pastaj npm start.
NĂ« repozitorin e aplikacionit gjithashtu do tĂ« ketĂ« njĂ« folder k8s, ku do tĂ« gjenden YAML-tĂ« pĂ«r Kubernetes/OpenShift, tĂ« pĂ«rdorura pĂ«r implementimin e aplikacionit. Aty do tĂ« jenĂ« Tasks, ClusterTasks, Resources dhe Pipelines, tĂ« cilat do tâi krijojmĂ« nĂ« kĂ«tĂ« .
Le të fillojmë
Më parë, për shembullin tonë, duhet të krijojmë një projekt të ri në klusterin OpenShift. Ta quajmë këtë projekt webapp-pipeline dhe ta krijojmë me komandën e mëposhtme:
$ oc new-project webapp-pipeline
Më vonë, ky emër projekti do të shfaqet në kod, prandaj nëse vendosni ta emërtoni ndryshe, mos harroni të ndryshoni përkatësisht kodin në shembuj. Duke filluar nga kjo pikë, do të shkojmë jo nga lart-poshtë, por nga poshtë-lart: domethënë, më parë do të krijojmë të gjitha përbërësit e tubacionit, dhe pastaj vetë tubacionin.
Pra, hapi i parĂ«âŠ
Detyrat Tasks
Do tĂ« krijojmĂ« disa detyra (tasks), tĂ« cilat mĂ« vonĂ« do tĂ« ndihmojnĂ« pĂ«r tĂ« shpĂ«rndarĂ« aplikacionin nĂ« kuadĂ«r tĂ« tubacionit tonĂ« pipeline. Detyra e parĂ« â apply_manifests_task â Ă«shtĂ« pĂ«rgjegjĂ«se pĂ«r aplikimin e YAML tĂ« burimeve Kubernetes (shĂ«rbimi, shpĂ«rndarja dhe rruga), tĂ« cilat ndodhen nĂ« dosjen k8s tĂ« aplikacionit tonĂ«. Detyra e dytĂ« â update_deployment_task â Ă«shtĂ« pĂ«rgjegjĂ«se pĂ«r pĂ«rditĂ«simin e imazhit tĂ« shpĂ«rndarĂ« tashmĂ« nĂ« atĂ« qĂ« krijohet nga tubacioni ynĂ«.
Mos u shqetĂ«soni nĂ«se ende nuk Ă«shtĂ« shumĂ« e qartĂ«. NĂ« tĂ« vĂ«rtetĂ«, kĂ«to detyra janĂ« si njĂ« lloj utiliteti, dhe ne do tâi shqyrtojmĂ« ato mĂ« nĂ« detaje pak mĂ« vonĂ«. Tani, le tĂ« 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, me ndihmën e komandës tkn CLI, do të kontrollojmë që detyrat u krijuan:
$ tkn task ls
EMRI MOSHA
apply-manifests 1 minutë më parë
update-deployment 1 minutë më parë
Shënim: këto janë detyrat lokale të projektit tuaj aktual.
Detyrat e klasterit
Detyrat e klasterit janë në thelb të njëjtat si detyrat e zakonshme. Kjo do të thotë se ato janë një koleksion i ripërdorshëm i hapave, të cilat kombinohen në një mënyrë ose në një tjetër kur ekzekutohet një detyrë specifike. Dallimi është se detyra e klasterit është e disponueshme kudo brenda klasterit. Për të parë listën e detyrave të klasterit, të cilat krijohen automatikisht duke shtuar Operatorin e Pipeline, do të përdorim përsëri komandën tkn CLI:
$ tkn clustertask ls
EMRI MOSHA
buildah 1 ditë më parë
buildah-v0-10-0 1 ditë më parë
jib-maven 1 ditë më parë
kn 1 ditë më parë
maven 1 ditë më parë
openshift-client 1 ditë më parë
openshift-client-v0-10-0 1 ditë më parë
s2i 1 ditë më parë
s2i-go 1 ditë më parë
s2i-go-v0-10-0 1 ditë më parë
s2i-java-11 1 ditë më parë
s2i-java-11-v0-10-0 1 ditë më parë
s2i-java-8 1 ditë më parë
s2i-java-8-v0-10-0 1 ditë më parë
s2i-nodejs 1 ditë më parë
s2i-nodejs-v0-10-0 1 ditë më parë
s2i-perl 1 ditë më parë
s2i-perl-v0-10-0 1 ditë më parë
s2i-php 1 ditë më parë
s2i-php-v0-10-0 1 ditë më parë
s2i-python-3 1 ditë më parë
s2i-python-3-v0-10-0 1 ditë më parë
s2i-ruby 1 ditë më parë
s2i-ruby-v0-10-0 1 ditë më parë
s2i-v0-10-0 1 ditë më parë
Tani le të krijojmë dy detyra klasterike. E para do të krijojë një imazh S2I dhe do ta dërgojë në regjistrin e brendshëm OpenShift; e dyta do të ekzekutojë ndërtimin e imazhit tonë mbi bazën e NGINX, duke përdorur si përmbajtje aplikacionin që e kemi ndërtuar më parë.
Krijojmë dhe dërgojmë imazh
Kur krijojmë detyrën e parë, do të përsërisim atë që bëmë në artikullin e mëparshëm mbi ndërlidhjet e ndërtimit. Të kujtojmë se ne përdorëm imazhin S2I (ubi8-s2i-web-app) për të "ndërtuar" aplikacionin tonë, dhe në fund morëm një imazh, i cili ruhej në regjistrin e brendshëm OpenShift. Tani do të përdorim këtë imazh S2I të aplikacionit web për të krijuar një DockerFile për aplikacionin tonë, dhe më pas do të angazhojmë Buildah për të kryer ndërtimin real dhe për të dërguar imazhin e marrë në regjistrin e brendshëm OpenShift, pasi kjo është saktësisht ajo që bën OpenShift kur ju vendosni aplikacionet tuaja duke përdorur NodeShift.
Po pyesni, nga e dimë të gjitha këto? Nga , ne thjesht e kopjuam atë dhe e përshtatëm për vete.
Kështu, tani krijojmë detyrën klasterike s2i-web-app:
$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/clustertasks/s2i-web-app-task.yaml
Nuk do të merremi me detaje të shumta rreth kësaj, por do të ndalemi vetëm te parametri OUTPUT_DIR:
params:
- name: OUTPUT_DIR
description: Vendi i drejtorisë së daljes së ndërtimit
default: build
Nga e drejta, ky parametr është i barabartë me build, dhe aty React ruan përmbajtjen e ndërtuar. Në kuadër të framework-ëve të tjerë përdoren rrugë të tjera, për shembull, në Ember kjo është dist. Të dhënat e detyrës sonë të parë klaster do të përbëhen nga një imazh, që përmban HTML-në, JavaScript dhe CSS-në që kemi mbledhur.
Krijojmë një imazh në bazë të NGINX
Sa i përket detyrës sonë të dytë klaster, ajo duhet të krijojë një imazh mbi bazën e NGINX, duke përdorur përmbajtjen e aplikacionit që kemi ndërtuar më parë. Në thelb, kjo është pjesa e atij kapitulli të mëparshëm, ku shqyrtuam ndërlidhjet e ndërtimit.
Për këtë, ne - pikërisht si më lart - do të krijojmë detyrën klaster 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ë grumbullit, do të vini re se nuk specifikohet depoja Git me të cilën punojmë, apo emrat e imazheve që krijojmë. Ne vetëm përcaktojmë se çfarë saktësisht po transferojmë në Git, ose ndonjë imazh, ku duhet të ruhet imazhi përfundimtar. Prandaj, këto detyra të grumbullit mund të ripërdoren edhe gjatë punës me aplikacione të tjera.
Dhe këtu kalojmë me elegancë në pikën tjetër...
Burimet
Pra, duke qenë se, siç sapo thamë, detyrat e grumbullit duhet të jenë sa më të përgjithshme, na nevojitet të krijojmë burime që do të përdoren në hyrje (depoja Git) dhe në 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 ka llojin git. ĂelĂ«si url nĂ« seksionin params tregon depozitat specifike dhe caktimin e degĂ«s master (kjo Ă«shtĂ« opsionale, por e shkruajmĂ« pĂ«r kompletim).
Tani na nevojitet të krijojmë një burim për imazhin, ku do të ruhen rezultatet e ekzekutimit të detyrës s2i-web-app; kjo bëhet kështu:
# 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 ka tipin image, dhe vlera e parametrave url tregon regjistrin e brendshëm të imazheve OpenShift, konkretisht atë që ndodhet në hapësirën e emrave webapp-pipeline. Mos harroni ta ndryshoni këtë parametrin nëse po përdorni një hapësirë tjetër emri.
Dhe, përfundimisht, burimi i fundit që do na nevojitet, gjithashtu do të ketë tipin image dhe ky do të jetë imazhi përfundimtar NGINX, i cili më pas do të përdoret gjatë implementimit:
# 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
Dhe përsëri, vini re se ky burim ruan imazhin në regjistrin e brendshëm OpenShift në hapësirën e emrave webapp-pipeline.
Për të krijuar të gjitha këto burime njëkohësisht, do të përdorim komandën create:
$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/resources/resource.yaml
Mund të verifikoni që burimet janë krijuar kështu:
$ tkn resource ls
Pipeline i konvejerit
Tani që kemi të gjitha përbërësit e nevojshëm, do ta ndërtrojmë konvejerin, 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, para se ta ekzekutojmĂ« kĂ«tĂ« komandĂ«, le tĂ« analizojmĂ« kĂ«ta pĂ«rbĂ«rĂ«s. I pari â Ă«shtĂ« emri:
apiVersion: tekton.dev/v1alpha1
kind: Pipeline
metadata:
name: build-and-deploy-react
Më pas, në seksionin spec shohim përcaktimin e burimeve që krijuam më parë:
spec:
burimet:
- emri: web-application-repo
lloji: git
- emri: built-web-application-image
lloji: image
- emri: runtime-web-application-image
lloji: image
Më pas krijojmë detyrat që do të ekzekutojë konvjeri ynë. E para që duhet të kryejë është detyra që e krijuam më parë, s2i-web-app:
detyrat:
- emri: build-web-application
taskRef:
emri: s2i-web-app
lloji: ClusterTask
Kjo detyrë merr parametrat hyrës (gir-burimi) dhe dalës (burimi built-web-application-image). Ne gjithashtu ia japim një parametër të veçantë që të mos verifikojë TLS, pasi po përdorim certifikata të vetë-nderuar:
burimet:
hyrjet:
- emri: source
burimi: web-application-repo
daljet:
- emri: image
burimi: built-web-application-image
parametrat:
- emri: TLSVERIFY
vlera: "false"
Detyra tjetër është pothuajse e njëjtë, vetëm se këtu thirret detyra tona klaster me emër webapp-build-runtime:
emri: build-runtime-image
taskRef:
emri: webapp-build-runtime
lloji: ClusterTask
Ashtu si me detyrën e mëparshme, ne transferojmë burimin, por tani kjo është built-web-application-image (dalja nga detyra jonë e mëparshme). Dhe si dalje, përsëri specifikojmë imazhin. Duke qenë se kjo detyrë duhet të ekzekutohet pas asaj paraprake, 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 aplikimin e skedarëve YAML për shërbimin, rrugën dhe implementimin, të cilët jetojnë në dosjen k8s të aplikacionit tonë web, si dhe për të përditësuar këtë implementim kur krijohen imazhe të reja. Këto dy detyra klasteri i kemi përcaktuar që në fillim të artikullit.
Ekzekutimi i konvejerit
Pra, të gjitha pjesët e konveyorëve tanë 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 komandave përdoret në mod të ndërveprimit dhe duhet të zgjidhni burimet përkatëse në përgjigje të çdo kërkese të saj: për burimin git zgjidhni web-application-repo, pastaj për burimin e parë të imazhit - built-web-application-image, dhe, në fund, 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 do të kontrollojmë statusin e pipeline-it duke përdorur komandën e mëposhtme:
$ tkn pipeline logs -f
Pasi të nisë pipeline-i dhe aplikacioni të jetë i instaluar, do ta kërkojmë rrugën e publikuar me komandën e mëposhtme:
$ oc get route react-pipeline-example --template='http://{{.spec.host}}'
Për më shumë vizibilitet, mund ta shikoni pipeline-n tonë në modalitetin Developer të konsolës së webit në seksionin Pipelines, ashtu siç tregohet në Fig. 1.
Fig. 1. Pasqyra e pipeline-ve të nisura.
Klikimi mbi pipeline-in e nisur tregon informacion shtesë, siç tregohet në Fig. 2.
Fig. 2. Informacion shtesë rreth pipeline-it.
Pas informacionit shtesë, mund të shikoni aplikacionet e nisura në pamjen Topology, siç tregohet në Fig. 3.
Fig. 3. Pod-i i nisur.
Klikimi mbi rrethin në këndin e sipërm të djathtë të ikonës hap aplikacionin tonë, siç tregohet në Fig. 4.
Fig. 4. Aplikacioni React i nisur.
PĂ«rfundimi
Pra, ne treguam se si të nisni në OpenShift një server zhvillimi për aplikacionin tuaj dhe ta sinkronizoni atë me sistemin lokal të skedave. Po ashtu, shqyrtuam se si të imitojmë template-n e chained-build me ndihmën e OpenShift Pipelines. Të gjitha kodet e shembujve nga ky artikull mund të gjenden në .
Burime të tjera (EN)
- E-libër falas
- Artikuj të tjerë mbi në faqen e Red Hat
Njoftimet për webinarët në vazhdim
Fillojmë një seri webinarësh të premtes mbi përvojën natyrore të përdorimit të Red Hat OpenShift Container Platform dhe Kubernetes:
Burimi: habr.com
