🥇Mūsdienīgas lietojumprogrammas vietnē OpenShift, 3. daļa: OpenShift kā izstrādes vide un OpenShift cauruļvadi

Sveiki visiem šajā emuārā! Šis ir trešais ieraksts sērijā, kurā mēs parādām, kā izvietot modernas tīmekļa lietojumprogrammas Red Hat OpenShift.

Iepriekšējos divos ziņojumos mēs parādījām, kā izvietot modernas tīmekļa lietojumprogrammas tikai dažās darbībās un kā izmantot jaunu S2I attēlu kopā ar gatavu HTTP servera attēlu, piemēram, NGINX, izmantojot ķēdes būvējumus, lai organizētu ražošanas izvietošanu. .

Šodien mēs parādīsim, kā palaist izstrādes serveri jūsu lietojumprogrammai OpenShift platformā un sinhronizēt to ar vietējo failu sistēmu, kā arī runāsim par to, kas ir OpenShift cauruļvadi un kā tos var izmantot kā alternatīvu saistītajiem mezgliem.

OpenShift kā izstrādes vide

Izstrādes darbplūsma

Kā jau teikts pirmais ieraksts, tipisks mūsdienu tīmekļa lietojumprogrammu izstrādes process ir vienkārši sava veida “izstrādes serveris”, kas izseko izmaiņas lokālajos failos. Kad tie notiek, tiek aktivizēta lietojumprogrammas būvēšana un pēc tam tā tiek atjaunināta pārlūkprogrammā.

Lielākajā daļā mūsdienu sistēmu šāds “attīstības serveris” ir iebūvēts atbilstošajos komandrindas rīkos.

Vietējais piemērs

Vispirms apskatīsim, kā tas darbojas, palaižot lietojumprogrammas lokāli. Ņemsim lietojumprogrammu kā piemēru Reaģēt no iepriekšējiem rakstiem, lai gan gandrīz tādas pašas darbplūsmas koncepcijas tiek izmantotas visos citos mūsdienu ietvaros.
Tātad, lai palaistu "dev serveri" mūsu React piemērā, mēs ievadīsim šādu komandu:

$ npm run start

Tad termināļa logā mēs redzēsim kaut ko līdzīgu:

Un mūsu lietojumprogramma tiks atvērta noklusējuma pārlūkprogrammā:

Tagad, ja mēs veiksim izmaiņas failā, lietojumprogramma ir jāatjaunina pārlūkprogrammā.

Labi, ar izstrādi vietējā režīmā viss ir skaidrs, bet kā to pašu panākt OpenShift?

Attīstības serveris uz OpenShift

Ja atceries, iekšā iepriekšējā ziņa, mēs apskatījām tā saukto S2I attēla palaišanas fāzi un redzējām, ka pēc noklusējuma apkalpošanas modulis ir atbildīgs par mūsu tīmekļa lietojumprogrammas apkalpošanu.

Tomēr, ja paskatās tuvāk palaist skriptu no šī piemēra tajā ir $NPM_RUN vides mainīgais, kas ļauj izpildīt komandu.

Piemēram, mēs varam izmantot moduli nodeshift, lai izvietotu mūsu lietojumprogrammu:

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

Piezīme. Iepriekš minētais piemērs ir saīsināts, lai ilustrētu vispārējo ideju.

Šeit mēs savai izvietošanai esam pievienojuši vides mainīgo NPM_RUN, kas liek izpildlaikam palaist yarn start komandu, kas palaiž React izstrādes serveri mūsu OpenShift podā.

Ja paskatās uz skriešanas pāksts žurnālu, tas izskatīsies apmēram šādi:

Protams, tas viss nebūs nekas, kamēr nevarēsim sinhronizēt lokālo kodu ar kodu, kas arī tiek uzraudzīts, lai nerodas izmaiņas, bet dzīvo uz attālā servera.

Tālvadības un vietējā koda sinhronizēšana

Par laimi, nodeshift var viegli palīdzēt sinhronizācijā, un jūs varat izmantot komandu skatīties, lai izsekotu izmaiņām.

Tātad pēc tam, kad esam izpildījuši komandu, lai mūsu lietojumprogrammai izvietotu izstrādes serveri, mēs varam droši izmantot šo komandu:

$ npx nodeshift watch

Rezultātā tiks izveidots savienojums ar nedaudz agrāk izveidoto darbvirsmu, tiks aktivizēta mūsu vietējo failu sinhronizācija ar attālo klasteru, un mūsu vietējās sistēmas faili tiks pārraudzīti, vai nav izmaiņu.

