🥇 Kaasaegsed rakendused OpenShiftis, osa 3: OpenShift arenduskeskkonnana ja OpenShift Pipelines torujuhtmed

Tere kõigile sellel blogis! Olete jõudnud kolmanda postituseni seerias, kus tutvustame, kuidas käivitada kaasaegseid veebirakendusi Red Hat OpenShiftis.

Kahel eelneval postitusel rääkisime, kuidas käivitada kaasaegseid veebirakendusi vaid mõne sammu jooksul ja kuidas kasutada uut S2I pilti koos valmis HTTP-serveri pildiga, näiteks NGINX, kasutades seotud ehitusi (chained builds), et korraldada tootmispaigaldust.

Täna näitame, kuidas avada arendusserver oma rakenduse jaoks OpenShift platvormil ja sünkroonida see lokaalse failisüsteemiga, samuti räägime sellest, mis on OpenShift Pipelines ja kuidas neid saab kasutada alternatiividena seotud ehitustele.

OpenShift arendus keskkonnana

Arendustöövoog

Kuidas juba mainitud esimese postituse, tüüpiline protsess kaasaegsete veebirakenduste arendamiseks on lihtsalt mingi "arendusserver", mis jälgib muutusi lokaalfailides. Kui need esinevad, käivitatakse rakenduse ehitus ja seejärel värskendatakse seda brauseris.

Enamik kaasaegsetest raamistikest sisaldab sellist 'arendusserverit' vastavates käsurea tööriistades.

Kohalik näide

Alustame vaatamist, kuidas see töötab kohalike rakenduste käivitamise korral. Näitena võtame rakenduse React eelmistest artiklitest, kuigi praktiliselt samad töövoo kontseptsioonid kehtivad kõikide teiste kaasaegsete raamistikute kohta.
Nii et, et käivitada 'arendusserver' meie Reacti näites, sisestame järgmise käsu:

$ npm run start

Siis näeme terminaliaknas umbkaudu järgmist:

Ja meie rakendus avaneb brauseris vaikimisi:

Nüüd, kui teeme faili muudatusi, peaks rakendus brauseris uuenduma.

OK, kohaliku režiimi arendamine on selge, aga kuidas saavutada sama OpenShiftis?

Arendusserver OpenShiftis

Kui mäletate, siis eelnevas postituses, käsitlesime nii-öelda käivituse etappi (run phase) S2I pildil ja nägime, et meie veebirakendust teenindab vaikimisi moodul serve.

Kuid kui vaadata lähemalt käivitusskript selle näite põhjal, siis seal on keskkonnamuutuja $NPM_RUN, mis võimaldab teil käivitada ka oma käsu.

Näiteks saame kasutada nodeshift moodulit, et meie rakendust juurutada:

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

Märkus: ülaltoodud näide on lühendatud, et illustreerida üldist ideed.

Siia oleme lisanud meie juurutamisse keskkonnamuutuja NPM_RUN, mis annab täitmisetapile teada, et see peaks käivitama käsu yarn start, mis alustab Reacti arendusserverit meie OpenShifti podis.

Kui vaadata töötava podi logi, siis seal on umbes selline:

Muidugi, see kõik ei tähenda midagi, kuni me ei suuda sünkroniseerida kohalikku koodi koodiga, mis samuti kontrollib muudatusi, kuid mida hoitakse eemalserveris.

Kaugekoodi ja kohaliku koodi sünkroonimine

Kohutavalt, nodeshift aitab sünkroniseerimisel kergesti, ja muudatuste jälgimiseks saab kasutada käsku watch.

Nii et pärast seda, kui oleme käivitanud käsu arendusserveri juurutamiseks meie rakendusele, saame julgelt kasutada sellist käsku:

$ npx nodeshift watch

Tulemuseks on ühendamine varustatud pod'iga, mille me natuke varem lõime, aktiveeritakse meie lokaalsete failide sünkroniseerimine eemal oleva klastriga ning meie lokaalses süsteemis jälgitakse faile muudatuste osas.

Seetõttu, kui nüüd uuendada faili src/App.js, reageerib süsteem nendele muudatustele, kopeerib need eemal olevasse klastrisse ja käivitab arendusserveri, mis seejärel värskendab meie rakendust brauseris.

Kuna teema täielikud käsud näevad välja sellised:

$ 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

Käsk watch on abstraktsioon käsu oc rsync kohal, rohkem teada selle toimimisest saab siit.

See oli näide Reacti jaoks, kuid täpselt sama meetodit saab kasutada ka teiste raamistikega, lihtsalt määrake keskkonnamuutuja NPM_RUN õigesti.

OpenShift Pipelines

Edasi räägime sellisest tööriistast nagu OpenShift Pipelines ja kuidas seda saab kasutada alternatiivina seotud ehitustele chained build.

Mis on OpenShift Pipelines

OpenShift Pipelines – pilvepõhine pideva integreerimise ja tarnimise (CI/CD) süsteem, mis on loodud konveierite korraldamiseks Tektoni abil. Tekton on paindlik Kubernetes'i kohalikke CI/CD raamistik avatud koodiga, mis võimaldab automatiseerida rakenduste juurutamist erinevates platvormides (Kubernetes, serverita, virtuaalmasinad jne) alumisele tasemele abstraktsiooni kaudu.

Selle artikli mõistmiseks on vajalikud teatud teadmised Pipelines'i kohta, seetõttu soovitame tungivalt kõigepealt tutvuda ametliku juhendiga.

Tööruumi seadistamine

Käesoleva artikli näidistega katsetamiseks tuleb esmalt ette valmistada tööruum:

Paigaldage ja seadistage OpenShift 4 klaster. Meie näidetes kasutatakse selleks CodeReady Containers (CRD), mille paigaldusjuhised leiate siit.
Pärast klastrite valmimist peate installima Pipeline Operatori. Ärge muretsege, see on lihtne, paigaldusjuhised siit.
Laadi Tekton CLI (tkn) siit.
Käitage create-react-app käsurea tööriista, et luua rakendus, mida seejärel juurutatakse (see on lihtne rakendus React).
(Valikuline) Kloonige hoidla, et käivitada rakenduse näide kohalikult käsuga npm install ja seejärel npm start.

Rakenduse hoidlas on ka kaust k8s, kuhu paigutatakse Kubernetes/OpenShift'i YAML-failid, mida rakenduse juurutamiseks kasutatakse. Seal on Tasks, ClusterTasks, Resources ja Pipelines, mille me selles loome. repositoriis.

Alustame

Esimene samm meie näite jaoks on uue projekti loomine OpenShift klastris. Nimetame selle projekti webapp-pipeline ja loome selle järgmise käsuga:

$ oc new-project webapp-pipeline

Edasi, see projekti nimi ilmub koodis, seega, kui otsustate nimetada selle teistmoodi, ärge unustage vastavalt kohandada näidiskoodi. Alates sellest kohast liikume alt üles: esmalt loome kõik konveieri komponendid ja alles seejärel konveieri ennast.

Nii, esimene samm...

Ülesanded Tasks

Loome paar ülesannet (tasks), mis aitavad seejärel rakendust meie konveieris (pipeline) laiendada. Esimene ülesanne – apply_manifests_task – vastutab YAML-failide rakendamise eest, mis sisaldavad Kubernetes-resursse (service, deployment ja route), mis asuvad meie rakenduse k8s kaustas. Teine ülesanne – update_deployment_task – vastutab juba despleeritud pildi uuendamise eest, mis meie konveieris luuakse.

Ärge muretsege, kui see ei ole veel täielikult arusaadav. Tegelikult on need ülesanded midagi nagu utiliidid, ja me käsitleme neid põhjalikumalt hiljem. Seniks loome lihtsalt need ülesanded:

$ 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

Seejärel kontrollime tkn CLI käsuga, et ülesanded on loodud:

$ tkn task ls

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

Märkus: need on kohalike ülesannete ülesanded teie praeguses projektis.

Klastrite ülesanded Cluster tasks

Klastrite ülesanded on sisuliselt samad mis lihtsalt ülesanded. See on taaskasutatav sammude kogum, mida kombineeritakse teatud viisil konkreetse ülesande käivitamisel. Erinevus seisneb selles, et klastrite ülesanne on saadaval kogu klastri ulatuses. Klastrite ülesannete loendi nägemiseks, mis luuakse automaatselt Pipeline Operatori lisamisel, kasutame uuesti tkn CLI käsku:

$ tkn clustertask ls

