Hallo almal op hierdie blog! Dit is die derde pos in 'n reeks waarin ons wys hoe om moderne webtoepassings op Red Hat OpenShift te ontplooi.
In die vorige twee plasings het ons gewys hoe om moderne webtoepassings in net 'n paar stappe te ontplooi en hoe om 'n nuwe S2I-beeld te gebruik saam met 'n off-the-shelf HTTP-bedienerbeeld, soos NGINX, met behulp van gekettingde bouwerk om produksie-ontplooiings te orkestreer .
Ons sal vandag wys hoe om 'n ontwikkelingsbediener vir jou toepassing op die OpenShift-platform te laat loop en dit met die plaaslike lêerstelsel te sinchroniseer, en ook praat oor wat OpenShift Pipelines is en hoe dit as 'n alternatief vir gekoppelde samestellings gebruik kan word.
OpenShift as 'n ontwikkelingsomgewing
Ontwikkelingswerkvloei
Soos reeds vermeld in , is die tipiese ontwikkelingsproses vir moderne webtoepassings bloot 'n soort "ontwikkelingsbediener" wat veranderinge aan plaaslike lêers naspoor. Wanneer hulle voorkom, word die toepassingsbou geaktiveer en dan word dit na die blaaier opgedateer.
In die meeste moderne raamwerke is so 'n "ontwikkelingsbediener" in die ooreenstemmende opdragreëlnutsgoed ingebou.
Plaaslike voorbeeld
Kom ons kyk eers hoe dit werk wanneer toepassings plaaslik uitgevoer word. Kom ons neem die toepassing as 'n voorbeeld van vorige artikels, hoewel byna dieselfde werkvloeikonsepte in alle ander moderne raamwerke geld.
Dus, om die "dev-bediener" in ons React-voorbeeld te begin, voer ons die volgende opdrag in:
$ npm run start
Dan sal ons in die terminale venster iets soos hierdie sien:
En ons toepassing sal in die verstekblaaier oopmaak:
Nou, as ons veranderinge aan die lêer maak, moet die toepassing in die blaaier opdateer.
OK, alles is duidelik met ontwikkeling in plaaslike modus, maar hoe om dieselfde op OpenShift te bereik?
Ontwikkelingsbediener op OpenShift
As jy onthou, in , het ons na die sogenaamde hardloopfase van die S2I-beeld gekyk en gesien dat die diensmodule by verstek verantwoordelik is vir die diens van ons webtoepassing.
As jy egter van nader kyk uit daardie voorbeeld bevat dit die $NPM_RUN omgewingsveranderlike, wat jou toelaat om jou opdrag uit te voer.
Ons kan byvoorbeeld die nodeshift-module gebruik om ons toepassing te ontplooi:
$ npx nodeshift --deploy.env NPM_RUN="yarn start" --dockerImage=nodeshift/ubi8-s2i-web-app
Let wel: Die voorbeeld hierbo is afgekort om die algemene idee te illustreer.
Hier het ons die NPM_RUN-omgewingsveranderlike by ons ontplooiing gevoeg, wat die looptyd vertel om die yarn start-opdrag uit te voer, wat die React-ontwikkelingsbediener binne ons OpenShift-pod begin.
As jy na die logboek van 'n lopende peul kyk, sal dit iets soos volg lyk:
Natuurlik sal dit alles niks wees totdat ons die plaaslike kode met die kode kan sinchroniseer, wat ook vir veranderinge gemonitor word, maar op 'n afgeleë bediener woon.
Sinchroniseer afgeleë en plaaslike kode
Gelukkig kan nodeshift maklik help met sinchronisasie, en jy kan die horlosie-opdrag gebruik om veranderinge op te spoor.
So nadat ons die opdrag uitgevoer het om die ontwikkelingsbediener vir ons toepassing te ontplooi, kan ons die volgende opdrag veilig gebruik:
$ npx nodeshift watch
As gevolg hiervan, sal 'n verbinding gemaak word met die lopende pod wat ons 'n bietjie vroeër geskep het, die sinchronisasie van ons plaaslike lêers met die afgeleë groepering sal geaktiveer word, en die lêers op ons plaaslike stelsel sal begin om gemonitor te word vir veranderinge.
As ons dus nou die src/App.js-lêer opdateer, sal die stelsel op hierdie veranderinge reageer, dit na die afgeleë groepering kopieer en die ontwikkelingsbediener begin, wat dan ons toepassing in die blaaier sal opdateer.
Om die prentjie te voltooi, kom ons wys hoe hierdie hele opdragte lyk:
$ 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
Die watch-opdrag is 'n abstraksie bo-op die oc rsync-opdrag, jy kan meer leer oor hoe dit werk .
Dit was 'n voorbeeld vir React, maar presies dieselfde metode kan met ander raamwerke gebruik word, stel net die NPM_RUN omgewingsveranderlike soos nodig.
Openshift pyplyne
Volgende sal ons praat oor 'n instrument soos OpenShift Pipelines en hoe dit as 'n alternatief vir vasgekettings gebruik kan word.
Wat is OpenShift Pipelines
OpenShift Pipelines is 'n wolk-inheemse CI/CD deurlopende integrasie en afleweringstelsel wat ontwerp is vir die organisering van pyplyne met Tekton. Tekton is 'n buigsame oopbron Kubernetes-inheemse CI/CD-raamwerk wat jou toelaat om ontplooiing op verskeie platforms (Kubernetes, bedienerlose, virtuele masjiene, ens.) te outomatiseer deur te onttrek van die onderliggende laag.
Om hierdie artikel te verstaan vereis 'n mate van kennis van Pipelines, so ons beveel sterk aan dat jy eers lees .
Die opstel van jou werksomgewing
Om met die voorbeelde in hierdie artikel te speel, moet jy eers jou werksomgewing voorberei:
- Installeer en konfigureer 'n OpenShift 4-kluster. Ons voorbeelde gebruik CodeReady Containers (CRD) hiervoor, waarvoor installasie-instruksies gevind kan word .
- Nadat die groep gereed is, moet jy Pipeline Operator daarop installeer. Moenie bang wees nie, dit is maklik, installasie-instruksies .
- Aflaai (tkn) .
- Begin die create-react-app-opdragreëlnutsding om 'n toepassing te skep wat u dan sal ontplooi (dit is 'n eenvoudige toepassing ).
- (Opsioneel) Kloon die bewaarplek om die voorbeeldtoepassing plaaslik te laat loop met npm install en dan npm start.
Die toepassingsbewaarplek sal ook 'n k8s-lêergids hê, wat die Kubernetes/OpenShift YAML's sal bevat wat gebruik word om die toepassing te ontplooi. Daar sal Take, ClusterTasks, Hulpbronne en Pyplyne wees wat ons hierin sal skep .
Aan die gang kom
Die eerste stap vir ons voorbeeld is om 'n nuwe projek in die OpenShift-kluster te skep. Kom ons noem hierdie projek webapp-pipeline en skep dit met die volgende opdrag:
$ oc new-project webapp-pipeline
Hierdie projeknaam sal later in die kode verskyn, so as jy besluit om dit iets anders te noem, moenie vergeet om die voorbeeldkode dienooreenkomstig te wysig nie. Vanaf hierdie punt gaan ons nie van bo af nie, maar onder na bo: dit wil sê, ons sal eers al die komponente van die vervoerband skep, en eers dan die vervoerband self.
So, eerstens...
Take
Kom ons skep 'n paar take, wat dan sal help om die toepassing binne ons pyplyn te ontplooi. Die eerste taak - application_manifests_task - is verantwoordelik vir die toepassing van die YAML van daardie Kubernetes-hulpbronne (diens, ontplooiing en roete) wat in die k8s-lêergids van ons toepassing geleë is. Die tweede taak – update_deployment_task – is verantwoordelik vir die opdatering van 'n reeds ontplooide prent na die een wat deur ons pyplyn geskep is.
Moenie bekommerd wees as dit nog nie baie duidelik is nie. Trouens, hierdie take is iets soos nutsprogramme, en ons sal 'n bietjie later in meer detail daarna kyk. Kom ons skep hulle vir eers:
$ 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
Dan, met behulp van die tkn CLI-opdrag, sal ons seker maak dat die take geskep is:
$ tkn task ls
NAME AGE
apply-manifests 1 minute ago
update-deployment 1 minute ago
Let wel: Dit is plaaslike take vir jou huidige projek.
Groepering take
Groeptake is basies dieselfde as eenvoudige take. Dit wil sê, dit is 'n herbruikbare versameling stappe wat op een of ander manier gekombineer word wanneer 'n spesifieke taak uitgevoer word. Die verskil is dat 'n klustertaak oral in die cluster beskikbaar is. Om die lys van groeptake te sien wat outomaties geskep word wanneer pyplynoperateur bygevoeg word, sal ons weer die tkn CLI-opdrag gebruik:
$ 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
Kom ons skep nou twee groeptake. Die eerste sal die S2I-beeld genereer en dit na die interne OpenShift-register stuur; die tweede is om ons beeld te bou gebaseer op NGINX, met behulp van die toepassing wat ons reeds as inhoud gebou het.
Skep en stuur die prent
Wanneer ons die eerste taak skep, sal ons herhaal wat ons reeds in die vorige artikel oor gekoppelde samestellings gedoen het. Onthou dat ons die S2I-beeld (ubi8-s2i-web-app) gebruik het om ons toepassing te "bou", en het uiteindelik met 'n prent gestoor in die OpenShift-interne register. Nou sal ons hierdie S2I-webtoepassingprent gebruik om 'n DockerFile vir ons toepassing te skep en dan Buildah gebruik om die werklike bou te doen en die resulterende prent na die OpenShift interne register te stoot, aangesien dit presies is wat OpenShift doen wanneer u u toepassings met NodeShift ontplooi .
Hoe het ons dit alles geweet, vra jy? Van , ons het dit net gekopieer en dit vir onsself verander.
So, laat ons nou die s2i-web-app-klustertaak skep:
$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/clustertasks/s2i-web-app-task.yaml
Ons sal dit nie in detail ontleed nie, maar sal slegs fokus op die OUTPUT_DIR parameter:
params:
- name: OUTPUT_DIR
description: The location of the build output directory
default: build
By verstek is hierdie parameter gelyk aan bou, dit is waar React die saamgestelde inhoud plaas. Ander raamwerke gebruik verskillende paaie, byvoorbeeld, in Ember is dit dist. Die uitvoer van ons eerste groepstaak sal 'n prent wees wat die HTML, JavaScript en CSS bevat wat ons versamel het.
Bou 'n prent gebaseer op NGINX
Wat ons tweede groeptaak betref, moet dit 'n NGINX-gebaseerde beeld vir ons bou, met behulp van die inhoud van die toepassing wat ons reeds gebou het. In wese is dit die deel van die vorige afdeling waar ons na gekettingde bouwerk gekyk het.
Om dit te doen, sal ons - presies dieselfde as net hierbo - 'n groeptaak skep webapp-build-runtime:
$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/clustertasks/webapp-build-runtime-task.yaml
As u na die kode van hierdie groeptake kyk, kan u sien dat dit nie die Git-bewaarplek waarmee ons werk of die name van die beelde wat ons skep, spesifiseer nie. Ons spesifiseer net presies wat ons na Git oordra, of 'n sekere prent waar die finale prent uitgevoer moet word. Daarom kan hierdie groeptake hergebruik word wanneer met ander toepassings gewerk word.
En hier gaan ons grasieus aan na die volgende punt...
Ресурсы
Dus, aangesien, soos ons pas gesê het, groepstake so algemeen as moontlik moet wees, moet ons hulpbronne skep wat as invoer (die Git-bewaarplek) en as uitvoer (die finale beelde) gebruik sal word. Die eerste hulpbron wat ons nodig het, is Git, waar ons toepassing is, iets soos hierdie:
# 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
Hier is PipelineResource van die tipe git. Die url-sleutel in die params-afdeling wys na 'n spesifieke bewaarplek en spesifiseer die meestertak (dit is opsioneel, maar ons skryf dit vir volledigheid).
Nou moet ons 'n hulpbron vir die prent skep waar die resultate van die s2i-web-app taak gestoor sal word, dit word so gedoen:
# 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
Hier is die PipelineResource van tipe beeld, en die waarde van die url-parameter wys na die interne OpenShift Image Registry, spesifiek die een wat in die webapp-pyplyn naamruimte geleë is. Moenie vergeet om hierdie instelling te verander as jy 'n ander naamspasie gebruik nie.
En laastens, die laaste hulpbron wat ons benodig, sal ook van tipe beeld wees en dit sal die finale NGINX-beeld wees wat dan tydens ontplooiing gebruik sal word:
# 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
Weereens, let op dat hierdie hulpbron die prent in die interne OpenShift-register in die webapp-pyplyn naamruimte stoor.
Om al hierdie hulpbronne gelyktydig te skep, gebruik ons die skepopdrag:
$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/resources/resource.yaml
Jy kan seker maak dat die hulpbronne so geskep is:
$ tkn resource ls
Vervoerband pyplyn
Noudat ons al die nodige komponente het, laat ons 'n pyplyn daaruit saamstel deur dit met die volgende opdrag te skep:
$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/pipelines/build-and-deploy-react.yaml
Maar voordat ons hierdie opdrag uitvoer, kom ons kyk na hierdie komponente. Die eerste is die naam:
apiVersion: tekton.dev/v1alpha1
kind: Pipeline
metadata:
name: build-and-deploy-react
Dan sien ons in die spesifikasie-afdeling 'n aanduiding van die hulpbronne wat ons vroeër geskep het:
spec:
resources:
- name: web-application-repo
type: git
- name: built-web-application-image
type: image
- name: runtime-web-application-image
type: image
Ons skep dan die take wat ons pyplyn moet voltooi. Eerstens moet dit die s2i-web-app taak uitvoer wat ons reeds geskep het:
tasks:
- name: build-web-application
taskRef:
name: s2i-web-app
kind: ClusterTask
Hierdie taak neem inset (gir hulpbron) en uitset (gebou-web-toepassing-beeld hulpbron) parameters. Ons gee dit ook 'n spesiale parameter deur sodat dit nie TLS verifieer nie, aangesien ons selfondertekende sertifikate gebruik:
resources:
inputs:
- name: source
resource: web-application-repo
outputs:
- name: image
resource: built-web-application-image
params:
- name: TLSVERIFY
value: "false"
Die volgende taak is amper dieselfde, net hier word die webapp-build-runtime cluster-taak wat ons reeds geskep het genoem:
name: build-runtime-image
taskRef:
name: webapp-build-runtime
kind: ClusterTask
Soos met die vorige taak, gee ons 'n hulpbron in, maar nou is dit gebou-web-toepassing-beeld (die uitset van ons vorige taak). En as 'n uitset stel ons weer die beeld. Aangesien hierdie taak na die vorige een uitgevoer moet word, voeg ons die runAfter-veld by:
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
Die volgende twee take is verantwoordelik vir die gebruik van die diens, roete en ontplooiing YAML-lêers wat in die k8s-gids van ons webtoepassing woon, en ook vir die opdatering van hierdie ontplooiing wanneer nuwe beelde geskep word. Ons het hierdie twee groeptake aan die begin van die artikel gedefinieer.
Die pyplyn bestuur
Dus, alle dele van ons pyplyn word geskep, en ons sal dit met die volgende opdrag uitvoer:
$ tkn pipeline start build-and-deploy-react
Op hierdie stadium word die opdragreël interaktief gebruik en jy moet die toepaslike hulpbronne kies in reaksie op elkeen van sy versoeke: vir die git-hulpbron, kies web-toepassing-repo, dan vir die eerste beeldhulpbron, gebou-web-toepassing -beeld, en laastens, vir tweede beeldhulpbron –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
Kom ons kyk nou na die status van die pyplyn deur die volgende opdrag te gebruik:
$ tkn pipeline logs -f
Sodra die pyplyn begin het en die toepassing ontplooi is, kan ons die gepubliseerde roete aanvra met die volgende opdrag:
$ oc get route react-pipeline-example --template='http://{{.spec.host}}'
Vir groter visualisering kan u ons pyplyn in die ontwikkelaarmodus van die webkonsole in die afdeling bekyk Pypleidings, soos in Fig. 1.
Fig.1. Hersiening van lopende pypleidings.
As u op 'n lopende pyplyn klik, word bykomende besonderhede vertoon, soos in Figuur 2 getoon.
Rys. 2. Bykomende inligting oor die pyplyn.
Na meer inligting, kan jy lopende toepassings in die aansig sien topologie, soos getoon in Fig.3.
Fig 3. Geloodsde peul.
As u op die sirkel in die regter boonste hoek van die ikoon klik, word ons toepassing oopgemaak, soos in Fig. 4 getoon.
Rys. 4. Begin React-toepassing.
Gevolgtrekking
Dus, ons het gewys hoe om 'n ontwikkelingsbediener vir u toepassing op OpenShift te laat loop en dit met die plaaslike lêerstelsel te sinchroniseer. Ons het ook gekyk na hoe om 'n kettinggeboude sjabloon met OpenShift Pipelines te simuleer. Alle voorbeeldkodes uit hierdie artikel kan gevind word .
Bykomende hulpbronne (EN)
- Gratis e-boek
- Ander artikels oor op die Red Hat-webwerf
Aankondigings van opkomende webinars
Ons begin 'n reeks van Vrydag webinars oor inheemse ervaring met behulp van Red Hat OpenShift Container Platform en Kubernetes:
Bron: will.com