🥇Aplikazio modernoak OpenShift-en, 3. zatia: OpenShift garapen-ingurune gisa eta OpenShift Pipelines

Kaixo guztioi blog honetan! Red Hat OpenShift-en web aplikazio modernoak nola zabaldu erakusten duen serie bateko hirugarren argitalpena da.

Aurreko bi argitalpenetan, web-aplikazio modernoak urrats gutxitan nola zabaldu eta S2I irudi berri bat erabiltzeko HTTP zerbitzariaren irudi batekin batera, NGINX adibidez, kateatutako eraikuntzak erabiliz, ekoizpen-inplementazioak antolatzeko. .

Gaur erakutsiko dugu nola exekutatu zure aplikaziorako garapen zerbitzari bat OpenShift plataforman eta fitxategi-sistema lokalarekin sinkronizatu, eta OpenShift Pipeline-ak zer diren eta estekatutako muntaketen alternatiba gisa nola erabil daitezkeen ere hitz egingo dugu.

OpenShift garapen-ingurune gisa

Garapen lan-fluxua

atalean esan bezala lehenengo mezua, web-aplikazio modernoen garapen-prozesu tipikoa "garapen-zerbitzari" moduko bat besterik ez da, fitxategi lokaletan egindako aldaketen jarraipena egiten duena. Gertatzen direnean, aplikazioaren eraikuntza abiarazten da eta ondoren arakatzailean eguneratzen da.

Esparru moderno gehienetan, hala nola, "garapen zerbitzaria" dagozkion komando lerroko tresnetan dago.

Tokiko adibidea

Lehenik eta behin, ikus dezagun nola funtzionatzen duen aplikazioak lokalean exekutatzen direnean. Har dezagun aplikazioa adibide gisa Erreakzionatzeko aurreko artikuluetatik, nahiz eta lan-fluxuaren kontzeptu ia berdinak beste esparru moderno guztietan aplikatzen diren.
Beraz, gure React adibideko "dev zerbitzaria" abiarazteko, komando hau sartuko dugu:

$ npm run start

Ondoren, terminaleko leihoan honelako zerbait ikusiko dugu:

Eta gure aplikazioa arakatzaile lehenetsian irekiko da:

Orain, fitxategian aldaketak egiten baditugu, aplikazioak arakatzailean eguneratu beharko luke.

Ados, dena argi dago tokiko moduan garapenarekin, baina nola lortu gauza bera OpenShift-en?

Garapen zerbitzaria OpenShift-en

Gogoratzen baduzu, sartu aurreko mezua, S2I irudiaren exekuzio fasea deritzona aztertu genuen eta ikusi genuen lehenespenez, zerbitzari-modulua gure web aplikazioa zaintzeaz arduratzen dela.

Hala ere, gertutik begiratuz gero exekutatu gidoia adibide horretatik, $NPM_RUN ingurune-aldagaia dauka, zure komandoa exekutatzeko aukera ematen duena.

Adibidez, nodeshift modulua erabil dezakegu gure aplikazioa zabaltzeko:

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

Oharra: goiko adibidea laburtua da ideia orokorra ilustratzeko.

Hemen NPM_RUN ingurune-aldagaia gehitu dugu gure inplementazioan, exekuzio denborari yarn start komandoa exekutatzeko esaten duena, eta horrek React garapen zerbitzaria abiarazten du gure OpenShift pod barruan.

Exekutatzen ari den pod baten erregistroa ikusten baduzu, itxura hau izango du:

Jakina, hori guztia ez da ezer izango tokiko kodea kodearekin sinkronizatu arte, aldaketak kontrolatzen dituena, baina urruneko zerbitzari batean bizi dena.

Urruneko eta tokiko kodea sinkronizatzea

Zorionez, nodeshift-ek erraz lagundu dezake sinkronizazioan, eta watch komandoa erabil dezakezu aldaketen jarraipena egiteko.

Beraz, gure aplikaziorako garapen zerbitzaria zabaltzeko komandoa exekutatu ondoren, segurtasunez hurrengo komandoa erabil dezakegu:

$ npx nodeshift watch

Ondorioz, pixka bat lehenago sortu dugun exekutatzen ari den podarekin konexio bat egingo da, gure fitxategi lokalen sinkronizazioa urruneko klusterrekin aktibatuko da eta gure sistema lokaleko fitxategiak aldaketen jarraipena egiten hasiko da.

