🥇Modern alkalmazások OpenShift-en, 2. rész: kapcsolt építések chained builds

Üdvözlet mindenkinek! Itt a második posztunk a sorozatunkból, amelyben bemutatjuk, hogyan lehet modern webalkalmazásokat telepíteni a Red Hat OpenShift-re.

Az előző posztban kissé érintettük az új S2I (source-to-image) builder-kép lehetőségeit, amely a modern webalkalmazások OpenShift platformon való építését és telepítését szolgálja. Akkor a gyors alkalmazástelepítés témájával foglalkoztunk, míg ma azt nézzük meg, hogyan használhatjuk az S2I képet „tisztán” builder-ként, és hogyan kombinálhatjuk azt az OpenShift összekapcsolt buildjeivel.

Tiszta builder-kép

Ahogy az első részben említettük, a legtöbb modern webalkalmazásnak van úgynevezett build szakasza, ahol általában olyan műveleteket hajtanak végre, mint a kód transpillálása, több fájl egyesítése és minimalizálása. Az ezekből a műveletekből származó fájlok – amelyek statikus HTML, JavaScript és CSS – a kimeneti mappába kerülnek. Ennek a mappának a helye általában attól függ, hogy milyen build-eszközöket használnak, és a React esetében ez a . /build mappa lesz (erről a kérdésről részletesebben lentebb térünk vissza).

Source-to-Image (S2I)

Ebben a posztban egyáltalán nem foglalkozunk a „mi az S2I és hogyan kell használni” témával (erről többet lehet olvasni itt), de fontos világosan megérteni ezt a folyamatot két szakaszban, hogy tudjuk, mit csinál a Web App Builder kép.

Összeszerelési szakasz (assemble phase)

Az összeszerelési szakasz lényegében nagyon hasonlít arra, ami történik, amikor elindítja a docker buildet, és ennek eredményeként új Docker képet kap. Ennek megfelelően ez a szakasz a build indítása során lép fel az OpenShift platformon.

A Web App Builder kép esetében a függőségek telepítéséért és a build elindításáért felelős összeszerelő szkript. Alapértelmezés szerint a builder-kép az npm run build szerkezetet használja, de ezt felül lehet írni az NPM_BUILD környezeti változón keresztül.

Ahogy korábban említettük, az elkészült, már összeállított alkalmazás helyzete attól függ, hogy milyen eszközöket használunk. Például React esetén ez a mappa ./build, míg Angular alkalmazások esetén a project_name/dist mappa. És amint azt a korábbi bejegyzésben bemutattuk, a kimeneti könyvtár helyét, amely alapértelmezetten build-ként van megadva, felül lehet írni az OUTPUT_DIR környezeti változóval. Mivel a kimeneti mappa helye keretrendszerenként eltér, a generált kimenetet egyszerűen másolja a konténer szokásos mappájába, nevezetesen az /opt/apt-root/output mappába. Ez fontos a cikk további részének megértéséhez, de most gyorsan nézzük meg a következő szakaszt – a futási fázist (run phase).

Futási fázis (run phase)

Ez a fázis akkor következik be, amikor egy új képet hívunk meg a docker run segítségével, amelyet az összeállítási szakaszban hoztunk létre. Ez történik az OpenShift platformon történő telepítéskor is. Alapértelmezés szerint run script használja serve module a fent említett szabványos kimeneti könyvtárban található statikus tartalom kiszolgálására.

Ez a módszer jó a gyors alkalmazástelepítéshez, de általában nem ajánlott statikus tartalmat ilyen módon kiszolgálni. Mivel valójában csak statikus tartalmat szolgálunk ki, így a képen belüli Node.js-ra nincs szükség – elég egy webszerver.

Más szavakkal, az összeállításkor szükségünk van valamire, a végrehajtáskor pedig egy másikra. Egy ilyen helyzetben hasznosak a láncolt összesítések (chained builds).

Láncolt összesítések (chained builds)

Íme, mit írnak a láncolt összesítésekről az OpenShift dokumentációban:

„Két összesítést összekapcsolhatunk, ahol az egyik egy lefordított entitást generál, a másik pedig ezt az entitást egy külön képre helyezi, amelyet ennek az entitásnak a futtatásához használnak.”

Más szóval, felhasználhatjuk a Web App Builder képet a mi összesítésünk futtatásához, majd a webszerver képét, például az NGINX-et, hogy kiszolgáljuk a tartalmunkat.

