Moderne applikationer på OpenShift, del 2: relaterede builds chained builds

Hej alle sammen! Dette er det andet indlæg i vores serie, hvor vi viser, hvordan man implementerer moderne webapplikationer på Red Hat OpenShift.

I det forrige indlæg nævnte vi kort mulighederne for det nye builder-image S2I (source-to-image), der er beregnet til at bygge og implementere moderne webapplikationer på OpenShift-platformen. Dengang var vi interesseret i hurtigt at implementere en applikation, og i dag vil vi se på, hvordan man kan bruge S2I-image som et 'rent' builder-image og kombinere det med tilknyttede builds i OpenShift.

Rent builder-image

Som nævnt i første del har de fleste moderne webapplikationer det, man kalder et build-trin, hvor operationer som transpilation af kode, konkatenering af flere filer og minificering typisk udføres. De filer, der resulterer fra disse operationer – nemlig statisk HTML, JavaScript og CSS – placeres i output-mappen. Placeringen af denne mappe afhænger normalt af, hvilke build-værktøjer der anvendes, og for React vil det være mappen ./build (vi vil komme nærmere tilbage til dette spørgsmål nedenfor).

Source-to-Image (S2I)

I dette indlæg berører vi slet ikke emnet 'hvad er S2I, og hvordan bruger man det' (du kan læse mere om det her), men det er vigtigt at have en klar forståelse af de to faser af denne proces for at forstå, hvad Web App Builder-imaget gør.

Assemblage-trin (assemble phase)

Assemblage-trinnet ligner i sin essens det, der sker, når du kører docker build og får et nyt Docker-image som resultat. Derfor opstår dette trin, når en build startes på OpenShift-platformen.

I tilfælde af Web App Builder-image er det assemble script. Som standard bruger builder-image konstruktionen npm run build, men dette kan overstyres via miljøvariablen NPM_BUILD.

Som vi nævnte tidligere, afhænger placeringen af den færdige, allerede samlede applikation af, hvilke værktøjer der anvendes. For eksempel, i tilfælde af React, vil det være mappen ./build, mens den for Angular-applikationer vil være mappen project_name/dist. Og som allerede vist i det foregående indlæg, kan placeringen af output-kataloget, som som standard er indstillet til build, overskrives via miljøvariablen OUTPUT_DIR. Og da placeringen af output-mappen varierer fra framework til framework, kopierer du simpelthen det genererede output til den standardmappe i billedet, nemlig /opt/apt-root/output. Dette er vigtigt for at forstå den videre del af denne artikel, men lad os hurtigt gennemgå næste trin – kørsel (run phase).

Kørselsfase (run phase)

Denne fase opstår, når der kaldes docker run for et nyt billede, der blev oprettet i samlingsfasen. Den finder også sted ved udrulning på OpenShift-platformen. Som standard kørselskriptet bruger serve module til at levere statisk indhold, der ligger i det ovenfor nævnte standard output-katalog.

Denne metode er god til hurtig udrulning af applikationer, men det anbefales faktisk ikke at levere statisk indhold på denne måde. Men da vi reelt leverer kun statisk indhold, er Node.js, der er installeret i vores billede, ikke nødvendigt – en webserver er tilstrækkelig.

Med andre ord, når vi bygger har vi ét behov, når vi udfører – et andet. I en sådan situation vil kædede builds (chained builds) være nyttige.

Kædede builds (chained builds)

Her er hvad der står om chained builds i OpenShift-dokumentationen:

«To builds kan kædes sammen, hvor den ene genererer en kompileret enhed, og den anden placerer denne enhed i et separat billede, der bruges til at køre denne enhed.»

Med andre ord kan vi bruge Web App Builder billedet til at køre vores build, og derefter bruge webserverbilledet, den samme NGINX, til at levere vores indhold.

Dermed kan vi anvende Web App Builder billedet som en 'ren' builder og samtidig have et lille runtime-billede.

Lad os nu se på dette med et konkret eksempel.

Til træning vil vi bruge en simpel React-applikation, oprettet ved hjælp af kommandolinjeværktøjet create-react-app.

At samle det hele vil blive hjulpet af OpenShift-skabelonfilen.

Lad os se nærmere på denne fil og starte med parameterafsnittet.

parameters:
  - name: SOURCE_REPOSITORY_URL
    description: Kilden URL for applikationen
    displayName: Kilde URL
    required: true
  - name: SOURCE_REPOSITORY_REF
    description: Grennavnet for applikationen
    displayName: Kildegren
    value: master
    required: true
  - name: SOURCE_REPOSITORY_DIR
    description: Placeringen inden for kilde-repositoriet af applikationen
    displayName: Kildekatalog
    value: .
    required: true
  - name: OUTPUT_DIR
    description: Placeringen af de kompilere statiske filer fra din webapps-bygningsværktøj
    displayName: Outputkatalog
    value: build
    required: false

