🥇Nútímaleg forrit á OpenShift, hluti 3: OpenShift sem þróunarumhverfi og OpenShift Pipelines

Halló allir á þessu bloggi! Þetta er þriðja færslan í röð þar sem við sýnum hvernig á að setja upp nútíma vefforrit á Red Hat OpenShift.

Í fyrri tveimur færslum sýndum við hvernig á að setja upp nútíma vefforrit í örfáum skrefum og hvernig á að nota nýja S2I mynd ásamt HTTP netþjónsmynd sem er utan hillunnar, eins og NGINX, með hlekkjaðri byggingu til að skipuleggja framleiðsluuppsetningar .

Í dag munum við sýna hvernig á að keyra þróunarþjón fyrir forritið þitt á OpenShift pallinum og samstilla það við staðbundið skráarkerfi, og einnig tala um hvað OpenShift Pipelines eru og hvernig þær geta verið notaðar sem valkostur við tengdar samsetningar.

OpenShift sem þróunarumhverfi

Þróunarvinnuflæði

Eins og áður hefur komið fram í fyrsta færsla, dæmigerð þróunarferli nútíma vefforrita er einfaldlega einhvers konar „þróunarþjónn“ sem fylgist með breytingum á staðbundnum skrám. Þegar þau eiga sér stað er forritabyggingin ræst og síðan er hún uppfærð í vafrann.

Í flestum nútíma ramma er slíkur „þróunarþjónn“ innbyggður í samsvarandi skipanalínuverkfæri.

Staðbundið dæmi

Fyrst skulum við sjá hvernig þetta virkar þegar forrit eru keyrð á staðnum. Tökum umsóknina sem dæmi Bregðast frá fyrri greinum, þó að nánast sömu verkflæðishugtök eigi við í öllum öðrum nútíma ramma.
Svo, til að ræsa „dev server“ í React dæminu okkar, munum við slá inn eftirfarandi skipun:

$ npm run start

Síðan í flugstöðvarglugganum munum við sjá eitthvað á þessa leið:

Og forritið okkar mun opnast í sjálfgefna vafranum:

Nú, ef við gerum breytingar á skránni, ætti forritið að uppfærast í vafranum.

Allt í lagi, allt er á hreinu með þróun í staðbundnum ham, en hvernig á að ná því sama á OpenShift?

Þróunarþjónn á OpenShift

Ef þú manst, í fyrri færsla, við skoðuðum svokallaðan keyrslufasa S2I myndarinnar og sáum að sjálfgefið er þjónustueiningin ábyrg fyrir þjónustu við vefforritið okkar.

Hins vegar, ef þú skoðar það nánar keyra handrit frá því dæmi inniheldur það $NPM_RUN umhverfisbreytuna, sem gerir þér kleift að framkvæma skipunina þína.

Til dæmis getum við notað nodeshift eininguna til að dreifa forritinu okkar:

$ npx nodeshift --deploy.env NPM_RUN="yarn start" --dockerImage=nodeshift/ubi8-s2i-web-app

Athugið: Dæmið hér að ofan er skammstafað til að sýna almenna hugmynd.

Hér höfum við bætt NPM_RUN umhverfisbreytunni við dreifinguna okkar, sem segir keyrslutímanum að keyra yarn start skipunina, sem ræsir React þróunarþjóninn inni í OpenShift pod okkar.

Ef þú horfir á skrá yfir hlaupandi belg lítur hann eitthvað svona út:

Allt þetta verður auðvitað ekkert fyrr en við getum samstillt staðarkóðann við kóðann, sem einnig er fylgst með breytingum, en býr á ytri netþjóni.

Samstilling fjarstýringar og staðbundins kóða

Sem betur fer getur hnútskipting auðveldlega hjálpað til við samstillingu og þú getur notað klukkuskipunina til að fylgjast með breytingum.

Svo eftir að við höfum keyrt skipunina til að dreifa þróunarþjóninum fyrir forritið okkar, getum við örugglega notað eftirfarandi skipun:

$ npx nodeshift watch

Fyrir vikið verður tenging við hlaupapúðann sem við bjuggum til aðeins fyrr, samstilling staðbundinna skráa okkar við fjarklasann verður virkjuð og byrjað verður að fylgjast með breytingum á skrám á staðbundnu kerfinu okkar.

Þess vegna, ef við uppfærum núna src/App.js skrána, mun kerfið bregðast við þessum breytingum, afrita þær í ytri þyrpinguna og ræsa þróunarþjóninn, sem mun síðan uppfæra forritið okkar í vafranum.

Til að klára myndina skulum við sýna hvernig allar þessar skipanir líta út:

$ 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

