{"id":90874,"date":"2020-08-07T01:42:20","date_gmt":"2020-08-06T23:42:20","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/sovremennye-prilozheniya-na-openshift-chast-2-svyazannye-sborki-chained-builds"},"modified":"2020-08-07T01:42:20","modified_gmt":"2020-08-06T23:42:20","slug":"sovremennye-prilozheniya-na-openshift-chast-2-svyazannye-sborki-chained-builds","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/sovremennye-prilozheniya-na-openshift-chast-2-svyazannye-sborki-chained-builds","title":{"rendered":"Moderne Anwendungen auf OpenShift, Teil 2: verbundene Builds chained builds","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

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

\"Moderne
\n
\nIm vorherigen Beitrag haben wir die M\u00f6glichkeiten des neuen Builder-Images S2I (Source-to-Image) etwas angerissen, das f\u00fcr den Bau und die Bereitstellung moderner Webanwendungen auf der OpenShift-Plattform gedacht ist. Damals interessierte uns das Thema der schnellen Bereitstellung von Anwendungen, und heute werden wir untersuchen, wie man das S2I-Image als \"reines\" Builder-Image verwendet und es mit den zugeh\u00f6rigen Builds von OpenShift kombiniert.
\n<\/a><\/noindex><\/p>\n

Reines Builder-Image<\/h3>\n

\nWie wir im ersten Teil erw\u00e4hnt haben, haben die meisten modernen Webanwendungen eine sogenannte Build-Phase, in der normalerweise Operationen wie Code-Transpilierung, Zusammenf\u00fchren mehrerer Dateien und Minimierung durchgef\u00fchrt werden. Die Resultate dieser Operationen - also statisches HTML, JavaScript und CSS - werden in einen Output-Ordner abgelegt. Der Standort dieses Ordners h\u00e4ngt normalerweise von den verwendeten Build-Tools ab, und f\u00fcr React wird dies der Ordner .\\\/build sein (darauf werden wir sp\u00e4ter noch ausf\u00fchrlicher eingehen).<\/p>\n

Source-to-Image (S2I)<\/h4>\n

\nIn diesem Beitrag werden wir das Thema \"Was ist S2I und wie verwendet man es\" nicht behandeln (dar\u00fcber kann man mehr lesen hier<\/a><\/noindex>), aber es ist wichtig, sich die beiden Phasen dieses Prozesses klar vor Augen zu f\u00fchren, um zu verstehen, was das Web App Builder-Image tats\u00e4chlich macht.<\/p>\n

Assemble-Phase<\/h4>\n

\nDie Assemble-Phase \u00e4hnelt im Wesentlichen dem, was passiert, wenn Sie docker build ausf\u00fchren und im Ergebnis ein neues Docker-Image erhalten. Infolgedessen tritt diese Phase auf, wenn der Build auf der OpenShift-Plattform gestartet wird.<\/p>\n

Im Fall des Web App Builder-Images ist das Skript zum Installieren der Abh\u00e4ngigkeiten f\u00fcr Ihre Anwendung und zum Starten des Builds verantwortlich assemble script<\/a><\/noindex>. Standardm\u00e4\u00dfig verwendet das Builder-Image den Befehl npm run build, aber dieser kann \u00fcber die Umgebungsvariable NPM_BUILD \u00fcberschrieben werden.<\/p>\n

Wie bereits erw\u00e4hnt, h\u00e4ngt der Speicherort der fertigen, bereits erstellten Anwendung davon ab, welche Werkzeuge verwendet werden. Bei React w\u00e4re dies zum Beispiel der Ordner \/build, w\u00e4hrend es bei Angular-Anwendungen der Ordner project_name\/dist ist. Und wie bereits im letzten Beitrag gezeigt, kann der Speicherort des Output-Verzeichnisses, das standardm\u00e4\u00dfig als build festgelegt ist, \u00fcber die Umgebungsvariable OUTPUT_DIR \u00fcberschrieben werden. Da der Speicherort des Output-Ordners von Framework zu Framework variiert, kopieren Sie einfach das generierte Output in den Standardordner im Image, n\u00e4mlich \/opt\/apt-root\/output. Das ist wichtig f\u00fcr das Verst\u00e4ndnis des n\u00e4chsten Teils dieses Artikels; lassen Sie uns nun schnell den n\u00e4chsten Schritt \u2013 die Ausf\u00fchrungsphase (run phase) \u2013 betrachten.<\/p>\n

Ausf\u00fchrungsphase (run phase)<\/h4>\n

\nDiese Phase tritt auf, wenn das neu erstellte Image aus der Assembly-Phase mit docker run aufgerufen wird. Sie tritt auch bei der Durchf\u00fchrung von Deployments auf der OpenShift-Plattform auf. Standardm\u00e4\u00dfig Ausf\u00fchrungsskript<\/a><\/noindex> verwendet Modul bereitstellen<\/a><\/noindex> um statische Inhalte bereitzustellen, die im oben genannten Standardausgabe-Verzeichnis liegen.<\/p>\n

Diese Methode eignet sich gut f\u00fcr das schnelle Deployment von Anwendungen, jedoch wird im Allgemeinen nicht empfohlen, statische Inhalte auf diese Weise bereitzustellen. Da wir jedoch tats\u00e4chlich nur statische Inhalte bereitstellen, ist Node.js, das in unserem Image installiert ist, nicht notwendig \u2013 ein Web-Server reicht aus.<\/p>\n

Mit anderen Worten, beim Build ben\u00f6tigen wir etwas anderes als w\u00e4hrend der Ausf\u00fchrung. In dieser Situation sind verkn\u00fcpfte Builds (chained builds) n\u00fctzlich.<\/p>\n

Verkn\u00fcpfte Builds (chained builds)<\/h3>\n

\nDas steht in der Dokumentation von chained builds<\/a><\/noindex> :<\/p>\n

\u201eZwei Builds k\u00f6nnen miteinander verkn\u00fcpft werden, wobei einer von ihnen eine kompilierte Entit\u00e4t erzeugt und der andere diese Entit\u00e4t in einem separaten Image platziert, das verwendet wird, um diese Entit\u00e4t auszuf\u00fchren.\u201c\n<\/p><\/blockquote>\n

\nAnders ausgedr\u00fcckt, wir k\u00f6nnen das Image des Web App Builders verwenden, um unseren Build auszuf\u00fchren, und dann das Image eines Web-Servers, wie NGINX, um unsere Inhalte bereitzustellen.<\/p>\n

Auf diese Weise k\u00f6nnen wir das Image des Web App Builders als \u201ereinen\u201c Builder verwenden und gleichzeitig ein kleines Runtime-Image haben.<\/p>\n

Lassen Sie uns nun ein konkretes Beispiel betrachten.<\/p>\n

F\u00fcr die \u00dcbung verwenden wir eine einfache React-Anwendung<\/a><\/noindex>, die mit dem Befehlszeilenwerkzeug create-react-app erstellt wurde.<\/p>\n

Um alles zusammenzufassen, hilft uns die OpenShift-Vorlagendatei.<\/a><\/noindex>.<\/p>\n

Lassen Sie uns diese Datei genauer ansehen, und beginnen wir mit dem Abschnitt Parameter.<\/p>\n

parameter:\n  - name: SOURCE_REPOSITORY_URL\n    description: Die Quell-URL f\u00fcr die Anwendung\n    displayName: Quell-URL\n    required: true\n  - name: SOURCE_REPOSITORY_REF\n    description: Der Branch-Name f\u00fcr die Anwendung\n    displayName: Quell-Branch\n    value: master\n    required: true\n  - name: SOURCE_REPOSITORY_DIR\n    description: Der Speicherort innerhalb des Quell-Repositorys der Anwendung\n    displayName: Quellverzeichnis\n    value: .\n    required: true\n  - name: OUTPUT_DIR\n    description: Der Speicherort der kompilierten statischen Dateien von Ihrem Webanwendungs-Builder\n    displayName: Ausgabeverzeichnis\n    value: build\n    required: false\n<\/code><\/pre>\n
\nHier ist alles recht klar, aber man sollte auf den Parameter OUTPUT_DIR achten. F\u00fcr die React-Anwendung aus unserem Beispiel gibt es keinen Grund zur Sorge, da React den Standardwert f\u00fcr das Ausgabeverzeichnis verwendet. Im Fall von Angular oder etwas anderem muss dieser Parameter jedoch entsprechend ge\u00e4ndert werden.<\/p>\n
Jetzt schauen wir uns den Abschnitt der ImageStreams an.<\/p>\n
- apiVersion: v1\n  kind: ImageStream\n  metadata:\n    name: react-web-app-builder  \/\/\/ 1 \n  spec: {}\n- apiVersion: v1\n  kind: ImageStream\n  metadata:\n    name: react-web-app-runtime  \/\/\/ 2 \n  spec: {}\n- apiVersion: v1\n  kind: ImageStream\n  metadata:\n    name: web-app-builder-runtime \/\/\/ 3\n  spec:\n    tags:\n    - name: latest\n      from:\n        kind: DockerImage\n        name: nodeshift\/ubi8-s2i-web-app:10.x\n- apiVersion: v1\n  kind: ImageStream\n  metadata:\n    name: nginx-image-runtime \/\/\/ 4\n  spec:\n    tags:\n    - name: latest\n      from:\n        kind: DockerImage\n        name: 'centos\/nginx-112-centos7:latest'\n<\/code><\/pre>\n
\nSchauen Sie sich das dritte und vierte Bild an. Beide sind als Docker-Images definiert, und man sieht deutlich, woher sie stammen.<\/p>\n
Das dritte Bild ist das web-app-builder und es stammt von nodeshift\/ubi8-s2i-web-app mit dem Tag 10.x auf Docker Hub<\/a><\/noindex>.<\/p>\n
Das vierte ist das NGINX-Image (Version 1.12) mit dem Tag latest auf Docker Hub<\/a><\/noindex>.<\/p>\n
Jetzt sehen wir uns die ersten beiden Bilder an. Beide sind zu Beginn leer und werden nur w\u00e4hrend der Build-Phase erstellt. Das erste Bild \u2013 react-web-app-builder \u2013 wird das Ergebnis der Assemblierungsphase sein, die das Bild web-app-builder-runtime und unseren Quellcode kombiniert. Deshalb haben wir \u201e-builder\u201c im Namen dieses Bildes hinzugef\u00fcgt.<\/p>\n
Das zweite Bild \u2013 react-web-app-runtime \u2013 wird das Ergebnis der Kombination von nginx-image-runtime und einigen Dateien aus dem Bild react-web-app-builder sein. Dieses Bild wird ebenfalls beim Deployment verwendet und enth\u00e4lt nur den Webserver sowie das statische HTML, JavaScript und CSS unserer Anwendung.<\/p>\n
Verwirrend? Schauen wir uns jetzt die Build-Konfigurationen an, und es wird etwas klarer.<\/p>\n
In unserer Vorlage gibt es zwei Build-Konfigurationen. Hier ist die erste davon, und sie ist ziemlich standardm\u00e4\u00dfig:<\/p>\n
  apiVersion: v1\n  kind: BuildConfig\n  metadata:\n    name: react-web-app-builder\n  spec:\n    output:\n      to:\n        kind: ImageStreamTag\n        name: react-web-app-builder:latest \\\/\\\/ 1\n    source:   \\\/\\\/ 2 \n      git:\n        uri: ${SOURCE_REPOSITORY_URL}\n        ref: ${SOURCE_REPOSITORY_REF}\n      contextDir: ${SOURCE_REPOSITORY_DIR}\n      type: Git\n    strategy:\n      sourceStrategy:\n        env:\n          - name: OUTPUT_DIR \\\/\\\/ 3 \n            value: ${OUTPUT_DIR}\n        from:\n          kind: ImageStreamTag\n          name: web-app-builder-runtime:latest \\\/\\\/ 4\n        incremental: true \\\/\\\/ 5\n      type: Source\n    triggers: \\\/\\\/ 6\n    - github:\n        secret: ${GITHUB_WEBHOOK_SECRET}\n      type: GitHub\n    - type: ConfigChange\n    - imageChange: {}\n      type: ImageChange\n<\/code><\/pre>\n
\nWie wir sehen, besagt die Zeile mit dem Etikett 1, dass das Ergebnis dieses Builds in das Bild react-web-app-builder gelegt wird, das wir zuvor im Abschnitt \u00fcber die ImageStreams gesehen haben.<\/p>\n
Die Zeile mit dem Etikett 2 beschreibt, von wo der Code bezogen wird. In unserem Fall handelt es sich um ein Git-Repository, und der Standort, der Ref und das Kontextverzeichnis sind durch die Parameter definiert, die wir oben bereits gesehen haben.<\/p>\n
Die Zeile mit dem Etikett 3 \u2013 das haben wir bereits im Abschnitt \u00fcber die Parameter gesehen. Sie f\u00fcgt die Umgebungsvariable OUTPUT_DIR hinzu, die in unserem Beispiel build entspricht.
\nDie Zeile mit dem Etikett 4 sagt, dass das Bild web-app-builder-runtime verwendet werden soll, das wir bereits im Abschnitt \u00fcber die ImageStreams gesehen haben.<\/p>\n
Die Zeile mit dem Etikett 5 besagt, dass wir einen inkrementellen Build verwenden m\u00f6chten, sofern das S2I-Image dies unterst\u00fctzt, was beim Web App Builder der Fall ist. Bei der ersten Ausf\u00fchrung, nach Abschluss der Zusammenbauphase, speichert das Bild den Ordner node_modules in einer Archivdatei. Bei nachfolgenden Ausf\u00fchrungen wird das Bild einfach diesen Ordner entpacken, um die Build-Dauer zu verk\u00fcrzen.<\/p>\n
Und schlie\u00dflich dient die Zeile mit dem Etikett 6 lediglich dazu, einige Trigger bereitzustellen, damit der Build automatisch gestartet wird, ohne manuelles Eingreifen, wenn sich etwas \u00e4ndert.<\/p>\n
Insgesamt handelt es sich um eine recht Standard-Build-Konfiguration.<\/p>\n
Lassen Sie uns nun einen Blick auf die zweite Build-Konfiguration werfen. Diese \u00e4hnelt der ersten sehr, weist jedoch eine wichtige Abweichung auf.<\/p>\n
apiVersion: v1\n  kind: BuildConfig\n  metadata:\n    name: react-web-app-runtime\n  spec:\n    output:\n      to:\n        kind: ImageStreamTag\n        name: react-web-app-runtime:latest \\\/\\\/ 1\n    source: \\\/\\\/ 2\n      type: Image\n      images:                              \n        - from:\n            kind: ImageStreamTag\n            name: react-web-app-builder:latest \\\/\\\/ 3\n          paths:\n            - sourcePath: \\\/opt\\\/app-root\\\/output\\\/.  \\\/\\\/ 4\n              destinationDir: .  \\\/\\\/ 5\n             \n    strategy: \\\/\\\/ 6\n      sourceStrategy:\n        from:\n          kind: ImageStreamTag\n          name: nginx-image-runtime:latest\n        incremental: true\n      type: Source\n    triggers:\n    - github:\n        secret: ${GITHUB_WEBHOOK_SECRET}\n      type: GitHub\n    - type: ConfigChange\n    - type: ImageChange\n      imageChange: {}\n    - type: ImageChange\n      imageChange:\n        from:\n          kind: ImageStreamTag\n          name: react-web-app-builder:latest \\\/\\\/ 7\n<\/code><\/pre>\n
\nAlso, die zweite Build-Konfiguration \u2013 react-web-app-runtime, und sie beginnt ganz standardm\u00e4\u00dfig.<\/p>\n
In der Zeile mit dem Label 1 gibt es nichts Neues \u2013 sie besagt einfach, dass das Build-Ergebnis in das Image react-web-app-runtime gelegt wird.<\/p>\n
Die Zeile mit dem Label 2, wie in der vorherigen Konfiguration, gibt an, wo der Quellcode hergenommen wird. Aber beachten Sie, dass wir hier sagen, dass er aus dem Image kommt. Und zwar aus dem Image, das wir gerade erstellt haben \u2013 aus react-web-app-builder (in der Zeile mit dem Label 3 angegeben). Die Dateien, die wir verwenden m\u00f6chten, befinden sich im Image und ihr Speicherort dort wird in der Zeile mit dem Label 4 festgelegt, in unserem Fall ist es \/opt\/app-root\/output\/. Wenn Sie sich erinnern, genau dorthin werden die Dateien gelegt, die durch das Build unseres Programms generiert werden.<\/p>\n
Das Zielverzeichnis, das in der Zeile mit dem Label 5 angegeben ist \u2013 ist einfach das aktuelle Verzeichnis (das alles, erinnern wir uns, l\u00e4uft in einem magischen Ding namens OpenShift, nicht auf Ihrem lokalen Computer).<\/p>\n
Der Abschnitt strategy \u2013 die Zeile mit dem Label 6 \u2013 \u00e4hnelt ebenfalls der ersten Build-Konfiguration. Nur dieses Mal werden wir das nginx-image-runtime verwenden, das wir im Abschnitt ImageStream bereits gesehen haben.<\/p>\n
Schlie\u00dflich ist die Zeile mit dem Label 7 der Bereich der Trigger, der diesen Build jedes Mal aktiviert, wenn sich das Image react-web-app-builder \u00e4ndert.<\/p>\n
Abgesehen davon enth\u00e4lt diese Vorlage eine ganz standardm\u00e4\u00dfige Bereitstellungskonfiguration sowie Dinge, die mit den Diensten und Routen zu tun haben, aber darauf werden wir nicht n\u00e4her eingehen. Beachten Sie, dass das Image, das bereitgestellt wird \u2013 das Image react-web-app-runtime ist.<\/p>\n
Anwendungsbereitstellung<\/h3>\n
\nAlso, nachdem wir einen Blick auf die Vorlage geworfen haben, lassen Sie uns sehen, wie wir sie zur Bereitstellung der Anwendung nutzen k\u00f6nnen.<\/p>\n
Wir k\u00f6nnen das OpenShift-Client-Tool namens oc verwenden, um unsere Vorlage bereitzustellen:<\/p>\n
$ find . | grep openshiftio | grep application | xargs -n 1 oc apply -f\n\n$ oc new-app --template react-web-app -p SOURCE_REPOSITORY_URL=https:\/\/github.com\/lholmquist\/react-web-app\n<\/code><\/pre>\n
\nDer erste Befehl auf dem Screenshot oben ist eine absichtlich technische Art, die Vorlage \/openshiftio\/application.yaml zu finden.<\/p>\n
Der zweite Befehl erstellt einfach eine neue Anwendung basierend auf dieser Vorlage.<\/p>\n
Nachdem diese Befehle ausgef\u00fchrt wurden, werden wir sehen, dass wir zwei Builds haben:<\/p>\n
\"Moderne<\/p>\n
Und wenn wir zum Bildschirm \u00dcbersicht zur\u00fcckkehren, sehen wir den laufenden Pod:<\/p>\n
\"Moderne<\/p>\n
Ein Klick auf den Link \u2013 und wir gelangen zu unserer Anwendung, die eine Standard-React-App-Seite darstellt:<\/p>\n
\"Moderne<\/p>\n
Erg\u00e4nzung 1<\/h3>\n
\nF\u00fcr Angular-Liebhaber haben wir auch ein Anwendungsbeispiel<\/a><\/noindex>.<\/p>\n
Die Vorlage hier ist die gleiche, mit der Ausnahme der Variablen OUTPUT_DIR.<\/p>\n
Erg\u00e4nzung 2<\/h3>\n
\nIn diesem Artikel haben wir NGINX als Webserver verwendet, aber es ist ganz einfach, ihn durch Apache zu ersetzen, indem Sie einfach die Vorlagendatei \u00e4ndern. NGINX-Image<\/a><\/noindex> auf Apache-Image<\/a><\/noindex>.<\/p>\n
Fazit<\/h3>\n
\nIm ersten Teil dieser Reihe haben wir gezeigt, wie moderne Webanwendungen schnell auf der OpenShift-Plattform bereitgestellt werden k\u00f6nnen. Heute haben wir betrachtet, was das Web App-Image tut und wie es mit einem reinen Webserver wie NGINX durch verkettete Builds kombiniert werden kann, um eine besser f\u00fcr Produktionsbedingungen geeignete Anwendungserstellung zu organisieren. Im n\u00e4chsten abschlie\u00dfenden Artikel dieser Reihe zeigen wir, wie Sie auf OpenShift einen Entwicklungsserver f\u00fcr Ihre Anwendung starten und die Synchronisierung zwischen lokalen und entfernten Dateien sicherstellen k\u00f6nnen.<\/p>\n
Inhalt dieser Artikelreihe<\/h3>\n
<\/p>\n