Így a Web App Builder képet használhatjuk „tiszta” builder-ként, miközben egy kis méretű runtime képet is kapunk.

Most vizsgáljuk meg ezt egy konkrét példán keresztül.

A gyakorlathoz egyszerű React alkalmazást, amelyet a create-react-app parancssori eszközzel hoztak létre.

Mindent egybe foglalni segít a OpenShift sablon fájl..

Nézzük meg közelebbről ezt a fájlt, és kezdjük a paraméterek szakaszával.

paraméterek:
  - név: SOURCE_REPOSITORY_URL
    leírás: Az alkalmazás forrás URL-je
    megjelenítési név: Forrás URL
    kötelező: true
  - név: SOURCE_REPOSITORY_REF
    leírás: Az alkalmazás ágainak neve
    megjelenítési név: Forráság
    érték: master
    kötelező: true
  - név: SOURCE_REPOSITORY_DIR
    leírás: Az alkalmazás helye a forrásrepo-n belül
    megjelenítési név: Forráskönyvtár
    érték: .
    kötelező: true
  - név: OUTPUT_DIR
    leírás: Az Ön webalkalmazásainak generált statikus fájljainek elérési útja
    megjelenítési név: Kimeneti könyvtár
    érték: build
    kötelező: false

Itt minden elég világos, de érdemes figyelni az OUTPUT_DIR paraméterre. A példa React-alkalmazás esetén nem kell aggódni, mivel a React alapértelmezett kimeneti mappaként használja az értéket, de Angular vagy más esetén ezt a paramétert megfelelően meg kell változtatni.

Most nézzük meg az ImageStream-ek szakaszát.

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

Nézze meg a harmadik és negyedik képet. Mindkettő Docker-képként van definiálva, és egyértelműen látható, honnan származnak.

A harmadik kép a web-app-builder, és a nodeshift/ubi8-s2i-web-app 10.x címkéjével érkezik. Docker hub.

A negyedik a NGINX (1.12-es verzió) képe, a legújabb címkével. Docker hub.

Most nézzük meg az első két képet. Mindkettő üres az elején, és csak a build fázisban jön létre. Az első kép, a react-web-app-builder, a web-app-builder-runtime képet és a forráskódunkat egyesítő összeállítási fázis eredménye lesz. Ezért írtuk be a kép nevébe a „-builder” szót.

A második kép, a react-web-app-runtime, a nginx-image-runtime és a react-web-app-builder képéből származó fájlok egyesítésének eredménye lesz. Ez a kép is a telepítés során fog használatba kerülni, és csak a webszervert és az alkalmazásunk statikus HTML, JavaScript, CSS fájljait fogja tartalmazni.

Zavaros? Most nézzük meg a build konfigurációkat, és kicsit világosabbá válik.

A sablonunkban két build konfiguráció található. Íme az első, és ez elég 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

Ahogyan látjuk, az 1-es címkével ellátott sor azt jelzi, hogy ennek a buildnek az eredménye a korábban a ImageStream részben látott react-web-app-builder képbe lesz elhelyezve.

A 2-es címkével ellátott sor azt mondja, hogy honnan kell beszerezni a kódot. Ebben az esetben ez egy git tároló, amelynek helyét, ref-jét és kontextusának mappáját már korábban láttuk.

A 3-as címkével ellátott sor azt jelzi, amit már láttunk a paraméterek részben. Ez hozzáad egy OUTPUT_DIR környezeti változót, amely a példánkban build értéket kap.
A 4-es címkével ellátott sor azt mondja, hogy a web-app-builder-runtime képet kell használni, amit már láttunk az ImageStream részben.

Az 5-ös címkével ellátott sor azt jelzi, hogy szeretnénk használni az inkrementális buildet, ha az S2I-kép támogatja azt, és a Web App Builder tényleg támogatja. Az első indításkor, az összesítési lépés befejezése után a kép menteni fogja a node_modules mappát egy archív fájlba. A következő indítások során a kép egyszerűen kicsomagolja ezt a mappát, hogy csökkentse a build idejét.

Végül a 6-os címkével ellátott sor csupán néhány kiváltó esemény, amely automatikusan elindítja a buildet, emberi beavatkozás nélkül, amikor valami megváltozik.

Összességében ez egy meglehetősen standard build konfiguráció.

Most nézzük meg a második build konfigurációt. Ez nagyon hasonlít az elsőhöz, de van egy fontos eltérés.

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

Tehát a második konfiguráció építési folyamata – react-web-app-runtime, és ez teljesen standard módon kezdődik.

