🥇Kaasaegsed rakendused OpenShiftis, osa 2: seotud ehitused chained builds

Tere kõigile! Siin on meie teise postituse seeria, kus näitame, kuidas juurutada tänapäevaseid veebirakendusi Red Hat OpenShiftis.

Eelnevas postituses käsitlesime veidi uue S2I (source-to-image) builder-pildi võimalusi, mis on mõeldud tänapäevaste veebirakenduste kogumiseks ja juurutamiseks OpenShifti platvormil. Toona huvitusime rakenduse kiirest juurutamisest, täna vaatame aga, kuidas kasutada S2I pilti „puhta” builder-pildina ja kombineerida seda seotud OpenShift'i kogumistega.

Puhas builder-pilt

Kuidas me esimeses osas mainisime, on enamikul tänapäevastest veebirakendustest nii-öelda kogumise etapp, kus tavaliselt teostatakse selliseid toiminguid nagu koodi transpileerimine, mitme faili ühendamine ja minimeerimine. Saadud failid – staatiline HTML, JavaScript ja CSS – paigutatakse väljundkausta. Selle kausta asukoht sõltub tavaliselt sellest, milliseid kogumise tööriistu kasutatakse, ja React'i puhul on see kaust ./build (naaseme selle küsimuse juurde lähemal ajal).

Source-to-Image (S2I)

Selles postituses ei käsitleme teemat "mis on S2I ja kuidas seda kasutada" (lisaks sellele saab lugeda siit), kuid on oluline selgelt mõista kahte etappi, et mõista, mida Web App Builderi pilt teeb.

Kokkuvõtte etapp (assemble phase)

Kokkuvõtte etapp on oma olemuselt väga sarnane sellele, mis juhtub, kui käivitate docker build ja saate uue Docker-pildi. Seega tekib see etapp OpenShift platvormil kokkupaneku käivitamisel.

Web App Builderi pildi puhul vastutab teie rakenduse sõltuvuste installimise ja kokkupaneku käivitamise eest assemble script. Vaikimisi kasutab builder-pilt npm run build käsu, kuid seda saab ümber määrata keskkonnamuutuja NPM_BUILD kaudu.

Nagu varem mainitud, sõltub valmis, juba kokku pandud rakenduse asukoht kasutatavatest tööriistadest. Näiteks Reacti puhul asub see kaustas ./build, Angulari rakenduste puhul aga kaustas project_name/dist. Ja nagu eelmisel postitusel näidatud, saab vaikimisi määratud output-katalooge, mis on build, üle kirjutada keskkonnamuutujaga OUTPUT_DIR. Kuna output-kausta asukoht sõltub raamistikust, kopeerite lihtsalt genereeritud väljundi standardkausta, see on /opt/apt-root/output. See on oluline arusaamiseks käesoleva artikli järgnevast osast, aga nüüd vaatame kiirelt järgmise etapi – käivitamise (run phase) – üle.

Käivitamise etapp (run phase)

See etapp algab, kui uue pildi jaoks, mis loodi assamblee etapis, tehakse docker run käsk. See toimub samuti OpenShift platvormil juurutamisel. Vaikimisi käivitusskript kasutab teenindusmoodul statilise sisu teenindamiseks, mis asub eespool nimetatud standardse output-katalooge.

See meetod sobib rakenduste kiireks juurutamiseks, kuid tegelikult ei soovitata staatilise sisu sellisel viisil teenindada. Kuna me tegelikult teenindame ainult staatilist sisu, pole meie Node.js pildi sees installimine vajalik – piisab veebiserverist.

Teisisõnu, ehitamisel vajame ühte ja täitmisel – teist. Sellises olukorras tulevad kasuks seotud ehitused (chained builds).

Seotud ehitused (chained builds)

Siin on, mida kirjutatakse chained builds OpenShift'i dokumentatsioonis:

„Kaks ehitust saab omavahel siduda, kusjuures üks neist genereerib kompileeritud üksuse ja teine paigutab selle üksuse eraldi pildile, mida kasutatakse selle üksuse käitamiseks.”

Teiste sõnadega, me saame kasutada Web App Builder pildil meie ehituse käitamiseks ja seejärel kasutada veebiserveri pilti, näiteks NGINX-i, et teenindada meie sisu.