Hori dela eta, orain src/App.js fitxategia eguneratzen badugu, sistemak aldaketa horiei erreakzionatuko die, urruneko klusterean kopiatu eta garapen zerbitzaria abiaraziko du, gero gure aplikazioa arakatzailean eguneratuko du.

Irudia osatzeko, erakutsi dezagun komando oso hauek nolakoak diren:

$ 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

Watch komandoa oc rsync komandoaren gaineko abstrakzio bat da, funtzionatzen duenari buruz gehiago jakin dezakezu Hemen.

Hau React-en adibide bat izan zen, baina metodo bera erabil daiteke beste esparru batzuekin, ezarri NPM_RUN ingurune-aldagaia behar den moduan.

Openshift Pipelines

Jarraian, OpenShift Pipelines bezalako tresna bati buruz hitz egingo dugu eta nola erabil daitekeen eraikuntza kateatuen alternatiba gisa.

Zer dira OpenShift Pipelines

OpenShift Pipelines Hodeian jatorrizko CI/CD etengabeko integrazio eta entrega sistema bat da, kanalizazioak antolatzeko Tekton erabiliz diseinatua. Tekton kode irekiko Kubernetes jatorrizko CI/CD esparru malgu bat da, hainbat plataformatan (Kubernetes, zerbitzaririk gabeko, makina birtualak, etab.) hedapena automatizatzeko aukera ematen duena, azpiko geruzatik abstraituz.

Artikulu hau ulertzeak Pipelines-en nolabaiteko ezagutza eskatzen du, beraz, lehenik irakurtzea gomendatzen dizugu testuliburu ofiziala.

Zure lan-ingurunea konfiguratzea

Artikulu honetako adibideekin jolasteko, lehenik eta behin zure lan-ingurunea prestatu behar duzu:

Instalatu eta konfiguratu OpenShift 4 kluster bat. Gure adibideek CodeReady Containers (CRD) erabiltzen dute horretarako, eta instalatzeko argibideak aurki daitezke. Hemen.
Klusterra prest dagoenean, Pipeline Operator instalatu behar duzu bertan. Ez izan beldurrik, erraza da, instalazio argibideak Hemen.
Deskargatu Tekton CLI (tkn) Hemen.
Exekutatu create-react-app komando lerroko tresna gero zabalduko duzun aplikazio bat sortzeko (aplikazio sinplea da hau Erreakzionatzeko).
(Aukerakoa) Klonatu biltegia adibideko aplikazioa lokalean exekutatzeko npm installarekin eta gero npm abiarazi.

Aplikazioen biltegiak k8s karpeta bat ere izango du, aplikazioa zabaltzeko erabiltzen diren Kubernetes/OpenShift YAMLak edukiko dituena. Honetan sortuko ditugun Zereginak, ClusterTasks, Baliabideak eta Pipelineak egongo dira. biltegiak.

Has gaitezen

Gure adibidearen lehen urratsa OpenShift klusterrean proiektu berri bat sortzea da. Dei diezaiogun proiektu honi webapp-pipeline eta sortu komando honekin:

$ oc new-project webapp-pipeline

Proiektuaren izena geroago agertuko da kodean, beraz, beste zerbait izendatzea erabakitzen baduzu, ez ahaztu adibide-kodea horren arabera editatzea. Puntu horretatik abiatuta, ez gara goitik behera joango, behetik gora baizik: hau da, lehenik eta behin garraiatzailearen osagai guztiak sortuko ditugu, eta gero garraiatzailea bera.

Beraz, lehenik eta behin...

Zereginak

Sor ditzagun zeregin pare bat, gero aplikazioa gure kanalizazioan zabaltzen lagunduko dutenak. Lehenengo zeregina - apply_manifests_task - gure aplikazioaren k8s karpetan dauden Kubernetes baliabide horien YAML aplikatzeaz arduratzen da (zerbitzua, inplementazioa eta ibilbidea). Bigarren zeregina - update_deployment_task - dagoeneko zabaldutako irudi bat gure kanalizazioak sortutakoarekin eguneratzeaz arduratzen da.

Ez kezkatu oraindik oso argi ez badago. Izan ere, zeregin hauek utilitateen antzeko zerbait dira, eta beranduago aztertuko ditugu zehatzago. Oraingoz, sortu ditzagun:

$ 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

Ondoren, tkn CLI komandoa erabiliz, zereginak sortu diren egiaztatuko dugu:

$ tkn task ls

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

Oharra: Hauek zure egungo proiekturako tokiko zereginak dira.

Kluster-zereginak

