Sveiki visi šiame tinklaraštyje! Tai trečiasis įrašas iš serijos, kurioje parodome, kaip diegti modernias žiniatinklio programas naudojant Red Hat OpenShift.
Ankstesniuose dviejuose įrašuose parodėme, kaip diegti modernias žiniatinklio programas vos keliais žingsniais ir kaip naudoti naują S2I vaizdą kartu su paruoštu HTTP serverio vaizdu, pvz., NGINX, naudojant grandinines versijas gamybos diegimui organizuoti. .
Šiandien parodysime, kaip paleisti programos kūrimo serverį „OpenShift“ platformoje ir sinchronizuoti jį su vietine failų sistema, taip pat kalbėsime apie tai, kas yra „OpenShift“ vamzdynai ir kaip juos galima naudoti kaip alternatyvą susietiems rinkiniams.
OpenShift kaip kūrimo aplinka
Kūrimo darbo eiga
Kaip jau buvo nurodyta , įprastas šiuolaikinių žiniatinklio programų kūrimo procesas yra tiesiog tam tikras „kūrimo serveris“, kuris seka vietinių failų pakeitimus. Kai jie atsiranda, programos kūrimas suaktyvinamas ir atnaujinamas naršyklėje.
Daugumoje šiuolaikinių sistemų toks „kūrimo serveris“ yra integruotas į atitinkamus komandinės eilutės įrankius.
Vietinis pavyzdys
Pirmiausia pažiūrėkime, kaip tai veikia, kai programas paleidžiate vietoje. Paimkime programą kaip pavyzdį iš ankstesnių straipsnių, nors beveik tos pačios darbo eigos koncepcijos taikomos visose kitose šiuolaikinėse sistemose.
Taigi, norėdami paleisti „dev serverį“ mūsų „React“ pavyzdyje, įvesime šią komandą:
$ npm run start
Tada terminalo lange pamatysime kažką panašaus į tai:
Ir mūsų programa bus atidaryta numatytojoje naršyklėje:
Dabar, jei pakeisime failą, programa turėtų būti atnaujinta naršyklėje.
Gerai, viskas aišku su plėtra vietiniu režimu, bet kaip tą patį pasiekti naudojant „OpenShift“?
Kūrimo serveris „OpenShift“.
Jei prisimenate, į , pažvelgėme į vadinamąją S2I vaizdo paleidimo fazę ir pamatėme, kad pagal numatytuosius nustatymus aptarnavimo modulis yra atsakingas už mūsų žiniatinklio programos aptarnavimą.
Tačiau jei pažvelgsite atidžiau iš šio pavyzdžio jame yra $NPM_RUN aplinkos kintamasis, leidžiantis vykdyti komandą.
Pavyzdžiui, galime naudoti nodeshift modulį, kad įdiegtume savo programą:
$ npx nodeshift --deploy.env NPM_RUN="yarn start" --dockerImage=nodeshift/ubi8-s2i-web-app
Pastaba: Aukščiau pateiktas pavyzdys yra sutrumpintas siekiant iliustruoti bendrą idėją.
Čia į diegimą įtraukėme aplinkos kintamąjį NPM_RUN, kuris nurodo vykdymo laikui paleisti yarn start komandą, kuri paleidžia React kūrimo serverį mūsų OpenShift pod.
Jei pažvelgsite į bėgimo angos žurnalą, jis atrodys maždaug taip:
Žinoma, visa tai bus niekis, kol negalėsime sinchronizuoti vietinio kodo su kodu, kuris taip pat yra stebimas dėl pokyčių, bet gyvena nuotoliniame serveryje.
Nuotolinio ir vietinio kodo sinchronizavimas
Laimei, nodeshift gali lengvai padėti sinchronizuoti, o pakeitimams sekti galite naudoti laikrodžio komandą.
Taigi, paleidę komandą įdiegti kūrimo serverį mūsų programai, galime saugiai naudoti šią komandą:
$ npx nodeshift watch
Dėl to bus užmegztas ryšys su veikiančiu bloku, kurį sukūrėme šiek tiek anksčiau, bus suaktyvintas vietinių failų sinchronizavimas su nuotoliniu klasteriu, o vietinėje sistemoje esantys failai bus pradėti stebėti, ar nėra pakeitimų.
Todėl, jei dabar atnaujinsime failą src/App.js, sistema reaguos į šiuos pakeitimus, nukopijuos juos į nuotolinį klasterį ir paleis kūrimo serverį, kuris vėliau atnaujins mūsų programą naršyklėje.
Norėdami užbaigti paveikslėlį, parodykime, kaip atrodo visos šios komandos:
$ 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
Laikrodžio komanda yra abstrakcija virš komandos oc rsync, galite sužinoti daugiau apie tai, kaip ji veikia .
Tai buvo „React“ pavyzdys, tačiau tą patį metodą galima naudoti su kitomis sistemomis, tiesiog nustatykite aplinkos kintamąjį NPM_RUN, jei reikia.
„Openshift“ vamzdynai
Toliau kalbėsime apie tokį įrankį kaip „OpenShift Pipelines“ ir kaip jį galima naudoti kaip alternatyvą grandininėms versijoms.
Kas yra „OpenShift“ vamzdynai
„OpenShift Pipelines“ yra debesyje sukurta CI / CD nuolatinio integravimo ir pristatymo sistema, skirta vamzdynams organizuoti naudojant „Tekton“. „Tekton“ yra lanksti atvirojo kodo „Kubernetes“ CI/CD sistema, leidžianti automatizuoti diegimą įvairiose platformose („Kubernetes“, be serverių, virtualiose mašinose ir kt.), atsiribojant nuo pagrindinio sluoksnio.
Norint suprasti šį straipsnį, reikia šiek tiek žinių apie vamzdynus, todėl primygtinai rekomenduojame pirmiausia perskaityti .
Darbo aplinkos nustatymas
Norėdami žaisti su šiame straipsnyje pateiktais pavyzdžiais, pirmiausia turite paruošti savo darbo aplinką:
- Įdiekite ir sukonfigūruokite „OpenShift 4“ klasterį. Mūsų pavyzdžiuose naudojami „CodeReady“ konteineriai (CRD), kurių diegimo instrukcijas rasite .
- Kai klasteris bus paruoštas, turite jame įdiegti „Pupeline Operator“. Nebijokite, tai paprasta, montavimo instrukcijos .
- Parsisiųsti (tkn) .
- Paleiskite komandų eilutės įrankį Create-React-app, kad sukurtumėte programą, kurią vėliau įdiegsite (tai paprasta programa ).
- (Pasirenkama) Klonuokite saugyklą, kad pavyzdinė programa būtų paleista vietoje su npm install ir tada npm start.
Programų saugykloje taip pat bus k8s aplankas, kuriame bus Kubernetes / OpenShift YAML, naudojami programai diegti. Čia bus sukurtos užduotys, klasterio užduotys, ištekliai ir vamzdynai .
Pradėkime
Pirmasis mūsų pavyzdžio žingsnis yra sukurti naują projektą OpenShift klasteryje. Pavadinkime šį projektą webapp-pipeline ir sukurkime jį naudodami šią komandą:
$ oc new-project webapp-pipeline
Šis projekto pavadinimas bus rodomas kode vėliau, todėl jei nuspręsite jį pavadinti kitaip, nepamirškite atitinkamai redaguoti pavyzdinio kodo. Pradėdami nuo šio taško, eisime ne iš viršaus į apačią, o iš apačios į viršų: tai yra, pirmiausia sukursime visus konvejerio komponentus, o tik tada patį konvejerį.
Taigi, visų pirma...
Užduotys
Sukurkime keletą užduočių, kurios padės įdiegti programą mūsų sistemoje. Pirmoji užduotis - apply_manifests_task - yra atsakinga už YAML taikymą tų Kubernetes išteklių (paslaugų, diegimo ir maršruto), kurie yra mūsų programos k8s aplanke. Antroji užduotis – update_deployment_task – yra atsakinga už jau įdiegto vaizdo atnaujinimą į tą, kuris sukurtas mūsų konvejeriu.
Nesijaudinkite, jei dar nėra labai aišku. Tiesą sakant, šios užduotys yra panašios į komunalines paslaugas, ir mes jas apžvelgsime šiek tiek vėliau. Kol kas tiesiog sukurkime juos:
$ 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
Tada, naudodami komandą tkn CLI, patikrinsime, ar buvo sukurtos užduotys:
$ tkn task ls
NAME AGE
apply-manifests 1 minute ago
update-deployment 1 minute ago
Pastaba: tai yra vietinės jūsų dabartinio projekto užduotys.
Klasterio užduotys
Klasterio užduotys iš esmės yra tokios pačios kaip paprastos užduotys. Tai yra, tai yra daugkartinio naudojimo veiksmų rinkinys, kuris vienaip ar kitaip derinamas vykdant konkrečią užduotį. Skirtumas tas, kad klasterio užduotis pasiekiama visur klasterio viduje. Norėdami pamatyti klasterio užduočių, kurios automatiškai sukuriamos pridedant dujotiekio operatorių, sąrašą, vėl naudosime komandą 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
Dabar sukurkime dvi klasterio užduotis. Pirmasis sugeneruos S2I vaizdą ir išsiųs jį į vidinį OpenShift registrą; antrasis – sukurti savo įvaizdį remiantis NGINX, naudojant programą, kurią jau sukūrėme kaip turinį.
Sukurkite ir atsiųskite vaizdą
Kurdami pirmąją užduotį pakartosime tai, ką jau padarėme ankstesniame straipsnyje apie susietus mazgus. Prisiminkite, kad mes naudojome S2I vaizdą (ubi8-s2i-web-app), norėdami „kurti“ savo programą ir gavome vaizdą, saugomą „OpenShift“ vidiniame registre. Dabar naudosime šį S2I žiniatinklio programos vaizdą, kad sukurtume „DockerFile“ savo programai, o tada naudosime „Buildah“, kad atliktume tikrąjį kūrimą ir gautą vaizdą perkeltume į „OpenShift“ vidinį registrą, nes būtent tai daro „OpenShift“, kai diegiate programas naudodami „NodeShift“. .
Klausiate, iš kur mes visa tai sužinojome? Iš , mes jį tiesiog nukopijavome ir modifikavome patys.
Taigi, dabar sukurkime s2i-web-app klasterio užduotį:
$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/clustertasks/s2i-web-app-task.yaml
Mes to išsamiai neanalizuosime, o sutelksime dėmesį tik į parametrą OUTPUT_DIR:
params:
- name: OUTPUT_DIR
description: The location of the build output directory
default: build
Pagal numatytuosius nustatymus šis parametras yra lygus kūrimui, kur „React“ įdeda surinktą turinį. Kitos sistemos naudoja skirtingus kelius, pavyzdžiui, Ember tai yra dist. Pirmosios klasterio užduoties išvestis bus vaizdas su mūsų surinktu HTML, JavaScript ir CSS.
Sukurkite vaizdą, pagrįstą NGINX
Kalbant apie antrąją klasterio užduotį, ji turėtų sukurti mums NGINX pagrįstą vaizdą, naudodama mūsų jau sukurtos programos turinį. Iš esmės tai yra ankstesnio skyriaus dalis, kurioje apžvelgėme grandinines konstrukcijas.
Norėdami tai padaryti, mes – lygiai taip pat, kaip ir aukščiau – sukursime klasterio užduotį webapp-build-runtime:
$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/clustertasks/webapp-build-runtime-task.yaml
Jei pažvelgsite į šių klasterio užduočių kodą, pamatysite, kad jame nenurodoma „Git“ saugykla, su kuria dirbame, ar kuriamų vaizdų pavadinimai. Mes tik nurodome, ką tiksliai perkeliame į Git, arba tam tikrą vaizdą, kuriame turėtų būti išvestas galutinis vaizdas. Štai kodėl šias klasterio užduotis galima pakartotinai naudoti dirbant su kitomis programomis.
Ir čia grakščiai pereiname prie kito punkto...
Ištekliai
Taigi, kadangi, kaip ką tik minėjome, klasterio užduotys turėtų būti kuo bendresnės, turime sukurti išteklius, kurie bus naudojami kaip įvestis ("Git" saugykla) ir kaip išvestis (galutiniai vaizdai). Pirmasis išteklius, kurio mums reikia, yra Git, kuriame yra mūsų programa, maždaug taip:
# 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
Čia „PipelineResource“ yra git tipo. URL raktas parametrų skiltyje nurodo konkrečią saugyklą ir nurodo pagrindinę šaką (tai neprivaloma, bet mes jį rašome, kad būtų išsamumas).
Dabar turime sukurti vaizdo šaltinį, kuriame bus išsaugoti s2i-web-app užduoties rezultatai, tai daroma taip:
# 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
Čia „PipelineResource“ yra vaizdo tipo, o url parametro reikšmė nurodo vidinį „OpenShift“ vaizdo registrą, konkrečiai tą, kuris yra žiniatinklio programos konvejerinėje vardų srityje. Nepamirškite pakeisti šio nustatymo, jei naudojate kitą vardų sritį.
Galiausiai, paskutinis išteklius, kurio mums reikia, taip pat bus vaizdo tipo ir tai bus galutinis NGINX vaizdas, kuris bus naudojamas diegiant:
# 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
Vėlgi, atminkite, kad šis išteklius saugo vaizdą vidiniame OpenShift registre žiniatinklio programos vamzdyno vardų srityje.
Norėdami sukurti visus šiuos išteklius vienu metu, naudojame komandą sukurti:
$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/resources/resource.yaml
Galite įsitikinti, kad ištekliai buvo sukurti taip:
$ tkn resource ls
Konvejerio vamzdynas
Dabar, kai turime visus reikiamus komponentus, surinkime iš jų dujotiekį, sukurdami jį šia komanda:
$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/pipelines/build-and-deploy-react.yaml
Tačiau prieš paleisdami šią komandą pažvelkime į šiuos komponentus. Pirmasis yra pavadinimas:
apiVersion: tekton.dev/v1alpha1
kind: Pipeline
metadata:
name: build-and-deploy-react
Tada specifikacijų skyriuje matome anksčiau sukurtų išteklių nuorodą:
spec:
resources:
- name: web-application-repo
type: git
- name: built-web-application-image
type: image
- name: runtime-web-application-image
type: image
Tada sukuriame užduotis, kurias mūsų vamzdynas turi atlikti. Visų pirma, ji turi atlikti mūsų jau sukurtą s2i-web-app užduotį:
tasks:
- name: build-web-application
taskRef:
name: s2i-web-app
kind: ClusterTask
Šiai užduočiai reikalingi įvesties (gir resursas) ir išvesties (built-web-application-image resource) parametrai. Taip pat perduodame specialų parametrą, kad jis netikrintų TLS, nes naudojame savarankiškai pasirašytus sertifikatus:
resources:
inputs:
- name: source
resource: web-application-repo
outputs:
- name: image
resource: built-web-application-image
params:
- name: TLSVERIFY
value: "false"
Kita užduotis beveik tokia pati, tik čia mūsų jau sukurta webapp-build-runtime klasterio užduotis vadinama:
name: build-runtime-image
taskRef:
name: webapp-build-runtime
kind: ClusterTask
Kaip ir ankstesnėje užduotyje, perduodame išteklius, bet dabar tai yra „build-web-application-image“ (ankstesnės užduoties išvestis). Ir kaip išvestį vėl nustatome vaizdą. Kadangi ši užduotis turi būti vykdoma po ankstesnės, pridedame lauką 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
Kitos dvi užduotys yra atsakingos už paslaugos, maršruto ir diegimo YAML failų, esančių mūsų žiniatinklio programos k8s kataloge, naudojimą, taip pat už šio diegimo atnaujinimą kuriant naujus vaizdus. Straipsnio pradžioje apibrėžėme šias dvi klasterio užduotis.
Konvejerio paleidimas
Taigi, visos mūsų dujotiekio dalys yra sukurtos, ir mes ją paleisime naudodami šią komandą:
$ tkn pipeline start build-and-deploy-react
Šiame etape komandų eilutė naudojama interaktyviai ir jums reikia pasirinkti tinkamus išteklius, atsakydami į kiekvieną jos užklausą: git ištekliui pasirinkite žiniatinklio programa-repo, tada pirmajam vaizdo ištekliui įtaisyta žiniatinklio programa. -image ir galiausiai antrajam vaizdo šaltiniui -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
Dabar patikrinkime dujotiekio būseną naudodami šią komandą:
$ tkn pipeline logs -f
Kai dujotiekis prasidės ir programa bus įdiegta, galime pateikti užklausą dėl paskelbto maršruto naudodami šią komandą:
$ oc get route react-pipeline-example --template='http://{{.spec.host}}'
Norėdami geriau vizualizuoti, galite peržiūrėti mūsų konvejerį žiniatinklio konsolės kūrėjo režimu skiltyje Vamzdynai, kaip parodyta pav. 1.
1 pav. Einamųjų vamzdynų apžvalga.
Spustelėjus veikiantį dujotiekį, rodoma papildoma informacija, kaip parodyta 2 paveiksle.
Ryžiai. 2. Papildoma informacija apie dujotiekį.
Gavę daugiau informacijos, rodinyje galite matyti veikiančias programas Topologija, kaip parodyta 3 pav.
3 pav. Paleista anga.
Spustelėjus apskritimą viršutiniame dešiniajame piktogramos kampe, atidaroma mūsų programa, kaip parodyta 4 pav.
Ryžiai. 4. Paleidžiama React programa.
išvada
Taigi, mes parodėme, kaip paleisti programos kūrimo serverį naudojant „OpenShift“ ir sinchronizuoti jį su vietine failų sistema. Taip pat pažvelgėme į tai, kaip modeliuoti grandininio kūrimo šabloną naudojant „OpenShift Pipelines“. Galima rasti visus šio straipsnio kodų pavyzdžius .
Papildomi ištekliai (EN)
- Elektroninė knyga nemokamai
- Daugiau straipsnių Red Hat svetainėje
Pranešimai apie artėjančius internetinius seminarus
Pradedame penktadienio internetinių seminarų seriją apie vietinę patirtį naudojant „Red Hat OpenShift Container Platform“ ir „Kubernetes“:
Šaltinis: www.habr.com