Nii saame rakendada Web App Builder pilti kui "puhtat" builder'it ja omada samal ajal väikese suurusega käituspilti.

Nüüd vaatame seda konkreetse näite põhjal.

Treeninguks kasutame lihtsat React rakendust, loodud käsurea tööriista create-react-app abil.

Kogume kõik kokku meie abiga OpenShift'i mallifail.

Vaatame seda faili lähemalt ja alustame parameetrite osast.

parameters:
  - name: SOURCE_REPOSITORY_URL
    description: Rakenduse allika URL
    displayName: Allika URL
    required: true
  - name: SOURCE_REPOSITORY_REF
    description: Rakenduse haru nimi
    displayName: Allika haru
    value: master
    required: true
  - name: SOURCE_REPOSITORY_DIR
    description: Rakenduse asukoht allika repos
    displayName: Allika kataloog
    value: .
    required: true
  - name: OUTPUT_DIR
    description: Koostatud staatiliste failide asukoht teie veebirakenduste koostajana
    displayName: Väljund kataloog
    value: build
    required: false

Siin on kõik üsna selge, kuid tasub tähelepanu pöörata parameetrile OUTPUT_DIR. Meie näite React-rakenduse puhul ei pea muretsema, kuna React kasutab väljundikaustana vaikeväärtust, kuid Angulari või millegi muu puhul tuleb see parameeter vastavalt muuta.

Nüüd vaatame ImageStreamide sektsiooni.

- 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'

Vaata kolmandat ja neljandat pilti. Need on mõlemad määratletud kui Docker-pildid ja on selgelt nähtav, kust need tulevad.

Kolmas pilt on web-app-builder ja see pärineb nodeshift/ubi8-s2i-web-app versiooniga 10.x. Docker hub.

Neljas on NGINX pilt (versioon 1.12) versiooniga latest. Docker hub.

Nüüd vaatame kahte esimest pilti. Need on mõlemad alguses tühjad ja luuakse ainult ehitusetapis (build phase). Esimene pilt – react-web-app-builder – saab olema assemblimise etapi tulemus, mis liidab web-app-builder-runtime pildi ja meie lähtekoodi. Just seetõttu olime selle pildi nime kirjutanud "-builder".

Teine pilt – react-web-app-runtime – on nginx-image-runtime'i ja mõnede failide kombinatsioon, mis pärinevad react-web-app-builder pildist. See pilt kasutatakse samuti juurutamisel ning see sisaldab ainult meie rakenduse veebiserverit ja staatilist HTML-i, JavaScripti ja CSS-i.

Kas see on keeruline? Vaatame nüüd ehituskonfiguratsioone, siis saab veidi arusaadavamaks.

Meie mallis on kaks ehituskonfiguratsiooni. Siin on neist esimene, mis on üsna standartne:

  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

Nagu näha, ütleb märgistuse 1 rida, et selle ehituse tulemus paigutatakse just sellesse react-web-app-builder pilti, mida me varem ImageStreamide jaotises nägime.

Märgitud rida 2 ütleb, kust koodi võtta. Meie puhul on see git-repositoorium, samas kui asukoht, ref ja konteksti kaust on määratud parameetritega, mida oleme juba varem näinud.

Märgitud rida 3 – see on see, mida oleme juba näinud jaotises parameetrid. See lisab keskkonnamuutuja OUTPUT_DIR, mis meie näites on igual to build.
Märgitud rida 4 ütleb kasutada pilti web-app-builder-runtime, mida me oleme juba näinud jaotises ImageStream.

Märgitud rida 5 ütleb, et soovime kasutada inkrementeerimist, kui S2I-pilt seda toetab, ja Web App Builder – toetab. Esmase käivitamise ajal, pärast koostamisfaasi lõpetamist, salvestab pilt kausta node_modules arhiivifaili. Siis järgmistel käivitustel lihtsalt dekompresseerib pilt selle kausta, et vähendada koostamise kestust.

Ja lõpuks, märgitud rida 6 – see on lihtsalt mõned käivitajad, et koostamine algaks automaatselt, ilma käsitsemise sekkumiseta, kui midagi muutub.

