🥇Kaasaegsed rakendused OpenShift'il, osa 2: seotud kogumid chained builds

Tere kõigile! See on meie teise postituse seeria, kus näitame, kuidas juurutada kaasaegseid veebirakendusi Red Hat OpenShiftis.

Eelmisel postitusel puudutasime veidi uue S2I (source-to-image) builder-ima võimalusi, mis on mõeldud kaasaegsete veebirakenduste kogumiseks ja juurutamiseks OpenShift platvormil. Sel korral keskendume kiire juurutamise teemale, kuid täna vaatame, kuidas kasutada S2I-ima ‚puhta‘ builder-ima ja ühendada seda seotud OpenShifti kogumitega.

Puhas builder-ima

Kuidas mainisime esimeses osas, on enamikul kaasaegsetest veebirakendustest nn kogumisetapp, kus tavaliselt viiakse läbi sellised toimingud nagu koodi transpileerimine, mitme faili ühendamine ja minifikatsioon. Neid toiminguid tulemusena saadud failid – need on staatiline HTML, JavaScript ja CSS – paigutatakse väljundkausta. Selle kausta asukoht sõltub tavaliselt kasutatavatest kogumistööriistadest ja Reacti puhul on see kaust ./build (täiendame seda teemat allpool).

Source-to-Image (S2I)

Selles postituses me ei käsitle teemat „mis on S2I ja kuidas seda kasutada“ (selle kohta saab rohkem lugeda siin), kuid on oluline selgelt mõista selle protsessi kahte etappi, et mõista, mida teeb Web App Builder'i ima.

Kogumise etapp (assemble phase)

Kogumise etapp on oma olemuselt väga sarnane sellele, mis juhtub, kui käivitate docker build'i ja saate tulemuseks uue Docker-i ima. Seetõttu toimub see etapp OpenShift platvormil kogumise käivitamisel.

Web App Builder'i ima puhul vastutab teie rakenduse sõltuvuste installimise ja kogumise käivitamise eest assemble script. Vaikimisi kasutab builder-ima konstruktsiooni npm run build, kuid seda saab ületada keskkonnamuutujaga NPM_BUILD.

Nagu varem mainitud, sõltub valminud, juba kokku pandud rakenduse asukoht kasutatavadest tööriistadest. Näiteks Reacti puhul on see kaust ./build, Angulari rakenduste puhul aga kaust project_name/dist. Ja nagu eelmises postituses näidatud, saab väljundikausta asukohta, mis on vaikimisi määratud kui build, üle kirjutada keskkonnamuutuja OUTPUT_DIR kaudu. Kuna väljundikausta asukoht erineb raamistikust raamistikku, kopeerite lihtsalt genereeritud väljundi standardkausta kujunduses, nimelt /opt/apt-root/output. See on oluline edasise osa mõistmiseks, aga vahepeal vaatame kiirelt järgmist etappi – käivitamine (run phase).

Käivitamise etapp (run phase)

See etapp tekib, kui uue kujundi, mis on loodud assambleerimise etapis, kutsutakse välja docker run. See toimub ka avamisel OpenShift platvormil. Vaikimisi käivitusskripti kasutab serve moodul staatilise sisu teenindamiseks, mis asub ülaltoodud standardse väljundikausta.

See meetod on hea rakenduste kiireks juurutamiseks, kuid tegelikult ei ole soovitatav staatilist sisu sellisel moel teenindada. Kuna me teenindame ainult staatilist sisu, ei ole meie kujunduses sisalduv Node.js vajalik – piisab veebiserverist.

Teisisõnu, kogumisel on meil üks, käivitamisel aga teine. Sellises olukorras tulevad kasuks seotud kogumid (chained builds).

Seotud kogumid (chained builds)

Siin on, mida öeldakse seotud kogumite (chained builds) OpenShift dokumentatsioonis:

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

Teisisõnu, me võime kasutada Web App Builder'i kujundit, et käivitada meie kogumine, ja seejärel kasutada veebiserveri kujundit, näiteks NGINX-i, et teenindada meie sisu.

Seega saame kasutada Web App Builder'i kujundit kui „puhast“ builder'it ja samal ajal omada väikese suurusega runtime kujundit.