Alt er ret klart her, men vær opmærksom på parameteren OUTPUT_DIR. For React-applikationen i vores eksempel er der ikke noget at bekymre sig om, da React bruger standardværdien som outputmappe, men for Angular eller noget andet skal denne parameter ændres passende.

Lad os nu se på ImageStream-sektionen.

- apiVersion: v1
  kind: ImageStream
  metadata:
    name: react-web-app-builder  // 1 
  spec: {}
- apiVersion: v1
  kind: ImageStream
  metadata:
    name: react-web-app-runtime  // 2 
  spec: {}
- apiVersion: v1
  kind: ImageStream
  metadata:
    name: web-app-builder-runtime // 3
  spec:
    tags:
    - name: latest
      from:
        kind: DockerImage
        name: nodeshift/ubi8-s2i-web-app:10.x
- apiVersion: v1
  kind: ImageStream
  metadata:
    name: nginx-image-runtime // 4
  spec:
    tags:
    - name: latest
      from:
        kind: DockerImage
        name: 'centos/nginx-112-centos7:latest'

Tag et kig på det tredje og fjerde billede. Begge er defineret som Docker-billeder, og her kan vi tydeligt se, hvor de kommer fra.

Det tredje billede er web-app-builder, og det kommer fra nodeshift/ubi8-s2i-web-app med taggen 10.x på Docker hub.

Det fjerde er NGINX-billedet (version 1.12) med taggen latest på Docker hub.

Lad os nu se på de to første billeder. Begge er tomme ved start og oprettes kun i byggefase (build phase). Det første billede, react-web-app-builder, vil være resultatet af samlingsfasen, der kombinerer billedet web-app-builder-runtime og vores kildekode. Det er derfor, vi har tilføjet '-builder' til navnet på dette billede.

Det andet billede, react-web-app-runtime, vil være resultatet af at kombinere nginx-image-runtime og nogle filer fra billedet react-web-app-builder. Dette billede vil også blive brugt ved implementering og vil kun indeholde webserver og den statiske HTML, JavaScript, CSS for vores applikation.

Forvirrende? Lad os nu se på byggekonfigurationerne, så det bliver lidt klarere.

Vi har to byggekonfigurationer i vores skabelon. Her er den første, og den er ret standard:

  apiVersion: v1
  kind: BuildConfig
  metadata:
    name: react-web-app-builder
  spec:
    output:
      to:
        kind: ImageStreamTag
        name: react-web-app-builder:latest // 1
    source:   // 2 
      git:
        uri: ${SOURCE_REPOSITORY_URL}
        ref: ${SOURCE_REPOSITORY_REF}
      contextDir: ${SOURCE_REPOSITORY_DIR}
      type: Git
    strategy:
      sourceStrategy:
        env:
          - name: OUTPUT_DIR // 3 
            value: ${OUTPUT_DIR}
        from:
          kind: ImageStreamTag
          name: web-app-builder-runtime:latest // 4
        incremental: true // 5
      type: Source
    triggers: // 6
    - github:
        secret: ${GITHUB_WEBHOOK_SECRET}
      type: GitHub
    - type: ConfigChange
    - imageChange: {}
      type: ImageChange

Som vi kan se, siger linjen med mærket 1, at resultatet af denne bygning vil blive placeret i det pågældende billede react-web-app-builder, som vi så tidligere i afsnittet om ImageStreams.

Linjen med mærket 2 siger, hvor koden skal hentes fra. I vores tilfælde er det et git-repositorium, og beliggenhed, ref og kontekstmappe er defineret ved hjælp af parametre, som vi allerede har set ovenfor.

Linjen med mærket 3 – det har vi allerede set i afsnittet om parametre. Den tilføjer miljøvariablen OUTPUT_DIR, som i vores eksempel svarer til build.
Linjen med mærket 4 siger, at vi skal bruge billedet web-app-builder-runtime, som vi allerede har set i afsnittet om ImageStreams.

Linjen med mærket 5 siger, at vi ønsker at bruge inkrementel bygning, hvis S2I-billedet understøtter det, og billedet Web App Builder gør det. Ved første kørsel, efter at samlingsfasen er afsluttet, vil billedet gemme mappen node_modules i en arkivfil. Derefter vil billedet blot udpakke denne mappe ved efterfølgende kørsel for at forkorte byggetiden.

Og endelig er linjen med mærket 6 blot et par triggere, så bygningen starter automatisk uden manuel indgriben, når der sker ændringer.

