Kaasaegsed rakendused OpenShiftis, osa 3: OpenShift kui arenduskeskkond ja OpenShifti torujuhtmed

Tere kõigile siin blogis! See on kolmas postitus seeriast, milles näitame, kuidas Red Hat OpenShiftis kaasaegseid veebirakendusi juurutada.

Kaasaegsed rakendused OpenShiftis, osa 3: OpenShift kui arenduskeskkond ja OpenShifti torujuhtmed

Kahes eelmises postituses näitasime, kuidas juurutada moodsaid veebirakendusi vaid mõne sammuga ja kuidas kasutada uut S2I-pilti koos valmis HTTP-serveri kujutisega (nt NGINX), kasutades tootmisjuurutuste korraldamiseks aheldatud versioone. .

Täna näitame, kuidas OpenShifti platvormil oma rakenduse jaoks arendusserverit käivitada ja seda kohaliku failisüsteemiga sünkroonida, ning räägime ka sellest, mis on OpenShift Pipelines ja kuidas neid lingitud sõlmede alternatiivina kasutada.

OpenShift arenduskeskkonnana

Arendustöö voog

Nagu juba märgitud esimene postitus, on tänapäevaste veebirakenduste tüüpiline arendusprotsess lihtsalt mingi "arendusserver", mis jälgib kohalike failide muudatusi. Kui need ilmnevad, käivitatakse rakenduse ehitamine ja seejärel värskendatakse seda brauserisse.

Enamikus kaasaegsetes raamistikes on selline “arendusserver” sisse ehitatud vastavatesse käsureatööriistadesse.

Kohalik näide

Esiteks vaatame, kuidas see rakendusi kohapeal käivitades töötab. Võtame näiteks rakenduse Reageerima varasematest artiklitest, kuigi peaaegu samad töövoo kontseptsioonid kehtivad kõigis teistes kaasaegsetes raamistikes.
Niisiis, meie Reacti näites "dev serveri" käivitamiseks sisestame järgmise käsu:

$ npm run start

Seejärel näeme terminali aknas midagi sellist:

Kaasaegsed rakendused OpenShiftis, osa 3: OpenShift kui arenduskeskkond ja OpenShifti torujuhtmed

Ja meie rakendus avaneb vaikebrauseris:

Kaasaegsed rakendused OpenShiftis, osa 3: OpenShift kui arenduskeskkond ja OpenShifti torujuhtmed

Nüüd, kui teeme failis muudatusi, peaks rakendus brauseris värskendama.

OK, kohalikus režiimis arendusega on kõik selge, aga kuidas OpenShiftis sama saavutada?

Arendusserver OpenShiftis

Kui mäletate, siis sisse eelmine postitus, vaatasime S2I-pildi nn käitamisfaasi ja nägime, et vaikimisi vastutab meie veebirakenduse teenindamise eest teenindusmoodul.

Kui aga lähemalt vaadata käivita skript selle näite põhjal sisaldab see keskkonnamuutujat $NPM_RUN, mis võimaldab teil käsku täita.

Näiteks saame oma rakenduse juurutamiseks kasutada nodeshift moodulit:

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

Märkus. Ülaltoodud näide on üldise idee illustreerimiseks lühendatud.

Siin oleme oma juurutusse lisanud keskkonnamuutuja NPM_RUN, mis käsib käitusajal käivitada käsku yarn start, mis käivitab meie OpenShifti kaustas Reacti arendusserveri.

Kui vaatate jooksva aku logi, näeb see välja umbes selline:

Kaasaegsed rakendused OpenShiftis, osa 3: OpenShift kui arenduskeskkond ja OpenShifti torujuhtmed

Muidugi pole sellest kõigest midagi enne, kui suudame sünkroonida kohaliku koodi koodiga, mida samuti jälgitakse muutuste suhtes, kuid mis elab kaugserveris.

Kaug- ja kohaliku koodi sünkroonimine

Õnneks saab nodeshift hõlpsasti sünkroonimisel abiks olla ja muudatuste jälgimiseks saab kasutada käsku watch.

Nii et pärast seda, kui oleme käivitanud käsu oma rakenduse arendusserveri juurutamiseks, saame ohutult kasutada järgmist käsku:

$ npx nodeshift watch

Selle tulemusel luuakse ühendus töötava podiga, mille lõime veidi varem, meie kohalike failide sünkroonimine kaugklastriga aktiveeritakse ja meie kohalikus süsteemis olevaid faile hakatakse jälgima muudatuste osas.

Seega, kui me nüüd värskendame faili src/App.js, siis süsteem reageerib nendele muudatustele, kopeerib need kaugklastrisse ja käivitab arendusserveri, mis seejärel värskendab meie rakendust brauseris.

Pildi lõpuleviimiseks näitame, kuidas need kõik käsud välja näevad:

$ 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 peal, selle toimimise kohta saate lisateavet siin.

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

Openshift torujuhtmed

Kaasaegsed rakendused OpenShiftis, osa 3: OpenShift kui arenduskeskkond ja OpenShifti torujuhtmed

Järgmisena räägime sellisest tööriistast nagu OpenShift Pipelines ja kuidas seda kasutada alternatiivina aheldatud ehitustele.

Mis on OpenShifti torujuhtmed

OpenShift Pipelines on pilvepõhise CI/CD pideva integreerimise ja edastamise süsteem, mis on loodud torujuhtmete korraldamiseks Tektoni abil. Tekton on paindlik avatud lähtekoodiga Kubernetese native CI/CD raamistik, mis võimaldab automatiseerida juurutamist erinevatel platvormidel (Kubernetes, serverita, virtuaalmasinad jne), abstraheerides aluskihist.

Selle artikli mõistmine nõuab mõningaid teadmisi torujuhtmete kohta, seega soovitame teil esmalt lugeda ametlik õpik.

Oma töökeskkonna seadistamine

Selle artikli näidetega mängimiseks peate esmalt valmistama ette oma töökeskkonna:

  1. Installige ja konfigureerige OpenShift 4 klaster. Meie näidetes kasutatakse selleks CodeReady konteinereid (CRD), mille paigaldamise juhised leiate siin.
  2. Kui klaster on valmis, peate sellesse installima Pipeline Operatori. Ärge kartke, see on lihtne, paigaldusjuhised siin.
  3. Lae alla Tekton CLI (tkn) siin.
  4. Käivitage käsureatööriist create-react-app, et luua rakendus, mille seejärel juurutada (see on lihtne rakendus Reageerima).
  5. (Valikuline) Kloonige hoidla, et käivitada näidisrakendus kohapeal koos npm install ja seejärel npm start.

Rakenduste hoidlas on ka kaust k8s, mis sisaldab rakenduse juurutamiseks kasutatud Kubernetes/OpenShift YAML-e. Selles loome ülesanded, klastriülesanded, ressursid ja torujuhtmed hoidlad.

Alla laskumine

Meie näite esimene samm on OpenShifti klastris uue projekti loomine. Nimetagem seda projekti webapp-pipeline'iks ja looge see järgmise käsuga:

$ oc new-project webapp-pipeline

See projekti nimi kuvatakse koodis hiljem, nii et kui otsustate sellele mõne muu nime panna, ärge unustage näidiskoodi vastavalt muuta. Sellest punktist alates ei lähe me ülevalt alla, vaid alt üles: see tähendab, et kõigepealt loome kõik konveieri komponendid ja alles seejärel konveieri enda.

Niisiis, esiteks...

Ülesanded

Loome paar ülesannet, mis aitavad seejärel rakendust meie konveieri raames juurutada. Esimene ülesanne - apply_manifests_task - vastutab nende Kubernetese ressursside (teenus, juurutamine ja marsruut) YAML-i rakendamise eest, mis asuvad meie rakenduse kaustas k8s. Teine ülesanne – update_deployment_task – vastutab juba juurutatud pildi värskendamise eest meie konveieri loodud pildile.

Ärge muretsege, kui see pole veel väga selge. Tegelikult on need ülesanded midagi kommunaalteenuste sarnast ja me vaatame neid üksikasjalikumalt veidi hiljem. Praegu loome need lihtsalt:

$ 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 käsuga tkn CLI, kas ülesanded on loodud:

$ tkn task ls

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

Märkus. Need on teie praeguse projekti kohalikud ülesanded.

Klastri ülesanded

Klastri ülesanded on põhimõtteliselt samad, mis lihtsad ülesanded. See tähendab, et tegemist on korduvkasutatavate sammude kogumiga, mida konkreetse ülesande täitmisel ühel või teisel viisil kombineeritakse. Erinevus seisneb selles, et klastriülesanne on saadaval kõikjal klastri sees. Pipeline Operatori lisamisel automaatselt loodud klastri ülesannete loendi vaatamiseks kasutame taas käsku 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

Nüüd loome kaks klastri ülesannet. Esimene genereerib S2I-pildi ja saadab selle sisemisse OpenShifti registrisse; teine ​​​​on luua oma pilt NGINX-i põhjal, kasutades sisuna juba loodud rakendust.

Looge ja saatke pilt

Esimese ülesande loomisel kordame seda, mida tegime juba eelmises artiklis lingitud koostude kohta. Tuletage meelde, et kasutasime oma rakenduse "ehitamiseks" S2I-pilti (ubi8-s2i-veebirakendus) ja saime OpenShifti siseregistrisse salvestatud pildi. Nüüd kasutame seda S2I veebirakenduse pilti oma rakenduse jaoks DockerFile'i loomiseks ja seejärel Buildahi abil, et teha tegelik ehitamine ja lükata saadud pilt OpenShifti siseregistrisse, kuna see on täpselt see, mida OpenShift teeb rakenduste NodeShifti abil juurutamisel. .

Kuidas me seda kõike teadsime, küsite? Alates ametliku Node.js ametlik versioon, me lihtsalt kopeerisime selle ja muutsime seda enda jaoks.

Loome nüüd s2i-veebirakenduse klastri ülesande:

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

Me ei analüüsi seda üksikasjalikult, vaid keskendume ainult parameetrile OUTPUT_DIR:

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

Vaikimisi on see parameeter võrdne ehitamisega, kuhu React paneb kokkupandud sisu. Teised raamistikud kasutavad erinevaid teid, näiteks Emberis on see dist. Meie esimese klastriülesande väljundiks on pilt, mis sisaldab meie kogutud HTML-i, JavaScripti ja CSS-i.

Looge NGINX-i põhjal pilt

Mis puudutab meie teist klastriülesannet, siis see peaks ehitama meie jaoks NGINX-põhise pildi, kasutades meie juba ehitatud rakenduse sisu. Põhimõtteliselt on see osa eelmisest jaotisest, kus vaatlesime aheldatud konstruktsioone.

Selleks loome täpselt samamoodi nagu ülalpool - klastri ülesande webapp-build-runtime:

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

Kui vaatate nende klastriülesannete koodi, näete, et see ei täpsusta Giti hoidlat, millega me töötame, ega loodavate piltide nimesid. Täpsustame ainult seda, mida me täpselt Giti teisaldame või teatud pildi, kuhu lõplik pilt välja tuleb. Seetõttu saab neid klastri ülesandeid teiste rakendustega töötamisel uuesti kasutada.

Ja siit liigume graatsiliselt järgmise punkti juurde...

Ressursid

Seega, kuna, nagu me just ütlesime, peaksid klastri ülesanded olema võimalikult üldised, peame looma ressursid, mida kasutatakse sisendina (Git-hoidla) ja väljundina (lõplikud pildid). Esimene ressurss, mida vajame, on Git, kus meie rakendus asub, 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üüpi git. URL-i võti jaotises parameetrid osutab konkreetsele hoidlale ja määrab põhiharu (see on valikuline, kuid me kirjutame selle täielikkuse huvides).

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

# 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üüpi pilt ja parameetri url väärtus osutab sisemisele OpenShifti pildiregistrile, täpsemalt sellele, mis asub veebirakenduse torujuhtme nimeruumis. Ärge unustage seda sätet muuta, kui kasutate teist nimeruumi.

Ja lõpuks, viimane ressurss, mida vajame, on samuti kujutise tüüpi ja see on viimane NGINX-pilt, mida seejärel juurutamise ajal kasutatakse:

# 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 pange tähele, et see ressurss salvestab pildi sisemises OpenShifti registris veebirakenduse torujuhtme nimeruumis.

Kõigi nende ressursside korraga loomiseks kasutame käsku create:

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

Saate veenduda, et ressursid on loodud järgmiselt:

$ tkn resource ls

Konveieri torujuhe

Nüüd, kui meil on kõik vajalikud komponendid, paneme nendest kokku torujuhtme, 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. Esimene on nimi:

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

Seejärel näeme spetsifikatsioonide jaotises viidet varem loodud ressurssidele:

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 konveier peab täitma. Esiteks peab see täitma meie juba loodud ülesande s2i-web-app:

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

See ülesanne võtab sisend- (gir-ressurss) ja väljund (ehitatud veebirakenduse-pildiressurss) parameetrid. Samuti edastame sellele spetsiaalse parameetri, et see ei kontrolliks TLS-i, kuna kasutame iseallkirjastatud 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, ainult siin nimetatakse meie juba loodud webapp-build-runtime klastri ülesannet:

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

Nagu eelmisegi ülesande puhul, edastame ressursi, kuid nüüd on see build-web-application-image (meie eelmise ülesande väljund). Ja väljundiks seadsime jälle pildi. Kuna see ülesanne tuleb täita 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 kasutamise eest, mis asuvad meie veebirakenduse k8s kataloogis, ning ka selle juurutuse värskendamise eest uute piltide loomisel. Need kaks klastriülesannet määratlesime artikli alguses.

Konveieri käivitamine

Seega luuakse kõik meie torujuhtme osad ja käivitame selle järgmise käsuga:

$ tkn pipeline start build-and-deploy-react

Selles etapis kasutatakse käsurida interaktiivselt ja vastuseks igale päringule tuleb valida sobivad ressursid: git-ressursi jaoks valige veebirakendus-repo, seejärel esimese pildiressursi jaoks sisseehitatud veebirakendus. -image ja lõpuks teise pildiressursi 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 olekut järgmise käsuga:

$ tkn pipeline logs -f

Kui torujuhe on käivitunud ja rakendus on juurutatud, saame taotleda avaldatud marsruuti järgmise käsuga:

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

Suurema visualiseerimise jaoks saate vaadata meie konveierit jaotises veebikonsooli arendajarežiimis Torujuhtmed, nagu on näidatud joonisel fig. 1.

Kaasaegsed rakendused OpenShiftis, osa 3: OpenShift kui arenduskeskkond ja OpenShifti torujuhtmed

Joonis 1. Töötavate torustike ülevaatus.

Klõpsates töötaval torujuhtmel, kuvatakse täiendavad üksikasjad, nagu on näidatud joonisel 2.

Kaasaegsed rakendused OpenShiftis, osa 3: OpenShift kui arenduskeskkond ja OpenShifti torujuhtmed

Riis. 2. Lisainfo torujuhtme kohta.

Pärast lisateavet näete vaates töötavaid rakendusi Topoloogia, nagu on näidatud joonisel 3.

Kaasaegsed rakendused OpenShiftis, osa 3: OpenShift kui arenduskeskkond ja OpenShifti torujuhtmed

Joon 3. Käivitatud pod.

Klõpsates ikooni paremas ülanurgas oleval ringil, avaneb meie rakendus, nagu on näidatud joonisel 4.

Kaasaegsed rakendused OpenShiftis, osa 3: OpenShift kui arenduskeskkond ja OpenShifti torujuhtmed

Riis. 4. Reacti rakenduse käivitamine.

Järeldus

Niisiis näitasime, kuidas OpenShiftis oma rakenduse arendusserverit käivitada ja seda kohaliku failisüsteemiga sünkroonida. Vaatasime ka, kuidas simuleerida aheldatud ehitusmalli, kasutades OpenShift Pipelines. Kõik selle artikli näidete koodid leiate siin.

Täiendavad ressursid (EN)

Eelseisvate veebiseminaride teated

Alustame reedeste veebiseminaride sarja Red Hat OpenShift Container Platformi ja Kubernetese omakogemuse kohta:

Allikas: www.habr.com

Lisa kommentaar