Watch skipunin er útdráttur ofan á oc rsync skipunina, þú getur lært meira um hvernig hún virkar hér.

Þetta var dæmi fyrir React, en nákvæmlega sömu aðferð er hægt að nota með öðrum ramma, stilltu bara NPM_RUN umhverfisbreytuna eftir þörfum.

Openshift leiðslur

Næst munum við tala um tól eins og OpenShift Pipelines og hvernig hægt er að nota það sem valkost við hlekkjaðar byggingar.

Hvað eru OpenShift Pipelines

OpenShift Pipelines er skýjaætt CI/CD samfellt samþættingar- og afhendingarkerfi hannað til að skipuleggja leiðslur með Tekton. Tekton er sveigjanlegur opinn uppspretta Kubernetes-innfæddur CI/CD ramma sem gerir þér kleift að gera sjálfvirkan dreifingu á ýmsum kerfum (Kubernetes, netþjónalausum, sýndarvélum osfrv.) með því að draga úr undirliggjandi laginu.

Að skilja þessa grein krefst nokkurrar þekkingar á Pipelines, svo við mælum eindregið með því að þú lesir fyrst opinber kennslubók.

Að setja upp vinnuumhverfið þitt

Til að leika með dæmin í þessari grein þarftu fyrst að undirbúa vinnuumhverfið þitt:

Settu upp og stilltu OpenShift 4 klasa. Dæmin okkar nota CodeReady Containers (CRD) fyrir þetta, uppsetningarleiðbeiningar um það má finna hér.
Eftir að þyrpingin er tilbúin þarftu að setja Pipeline Operator á hann. Ekki vera hræddur, það er auðvelt, uppsetningarleiðbeiningar hér.
Niðurhal Tekton CLI (tkn) hér.
Keyrðu create-react-app skipanalínutólið til að búa til forrit sem þú munt síðan nota (þetta er einfalt forrit Bregðast).
(Valfrjálst) Klóna geymsluna til að keyra dæmiforritið á staðnum með npm install og síðan npm start.

Forritsgeymslan mun einnig hafa k8s möppu, sem mun innihalda Kubernetes/OpenShift YAML sem notuð eru til að dreifa forritinu. Það verða Verkefni, ClusterTasks, Resources og Pipelines sem við munum búa til í þessu geymslum.

Byrjum

Fyrsta skrefið fyrir dæmið okkar er að búa til nýtt verkefni í OpenShift klasanum. Við skulum kalla þetta verkefni webapp-pipeline og búa það til með eftirfarandi skipun:

$ oc new-project webapp-pipeline

Þetta verkefnisheiti mun birtast í kóðanum síðar, svo ef þú ákveður að nefna það eitthvað annað, ekki gleyma að breyta dæmikóðann í samræmi við það. Frá og með þessum tímapunkti munum við ekki fara ofan frá, heldur neðan og upp: það er, við munum fyrst búa til alla íhluti færibandsins, og aðeins þá færibandið sjálft.

Svo, fyrst og fremst...

Verkefni

Við skulum búa til nokkur verkefni, sem munu síðan hjálpa til við að dreifa forritinu innan leiðslunnar okkar. Fyrsta verkefnið - application_manifests_task - er ábyrgt fyrir því að beita YAML þessara Kubernetes auðlinda (þjónusta, dreifing og leið) sem eru staðsett í k8s möppunni í forritinu okkar. Annað verkefnið - update_deployment_task - er ábyrgt fyrir því að uppfæra mynd sem þegar hefur verið dreift í þá mynd sem var búin til af leiðslunni okkar.

Ekki hafa áhyggjur ef það er ekki alveg ljóst ennþá. Í raun eru þessi verkefni eitthvað eins og veitur og við munum skoða þau nánar aðeins síðar. Í bili skulum við bara búa þær til:

$ 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

Síðan, með því að nota tkn CLI skipunina, munum við athuga hvort verkefnin hafi verið búin til:

$ tkn task ls

NAME                AGE
apply-manifests     1 minute ago
update-deployment   1 minute ago

Athugið: Þetta eru staðbundin verkefni fyrir núverandi verkefni.

Klasaverkefni

Klasaverkefni eru í grundvallaratriðum það sama og einföld verkefni. Það er að segja, það er endurnýtanlegt safn af skrefum sem eru sameinuð á einn eða annan hátt þegar tiltekið verkefni er keyrt. Munurinn er sá að klasaverkefni er í boði alls staðar innan klasans. Til að sjá lista yfir klasaverkefni sem eru sjálfkrafa búin til þegar Pipeline Operator er bætt við munum við aftur nota tkn CLI skipunina:

$ 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

