ProHoster > Blogi > Haldamine > Kaasaegsed rakendused OpenShiftis, osa 3: OpenShift kui arenduskeskkond ja OpenShifti torujuhtmed
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.
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:
Ja meie rakendus avaneb vaikebrauseris:
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:
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:
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:
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
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:
Installige ja konfigureerige OpenShift 4 klaster. Meie näidetes kasutatakse selleks CodeReady konteinereid (CRD), mille paigaldamise juhised leiate siin.
Kui klaster on valmis, peate sellesse installima Pipeline Operatori. Ärge kartke, see on lihtne, paigaldusjuhised siin.
Käivitage käsureatööriist create-react-app, et luua rakendus, mille seejärel juurutada (see on lihtne rakendus Reageerima).
(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:
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.
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:
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:
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:
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:
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.
Joonis 1. Töötavate torustike ülevaatus.
Klõpsates töötaval torujuhtmel, kuvatakse täiendavad üksikasjad, nagu on näidatud joonisel 2.
Riis. 2. Lisainfo torujuhtme kohta.
Pärast lisateavet näete vaates töötavaid rakendusi Topoloogia, nagu on näidatud joonisel 3.
Joon 3. Käivitatud pod.
Klõpsates ikooni paremas ülanurgas oleval ringil, avaneb meie rakendus, nagu on näidatud joonisel 4.
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.