Hej alle på denne blog! Dette er det tredje indlæg i en serie, hvor vi viser, hvordan man implementerer moderne webapplikationer på Red Hat OpenShift.
I de foregående to indlæg viste vi, hvordan man implementerer moderne webapplikationer i nogle få trin, og hvordan man bruger et nyt S2I-image sammen med et off-the-shelf HTTP-serverbillede, såsom NGINX, ved hjælp af kædede builds til at orkestrere produktionsimplementeringer .
I dag vil vi vise, hvordan du kører en udviklingsserver til din applikation på OpenShift-platformen og synkroniserer den med det lokale filsystem, og vi vil også tale om, hvad OpenShift Pipelines er, og hvordan de kan bruges som et alternativ til sammenkædede assemblies.
OpenShift som udviklingsmiljø
Udviklings arbejdsgang
Som allerede nævnt i , er den typiske udviklingsproces for moderne webapplikationer simpelthen en slags "udviklingsserver", der sporer ændringer til lokale filer. Når de opstår, udløses applikationsopbygningen, og derefter opdateres den til browseren.
I de fleste moderne rammer er en sådan "udviklingsserver" indbygget i de tilsvarende kommandolinjeværktøjer.
Lokalt eksempel
Lad os først se, hvordan dette fungerer, når du kører applikationer lokalt. Lad os tage applikationen som et eksempel fra tidligere artikler, selvom næsten de samme workflow-koncepter gælder i alle andre moderne rammer.
Så for at starte "dev-serveren" i vores React-eksempel, indtaster vi følgende kommando:
$ npm run start
Så i terminalvinduet vil vi se noget som dette:
Og vores applikation åbner i standardbrowseren:
Nu, hvis vi foretager ændringer i filen, bør applikationen opdatere i browseren.
OK, alt er klart med udvikling i lokal tilstand, men hvordan opnår man det samme på OpenShift?
Udviklingsserver på OpenShift
Hvis du husker, i , så vi på den såkaldte kørselsfase af S2I-billedet og så, at servermodulet som standard er ansvarlig for at servicere vores webapplikation.
Men hvis man kigger nærmere fra det eksempel indeholder den miljøvariablen $NPM_RUN, som giver dig mulighed for at udføre din kommando.
For eksempel kan vi bruge nodeshift-modulet til at implementere vores applikation:
$ npx nodeshift --deploy.env NPM_RUN="yarn start" --dockerImage=nodeshift/ubi8-s2i-web-app
Bemærk: Ovenstående eksempel er forkortet for at illustrere den generelle idé.
Her har vi tilføjet miljøvariablen NPM_RUN til vores implementering, som fortæller runtime at køre kommandoen yarn start, som starter React-udviklingsserveren inde i vores OpenShift-pod.
Hvis du ser på loggen for en kørende pod, vil den se sådan ud:
Alt dette bliver selvfølgelig ingenting, før vi kan synkronisere den lokale kode med koden, som også overvåges for ændringer, men bor på en ekstern server.
Synkronisering af fjern- og lokalkode
Heldigvis kan nodeshift nemt hjælpe med synkronisering, og du kan bruge watch-kommandoen til at spore ændringer.
Så efter at vi har kørt kommandoen til at implementere udviklingsserveren til vores applikation, kan vi trygt bruge følgende kommando:
$ npx nodeshift watch
Som et resultat vil der blive oprettet forbindelse til den kørende pod, som vi oprettede lidt tidligere, synkroniseringen af vores lokale filer med fjernklyngen vil blive aktiveret, og filerne på vores lokale system vil begynde at blive overvåget for ændringer.
Derfor, hvis vi nu opdaterer src/App.js-filen, vil systemet reagere på disse ændringer, kopiere dem til fjernklyngen og starte udviklingsserveren, som derefter opdaterer vores applikation i browseren.
For at fuldende billedet, lad os vise, hvordan hele disse kommandoer ser ud:
$ 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 abstraktion oven på kommandoen oc rsync, du kan lære mere om, hvordan den virker .
Dette var et eksempel for React, men den nøjagtige samme metode kan bruges med andre rammer, bare indstil NPM_RUN miljøvariablen efter behov.
Openshift rørledninger
Dernæst vil vi tale om et værktøj som OpenShift Pipelines, og hvordan det kan bruges som et alternativ til kædede builds.
Hvad er OpenShift Pipelines
OpenShift Pipelines er et cloud-native CI/CD kontinuerlig integration og leveringssystem designet til at organisere pipelines ved hjælp af Tekton. Tekton er en fleksibel open source Kubernetes-native CI/CD-ramme, der giver dig mulighed for at automatisere implementering på forskellige platforme (Kubernetes, serverløse, virtuelle maskiner osv.) ved at abstrahere fra det underliggende lag.
Forståelse af denne artikel kræver en vis viden om Pipelines, så vi anbefaler stærkt, at du først læser .
Opsætning af dit arbejdsmiljø
For at lege med eksemplerne i denne artikel skal du først forberede dit arbejdsmiljø:
- Installer og konfigurer en OpenShift 4-klynge. Vores eksempler bruger CodeReady Containers (CRD) til dette, som du kan finde installationsinstruktioner til .
- Når klyngen er klar, skal du installere Pipeline Operator på den. Vær ikke bange, det er nemt, installationsvejledning .
- downloade (tkn) .
- Kør kommandolinjeværktøjet create-react-app for at oprette en applikation, som du derefter vil implementere (dette er en simpel applikation ).
- (Valgfrit) Klon lageret for at køre eksempelapplikationen lokalt med npm install og derefter npm start.
Applikationslageret vil også have en k8s-mappe, som vil indeholde de Kubernetes/OpenShift YAML'er, der bruges til at implementere applikationen. Der vil være Opgaver, ClusterTasks, Ressourcer og Pipelines, som vi vil skabe i dette .
Lad os komme igang
Det første trin i vores eksempel er at oprette et nyt projekt i OpenShift-klyngen. Lad os kalde dette projekt webapp-pipeline og oprette det med følgende kommando:
$ oc new-project webapp-pipeline
Dette projektnavn vil dukke op i koden senere, så hvis du beslutter dig for at navngive det noget andet, så glem ikke at redigere eksempelkoden i overensstemmelse hermed. Fra dette punkt vil vi ikke gå top-down, men bottom-up: det vil sige, vi vil først oprette alle komponenterne i transportøren, og først derefter selve transportøren.
Så først og fremmest...
Opgaver
Lad os oprette et par opgaver, som derefter vil hjælpe med at implementere applikationen i vores pipeline. Den første opgave - application_manifests_task - er ansvarlig for at anvende YAML for disse Kubernetes-ressourcer (service, implementering og rute), der er placeret i k8s-mappen i vores applikation. Den anden opgave – update_deployment_task – er ansvarlig for at opdatere et allerede implementeret image til det, der er oprettet af vores pipeline.
Bare rolig, hvis det ikke er meget klart endnu. Faktisk er disse opgaver noget som hjælpeprogrammer, og vi vil se nærmere på dem lidt senere. Indtil videre, lad os bare oprette 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
Derefter vil vi ved hjælp af tkn CLI-kommandoen kontrollere, at opgaverne er blevet oprettet:
$ tkn task ls
NAME AGE
apply-manifests 1 minute ago
update-deployment 1 minute ago
Bemærk: Dette er lokale opgaver for dit nuværende projekt.
Klynge opgaver
Klyngeopgaver er grundlæggende det samme som simple opgaver. Det vil sige, at det er en genanvendelig samling af trin, der kombineres på den ene eller anden måde, når man kører en specifik opgave. Forskellen er, at en klyngeopgave er tilgængelig overalt i klyngen. For at se listen over klyngeopgaver, der oprettes automatisk, når du tilføjer Pipeline Operator, vil vi igen bruge 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
Lad os nu oprette to klyngeopgaver. Den første vil generere S2I-billedet og sende det til den interne OpenShift-registrering; det andet er at bygge vores image baseret på NGINX ved at bruge den applikation, vi allerede har bygget som indhold.
Opret og send billedet
Når vi opretter den første opgave, vil vi gentage, hvad vi allerede gjorde i den forrige artikel om sammenkædede samlinger. Husk, at vi brugte S2I-billedet (ubi8-s2i-web-app) til at "bygge" vores applikation og endte med et billede gemt i OpenShifts interne registreringsdatabase. Nu vil vi bruge dette S2I-webappbillede til at oprette en DockerFile til vores app og derefter bruge Buildah til at lave den faktiske build og skubbe det resulterende billede til det interne OpenShift-register, da det er præcis, hvad OpenShift gør, når du implementerer dine applikationer ved hjælp af NodeShift .
Hvordan vidste vi alt dette, spørger du? Fra , vi har bare kopieret det og ændret det for os selv.
Så lad os nu oprette s2i-web-app klyngeopgaven:
$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/clustertasks/s2i-web-app-task.yaml
Vi vil ikke analysere dette i detaljer, 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 parameter lig med build, hvilket er hvor React placerer det samlede indhold. Andre rammer bruger forskellige stier, for eksempel i Ember er det dist. Outputtet af vores første klyngeopgave vil være et billede, der indeholder HTML, JavaScript og CSS, vi indsamlede.
Byg et billede baseret på NGINX
Hvad angår vores anden klyngeopgave, skulle den bygge et NGINX-baseret billede til os ved at bruge indholdet af den applikation, vi allerede har bygget. I det væsentlige er dette den del af det forrige afsnit, hvor vi så på kædede builds.
For at gøre dette vil vi - nøjagtigt det samme som lige ovenfor - oprette en klyngeopgave 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 for disse klyngeopgaver, kan du se, at den ikke specificerer det Git-lager, vi arbejder med, eller navnene på de billeder, vi opretter. Vi specificerer kun, hvad vi præcist overfører til Git, eller et bestemt billede, hvor det endelige billede skal udskrives. Derfor kan disse klyngeopgaver genbruges, når man arbejder med andre applikationer.
Og her går vi yndefuldt videre til næste punkt...
ressourcer
Så da, som vi lige sagde, klyngeopgaver skal være så generelle som muligt, er vi nødt til at skabe ressourcer, der vil blive brugt som input (Git-lageret) og som output (de endelige billeder). Den første ressource, vi har brug for, er Git, hvor vores applikation findes, noget 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 af typen git. URL-nøglen i params-sektionen peger på et specifikt lager og specificerer mastergrenen (dette er valgfrit, men vi skriver det for fuldstændighedens skyld).
Nu skal vi oprette en ressource til billedet, hvor resultaterne af s2i-web-app opgaven vil blive gemt, dette gøres sådan:
# 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 af typen image, og værdien af url-parameteren peger på det interne OpenShift Image Registry, specifikt det der er placeret i webapp-pipeline-navnerummet. Glem ikke at ændre denne indstilling, hvis du bruger et andet navneområde.
Og endelig vil den sidste ressource, vi har brug for, også være af typen image, og dette vil være det endelige NGINX-billede, der derefter vil blive brugt under udrulningen:
# 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
Bemærk igen, at denne ressource gemmer billedet i den interne OpenShift-registrering i webapp-pipeline-navneområdet.
For at oprette alle disse ressourcer på én gang bruger vi kommandoen create:
$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/resources/resource.yaml
Du kan sikre dig, at ressourcerne er oprettet på denne måde:
$ tkn resource ls
Transportør rørledning
Nu hvor vi har alle de nødvendige komponenter, lad os samle en pipeline fra dem ved at oprette 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 kører denne kommando, lad os se på disse komponenter. Det første er navnet:
apiVersion: tekton.dev/v1alpha1
kind: Pipeline
metadata:
name: build-and-deploy-react
Så i spec-afsnittet ser vi en indikation af de ressourcer, vi oprettede tidligere:
spec:
resources:
- name: web-application-repo
type: git
- name: built-web-application-image
type: image
- name: runtime-web-application-image
type: image
Derefter opretter vi de opgaver, som vores pipeline skal udføre. Først og fremmest skal den udføre s2i-web-app-opgaven, vi allerede har oprettet:
tasks:
- name: build-web-application
taskRef:
name: s2i-web-app
kind: ClusterTask
Denne opgave tager input (gir ressource) og output (built-web-application-image ressource) parametre. Vi giver den også en speciel parameter, så den ikke verificerer TLS, da vi bruger selvsignerede certifikater:
resources:
inputs:
- name: source
resource: web-application-repo
outputs:
- name: image
resource: built-web-application-image
params:
- name: TLSVERIFY
value: "false"
Den næste opgave er næsten den samme, kun her hedder webapp-build-runtime cluster-opgaven, vi allerede har oprettet:
name: build-runtime-image
taskRef:
name: webapp-build-runtime
kind: ClusterTask
Som med den forrige opgave sender vi en ressource ind, men nu er det indbygget web-applikationsbillede (output af vores tidligere opgave). Og som output sætter vi igen billedet. Da denne opgave skal udføres efter den forrige, tilføjer vi feltet 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
De næste to opgaver er ansvarlige for at bruge tjenesten, ruten og implementeringen YAML-filer, der findes i k8s-biblioteket i vores webapplikation, og også for at opdatere denne implementering, når der oprettes nye billeder. Vi definerede disse to klyngeopgaver i begyndelsen af artiklen.
Start af transportbåndet
Så alle dele af vores pipeline er oprettet, og vi kører den med følgende kommando:
$ tkn pipeline start build-and-deploy-react
På dette stadium bruges kommandolinjen interaktivt, og du skal vælge de relevante ressourcer som svar på hver af dens anmodninger: for git-ressourcen, vælg web-applikation-repo, derefter for den første billedressource, indbygget web-applikation -image, og endelig for anden billedressource -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
Lad os nu tjekke status for pipelinen ved hjælp af følgende kommando:
$ tkn pipeline logs -f
Når pipelinen er startet, og applikationen er blevet implementeret, kan vi anmode om den offentliggjorte rute med følgende kommando:
$ oc get route react-pipeline-example --template='http://{{.spec.host}}'
For bedre visualisering kan du se vores pipeline i webkonsollens udviklertilstand i afsnittet Rørledninger, som vist i fig. 1.
Fig.1. Gennemgang af løbende rørledninger.
Ved at klikke på en løbende pipeline vises yderligere detaljer, som vist i figur 2.
Ris. 2. Yderligere oplysninger om rørledningen.
Efter mere information kan du se kørende applikationer i visningen Topologi, som vist i fig.
Fig 3. Lanceret pod.
Ved at klikke på cirklen i øverste højre hjørne af ikonet åbnes vores applikation, som vist i Fig. 4.
Ris. 4. Kører React-applikationen.
Konklusion
Så vi viste, hvordan man kører en udviklingsserver til din applikation på OpenShift og synkroniserer den med det lokale filsystem. Vi så også på, hvordan man simulerer en kædet skabelon ved hjælp af OpenShift Pipelines. Alle eksempelkoder fra denne artikel kan findes .
Yderligere ressourcer (EN)
- Gratis e-bog
- Mere om på Red Hats hjemmeside
Meddelelser om kommende webinarer
Vi starter en serie af fredagswebinarer om indfødte erfaringer med at bruge Red Hat OpenShift Container Platform og Kubernetes:
Kilde: www.habr.com