Kluster-zereginak funtsean zeregin sinpleen berdinak dira. Hau da, zeregin zehatz bat exekutatzen denean era batera edo bestera konbinatzen diren urratsen bilduma berrerabilgarria da. Aldea da kluster-zeregin bat klusterraren barruan edonon eskuragarri dagoela. Pipeline Operator gehitzean automatikoki sortzen diren klusterreko atazen zerrenda ikusteko, berriro erabiliko dugu tkn CLI komandoa:

$ 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

Sor ditzagun bi cluster zeregin. Lehenengoak S2I irudia sortuko du eta barneko OpenShift erregistrora bidaliko du; bigarrena, gure irudia NGINX-en oinarrituta eraikitzea da, dagoeneko eraiki dugun aplikazioa eduki gisa erabiliz.

Sortu eta bidali irudia

Lehenengo ataza sortzean, aurreko artikuluan loturiko batzarrei buruz lehendik egin genuena errepikatuko dugu. Gogoratu S2I irudia (ubi8-s2i-web-app) gure aplikazioa "eraikitzeko" erabili genuela, eta OpenShift barne-erregistroan gordetako irudi batekin amaitu genuela. Orain S2I web aplikazioaren irudi hau erabiliko dugu gure aplikaziorako DockerFile bat sortzeko eta, ondoren, Buildah erabiliko dugu benetako eraikuntza egiteko eta ondoriozko irudia OpenShift-en barneko erregistrora bultzatzeko, hori baita OpenShift-ek egiten duena NodeShift erabiliz zure aplikazioak zabaltzen dituzunean. .

Nola jakin genuen hori guztia, galdetzen duzu? Bertatik Node.js ofizialaren bertsio ofiziala, kopiatu eta guk geuk aldatu besterik ez dugu egin.

Beraz, orain sor dezagun s2i-web-app cluster zeregina:

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

Ez dugu hori zehatz-mehatz aztertuko, OUTPUT_DIR parametroan bakarrik zentratuko gara:

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

Lehenespenez, parametro hau eraikitzearen berdina da, hau da, React-ek muntatutako edukia jartzen du. Beste esparru batzuek bide desberdinak erabiltzen dituzte, adibidez, Ember-en dist. Gure lehen cluster zereginaren irteera bildu ditugun HTML, JavaScript eta CSS-ak dituen irudi bat izango da.

Eraiki irudi bat NGINX-en oinarrituta

Gure bigarren kluster zereginari dagokionez, NGINX-en oinarritutako irudi bat eraiki beharko luke guretzat, dagoeneko eraiki dugun aplikazioaren edukia erabiliz. Funtsean, aurreko atalaren zatia da, non kateatutako eraikuntzak aztertu genituen.

Horretarako, goian bezalaxe, kluster zeregin bat sortuko dugu webapp-build-runtime:

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

Kluster-zeregin hauen kodeari erreparatuz gero, ikusiko duzu ez duela zehazten lanean ari garen Git biltegia edo sortzen ari garen irudien izenak. Git-era zer transferitzen ari garen edo azken irudia atera behar den irudi jakin bat bakarrik zehazten dugu. Horregatik, kluster-zeregin hauek berrerabili daitezke beste aplikazio batzuekin lan egitean.

Eta hemen dotorez pasatzen gara hurrengo puntura...

baliabideak

Beraz, esan berri dugun bezala, cluster-ak ahalik eta orokorrenak izan behar direnez, sarrera gisa (Git biltegia) eta irteera gisa (azken irudiak) erabiliko diren baliabideak sortu behar ditugu. Behar dugun lehen baliabidea Git da, non gure aplikazioa dagoen, honelako zerbait:

# 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

Hemen PipelineResource git motakoa da. Params ataleko url gakoak biltegi zehatz batera seinalatzen du eta adar maisua zehazten du (hau aukerakoa da, baina osotasunerako idazten dugu).

Orain s2i-web-app zereginaren emaitzak gordeko diren irudirako baliabide bat sortu behar dugu, honela egiten da:

# 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

Hemen PipelineResource irudi motakoa da, eta url parametroaren balioak barneko OpenShift Irudi Erregistrora seinalatzen du, zehazki webapp-pipeline izen-eremuan dagoena. Ez ahaztu ezarpen hau aldatzea beste izen-espazio bat erabiltzen ari bazara.

Eta, azkenik, behar dugun azken baliabidea ere irudi motakoa izango da eta hau izango da inplementazioan erabiliko den NGINX azken irudia:

# 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

Berriz ere, kontuan izan baliabide honek irudia barneko OpenShift erregistroan gordetzen duela webapp-pipeline izen-eremuan.

