🥇Modern alkalmazások az OpenShift-en, 3. rész: OpenShift mint fejlesztői környezet és OpenShift Pipelines

Üdvözöljük a blogban! Itt a harmadik bejegyzés a sorozatunkból, amelyben bemutatjuk, hogyan lehet modern webalkalmazásokat telepíteni a Red Hat OpenShift-en.

Az előző két bejegyzésben elmondtuk, hogyan lehet modern webalkalmazásokat telepíteni mindössze néhány lépésben, és hogyan használhatjuk az új S2I képet egy előre elkészített HTTP-szerver képpel, például az NGINX-szel, a kapcsolt build-ek segítségével a termelési telepítés szervezéséhez.

Ma megmutatjuk, hogyan indíthatunk fejlesztői szervert az OpenShift platformon az alkalmazásunk számára, és hogyan szinkronizálhatjuk azt a helyi fájlrendszerrel, valamint beszélni fogunk arról, mi az OpenShift Pipelines és hogyan alkalmazható a kapcsolt build-ek alternatívájaként.

OpenShift mint fejlesztői környezet

Fejlesztési munkafolyamat

Ahogyan azt korábban említettük a első bejegyzésben, a modern webalkalmazások tipikus fejlesztési folyamata egy „fejlesztői szerver”, amely figyeli a helyi fájlokban végrehajtott változásokat. Amikor ezek bekövetkeznek, elindul az alkalmazás build folyamata, majd az a böngészőben frissül.

A legtöbb modern keretrendszerben az ilyen „fejlesztői szerver” be van építve a megfelelő parancssori eszközökbe.

Helyi példa

Először nézzük meg, hogyan működik ez a helyi alkalmazások indításakor. Példaként vegyük az alkalmazást React az előző cikkekből, bár gyakorlatilag ugyanazokat a munkafolyamat-koncepciókat alkalmazzák a többi modern keretrendszerben is.
Tehát, hogy elindítsuk a „fejlesztői szervert” a React példánkban, adjuk ki a következő parancsot:

$ npm run start

Így a terminál ablakban körülbelül a következőt fogjuk látni:

És az alkalmazásunk megnyílik az alapértelmezett böngészőben:

Most, ha módosítunk egy fájlt, az alkalmazásnak frissülnie kell a böngészőben.

Rendben, a helyi fejlesztéssel minden világos, de hogyan érhetjük el ugyanezt OpenShift-en?

Fejlesztői szerver OpenShift-en

Ha emlékeztek, a korábbi bejegyzésben-ben foglalkoztunk az S2I kép indítási fázisával, és láttuk, hogy alapértelmezés szerint a webalkalmazásunk kiszolgálását a serve modul végzi.

Azonban érdemes alaposabban megnézni run script abból a példából, hogy van egy $NPM_RUN környezeti változó, amely lehetővé teszi a saját parancsunk végrehajtását.

Például felhasználhatjuk a nodeshift modult az alkalmazásunk telepítésére:

$ npx nodeshift --deploy.env NPM_RUN="yarn start" --dockerImage=nodeshift/ubi8-s2i-web-app

Megjegyzés: a fenti példa rövidített formában van, hogy bemutassa az általános ötletet.

Itt hozzáadtuk a telepítésünkhöz az NPM_RUN környezeti változót, amely azt mondja a végrehajtási lépésnek, hogy futtassa a yarn start parancsot, amely elindítja a React fejlesztői szervert az OpenShift pod-on belül.

Ha megnézzük a futó pod naplóját, körülbelül a következőképpen fog kinézni:

Természetesen ez mind semmit sem jelent, amíg nem tudjuk szinkronizálni a helyi kódot a távoli szerveren, amelyet szintén változások szerint kell ellenőrizni.

A távoli és helyi kód szinkronizálása

Szerencsére a nodeshift könnyen segít a szinkronizálásban, a változások nyomon követésére pedig használhatjuk a watch parancsot.

Tehát miután végrehajtottuk a parancsot a fejlesztői szerver telepítésére az alkalmazásunkhoz, nyugodtan használhatjuk a következő parancsot:

$ npx nodeshift watch

Ennek eredményeként csatlakozunk a korábban létrehozott futó podhoz, aktiválva a helyi fájljaink szinkronizálását a távoli klaszterrel, a helyi rendszerünk fájljait pedig a változásokra fogják figyelni.

