{"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\/sv\/blog\/administrirovanie\/sovremennye-prilozheniya-na-openshift-chast-3-openshift-kak-sreda-razrabotki-i-konvejery-openshift-pipelines","title":{"rendered":"Moderna applikationer p\u00e5 OpenShift, del 3: OpenShift som utvecklingsmilj\u00f6 och OpenShift Pipelines.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Hej alla i denna blogg! H\u00e4r \u00e4r det tredje inl\u00e4gget i serien d\u00e4r vi visar hur man distribuerar moderna webbapplikationer p\u00e5 Red Hat OpenShift.<\/p>\n

\"Moderna
\n
\nI de tv\u00e5 tidigare inl\u00e4ggen har vi ber\u00e4ttat hur man distribuerar moderna webbapplikationer p\u00e5 bara n\u00e5gra steg och hur man anv\u00e4nder den nya S2I-bilden tillsammans med en f\u00e4rdig HTTP-serverbild, som NGINX, med hj\u00e4lp av kedjade byggnader f\u00f6r att organisera produktionsdistributionen.<\/p>\n

Idag visar vi hur man startar en utvecklingsserver f\u00f6r sin applikation p\u00e5 OpenShift och synkroniserar den med filsystemet lokalt, samt pratar om vad OpenShift Pipelines \u00e4r och hur man kan anv\u00e4nda det som ett alternativ till kedjade byggnader.
\n<\/a><\/noindex><\/p>\n

OpenShift som utvecklingsmilj\u00f6<\/h3>\n

<\/p>\n

Utvecklingsarbetsfl\u00f6de<\/h4>\n

\nSom n\u00e4mnts i det f\u00f6rsta inl\u00e4gget<\/a><\/noindex>, \u00e4r den typiska utvecklingsprocessen f\u00f6r moderna webbapplikationer helt enkelt en \"utvecklingsserver\" som \u00f6vervakar \u00e4ndringar i lokala filer. N\u00e4r de intr\u00e4ffar startas en byggnad av applikationen och den uppdateras sedan i webbl\u00e4saren.<\/p>\n

I de flesta moderna ramverk \u00e4r en s\u00e5dan \"utvecklingsserver\" inbyggd i de relevanta kommandoradsverktygen.<\/p>\n

Lokalt exempel<\/h4>\n

\nL\u00e5t oss b\u00f6rja med att visa hur detta fungerar i fallet med lokal k\u00f6rning av applikationer. Som exempel tar vi applikationen React<\/a><\/noindex> fr\u00e5n de tidigare artiklarna, \u00e4ven om praktiskt taget samma processt\u00e4nkande g\u00e4ller f\u00f6r alla andra moderna ramverk.
\nS\u00e5 f\u00f6r att k\u00f6ra en \"utvecklingsserver\" i v\u00e5rt exempel med React, skriver vi in f\u00f6ljande kommando:<\/p>\n

$ npm run start\n<\/code><\/pre>\n
\nD\u00e5 ser vi ungef\u00e4r f\u00f6ljande i terminalf\u00f6nstret:<\/p>\n
\"Moderna<\/p>\n
Och v\u00e5r applikation \u00f6ppnas i webbl\u00e4saren som standard:<\/p>\n
\"Moderna<\/p>\n
Nu, om vi g\u00f6r \u00e4ndringar i filen, b\u00f6r applikationen uppdateras i webbl\u00e4saren.<\/p>\n
OK, utvecklingen i lokalt l\u00e4ge \u00e4r tydlig, men hur f\u00e5r man till samma sak p\u00e5 OpenShift?<\/p>\n
Utvecklingsserver p\u00e5 OpenShift<\/h4>\n
\nOm ni minns, i i det f\u00f6reg\u00e5ende inl\u00e4gget<\/a><\/noindex>, vi granskade s\u00e5 kallad k\u00f6rningsfas (run phase) av S2I-bilden och s\u00e5g att servermodulen sk\u00f6ter v\u00e5r webbapplikation som standard.<\/p>\n
Men om man tittar lite n\u00e4rmare k\u00f6r skript<\/a><\/noindex> p\u00e5 det exemplet, s\u00e5 finns det en milj\u00f6variabel $NPM_RUN, som till\u00e5ter att k\u00f6ra sin egen kommando.<\/p>\n
Till exempel kan man anv\u00e4nda modulen nodeshift f\u00f6r att distribuera v\u00e5r applikation:<\/p>\n
$ npx nodeshift --deploy.env NPM_RUN=\"yarn start\" --dockerImage=nodeshift\/ubi8-s2i-web-app\n<\/code><\/pre>\n
\nObservera: exemplet ovan ges i en f\u00f6rkortad form f\u00f6r att illustrera den allm\u00e4nna id\u00e9n.<\/i><\/p>\n
H\u00e4r har vi lagt till en milj\u00f6variabel NPM_RUN i v\u00e5r deployment, som s\u00e4ger till k\u00f6rrutinen att den ska k\u00f6ra kommandot yarn start, vilket startar Reacts utvecklingsserver inuti v\u00e5r OpenShift pod.<\/p>\n
Om vi tittar p\u00e5 loggen fr\u00e5n den k\u00f6rande podden, s\u00e5 kommer det att se ungef\u00e4r ut s\u00e5 h\u00e4r:<\/p>\n
\"Moderna<\/p>\n
Sj\u00e4lvklart \u00e4r det h\u00e4r allt meningsl\u00f6st tills vi kan synkronisera lokal kod med den kod som ocks\u00e5 kontrolleras f\u00f6r f\u00f6r\u00e4ndringar, men som bor p\u00e5 en fj\u00e4rrserver.<\/p>\n
Synkronisering av fj\u00e4rr- och lokal kod<\/h4>\n
\nLyckligtvis kan nodeshift hj\u00e4lpa till med synkroniseringen enkelt, och f\u00f6r att \u00f6vervaka f\u00f6r\u00e4ndringar kan vi anv\u00e4nda kommandot watch.<\/p>\n
S\u00e5 efter att vi har k\u00f6rt kommandot f\u00f6r att deploya utvecklingsservern f\u00f6r v\u00e5r applikation, kan vi utan problem anv\u00e4nda f\u00f6ljande kommando:<\/p>\n
$ npx nodeshift watch\n<\/code><\/pre>\n
\nSom ett resultat kommer vi att ansluta till den pod som vi skapade tidigare, synkronisera v\u00e5ra lokala filer med den fj\u00e4rrklustret, och filerna p\u00e5 v\u00e5rt lokala system kommer att \u00f6vervakas f\u00f6r f\u00f6r\u00e4ndringar.<\/p>\n
S\u00e5 om vi nu uppdaterar filen src\/App.js, kommer systemet att reagera p\u00e5 dessa f\u00f6r\u00e4ndringar, kopiera dem till den fj\u00e4rrklustret och starta utvecklingsservern, som sedan uppdaterar v\u00e5r applikation i webbl\u00e4saren.<\/p>\n
F\u00f6r att f\u00e5 en komplett bild visar vi hur dessa kommandon ser ut helt:<\/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
\nKommandot watch \u00e4r en abstraktion \u00f6ver kommandot oc rsync, mer information om hur det fungerar kan man f\u00e5. h\u00e4r<\/a><\/noindex>.<\/p>\n
Detta var ett exempel f\u00f6r React, men exakt samma metod kan anv\u00e4ndas med andra ramverk, skriv helt enkelt milj\u00f6variabeln NPM_RUN p\u00e5 r\u00e4tt s\u00e4tt.
\n\u2003<\/p>\n
OpenShift Pipelines<\/h3>\n
\"Moderna<\/p>\n
Vidare kommer vi att tala om ett verktyg som OpenShift Pipelines, och hur det kan anv\u00e4ndas som ett alternativ till sammanh\u00e4ngande byggen, chained build.<\/p>\n
Vad \u00e4r OpenShift Pipelines<\/h4>\n
\nOpenShift Pipelines \u00e4r ett molnbaserat CI\/CD-system f\u00f6r kontinuerlig integration och leverans, som \u00e4r utformat f\u00f6r att organisera pipeline med hj\u00e4lp av Tekton. Tekton \u00e4r ett flexibelt Kubernetes-nativt CI\/CD-ramverk med \u00f6ppen k\u00e4llkod som g\u00f6r det m\u00f6jligt att automatisera distribution p\u00e5 olika plattformar (Kubernetes, serverless, virtuella maskiner, etc.) genom att abstrahera bort fr\u00e5n underliggande niv\u00e5.<\/p>\n
F\u00f6r att f\u00f6rst\u00e5 denna artikel beh\u00f6vs vissa kunskaper om Pipelines, s\u00e5 vi rekommenderar starkt att du f\u00f6rst bekantar dig med den officiella handboken<\/a><\/noindex>.<\/p>\n
Konfigurera arbetsmilj\u00f6<\/h4>\n
\nF\u00f6r att leka med exemplen i denna artikel m\u00e5ste du f\u00f6rst f\u00f6rbereda din arbetsmilj\u00f6:<\/p>\n
    \n
  1. Installera och konfigurera en OpenShift 4-kluster. I v\u00e5ra exempel anv\u00e4nder vi CodeReady Containers (CRD), installationsanvisningar f\u00f6r detta kan du hitta h\u00e4r<\/a><\/noindex>.<\/li>\n
  2. N\u00e4r klustret \u00e4r klart m\u00e5ste Pipeline Operator installeras p\u00e5 det. Oroa dig inte, det \u00e4r enkelt, installationsanvisningar h\u00e4r<\/a><\/noindex>.<\/li>\n
  3. Ladda ner Tekton CLI<\/a><\/noindex> (tkn) h\u00e4r<\/a><\/noindex>.<\/li>\n
  4. K\u00f6r kommandoradsverktyget create-react-app f\u00f6r att skapa en applikation som sedan kommer att distribueras (detta \u00e4r en enkel applikation React<\/a><\/noindex>).<\/li>\n
  5. (Valfritt) Klona repositoriet f\u00f6r att lokalt k\u00f6ra exempelapplikationen med kommandot npm install och sedan npm start.<\/li>\n<\/ol>\n
    \nI applikationens repository finns ocks\u00e5 en mapp k8s, d\u00e4r YAML-filer f\u00f6r Kubernetes\/OpenShift, som anv\u00e4nds f\u00f6r distribution av applikationen, kommer att ligga. D\u00e4r kommer det att finnas Tasks, ClusterTasks, Resources och Pipelines som vi kommer att skapa i detta f\u00f6rr\u00e5det<\/a><\/noindex>.<\/p>\n
    L\u00e5t oss b\u00f6rja<\/h4>\n
    \nF\u00f6rst och fr\u00e4mst, f\u00f6r v\u00e5rt exempel m\u00e5ste vi skapa ett nytt projekt i OpenShift-klustret. Vi kallar detta projekt webapp-pipeline och skapar det med f\u00f6ljande kommando:<\/p>\n
    $ oc new-project webapp-pipeline\n<\/code><\/pre>\n
    \nFram\u00f6ver kommer detta projektnamn att f\u00f6rekomma i koden, s\u00e5 om du v\u00e4ljer att kalla det n\u00e5got annat, gl\u00f6m inte att justera koden fr\u00e5n exemplen i enlighet d\u00e4rmed. Fr\u00e5n och med denna punkt kommer vi att g\u00e5 botten upp, det vill s\u00e4ga, f\u00f6rst skapa alla delar av pipelinen och f\u00f6rst d\u00e4refter sj\u00e4lva pipelinen.<\/p>\n
    S\u00e5, f\u00f6rst och fr\u00e4mst\u2026<\/p>\n
    Tasks<\/h4>\n
    \nVi skapar ett par uppgifter (tasks) som sedan kommer att hj\u00e4lpa till att distribuera applikationen inom v\u00e5r pipeline. Den f\u00f6rsta uppgiften \u2013 apply_manifests_task \u2013 ansvarar f\u00f6r att till\u00e4mpa YAML-filerna av Kubernetes-resurser (service, deployment och route) som finns i k8s-mappen f\u00f6r v\u00e5r applikation. Den andra uppgiften \u2013 update_deployment_task \u2013 ansvarar f\u00f6r att uppdatera den redan distribuerade bilden till den som skapas av v\u00e5r pipeline.<\/p>\n
    Oroa dig inte om det \u00e4r oklart just nu. Egentligen \u00e4r dessa uppgifter n\u00e5got som verktyg, och vi kommer att diskutera dem mer detaljerat senare. Men f\u00f6rst skapar vi 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
    \nSedan, med hj\u00e4lp av tkn CLI-kommandot, kontrollerar vi att uppgifterna har skapats:<\/p>\n
    $ tkn task ls\n\nNAME                AGE\napply-manifests     1 minute ago\nupdate-deployment   1 minute ago\n<\/code><\/pre>\n
    \nObs: detta \u00e4r lokala uppgifter f\u00f6r ditt nuvarande projekt.<\/i><\/p>\n
    Klasuppgifter Cluster tasks<\/h4>\n
    \nKlasuppgifter \u00e4r i princip samma sak som vanliga uppgifter. Det vill s\u00e4ga, det \u00e4r en \u00e5teranv\u00e4ndbar samling steg som kombineras p\u00e5 olika s\u00e4tt n\u00e4r en specifik uppgift k\u00f6rs. Skillnaden \u00e4r att klasuppgiften \u00e4r tillg\u00e4nglig \u00f6ver hela klustret. F\u00f6r att se listan \u00f6ver klasuppgifter som automatiskt skapas n\u00e4r Pipeline Operator l\u00e4ggs till, anv\u00e4nder vi \u00e5terigen tkn CLI-kommandot:<\/p>\n
    $ tkn clustertask ls\n\nNAME                       AGE\nbuildah                    1 day ago\nbuildah-v0-10-0            1 day ago\njib-maven                  1 day ago\nkn                         1 day ago\nmaven                      1 day ago\nopenshift-client           1 day ago\nopenshift-client-v0-10-0   1 day ago\ns2i                        1 day ago\ns2i-go                     1 day ago\ns2i-go-v0-10-0             1 day ago\ns2i-java-11                1 day ago\ns2i-java-11-v0-10-0        1 day ago\ns2i-java-8                 1 day ago\ns2i-java-8-v0-10-0         1 day ago\ns2i-nodejs                 1 day ago\ns2i-nodejs-v0-10-0         1 day ago\ns2i-perl                   1 day ago\ns2i-perl-v0-10-0           1 day ago\ns2i-php                    1 day ago\ns2i-php-v0-10-0            1 day ago\ns2i-python-3               1 day ago\ns2i-python-3-v0-10-0       1 day ago\ns2i-ruby                   1 day ago\ns2i-ruby-v0-10-0           1 day ago\ns2i-v0-10-0                1 day ago\n<\/code><\/pre>\n
    \nOch nu ska vi skapa tv\u00e5 klasuppgifter. Den f\u00f6rsta kommer att generera en S2I-bild och skicka den till det interna OpenShift-registret; den andra kommer att bygga v\u00e5r bild baserat p\u00e5 NGINX, med det inneh\u00e5ll som vi redan har samlat ihop.<\/p>\n
    Vi skapar och skickar bilden<\/h4>\n
    \nN\u00e4r vi skapar den f\u00f6rsta uppgiften kommer vi att upprepa vad vi redan har gjort i den tidigare artikeln om relaterade samlingar. Vi p\u00e5minde oss om att vi anv\u00e4nde S2I-bilden (ubi8-s2i-web-app) f\u00f6r att \"bygga\" v\u00e5r applikation, och vi slutade med en bild som lagras i OpenShifts interna register. Nu kommer vi att anv\u00e4nda denna S2I-bild f\u00f6r webbapplikationen f\u00f6r att skapa en DockerFile f\u00f6r v\u00e5r applikation, och sedan anv\u00e4nder vi Buildah f\u00f6r att utf\u00f6ra den verkliga byggnationen och skicka den resulterande bilden till OpenShifts interna register, eftersom det \u00e4r precis vad OpenShift g\u00f6r n\u00e4r du distribuerar dina applikationer med NodeShift.<\/p>\n
    Fr\u00e5gar ni hur vi kom fram till allt detta? Fr\u00e5n \u043e\u0444\u0438\u0446\u0438\u0430\u043b\u044c\u043d\u043e\u0439 \u0432\u0435\u0440\u0441\u0438\u0438 official Node.js<\/a><\/noindex>, vi kopierade den bara och anpassade den f\u00f6r oss sj\u00e4lva.<\/p>\n
    S\u00e5, nu skapar vi en klusteruppgift 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 kommer inte att g\u00e5 in p\u00e5 detaljer om detta, utan bara stanna vid parametern OUTPUT_DIR:<\/p>\n
    params:\n      - name: OUTPUT_DIR\n        description: Platsen f\u00f6r byggutmatningskatalogen\n        default: build\n<\/code><\/pre>\n
    \nSom standard \u00e4r den h\u00e4r parametern inst\u00e4lld p\u00e5 build, dit React l\u00e4gger den samlade inneh\u00e5llet. Andra ramverk anv\u00e4nder olika s\u00f6kv\u00e4gar, till exempel i Ember \u00e4r det dist. Utmatningen av v\u00e5r f\u00f6rsta klusteruppgift kommer att vara en bild som inneh\u00e5ller de HTML-, JavaScript- och CSS-filer vi har samlat.<\/p>\n
    Bygger en bild baserad p\u00e5 NGINX<\/h4>\n
    \nF\u00f6r v\u00e5r andra klusteruppgift m\u00e5ste den bygga en bild baserad p\u00e5 NGINX, som anv\u00e4nder inneh\u00e5llet fr\u00e5n v\u00e5r redan samlade applikation. I huvudsak \u00e4r detta den del av det f\u00f6reg\u00e5ende avsnittet d\u00e4r vi diskuterade sammanl\u00e4nkade byggnader (chained builds).<\/p>\n
    F\u00f6r detta \u2013 p\u00e5 samma s\u00e4tt som ovan \u2013 kommer vi att skapa en klusteruppgift 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
    \nOm man tittar p\u00e5 koden f\u00f6r dessa klusteruppgifter ser man att det inte specificeras vilket Git-repo vi arbetar med, eller namnen p\u00e5 de bilder vi skapar. Vi anger bara vad vi skickar till Git, eller en viss bild dit den slutliga bilden ska matas. Just d\u00e4rf\u00f6r kan dessa klusteruppgifter \u00e5teranv\u00e4ndas \u00e4ven n\u00e4r man arbetar med andra applikationer.<\/p>\n
    Och h\u00e4r \u00f6verg\u00e5r vi elegant till n\u00e4sta punkt\u2026<\/p>\n
    Resurser<\/h4>\n
    \nS\u00e5, eftersom som vi just n\u00e4mnde, m\u00e5ste klusteruppgifterna vara s\u00e5 allm\u00e4nna som m\u00f6jligt, m\u00e5ste vi skapa resurser som kommer att anv\u00e4ndas som indata (Git-repository) och utdata (slutbilder). Den f\u00f6rsta resursen vi beh\u00f6ver \u00e4r Git, d\u00e4r v\u00e5r applikation finns, n\u00e5got som detta:<\/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
    \nH\u00e4r har PipelineResource typen git. Nyckeln url i sektionen params anger det specifika repositoryt och st\u00e4ller in master-grenen (detta \u00e4r valfritt, men vi skriver den f\u00f6r fullst\u00e4ndighetens skull).<\/p>\n
    Nu m\u00e5ste vi skapa en resurs f\u00f6r bilden, d\u00e4r resultaten av s2i-web-app-uppgiften kommer att sparas, det g\u00f6rs s\u00e5 h\u00e4r:<\/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
    \nH\u00e4r har PipelineResource typen image, och v\u00e4rdet f\u00f6r parametern url pekar p\u00e5 den interna OpenShift Image Registry, specifikt den som finns i namnomr\u00e5det webapp-pipeline. Gl\u00f6m inte att \u00e4ndra denna parameter om du anv\u00e4nder ett annat namnomr\u00e5de.<\/p>\n
    Och slutligen, den sista resursen vi beh\u00f6ver kommer ocks\u00e5 att ha typen image och detta blir den slutliga bilden av NGINX, som sedan kommer att anv\u00e4ndas vid distribution:<\/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
    \nOch igen, observera att denna resurs sparar bilden i OpenShift:s interna register i namnomr\u00e5det webapp-pipeline.<\/p>\n
    F\u00f6r att skapa alla dessa resurser p\u00e5 en g\u00e5ng, anv\u00e4nder vi kommandot create:<\/p>\n
    $ oc create -f https:\/\/raw.githubusercontent.com\/nodeshift\/webapp-pipeline-tutorial\/master\/resources\/resource.yaml\n<\/code><\/pre>\n
    \nF\u00f6r att s\u00e4kerst\u00e4lla att resurserna har skapats kan man g\u00f6ra s\u00e5 h\u00e4r:<\/p>\n
    $ tkn resource ls\n<\/code><\/pre>\n
    <\/p>\n
    Pipeline-conveyern<\/h4>\n
    \nNu n\u00e4r vi har alla n\u00f6dv\u00e4ndiga delar, ska vi bygga en pipeline av dem genom att k\u00f6ra f\u00f6ljande 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 innan vi k\u00f6r detta kommando, l\u00e5t oss g\u00e5 igenom dessa delar. Den f\u00f6rsta \u00e4r namnet:<\/p>\n
    apiVersion: tekton.dev\/v1alpha1\nkind: Pipeline\nmetadata:\n  name: build-and-deploy-react\n<\/code><\/pre>\n
    \nSedan ser vi i sektionen spec en angivelse av resurserna som vi skapade tidigare:<\/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
    \nSedan skapar vi uppgifter som v\u00e5r pipeline ska utf\u00f6ra. F\u00f6rst och fr\u00e4mst m\u00e5ste den utf\u00f6ra den uppgift vi redan har skapat, 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
    \nDenna uppgift tar indata (gir-resurs) och utdata (resurs built-web-application-image) parametrar. Vi skickar ocks\u00e5 en speciell parameter s\u00e5 att den inte verifierar TLS, eftersom vi anv\u00e4nder sj\u00e4lvsignerade certifikat:<\/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\u00e4sta uppgiften \u00e4r n\u00e4stan densamma, men h\u00e4r anropas redan den klustertask som vi har skapat, webapp-build-runtime:<\/p>\n
    namn: build-runtime-image\n    taskRef:\n      namn: webapp-build-runtime\n      typ: ClusterTask\n<\/code><\/pre>\n
    \nSom med den f\u00f6reg\u00e5ende uppgiften \u00f6verf\u00f6r vi en resurs, men nu \u00e4r det built-web-application-image (utg\u00e5ngen fr\u00e5n v\u00e5r tidigare uppgift). Och som utg\u00e5ng s\u00e4tter vi \u00e5terigen en bild. Eftersom denna uppgift ska utf\u00f6ras efter den f\u00f6reg\u00e5ende, l\u00e4gger vi till f\u00e4ltet 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\u00e4sta tv\u00e5 uppgifterna ansvarar f\u00f6r till\u00e4mpningen av YAML-filerna f\u00f6r tj\u00e4nsten, routen och distributionen som ligger i k8s-katalogen av v\u00e5r webbapplikation, samt f\u00f6r att uppdatera denna distribution vid skapandet av nya bilder. Dessa tv\u00e5 klustertasks angav vi redan i b\u00f6rjan av artikeln.<\/p>\n
    Starta pipelinen<\/h4>\n
    \nS\u00e5, alla delar av v\u00e5r pipeline \u00e4r skapade, och vi startar den med f\u00f6ljande kommando:<\/p>\n
    $ tkn pipeline start build-and-deploy-react\n<\/code><\/pre>\n
    \nI detta skede anv\u00e4nds kommandoraden i interaktivt l\u00e4ge och man m\u00e5ste v\u00e4lja l\u00e4mpliga resurser som svar p\u00e5 varje fr\u00e5ga: f\u00f6r git-resursen v\u00e4ljer vi web-application-repo, sedan f\u00f6r den f\u00f6rsta bildresursen \u2013 built-web-application-image, och slutligen f\u00f6r den andra bildresursen \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 kontrollerar vi statusen f\u00f6r pipelinen med f\u00f6ljande kommando:<\/p>\n
    $ tkn pipeline logs -f\n<\/code><\/pre>\n
    \nEfter att pipelinen har startat och applikationen har distribuerats, beg\u00e4r vi den publicerade routen med f\u00f6ljande kommando:<\/p>\n
    $ oc get route react-pipeline-example --template='http:\/\/{{.spec.host}}'\n<\/code><\/pre>\n
    \nF\u00f6r b\u00e4ttre visuell \u00f6versikt kan vi se v\u00e5r pipeline i Developer-l\u00e4get i webbkonsolen i avsnittet Pipeline<\/b>, som visas i Fig. 1.<\/p>\n
    \"Moderna<\/p>\n
    Fig. 1. \u00d6versikt \u00f6ver k\u00f6rda pipelines.<\/i><\/p>\n
    Ett klick p\u00e5 den k\u00f6rda pipelinen visar ytterligare information, som visas i Fig. 2.<\/p>\n
    \"Moderna<\/p>\n
    Fig. 2. Ytterligare information om pipelinen.<\/i><\/p>\n
    Efter den ytterligare informationen kan man se de k\u00f6rda applikationerna i visningen Topologi<\/b>, som visas i Fig. 3.<\/p>\n
    \"Moderna<\/p>\n
    Fig. 3. K\u00f6rd pod.<\/i><\/p>\n
    Ett klick p\u00e5 cirkeln i \u00f6vre h\u00f6gra h\u00f6rnet av ikonen \u00f6ppnar v\u00e5r applikation, som visas i Fig. 4.<\/p>\n
    \"Moderna<\/p>\n
    Fig. 4. K\u00f6rd React-applikation.<\/i><\/p>\n
    Slutsats<\/h3>\n
    \nS\u00e5 vi har visat hur man startar en utvecklingsserver f\u00f6r sin applikation p\u00e5 OpenShift och synkroniserar den med det lokala filsystemet. Vi har ocks\u00e5 g\u00e5tt igenom hur man simulerar en chained-build mall med hj\u00e4lp av OpenShift Pipelines. All kod i exemplen fr\u00e5n denna artikel g\u00e5r att hitta h\u00e4r<\/a><\/noindex>.<\/p>\n
    Ytterligare resurser (EN)<\/h3>\n
    <\/p>\n