🥇Moderna applikationer på OpenShift, del 3: OpenShift som utvecklingsmiljö och OpenShift Pipelines

Hej alla i denna blogg! Här är det tredje inlägget i serien där vi visar hur man distribuerar moderna webbapplikationer på Red Hat OpenShift.

I de två tidigare inläggen har vi berättat hur man distribuerar moderna webbapplikationer på bara några steg och hur man använder den nya S2I-bilden tillsammans med en färdig HTTP-serverbild, som NGINX, med hjälp av kedjade byggnader för att organisera produktionsdistributionen.

Idag visar vi hur man startar en utvecklingsserver för sin applikation på OpenShift och synkroniserar den med filsystemet lokalt, samt pratar om vad OpenShift Pipelines är och hur man kan använda det som ett alternativ till kedjade byggnader.

OpenShift som utvecklingsmiljö

Utvecklingsarbetsflöde

Som nämnts i det första inlägget, är den typiska utvecklingsprocessen för moderna webbapplikationer helt enkelt en "utvecklingsserver" som övervakar ändringar i lokala filer. När de inträffar startas en byggnad av applikationen och den uppdateras sedan i webbläsaren.

I de flesta moderna ramverk är en sådan "utvecklingsserver" inbyggd i de relevanta kommandoradsverktygen.

Lokalt exempel

Låt oss börja med att visa hur detta fungerar i fallet med lokal körning av applikationer. Som exempel tar vi applikationen React från de tidigare artiklarna, även om praktiskt taget samma processtänkande gäller för alla andra moderna ramverk.
Så för att köra en "utvecklingsserver" i vårt exempel med React, skriver vi in följande kommando:

$ npm run start

Då ser vi ungefär följande i terminalfönstret:

Och vår applikation öppnas i webbläsaren som standard:

Nu, om vi gör ändringar i filen, bör applikationen uppdateras i webbläsaren.

OK, utvecklingen i lokalt läge är tydlig, men hur får man till samma sak på OpenShift?

Utvecklingsserver på OpenShift

Om ni minns, i i det föregående inlägget, vi granskade så kallad körningsfas (run phase) av S2I-bilden och såg att servermodulen sköter vår webbapplikation som standard.

Men om man tittar lite närmare kör skript på det exemplet, så finns det en miljövariabel $NPM_RUN, som tillåter att köra sin egen kommando.

Till exempel kan man använda modulen nodeshift för att distribuera vår applikation:

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

Observera: exemplet ovan ges i en förkortad form för att illustrera den allmänna idén.

Här har vi lagt till en miljövariabel NPM_RUN i vår deployment, som säger till körrutinen att den ska köra kommandot yarn start, vilket startar Reacts utvecklingsserver inuti vår OpenShift pod.

Om vi tittar på loggen från den körande podden, så kommer det att se ungefär ut så här:

Självklart är det här allt meningslöst tills vi kan synkronisera lokal kod med den kod som också kontrolleras för förändringar, men som bor på en fjärrserver.

Synkronisering av fjärr- och lokal kod

Lyckligtvis kan nodeshift hjälpa till med synkroniseringen enkelt, och för att övervaka förändringar kan vi använda kommandot watch.

Så efter att vi har kört kommandot för att deploya utvecklingsservern för vår applikation, kan vi utan problem använda följande kommando:

$ npx nodeshift watch

Som ett resultat kommer vi att ansluta till den pod som vi skapade tidigare, synkronisera våra lokala filer med den fjärrklustret, och filerna på vårt lokala system kommer att övervakas för förändringar.

Så om vi nu uppdaterar filen src/App.js, kommer systemet att reagera på dessa förändringar, kopiera dem till den fjärrklustret och starta utvecklingsservern, som sedan uppdaterar vår applikation i webbläsaren.

För att få en komplett bild visar vi hur dessa kommandon ser ut helt:

$ 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

Kommandot watch är en abstraktion över kommandot oc rsync, mer information om hur det fungerar kan man få. här.

Detta var ett exempel för React, men exakt samma metod kan användas med andra ramverk, skriv helt enkelt miljövariabeln NPM_RUN på rätt sätt.

OpenShift Pipelines

Vidare kommer vi att tala om ett verktyg som OpenShift Pipelines, och hur det kan användas som ett alternativ till sammanhängande byggen, chained build.

Vad är OpenShift Pipelines

OpenShift Pipelines är ett molnbaserat CI/CD-system för kontinuerlig integration och leverans, som är utformat för att organisera pipeline med hjälp av Tekton. Tekton är ett flexibelt Kubernetes-nativt CI/CD-ramverk med öppen källkod som gör det möjligt att automatisera distribution på olika plattformar (Kubernetes, serverless, virtuella maskiner, etc.) genom att abstrahera bort från underliggande nivå.

För att förstå denna artikel behövs vissa kunskaper om Pipelines, så vi rekommenderar starkt att du först bekantar dig med den officiella handboken.

Konfigurera arbetsmiljö

För att leka med exemplen i denna artikel måste du först förbereda din arbetsmiljö:

