{"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: Verkn\u00fcpfte 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 bereitstellt. <\/p>\n

\"Moderne
\n
\nIm vorherigen Beitrag haben wir kurz die M\u00f6glichkeiten des neuen S2I (Source-to-Image) Builder-Images er\u00f6rtert, das zur Erstellung und Bereitstellung moderner Webanwendungen auf der OpenShift-Plattform dient. Dabei haben wir uns mit dem Thema der schnellen Bereitstellung von Anwendungen besch\u00e4ftigt, und heute schauen wir uns an, wie man das S2I-Image als 'reines' Builder-Image verwenden und mit verkn\u00fcpften Builds in OpenShift kombinieren kann.
\n<\/a><\/noindex><\/p>\n

Reines Builder-Image<\/h3>\n

\nWie bereits im ersten Teil erw\u00e4hnt, verf\u00fcgen die meisten modernen Webanwendungen \u00fcber einen sogenannten Build-Schritt, in dem normalerweise Operationen wie Code-Transpilation, das Zusammenf\u00fchren mehrerer Dateien und Minifizierung stattfinden. Die aus diesen Vorg\u00e4ngen resultierenden Dateien \u2013 also statisches HTML, JavaScript und CSS \u2013 werden im Output-Ordner abgelegt. Der Ort dieses Ordners h\u00e4ngt normalerweise davon ab, welche Build-Tools verwendet werden, und f\u00fcr React ist dies der Ordner .\/build (wir werden auf dieses Thema weiter unten detaillierter eingehen).<\/p>\n

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

\nIn diesem Beitrag besch\u00e4ftigen wir uns nicht mit dem Thema \u201eWas ist S2I und wie verwendet man es?\u201c (dar\u00fcber k\u00f6nnen Sie mehr lesen hier<\/a><\/noindex>), jedoch ist es wichtig, die beiden Phasen dieses Prozesses klar zu verstehen, um zu begreifen, was das Web App Builder-Image macht.<\/p>\n

Phase der Assemblierung<\/h4>\n

\nDie Assemblierungsphase \u00e4hnelt im Wesentlichen dem, was passiert, wenn Sie `docker build` ausf\u00fchren und schlie\u00dflich ein neues Docker-Image erhalten. Diese Phase tritt entsprechend auf, wenn der Build auf der OpenShift-Plattform gestartet wird.<\/p>\n

Im Fall des Web App Builder-Images ist das Assemblierungsskript<\/a><\/noindex>f\u00fcr die Installation der Abh\u00e4ngigkeiten Ihrer Anwendung und den Start des Builds verantwortlich. Standardm\u00e4\u00dfig verwendet das Builder-Image den Befehl `npm run build`, dieser kann jedoch \u00fcber die Umgebungsvariable NPM_BUILD \u00fcberschrieben werden.<\/p>\n

Wie bereits erw\u00e4hnt, h\u00e4ngt der Standort der bereitgestellten Anwendung von den verwendeten Werkzeugen ab. Bei React zum Beispiel befindet sich dieser im 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 Ausgabeverzeichnisses, das standardm\u00e4\u00dfig auf build gesetzt ist, \u00fcber die Umgebungsvariable OUTPUT_DIR \u00fcberschrieben werden. Da der Speicherort des Ausgabeverzeichnisses je nach Framework unterschiedlich ist, kopieren Sie einfach die generierte Ausgabe in das Standardverzeichnis im Image, n\u00e4mlich nach \/opt\/apt-root\/output. Dies ist wichtig f\u00fcr das Verst\u00e4ndnis des weiteren Teils dieses Artikels. Lassen Sie uns nun schnell zum n\u00e4chsten Schritt \u00fcbergehen \u2013 der Phase des Ausf\u00fchrens (run phase).<\/p>\n

Phase des Ausf\u00fchrens (run phase)<\/h4>\n

\nDiese Phase tritt ein, wenn f\u00fcr das neue Image, das in der Assemblierungsphase erstellt wurde, der Befehl docker run aufgerufen wird. Dies geschieht auch bei der Bereitstellung auf der OpenShift-Plattform. Standardm\u00e4\u00dfig run script<\/a><\/noindex> nutzt serve module<\/a><\/noindex> zum Bereitstellen von statischem Inhalt, der im oben angegebenen Standard-Ausgabeverzeichnis liegt.<\/p>\n

Diese Methode eignet sich gut f\u00fcr die schnelle Bereitstellung von Anwendungen, allerdings sollte statischer Inhalt nicht auf diese Weise bereitgestellt werden. Da wir tats\u00e4chlich nur statischen Inhalt bereitstellen, ist die in unserem Node.js-Image enthaltene Installation nicht erforderlich \u2013 ein Webserver reicht aus.<\/p>\n

Anders gesagt, ben\u00f6tigen wir bei der Erstellung das eine, beim Ausf\u00fchren das andere. In solchen Situationen sind verkettete Builds (chained builds) n\u00fctzlich.<\/p>\n

Verkettete Builds (chained builds)<\/h3>\n

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

\u201eZwei Builds k\u00f6nnen miteinander verkn\u00fcpft werden, wobei einer ein kompiliertes Artefakt erzeugt und der andere dieses Artefakt in einem separaten Image speichert, das verwendet wird, um dieses Artefakt auszuf\u00fchren.\u201c\n<\/p><\/blockquote>\n

\nAnders gesagt, wir k\u00f6nnen das Image Web App Builder verwenden, um unseren Build auszuf\u00fchren, und dann das Image des Webservers, also NGINX, verwenden, um unseren Inhalt bereitzustellen.<\/p>\n

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

Schauen wir uns das nun an einem konkreten Beispiel an.<\/p>\n

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

Um alles zusammenzuf\u00fchren, ben\u00f6tigen wir die OpenShift-Vorlagendatei.<\/a><\/noindex>.<\/p>\n

Wir werden diese Datei im Detail durchgehen und beginnen mit dem Abschnitt f\u00fcr Parameter.<\/p>\n

parameters:\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 Web-App-Builder\n    displayName: Ausgabeverzeichnis\n    value: build\n    required: false\n<\/code><\/pre>\n
\nDas ist alles recht klar, aber man sollte auf den Parameter OUTPUT_DIR achten. F\u00fcr die React-Anwendung aus unserem Beispiel besteht kein Grund zur Sorge, da React den Standardwert f\u00fcr das Ausgabeverzeichnis verwendet. Bei Angular oder etwas anderem muss dieser Parameter entsprechend angepasst werden.<\/p>\n
Nun 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
\nBetrachten Sie die dritte und vierte Abbildung. Beide sind als Docker-Images definiert, und es ist deutlich zu sehen, woher sie stammen.<\/p>\n
Das dritte Image ist der web-app-builder und 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 schauen wir uns die ersten beiden Images an. Beide sind zu Beginn leer und werden nur w\u00e4hrend des Build-Prozesses erstellt. Das erste Image \u2013 react-web-app-builder \u2013 wird das Ergebnis der Assembly-Phase sein, in der das Image web-app-builder-runtime und unser Quellcode kombiniert werden. Deshalb haben wir in den Namen dieses Images \u201e-builder\u201c aufgenommen.<\/p>\n
Das zweite Image \u2013 react-web-app-runtime \u2013 entsteht durch die Kombination von nginx-image-runtime und einigen Dateien aus dem Image react-web-app-builder. Dieses Image wird ebenfalls beim Deployment verwendet und enth\u00e4lt ausschlie\u00dflich den Webserver sowie das statische HTML, JavaScript und CSS unserer Anwendung.<\/p>\n
Klingt kompliziert? Lassen Sie uns die Build-Konfigurationen ansehen, dann wird es etwas klarer.<\/p>\n
In unserer Vorlage gibt es zwei Build-Konfigurationen. Hier ist die erste, die ziemlich standardm\u00e4\u00dfig ist:<\/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 \n    source:\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 \n            value: ${OUTPUT_DIR}\n        from:\n          kind: ImageStreamTag\n          name: web-app-builder-runtime:latest \n        incremental: true \n      type: Source\n    triggers:\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 k\u00f6nnen, gibt die Zeile mit dem Label 1 an, dass das Ergebnis dieses Builds in das Image react-web-app-builder eingef\u00fcgt wird, das wir zuvor im Abschnitt \u00fcber ImageStreams gesehen haben.<\/p>\n
Die Zeile mit dem Label 2 gibt an, wo der Code herkommt. In unserem Fall handelt es sich um ein Git-Repository, und die Position, der Ref und der Kontext-Ordner sind durch Parameter definiert, die wir bereits zuvor gesehen haben.<\/p>\n
Die Zeile mit dem Label 3 haben wir bereits im Abschnitt Parameter gesehen. Sie f\u00fcgt die Umgebungsvariable OUTPUT_DIR hinzu, die in unserem Beispiel den Wert build hat.
\nDie Zeile mit dem Label 4 weist darauf hin, dass wir das Image web-app-builder-runtime verwenden m\u00f6chten, das wir bereits im Abschnitt ImageStream gesehen haben.<\/p>\n
Die Zeile mit dem Label 5 besagt, dass wir einen inkrementellen Build verwenden m\u00f6chten, sofern das S2I-Image dies unterst\u00fctzt, und das Image Web App Builder unterst\u00fctzt dies. Beim ersten Start wird nach Abschluss der Assemblierungsphase der Ordner node_modules in einer Archivdatei gespeichert. Bei sp\u00e4teren Starts wird das Image einfach diesen Ordner entpacken, um die Build-Dauer zu verk\u00fcrzen.<\/p>\n
Und schlie\u00dflich enth\u00e4lt die Zeile mit dem Label 6 nur einige Trigger, damit der Build automatisch ausgef\u00fchrt wird, ohne manuelles Eingreifen, wenn sich etwas \u00e4ndert.<\/p>\n
Insgesamt handelt es sich um eine recht standardisierte Build-Konfiguration.<\/p>\n
Schauen wir uns nun die zweite Build-Konfiguration an. Sie \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
\nDie zweite Build-Konfiguration \u2013 react-web-app-runtime \u2013 beginnt ganz Standardm\u00e4\u00dfig.<\/p>\n
In der Zeile mit dem Label 1 gibt es nichts Neues \u2013 sie sagt einfach, dass das Ergebnis der Build in das Bild react-web-app-runtime gelegt wird.<\/p>\n
Die Zeile mit dem Label 2 gibt an, woher der Quellcode stammt, \u00e4hnlich wie in der vorherigen Konfiguration. Dabei beachten Sie bitte, dass er aus dem Image stammt. Und zwar aus dem Image, das wir gerade erstellt haben \u2013 aus react-web-app-builder (wie in der Zeile mit dem Label 3 angegeben). Die Dateien, die wir verwenden m\u00f6chten, befinden sich innerhalb des Images, und ihr Speicherort wird in der Zeile mit dem Label 4 festgelegt, in unserem Fall ist das \/opt\/app-root\/output\/. Wenn Sie sich erinnern, werden genau dort die Dateien abgelegt, die aus dem Build-Ergebnis unserer Anwendung generiert wurden.<\/p>\n
Der Zielordner, der in der Zeile mit dem Label 5 angegeben ist, ist einfach das aktuelle Verzeichnis (alles l\u00e4uft, erinnern Sie sich, innerhalb einer magischen Sache namens OpenShift und nicht auf Ihrem lokalen Computer).<\/p>\n
Der Abschnitt strategy \u2013 die Zeile mit dem Label 6 \u2013 \u00e4hnelt ebenfalls der ersten Build-Konfiguration. Dieses Mal werden wir jedoch 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 Abschnitt der Trigger, der diesen Build jedes Mal aktiviert, wenn sich das Image react-web-app-builder \u00e4ndert.<\/p>\n
Ansonsten enth\u00e4lt diese Vorlage eine ganz standardisierte Bereitstellungskonfiguration sowie Elemente, die mit Diensten und Routen zu tun haben. Wir werden jedoch nicht n\u00e4her darauf eingehen. Bitte beachten Sie, dass das Bild, das bereitgestellt wird, das Bild react-web-app-runtime ist.<\/p>\n
Anwendungsbereitstellung<\/h3>\n
\nNachdem wir nun einen Blick auf die Vorlage geworfen haben, sehen wir uns an, wie wir sie f\u00fcr die Bereitstellung einer 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 im obigen Screenshot ist absichtlich technisch, um 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, sehen wir, dass wir zwei Builds erhalten haben:<\/p>\n
\"Moderne<\/p>\n
Und wenn wir zum Bildschirm \u00dcbersicht zur\u00fcckkehren, sehen wir das gestartete Pod:<\/p>\n
\"Moderne<\/p>\n
Ein Klick auf den Link und wir gelangen zu unserer Anwendung, die die Standardseite der React-App darstellt:<\/p>\n
\"Moderne<\/p>\n
Erg\u00e4nzung 1<\/h3>\n
\nF\u00fcr Angular-Begeisterte haben wir ebenfalls ein Anwendungsbeispiel<\/a><\/noindex>.<\/p>\n
Die Vorlage hier ist identisch, abgesehen von der Variable OUTPUT_DIR.<\/p>\n
Erg\u00e4nzung 2<\/h3>\n
\nIn diesem Artikel haben wir NGINX als Webserver verwendet, es ist jedoch ziemlich einfach, ihn durch Apache zu ersetzen, indem Sie einfach die Vorlagendatei \u00e4ndern. NGINX-Image<\/a><\/noindex> findet man Apache-Image<\/a><\/noindex>.<\/p>\n
Fazit<\/h3>\n
\nIm ersten Teil dieser Reihe haben wir gezeigt, wie man moderne Web-Anwendungen schnell auf der OpenShift-Plattform bereitstellt. Heute haben wir uns angesehen, was ein Web-App-Image ausmacht und wie es mit einem reinen Webserver wie NGINX mithilfe von verkn\u00fcpften Builds (chained builds) zu einer f\u00fcr Produktionsumgebungen geeigneten App-Bereitstellung kombiniert werden kann. Im n\u00e4chsten und letzten Artikel dieser Reihe zeigen wir, wie Sie auf OpenShift einen Entwicklungsserver f\u00fcr Ihre Anwendung starten und die Synchronisierung von lokalen und entfernten Dateien gew\u00e4hrleisten k\u00f6nnen.<\/p>\n
Inhalt dieser Artikelreihe<\/h3>\n
<\/p>\n