NAME                       AGE
buildah                    1 päev tagasi
buildah-v0-10-0            1 päev tagasi
jib-maven                  1 päev tagasi
kn                         1 päev tagasi
maven                      1 päev tagasi
openshift-client           1 päev tagasi
openshift-client-v0-10-0   1 päev tagasi
s2i                        1 päev tagasi
s2i-go                     1 päev tagasi
s2i-go-v0-10-0             1 päev tagasi
s2i-java-11                1 päev tagasi
s2i-java-11-v0-10-0        1 päev tagasi
s2i-java-8                 1 päev tagasi
s2i-java-8-v0-10-0         1 päev tagasi
s2i-nodejs                 1 päev tagasi
s2i-nodejs-v0-10-0         1 päev tagasi
s2i-perl                   1 päev tagasi
s2i-perl-v0-10-0           1 päev tagasi
s2i-php                    1 päev tagasi
s2i-php-v0-10-0            1 päev tagasi
s2i-python-3               1 päev tagasi
s2i-python-3-v0-10-0       1 päev tagasi
s2i-ruby                   1 päev tagasi
s2i-ruby-v0-10-0           1 päev tagasi
s2i-v0-10-0                1 päev tagasi

Nüüd loome kaks klastrite ülesannet. Esimene genereerib S2I kujundi ja saadab selle OpenShifti siseregistrisse; teine kogub meie NGINX-i põhjal kujundi, kasutades sisuna juba koostatud rakendust.

Loome ja saadame kujundi

Esimese ülesande loomisel kordame samme, mida tegime eelnevas artiklis seotud kogumiste kohta. Tuletame meelde, et kasutasime S2I kujundit (ubi8-s2i-web-app), et "koguda" meie rakendust, ja lõpuks saime kujundi, mis on salvestatud OpenShifti siseregistrisse. Nüüd kasutame seda S2I veebirakenduse kujundit, et luua meie rakendusele DockerFile, ja seejärel kasutame Buildah'is tõeliseks kogumiseks ja saadame saadud kujundi OpenShifti siseregistrisse, kuna just seda teeb OpenShift, kui kasutate NodeShiftiga oma rakenduste juurutamiseks.

Küsite, kust me seda kõike teame? официальной версии official Node.js, me lihtsalt kopeerisime selle ja kohandasime enda jaoks.

Nii, nüüd loome klastrite ülesande s2i-web-app:

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

Me ei käsitle seda süvitsi, vaid peatume ainult OUTPUT_DIR parameetril:

params:
      - name: OUTPUT_DIR
        description: Kogumise väljundikausta asukoht
        default: build

Vaikimisi on see parameeter seatud väärtusele build, kuhu React paigutab kogutud sisu. Teistes raamistikes on kasutusel erinevad teed, näiteks Emberis on see dist. Meie esimese klastriülesande väljund kujutab endast pilti, mis sisaldab kogutud HTML, JavaScripti ja CSS-i.

Kogume NGINX-i baasil pilti

Mis puudutab meie teist klastriülesannet, siis see peab koguma meile pilti NGINX-i põhjal, kasutades juba kogutud rakenduse sisu. Sisuliselt on see see osa eelmise peatüki osas, kus käsitlesime seotud kogumisi (chained builds).

Selleks loome – täpselt nagu veidi üle – klastriülesande webapp-build-runtime:

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

Kui vaadata nende klasterülesannete koodi, siis on näha, et seal ei täpsustata Git'i hoidlat, millega me töötame, ega ka piltide nimesid, mida me loome. Me määratleme vaid, mida me Git'ile edastame, või mingit pilti, kuhu peab tulemuseks saadud pilt viima. Just selle tõttu on neid klasterülesandeid võimalik taaskasutada ka teiste rakenduste puhul.

Ja siit liigume elegantselt järgmisele punktile…

Ressursid