Nú skulum við búa til tvö klasaverkefni. Sá fyrsti mun búa til S2I myndina og senda hana til innri OpenShift skrárinnar; annað er að byggja ímynd okkar byggða á NGINX, með því að nota forritið sem við höfum þegar byggt sem innihald.

Búðu til og sendu myndina

Þegar fyrsta verkefnið er búið til munum við endurtaka það sem við gerðum þegar í fyrri grein um tengdar samsetningar. Mundu að við notuðum S2I myndina (ubi8-s2i-web-app) til að „smíða“ forritið okkar og enduðum með mynd sem var geymd í OpenShift innri skránni. Nú munum við nota þessa S2I vefforritsmynd til að búa til DockerFile fyrir appið okkar og nota síðan Buildah til að gera raunverulega byggingu og ýta myndinni sem myndast í OpenShift innri skráninguna, þar sem það er nákvæmlega það sem OpenShift gerir þegar þú setur forritin þín í notkun með NodeShift .

Hvernig vissum við allt þetta, spyrðu? Frá opinber útgáfa af opinberu Node.js, við afrituðum það bara og breyttum því fyrir okkur.

Svo, nú skulum við búa til s2i-web-app klasaverkefnið:

$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/clustertasks/s2i-web-app-task.yaml

Við munum ekki greina þetta í smáatriðum, heldur einbeita okkur aðeins að OUTPUT_DIR færibreytunni:

params:
      - name: OUTPUT_DIR
        description: The location of the build output directory
        default: build

Sjálfgefið er að þessi færibreyta er jöfn byggingu, sem er þar sem React setur samansett efni. Aðrir rammar nota mismunandi leiðir, til dæmis í Ember er það dist. Framleiðsla fyrsta klasaverkefnisins okkar verður mynd sem inniheldur HTML, JavaScript og CSS sem við söfnuðum.

Búðu til mynd byggða á NGINX

Hvað varðar annað klasaverkefnið okkar, þá ætti það að búa til NGINX-byggða mynd fyrir okkur með því að nota innihald forritsins sem við höfum þegar smíðað. Í meginatriðum er þetta hluti fyrri hlutans þar sem við skoðuðum hlekkjaðar byggingar.

Til að gera þetta munum við - nákvæmlega það sama og rétt fyrir ofan - búa til klasaverkefni webapp-build-runtime:

$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/clustertasks/webapp-build-runtime-task.yaml

Ef þú skoðar kóða þessara klasaverkefna geturðu séð að hann tilgreinir ekki Git geymsluna sem við erum að vinna með eða nöfn myndanna sem við erum að búa til. Við tilgreinum aðeins hvað nákvæmlega við erum að flytja yfir í Git, eða ákveðna mynd þar sem lokamyndin ætti að vera send út. Þess vegna er hægt að endurnýta þessi klasaverkefni þegar unnið er með önnur forrit.

Og hér höldum við þokkalega yfir í næsta atriði...

Resources

Svo, þar sem, eins og við sögðum, ættu klasaverkefni að vera eins almenn og mögulegt er, þurfum við að búa til auðlindir sem verða notaðar sem inntak (Git geymsluna) og sem úttak (lokamyndirnar). Fyrsta auðlindin sem við þurfum er Git, þar sem forritið okkar er, eitthvað á þessa leið:

# 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

Hér er PipelineResource af gerðinni git. Vefslóð lykillinn í params hlutanum bendir á tiltekna geymslu og tilgreinir aðalútibúið (þetta er valfrjálst, en við skrifum það til að vera fullkomið).

Nú þurfum við að búa til tilföng fyrir myndina þar sem niðurstöður s2i-web-app verkefnisins verða vistaðar, þetta er gert svona:

# 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

Hér er PipelineResource af gerðinni mynd og gildi url færibreytunnar bendir á innri OpenShift Image Registry, sérstaklega þann sem er staðsettur í webapp-pipeline nafnrýminu. Ekki gleyma að breyta þessari stillingu ef þú ert að nota annað nafnrými.

Og að lokum, síðasta tilfangið sem við þurfum mun einnig vera af gerðinni mynd og þetta verður síðasta NGINX myndin sem verður síðan notuð við uppsetningu:

# 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

Athugaðu aftur að þetta tilfang geymir myndina í innri OpenShift skránni í nafnrými webapp-pipeline.

Til að búa til öll þessi úrræði í einu notum við create skipunina:

$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/resources/resource.yaml

Þú getur gengið úr skugga um að tilföngin hafi verið búin til svona:

$ tkn resource ls

Færibandsleiðslu

Nú þegar við höfum alla nauðsynlega íhluti skulum við setja saman leiðslu úr þeim með því að búa hana til með eftirfarandi skipun:

$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/pipelines/build-and-deploy-react.yaml