Ezért ha most frissítjük a src/App.js fájlt, a rendszer reagál a változásokra, átviszi azokat a távoli klaszterre és elindítja a fejlesztői szervert, amely ezután frissíti az alkalmazásunkat a böngészőben.

A teljesség kedvéért mutassuk meg, hogyan néznek ki ezek a parancsok teljes egészében:

$ npx nodeshift --strictSSL=false --dockerImage=nodeshift/ubi8-s2i-web-app --build.env YARN_ENABLED=true --expose --deploy.env NPM_RUN="yarn start" --deploy.port 3000

$ npx nodeshift watch --strictSSL=false

A watch parancs egy absztrakció az oc rsync parancs felett, részletesebben arról, hogyan működik, lehet utánaolvasni. itt.

Ez egy példa volt a React-ra, de pontosan ugyanazt a módszert más keretrendszerekkel is lehet használni, csak a megfelelő módon kell megadni az NPM_RUN környezeti változót.

OpenShift Pipelines

Később a OpenShift Pipelines nevű eszközről fogunk beszélni, és arról, hogyan használható alternatívaként a láncolt build-ekhez.

Mi az OpenShift Pipelines

Az OpenShift Pipelines egy felhő-centrikus CI/CD rendszer, amely a folyamatos integráció és kiszállítás megszervezésére szolgál, és a Tekton használatára épül. A Tekton egy rugalmas, Kubernetes-alapú, nyílt forráskódú CI/CD keretrendszer, amely lehetővé teszi a különböző platformokon (Kubernetes, serverless, virtuális gépek stb.) történő telepítés automatizálását a háttérszint absztrahálásával.

E cikk megértéséhez bizonyos ismeretek szükségesek a Pipelines-ról, ezért javasoljuk, hogy először ismerkedjen meg a hivatalos útmutatóval.

A fejlesztési környezet beállítása

A cikk példáinak kipróbálásához először is készítse elő a fejlesztési környezetet:

Telepítse és konfigurálja az OpenShift 4 klasztert. Példáinkhoz a CodeReady Containers (CRD) kerül felhasználásra, amelynek telepítési utasításait itt találja: itt.
Miután a klaszter készen áll, telepítenie kell a Pipeline Operator-t. Ne aggódjon, ez könnyű, a telepítési utasítások itt.
Letöltés Tekton CLI (tkn) itt.
Futtassa a create-react-app parancssori eszközt, hogy létrehozzon egy alkalmazást, amelyet később telepítünk (ez egy egyszerű alkalmazás) React).
(Opcionális) Klónozza a tárolót, hogy helyben futtathassa az alkalmazás példáját az npm install parancs használatával, majd az npm start-tal.

Az alkalmazás tárolójában lesz egy k8s mappa is, amely a Kubernetes/OpenShift YAML fájlokat tartalmazza, amelyeket az alkalmazás telepítésére használunk. Itt lesznek Tasks, ClusterTasks, Resources és Pipelines, amelyeket a következő lépésekben hozunk létre. tárhelyen.

Kezdjük

Először is létre kell hoznunk egy új projektet az OpenShift klaszterben. Ezt a projektet webapp-pipeline-nak nevezzük, és a következő parancsot használjuk:

$ oc new-project webapp-pipeline

Ezt követően a projekt neve meg fog jelenni a kódban, tehát ha más néven szeretné elnevezni, ne felejtse el ennek megfelelően módosítani a példák kódját. Ettől a ponttól kezdve nem fentről lefelé, hanem lentről felfelé haladunk: először létrehozzuk a konvektor alkotóelemeit, és csak ezután magát a konvektort.

Tehát, először is...

Feladatok Tasks

Készítünk egy pár feladatot (tasks), amelyek segítenek az alkalmazásunk ütemezésében a pipeline keretein belül. Az első feladat – apply_manifests_task – felelős a YAML fájlok Kubernetes-erőforrások (service, deployment és route) alkalmazásáért, amelyek az alkalmazásunk k8s mappájában találhatók. A második feladat – update_deployment_task – a már telepített képek frissítéséért felelős azzal, amelyet a pipeline-unk készít.