Tāpēc, ja tagad atjaunināsim failu src/App.js, sistēma reaģēs uz šīm izmaiņām, kopēs tās uz attālo klasteru un startēs izstrādes serveri, kas pēc tam atjauninās mūsu lietojumprogrammu pārlūkprogrammā.

Lai pabeigtu attēlu, parādīsim, kā izskatās visas šīs komandas:

$ 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 komanda ir abstrakcija virs komandas oc rsync, jūs varat uzzināt vairāk par to, kā tā darbojas šeit.

Šis bija piemērs React, taču tieši to pašu metodi var izmantot ar citām sistēmām, vienkārši iestatiet NPM_RUN vides mainīgo pēc vajadzības.

Openshift cauruļvadi

Tālāk mēs runāsim par tādu rīku kā OpenShift Pipelines un to, kā to var izmantot kā alternatīvu ķēdītajām būvēm.

Kas ir OpenShift cauruļvadi

OpenShift Pipelines ir mākoņa CI/CD nepārtrauktas integrācijas un piegādes sistēma, kas paredzēta cauruļvadu organizēšanai, izmantojot Tekton. Tekton ir elastīga atvērtā pirmkoda Kubernetes CI/CD ietvars, kas ļauj automatizēt izvietošanu dažādās platformās (Kubernetes, bez servera, virtuālās mašīnas utt.), abstrahējoties no pamatā esošā slāņa.

Lai saprastu šo rakstu, ir nepieciešamas zināmas zināšanas par cauruļvadiem, tāpēc mēs ļoti iesakām vispirms to izlasīt oficiālā mācību grāmata.

Jūsu darba vides iekārtošana

Lai spēlētu ar šajā rakstā minētajiem piemēriem, vispirms ir jāsagatavo sava darba vide:

Instalējiet un konfigurējiet OpenShift 4 klasteru. Mūsu piemēros šim nolūkam tiek izmantoti CodeReady konteineri (CRD), kuru instalēšanas instrukcijas var atrast šeit.
Kad klasteris ir gatavs, tajā jāinstalē Pipeline Operator. Nebaidieties, tas ir vienkārši, uzstādīšanas instrukcijas šeit.
Lejupielādēt Tekton CLI (tkn) šeit.
Palaidiet komandrindas rīku Create-react-app, lai izveidotu lietojumprogrammu, kuru pēc tam izvietosit (šī ir vienkārša lietojumprogramma Reaģēt).
(Neobligāti) Klonējiet repozitoriju, lai lokāli palaistu parauga lietojumprogrammu ar npm instalēšanu un pēc tam npm start.

Lietojumprogrammu repozitorijā būs arī mape k8s, kurā būs Kubernetes/OpenShift YAML, kas izmantoti lietojumprogrammas izvietošanai. Būs uzdevumi, klasteru uzdevumi, resursi un cauruļvadi, kurus mēs izveidosim šajā krātuves.

Sāksim

Pirmais solis mūsu piemērā ir jauna projekta izveide OpenShift klasterī. Nosauksim šo projektu webapp-pipeline un izveidosim to ar šādu komandu:

$ oc new-project webapp-pipeline

Šis projekta nosaukums parādīsies kodā vēlāk, tādēļ, ja nolemjat to nosaukt citādi, neaizmirstiet attiecīgi rediģēt parauga kodu. Sākot no šī punkta, mēs virzīsimies nevis no augšas uz leju, bet gan no apakšas uz augšu: tas ir, mēs vispirms izveidosim visas konveijera sastāvdaļas un tikai pēc tam pašu konveijeru.

Tātad, pirmkārt...

Uzdevumi

Izveidosim dažus uzdevumus, kas pēc tam palīdzēs izvietot lietojumprogrammu mūsu konveijerā. Pirmais uzdevums - apply_manifests_task - ir atbildīgs par YAML lietošanu tiem Kubernetes resursiem (pakalpojums, izvietošana un maršruts), kas atrodas mūsu lietojumprogrammas mapē k8s. Otrais uzdevums — update_deployment_task — ir atbildīgs par jau izvietota attēla atjaunināšanu uz mūsu konveijera izveidoto attēlu.

Neuztraucieties, ja tas vēl nav īsti skaidrs. Faktiski šie uzdevumi ir kaut kas līdzīgs utilītprogrammām, un mēs tos aplūkosim sīkāk nedaudz vēlāk. Pagaidām vienkārši izveidosim tos:

$ 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

Pēc tam, izmantojot komandu tkn CLI, mēs pārbaudīsim, vai uzdevumi ir izveidoti:

$ tkn task ls

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

Piezīme. Šie ir jūsu pašreizējā projekta vietējie uzdevumi.

