Pozdravljeni vsi na tem blogu! To je tretja objava v seriji, v kateri prikazujemo, kako razmestiti sodobne spletne aplikacije na Red Hat OpenShift.
V prejšnjih dveh objavah smo pokazali, kako razmestiti sodobne spletne aplikacije v samo nekaj korakih in kako uporabiti novo sliko S2I skupaj s sliko strežnika HTTP, ki ni na voljo, kot je NGINX, z uporabo verižnih gradenj za orkestriranje produkcijskih uvajanj .
Danes bomo pokazali, kako zagnati razvojni strežnik za vašo aplikacijo na platformi OpenShift in ga sinhronizirati z lokalnim datotečnim sistemom, govorili pa bomo tudi o tem, kaj so cevovodi OpenShift in kako jih je mogoče uporabiti kot alternativo povezanim sklopom.
OpenShift kot razvojno okolje
Potek dela v razvoju
Kot že navedeno v , je tipičen razvojni proces za sodobne spletne aplikacije preprosto nekakšen "razvojni strežnik", ki sledi spremembam lokalnih datotek. Ko se pojavijo, se sproži gradnja aplikacije in se nato posodobi v brskalnik.
V večini sodobnih okvirov je tak "razvojni strežnik" vgrajen v ustrezna orodja ukazne vrstice.
Lokalni primer
Najprej poglejmo, kako to deluje pri lokalnem izvajanju aplikacij. Vzemimo aplikacijo kot primer iz prejšnjih člankov, čeprav skoraj enaki koncepti poteka dela veljajo v vseh drugih sodobnih okvirih.
Torej, da zaženemo "strežnik za razvijalce" v našem primeru React, bomo vnesli naslednji ukaz:
$ npm run start
Nato bomo v oknu terminala videli nekaj takega:
In naša aplikacija se bo odprla v privzetem brskalniku:
Zdaj, če spremenimo datoteko, se mora aplikacija posodobiti v brskalniku.
V redu, z razvojem v lokalnem načinu je vse jasno, toda kako doseči isto na OpenShift?
Razvojni strežnik na OpenShift
Če se spomnite, v , smo si ogledali tako imenovano fazo izvajanja slike S2I in videli, da je strežni modul privzeto odgovoren za servisiranje naše spletne aplikacije.
Vendar, če pogledate pobližje iz tega primera vsebuje spremenljivko okolja $NPM_RUN, ki vam omogoča izvajanje vašega ukaza.
Na primer, za uvedbo naše aplikacije lahko uporabimo modul nodeshift:
$ npx nodeshift --deploy.env NPM_RUN="yarn start" --dockerImage=nodeshift/ubi8-s2i-web-app
Opomba: zgornji primer je skrajšan za ponazoritev splošne ideje.
Tukaj smo naši uvedbi dodali spremenljivko okolja NPM_RUN, ki sporoči izvajalnemu okolju, naj zažene ukaz yarn start, ki zažene razvojni strežnik React znotraj našega sklopa OpenShift.
Če pogledate dnevnik tekaške enote, bo videti nekako takole:
Seveda vse to ne bo nič, dokler ne bomo uspeli sinhronizirati lokalne kode s kodo, ki je prav tako nadzorovana glede sprememb, a živi na oddaljenem strežniku.
Sinhronizacija oddaljene in lokalne kode
Na srečo lahko nodeshift zlahka pomaga pri sinhronizaciji, za spremljanje sprememb pa lahko uporabite ukaz watch.
Potem ko smo zagnali ukaz za namestitev razvojnega strežnika za našo aplikacijo, lahko varno uporabimo naslednji ukaz:
$ npx nodeshift watch
Posledično bo vzpostavljena povezava s tekočim podom, ki smo ga ustvarili malo prej, aktivirana bo sinhronizacija naših lokalnih datotek z oddaljeno gručo in datoteke v našem lokalnem sistemu se bodo začele spremljati glede sprememb.
Če torej zdaj posodobimo datoteko src/App.js, se bo sistem odzval na te spremembe, jih kopiral v oddaljeno gručo in zagnal razvojni strežnik, ki bo nato posodobil našo aplikacijo v brskalniku.
Za dokončanje slike pokažimo, kako izgledajo ti celotni ukazi:
$ 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
Ukaz watch je abstrakcija poleg ukaza oc rsync, lahko izveste več o tem, kako deluje .
To je bil primer za React, vendar je popolnoma isto metodo mogoče uporabiti z drugimi okviri, samo nastavite spremenljivko okolja NPM_RUN, kot je potrebno.
Openshift Cevovodi
Nato bomo govorili o orodju, kot je OpenShift Pipelines, in o tem, kako ga je mogoče uporabiti kot alternativo verižnim zgradbam.
Kaj so OpenShift Pipelines
OpenShift Pipelines je v oblaku izvorni sistem za stalno integracijo in dostavo CI/CD, zasnovan za organiziranje cevovodov z uporabo Tektona. Tekton je prilagodljivo odprtokodno ogrodje CI/CD, ki izvira iz Kubernetesa, ki vam omogoča avtomatizacijo uvajanja na različnih platformah (Kubernetes, brez strežnika, virtualni stroji itd.) tako, da abstrahirate osnovno plast.
Razumevanje tega članka zahteva nekaj znanja o cevovodih, zato toplo priporočamo, da ga najprej preberete .
Nastavitev vašega delovnega okolja
Če se želite igrati s primeri v tem članku, morate najprej pripraviti svoje delovno okolje:
- Namestite in konfigurirajte gručo OpenShift 4. Naši primeri za to uporabljajo vsebnike CodeReady (CRD), navodila za namestitev pa najdete .
- Ko je gruča pripravljena, morate nanjo namestiti Pipeline Operator. Ne bojte se, enostavno je, navodila za namestitev .
- Prenesi (tkn) .
- Zaženite orodje ukazne vrstice create-react-app, da ustvarite aplikacijo, ki jo boste nato uvedli (to je preprosta aplikacija ).
- (Izbirno) Klonirajte repozitorij, da lokalno zaženete primer aplikacije z npm install in nato npm start.
Repozitorij aplikacij bo imel tudi mapo k8s, ki bo vsebovala YAML-je Kubernetes/OpenShift, uporabljene za uvajanje aplikacije. V tem bomo ustvarili opravila, opravila gruč, vire in cevovode .
Začnimo
Prvi korak za naš primer je ustvariti nov projekt v gruči OpenShift. Poimenujmo ta projekt webapp-pipeline in ga ustvarimo z naslednjim ukazom:
$ oc new-project webapp-pipeline
To ime projekta se bo kasneje pojavilo v kodi, tako da, če se odločite, da ga poimenujete kako drugače, ne pozabite ustrezno urediti vzorčne kode. Od te točke naprej ne bomo šli od zgoraj navzdol, ampak od spodaj navzgor: to pomeni, da bomo najprej ustvarili vse komponente tekočega traku in šele nato samega tekočega traku.
Torej, najprej ...
Naloge
Ustvarimo nekaj nalog, ki bodo nato pomagale razmestiti aplikacijo v našem cevovodu. Prva naloga – apply_manifests_task – je odgovorna za uporabo YAML tistih virov Kubernetes (storitev, uvajanje in pot), ki se nahajajo v mapi k8s naše aplikacije. Druga naloga – update_deployment_task – je odgovorna za posodobitev že nameščene slike na tisto, ki jo je ustvaril naš cevovod.
Ne skrbite, če še ni zelo jasno. Pravzaprav so te naloge nekaj podobnega pripomočkom in jih bomo podrobneje preučili malo kasneje. Za zdaj jih le ustvarimo:
$ 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
Nato bomo z ukazom tkn CLI preverili, ali so bile naloge ustvarjene:
$ tkn task ls
NAME AGE
apply-manifests 1 minute ago
update-deployment 1 minute ago
Opomba: To so lokalne naloge za vaš trenutni projekt.
Grozdne naloge
Naloge gruče so v osnovi enake preprostim nalogam. To pomeni, da gre za večkratno uporabno zbirko korakov, ki so na tak ali drugačen način združeni pri izvajanju določene naloge. Razlika je v tem, da je naloga gruče na voljo povsod znotraj gruče. Za ogled seznama nalog gruče, ki se samodejno ustvarijo ob dodajanju operaterja cevovoda, bomo znova uporabili ukaz 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
Zdaj pa ustvarimo dve nalogi gruče. Prvi bo ustvaril sliko S2I in jo poslal v notranji register OpenShift; drugi je izdelava naše podobe na podlagi NGINX z uporabo aplikacije, ki smo jo že zgradili kot vsebino.
Ustvarite in pošljite sliko
Pri izdelavi prve naloge bomo ponovili, kar smo naredili že v prejšnjem članku o povezanih sklopih. Spomnimo se, da smo uporabili sliko S2I (ubi8-s2i-web-app) za "zgradnjo" naše aplikacije in na koncu dobili sliko, shranjeno v notranjem registru OpenShift. Zdaj bomo uporabili to sliko spletne aplikacije S2I za ustvarjanje datoteke DockerFile za našo aplikacijo in nato uporabili Buildah za izvedbo dejanske gradnje in potisnili nastalo sliko v notranji register OpenShift, saj je točno to, kar naredi OpenShift, ko svoje aplikacije uvedete z uporabo NodeShift. .
Kako smo vedeli vse to, se sprašujete? Od , smo ga samo kopirali in spremenili zase.
Torej, zdaj ustvarimo nalogo gruče s2i-web-app:
$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/clustertasks/s2i-web-app-task.yaml
Tega ne bomo podrobno analizirali, ampak se bomo osredotočili le na parameter OUTPUT_DIR:
params:
- name: OUTPUT_DIR
description: The location of the build output directory
default: build
Privzeto je ta parameter enak buildu, kamor React postavi sestavljeno vsebino. Druga ogrodja uporabljajo drugačne poti, na primer v Emberju je dist. Rezultat naše prve naloge v gruči bo slika, ki bo vsebovala HTML, JavaScript in CSS, ki smo jih zbrali.
Zgradite sliko, ki temelji na NGINX
Kar zadeva našo drugo nalogo gruče, bi morala za nas zgraditi sliko, ki temelji na NGINX, z uporabo vsebine aplikacije, ki smo jo že zgradili. V bistvu je to del prejšnjega razdelka, kjer smo si ogledali verižne zgradbe.
Da bi to naredili, bomo – povsem enako kot zgoraj – ustvarili opravilo gruče webapp-build-runtime:
$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/clustertasks/webapp-build-runtime-task.yaml
Če pogledate kodo teh nalog gruče, lahko vidite, da ne določa repozitorija Git, s katerim delamo, ali imen slik, ki jih ustvarjamo. Določimo le, kaj točno prenašamo v Git oziroma določeno sliko, kjer naj se izpiše končna slika. Zato je mogoče te naloge gruče ponovno uporabiti pri delu z drugimi aplikacijami.
In tu lepo preidemo na naslednjo točko ...
Viri
Torej, kot smo pravkar rekli, bi morale biti naloge gruče čim bolj splošne, moramo ustvariti vire, ki bodo uporabljeni kot vhod (repozitorij Git) in kot izhod (končne slike). Prvi vir, ki ga potrebujemo, je Git, kjer se nahaja naša aplikacija, nekaj takega:
# 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
Tu je PipelineResource vrste git. Ključ url v razdelku params kaže na določeno skladišče in določa glavno vejo (to ni obvezno, vendar ga pišemo zaradi popolnosti).
Zdaj moramo ustvariti vir za sliko, kjer bodo shranjeni rezultati naloge s2i-web-app, to naredimo takole:
# 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
Tu je PipelineResource vrste image in vrednost parametra url kaže na notranji register slik OpenShift, natančneje na tistega, ki se nahaja v imenskem prostoru cevovoda spletne aplikacije. Ne pozabite spremeniti te nastavitve, če uporabljate drug imenski prostor.
In končno, zadnji vir, ki ga potrebujemo, bo tudi tipska slika in to bo končna slika NGINX, ki bo nato uporabljena med uvajanjem:
# 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
Ponovno upoštevajte, da ta vir shrani sliko v notranji register OpenShift v imenskem prostoru cevovoda webapp.
Za ustvarjanje vseh teh virov hkrati uporabimo ukaz create:
$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/resources/resource.yaml
Lahko se prepričate, da so bili viri ustvarjeni takole:
$ tkn resource ls
Transportni cevovod
Zdaj, ko imamo vse potrebne komponente, iz njih sestavimo cevovod tako, da ga ustvarimo z naslednjim ukazom:
$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/pipelines/build-and-deploy-react.yaml
Toda preden zaženemo ta ukaz, si poglejmo te komponente. Prvo je ime:
apiVersion: tekton.dev/v1alpha1
kind: Pipeline
metadata:
name: build-and-deploy-react
Nato v razdelku s specifikacijami vidimo navedbo virov, ki smo jih ustvarili prej:
spec:
resources:
- name: web-application-repo
type: git
- name: built-web-application-image
type: image
- name: runtime-web-application-image
type: image
Nato ustvarimo naloge, ki jih mora dokončati naš cevovod. Najprej mora izvesti nalogo s2i-web-app, ki smo jo že ustvarili:
tasks:
- name: build-web-application
taskRef:
name: s2i-web-app
kind: ClusterTask
Ta naloga zavzema vhodne (vir gir) in izhodne (vir slike vgrajene spletne aplikacije) parametre. Posredujemo mu tudi poseben parameter, da ne preverja TLS, ker uporabljamo samopodpisana potrdila:
resources:
inputs:
- name: source
resource: web-application-repo
outputs:
- name: image
resource: built-web-application-image
params:
- name: TLSVERIFY
value: "false"
Naslednja naloga je skoraj enaka, le da se tukaj imenuje gručna naloga webapp-build-runtime, ki smo jo že ustvarili:
name: build-runtime-image
taskRef:
name: webapp-build-runtime
kind: ClusterTask
Kot pri prejšnji nalogi posredujemo vir, zdaj pa je to vgrajena slika spletne aplikacije (izhod naše prejšnje naloge). In kot izhod ponovno nastavimo sliko. Ker mora biti to opravilo izvedeno za prejšnjim, dodamo polje 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
Naslednji dve nalogi sta odgovorni za uporabo datotek YAML storitve, poti in uvajanja, ki se nahajajo v imeniku k8s naše spletne aplikacije, in tudi za posodabljanje te uvedbe pri ustvarjanju novih slik. Ti dve nalogi grozda smo definirali na začetku članka.
Zagon tekočega traku
Torej, vsi deli našega cevovoda so ustvarjeni in zagnali ga bomo z naslednjim ukazom:
$ tkn pipeline start build-and-deploy-react
Na tej stopnji se ukazna vrstica uporablja interaktivno in morate izbrati ustrezen vir kot odgovor na vsako njegovo zahtevo: za vir git izberemo spletno aplikacijo-repo, nato za prvi slikovni vir - vgrajeno spletno aplikacijo -image in nazadnje za drugi slikovni vir –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
Zdaj pa preverimo stanje cevovoda z naslednjim ukazom:
$ tkn pipeline logs -f
Ko se cevovod začne in je aplikacija nameščena, lahko zahtevamo objavljeno pot z naslednjim ukazom:
$ oc get route react-pipeline-example --template='http://{{.spec.host}}'
Za večjo vizualizacijo si lahko ogledate naš cevovod v načinu za razvijalce spletne konzole v razdelku Cevovodi, kot je prikazano na sl. 1.
Slika 1. Pregled tekočih cevovodov.
S klikom na tekoči cevovod se prikažejo dodatne podrobnosti, kot je prikazano na sliki 2.
riž. 2. Dodatne informacije o plinovodu.
Po več informacijah si lahko v pogledu ogledate zagnane aplikacije topologija, kot je prikazano na sliki 3.
Slika 3. Izstreljena kapsula.
S klikom na krog v zgornjem desnem kotu ikone se odpre naša aplikacija, kot je prikazano na sliki 4.
riž. 4. Zagon aplikacije React.
Zaključek
Tako smo pokazali, kako zagnati razvojni strežnik za vašo aplikacijo na OpenShift in ga sinhronizirati z lokalnim datotečnim sistemom. Pogledali smo tudi, kako simulirati predlogo za verižno gradnjo z uporabo cevovodov OpenShift. Vse primere kod iz tega članka lahko najdete .
Dodatni viri (EN)
- Brezplačna e-knjiga
- Drugi članki o na spletni strani Red Hat
Napovedi prihajajočih spletnih seminarjev
Začenjamo serijo petkovih spletnih seminarjev o domači izkušnji z uporabo vsebniške platforme Red Hat OpenShift in Kubernetes:
Vir: www.habr.com