En áður en við keyrum þessa skipun skulum við skoða þessa hluti. Það fyrsta er nafnið:

apiVersion: tekton.dev/v1alpha1
kind: Pipeline
metadata:
  name: build-and-deploy-react

Síðan í forskriftarhlutanum sjáum við vísbendingu um auðlindirnar sem við bjuggum til áðan:

spec:
  resources:
    - name: web-application-repo
      type: git
    - name: built-web-application-image
      type: image
    - name: runtime-web-application-image
      type: image

Við búum svo til þau verkefni sem leiðslan okkar þarf að klára. Fyrst af öllu verður það að framkvæma s2i-web-app verkefnið sem við höfum þegar búið til:

tasks:
    - name: build-web-application
      taskRef:
        name: s2i-web-app
        kind: ClusterTask

Þetta verkefni tekur inntak (gir auðlind) og úttak (innbyggður-vef-forrit-mynd auðlind) færibreytur. Við sendum henni líka sérstaka færibreytu þannig að hún staðfesti ekki TLS þar sem við erum að nota sjálfundirrituð vottorð:

resources:
        inputs:
          - name: source
            resource: web-application-repo
        outputs:
          - name: image
            resource: built-web-application-image
      params:
        - name: TLSVERIFY
          value: "false"

Næsta verkefni er næstum því það sama, aðeins hér heitir webapp-build-runtime klasaverkefnið sem við höfum þegar búið til:

name: build-runtime-image
    taskRef:
      name: webapp-build-runtime
      kind: ClusterTask

Eins og með fyrra verkefnið sendum við tilföng inn, en núna er það innbyggð vefforritsmynd (úttak fyrra verkefnis okkar). Og sem framleiðsla stillum við aftur myndina. Þar sem þetta verkefni verður að vera framkvæmt eftir það fyrra, bætum við runAfter reitnum:

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

Næstu tvö verkefni eru ábyrg fyrir notkun þjónustu, leiðar og dreifingar YAML skrár sem eru í k8s skránni í vefforritinu okkar, og einnig fyrir að uppfæra þessa dreifingu þegar nýjar myndir eru búnar til. Við skilgreindum þessi tvö klasaverkefni í upphafi greinarinnar.

Ræsir færibandið

Þannig að allir hlutar leiðslunnar okkar eru búnir til og við munum keyra hana með eftirfarandi skipun:

$ tkn pipeline start build-and-deploy-react

Á þessu stigi er skipanalínan notuð gagnvirkt og þú þarft að velja viðeigandi tilföng sem svar við hverri beiðni hennar: fyrir git-tilföngina, veldu vefforrit-repo, síðan fyrir fyrsta myndforritið, innbyggða vefforritið -mynd, og að lokum, fyrir annað myndefni -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

Nú skulum við athuga stöðu leiðslunnar með því að nota eftirfarandi skipun:

$ tkn pipeline logs -f

Þegar leiðslan hefur ræst og forritið hefur verið dreift getum við beðið um birtu leiðina með eftirfarandi skipun:

$ oc get route react-pipeline-example --template='http://{{.spec.host}}'

Til að fá betri sjónmynd geturðu skoðað leiðsluna okkar í þróunarstillingu vefborðsins í hlutanum Leiðslur, eins og sýnt er á mynd. 1.

Mynd.1. Endurskoðun á hlaupandi leiðslum.

Með því að smella á hlaupandi leiðslu birtast frekari upplýsingar, eins og sýnt er á mynd 2.

Hrísgrjón. 2. Viðbótarupplýsingar um leiðsluna.

Eftir frekari upplýsingar geturðu séð keyrandi forrit á skjánum grannfræði, eins og sýnt er á mynd 3.

Mynd 3. Sjósett belg.

Með því að smella á hringinn í efra hægra horninu á tákninu opnast forritið okkar, eins og sýnt er á mynd 4.

Hrísgrjón. 4. Keyrir React forritið.

Ályktun

Svo, við sýndum hvernig á að keyra þróunarþjón fyrir forritið þitt á OpenShift og samstilla það við staðbundið skráarkerfi. Við skoðuðum líka hvernig á að líkja eftir hlekkjaðri sniðmáti með því að nota OpenShift Pipelines. Hægt er að finna alla dæmikóða úr þessari grein hér.

Viðbótarupplýsingar (EN)

Tilkynningar um væntanlegar vefnámskeið

Við erum að hefja röð af föstudagsnámskeiðum um innfædda reynslu af því að nota Red Hat OpenShift Container Platform og Kubernetes:

Heimild: www.habr.com

Nútíma forrit á OpenShift, hluti 3: OpenShift sem þróunarumhverfi og OpenShift Pipelines