{"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 der 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 beschrieben, wie man moderne Webanwendungen in nur wenigen Schritten bereitstellt und wie man das neue S2I-Image zusammen mit einem vorgefertigten HTTP-Server-Image, zum Beispiel NGINX, mithilfe von verbundenen Builds f\u00fcr die Organisation der Produktionsbereitstellung nutzt.<\/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 dar\u00fcber sprechen, 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, ist der typische Entwicklungsprozess f\u00fcr moderne Webanwendungen im Wesentlichen ein \"Entwicklungsserver\", der \u00c4nderungen an lokalen Dateien \u00fcberwacht. Wenn diese eintreten, wird eine Anwendungskompilation gestartet und die Anwendung wird im Browser aktualisiert.<\/p>\n

In den meisten modernen Frameworks ist ein solcher \"Entwicklungsserver\" in die entsprechenden Befehlszeilenwerkzeuge integriert.<\/p>\n

Lokales Beispiel<\/h4>\n

\nSchauen wir uns zun\u00e4chst an, wie das bei der lokalen Ausf\u00fchrung von Anwendungen funktioniert. Als Beispiel nehmen wir die Anwendung React<\/a><\/noindex> aus den vorherigen Artikeln, obwohl die gleichen Konzepte des Workflows auch in allen anderen modernen Frameworks Anwendung finden.
\nUm den \"Entwicklungsserver\" 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 wird im Standardbrowser ge\u00f6ffnet:<\/p>\n
\"Moderne<\/p>\n
Jetzt, wenn wir \u00c4nderungen an der Datei vornehmen, sollte die Anwendung im Browser aktualisiert werden.<\/p>\n
Okay, mit der Entwicklung im lokalen Modus ist alles klar, aber wie erreichen wir das Gleiche auf OpenShift?<\/p>\n
Entwicklungsserver auf OpenShift<\/h4>\n
\nWenn Sie sich erinnern, haben wir in im vorherigen Beitrag<\/a><\/noindex>den sogenannten Startphase (run phase) des S2I-Images behandelt und gesehen, dass standardm\u00e4\u00dfig das Modul serve f\u00fcr unsere Webanwendung zust\u00e4ndig ist.<\/p>\n
Wenn wir jedoch genauer hinsehen, Ausf\u00fchrungsskript<\/a><\/noindex> aus diesem Beispiel, finden wir die Umgebungsvariable $NPM_RUN, die es uns erm\u00f6glicht, auch unseren eigenen Befehl auszuf\u00fchren.<\/p>\n
Wir k\u00f6nnen zum Beispiel das Modul nodeshift verwenden, 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 aus Gr\u00fcnden der K\u00fcrze angef\u00fchrt, um die allgemeine Idee zu veranschaulichen.<\/i><\/p>\n
Hier haben wir in unser Deployment die Umgebungsvariable NPM_RUN hinzugef\u00fcgt, die dem Ausf\u00fchrungsprozess mitteilt, dass er den Befehl yarn start ausf\u00fchren soll, um den Entwicklungsserver von React innerhalb unseres OpenShift-Pods zu starten.<\/p>\n
Wenn man das Protokoll des laufenden Pods betrachtet, sieht es ungef\u00e4hr so aus:<\/p>\n
\"Moderne<\/p>\n
Nat\u00fcrlich ist das alles nichtssagend, solange wir unseren lokalen Code nicht mit dem Code synchronisieren k\u00f6nnen, der ebenfalls auf \u00c4nderungen \u00fcberwacht wird, aber auf einem entfernten Server lebt.<\/p>\n
Synchronisation von entferntem und lokalem Code<\/h4>\n
\nGl\u00fccklicherweise kann nodeshift leicht bei der Synchronisation helfen, und zur \u00dcberwachung von \u00c4nderungen kann der Befehl watch verwendet werden.<\/p>\n
Nachdem wir also den Befehl zum Deployen des Entwicklungsservers f\u00fcr unsere Anwendung ausgef\u00fchrt haben, k\u00f6nnen wir getrost folgenden Befehl verwenden:<\/p>\n
$ npx nodeshift watch\n<\/code><\/pre>\n
\nInfolgedessen wird eine Verbindung zu dem zuvor erstellten laufenden Pod hergestellt, die Synchronisation unserer lokalen Dateien mit dem entfernten Cluster aktiviert, und die Dateien auf unserem lokalen System beginnen, auf \u00c4nderungen \u00fcberwacht zu werden.<\/p>\n
Wenn jetzt die Datei src\/App.js aktualisiert wird, reagiert das System auf diese \u00c4nderungen, kopiert sie zum entfernten Cluster und startet den Entwicklungsserver, der dann unsere Anwendung im Browser aktualisiert.<\/p>\n
Um das Bild zu vervollst\u00e4ndigen, 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 watch-Befehl ist eine Abstraktion \u00fcber dem oc rsync-Befehl, mehr dar\u00fcber, wie es funktioniert, kann man hier erfahren. hier<\/a><\/noindex>.<\/p>\n
Das war ein Beispiel f\u00fcr React, aberelbe Methode kann auch mit anderen Frameworks verwendet werden, man muss lediglich die Umgebungsvariable NPM_RUN entsprechend festlegen.
\n\u2003<\/p>\n
OpenShift Pipelines<\/h3>\n
\"Moderne<\/p>\n
Als N\u00e4chstes werden wir \u00fcber ein Tool namens OpenShift Pipelines sprechen und wie es als Alternative zu verkn\u00fcpften Builds (chained build) verwendet werden kann.<\/p>\n
Was sind OpenShift Pipelines?<\/h4>\n
\nOpenShift Pipelines ist ein cloudorientiertes CI\/CD-System f\u00fcr kontinuierliche Integration und Bereitstellung, das zur Organisation von Pipelines mit Tekton verwendet wird. Tekton ist ein flexibles, Kubernetes-natives CI\/CD-Framework mit offenem Quellcode, das die Automatisierung der Bereitstellung auf verschiedenen Plattformen (Kubernetes, serverless, virtuelle Maschinen usw.) durch Abstraktion von der darunterliegenden Ebene erm\u00f6glicht.<\/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 Einrichten eines OpenShift 4 Clusters. In unseren Beispielen wird daf\u00fcr CodeReady Containers (CRD) verwendet, die Installationsanleitung finden Sie hier<\/a><\/noindex>.<\/li>\n
  2. Sobald das Cluster bereit ist, muss der Pipeline-Operator installiert werden. Keine Sorge, das ist einfach, die Installationsanleitung finden Sie hier<\/a><\/noindex>.<\/li>\n
  3. Herunterladen Tekton CLI<\/a><\/noindex> (tkn) hier<\/a><\/noindex>.<\/li>\n
  4. Starten Sie das Befehlszeilenwerkzeug create-react-app, um eine Anwendung zu erstellen, die anschlie\u00dfend bereitgestellt wird (dies ist eine einfache Anwendung React<\/a><\/noindex>).<\/li>\n
  5. (Optional) Klonen Sie das Repository, um das Anwendungsbeispiel lokal mit dem Befehl npm install auszuf\u00fchren und dann npm start.<\/li>\n<\/ol>\n
    \nIm Anwendungsrepository gibt es auch einen Ordner k8s, in dem sich die YAML-Dateien von Kubernetes\/OpenShift befinden, die zur Bereitstellung der Anwendung verwendet werden. Dort befinden sich Tasks, ClusterTasks, Ressourcen und Pipelines, die wir in diesem das Repository<\/a><\/noindex>.<\/p>\n
    Wir beginnen<\/h4>\n
    \nZuerst m\u00fcssen wir f\u00fcr unser Beispiel ein neues Projekt im OpenShift-Cluster erstellen. Nennen wir dieses Projekt webapp-pipeline und erstellen wir es mit dem folgenden Befehl:<\/p>\n
    $ oc new-project webapp-pipeline\n<\/code><\/pre>\n
    \nDieser Projektname wird dann im Code verwendet, also vergessen Sie nicht, den Code der Beispiele entsprechend zu \u00e4ndern, falls Sie ihm einen anderen Namen geben. Ab diesem Punkt werden wir nicht von oben nach unten, sondern von unten nach oben vorgehen: das hei\u00dft, wir erstellen zuerst alle Bestandteile der Pipeline und erst danach die Pipeline selbst.<\/p>\n
    Also, als Erstes\u2026<\/p>\n
    Aufgaben Tasks<\/h4>\n
    \nWir erstellen ein paar Aufgaben (tasks), die dann helfen werden, die Anwendung im Rahmen unserer Pipeline zu deployen. Die erste Aufgabe \u2013 apply_manifests_task \u2013 ist verantwortlich f\u00fcr die Anwendung der YAML-Dateien der Kubernetes-Ressourcen (Service, Deployment und Route), die sich im k8s-Ordner unserer Anwendung befinden. Die zweite Aufgabe \u2013 update_deployment_task \u2013 ist verantwortlich f\u00fcr das Aktualisieren des bereits bereitgestellten Images auf das, das von unserer Pipeline erstellt wird.<\/p>\n
    Keine Sorge, wenn es bisher noch nicht ganz klar ist. Tats\u00e4chlich sind diese Aufgaben eine Art von Dienstprogrammen, und wir werden sie sp\u00e4ter genauer erl\u00e4utern. Lassen Sie uns vorerst einfach die beiden erstellen:<\/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
    \nDann \u00fcberpr\u00fcfen wir mit dem tkn CLI-Befehl, ob die Aufgaben erstellt wurden:<\/p>\n
    $ tkn task ls\n\nNAME                AGE\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
    Klastenaufgaben Cluster tasks<\/h4>\n
    \nKlastenaufgaben sind im Grunde 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 ausgef\u00fchrt wird. Der Unterschied besteht darin, dass eine Klastenaufgabe im gesamten Cluster verf\u00fcgbar ist. Um die Liste der Klastenaufgaben zu sehen, die automatisch erstellt werden, wenn der Pipeline Operator hinzugef\u00fcgt wird, verwenden wir erneut den tkn CLI-Befehl:<\/p>\n
    $ tkn clustertask ls\n\nNAME                       AGE\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 Klastenaufgaben. Die erste wird ein S2I-Image generieren und es in das interne OpenShift-Registry hochladen; die zweite wird unser Image auf Basis von NGINX erstellen und die bereits entwickelte Anwendung als Inhalt verwenden.<\/p>\n
    Wir erstellen und laden das Image hoch<\/h4>\n
    \nBei der Erstellung der ersten Aufgabe wiederholen wir das, was wir bereits im vorherigen Artikel \u00fcber verkn\u00fcpfte Builds behandelt haben. Wir erinnern daran, dass wir das S2I-Image (ubi8-s2i-web-app) verwendet haben, um unsere Anwendung zu \u201ebauen\u201c, und letztlich ein Image erhalten haben, das im internen OpenShift-Registry gespeichert ist. Jetzt werden wir dieses S2I-Image der Webanwendung verwenden, um ein DockerFile f\u00fcr unsere Anwendung zu erstellen, und dann Buildah einsetzen, um den tats\u00e4chlichen Build durchzuf\u00fchren und das erhaltene Image in die interne OpenShift-Registry zu senden, denn genau das macht OpenShift, wenn Sie Ihre Anwendungen mit NodeShift bereitstellen.<\/p>\n
    Fragen Sie 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>, haben wir es einfach kopiert und an unsere Bed\u00fcrfnisse angepasst.<\/p>\n
    So, jetzt erstellen wir die Cluster-Aufgabe 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 das nicht im Detail durchgehen, sondern nur auf den Parameter OUTPUT_DIR eingehen:<\/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, dorthin legt React den gebauten Inhalt ab. In anderen Frameworks werden andere Pfade verwendet, zum Beispiel in Ember ist es dist. Die Ausgabe unserer ersten Cluster-Aufgabe wird ein Image sein, das die von uns gebauten HTML-, JavaScript- und CSS-Dateien enth\u00e4lt.<\/p>\n
    Wir erstellen ein Image auf der Basis von NGINX<\/h4>\n
    \nWas unsere zweite Cluster-Aufgabe betrifft, so soll sie ein Image auf Basis von NGINX erstellen, das den Inhalt unserer bereits gebauten Anwendung verwendet. Im Grunde ist dies der Teil des vorherigen Abschnitts, in dem wir die verkn\u00fcpften Builds behandelt haben.<\/p>\n
    Dazu \u2013 ganz wie oben \u2013 erstellen wir die Cluster-Aufgabe 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
    \nWenn man den Code dieser Cluster-Aufgaben betrachtet, sieht man, dass dort nicht das Git-Repository spezifiziert wird, mit dem wir arbeiten, oder die Namen der Images, die wir erstellen. Wir geben nur an, was wir an Git \u00fcbergeben oder ein Image, in das das finale Image ausgegeben werden soll. Deshalb k\u00f6nnen diese Cluster-Aufgaben wiederverwendet werden, auch wenn wir mit anderen Anwendungen arbeiten.<\/p>\n
    Und hier kommen wir elegant zum n\u00e4chsten Punkt\u2026<\/p>\n
    Ressourcen<\/h4>\n
    \nAlso, da die Cluster-Aufgaben, wie wir gerade gesagt haben, so allgemein wie m\u00f6glich sein m\u00fcssen, m\u00fcssen wir Ressourcen erstellen, die als Eingabe (Git-Repository) und Ausgabe (Endbilder) verwendet werden. Die erste Ressource, die wir ben\u00f6tigen, ist Git, wo sich unsere Anwendung befindet, etwas wie das:<\/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 PipelineResource den Typ git. Der Schl\u00fcssel url im Abschnitt params verweist auf das spezifische Repository und legt den Branch master fest (das ist optional, aber wir geben ihn der Vollst\u00e4ndigkeit halber an).<\/p>\n
    Jetzt m\u00fcssen wir eine Ressource f\u00fcr das Bild erstellen, in dem die Ergebnisse der Ausf\u00fchrung der Aufgabe s2i-web-app gespeichert werden. Das geschieht so:<\/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, konkret auf das, das sich im Namespace webapp-pipeline befindet. Vergessen Sie nicht, diesen Parameter zu \u00e4ndern, wenn Sie einen anderen Namespace verwenden.<\/p>\n
    Und schlie\u00dflich wird die letzte Ressource, die wir ben\u00f6tigen, ebenfalls vom Typ image sein und es wird das endg\u00fcltige NGINX-Bild sein, das dann beim Deployment 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
    \nUnd wieder sei darauf hingewiesen, dass diese Ressource das Bild im internen OpenShift-Register im Namespace webapp-pipeline speichert.<\/p>\n
    Um all diese Ressourcen gleichzeitig 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
    \nSie k\u00f6nnen \u00fcberpr\u00fcfen, ob die Ressourcen erstellt wurden, indem Sie Folgendes eingeben:<\/p>\n
    $ tkn resource ls\n<\/code><\/pre>\n
    <\/p>\n
    Pipeline<\/h4>\n
    \nJetzt, wo wir alle notwendigen Komponenten haben, erstellen wir die Pipeline, indem wir den folgenden Befehl ausf\u00fchren:<\/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 analysieren. 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 Angabe der Ressourcen, 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
    \nDann erstellen wir die Aufgaben, die unser Pipeline ausf\u00fchren soll. Zuerst muss sie die bereits von uns erstellte Aufgabe s2i-web-app ausf\u00fchren:<\/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 Eingangsparameter (git-Ressource) und die Ausgangsparameter (Ressource built-web-application-image). Wir \u00fcbergeben ihr auch einen speziellen Parameter, damit sie TLS nicht \u00fcberpr\u00fcft, da wir selbstsignierte Zertifikate verwenden:<\/p>\n
    Ressourcen:\n        Eingaben:\n          - Name: Quelle\n            Ressource: web-application-repo\n        Ausgaben:\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      Art: ClusterTask\n<\/code><\/pre>\n
    \nWie bei der vorherigen Aufgabe \u00fcbergeben wir eine Ressource, aber jetzt ist es das built-web-application-image (Ausgabe unserer vorherigen Aufgabe). Und erneut definieren wir als Ausgabe ein Bild. Da diese Aufgabe nach der vorherigen ausgef\u00fchrt werden muss, f\u00fcgen wir das Feld runAfter hinzu:<\/p>\n
    Ressourcen:\n        Eingaben:\n          - Name: Bild\n            Ressource: built-web-application-image\n        Ausgaben:\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 f\u00fcr den Dienst, die Route und das Deployment verantwortlich, die im k8s-Verzeichnis unserer Webanwendung leben, sowie f\u00fcr die Aktualisierung dieses Deployments bei der Erstellung neuer Bilder. Diese beiden Clusteraufgaben haben wir bereits zu Beginn des Artikels definiert.<\/p>\n
    Pipeline starten<\/h4>\n
    \nAlso, alle Teile unseres Pipelines sind erstellt, und wir werden sie mit dem folgenden Befehl starten:<\/p>\n
    $ tkn pipeline start build-and-deploy-react\n<\/code><\/pre>\n
    \nIn diesem Schritt wird die Befehlszeile im interaktiven Modus verwendet und man muss die entsprechenden Ressourcen als Antwort auf jede ihrer Anfragen ausw\u00e4hlen: F\u00fcr die Ressource git w\u00e4hlen wir web-application-repo, dann f\u00fcr die Ressource des ersten Bildes \u2013 built-web-application-image, und schlie\u00dflich f\u00fcr die Ressource des zweiten Bildes \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 dem folgenden Befehl:<\/p>\n
    $ tkn pipeline logs -f\n<\/code><\/pre>\n
    \nNachdem die Pipeline gestartet wurde und die Anwendung bereitgestellt ist, fordern wir die ver\u00f6ffentlichte Route mit dem folgenden Befehl an:<\/p>\n
    $ oc get route react-pipeline-example --template='http:\/\/{{.spec.host}}'\n<\/code><\/pre>\n
    \nF\u00fcr mehr Anschaulichkeit k\u00f6nnen wir unsere Pipeline im Entwickler-Modus der Web-Konsole im Abschnitt Pipelines<\/b>, wie in Abb. 1 gezeigt.<\/p>\n
    \"Moderne<\/p>\n
    Abb. 1. \u00dcbersicht \u00fcber die gestarteten Pipelines.<\/i><\/p>\n
    Ein Klick auf die gestartete Pipeline zeigt zus\u00e4tzliche Informationen an, wie in Abb. 2 gezeigt.<\/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 Sichtfeld Topologie<\/b>, wie in Abb. 3 gezeigt.<\/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 gezeigt.<\/p>\n
    \"Moderne<\/p>\n
    Abb. 4. gestartete React-Anwendung.<\/i><\/p>\n
    Fazit<\/h3>\n
    \nWir haben gezeigt, wie man auf OpenShift einen Entwicklungsserver f\u00fcr seine Anwendung starten und ihn mit dem lokalen Dateisystem synchronisieren kann. Au\u00dferdem haben wir betrachtet, wie man eine chained-build-Vorlage mit OpenShift Pipelines simuliert. Alle Beispielcodes aus diesem Artikel sind zu finden hier<\/a><\/noindex>.<\/p>\n
    Zus\u00e4tzliche Ressourcen (EN)<\/h3>\n
    <\/p>\n