{"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\/de\/blog\/administrirovanie\/sovremennye-prilozheniya-na-openshift-chast-3-openshift-kak-sreda-razrabotki-i-konvejery-openshift-pipelines","title":{"rendered":"Moderne Anwendungen auf OpenShift, Teil 3: OpenShift als Entwicklungsumgebung und OpenShift Pipelines","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Hallo zusammen in diesem Blog! Hier ist der dritte Beitrag aus unserer Reihe, in der wir zeigen, wie man moderne Webanwendungen auf Red Hat OpenShift bereitstellt.<\/p>\n

\"Moderne
\n
\nIn den beiden vorherigen Beitr\u00e4gen haben wir erkl\u00e4rt, wie man moderne Webanwendungen in nur wenigen Schritten bereitstellt und wie man das neue S2I-Image zusammen mit einem fertigen HTTP-Server-Image, wie NGINX, mit Hilfe von verkn\u00fcpften Builds f\u00fcr die Produktion verwendet.<\/p>\n

Heute zeigen wir, wie man auf der OpenShift-Plattform einen Entwicklungsserver f\u00fcr seine Anwendung startet und ihn mit dem lokalen Dateisystem synchronisiert. Au\u00dferdem werden wir besprechen, was OpenShift Pipelines sind und wie sie als Alternative zu verbundenen Builds eingesetzt werden k\u00f6nnen.
\n<\/a><\/noindex><\/p>\n

OpenShift als Entwicklungsumgebung<\/h3>\n

<\/p>\n

Entwicklungsworkflow<\/h4>\n

\nWie bereits im ersten Beitrag<\/a><\/noindex>erw\u00e4hnt, besteht der typische Entwicklungsprozess f\u00fcr moderne Webanwendungen einfach aus einem \u201eEntwicklungsserver\u201c, der \u00c4nderungen an lokalen Dateien \u00fcberwacht. Wenn \u00c4nderungen vorgenommen werden, wird das Anwendungs-Build gestartet, und anschlie\u00dfend wird es im Browser aktualisiert.<\/p>\n

In den meisten modernen Frameworks ist ein solcher \u201eEntwicklungsserver\u201c in die entsprechenden Befehlszeilentools integriert.<\/p>\n

Lokales Beispiel<\/h4>\n

\nZun\u00e4chst schauen wir uns an, wie das bei der lokalen Ausf\u00fchrung von Anwendungen funktioniert. Als Beispiel nehmen wir die Anwendung React<\/a><\/noindex> aus fr\u00fcheren Artikeln, wobei praktisch die gleichen Konzepte des Workflows auch auf alle anderen modernen Frameworks angewendet werden.
\nUm den \u201eEntwicklungsserver\u201c in unserem Beispiel mit React zu starten, geben wir den folgenden Befehl ein:<\/p>\n

$ npm run start\n<\/code><\/pre>\n
\nDann sehen wir im Terminalfenster ungef\u00e4hr Folgendes:<\/p>\n
\"Moderne<\/p>\n
Und unsere Anwendung \u00f6ffnet sich im Standardbrowser:<\/p>\n
\"Moderne<\/p>\n
Jetzt, wenn wir \u00c4nderungen an der Datei vornehmen, sollte sich die Anwendung im Browser aktualisieren.<\/p>\n
Okay, die Entwicklung im lokalen Modus ist klar, aber wie erreichen wir das Gleiche auf OpenShift?<\/p>\n
Entwicklungsserver auf OpenShift<\/h4>\n
\nWenn ihr euch erinnert, haben wir im meinem vorherigen Post<\/a><\/noindex>, die sogenannte Ausf\u00fchrungsphase des S2I-Images besprochen und gesehen, dass standardm\u00e4\u00dfig das Modul serve f\u00fcr die Bereitstellung unserer Webanwendung zust\u00e4ndig ist.<\/p>\n
Wenn wir jedoch genauer hinsehen run script<\/a><\/noindex> aus diesem Beispiel, gibt es eine Umgebungsvariable $NPM_RUN, die es erm\u00f6glicht, auch einen eigenen Befehl auszuf\u00fchren.<\/p>\n
Zum Beispiel kann das Modul nodeshift verwendet werden, um unsere Anwendung bereitzustellen:<\/p>\n
$ npx nodeshift --deploy.env NPM_RUN="yarn start" --dockerImage=nodeshift\\\/ubi8-s2i-web-app\n<\/code><\/pre>\n
\nHinweis: Das obige Beispiel wird verk\u00fcrzt dargestellt, um die allgemeine Idee zu veranschaulichen.<\/i><\/p>\n
Hier haben wir in unsere Bereitstellung die Umgebungsvariable NPM_RUN hinzugef\u00fcgt, die dem Ausf\u00fchrungsprozess mitteilt, dass er den Befehl yarn start ausf\u00fchren soll, der den Entwicklungsserver von React innerhalb unseres OpenShift-Pods startet.<\/p>\n
Wenn wir die Logs des laufenden Pods ansehen, wird Folgendes angezeigt:<\/p>\n
\"Moderne<\/p>\n
Nat\u00fcrlich ist das alles wenig hilfreich, bis wir den lokalen Code mit dem Remote-Code synchronisieren k\u00f6nnen, der ebenfalls auf \u00c4nderungen \u00fcberwacht wird.<\/p>\n
Synchronisierung von Remote- und lokalem Code<\/h4>\n
\nGl\u00fccklicherweise hilft nodeshift bei der Synchronisierung, und zur \u00dcberwachung von \u00c4nderungen kann der Befehl watch verwendet werden.<\/p>\n
Nachdem wir den Befehl zur Bereitstellung des Entwicklungsservers f\u00fcr unsere Anwendung ausgef\u00fchrt haben, k\u00f6nnen wir diesen Befehl sicher verwenden:<\/p>\n
$ npx nodeshift watch\n<\/code><\/pre>\n
\nIn der Folge wird eine Verbindung zu dem gestarteten Pod hergestellt, den wir zuvor erstellt haben. Die Synchronisierung unserer lokalen Dateien mit dem entfernten Cluster wird aktiviert, und die Dateien auf unserem lokalen System beginnen, auf \u00c4nderungen \u00fcberwacht zu werden.<\/p>\n
Wenn wir nun die Datei src\/App.js aktualisieren, reagiert das System auf diese \u00c4nderungen, kopiert sie in den entfernten Cluster und startet den Entwicklungsserver, der dann unsere Anwendung im Browser aktualisiert.<\/p>\n
Zur Vollst\u00e4ndigkeit zeigen wir, wie diese Befehle vollst\u00e4ndig aussehen:<\/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
\nDer Befehl 'watch' ist eine Abstraktion \u00fcber dem Befehl 'oc rsync'. Detailliertere Informationen dar\u00fcber, wie das funktioniert, finden Sie hier. hier<\/a><\/noindex>.<\/p>\n
Das war ein Beispiel f\u00fcr React, aber eine \u00e4hnliche Methode kann auch mit anderen Frameworks verwendet werden; passen Sie einfach die Umgebungsvariable NPM_RUN entsprechend an.
\n\u2003<\/p>\n
OpenShift Pipelines<\/h3>\n
\"Moderne<\/p>\n
Als N\u00e4chstes sprechen wir \u00fcber ein Werkzeug namens OpenShift Pipelines und wie es als Alternative zu verkn\u00fcpften Builds (chained build) verwendet werden kann.<\/p>\n
Was sind OpenShift Pipelines?<\/h4>\n
\nOpenShift Pipelines \u2013 ist ein cloud-orientiertes CI\/CD-System f\u00fcr kontinuierliche Integration und Lieferung, das zur Organisation von Pipelines unter Verwendung von Tekton entwickelt wurde. Tekton ist ein flexibles, Kubernetes-natives CI\/CD-Framework mit Open-Source-Code, das die Bereitstellung auf verschiedenen Plattformen (Kubernetes, serverless, virtuelle Maschinen usw.) durch Abstraktion von der darunter liegenden Ebene automatisiert.<\/p>\n
Um diesen Artikel zu verstehen, sind bestimmte Kenntnisse \u00fcber Pipelines erforderlich. Daher empfehlen wir dringend, sich zun\u00e4chst mit dem offiziellen Handbuch<\/a><\/noindex>.<\/p>\n
Einrichten der Arbeitsumgebung<\/h4>\n
\nUm mit den Beispielen aus diesem Artikel zu experimentieren, m\u00fcssen Sie zun\u00e4chst die Arbeitsumgebung vorbereiten:<\/p>\n
    \n
  1. Installieren und Konfigurieren eines OpenShift 4-Clusters. In unseren Beispielen verwenden wir daf\u00fcr CodeReady Containers (CRD), deren Installationsanleitungen Sie finden k\u00f6nnen hier<\/a><\/noindex>.<\/li>\n
  2. Nachdem der Cluster bereit ist, muss der Pipeline Operator darauf installiert werden. Keine Angst, es ist einfach; die Installationsanleitung finden Sie hier<\/a><\/noindex>.<\/li>\n
  3. Hochladen Tekton CLI<\/a><\/noindex> (tkn) hier<\/a><\/noindex>.<\/li>\n
  4. F\u00fchren Sie das Kommandozeilenwerkzeug create-react-app aus, um eine Anwendung zu erstellen, die sp\u00e4ter bereitgestellt wird (es handelt sich um eine einfache Anwendung React<\/a><\/noindex>).<\/li>\n
  5. (Optional) Klonen Sie das Repository, um das Beispielprojekt lokal mit dem Befehl npm install und anschlie\u00dfend npm start auszuf\u00fchren.<\/li>\n<\/ol>\n
    \nIm Anwendungsrepository wird es auch einen Ordner k8s geben, in dem die YAML-Dateien f\u00fcr Kubernetes\/OpenShift gespeichert sind, die zum Bereitstellen der Anwendung verwendet werden. Dort befinden sich Tasks, ClusterTasks, Ressourcen und Pipelines, die wir in diesem erstellen werden. Repository<\/a><\/noindex>.<\/p>\n
    Legen wir los<\/h4>\n
    \nZun\u00e4chst m\u00fcssen wir ein neues Projekt im OpenShift-Cluster erstellen. Wir nennen dieses Projekt webapp-pipeline und erstellen es mit dem folgenden Befehl:<\/p>\n
    $ oc new-project webapp-pipeline\n<\/code><\/pre>\n
    \nDer Projektname wird sp\u00e4ter im Code verwendet, also denken Sie daran, den Code in den Beispielen entsprechend zu \u00e4ndern, falls Sie ihn anders benennen m\u00f6chten. Ab diesem Punkt werden wir nicht von oben nach unten, sondern von unten nach oben arbeiten: Zuerst erstellen wir alle Komponenten der Pipeline und dann die Pipeline selbst.<\/p>\n
    Also, zun\u00e4chst\u2026<\/p>\n
    Aufgaben Tasks<\/h4>\n
    \nWir erstellen eine Reihe von Aufgaben (tasks), die helfen werden, die Anwendung in unserem Pipeline-Prozess bereitzustellen. Die erste Aufgabe \u2013 apply_manifests_task \u2013 ist daf\u00fcr verantwortlich, die YAML-Dateien der Kubernetes-Ressourcen (Service, Deployment und Route), die sich im k8s-Ordner unserer Anwendung befinden, anzuwenden. Die zweite Aufgabe \u2013 update_deployment_task \u2013 hat die Aufgabe, das bereits bereitgestellte Image auf das zu aktualisieren, das unser Pipeline-Prozess erstellt.<\/p>\n
    Keine Sorge, wenn es im Moment noch nicht ganz klar ist. Tats\u00e4chlich sind diese Aufgaben eine Art Dienstprogramm, und wir werden sie sp\u00e4ter ausf\u00fchrlicher besprechen. Aber zun\u00e4chst erstellen wir sie einfach:<\/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
    \nDanach \u00fcberpr\u00fcfen wir mit dem tkn CLI-Befehl, ob die Aufgaben erstellt wurden:<\/p>\n
    $ tkn task ls\n\nNAME                ALTER\napply-manifests     vor 1 Minute\nupdate-deployment   vor 1 Minute\n<\/code><\/pre>\n
    \nHinweis: Dies sind lokale Aufgaben Ihres aktuellen Projekts.<\/i><\/p>\n
    Cluster-Aufgaben<\/h4>\n
    \nClusteraufgaben sind grunds\u00e4tzlich dasselbe wie einfache Aufgaben. Das hei\u00dft, es handelt sich um eine wiederverwendbare Sammlung von Schritten, die auf verschiedene Weise kombiniert werden, wenn eine bestimmte Aufgabe gestartet wird. Der Unterschied besteht darin, dass die Clusteraufgabe im gesamten Cluster verf\u00fcgbar ist. Um eine Liste der Clusteraufgaben zu sehen, die automatisch erstellt werden, wenn Sie einen Pipeline-Operator hinzuf\u00fcgen, verwenden wir erneut den Befehl tkn CLI:<\/p>\n
    $ tkn clustertask ls\n\nNAME                       ALTER\nbuildah                    vor 1 Tag\nbuildah-v0-10-0            vor 1 Tag\njib-maven                  vor 1 Tag\nkn                         vor 1 Tag\nmaven                      vor 1 Tag\nopenshift-client           vor 1 Tag\nopenshift-client-v0-10-0   vor 1 Tag\ns2i                        vor 1 Tag\ns2i-go                     vor 1 Tag\ns2i-go-v0-10-0             vor 1 Tag\ns2i-java-11                vor 1 Tag\ns2i-java-11-v0-10-0        vor 1 Tag\ns2i-java-8                 vor 1 Tag\ns2i-java-8-v0-10-0         vor 1 Tag\ns2i-nodejs                 vor 1 Tag\ns2i-nodejs-v0-10-0         vor 1 Tag\ns2i-perl                   vor 1 Tag\ns2i-perl-v0-10-0           vor 1 Tag\ns2i-php                    vor 1 Tag\ns2i-php-v0-10-0            vor 1 Tag\ns2i-python-3               vor 1 Tag\ns2i-python-3-v0-10-0       vor 1 Tag\ns2i-ruby                   vor 1 Tag\ns2i-ruby-v0-10-0           vor 1 Tag\ns2i-v0-10-0                vor 1 Tag\n<\/code><\/pre>\n
    \nJetzt erstellen wir zwei Clusteraufgaben. Die erste wird ein S2I-Image generieren und es an das interne OpenShift-Register senden; die zweite wird unser Image auf Basis von NGINX erstellen, wobei wir bereits unsere gebaute Anwendung als Inhalt verwenden.<\/p>\n
    Image erstellen und senden<\/h4>\n
    \nBei der Erstellung der ersten Aufgabe wiederholen wir das, was wir im vorherigen Artikel \u00fcber verkn\u00fcpfte Builds bereits gemacht haben. Erinnern wir uns, dass wir das S2I-Image (ubi8-s2i-web-app) verwendet haben, um unsere Anwendung zu \u201ebauen\u201c, und am Ende erhielten wir ein Image, das im internen OpenShift-Register gespeichert wurde. Jetzt werden wir dieses S2I-Image der Webanwendung verwenden, um ein DockerFile f\u00fcr unsere Anwendung zu erstellen, und dann Buildah einsetzen, um den eigentlichen Build durchzuf\u00fchren und das resultierende Image in das interne OpenShift-Register zu senden, da dies genau das ist, was OpenShift tut, wenn Sie Ihre Anwendungen mit NodeShift bereitstellen.<\/p>\n
    Sie fragen sich, woher wir das alles wissen? Aus \u043e\u0444\u0438\u0446\u0438\u0430\u043b\u044c\u043d\u043e\u0439 \u0432\u0435\u0440\u0441\u0438\u0438 official Node.js<\/a><\/noindex>, wir haben es einfach kopiert und angepasst.<\/p>\n
    Jetzt erstellen wir die Clusteraufgabe 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
    \nWir werden dies nicht im Detail durchgehen, sondern uns lediglich auf den Parameter OUTPUT_DIR konzentrieren:<\/p>\n
    params:\n      - name: OUTPUT_DIR\n        description: Der Speicherort des Build-Ausgabeverzeichnisses\n        default: build\n<\/code><\/pre>\n
    \nStandardm\u00e4\u00dfig ist dieser Parameter auf build gesetzt, wohin React den erstellten Inhalt ablegt. In anderen Frameworks werden andere Pfade verwendet, zum Beispiel dist in Ember. Das Ergebnis unserer ersten Clusteraufgabe wird ein Image sein, das unser erstelltes HTML, JavaScript und CSS enth\u00e4lt.<\/p>\n
    Wir erstellen ein Image auf Basis von NGINX<\/h4>\n
    \nWas unsere zweite Clusteraufgabe betrifft, so soll sie ein Image auf Basis von NGINX erstellen, wobei der Inhalt unserer bereits zusammengestellten Anwendung verwendet wird. Im Grunde genommen handelt es sich hierbei um den Teil des vorherigen Abschnitts, in dem wir die verkn\u00fcpften Builds (chained builds) behandelt haben.<\/p>\n
    Dazu werden wir, genau wie oben, eine Clusteraufgabe webapp-build-runtime erstellen:<\/p>\n
    $ oc create -f https:\/\/raw.githubusercontent.com\/nodeshift\/webapp-pipeline-tutorial\/master\/clustertasks\/webapp-build-runtime-task.yaml\n<\/code><\/pre>\n
    \nWenn wir den Code dieser Clusteraufgaben betrachten, f\u00e4llt auf, dass das verwendete Git-Repository oder die Namen der zu erstellenden Images nicht konkretisiert sind. Wir geben lediglich an, was wir in Git \u00fcbergeben oder in ein bestimmtes Image schreiben m\u00fcssen. Genau deshalb k\u00f6nnen diese Clusteraufgaben wiederverwendet werden, auch bei der Arbeit mit anderen Anwendungen.<\/p>\n
    Und hier gelangen wir elegant zum n\u00e4chsten Punkt\u2026<\/p>\n
    Ressourcen<\/h4>\n
    \nDa die Clusteraufgaben, wie wir gerade erw\u00e4hnt haben, so allgemein wie m\u00f6glich gehalten werden m\u00fcssen, m\u00fcssen wir Ressourcen erstellen, die als Eingabe (Git-Repository) und Ausgabe (Endbilder) verwendet werden. Die erste ben\u00f6tigte Ressource ist Git, wo unsere Anwendung gespeichert ist, etwas in der Art von:<\/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
    \nHier hat der PipelineResource-Typ den Wert git. Der Schl\u00fcssel url im Abschnitt params verweist auf das spezifische Repository und gibt den master-Branch an (dies ist optional, wir f\u00fcgen es jedoch zur Vollst\u00e4ndigkeit hinzu).<\/p>\n
    Jetzt m\u00fcssen wir eine Ressource f\u00fcr das Image erstellen, in dem die Ergebnisse der Ausf\u00fchrung der s2i-web-app-Aufgabe gespeichert werden, das wird so gemacht:<\/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
    \nHier hat PipelineResource den Typ image und der Wert des Parameters url verweist auf das interne OpenShift Image Registry, insbesondere auf das im Namespace webapp-pipeline. Vergessen Sie nicht, diesen Parameter zu \u00e4ndern, wenn Sie einen anderen Namespace verwenden.<\/p>\n
    Und schlie\u00dflich wird die letzte ben\u00f6tigte Ressource ebenfalls den Typ image haben und es wird das endg\u00fcltige NGINX-Image sein, das dann bei der Bereitstellung verwendet wird:<\/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
    \nBeachten Sie erneut, dass diese Ressource das Image im internen OpenShift-Registry im Namespace webapp-pipeline speichert.<\/p>\n
    Um all diese Ressourcen auf einmal zu erstellen, verwenden wir den Befehl create:<\/p>\n
    $ oc create -f https:\/\/raw.githubusercontent.com\/nodeshift\/webapp-pipeline-tutorial\/master\/resources\/resource.yaml\n<\/code><\/pre>\n
    \nUm sicherzustellen, dass die Ressourcen erstellt wurden, k\u00f6nnen Sie folgendes tun:<\/p>\n
    $ tkn resource ls\n<\/code><\/pre>\n
    <\/p>\n
    Pipeline<\/h4>\n
    \nJetzt, da wir alle erforderlichen Komponenten haben, erstellen wir die Pipeline mit dem folgenden Befehl:<\/p>\n
    $ oc create -f https:\/\/raw.githubusercontent.com\/nodeshift\/webapp-pipeline-tutorial\/master\/pipelines\/build-and-deploy-react.yaml\n<\/code><\/pre>\n
    \nAber bevor wir diesen Befehl ausf\u00fchren, lassen Sie uns diese Komponenten durchgehen. Die erste ist der Name:<\/p>\n
    apiVersion: tekton.dev\/v1alpha1\nkind: Pipeline\nmetadata:\n  name: build-and-deploy-react\n<\/code><\/pre>\n
    \nDann sehen wir im Abschnitt 'spec' die Ressourcenangaben, die wir zuvor erstellt haben:<\/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
    \nNun erstellen wir die Aufgaben, die unser Pipeline ausf\u00fchren muss. Zuerst wird die bereits erstellte Aufgabe s2i-web-app ausgef\u00fchrt:<\/p>\n
    tasks:\n    - name: build-web-application\n      taskRef:\n        name: s2i-web-app\n        kind: ClusterTask\n<\/code><\/pre>\n
    \nDiese Aufgabe nimmt die Eingangs- (gir-Ressource) und Ausgangsparameter (Ressource built-web-application-image). Au\u00dferdem \u00fcbergeben wir ihr einen speziellen Parameter, damit sie TLS nicht validiert, da wir selbstsignierte Zertifikate verwenden:<\/p>\n
    Ressourcen:\n        Eing\u00e4nge:\n          - Name: Quelle\n            Ressource: web-application-repo\n        Ausg\u00e4nge:\n          - Name: Bild\n            Ressource: built-web-application-image\n      Parameter:\n        - Name: TLSVERIFY\n          Wert: "false"\n<\/code><\/pre>\n
    \nDie n\u00e4chste Aufgabe ist fast identisch, nur dass hier die bereits erstellte Clusteraufgabe webapp-build-runtime aufgerufen wird:<\/p>\n
    name: build-runtime-image\n    taskRef:\n      name: webapp-build-runtime\n      kind: ClusterTask\n<\/code><\/pre>\n
    \nWie bei der vorherigen Aufgabe \u00fcbergeben wir eine Ressource, aber diesmal ist es das built-web-application-image (das Ergebnis unserer vorherigen Aufgabe). Als Ausgabe legen wir erneut ein Bild fest. Da diese Aufgabe nach der vorherigen ausgef\u00fchrt werden soll, f\u00fcgen wir das Feld runAfter hinzu:<\/p>\n
    Ressourcen:\n        Eing\u00e4nge:\n          - Name: Bild\n            Ressource: built-web-application-image\n        Ausg\u00e4nge:\n          - Name: Bild\n            Ressource: runtime-web-application-image\n        Parameter:\n        - Name: TLSVERIFY\n          Wert: "false"\n      runAfter:\n        - build-web-application\n<\/code><\/pre>\n
    \nDie n\u00e4chsten beiden Aufgaben sind f\u00fcr die Anwendung der YAML-Dateien des Dienstes, der Route und des Deployments verantwortlich, die sich im k8s-Verzeichnis unserer Webanwendung befinden, sowie daf\u00fcr, dieses Deployment bei der Erstellung neuer Images zu aktualisieren. Diese beiden Clusteraufgaben haben wir bereits am Anfang des Artikels definiert.<\/p>\n
    Start der Pipeline<\/h4>\n
    \nNun sind alle Teile unserer Pipeline erstellt, und wir werden sie mit dem folgenden Befehl starten:<\/p>\n
    $ tkn pipeline start build-and-deploy-react\n<\/code><\/pre>\n
    \nAn dieser Stelle wird die Befehlszeile im interaktiven Modus verwendet, und es m\u00fcssen die entsprechenden Ressourcen als Antwort auf jede ihrer Anfragen ausgew\u00e4hlt werden: F\u00fcr die Ressource git w\u00e4hlen wir web-application-repo, dann f\u00fcr die Ressource des ersten Images \u2013 built-web-application-image, und schlie\u00dflich f\u00fcr die Ressource des zweiten Images \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
    \nJetzt \u00fcberpr\u00fcfen wir den Status der Pipeline mit folgendem Befehl:<\/p>\n
    $ tkn pipeline logs -f\n<\/code><\/pre>\n
    \nSobald die Pipeline gestartet ist und die Anwendung bereitgestellt wurde, fordern wir den ver\u00f6ffentlichten Route mit folgendem Befehl an:<\/p>\n
    $ oc get route react-pipeline-example --template='http:\/\/{{.spec.host}}'\n<\/code><\/pre>\n
    \nF\u00fcr eine bessere \u00dcbersicht k\u00f6nnen wir unsere Pipeline im Developer-Modus der Web-Konsole im Abschnitt Pipelines<\/b>, wie in Abb. 1 gezeigt, betrachten.<\/p>\n
    \"Moderne<\/p>\n
    Abb. 1. \u00dcbersicht der gestarteten Pipelines.<\/i><\/p>\n
    Ein Klick auf die gestartete Pipeline zeigt zus\u00e4tzliche Informationen an, wie in Abb. 2 dargestellt.<\/p>\n
    \"Moderne<\/p>\n
    Abb. 2. Zus\u00e4tzliche Informationen zur Pipeline.<\/i><\/p>\n
    Nach den zus\u00e4tzlichen Informationen k\u00f6nnen die gestarteten Anwendungen im Blick Topology<\/b>, wie in Abb. 3 gezeigt, betrachtet werden.<\/p>\n
    \"Moderne<\/p>\n
    Abb. 3. Gestarteter Pod.<\/i><\/p>\n
    Ein Klick auf den Kreis in der oberen rechten Ecke des Symbols \u00f6ffnet unsere Anwendung, wie in Abb. 4 angezeigt.<\/p>\n
    \"Moderne<\/p>\n
    Abb. 4. Gestartete React-Anwendung.<\/i><\/p>\n
    Fazit<\/h3>\n
    \nWir haben gezeigt, wie man einen Entwicklungsserver f\u00fcr seine Anwendung auf OpenShift startet und ihn mit dem lokalen Dateisystem synchronisiert. Au\u00dferdem haben wir betrachtet, wie man eine chained-build Template mit OpenShift Pipelines simuliert. Alle Beispielcodes aus diesem Artikel sind verf\u00fcgbar unter hier<\/a><\/noindex>.<\/p>\n
    Weitere Ressourcen (EN)<\/h3>\n
    <\/p>\n