Klasteru uzdevumi

Klastera uzdevumi būtībā ir tādi paši kā vienkāršie uzdevumi. Tas ir, tā ir atkārtoti lietojama darbību kolekcija, kas vienā vai otrā veidā tiek apvienota, izpildot konkrētu uzdevumu. Atšķirība ir tāda, ka klastera uzdevums ir pieejams visur klasterī. Lai skatītu klastera uzdevumu sarakstu, kas tiek automātiski izveidoti, pievienojot cauruļvada operatoru, mēs atkal izmantosim komandu 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

Tagad izveidosim divus klastera uzdevumus. Pirmais ģenerēs S2I attēlu un nosūtīs to uz iekšējo OpenShift reģistru; otrs ir veidot savu tēlu, pamatojoties uz NGINX, izmantojot lietojumprogrammu, ko jau esam izveidojuši kā saturu.

Izveidojiet un nosūtiet attēlu

Veidojot pirmo uzdevumu, mēs atkārtosim to, ko jau izdarījām iepriekšējā rakstā par saistītajām montāžām. Atgādiniet, ka mēs izmantojām S2I attēlu (ubi8-s2i-web-app), lai “veidotu” savu lietojumprogrammu, un galu galā tika izveidots attēls, kas tika saglabāts OpenShift iekšējā reģistrā. Tagad mēs izmantosim šo S2I tīmekļa lietotnes attēlu, lai savai lietotnei izveidotu DockerFile, un pēc tam izmantosim Buildah, lai veiktu faktisko veidošanu un nosūtītu iegūto attēlu OpenShift iekšējam reģistram, jo tas ir tieši tas, ko OpenShift dara, kad izvietojat savas lietojumprogrammas, izmantojot NodeShift. .

Kā mēs to visu uzzinājām, jūs jautājat? No oficiālā oficiālā Node.js versija, mēs to vienkārši nokopējām un modificējām sev.

Tātad, tagad izveidosim s2i-web-app klastera uzdevumu:

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

Mēs to neanalizēsim detalizēti, bet koncentrēsimies tikai uz parametru OUTPUT_DIR:

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

Pēc noklusējuma šis parametrs ir vienāds ar build, kur React ievieto salikto saturu. Citi ietvari izmanto dažādus ceļus, piemēram, Ember tas ir dist. Mūsu pirmā klastera uzdevuma izvade būs attēls, kas satur mūsu apkopoto HTML, JavaScript un CSS.

Izveidojiet attēlu, pamatojoties uz NGINX

Kas attiecas uz mūsu otro klastera uzdevumu, tam vajadzētu izveidot uz NGINX balstītu attēlu, izmantojot mūsu jau izveidotās lietojumprogrammas saturu. Būtībā šī ir daļa no iepriekšējās sadaļas, kurā mēs apskatījām ķēdītos būvējumus.

Lai to izdarītu, mēs — tieši tāpat kā iepriekš — izveidosim klastera uzdevumu webapp-build-runtime:

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

Ja paskatās uz šo klastera uzdevumu kodu, jūs varat redzēt, ka tajā nav norādīts Git repozitorijs, ar kuru mēs strādājam, vai mūsu veidojamo attēlu nosaukumi. Mēs tikai norādām, ko tieši mēs pārsūtām uz Git, vai noteiktu attēlu, kurā jāizvada gala attēls. Tāpēc šos klastera uzdevumus var izmantot atkārtoti, strādājot ar citām lietojumprogrammām.

Un šeit mēs graciozi pārejam pie nākamā punkta...

Resursi

Tātad, tā kā, kā mēs tikko teicām, klastera uzdevumiem jābūt pēc iespējas vispārīgākiem, mums ir jāizveido resursi, kas tiks izmantoti kā ievade (Git repozitorijs) un kā izvade (galīgie attēli). Pirmais mums nepieciešamais resurss ir Git, kurā atrodas mūsu lietojumprogramma, apmēram šādi:

# 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

Šeit PipelineResource ir git tipa. URL atslēga sadaļā parametri norāda uz konkrētu repozitoriju un norāda galveno atzaru (tas nav obligāts, taču mēs to rakstām, lai nodrošinātu pilnīgumu).

Tagad mums ir jāizveido attēla resurss, kurā tiks saglabāti s2i-web-app uzdevuma rezultāti, tas tiek darīts šādi:

# 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

Šeit PipelineResource ir attēla tips, un url parametra vērtība norāda uz iekšējo OpenShift attēla reģistru, jo īpaši to, kas atrodas tīmekļa lietotnes konveijera nosaukumvietā. Ja izmantojat citu nosaukumvietu, neaizmirstiet mainīt šo iestatījumu.