Az 1. jelölésű sorban nincs semmi új – csak annyit mond, hogy az építési eredményt a react-web-app-runtime képbe helyezzük.

A 2. jelölésű sor, akárcsak az előző konfigurációban, arra utal, honnan vesszük az forráskódot. De figyeljen arra, hogy itt azt mondjuk, hogy az a képből származik. Mégpedig abból a képből, amelyet most készítettünk – a react-web-app-builder-ből (amelyet a 3. jelölésű sorban adtunk meg). Azok a fájlok, amelyeket használni szeretnénk, a képen belül találhatók, és a helyüket a 4. jelölésű sorban határozzuk meg, ebben az esetben ez /opt/app-root/output/. Ha emlékezik, ide kerülnek a fájlok, amelyeket a webalkalmazásunk építési eredményeként generáltunk.

Az 5. jelölésű sorban megadott célmappa csupán a jelenlegi könyvtár (ezt mindenképpen emlékeztetjük, hogy valahol a varázslatos dolog alatt fut, amit OpenShift-nek hívnak, nem pedig a helyi számítógépén).

A strategy szekció – a 6. jelölésű sor – is hasonlít az első építési konfigurációra. Csak ezúttal az nginx-image-runtime-ot használjuk, amelyet már láttunk az ImageStream szakaszban.

Végül a 7. jelölésű sor – ez a triggereket tartalmazó szakasz, amely aktiválja ezt az építést, minden alkalommal, amikor a react-web-app-builder kép megváltozik.

Egyébként ez a sablon teljesen standard telepítési konfigurációt tartalmaz, valamint dolgokat, amelyek a szolgáltatásokkal és útvonalakkal kapcsolatosak, de ebbe nem mélyedünk bele. Figyeljen arra, hogy az a kép, amelyet telepíteni fogunk – az a react-web-app-runtime kép.

Alkalmazás telepítése

Tehát, miután megtekintettük a sablont, nézzük meg, hogyan használjuk azt az alkalmazás telepítésére.

Használhatjuk az OpenShift kliens eszközét, amelyet oc-nak hívnak, hogy telepítsük a sablonunkat:

$ 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

A fenti képernyőn látható első parancs kissé mérnöki módszer a sablon keresésére: ./openshiftio/application.yaml.

A második parancs egyszerűen új alkalmazást hoz létre a sablon alapján.

Miután ezek a parancsok lefutottak, látni fogjuk, hogy két építésünk keletkezett:

És visszatérve az Overview képernyőre, látni fogjuk az elindult podot:

Egy kattintás a linkre – és átkerülünk a webalkalmazásunkhoz, amely az alapértelmezett React App alkalmazás oldalát jelenti:

Kiegészítő 1

Az Angular kedvelői számára is van alkalmazás példa.

A sablon itt hasonló, kivéve az OUTPUT_DIR változót.

Kiegészítő 2

Ebben a cikkben NGINX-t használtunk webkiszolgálóként, de könnyen helyettesíthető Apache-val, csak módosítani kell a sablon fájlban. NGINX kép Gyorsan emlékezzünk vissza, hogyan működik a moduláris aritmetika. Az óra már egy ismert koncepció. Az órák használata Apache kép.

Zárás

A sorozat első részében bemutattuk, hogyan lehet gyorsan telepíteni modern webalkalmazásokat az OpenShift platformon. Ma áttekintettük, hogy mit csinál a Web App kép, és hogyan kombinálható egy tiszta NGINX típusú webkiszolgálóval kapcsolt építésekkel (chained build), hogy a gyártási körülményekhez jobban megfelelő alkalmazásépítést biztosítsunk. A sorozat következő, záró cikkében bemutatjuk, hogyan indíthatunk fejlesztői szervert az OpenShift-en saját alkalmazásunkhoz és hogyan szinkronizálhatjuk a helyi és távoli fájlokat.

A cikk sorozat tartalma

1. rész: hogyan telepítsünk modern webalkalmazásokat mindössze néhány lépésben;
2. rész: hogyan alkalmazzuk az új S2I képet a meglévő HTTP-kiszolgáló képével, például NGINX, amelyek kapcsolatban állnak az OpenShift kapcsolt építéseivel a gyártási telepítés megszervezéséhez;
3. rész: hogyan indítsunk fejlesztői szervert az OpenShift platformon saját alkalmazásunkhoz és hogyan szinkronizáljuk azt a helyi fájlrendszerrel.