Ne aggódj, ha eddig nem teljesen világos. Valójában ezek a feladatok – valami hasonlóan, mint a segédeszközök –, és részletesebben is átbeszéljük őket egy kicsit később. Most csak hozzuk létre őket:

$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/tasks/update_deployment_task.yaml
$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/tasks/apply_manifests_task.yaml

Ezután a tkn CLI parancs segítségével ellenőrizzük, hogy a feladatok létrejöttek:

$ tkn task ls

NAME                AGE
apply-manifests     1 minute ago
update-deployment   1 minute ago

Megjegyzés: ezek a feladatok a jelenlegi projekted lokális feladatai.

Cluster tasks

A cluster tasks lényegében ugyanaz, mint a sima feladatok. Tehát ez egy újra felhasználható lépések gyűjteménye, amelyeket valamilyen módon kombinálnak, amikor egy adott feladatot futtatnak. Az eltérés abban rejlik, hogy a cluster task bárhol elérhető a klaszter keretein belül. A klaszter feladatok listájának megtekintéséhez, amelyeket automatikusan létrehoznak a Pipeline Operator hozzáadásakor, ismét a tkn CLI parancsot használjuk:

$ tkn clustertask ls

NAME                       AGE
buildah                    1 day ago
buildah-v0-10-0            1 day ago
jib-maven                  1 day ago
kn                         1 day ago
maven                      1 day ago
openshift-client           1 day ago
openshift-client-v0-10-0   1 day ago
s2i                        1 day ago
s2i-go                     1 day ago
s2i-go-v0-10-0             1 day ago
s2i-java-11                1 day ago
s2i-java-11-v0-10-0        1 day ago
s2i-java-8                 1 day ago
s2i-java-8-v0-10-0         1 day ago
s2i-nodejs                 1 day ago
s2i-nodejs-v0-10-0         1 day ago
s2i-perl                   1 day ago
s2i-perl-v0-10-0           1 day ago
s2i-php                    1 day ago
s2i-php-v0-10-0            1 day ago
s2i-python-3               1 day ago
s2i-python-3-v0-10-0       1 day ago
s2i-ruby                   1 day ago
s2i-ruby-v0-10-0           1 day ago
s2i-v0-10-0                1 day ago

Most létrehozunk két klaszterfeladatot. Az első S2I képet fog generálni és elküldi azt az OpenShift belső regisztrátorába; a második a NGINX alapú képünket fogja építeni, az általunk már összeszerelt alkalmazás tartalmát használva.

Kép létrehozása és elküldése

Az első feladat létrehozásakor megismételjük, amit már a kapcsolt build-ekről szóló előző cikkben csináltunk. Emlékeztessem, hogy az S2I (ubi8-s2i-web-app) képet használtuk az alkalmazásunk „összeállítására”, aminek eredményeként egy kép keletkezett, amely a nyílt OpenShift registry-ben tárolódott. Most ezt az S2I-webalkalmazás képet használjuk, hogy DockerFile-t készítsünk az alkalmazásunkhoz, majd a Buildah-t fogjuk használni a tényleges build lebonyolításához és a kapott kép feltöltéséhez az OpenShift belső registry-jébe, mivel ez az, amit az OpenShift tesz, amikor a NodeShift segítségével telepíti az alkalmazásokat.

Megkérdezi, honnan tudtuk mindezt? Az официальной версии official Node.js, egyszerűen átmásoltuk és nekünk megfelelően átírtuk.

Tehát most létrehozzuk az s2i-web-app klaszterfeladatot:

$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/clustertasks/s2i-web-app-task.yaml

Nem fogjuk részletesen elemezni, csak a OUTPUT_DIR paraméterre fogunk fókuszálni:

params:
      - name: OUTPUT_DIR
        description: A build kimeneti könyvtárának helye
        default: build

Alapértelmezés szerint ez a paraméter a build értékét takarja, ahová a React a összeállított tartalmat elhelyezi. Más keretrendszerekben más útvonalakat használnak, például az Ember esetén ez a dist. Az első klaszterfeladatunk kimenete egy képet fog tartalmazni, amely magában foglalja a létrehozott HTML, JavaScript és CSS fájlokat.

Képeket állítunk össze NGINX alapjaira

