{"id":92048,"date":"2020-08-22T07:42:57","date_gmt":"2020-08-22T05:42:57","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/sovremennye-prilozheniya-na-openshift-chast-3-openshift-kak-sreda-razrabotki-i-konvejery-openshift-pipelines"},"modified":"2020-08-22T07:42:57","modified_gmt":"2020-08-22T05:42:57","slug":"sovremennye-prilozheniya-na-openshift-chast-3-openshift-kak-sreda-razrabotki-i-konvejery-openshift-pipelines","status":"publish","type":"post","link":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/sovremennye-prilozheniya-na-openshift-chast-3-openshift-kak-sreda-razrabotki-i-konvejery-openshift-pipelines","title":{"rendered":"Moderne applikationer p\u00e5 OpenShift, del 3: OpenShift som udviklingsmilj\u00f8 og OpenShift Pipelines","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Hej alle sammen i denne blog! Her er det tredje indl\u00e6g i serien, hvor vi viser, hvordan man implementerer moderne webapplikationer p\u00e5 Red Hat OpenShift.<\/p>\n

\"Moderne
\n
\nI de to foreg\u00e5ende indl\u00e6g har vi forklaret, hvordan man implementerer moderne webapplikationer p\u00e5 f\u00e5 trin, og hvordan man bruger det nye S2I-billede sammen med et f\u00e6rdigt HTTP-serverbillede, som NGINX, ved hj\u00e6lp af k\u00e6dede builds til at organisere produktionsimplementeringen.<\/p>\n

I dag viser vi, hvordan man starter en udviklingsserver for sin applikation p\u00e5 OpenShift-platformen og synkroniserer den med det lokale filsystem, samt taler om, hvad OpenShift Pipelines er, og hvordan de kan anvendes som et alternativ til k\u00e6dede builds.
\n<\/a><\/noindex><\/p>\n

OpenShift som udviklingsmilj\u00f8<\/h3>\n

<\/p>\n

Udviklingsarbejdsgang<\/h4>\n

\nSom n\u00e6vnt i det f\u00f8rste indl\u00e6g<\/a><\/noindex>, er den typiske udviklingsproces for moderne webapplikationer blot en slags \"udviklingsserver\", der overv\u00e5ger \u00e6ndringer i de lokale filer. N\u00e5r de opst\u00e5r, starter applikationen en bygning, og derefter opdateres den i browseren.<\/p>\n

I de fleste moderne rammer er en s\u00e5dan \"udviklingsserver\" indbygget i de relevante kommandolinjev\u00e6rkt\u00f8jer.<\/p>\n

Lokalt eksempel<\/h4>\n

\nFor at begynde, lad os se, hvordan det fungerer i tilf\u00e6lde af lokal k\u00f8rsel af applikationer. Som eksempel vil vi tage applikationen React<\/a><\/noindex> fra de tidligere artikler, selvom n\u00e6sten de samme arbejdsgangskoncept bruges i alle andre moderne rammer.
\nS\u00e5 for at starte \"udviklingsserveren\" i vores eksempel med React, indtaster vi f\u00f8lgende kommando:<\/p>\n