Kuna, nagu äsja ütlesime, peavad klasterülesanded olema võimalikult üldised, peame looma ressursid, mida kasutatakse sisendina (Git'i hoidla) ja väljundina (lõplikud pildid). Esimene ressurss, mida me vajame, on Git, kus asub meie rakendus, midagi sellist:

# 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

Siin on PipelineResource tüübiks git. Parameetrite sektsiooni url võti osutab konkreetsele hoidla ja määrab master haru (see on valikuline, kuid kirjutame selle täitmiseks).

Nüüd peame looma ressursi pildi jaoks, kuhu salvestatakse s2i-web-app ülesande täitmise tulemused, seda tehakse nii:

# 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

Siin on PipelineResource tüüp image ja url-i parameeter viitab sisemisele OpenShift Image Registry'le, täpsemalt sellele, mis asub namespace'is webapp-pipeline. Ära unusta seda parameetrit muuta, kui kasutad teistsugust namespace'i.

Ja lõpuks, viimane ressurss, mida me vajame, on samuti tüübilt image ja see on lõplik NGINX pilt, mida kasutatakse hiljem juurutamisel:

# 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

Jällegi, pane tähele, et see ressurss salvestab pildi sisemisse OpenShift registrisse namespace'is webapp-pipeline.

Kogu nende ressursside loomiseks kasutame käsku create:

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

Saame veenduda, et ressursid on loodud järgmiselt:

$ tkn resource ls

Pipelini konveier

Nüüd, kui meil on kõik vajalikud osad, koostame neist konveieri, luues selle järgmise käsuga:

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

Kuid enne selle käsu käivitamist vaatame neid komponente lähemalt. Esimene on nimi:

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

Seejärel näeme spec jaotises viidet ressursidele, mille me eelnevalt lõime:

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

Seejärel loome ülesanded, mida meie torujuhe peab täitma. Esiteks peab ta täitma juba loodud ülesande s2i-web-app:

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

See ülesanne võtab sisendid (gir-resurss) ja väljundid (resurss built-web-application-image). Samuti edastame sellele spetsiaalse parameetri, et see ei kinnitaks TLS-i, kuna kasutame isesigneeritud sertifikaate:

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

Järgmine ülesanne on peaaegu sama, kuigi siin kutsutakse juba loodud klastrite ülesannet webapp-build-runtime:

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

Nagu eelmise ülesande puhul, edastame ressursi, kuid nüüd on see built-web-application-image (meie eelmise ülesande väljund). Ja väljundina määrame jälle pildi. Kuna see ülesanne peaks toimuma pärast eelmist, lisame välja 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

Järgmised kaks ülesannet vastutavad teenuse, marsruudi ja juurutamise YAML-failide rakendamise eest, mis asuvad meie veebirakenduse k8s kataloogis, ning ka selle eest, et uuendada seda juurutamist uute piltide loomisel. Need kaks klastrite ülesannet määrasime juba artikli alguses.

Konveieri käivitamine

Nii et kõik meie toru osad on loodud ja käivitame selle järgmise käsuga:

$ tkn pipeline start build-and-deploy-react

Selles etapis kasutatakse käsurea interaktiivset režiimi ja tuleb valida vastavad ressursid iga tema päringu vastusena: git-resursi puhul valime web-application-repo, seejärel esimese pildi ressursi jaoks – built-web-application-image, ja lõpuks teise pildi ressursi jaoks – 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üüd kontrollime torujuhtme staatust järgmise käsuga:

$ tkn pipeline logs -f

Pärast seda, kui torujuhe on käivitatud ja rakendus on juurutatud, saame avaldatud marsruudi järgmise käsuga:

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

Visuaalsuse parandamiseks saab meie torujuhtme vaadata arendaja režiimis veebikonsolis jaotises Torud, nagu on näidatud joonisel 1.

Joonis 1. Käivitatud torujuhtmete ülevaade.

Käivitatud torujuhtmele klõpsamine kuvab täiendavat teavet, nagu on näidatud joonisel 2.

Joonis 2. Torujuhtme täiendavad andmed.

Pärast täiendavate andmete vaatamist saab käivitatud rakendusi vaadata vaates Topoloogia, nagu on näidatud joonisel 3.

Joonis 3. Käivitatud pod.

Ülemises paremas nurgas asuvale ringikujulisele ikoonile klõpsamine avab meie rakenduse, nagu on näidatud joonisel 4.

Joonis 4. Käivitatud React rakendus.

Kokkuvõte

Nii näitasime, kuidas käivitada avatud rakenduste server OpenShiftis ja sünkroniseerida see kohaliku failisüsteemiga. Samuti vaatasime, kuidas simuleerida chained-build šablooni OpenShift Pipelines'i abil. Kõik näidiskoodid, mis on selles artiklis, on saadaval siit.