Nykyaikaiset sovellukset OpenShiftissä, osa 2: ketjutetut koontiversiot

Hei kaikki! Tämä on sarjamme toinen viesti, jossa näytämme, kuinka modernit verkkosovellukset otetaan käyttöön Red Hat OpenShiftissä.

Edellisessä postauksessa käsittelimme hieman uuden S2I (source-to-image) -muodostinkuvan ominaisuuksia, joka on suunniteltu nykyaikaisten verkkosovellusten rakentamiseen ja käyttöönottoon OpenShift-alustalla. Sitten kiinnostuimme sovelluksen nopeasta käyttöönotosta, ja tänään tarkastelemme, kuinka S2I-kuvaa voidaan käyttää "puhtaana" rakennuskuvana ja yhdistää se siihen liittyviin OpenShift-kokoonpanoihin.

Puhdas rakentajan kuva

Kuten mainittiin osassa XNUMX, useimmissa nykyaikaisissa verkkosovelluksissa on niin kutsuttu rakennusvaihe, joka tyypillisesti suorittaa toimintoja, kuten koodin transpilaatiota, useiden tiedostojen yhdistämistä ja pienentämistä. Näiden toimintojen tuloksena saadut tiedostot - ja tämä on staattinen HTML, JavaScript ja CSS - tallennetaan tuloskansioon. Tämän kansion sijainti riippuu yleensä siitä, mitä koontityökaluja käytetään, ja Reactille tämä on ./build-kansio (palaamme tähän tarkemmin alla).

Lähteestä kuvaksi (S2I)

Tässä viestissä emme kosketa aihetta "mikä on S2I ja miten sitä käytetään" (voit lukea lisää tästä täällä), mutta on tärkeää tehdä selväksi tämän prosessin kaksi vaihetta, jotta ymmärrät, mitä Web App Builder -kuva tekee.

Kokoamisvaihe

Kokoonpanovaihe on luonteeltaan hyvin samanlainen kuin mitä tapahtuu, kun suoritat Docker buildin ja päädyt uuteen Docker-kuvaan. Vastaavasti tämä vaihe tapahtuu aloitettaessa koontiversio OpenShift-alustalla.

Web App Builder -otoksen tapauksessa se on vastuussa sovelluksesi riippuvuuksien asentamisesta ja koontiversion suorittamisesta. koota käsikirjoitus. Oletusarvoisesti rakennustyökalun näköistiedosto käyttää npm run build -rakennetta, mutta tämä voidaan ohittaa ympäristömuuttujan NPM_BUILD avulla.

Kuten aiemmin totesimme, valmiin, jo rakennetun sovelluksen sijainti riippuu käyttämistäsi työkaluista. Esimerkiksi Reactin tapauksessa tämä on ./build-kansio, ja Angular-sovelluksissa se on projektin_nimi/dist-kansio. Ja kuten edellisessä viestissä jo näytettiin, lähtöhakemiston sijainti, joka on asetettu oletuksena rakentamaan, voidaan ohittaa ympäristömuuttujan OUTPUT_DIR kautta. No, koska tuloskansion sijainti vaihtelee kehyksestä riippuen, kopioit luotu tulosteen kuvan vakiokansioon, nimittäin /opt/apt-root/output. Tämä on tärkeää tämän artikkelin loppuosan ymmärtämiseksi, mutta katsotaan nyt nopeasti seuraavaa vaihetta - suoritusvaihetta.

ajovaihe

Tämä vaihe tapahtuu, kun kokoonpanovaiheen aikana luodulle uudelle kuvalle tehdään kutsu Docker-ajolle. Sama tapahtuu, kun otetaan käyttöön OpenShift-alustalla. Oletus suorita komentosarja käyttää palvele moduulia palvelemaan yllä olevassa vakiotulostushakemistossa sijaitsevaa staattista sisältöä.

Tämä menetelmä sopii sovellusten nopeaan käyttöönottoon, mutta staattista sisältöä ei yleensä suositella tällä tavalla. No, koska todellisuudessa tarjoamme vain staattista sisältöä, emme tarvitse Node.js:ää asennettuna kuvamme sisään - verkkopalvelin riittää.

Toisin sanoen koottaessa tarvitsemme yhtä asiaa, kun suoritamme toisen. Tässä tilanteessa ketjutetut rakenteet ovat hyödyllisiä.

Ketjutetut rakenteet

Tästä he kirjoittavat ketjutettuja rakennuksia OpenShift-dokumentaatiossa:

"Kaksi kokoonpanoa voidaan linkittää yhteen, joista toinen luo käännetyn kokonaisuuden ja toinen isännöi kokonaisuutta erillisessä kuvassa, jota käytetään kyseisen kokonaisuuden suorittamiseen."

