Hei alle sammen på denne bloggen! Dette er det tredje innlegget i en serie der vi viser hvordan du distribuerer moderne webapplikasjoner på Red Hat OpenShift.
I de to foregående innleggene viste vi hvordan du distribuerer moderne nettapplikasjoner med bare noen få trinn og hvordan du bruker et nytt S2I-bilde sammen med et hyllevare HTTP-serverbilde, for eksempel NGINX, ved å bruke kjedede bygg for å orkestrere produksjonsdistribusjoner .
I dag skal vi vise hvordan du kjører en utviklingsserver for applikasjonen din på OpenShift-plattformen og synkroniserer den med det lokale filsystemet, og snakker også om hva OpenShift Pipelines er og hvordan de kan brukes som et alternativ til koblede sammenstillinger.
OpenShift som utviklingsmiljø
Arbeidsflyt for utvikling
Som allerede nevnt i , er den typiske utviklingsprosessen for moderne webapplikasjoner ganske enkelt en slags "utviklingsserver" som sporer endringer i lokale filer. Når de oppstår, utløses applikasjonsbyggingen og deretter oppdateres den til nettleseren.
I de fleste moderne rammeverk er en slik "utviklingsserver" innebygd i de tilsvarende kommandolinjeverktøyene.
Lokalt eksempel
Først, la oss se hvordan dette fungerer når du kjører applikasjoner lokalt. La oss ta applikasjonen som et eksempel fra tidligere artikler, selv om nesten de samme arbeidsflytkonseptene gjelder i alle andre moderne rammeverk.
Så for å starte "utviklerserveren" i vårt React-eksempel, skriver vi inn følgende kommando:
$ npm run start
Så i terminalvinduet vil vi se noe slikt:
Og applikasjonen vår åpnes i standardnettleseren:
Nå, hvis vi gjør endringer i filen, bør applikasjonen oppdateres i nettleseren.
OK, alt er klart med utvikling i lokal modus, men hvordan oppnår man det samme på OpenShift?
Utviklingsserver på OpenShift
Hvis du husker, i , så vi på den såkalte kjørefasen til S2I-bildet og så at servermodulen som standard er ansvarlig for å betjene nettapplikasjonen vår.
Men hvis du tar en nærmere titt fra det eksemplet inneholder den miljøvariabelen $NPM_RUN, som lar deg utføre kommandoen din.
For eksempel kan vi bruke nodeshift-modulen til å distribuere applikasjonen vår:
$ npx nodeshift --deploy.env NPM_RUN="yarn start" --dockerImage=nodeshift/ubi8-s2i-web-app
Merk: Eksempelet ovenfor er forkortet for å illustrere den generelle ideen.
Her har vi lagt til miljøvariabelen NPM_RUN i distribusjonen vår, som forteller kjøretiden å kjøre kommandoen yarn start, som starter React-utviklingsserveren inne i OpenShift-poden vår.
Hvis du ser på loggen til en løpende pod, vil den se omtrent slik ut:
Alt dette blir selvfølgelig ingenting før vi kan synkronisere den lokale koden med koden, som også overvåkes for endringer, men lever på en ekstern server.
Synkronisering av ekstern og lokal kode
Heldigvis kan nodeshift enkelt hjelpe med synkronisering, og du kan bruke klokkekommandoen til å spore endringer.
Så etter at vi har kjørt kommandoen for å distribuere utviklingsserveren for applikasjonen vår, kan vi trygt bruke følgende kommando:
$ npx nodeshift watch
Som et resultat vil det bli opprettet en tilkobling til den løpende poden som vi opprettet litt tidligere, synkroniseringen av våre lokale filer med den eksterne klyngen vil bli aktivert, og filene på vårt lokale system vil begynne å overvåkes for endringer.
Derfor, hvis vi nå oppdaterer src/App.js-filen, vil systemet reagere på disse endringene, kopiere dem til den eksterne klyngen og starte utviklingsserveren, som deretter oppdaterer applikasjonen vår i nettleseren.
For å fullføre bildet, la oss vise hvordan hele disse kommandoene ser ut:
$ 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-kommandoen er en abstraksjon på toppen av oc rsync-kommandoen, du kan lære mer om hvordan den fungerer .
Dette var et eksempel for React, men nøyaktig samme metode kan brukes med andre rammeverk, bare angi NPM_RUN-miljøvariabelen etter behov.
Openshift rørledninger
Deretter skal vi snakke om et verktøy som OpenShift Pipelines og hvordan det kan brukes som et alternativ til kjedede bygg.
Hva er OpenShift Pipelines
OpenShift Pipelines er et skybasert CI/CD kontinuerlig integrasjon og leveringssystem designet for å organisere pipelines ved hjelp av Tekton. Tekton er et fleksibelt åpen kildekode Kubernetes-native CI/CD-rammeverk som lar deg automatisere distribusjon på ulike plattformer (Kubernetes, serverløse, virtuelle maskiner, etc.) ved å abstrahere fra det underliggende laget.
Å forstå denne artikkelen krever litt kunnskap om Pipelines, så vi anbefaler på det sterkeste at du først leser .
Sette opp arbeidsmiljøet ditt
For å leke med eksemplene i denne artikkelen, må du først forberede arbeidsmiljøet ditt:
- Installer og konfigurer en OpenShift 4-klynge. Eksemplene våre bruker CodeReady Containers (CRD) for dette, installasjonsinstruksjoner kan bli funnet for .
- Etter at klyngen er klar, må du installere Pipeline Operator på den. Ikke vær redd, det er enkelt, installasjonsinstruksjoner .
- nedlasting (tkn) .
- Kjør kommandolinjeverktøyet create-react-app for å lage en applikasjon som du deretter vil distribuere (dette er en enkel applikasjon ).
- (Valgfritt) Klon depotet for å kjøre eksempelapplikasjonen lokalt med npm install og deretter npm start.
Applikasjonslageret vil også ha en k8s-mappe, som vil inneholde Kubernetes/OpenShift YAML-ene som brukes til å distribuere applikasjonen. Det vil være Tasks, ClusterTasks, Resources og Pipelines som vi skal lage i dette .
La oss komme i gang
Det første trinnet for vårt eksempel er å lage et nytt prosjekt i OpenShift-klyngen. La oss kalle dette prosjektet webapp-pipeline og lage det med følgende kommando:
$ oc new-project webapp-pipeline
Dette prosjektnavnet vil vises i koden senere, så hvis du bestemmer deg for å navngi det noe annet, ikke glem å redigere eksempelkoden i henhold til dette. Fra dette punktet vil vi ikke gå ovenfra og ned, men nedenfra og opp: det vil si at vi først vil lage alle komponentene til transportøren, og først da selve transportøren.
Så, først og fremst...
Oppgaver
La oss lage et par oppgaver, som deretter vil bidra til å distribuere applikasjonen i vår pipeline. Den første oppgaven - application_manifests_task - er ansvarlig for å bruke YAML for de Kubernetes-ressursene (tjeneste, distribusjon og rute) som er plassert i k8s-mappen i applikasjonen vår. Den andre oppgaven – update_deployment_task – er ansvarlig for å oppdatere et allerede distribuert bilde til det som er opprettet av vår pipeline.
Ikke bekymre deg hvis det ikke er veldig klart ennå. Faktisk er disse oppgavene noe sånt som verktøy, og vi vil se på dem mer detaljert litt senere. For nå, la oss bare lage dem:
$ 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
Deretter, ved å bruke tkn CLI-kommandoen, vil vi sjekke at oppgavene er opprettet:
$ tkn task ls
NAME AGE
apply-manifests 1 minute ago
update-deployment 1 minute ago
Merk: Dette er lokale oppgaver for ditt nåværende prosjekt.
Klyngeoppgaver
Klyngeoppgaver er i utgangspunktet det samme som enkle oppgaver. Det vil si at det er en gjenbrukbar samling av trinn som kombineres på en eller annen måte når du kjører en spesifikk oppgave. Forskjellen er at en klyngeoppgave er tilgjengelig overalt i klyngen. For å se listen over klyngeoppgaver som opprettes automatisk når du legger til Pipeline Operator, vil vi igjen bruke tkn CLI-kommandoen:
$ 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
La oss nå lage to klyngeoppgaver. Den første vil generere S2I-bildet og sende det til det interne OpenShift-registeret; det andre er å bygge bildet vårt basert på NGINX, ved å bruke applikasjonen vi allerede har bygget som innhold.
Opprett og send bildet
Når vi oppretter den første oppgaven, vil vi gjenta det vi allerede gjorde i den forrige artikkelen om koblede sammenstillinger. Husk at vi brukte S2I-bildet (ubi8-s2i-web-app) for å "bygge" applikasjonen vår, og endte opp med et bilde lagret i det interne OpenShift-registeret. Nå skal vi bruke dette S2I-nettappbildet til å lage en DockerFile for appen vår og deretter bruke Buildah til å gjøre selve byggingen og skyve det resulterende bildet til det interne OpenShift-registeret, siden det er akkurat det OpenShift gjør når du distribuerer applikasjonene dine ved hjelp av NodeShift .
Hvordan visste vi alt dette, spør du? Fra , vi bare kopierte den og modifiserte den for oss selv.
Så la oss nå lage s2i-web-app klyngeoppgaven:
$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/clustertasks/s2i-web-app-task.yaml
Vi vil ikke analysere dette i detalj, men vil kun fokusere på parameteren OUTPUT_DIR:
params:
- name: OUTPUT_DIR
description: The location of the build output directory
default: build
Som standard er denne parameteren lik build, som er der React legger det sammensatte innholdet. Andre rammer bruker forskjellige baner, for eksempel i Ember er det dist. Utdataene fra vår første klyngeoppgave vil være et bilde som inneholder HTML, JavaScript og CSS vi samlet inn.
Bygg et bilde basert på NGINX
Når det gjelder vår andre klyngeoppgave, bør den bygge et NGINX-basert bilde for oss ved å bruke innholdet i applikasjonen vi allerede har bygget. I hovedsak er dette delen av forrige seksjon der vi så på lenkede bygg.
For å gjøre dette vil vi - akkurat det samme som rett ovenfor - lage en klyngeoppgave webapp-build-runtime:
$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/clustertasks/webapp-build-runtime-task.yaml
Hvis du ser på koden til disse klyngeoppgavene, kan du se at den ikke spesifiserer Git-depotet vi jobber med eller navnene på bildene vi lager. Vi spesifiserer bare hva vi overfører til Git, eller et bestemt bilde hvor det endelige bildet skal sendes ut. Det er derfor disse klyngeoppgavene kan gjenbrukes når du arbeider med andre applikasjoner.
Og her går vi grasiøst videre til neste punkt...
Ресурсы
Så siden, som vi nettopp sa, klyngeoppgaver bør være så generelle som mulig, må vi lage ressurser som vil bli brukt som input (Git-repositoriet) og som output (de endelige bildene). Den første ressursen vi trenger er Git, der applikasjonen vår ligger, noe som dette:
# 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
Her er PipelineResource av typen git. URL-nøkkelen i params-delen peker til et spesifikt depot og spesifiserer mastergrenen (dette er valgfritt, men vi skriver det for fullstendighetens skyld).
Nå må vi lage en ressurs for bildet der resultatene av s2i-web-app-oppgaven skal lagres, dette gjøres slik:
# 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
Her er PipelineResource av typen image, og verdien av url-parameteren peker til det interne OpenShift Image Registry, nærmere bestemt det som ligger i webapp-pipeline-navneområdet. Ikke glem å endre denne innstillingen hvis du bruker et annet navneområde.
Og til slutt, den siste ressursen vi trenger vil også være av typen image, og dette vil være det endelige NGINX-bildet som deretter vil bli brukt under distribusjon:
# 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
Igjen, merk at denne ressursen lagrer bildet i det interne OpenShift-registeret i webapp-pipeline-navneområdet.
For å lage alle disse ressursene på en gang, bruker vi kommandoen create:
$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/resources/resource.yaml
Du kan forsikre deg om at ressursene er opprettet slik:
$ tkn resource ls
Transportør rørledning
Nå som vi har alle nødvendige komponenter, la oss sette sammen en rørledning fra dem ved å lage den med følgende kommando:
$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/pipelines/build-and-deploy-react.yaml
Men før vi kjører denne kommandoen, la oss se på disse komponentene. Det første er navnet:
apiVersion: tekton.dev/v1alpha1
kind: Pipeline
metadata:
name: build-and-deploy-react
Så i spesifikasjonsdelen ser vi en indikasjon på ressursene vi opprettet tidligere:
spec:
resources:
- name: web-application-repo
type: git
- name: built-web-application-image
type: image
- name: runtime-web-application-image
type: image
Deretter lager vi oppgavene som rørledningen vår trenger for å fullføre. Først av alt må den utføre s2i-web-app-oppgaven vi allerede har opprettet:
tasks:
- name: build-web-application
taskRef:
name: s2i-web-app
kind: ClusterTask
Denne oppgaven tar parametere for input (gir-ressurs) og output (built-web-application-image-ressurs). Vi sender den også en spesiell parameter slik at den ikke bekrefter TLS siden vi bruker selvsignerte sertifikater:
resources:
inputs:
- name: source
resource: web-application-repo
outputs:
- name: image
resource: built-web-application-image
params:
- name: TLSVERIFY
value: "false"
Den neste oppgaven er nesten den samme, bare her kalles webapp-build-runtime cluster-oppgaven vi allerede har opprettet:
name: build-runtime-image
taskRef:
name: webapp-build-runtime
kind: ClusterTask
Som med den forrige oppgaven sender vi inn en ressurs, men nå er det bygget-web-applikasjonsbilde (resultatet av vår forrige oppgave). Og som en utgang setter vi igjen bildet. Siden denne oppgaven må utføres etter den forrige, legger vi til runAfter-feltet:
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
De neste to oppgavene er ansvarlige for å bruke tjenesten, ruten og distribusjonen YAML-filene som ligger i k8s-katalogen til webapplikasjonen vår, og også for å oppdatere denne distribusjonen når du oppretter nye bilder. Vi definerte disse to klyngeoppgavene i begynnelsen av artikkelen.
Starter transportøren
Så alle deler av rørledningen vår er opprettet, og vi kjører den med følgende kommando:
$ tkn pipeline start build-and-deploy-react
På dette stadiet brukes kommandolinjen interaktivt, og du må velge de riktige ressursene som svar på hver av dens forespørsler: for git-ressursen, velg web-application-repo, deretter for den første bilderessursen, innebygd web-applikasjon -image, og til slutt, for andre bilderessurs -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
La oss nå sjekke statusen til rørledningen ved å bruke følgende kommando:
$ tkn pipeline logs -f
Når rørledningen har startet og applikasjonen er distribuert, kan vi be om den publiserte ruten med følgende kommando:
$ oc get route react-pipeline-example --template='http://{{.spec.host}}'
For bedre visualisering kan du se vår pipeline i utviklermodusen til nettkonsollen i delen Rørledninger, som vist i fig. 1.
Figur 1. Gjennomgang av løpende rørledninger.
Ved å klikke på en løpende rørledning vises ytterligere detaljer, som vist i figur 2.
Ris. 2. Ytterligere informasjon om rørledningen.
Etter mer informasjon kan du se kjørende applikasjoner i visningen topologi, som vist i fig.3.
Fig 3. Lansert pod.
Ved å klikke på sirkelen i øvre høyre hjørne av ikonet åpnes applikasjonen vår, som vist i fig. 4.
Ris. 4. Kjører React-applikasjonen.
Konklusjon
Så vi viste hvordan du kjører en utviklingsserver for applikasjonen din på OpenShift og synkroniserer den med det lokale filsystemet. Vi har også sett på hvordan man simulerer en kjedet konstruksjonsmal ved hjelp av OpenShift Pipelines. Alle eksempelkoder fra denne artikkelen kan bli funnet .
Ytterligere ressurser (EN)
- Gratis e-bok
- Flere artikler om på Red Hat-nettstedet
Kunngjøringer om kommende webinarer
Vi starter en serie med nettseminarer på fredag om innfødt opplevelse med Red Hat OpenShift Container Platform og Kubernetes:
Kilde: www.habr.com