Installera och konfigurera en OpenShift 4-kluster. I våra exempel använder vi CodeReady Containers (CRD), installationsanvisningar för detta kan du hitta här.
När klustret är klart måste Pipeline Operator installeras på det. Oroa dig inte, det är enkelt, installationsanvisningar här.
Ladda ner Tekton CLI (tkn) här.
Kör kommandoradsverktyget create-react-app för att skapa en applikation som sedan kommer att distribueras (detta är en enkel applikation React).
(Valfritt) Klona repositoriet för att lokalt köra exempelapplikationen med kommandot npm install och sedan npm start.

I applikationens repository finns också en mapp k8s, där YAML-filer för Kubernetes/OpenShift, som används för distribution av applikationen, kommer att ligga. Där kommer det att finnas Tasks, ClusterTasks, Resources och Pipelines som vi kommer att skapa i detta förrådet.

Låt oss börja

Först och främst, för vårt exempel måste vi skapa ett nytt projekt i OpenShift-klustret. Vi kallar detta projekt webapp-pipeline och skapar det med följande kommando:

$ oc new-project webapp-pipeline

Framöver kommer detta projektnamn att förekomma i koden, så om du väljer att kalla det något annat, glöm inte att justera koden från exemplen i enlighet därmed. Från och med denna punkt kommer vi att gå botten upp, det vill säga, först skapa alla delar av pipelinen och först därefter själva pipelinen.

Så, först och främst…

Tasks

Vi skapar ett par uppgifter (tasks) som sedan kommer att hjälpa till att distribuera applikationen inom vår pipeline. Den första uppgiften – apply_manifests_task – ansvarar för att tillämpa YAML-filerna av Kubernetes-resurser (service, deployment och route) som finns i k8s-mappen för vår applikation. Den andra uppgiften – update_deployment_task – ansvarar för att uppdatera den redan distribuerade bilden till den som skapas av vår pipeline.

Oroa dig inte om det är oklart just nu. Egentligen är dessa uppgifter något som verktyg, och vi kommer att diskutera dem mer detaljerat senare. Men först skapar vi 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

Sedan, med hjälp av tkn CLI-kommandot, kontrollerar vi att uppgifterna har skapats:

$ tkn task ls

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

Obs: detta är lokala uppgifter för ditt nuvarande projekt.

Klasuppgifter Cluster tasks

Klasuppgifter är i princip samma sak som vanliga uppgifter. Det vill säga, det är en återanvändbar samling steg som kombineras på olika sätt när en specifik uppgift körs. Skillnaden är att klasuppgiften är tillgänglig över hela klustret. För att se listan över klasuppgifter som automatiskt skapas när Pipeline Operator läggs till, använder vi återigen tkn CLI-kommandot:

$ 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

Och nu ska vi skapa två klasuppgifter. Den första kommer att generera en S2I-bild och skicka den till det interna OpenShift-registret; den andra kommer att bygga vår bild baserat på NGINX, med det innehåll som vi redan har samlat ihop.

Vi skapar och skickar bilden

När vi skapar den första uppgiften kommer vi att upprepa vad vi redan har gjort i den tidigare artikeln om relaterade samlingar. Vi påminde oss om att vi använde S2I-bilden (ubi8-s2i-web-app) för att "bygga" vår applikation, och vi slutade med en bild som lagras i OpenShifts interna register. Nu kommer vi att använda denna S2I-bild för webbapplikationen för att skapa en DockerFile för vår applikation, och sedan använder vi Buildah för att utföra den verkliga byggnationen och skicka den resulterande bilden till OpenShifts interna register, eftersom det är precis vad OpenShift gör när du distribuerar dina applikationer med NodeShift.

Frågar ni hur vi kom fram till allt detta? Från официальной версии official Node.js, vi kopierade den bara och anpassade den för oss själva.

Så, nu skapar vi en klusteruppgift s2i-web-app:

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

Vi kommer inte att gå in på detaljer om detta, utan bara stanna vid parametern OUTPUT_DIR:

params:
      - name: OUTPUT_DIR
        description: Platsen för byggutmatningskatalogen
        default: build

Som standard är den här parametern inställd på build, dit React lägger den samlade innehållet. Andra ramverk använder olika sökvägar, till exempel i Ember är det dist. Utmatningen av vår första klusteruppgift kommer att vara en bild som innehåller de HTML-, JavaScript- och CSS-filer vi har samlat.

Bygger en bild baserad på NGINX

För vår andra klusteruppgift måste den bygga en bild baserad på NGINX, som använder innehållet från vår redan samlade applikation. I huvudsak är detta den del av det föregående avsnittet där vi diskuterade sammanlänkade byggnader (chained builds).

För detta – på samma sätt som ovan – kommer vi att skapa en klusteruppgift webapp-build-runtime:

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

Om man tittar på koden för dessa klusteruppgifter ser man att det inte specificeras vilket Git-repo vi arbetar med, eller namnen på de bilder vi skapar. Vi anger bara vad vi skickar till Git, eller en viss bild dit den slutliga bilden ska matas. Just därför kan dessa klusteruppgifter återanvändas även när man arbetar med andra applikationer.