Üldiselt on see üsna standardne koostamisconfig.

Nüüd vaatame teist koostamisseadet. See on väga sarnane esimesele, kuid seal on üks oluline erinevus.

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

Nii, teine kogumiskonfiguratsioon on react-web-app-runtime, ja see algab üsna standardina.

Märgil 1 ei ole midagi uut – see ütleb lihtsalt, et kogumise tulemus salvestatakse react-web-app-runtime pildile.

Märgisest 2 rida, nagu ka eelnevas konfiguratsioonis, näitab, kust lähtekoodi võtta. Kuid pidage meeles, et siin räägime, et see võetakse pildist. Ja just sellest pildist, mille me just loome – react-web-app-builder (mille oleme määranud märgis 3). Failid, mida soovime kasutada, asuvad pildi sees ja nende asukoht seal on määratud märgis 4, meie puhul see on /opt/app-root/output/. Kui mäletate, siis just sinna laaditakse failid, mis genereeritakse meie rakenduse kogumise tulemuste põhjal.

Sihtkaust, mille määrasime märgis 5 – on lihtsalt praegune kataloog (kõik see, meenutame, käib mingisuguse maagilise asja nimega OpenShift sees, mitte teie kohalikus arvutis).

Jaotises strategy – rida, millel on märgis 6 – näeb samuti välja nagu esimene kogumiskonfiguratsioon. Ainult seekord kavandame kasutada nginx-image-runtime'i, mida oleme juba näinud jaos ImageStream.

Lõpuks, rida, millel on märgis 7 – on käivitajate jaotis, mis aktiveerib selle kogumise igal korral, kui react-web-app-builder pilt muutub.

Tegu on muidu üsna standardse juurutamissektori konfiguratsiooniga ning hõlmab ka teenuseid ja marsruute, kuid me ei süvene sellesse. Pange tähele, et juurutatav pilt on react-web-app-runtime.

Rakenduse juurutamine

Nii et pärast seda, kui oleme vaadanud šablooni, vaatame, kuidas seda rakenduse juurutamiseks kasutada.

Me kasutame OpenShift'i kliendi tööriista nimega oc, et juurutada meie šabloon:

$ 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

Esimene käsk ülaltoodud ekraanil on ekslikult inseneritehniline viis šablooni leidmiseks ./openshiftio/application.yaml.

Teine käsk loob lihtsalt uue rakenduse selle šablooni põhjal.

Pärast nende käskude täitmist näeme, et meil on kaks koostamist:

Ja tagasipöördudes Overview ekraanile, näeme jooksva pod'i:

Linki klõpsates jõuame meie rakendusele, mis on vaikesättega React App leht:

Täiend 1

Angulari fännide jaoks on meil ka rakenduse näidis.

Mall on sama, välja arvatud muutuja OUTPUT_DIR.

Lisa 2

Selles artiklis kasutasime veebiserverina NGINX-i, kuid selle saab hõlpsasti asendada Apache'iga, lihtsalt muutes mallifailis. NGINX-i pilt järgnevaga Apache'i pilt.

Kokkuvõte

Selle seeria esimeses osas näitasime, kuidas kiiresti juurutada kaasaegseid veebirakendusi OpenShift platvormil. Täna vaatame, mida teeb Veebirakenduse pilt ja kuidas seda saab ühendada puhta veebiserveriga nagu NGINX, kasutades seotud ehitusi (chained build), et korraldada rakenduste ehitus rohkem tootmistingimustele sobivalt. Seeria järgmises, viimases artiklis näitame, kuidas OpenShiftis käivitada arendusserver oma rakenduse jaoks ja tagada kohapealsete ja eemalsete failide sünkroonimine.

Selle seeria artiklite sisu

Osa 1: kuidas juurutada kaasaegseid veebirakendusi vaid mõne sammuga;
Osa 2: kuidas rakendada uut S2I pilti koos juba olemasoleva HTTP-serveri pildiga, näiteks NGINX, kasutades OpenShifti seotud ehitusi tootmisjuurutuse korraldamiseks;
Osa 3: kuidas avada OpenShift platvormil arendusserver oma rakendusele ja sünkroonida see kohaliku failisüsteemiga.