Nüüd käsitleme seda konkreetses näites.

Treeninguks kasutame lihtsat React rakendust, mis on loodud käsureatööriista create-react-app abil.

Koguda kõik kokku aitab meil OpenShift'i mallifail.

Vaatame seda faili lähemalt ja alustame parameetrite jaotusest.

parameetrid:
  - nimi: SOURCE_REPOSITORY_URL
    kirjeldus: Rakenduse allika URL
    kuvamisnimi: Allika URL
    nõutav: tõene
  - nimi: SOURCE_REPOSITORY_REF
    kirjeldus: Rakenduse haru nimi
    kuvamisnimi: Allika haru
    väärtus: master
    nõutav: tõene
  - nimi: SOURCE_REPOSITORY_DIR
    kirjeldus: Rakenduse asukoht allika repositooriumis
    kuvamisnimi: Allika kaust
    väärtus: .
    nõutav: tõene
  - nimi: OUTPUT_DIR
    kirjeldus: Koht kompileeritud staatiliste failide jaoks teie veebirakenduse koosturi seest
    kuvamisnimi: Väljundi kaust
    väärtus: build
    nõutav: vale

Siin on kõik üsna arusaadav, kuid väärtus OUTPUT_DIR parameetrit tuleks tähelepanelikult vaadata. Meie näites React-rakenduse puhul ei pea me muretsema, kuna React kasutab väljundikaustana vaikimisi väärtust, kuid Angulari või muu puhul tuleb see parameeter vastavalt muuta.

Nüüd vaatame ImageStream-ide jaotust.

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

Vaadake kolmandat ja neljandat pilti. Need on mõlemad määratletud kui Docker-pildid ja on selgelt näha, kust nad pärinevad.

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

Neljandaks on NGINX (versioon 1.12) pilt koos sildiga latest Docker hub.

Nüüd vaatame kahte esimest pilti. Need on mõlemad alguses tühjad ja luuakse ainult koostamisetapis (build phase). Esimene pilt – react-web-app-builder – saab olema koosseisu tulemuseks, mis ühendab web-app-builder-runtime pildi ja meie lähtekoodi. Seetõttu lisasime sellele pildile nime lõppu „-builder”.

Teine pilt – react-web-app-runtime – saab olema nginx-image-runtime ja mõne faili ühendamise tulemus react-web-app-builder pildist. See pilt kasutatakse samuti juurutamisel ja sisaldab ainult veebiserverit ning meie rakenduse staatilist HTML-i, JavaScripti ja CSS-i.

Järsk? Vaatame nüüd koostamiskonfiguratsioone ja see muutub veidi selgemaks.

Meie mallel on kaks koostamiskonfiguratsiooni. Siin on neist esimene ja see on üsna tavaline:

  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

Kuidas näeme, et 1. märgiga rida ütleb, et selle kompileerimise tulemus paigutatakse just sellesse pildi react-web-app-builder, mida me varem nägime ImageStreamide jagu.

2. märgiga rida ütleb, kust koodi võtta. Meie puhul on see git-repositoorium ning asukoht, ref ja kontekstikaust on määratletud parameetritega, mida oleme juba varem näinud.

3. märgiga rida – see on see, mida me oleme juba näinud parameetrite sektsioonis. See lisab keskkonnamuutuja OUTPUT_DIR, mis meie näites on võrdundus build.
4. märgiga rida ütleb kasutada pilti web-app-builder-runtime, mida me oleme juba näinud ImageStreamide sektsioonis.

5. märgiga rida ütleb, et me tahame kasutada inkrementaalset kompileerimist, kui S2I-pilt seda toetab, ja Web App Builder toetab. Esimese käivitamise ajal, pärast kokkupanekufaasi lõpetamist, salvestab pilt node_modules kausta arhivifaili. Seejärel järgmisel käivitamisel dekompresseerib pilt lihtsalt selle kausta, et lühendada ehituskestvust.

Ja lõpuks, 6. märgiga rida – see on lihtsalt mõned triggarid, et kompileerimist saaks automaatselt alustada, ilma käsitsi sekkumiseta, kui midagi muutub.