A második klaszterfeladatunknak NGINX alapú képet kell létrehoznia, az általunk már létrehozott alkalmazás tartalmát felhasználva. Valójában ez a része az előző szakasznak, ahol a kapcsolt build-eket vizsgáltuk.

Ehhez – ahogyan az előbb is tettük – létrehozunk egy webapp-build-runtime klaszterfeladatot:

$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/clustertasks/webapp-build-runtime-task.yaml

Ha megnézi a klaszterfeladatok kódját, láthatja, hogy ott nincs konkretizálva a Git tároló, amellyel dolgozunk, vagy a képek nevei, amelyeket létrehozunk. Csak azt adjuk meg, hogy pontosan mit adunk át a Git-nek, vagy egy képet, ahová ki kell adni a végső képet. Ezért ezeket a klaszterfeladatokat más alkalmazásokkal is újra felhasználhatjuk.

És itt elegánsan átvezetünk a következő pontra…

Források

Tehát, mivel, ahogy már említettük, a klaszteres feladatoknak a lehető legáltalánosabbnak kell lenniük, létre kell hoznunk azokat az erőforrásokat, amelyeket bemenetként (Git-tárhely) és kimenetként (végső képek) használunk. Az első erőforrás, amire szükségünk van – ez a Git, ahol az alkalmazásunk található, valami ilyesmi:

# This resource is the location of the git repo with the web application source
apiVersion: tekton.dev/v1alpha1
kind: PipelineResource
metadata:
  name: web-application-repo
spec:
  type: git
  params:
    - name: url
      value: https://github.com/nodeshift-starters/react-pipeline-example
    - name: revision
      value: master

Itt a PipelineResource típusa git. A params szekcióban található url kulcs megadja a konkrét tárolót, és beállítja a master ágat (ez opcionális, de a teljesség kedvéért megadjuk).

Most létre kell hoznunk egy erőforrást a kép számára, ahová a s2i-web-app feladat eredményei kerülnek, ez így működik:

# This resource is the result of running "npm run build",  the resulting built files will be located in /opt/app-root/output
apiVersion: tekton.dev/v1alpha1
kind: PipelineResource
metadata:
  name: built-web-application-image
spec:
  type: image
  params:
    - name: url
      value: image-registry.openshift-image-registry.svc:5000/webapp-pipeline/built-web-application:latest

Itt a PipelineResource típusa image, és a url paraméter értéke az OpenShift Image Registry belső helyére mutat, konkrétan arra, amely a webapp-pipeline névtérben található. Ne felejtsd el megváltoztatni ezt a paramétert, ha más névteret használsz.

És végül, az utolsó erőforrás, amire szükségünk lesz, szintén image típúsú lesz, és ez a végső NGINX kép, amely később a telepítés során lesz használva:

# This resource is the image that will be just the static html, css, js files being run with nginx
apiVersion: tekton.dev/v1alpha1
kind: PipelineResource
metadata:
  name: runtime-web-application-image
spec:
  type: image
  params:
    - name: url
      value: image-registry.openshift-image-registry.svc:5000/webapp-pipeline/runtime-web-application:latest

Ismét figyeljünk arra, hogy ez az erőforrás a képet az OpenShift belső nyilvántartásába menti a webapp-pipeline névtérben.

Ahhoz, hogy az összes ilyen erőforrást egyszerre létrehozzuk, használjuk a create parancsot:

$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/resources/resource.yaml

Az erőforrások létrejöttének ellenőrzéséhez használhatjuk a következőt:

$ tkn resource ls

Pipeline

Most, hogy megvannak a szükséges összetevők, összerakjuk a pipelinet, létrehozva azt a következő paranccsal:

$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/pipelines/build-and-deploy-react.yaml

De mielőtt futtatnánk ezt a parancsot, nézzük meg ezeket az összetevőket. Az első – ez a név:

apiVersion: tekton.dev/v1alpha1
kind: Pipeline
metadata:
  name: build-and-deploy-react

Ezután a spec szekcióban látjuk az előzőleg létrehozott erőforrások meghatározását:

spec:
  resources:
    - name: web-application-repo
      type: git
    - name: built-web-application-image
      type: image
    - name: runtime-web-application-image
      type: image

Ezután létrehozzuk azokat a feladatokat, amelyeket a pipelinnak el kell végeznie. Először is, végre kell hajtania a már létrehozott s2i-web-app feladatot:

tasks:
    - name: build-web-application
      taskRef:
        name: s2i-web-app
        kind: ClusterTask

Ez a feladat az bemeneti (gir-erőforrás) és kimeneti (built-web-application-image erőforrás) paramétereket veszi át. Szintén átadunk neki egy speciális paramétert, hogy ne ellenőrizze a TLS-t, mivel önaláírt tanúsítványokat használunk:

erőforrások:
        bemenetek:
          - név: forrás
            erőforrás: web-application-repo
        kimenetek:
          - név: kép
            erőforrás: built-web-application-image
      paraméterek:
        - név: TLSVERIFY
          érték: "false"

A következő feladat szinte ugyanaz, csak itt a már létrehozott webapp-build-runtime klaszter feladatot hívjuk meg:

név: build-runtime-image
    feladatRef:
      név: webapp-build-runtime
      típus: ClusterTask

Ahogy az előző feladatnál, itt is átadjuk az erőforrást, de most a built-web-application-image-t (előző feladatunk kimenete). És mint kimenet, ismét egy képet adunk meg. Mivel ennek a feladatnak a korábbi után kell végrehajtódnia, hozzáadjuk a runAfter mezőt:

erőforrások:
        bemenetek:
          - név: kép
            erőforrás: built-web-application-image
        kimenetek:
          - név: kép
            erőforrás: runtime-web-application-image
        paraméterek:
        - név: TLSVERIFY
          érték: "false"
      runAfter:
        - build-web-application

A következő két feladat a szerviz, az útvonal és a telepítés YAML fájljainak alkalmazásáért felel, amelyek a webalkalmazásunk k8s mappájában találhatók, valamint azok frissítéséért új képek létrehozásakor. E két klaszter feladatot már a cikk elején meghatároztuk.

A csővezeték indítása

Tehát, az összes részünk elkészült, és a következő parancssal indítjuk el:

$ tkn pipeline start build-and-deploy-react

Ebben a fázisban a parancssort interaktív módban használjuk, és válaszolnunk kell minden kérdésre a megfelelő erőforrás kiválasztásával: a git erőforráshoz a web-application-repo-t választjuk, majd az első kép erőforrásához – built-web-application-image, végül a második kép erőforrásához – runtime-web-application-image:

? Choose the git resource to use for web-application-repo: web-application-repo (https://github.com/nodeshift-starters/react-pipeline-example)
? Choose the image resource to use for built-web-application-image: built-web-application-image (image-registry.openshift-image-registry.svc:5000/webapp-pipeline/built-web-
application:latest)
? Choose the image resource to use for runtime-web-application-image: runtime-web-application-image (image-registry.openshift-image-registry.svc:5000/webapp-pipeline/runtim
e-web-application:latest)
Pipelinerun started: build-and-deploy-react-run-4xwsr

Most ellenőrizzük a csővezeték állapotát a következő paranccsal:

$ tkn pipeline logs -f

Miután a csővezeték elindult és az alkalmazás telepítve lett, kérdezzük le a publikált útvonalat a következő paranccsal:

$ oc get route react-pipeline-example --template='http://{{.spec.host}}'

A jobb vizuális élmény érdekében megtekinthetjük csővezetékünket a webes konzol Developer módjában a szakaszban Pipelines, ahogy az a 1. ábrán látható.

1. ábra. Futtató csővezetékek áttekintése.

A futó csővezeték rákattintása további információkat jelenít meg, ahogy az a 2. ábrán látható.

2. ábra. A csővezetékről további információk.

A további információk után megtekinthetjük a futó alkalmazásokat a következő nézetben: Topology, ahogy az a 3. ábrán látható.

3. ábra. Futtató pod.

A jobb felső sarokban lévő körre kattintva megnyithatjuk az alkalmazásunkat, ahogy az a 4. ábrán látható.

4. ábra. Futtató React alkalmazás.

Zárás

Így bemutattuk, hogyan indíthatunk el egy fejlesztői szervert az OpenShift-en az alkalmazásunkhoz, és szinkronizálhatjuk a helyi fájlrendszerünkkel. Ezen kívül megnéztük, hogyan lehet szimulálni egy chained-build sablont az OpenShift Pipelines segítségével. A cikkben található példakódok elérhetők itt.