Toisin sanoen voimme käyttää Web App Builder -kuvaa koontiversiomme suorittamiseen ja sitten käyttää verkkopalvelimen kuvaa, samaa NGINX:ää, sisältömme palvelemiseen.

Näin ollen voimme käyttää Web App Builder -kuvaa "puhtaan" rakennustyökaluna ja samalla meillä on pieni ajonaikainen kuva.

Katsotaanpa tätä nyt erityisellä esimerkillä.

Harjoitteluun käytämme yksinkertainen React-sovellus, luotu Create-react-app-komentorivityökalulla.

Se auttaa meitä yhdistämään kaiken OpenShift-mallitiedosto.

Katsotaanpa tätä tiedostoa yksityiskohtaisemmin ja aloitetaan parametrit-osiosta.

parameters:
  - name: SOURCE_REPOSITORY_URL
    description: The source URL for the application
    displayName: Source URL
    required: true
  - name: SOURCE_REPOSITORY_REF
    description: The branch name for the application
    displayName: Source Branch
    value: master
    required: true
  - name: SOURCE_REPOSITORY_DIR
    description: The location within the source repo of the application
    displayName: Source Directory
    value: .
    required: true
  - name: OUTPUT_DIR
    description: The location of the compiled static files from your web apps builder
    displayName: Output Directory
    value: build
    required: false

Kaikki täällä on melko selvää, mutta kannattaa kiinnittää huomiota parametriin OUTPUT_DIR. Esimerkkimme React-sovelluksessa ei ole mitään huolestuttavaa, koska React käyttää oletusarvoa tuloskansiona, mutta Angularin tai jonkin muun tapauksessa tätä parametria on muutettava tarpeen mukaan.

Katsotaanpa nyt ImageStreams-osiota.

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

Katso kolmatta ja neljättä kuvaa. Ne molemmat määritellään Docker-kuviksi, ja näet selvästi, mistä ne tulevat.

Kolmas kuva on web-app-builder ja se on peräisin nodeshift/ubi8-s2i-web-app-tunnisteesta 10.x. Docker-keskitin.

Neljäs on NGINX-kuva (versio 1.12), jossa on viimeisin tagi Docker-keskitin.

Katsotaan nyt kahta ensimmäistä kuvaa. Ne ovat molemmat tyhjiä alussa ja luodaan vasta rakennusvaiheen aikana. Ensimmäinen kuva, react-web-app-builder, on tulos kokoonpanovaiheesta, joka yhdistää web-app-builder-runtime-kuvan ja lähdekoodimme. Siksi lisäsimme tämän kuvan nimeen "-builder".

Toinen kuva - react-web-app-runtime - on tulos nginx-image-runtime-tiedoston ja joidenkin react-web-app-builder-kuvan tiedostojen yhdistämisestä. Tätä kuvaa käytetään myös käyttöönoton aikana, ja se sisältää vain sovelluksemme verkkopalvelimen ja staattisen HTML:n, JavaScriptin ja CSS:n.

Hämmentynyt? Katsotaanpa nyt koontikokoonpanoja ja se tulee hieman selkeämmäksi.

Mallissamme on kaksi koontikokoonpanoa. Tässä on ensimmäinen, ja se on melko vakio:

  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

Kuten näet, rivi tunnisteella 1 sanoo, että tämän koontiversion tulos sijoitetaan samaan react-web-app-builder-kuvaan, jonka näimme hieman aiemmin ImageStreams-osiossa.

Rivi 2 kertoo, mistä koodi saa. Meidän tapauksessamme tämä on git-arkisto, ja sijainti, viite ja kontekstikansio määräytyvät parametrien mukaan, jotka olemme jo nähneet yllä.

Rivi, jonka nimi on 3, on se, mitä näimme jo parametriosiossa. Se lisää OUTPUT_DIR-ympäristömuuttujan, joka esimerkissämme on build.
Rivi, jonka nimi on 4, kehottaa käyttämään web-app-builder-runtime-kuvaa, jonka näimme jo ImageStream-osiossa.

Rivi 5 sanoo, että haluamme käyttää inkrementaalista koontiversiota, jos S2I-kuva tukee sitä ja Web App Builder -kuva tukee sitä. Ensimmäisellä käynnistyksellä, kun kokoonpanovaihe on suoritettu, kuva tallentaa node_modules-kansion arkistotiedostoon. Sitten seuraavissa ajoissa kuva yksinkertaisesti purkaa tämän kansion koontiajan lyhentämiseksi.

Ja lopuksi, rivi, jonka nimi on 6, on vain muutamia laukaisimia, jotka saavat koontiversion toimimaan automaattisesti ilman manuaalista puuttumista, kun jokin muuttuu.

Kaiken kaikkiaan tämä on melko vakiorakennekokoonpano.