Visbeidzot, pēdējais mums nepieciešamais resurss būs arī attēla tipa, un tas būs pēdējais NGINX attēls, kas tiks izmantots izvietošanas laikā:

# 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

Atkal ņemiet vērā, ka šis resurss saglabā attēlu iekšējā OpenShift reģistrā tīmekļa lietotnes konveijera nosaukumvietā.

Lai izveidotu visus šos resursus vienlaikus, mēs izmantojam komandu Create:

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

Varat pārliecināties, ka resursi ir izveidoti šādi:

$ tkn resource ls

Konveijera cauruļvads

Tagad, kad mums ir visas nepieciešamās sastāvdaļas, saliksim no tiem cauruļvadu, izveidojot to ar šādu komandu:

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

Bet pirms šīs komandas palaišanas apskatīsim šos komponentus. Pirmais ir nosaukums:

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

Pēc tam specifikāciju sadaļā mēs redzam norādi uz iepriekš izveidotajiem resursiem:

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

Pēc tam mēs izveidojam uzdevumus, kas mūsu konveijeram ir jāpabeidz. Pirmkārt, tai ir jāizpilda mūsu jau izveidotais s2i-web-app uzdevums:

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

Šim uzdevumam tiek izmantoti ievades (gir resurss) un izvades (built-web-application-image resurss) parametri. Mēs tam arī nododam īpašu parametru, lai tas nepārbaudītu TLS, jo mēs izmantojam pašparakstītus sertifikātus:

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

Nākamais uzdevums ir gandrīz tāds pats, tikai šeit mūsu jau izveidotais webapp-build-runtime klastera uzdevums tiek saukts:

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

Tāpat kā iepriekšējā uzdevumā, mēs nododam resursu, bet tagad tas ir iebūvēts tīmekļa lietojumprogrammas attēls (mūsu iepriekšējā uzdevuma izvade). Un kā izvadi mēs atkal iestatām attēlu. Tā kā šis uzdevums ir jāizpilda pēc iepriekšējā, mēs pievienojam lauku 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

Nākamie divi uzdevumi ir atbildīgi par pakalpojuma, maršruta un izvietošanas YAML failu izmantošanu, kas atrodas mūsu tīmekļa lietojumprogrammas k8s direktorijā, kā arī par šīs izvietošanas atjaunināšanu, veidojot jaunus attēlus. Raksta sākumā mēs definējām šos divus klastera uzdevumus.

Konveijera palaišana

Tātad visas mūsu cauruļvada daļas ir izveidotas, un mēs to izpildīsim ar šādu komandu:

$ tkn pipeline start build-and-deploy-react

Šajā posmā komandrinda tiek izmantota interaktīvi, un jums ir jāizvēlas atbilstošie resursi, atbildot uz katru tās pieprasījumu: git resursam atlasiet tīmekļa lietojumprogrammu repo, pēc tam pirmajam attēla resursam iebūvēto tīmekļa lietojumprogrammu. -image un, visbeidzot, otrajam attēla resursam -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

Tagad pārbaudīsim cauruļvada statusu, izmantojot šādu komandu:

$ tkn pipeline logs -f

Kad cauruļvads ir sācies un lietojumprogramma ir izvietota, mēs varam pieprasīt publicēto maršrutu ar šādu komandu:

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

Lai iegūtu labāku vizualizāciju, sadaļā tīmekļa konsoles izstrādātāja režīmā varat skatīt mūsu konveijeru Cauruļvadi, kā parādīts attēlā. 1.

1. att. Darbojošo cauruļvadu apskats.

Noklikšķinot uz darbojas cauruļvada, tiek parādīta papildu informācija, kā parādīts 2. attēlā.

Rīsi. 2. Papildu informācija par cauruļvadu.

Pēc plašākas informācijas skatā varat redzēt darbojošās lietojumprogrammas Topoloģija, kā parādīts 3. att.

3. att. Palaists pods.

Noklikšķinot uz apļa ikonas augšējā labajā stūrī, tiek atvērta mūsu lietojumprogramma, kā parādīts 4. attēlā.

Rīsi. 4. Palaižot lietojumprogrammu React.

Secinājums

Tātad, mēs parādījām, kā palaist izstrādes serveri jūsu lietojumprogrammai OpenShift un sinhronizēt to ar vietējo failu sistēmu. Mēs arī apskatījām, kā simulēt ķēdes veidošanas veidni, izmantojot OpenShift cauruļvadus. Visus šī raksta kodu piemērus var atrast šeit.