Baliabide hauek guztiak aldi berean sortzeko, create komandoa erabiltzen dugu:

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

Baliabideak honela sortu direla ziurtatu dezakezu:

$ tkn resource ls

Zinta garraiatzailea

Orain beharrezko osagai guztiak ditugula, munta dezagun kanalizazio bat haietatik sortuz komando honekin:

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

Baina komando hau exekutatu aurretik, ikus ditzagun osagai hauek. Lehenengoa izena da:

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

Ondoren, zehaztapenen atalean, lehenago sortu ditugun baliabideen zantzu bat ikusiko dugu:

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

Ondoren, gure kanalizazioak bete behar dituen zereginak sortzen ditugu. Lehenik eta behin, dagoeneko sortu dugun s2i-web-app zeregina exekutatu behar du:

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

Zeregin honek sarrera (gir baliabidea) eta irteera (eraikitako web-aplikazioa-irudi baliabidea) parametroak hartzen ditu. Parametro berezi bat ere pasatzen dugu, TLS egiaztatzen ez dezan, norberak sinatutako ziurtagiriak erabiltzen ari garenez:

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

Hurrengo zeregina ia berdina da, hemen dagoeneko sortu dugun webapp-build-runtime cluster zeregina deitzen da:

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

Aurreko zereginean bezala, baliabide bat pasatzen dugu, baina orain eraiki-web-aplikazio-irudia da (gure aurreko zereginaren irteera). Eta irteera gisa berriro ezarri dugu irudia. Zeregin hau aurrekoaren ondoren exekutatu behar denez, runAfter eremua gehitzen dugu:

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

Hurrengo bi zereginak gure web aplikazioko k8s direktorioan bizi diren zerbitzu, ibilbide eta hedapen YAML fitxategiak erabiltzeaz arduratzen dira, eta irudi berriak sortzerakoan inplementazio hori eguneratzeaz ere arduratzen dira. Artikuluaren hasieran zehaztu ditugu bi multzoko zeregin hauek.

Zinta garraiatzailea abiaraztea

Beraz, gure kanalizazioaren zati guztiak sortu dira eta komando honekin exekutatu egingo dugu:

$ tkn pipeline start build-and-deploy-react

Fase honetan, komando-lerroa modu interaktiboan erabiltzen da eta bere eskaera bakoitzari erantzunez baliabide egokiak hautatu behar dituzu: git baliabiderako, hautatu web-application-repo, ondoren, lehen irudi-baliabiderako, built-web-application. -image, eta azkenik, bigarren irudi baliabiderako –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

Orain egiaztatu dezagun kanalizazioaren egoera komando hau erabiliz:

$ tkn pipeline logs -f

Behin kanalizazioa hasi eta aplikazioa zabalduta, argitaratutako ibilbidea eska dezakegu komando honekin:

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

Ikuspegi handiagoa lortzeko, gure kanalizazioa ikus dezakezu web kontsolaren Garatzaile moduan atalean hodiak, irudian ikusten den bezala. 1.

1. irudia. Martxan dauden hodien berrikuspena.

Abian dagoen kanalizazio batean klik egitean xehetasun gehigarriak bistaratzen dira, 2. irudian erakusten den moduan.

Arroza. 2. Hodiari buruzko informazio osagarria.

Informazio gehiago jaso ondoren, exekutatzen ari diren aplikazioak ikus ditzakezu ikuspegian Topologia, 3. irudian ikusten den bezala.

3. irudia. Abian jarritako poda.

Ikonoaren goiko eskuineko izkinan dagoen zirkuluan klik eginez gero, gure aplikazioa irekiko da, 4. irudian ikusten den bezala.

Arroza. 4. React aplikazioa exekutatzen.

Ondorioa

Beraz, OpenShift-en zure aplikaziorako garapen zerbitzari bat nola exekutatu eta tokiko fitxategi-sistemarekin sinkronizatzen erakutsi genuen. OpenShift Pipelines erabiliz kateatutako eraikitze txantiloi bat nola simulatu ere aztertu dugu. Artikulu honetako adibide-kode guztiak aurki daitezke Hemen.

Baliabide gehigarriak (EN)

Datozen webinarioen iragarkiak

Red Hat OpenShift Container Platform eta Kubernetes erabiliz jatorrizko esperientziari buruzko ostiraleko webinar batzuk hasiko gara:

Iturria: www.habr.com

OpenShift-en aplikazio modernoak, 3. zatia: OpenShift garapen-ingurune gisa eta OpenShift Pipelines