$ npm run start\n<\/code><\/pre>\n
\nS\u00e5 vil vi se noget lignende i terminalvinduet:<\/p>\n
\"Moderne<\/p>\n
Og vores applikation \u00e5bner i standardbrowseren:<\/p>\n
\"Moderne<\/p>\n
Nu, hvis vi foretager \u00e6ndringer i filen, skal applikationen opdateres i browseren.<\/p>\n
OK, udviklingen i lokal tilstand er klar, men hvordan f\u00e5r vi det til at fungere p\u00e5 OpenShift?<\/p>\n
Udviklingsserver p\u00e5 OpenShift<\/h4>\n
\nHvis du kan huske, i i det tidligere indl\u00e6g<\/a><\/noindex>, gennemgik vi den s\u00e5kaldte k\u00f8rselfase (run phase) af S2I-billedet og s\u00e5, at standardm\u00e6ssigt bliver vores webapplikation betjent af modulet serve.<\/p>\n
Men hvis vi ser n\u00e6rmere p\u00e5 k\u00f8rselskriptet<\/a><\/noindex> fra det eksempel, s\u00e5 er der en milj\u00f8variabel $NPM_RUN, der giver mulighed for at k\u00f8re sin egen kommando.<\/p>\n
For example, you can use the nodeshift module to deploy our application:<\/p>\n
$ npx nodeshift --deploy.env NPM_RUN="yarn start" --dockerImage=nodeshift\/ubi8-s2i-web-app\n<\/code><\/pre>\n
\nNote: the example above is presented in a shortened form to illustrate the general idea.<\/i><\/p>\n
Here we added the environment variable NPM_RUN to our deployment, which tells the execution phase to run the command yarn start, which starts the React development server inside our OpenShift pod.<\/p>\n
If you look at the logs of the running pod, it will look something like this:<\/p>\n
\"Moderne<\/p>\n
Of course, this will be meaningless until we can synchronize our local code with the code that is also monitored for changes but lives on a remote server.<\/p>\n
Synchronization of remote and local code<\/h4>\n
\nFortunately, nodeshift makes synchronization easy, and to track changes, you can use the watch command.<\/p>\n
So after we execute the command to deploy the development server for our application, we can confidently use this command:<\/p>\n
$ npx nodeshift watch\n<\/code><\/pre>\n
\nAs a result, it will connect to the running pod we created earlier, activate the synchronization of our local files with the remote cluster, and local system files will start to be monitored for changes.<\/p>\n
Therefore, if you now update the file src\/App.js, the system will react to these changes, copy them to the remote cluster, and start the development server, which will then update our application in the browser.<\/p>\n
To complete the picture, let\u2019s show how these commands look in full:<\/p>\n
$ 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\n\n$ npx nodeshift watch --strictSSL=false\n<\/code><\/pre>\n
\nThe watch command is an abstraction over the oc rsync command, you can learn more about how it works. her<\/a><\/noindex>.<\/p>\n
This was an example for React, but the same method can be used with other frameworks; just write the environment variable NPM_RUN appropriately.
\n\u2003<\/p>\n
OpenShift Pipelines<\/h3>\n
\"Moderne<\/p>\n
Next, we will discuss a tool called OpenShift Pipelines and how it can be used as an alternative to related chained builds.<\/p>\n
What are OpenShift Pipelines?<\/h4>\n
\nOpenShift Pipelines er et cloudbaseret CI\/CD-system til kontinuerlig integration og levering, designet til at organisere pipelines ved hj\u00e6lp af Tekton. Tekton er et fleksibelt Kubernetes-nativt CI\/CD-rammev\u00e6rk med \u00e5bent kildekode, der g\u00f8r det muligt at automatisere implementering p\u00e5 forskellige platforme (Kubernetes, serverless, virtuelle maskiner osv.) ved at abstrahere fra det underliggende niveau.<\/p>\n
For at forst\u00e5 denne artikel kr\u00e6ves der visse kendskaber til Pipelines, s\u00e5 vi anbefaler st\u00e6rkt at begynde med at g\u00f8re dig bekendt med den officielle vejledning<\/a><\/noindex>.<\/p>\n
Ops\u00e6tning af arbejdsomr\u00e5de<\/h4>\n
\nFor at lege med eksemplerne fra denne artikel skal du f\u00f8rst forberede dit arbejdsomr\u00e5de:<\/p>\n
    \n
  1. Installere og konfigurere et OpenShift 4-klynge. I vores eksempler bruger vi CodeReady Containers (CRD), installationsvejledningen til hvilket kan findes her<\/a><\/noindex>.<\/li>\n
  2. N\u00e5r klyngen er klar, skal du installere Pipeline Operator. Frygt ikke, det er let, installationsvejledningen findes her<\/a><\/noindex>.<\/li>\n
  3. Download Tekton CLI<\/a><\/noindex> (tkn) her<\/a><\/noindex>.<\/li>\n
  4. Starte kommandolinjev\u00e6rkt\u00f8jet create-react-app for at oprette en applikation, som derefter skal implementeres (det er en simpel applikation React<\/a><\/noindex>).<\/li>\n
  5. (Valgfrit) Klon repositoryet for lokalt at k\u00f8re applikationseksemplet ved hj\u00e6lp af npm install og derefter npm start.<\/li>\n<\/ol>\n
    \nI applikationsrepositoryet vil der ogs\u00e5 v\u00e6re en mappe k8s, hvor YAML-filerne til Kubernetes\/OpenShift, der bruges til implementeringen af applikationen, vil v\u00e6re. Der vil v\u00e6re Tasks, ClusterTasks, Resources og Pipelines, som vi vil oprette i dette repository<\/a><\/noindex>.<\/p>\n
    Lad os komme i gang<\/h4>\n
    \nF\u00f8rst skal vi for vores eksempel oprette et nyt projekt i OpenShift-klyngen. Vi kalder dette projekt webapp-pipeline og opretter det med f\u00f8lgende kommando:<\/p>\n
    $ oc new-project webapp-pipeline\n<\/code><\/pre>\n
    \nDerefter vil dette projektnavn optr\u00e6de i koden, s\u00e5 husk at \u00e6ndre koden i eksemplerne, hvis du v\u00e6lger at kalde det noget andet. Fra dette punkt vil vi g\u00e5 oppefra og ned, men begynde med at oprette alle elementerne i pipelinen og derefter selve pipelinen.<\/p>\n
    S\u00e5, f\u00f8rst og fremmest\u2026<\/p>\n
    Opgaver Tasks<\/h4>\n
    \nLad os oprette et par opgaver (tasks), som derefter vil hj\u00e6lpe med at implementere applikationen i vores pipeline. Den f\u00f8rste opgave \u2013 apply_manifests_task \u2013 er ansvarlig for anvendelsen af YAML for de Kubernetes-ressourcer (service, deployment og route), som findes i k8s-mappen i vores applikation. Den anden opgave \u2013 update_deployment_task \u2013 er ansvarlig for at opdatere det allerede implementerede billede til det, som vores pipeline skaber.<\/p>\n
    Bare rolig, hvis det ikke er helt klart endnu. Faktisk er disse opgaver noget som v\u00e6rkt\u00f8jer, og vi vil se n\u00e6rmere p\u00e5 dem lidt senere. Men lad os f\u00f8rst oprette dem:<\/p>\n
    $ oc create -f https:\/\/raw.githubusercontent.com\/nodeshift\/webapp-pipeline-tutorial\/master\/tasks\/update_deployment_task.yaml\n$ oc create -f https:\/\/raw.githubusercontent.com\/nodeshift\/webapp-pipeline-tutorial\/master\/tasks\/apply_manifests_task.yaml\n<\/code><\/pre>\n
    \nDerefter vil vi ved hj\u00e6lp af tkn CLI kommandoen kontrollere, at opgaverne blev oprettet:<\/p>\n
    $ tkn task ls\n\nNAVN                ALDER\napply-manifests     1 minut siden\nupdate-deployment   1 minut siden\n<\/code><\/pre>\n
    \nBem\u00e6rk: dette er lokale opgaver i dit nuv\u00e6rende projekt.<\/i><\/p>\n
    Klyngeopgaver Cluster tasks<\/h4>\n
    \nKlyngeopgaver er i bund og grund det samme som blot opgaver. Det vil sige, det er en genanvendelig samling af trin, der kombineres p\u00e5 forskellige m\u00e5der ved udf\u00f8relsen af en bestemt opgave. Forskellen er, at klyngeopgaven er tilg\u00e6ngelig overalt i klyngen. For at se listen over klyngeopgaver, der automatisk oprettes ved tilf\u00f8jelse af Pipeline Operator, vil vi igen bruge tkn CLI kommandoen:<\/p>\n
    $ tkn clustertask ls\n\nNAVN                       ALDER\nbuildah                    1 dag siden\nbuildah-v0-10-0            1 dag siden\njib-maven                  1 dag siden\nkn                         1 dag siden\nmaven                      1 dag siden\nopenshift-client           1 dag siden\nopenshift-client-v0-10-0   1 dag siden\ns2i                        1 dag siden\ns2i-go                     1 dag siden\ns2i-go-v0-10-0             1 dag siden\ns2i-java-11                1 dag siden\ns2i-java-11-v0-10-0        1 dag siden\ns2i-java-8                 1 dag siden\ns2i-java-8-v0-10-0         1 dag siden\ns2i-nodejs                 1 dag siden\ns2i-nodejs-v0-10-0         1 dag siden\ns2i-perl                   1 dag siden\ns2i-perl-v0-10-0           1 dag siden\ns2i-php                    1 dag siden\ns2i-php-v0-10-0            1 dag siden\ns2i-python-3               1 dag siden\ns2i-python-3-v0-10-0       1 dag siden\ns2i-ruby                   1 dag siden\ns2i-ruby-v0-10-0           1 dag siden\ns2i-v0-10-0                1 dag siden\n<\/code><\/pre>\n
    \nLad os nu oprette to klyngeopgaver. Den f\u00f8rste vil generere et S2I-billede og uploade det til den interne OpenShift-register; den anden vil bygge vores billede baseret p\u00e5 NGINX, ved at bruge det applikation, som vi allerede har samlet, som indhold.<\/p>\n
    Opretter og sender billede<\/h4>\n
    \nN\u00e5r vi opretter den f\u00f8rste opgave, gentager vi det, vi allerede har gjort i den tidligere artikel om sammenkoblede builds. Vi minder om, at vi brugte S2I-imaget (ubi8-s2i-web-app) til at 'bygge' vores applikation, og resultatet var et image, der gemmes i den interne OpenShift-registre. Nu vil vi bruge dette S2I-image af webapplikationen til at oprette et DockerFile til vores applikation, og derefter anvende Buildah til at udf\u00f8re den faktiske bygning og sende det genererede image til den interne OpenShift-registre, da det netop er det, OpenShift g\u00f8r, n\u00e5r du implementerer dine applikationer ved hj\u00e6lp af NodeShift.<\/p>\n
    Sp\u00f8rger du, hvor vi har f\u00e5et det hele fra? Fra \u043e\u0444\u0438\u0446\u0438\u0430\u043b\u044c\u043d\u043e\u0439 \u0432\u0435\u0440\u0441\u0438\u0438 official Node.js<\/a><\/noindex>, vi har blot kopieret det og tilpasset det til vores behov.<\/p>\n
    S\u00e5, lad os nu oprette en klyngeopgave s2i-web-app:<\/p>\n
    $ oc create -f https:\/\/raw.githubusercontent.com\/nodeshift\/webapp-pipeline-tutorial\/master\/clustertasks\/s2i-web-app-task.yaml\n<\/code><\/pre>\n
    \nVi vil ikke gennemg\u00e5 dette i detaljer, men blot stoppe ved parameteren OUTPUT_DIR:<\/p>\n
    params:\n      - name: OUTPUT_DIR\n        description: Placeringen af byggets output-mappe\n        default: build\n<\/code><\/pre>\n
    \nSom standard er denne parameter lig med build, og det er her, React gemmer det samlede indhold. I andre rammer anvendes der andre stier, for eksempel i Ember er det dist. Outputtet fra vores f\u00f8rste klyngeopgave vil v\u00e6re et image, der indeholder den HTML, JavaScript og CSS, vi har samlet.<\/p>\n
    Vi bygger et image baseret p\u00e5 NGINX<\/h4>\n
    \nN\u00e5r det g\u00e6lder vores anden klyngeopgave, skal den samle et image baseret p\u00e5 NGINX ved hj\u00e6lp af indholdet fra vores allerede samlede applikation. Grundl\u00e6ggende set er dette den del af det forrige afsnit, hvor vi betragtede sammenkoblede builds.<\/p>\n
    Til dette form\u00e5l \u2013 pr\u00e6cis som f\u00f8r \u2013 opretter vi en klyngeopgave webapp-build-runtime:<\/p>\n
    $ oc create -f https:\/\/raw.githubusercontent.com\/nodeshift\/webapp-pipeline-tutorial\/master\/clustertasks\/webapp-build-runtime-task.yaml\n<\/code><\/pre>\n
    \nHvis vi ser koden for disse klyngeopgaver, kan vi se, at der ikke specificeres noget Git-repositorium, som vi arbejder med, eller navne p\u00e5 de images, vi skaber. Vi angiver kun, hvad vi sender til Git, eller et image, hvortil det endelige image skal exporteres. Det er derfor, disse klyngeopgaver kan genbruges, ogs\u00e5 n\u00e5r vi arbejder med andre applikationer.<\/p>\n
    Og her g\u00e5r vi elegant videre til n\u00e6ste punkt\u2026<\/p>\n
    Ressourcer<\/h4>\n
    \nS\u00e5, som vi lige har sagt, skal klyngeopgaver v\u00e6re s\u00e5 generelle som muligt, vi skal oprette ressourcer, der skal bruges til indgangen (Git-arkiv) og udgangen (de endelige billeder). Den f\u00f8rste ressource, vi har brug for, er Git, hvor vores ans\u00f8gning befinder sig, noget i stil med dette:<\/p>\n
    # This resource is the location of the git repo with the web application source\napiVersion: tekton.dev\/v1alpha1\nkind: PipelineResource\nmetadata:\n  name: web-application-repo\nspec:\n  type: git\n  params:\n    - name: url\n      value: https:\/\/github.com\/nodeshift-starters\/react-pipeline-example\n    - name: revision\n      value: master\n<\/code><\/pre>\n
    \nHer har PipelineResource typen git. N\u00f8glen url i sektionen params angiver det specifikke arkiv og s\u00e6tter master-grenen (dette er valgfrit, men vi skriver det for fuldst\u00e6ndighedens skyld).<\/p>\n
    Nu skal vi oprette en ressource til billedet, hvor resultaterne af opgaven s2i-web-app skal gemmes, det g\u00f8res s\u00e5ledes:<\/p>\n
    # This resource is the result of running "npm run build",  the resulting built files will be located in \/opt\/app-root\/output\napiVersion: tekton.dev\/v1alpha1\nkind: PipelineResource\nmetadata:\n  name: built-web-application-image\nspec:\n  type: image\n  params:\n    - name: url\n      value: image-registry.openshift-image-registry.svc:5000\/webapp-pipeline\/built-web-application:latest\n<\/code><\/pre>\n
    \nHer har PipelineResource typen image, og v\u00e6rdien af parameteren url henviser til den interne OpenShift Image Registry, specifikt den, der findes i navnerummet webapp-pipeline. Glem ikke at \u00e6ndre denne parameter, hvis du bruger et andet navnerum.<\/p>\n
    Og endelig, den sidste ressource, vi f\u00e5r brug for, vil ogs\u00e5 have typen image, og det vil v\u00e6re det endelige NGINX-billede, som derefter vil blive brugt ved implementeringen:<\/p>\n
    # This resource is the image that will be just the static html, css, js files being run with nginx\napiVersion: tekton.dev\/v1alpha1\nkind: PipelineResource\nmetadata:\n  name: runtime-web-application-image\nspec:\n  type: image\n  params:\n    - name: url\n      value: image-registry.openshift-image-registry.svc:5000\/webapp-pipeline\/runtime-web-application:latest\n<\/code><\/pre>\n
    \nOg bem\u00e6rk igen, at denne ressource gemmer billedet i den interne OpenShift registry i navnerummet webapp-pipeline.<\/p>\n
    For at oprette alle disse ressourcer p\u00e5 \u00e9n gang, bruger vi kommandoen create:<\/p>\n
    $ oc create -f https:\/\/raw.githubusercontent.com\/nodeshift\/webapp-pipeline-tutorial\/master\/resources\/resource.yaml\n<\/code><\/pre>\n
    \nFor at bekr\u00e6fte, at ressourcerne er oprettet, kan du g\u00f8re det s\u00e5dan:<\/p>\n
    $ tkn resource ls\n<\/code><\/pre>\n
    <\/p>\n
    Pipeline-k\u00e6den<\/h4>\n
    \nNu hvor vi har alle de n\u00f8dvendige komponenter, samler vi dem i en pipeline ved at k\u00f8re f\u00f8lgende kommando:<\/p>\n
    $ oc create -f https:\/\/raw.githubusercontent.com\/nodeshift\/webapp-pipeline-tutorial\/master\/pipelines\/build-and-deploy-react.yaml\n<\/code><\/pre>\n
    \nMen f\u00f8r vi k\u00f8rer denne kommando, lad os gennemg\u00e5 disse komponenter. Den f\u00f8rste er navnet:<\/p>\n
    apiVersion: tekton.dev\/v1alpha1\nkind: Pipeline\nmetadata:\n  name: build-and-deploy-react\n<\/code><\/pre>\n
    \nDerefter ser vi i sektionen spec angivelsen af de ressourcer, vi tidligere har oprettet:<\/p>\n
    spec:\n  resources:\n    - name: web-application-repo\n      type: git\n    - name: built-web-application-image\n      type: image\n    - name: runtime-web-application-image\n      type: image\n<\/code><\/pre>\n
    \nDerefter opretter vi de opgaver, som vores pipeline skal udf\u00f8re. F\u00f8rst skal den udf\u00f8re den opgave, vi allerede har oprettet, s2i-web-app:<\/p>\n
    tasks:\n    - name: build-web-application\n      taskRef:\n        name: s2i-web-app\n        kind: ClusterTask\n<\/code><\/pre>\n
    \nDenne opgave tager indgangs (git-ressource) og udgangs (ressource built-web-application-image) parametre. Vi sender ogs\u00e5 et specielt parameter til den, s\u00e5 den ikke validerer TLS, da vi bruger selvsignerede certifikater:<\/p>\n
    resources:\n        inputs:\n          - name: source\n            resource: web-application-repo\n        outputs:\n          - name: image\n            resource: built-web-application-image\n      params:\n        - name: TLSVERIFY\n          value: "false"\n<\/code><\/pre>\n
    \nDen n\u00e6ste opgave er n\u00e6sten den samme, men her kaldes allerede den klyngopgave, vi har oprettet, webapp-build-runtime:<\/p>\n
    navn: build-runtime-image\n    taskRef:\n      navn: webapp-build-runtime\n      type: ClusterTask\n<\/code><\/pre>\n
    \nSom med den forrige opgave, sender vi ressourcen, men nu er det built-web-application-image (udgangen fra vores forrige opgave). Og som udgang angiver vi igen billedet. Da denne opgave skal udf\u00f8res efter den forrige, tilf\u00f8jer vi feltet runAfter:<\/p>\n
    resources:\n        inputs:\n          - name: image\n            resource: built-web-application-image\n        outputs:\n          - name: image\n            resource: runtime-web-application-image\n        params:\n        - name: TLSVERIFY\n          value: "false"\n      runAfter:\n        - build-web-application\n<\/code><\/pre>\n
    \nDe n\u00e6ste to opgaver er ansvarlige for anvendelse af YAML-filerne til tjenesten, ruten og udrulningen, som findes i mappen k8s i vores webapplikation, samt for at opdatere denne udrulning, n\u00e5r der oprettes nye billeder. Disse to klyngopgaver blev vi enige om i starten af artiklen.<\/p>\n
    K\u00f8r pipeline<\/h4>\n
    \nS\u00e5 alle dele af vores pipeline er skabt, og vi vil starte den med f\u00f8lgende kommando:<\/p>\n
    $ tkn pipeline start build-and-deploy-react\n<\/code><\/pre>\n
    \nP\u00e5 dette tidspunkt bruges kommandoprompten i interaktiv tilstand, og man skal v\u00e6lge de relevante ressourcer som svar p\u00e5 hver anmodning: for git-resourcen v\u00e6lger vi web-application-repo, derefter for den f\u00f8rste billedressource \u2013 built-web-application-image, og til sidst for den anden billedressource \u2013 runtime-web-application-image:<\/p>\n
    ? Choose the git resource to use for web-application-repo: web-application-repo (https:\/\/github.com\/nodeshift-starters\/react-pipeline-example)\n? 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-\napplication:latest)\n? 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\ne-web-application:latest)\nPipelinerun started: build-and-deploy-react-run-4xwsr\n<\/code><\/pre>\n
    \nNu vil vi kontrollere status for pipeline med f\u00f8lgende kommando:<\/p>\n
    $ tkn pipeline logs -f\n<\/code><\/pre>\n
    \nN\u00e5r pipeline er startet, og applikationen er blevet udrullet, kan vi anmode om den offentliggjorte rute med f\u00f8lgende kommando:<\/p>\n
    $ oc get route react-pipeline-example --template='http:\/\/{{.spec.host}}'\n<\/code><\/pre>\n
    \nFor bedre visualisering kan vi se vores pipeline i udvikler-tilstand i webkonsollen i sektionen Pipelines<\/b>, som vist p\u00e5 Figur 1.<\/p>\n
    \"Moderne<\/p>\n
    Figur 1. Oversigt over k\u00f8rende pipelines.<\/i><\/p>\n
    Et klik p\u00e5 den k\u00f8rende pipeline viser yderligere oplysninger, som vist p\u00e5 Figur 2.<\/p>\n
    \"Moderne<\/p>\n
    Figur 2. Yderligere oplysninger om pipeline.<\/i><\/p>\n
    Efter de yderligere oplysninger kan man se k\u00f8rende applikationer i visningen Topologi<\/b>, som vist p\u00e5 Figur 3.<\/p>\n
    \"Moderne<\/p>\n
    Figur 3. K\u00f8rende pod.<\/i><\/p>\n
    Et klik p\u00e5 cirklen i \u00f8verste h\u00f8jre hj\u00f8rne af ikonet \u00e5bner vores applikation, som vist p\u00e5 Figur 4.<\/p>\n
    \"Moderne<\/p>\n
    Figur 4. K\u00f8rende React-applikation.<\/i><\/p>\n
    Konklusion<\/h3>\n
    \nS\u00e5dan k\u00f8rer du en udviklingsserver for din applikation p\u00e5 OpenShift og synkroniserer den med dit lokale filsystem. Vi har ogs\u00e5 set p\u00e5, hvordan man simulerer en chained-build skabelon ved hj\u00e6lp af OpenShift Pipelines. Alle koderne fra denne artikel kan findes her<\/a><\/noindex>.<\/p>\n
    Yderligere ressourcer (EN)<\/h3>\n
    <\/p>\n