Katsotaanpa nyt toista koontikokoonpanoa. Se on hyvin samanlainen kuin ensimmäinen, mutta siinä on yksi tärkeä ero.

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

Joten toinen koontikokoonpano on react-web-app-runtime, ja se alkaa melko vakiona.

Rivi, jonka nimi on 1, ei ole mikään uusi - se kertoo yksinkertaisesti, että koontitulos lisätään react-web-app-runtime-kuvaan.

Rivi 2, kuten edellisessä kokoonpanossa, osoittaa, mistä lähdekoodi saa. Mutta huomaa, että tässä sanomme, että se on otettu kuvasta. Lisäksi juuri luomastamme kuvasta - react-web-app-builderista (merkitty rivillä 3). Tiedostot, joita haluamme käyttää, ovat kuvan sisällä ja niiden sijainti siellä on asetettu riville 4, meidän tapauksessamme se on /opt/app-root/output/. Jos muistat, tähän tallennetaan sovelluksemme rakentamisen tulosten perusteella luodut tiedostot.

Kohdekansio, joka on määritetty termissä tunnisteella 5, on yksinkertaisesti nykyinen hakemisto (tämä on kaikki, muista, että se toimii jossain taianomaisessa OpenShift-nimisessä esineessä, ei paikallisessa tietokoneessa).

Strategiaosio – rivillä 6 – on myös samanlainen kuin ensimmäinen koontikokoonpano. Vain tällä kertaa aiomme käyttää nginx-image-runtimea, jonka näimme jo ImageStream-osiossa.

Lopuksi rivi 7 on osa triggereistä, jotka aktivoivat tämän koontiversion aina, kun react-web-app-builder-kuva muuttuu.

Muuten tämä malli sisältää melko tavallisia käyttöönottokokoonpanoja sekä asioita, jotka liittyvät palveluihin ja reitteihin, mutta emme mene siihen liian yksityiskohtiin. Huomaa, että käyttöön otettava kuva on react-web-app-runtime-kuva.

Sovelluksen käyttöönotto

Joten nyt kun olemme tarkastelleet mallia, katsotaanpa, kuinka sitä käytetään sovelluksen käyttöönottoon.

Voimme käyttää OpenShift-asiakastyökalua nimeltä oc ottaaksemme käyttöön mallimme:

$ 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

Ensimmäinen komento yllä olevassa kuvakaappauksessa on tarkoituksella suunniteltu tapa löytää malli./openshiftio/application.yaml.

Toinen komento yksinkertaisesti luo uuden sovelluksen tämän mallin perusteella.

Kun nämä komennot toimivat, näemme, että meillä on kaksi kokoonpanoa:

Ja palaamalla Yleiskatsaus-näyttöön, näemme käynnistetyn pod:

Napsauta linkkiä ja siirrymme sovellukseemme, joka on React App -oletussivu:

Täydennys 1

Meillä on myös Angular-ystäville esimerkkisovellus.

Malli tässä on sama, paitsi OUTPUT_DIR-muuttuja.

Täydennys 2

Tässä artikkelissa käytimme NGINX:ää verkkopalvelimena, mutta sen korvaaminen Apachella on melko helppoa, vaihda vain malli tiedostossa NGINX kuva päälle Apache-kuva.

Johtopäätös

Tämän sarjan ensimmäisessä osassa näytimme, kuinka modernit verkkosovellukset otetaan nopeasti käyttöön OpenShift-alustalla. Tänään tarkastelimme, mitä Web App -kuva tekee ja kuinka se voidaan yhdistää puhtaaseen verkkopalvelimeen, kuten NGINX, käyttämällä ketjutettuja koontiversioita tuotantovalmimman sovelluksen koontiversion luomiseksi. Tämän sarjan seuraavassa ja viimeisessä artikkelissa näytämme, kuinka voit käyttää kehityspalvelinta sovelluksellesi OpenShiftissä ja varmistaa paikallisten ja etätiedostojen synkronoinnin.

Tämän artikkelisarjan sisältö

• Osa 1: kuinka ottaa modernit verkkosovellukset käyttöön vain muutamassa vaiheessa;
• Osa 2: Uuden S2I-kuvan käyttäminen olemassa olevan HTTP-palvelinkuvan, kuten NGINX:n, kanssa käyttämällä siihen liittyviä OpenShift-kokoonpanoja tuotantokäyttöön;
• Osa 3: kuinka käyttää kehityspalvelinta sovelluksellesi OpenShift-alustalla ja synkronoida se paikallisen tiedostojärjestelmän kanssa.

Lisäresurssit

• Ilmainen e-kirja Käyttöönotto OpenShiftiin.
• Tietoa OpenShift ja Kubernetes.

Lähde: will.com