Ühesõnaga, see on üsna tavaline kompileerimise konfiguratsioon.

Nüüd vaatame teist kompileerimiskonfiguratsiooni. See on väga sarnane esimesele, kuid 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\/.
              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 et, teine konfiguratsioon on react-web-app-runtime ja see algab üsna tavapäraselt.

Märgi 1 real pole midagi uut – see ütleb lihtsalt, et koostamise tulemus pannakse react-web-app-runtime pildile.

Märgi 2 real, nagu ka eelnevas konfiguratsioonis, näidatakse, kust lähtekood võtta. Kuid pöörake tähelepanu, et siin öeldakse, et see võetakse pildist. Ja see pilt, millest me just rääkisime, on react-web-app-builder (mille oleme näidanud märgi 3 real). Failid, mida soovime kasutada, asuvad pildi sees ja nende asukoht seal määratakse märgi 4 real, meie puhul on see \/opt\/app-root\/output\/. Kui mäletate, just sinna pannakse failid, mis genereeritakse meie rakenduse koostamisprotsessi tulemusena.

Märgi 5 real määratud sihtkaust on lihtsalt praegune kataloog (kõik see, meenutame, töötab mingisugustes maagilistes asjades nimega OpenShift, mitte teie kohalikel arvutitel).

Jaotises strategy – märgi 6 real – on samuti sarnane esimesele koostamise konfiguratsioonile. Ainult seekord kavatseme kasutada nginx-image-runtime'i, mida oleme juba näinud ImageStreami jaotises.

Lõpuks, märgi 7 real on see triggereid sektsioon, mis aktiveerib selle koostamise iga kord, kui react-web-app-builder pilt muutub.

Muus osas sisaldab see mall üsna tavapärast juurutamise konfiguratsiooni ning ka asju, mis puudutavad teenuseid ja marsruute, kuid me ei süvene sellesse. Pange tähele, et juurutatav pilt on react-web-app-runtime.

Rakenduse juurutamine

Nii et vaatame mallile peale, kuidas seda rakenduse juurutamiseks kasutada.

Saame kasutada OpenShifti klienditööriista nimega oc, et juurutada meie malli:

$ 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

Eespool oleval ekraanipildil on esimene käsk tahtlikult inseneritehniline viis mallide leidmiseks.\/openshiftio\/application.yaml.

Teine käsk loob lihtsalt uue rakenduse selle malli alusel.

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

Ja tagasi ülevaate ekraanile näeme, et pod on käivitatud:

Klikkige lingil ja jõuame meie rakendusse, mis on vaikimisi React Appi leht:

Lisa 1

Angulari armastajatele on meil samuti rakenduse näidis.

Mall siin on sama, välja arvatud muutuja OUTPUT_DIR.

Lisaosa 2

Selles artiklis kasutasime veebiserverina NGINX-i, kuid selle saab üsna lihtsalt asendada Apache'iga, kui lihtsalt muudate mallifailis. NGINX-i pilt . Tundub, et Apache'i pilt.

Kokkuvõte

Selle seeria esimeses osas näitasime, kuidas kiiresti käivitada kaasaegseid veebirakendusi OpenShift'i platvormil. Täna vaatleme, mis teeb Web App'i pildi ja kuidas seda saab kombineerida puhta veebiserveri, näiteks NGINX-iga, kasutades seotud kogumisi (chained build), et korraldada tootmisoludele sobilikumat rakenduste kogumist. Seeria järgmises ja viimases artiklis näitame, kuidas käivitada OpenShift'is arendusserver oma rakendusele ja tagada lokaalsete ja kaugfailide sünkroniseerimine.

Selle seeria artiklite sisu

Osa 1: kuidas käitada kaasaegseid veebirakendusi vaid mõne sammuga;
Osa 2: kuidas kasutada uut S2I pilti koos olemasoleva HTTP-serveri pildiga, näiteks NGINX-iga, kasutades OpenShift'i seotud kogumisi, et korraldada tootmispaigaldust;
Osa 3: kuidas käivitada OpenShift'i platvormil arendusserver oma rakendusele ja sünkroniseerida see kohaliku failisüsteemiga.