Och här övergår vi elegant till nästa punkt…

Resurser

Så, eftersom som vi just nämnde, måste klusteruppgifterna vara så allmänna som möjligt, måste vi skapa resurser som kommer att användas som indata (Git-repository) och utdata (slutbilder). Den första resursen vi behöver är Git, där vår applikation finns, något som detta:

# 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

Här har PipelineResource typen git. Nyckeln url i sektionen params anger det specifika repositoryt och ställer in master-grenen (detta är valfritt, men vi skriver den för fullständighetens skull).

Nu måste vi skapa en resurs för bilden, där resultaten av s2i-web-app-uppgiften kommer att sparas, det görs så här:

# 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

Här har PipelineResource typen image, och värdet för parametern url pekar på den interna OpenShift Image Registry, specifikt den som finns i namnområdet webapp-pipeline. Glöm inte att ändra denna parameter om du använder ett annat namnområde.

Och slutligen, den sista resursen vi behöver kommer också att ha typen image och detta blir den slutliga bilden av NGINX, som sedan kommer att användas vid distribution:

# 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

Och igen, observera att denna resurs sparar bilden i OpenShift:s interna register i namnområdet webapp-pipeline.

För att skapa alla dessa resurser på en gång, använder vi kommandot create:

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

För att säkerställa att resurserna har skapats kan man göra så här:

$ tkn resource ls

Pipeline-conveyern

Nu när vi har alla nödvändiga delar, ska vi bygga en pipeline av dem genom att köra följande kommando:

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

Men innan vi kör detta kommando, låt oss gå igenom dessa delar. Den första är namnet:

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

Sedan ser vi i sektionen spec en angivelse av resurserna som vi skapade tidigare:

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

Sedan skapar vi uppgifter som vår pipeline ska utföra. Först och främst måste den utföra den uppgift vi redan har skapat, s2i-web-app:

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

Denna uppgift tar indata (gir-resurs) och utdata (resurs built-web-application-image) parametrar. Vi skickar också en speciell parameter så att den inte verifierar TLS, eftersom vi använder självsignerade certifikat:

resurser:
        ingångar:
          - namn: källa
            resurs: web-application-repo
        utgångar:
          - namn: bild
            resurs: built-web-application-image
      parametrar:
        - namn: TLSVERIFY
          värde: "false"

Den nästa uppgiften är nästan densamma, men här anropas redan den klustertask som vi har skapat, webapp-build-runtime:

namn: build-runtime-image
    taskRef:
      namn: webapp-build-runtime
      typ: ClusterTask

Som med den föregående uppgiften överför vi en resurs, men nu är det built-web-application-image (utgången från vår tidigare uppgift). Och som utgång sätter vi återigen en bild. Eftersom denna uppgift ska utföras efter den föregående, lägger vi till fältet runAfter:

resurser:
        ingångar:
          - namn: bild
            resurs: built-web-application-image
        utgångar:
          - namn: bild
            resurs: runtime-web-application-image
        parametrar:
        - namn: TLSVERIFY
          värde: "false"
      runAfter:
        - build-web-application

De nästa två uppgifterna ansvarar för tillämpningen av YAML-filerna för tjänsten, routen och distributionen som ligger i k8s-katalogen av vår webbapplikation, samt för att uppdatera denna distribution vid skapandet av nya bilder. Dessa två klustertasks angav vi redan i början av artikeln.

Starta pipelinen

Så, alla delar av vår pipeline är skapade, och vi startar den med följande kommando:

$ tkn pipeline start build-and-deploy-react

I detta skede används kommandoraden i interaktivt läge och man måste välja lämpliga resurser som svar på varje fråga: för git-resursen väljer vi web-application-repo, sedan för den första bildresursen – built-web-application-image, och slutligen för den andra bildresursen – 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

Nu kontrollerar vi statusen för pipelinen med följande kommando:

$ tkn pipeline logs -f

Efter att pipelinen har startat och applikationen har distribuerats, begär vi den publicerade routen med följande kommando:

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

För bättre visuell översikt kan vi se vår pipeline i Developer-läget i webbkonsolen i avsnittet Pipeline, som visas i Fig. 1.

Fig. 1. Översikt över körda pipelines.

Ett klick på den körda pipelinen visar ytterligare information, som visas i Fig. 2.

Fig. 2. Ytterligare information om pipelinen.

Efter den ytterligare informationen kan man se de körda applikationerna i visningen Topologi, som visas i Fig. 3.

Fig. 3. Körd pod.

Ett klick på cirkeln i övre högra hörnet av ikonen öppnar vår applikation, som visas i Fig. 4.

Fig. 4. Körd React-applikation.

Slutsats

Så vi har visat hur man startar en utvecklingsserver för sin applikation på OpenShift och synkroniserar den med det lokala filsystemet. Vi har också gått igenom hur man simulerar en chained-build mall med hjälp av OpenShift Pipelines. All kod i exemplen från denna artikel går att hitta här.