Generelt set er dette en temmelig standardbyggekonfiguration.

Lad os nu se på den anden byggekonfiguration. Den ligner meget den første, men der er én vigtig forskel.

apiVersion: v1
  kind: BuildConfig
  metadata:
    name: react-web-app-runtime
  spec:
    output:
      to:
        kind: ImageStreamTag
        name: react-web-app-runtime:latest // 1
    source: // 2
      type: Image
      images:                              
        - from:
            kind: ImageStreamTag
            name: react-web-app-builder:latest // 3
          paths:
            - sourcePath: /opt/app-root/output/.  // 4
              destinationDir: .  // 5
             
    strategy: // 6
      sourceStrategy:
        from:
          kind: ImageStreamTag
          name: nginx-image-runtime:latest
        incremental: true
      type: Source
    triggers:
    - github:
        secret: ${GITHUB_WEBHOOK_SECRET}
      type: GitHub
    - type: ConfigChange
    - type: ImageChange
      imageChange: {}
    - type: ImageChange
      imageChange:
        from:
          kind: ImageStreamTag
          name: react-web-app-builder:latest // 7

Så, den anden build-konfiguration – react-web-app-runtime, starter ganske standard.

I linjen med mærket 1 er der ikke noget nyt – den siger blot, at resultatet af build'en placeres i billedet react-web-app-runtime.

Linjen med mærket 2 angiver, ligesom i den forrige konfiguration, hvor vi henter kildekoden fra. Men bemærk, at vi her siger, at den hentes fra billedet. Og det billede, vi netop har oprettet – fra react-web-app-builder (angivet i linjen med mærket 3). De filer, vi ønsker at bruge, findes inde i billedet, og deres placering der defineres i linjen med mærket 4, i vores tilfælde er det /opt/app-root/output/. Hvis du husker, så er det netop der, filerne, der genereres som resultat af vores applikations build, placeres.

Målmappen, der er angivet i linjen med mærket 5 – er blot den aktuelle mappe (det hele, lad os huske, kører inden i en slags magisk ting kaldet OpenShift, og ikke på din lokale computer).

Sektionen strategy – linjen med mærket 6 – ligner også den første build-konfiguration. Bare denne gang agter vi at bruge nginx-image-runtime, som vi allerede har set i afsnittet ImageStream.

Endelig er linjen med mærket 7 – sektionen af triggers, der aktiverer denne build hver gang billedet react-web-app-builder ændres.

Ellers indeholder denne skabelon en helt standard deploymentskonfiguration samt ting, der vedrører tjenester og ruter, men vi vil ikke dykke ned i det. Bemærk, at billedet, der skal implementeres – er billedet react-web-app-runtime.

Implementering af applikationen

Så, efter at vi har kigget på skabelonen, lad os se, hvordan vi bruger den til at implementere applikationen.

Vi kan bruge OpenShift-klientværktøjet kaldet oc til at implementere vores skabelon:

$ find . | grep openshiftio | grep application | xargs -n 1 oc apply -f

$ oc new-app --template react-web-app -p SOURCE_REPOSITORY_URL=https://github.com/lholmquist/react-web-app

Den første kommando på skærmen ovenfor – er en bevidst ingeniørmetode til at finde skabelonen ./openshiftio/application.yaml.

Den anden kommando opretter blot en ny applikation baseret på denne skabelon.

Efter at disse kommandoer er kørt, vil vi se, at vi har fået to builds:

Og når vi vender tilbage til oversigtsskærmen, ser vi den kørende pod:

Et klik på linket – og vi går til vores applikation, som er en standard React App-side:

Bilag 1

For Angular enthusiasts, we also have an application example.

The template here is the same, except for the OUTPUT_DIR variable.

Appendix 2

In this article, we used NGINX as the web server, but it's quite easy to replace it with Apache; just change the template file. NGINX image og få en fungerende kommando. Apache image.

Konklusion

In the first part of this series, we showed how to quickly deploy modern web applications on the OpenShift platform. Today, we explored what the Web App image does and how it can be combined with a clean web server like NGINX using chained builds to organize a build more suitable for production conditions. In the next, final article of this series, we will show how to run a development server for your application on OpenShift and ensure synchronization between local and remote files.

Content of this article series

• Part 1: how to deploy modern web applications in just a few steps;
• Part 2: how to apply the new S2I image together with an existing HTTP server image, such as NGINX, using OpenShift's chained builds for organizing production deployment;
• Part 3: how to run a development server for your application on the OpenShift platform and synchronize it with the local file system.

Yderligere ressourcer

• Gratis e-bog Deploying to OpenShift.
• Information on OpenShift og Kubernetes.

Kilde: habr.com