Üdv mindenkinek ezen a blogon! Ez a harmadik bejegyzés a sorozatban, amelyben bemutatjuk, hogyan telepítsünk modern webes alkalmazásokat a Red Hat OpenShift rendszeren.
Az előző két bejegyzésben bemutattuk, hogyan lehet néhány lépésben telepíteni modern webalkalmazásokat, és hogyan lehet új S2I-képet használni egy kész HTTP-szerverkép mellett, mint például az NGINX, láncolt buildekkel az éles telepítések összehangolására. .
Ma megmutatjuk, hogyan futtathat fejlesztői kiszolgálót az alkalmazásához az OpenShift platformon és szinkronizálhatja azt a helyi fájlrendszerrel, valamint arról is beszélünk, hogy mik az OpenShift Pipelines, és hogyan használhatók a csatolt összeállítások alternatívájaként.
OpenShift, mint fejlesztői környezet
Fejlesztési munkafolyamat
Amint azt már leírtuk , a modern webalkalmazások tipikus fejlesztési folyamata egyszerűen valamiféle „fejlesztési szerver”, amely nyomon követi a helyi fájlok változásait. Amikor ezek előfordulnak, az alkalmazás összeállítása elindul, majd frissül a böngészőben.
A legtöbb modern keretrendszerben egy ilyen „fejlesztési szerver” be van építve a megfelelő parancssori eszközökbe.
Helyi példa
Először is nézzük meg, hogyan működik ez az alkalmazások helyi futtatásakor. Vegyük példának az alkalmazást korábbi cikkekből, bár szinte ugyanazok a munkafolyamat-koncepciók érvényesek minden más modern keretrendszerre.
Tehát a "dev szerver" elindításához a React példánkban a következő parancsot írjuk be:
$ npm run start
Ezután a terminál ablakában valami ilyesmit fogunk látni:
És alkalmazásunk az alapértelmezett böngészőben fog megnyílni:
Most, ha módosítjuk a fájlt, az alkalmazásnak frissülnie kell a böngészőben.
OK, minden világos a helyi módban történő fejlesztéssel, de hogyan érhetjük el ugyanezt az OpenShift-en?
Fejlesztői szerver OpenShift-en
Ha emlékszel, be , megnéztük az S2I kép úgynevezett futtatási fázisát, és azt láttuk, hogy alapértelmezés szerint a szerver modul felel a webalkalmazásunk kiszolgálásáért.
Ha azonban jobban megnézed ebből a példából a $NPM_RUN környezeti változót tartalmazza, amely lehetővé teszi a parancs végrehajtását.
Használhatjuk például a nodeshift modult az alkalmazásunk üzembe helyezéséhez:
$ npx nodeshift --deploy.env NPM_RUN="yarn start" --dockerImage=nodeshift/ubi8-s2i-web-app
Megjegyzés: A fenti példa rövidítése az általános elképzelés szemléltetésére szolgál.
Itt hozzáadtuk az NPM_RUN környezeti változót a telepítésünkhöz, amely megmondja a futási környezetnek, hogy futtassa a yarn start parancsot, amely elindítja a React fejlesztői kiszolgálót az OpenShift podban.
Ha megnézi egy futó pod naplóját, az valahogy így fog kinézni:
Mindez persze addig nem lesz semmi, amíg a helyi kódot nem tudjuk szinkronizálni a kóddal, amely ugyancsak figyeli a változásokat, de egy távoli szerveren él.
Távoli és helyi kód szinkronizálása
Szerencsére a nodeshift könnyen segíthet a szinkronizálásban, a watch paranccsal pedig nyomon követhetjük a változásokat.
Tehát miután futtattuk a parancsot a fejlesztői kiszolgáló telepítéséhez az alkalmazásunkhoz, biztonságosan használhatjuk a következő parancsot:
$ npx nodeshift watch
Ennek eredményeként létrejön egy kapcsolat a kicsit korábban létrehozott futó podhoz, aktiválódik a helyi fájljaink szinkronizálása a távoli fürttel, és elkezdődik a helyi rendszerünk fájlok változásainak figyelése.
Ezért ha most frissítjük az src/App.js fájlt, akkor a rendszer reagálni fog ezekre a változásokra, átmásolja azokat a távoli fürtbe, és elindítja a fejlesztőszervert, amely majd frissíti az alkalmazásunkat a böngészőben.
A kép teljessé tételéhez mutassuk meg, hogyan néznek ki ezek a teljes parancsok:
$ 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 parancson felül, többet megtudhat a működéséről .
Ez volt egy példa a Reacthoz, de pontosan ugyanaz a módszer használható más keretrendszerekkel is, csak szükség szerint állítsa be az NPM_RUN környezeti változót.
Openshift csővezetékek
Ezután egy olyan eszközről fogunk beszélni, mint az OpenShift Pipelines, és arról, hogyan használhatók a láncolt buildek alternatívájaként.
Mik azok az OpenShift-csővezetékek
Az OpenShift Pipelines egy felhőben natív CI/CD folyamatos integrációs és kézbesítési rendszer, amelyet a Tekton segítségével csővezetékek szervezésére terveztek. A Tekton egy rugalmas, nyílt forráskódú Kubernetes-natív CI/CD keretrendszer, amely lehetővé teszi a különféle platformokon (Kubernetes, kiszolgáló nélküli, virtuális gépek stb.) történő telepítés automatizálását az alapul szolgáló rétegtől való elvonatkoztatás révén.
Ennek a cikknek a megértéséhez bizonyos ismeretekre van szükség a csővezetékekről, ezért azt javasoljuk, hogy először olvassa el .
Munkakörnyezetének beállítása
A cikkben szereplő példákkal való játékhoz először fel kell készítenie munkakörnyezetét:
- Telepítsen és konfiguráljon egy OpenShift 4 fürtöt. Példáink erre a CodeReady Container-t (CRD) használják, amelyek telepítési útmutatója megtalálható .
- Miután a fürt elkészült, telepítenie kell rá a Pipeline Operatort. Ne féljen, egyszerű, telepítési útmutató .
- Letöltés (tkn) .
- Futtassa a create-react-app parancssori eszközt egy alkalmazás létrehozásához, amelyet ezután telepíteni fog (ez egy egyszerű alkalmazás ).
- (Opcionális) Klónozza a tárat a példaalkalmazás helyi futtatásához az npm install, majd az npm start segítségével.
Az alkalmazástárnak lesz egy k8s mappája is, amely tartalmazza az alkalmazás üzembe helyezéséhez használt Kubernetes/OpenShift YAML-eket. Lesznek Tasks, ClusterTasks, Resources és Pipelines, amelyeket ebben fogunk létrehozni .
Kezdjük el
Példánk első lépése egy új projekt létrehozása az OpenShift-fürtben. Nevezzük ezt a projektet webapp-pipeline-nak, és hozzuk létre a következő paranccsal:
$ oc new-project webapp-pipeline
Ez a projektnév a későbbiekben megjelenik a kódban, így ha úgy dönt, hogy más nevet ad, ne felejtse el ennek megfelelően módosítani a példakódot. Ettől a ponttól kezdve nem fentről lefelé haladunk, hanem alulról felfelé: vagyis először a szállítószalag összes alkatrészét hozzuk létre, és csak utána magát a szállítószalagot.
Szóval először is...
Feladatok
Hozzon létre néhány feladatot, amelyek azután segítik az alkalmazás telepítését a folyamatban. Az első feladat - apply_manifests_task - felelős az alkalmazásunk k8s mappájában található Kubernetes-erőforrások YAML-jének alkalmazásáért (szolgáltatás, telepítés és útvonal). A második feladat – update_deployment_task – a már telepített lemezkép frissítéséért felelős a folyamatunk által létrehozott képre.
Ne aggódjon, ha még nem teljesen világos. Valójában ezek a feladatok olyanok, mint a segédprogramok, és egy kicsit később részletesebben is megvizsgáljuk őket. Egyelőre 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 paranccsal ellenőrizzük, hogy a feladatok létrejöttek-e:
$ tkn task ls
NAME AGE
apply-manifests 1 minute ago
update-deployment 1 minute ago
Megjegyzés: Ezek az aktuális projekt helyi feladatai.
Klaszter feladatok
A fürtfeladatok alapvetően megegyeznek az egyszerű feladatokkal. Azaz olyan lépések újrafelhasználható gyűjteménye, amelyek ilyen vagy olyan módon kombinálódnak egy adott feladat futtatásakor. A különbség az, hogy egy fürtfeladat mindenhol elérhető a fürtön belül. A Pipeline Operator hozzáadásakor automatikusan létrehozott fürtfeladatok listájának megtekintéséhez 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 hozzunk létre két fürtfeladatot. Az első létrehozza az S2I képfájlt, és elküldi a belső OpenShift rendszerleíró adatbázisba; a második az, hogy NGINX-re építjük az arculatunkat, a már felépített alkalmazást tartalomként használva.
Készítse el és küldje el a képet
Az első feladat elkészítésekor megismételjük azt, amit az előző cikkben már tettünk a linkelt összeállításokról. Emlékezzünk vissza, hogy az S2I képfájlt (ubi8-s2i-web-app) használtuk az alkalmazásunk „felépítéséhez”, és végül az OpenShift belső nyilvántartásában tárolt kép lett. Most ezt az S2I webalkalmazás-képet fogjuk használni, hogy létrehozzunk egy DockerFile-t az alkalmazásunkhoz, majd a Buildah segítségével végrehajtsuk a tényleges összeállítást, és az eredményül kapott képet az OpenShift belső registry-ébe küldjük, mivel az OpenShift pontosan ezt teszi, amikor NodeShift használatával telepíti az alkalmazásokat. .
Kérdezed, honnan tudtuk meg mindezt? Tól től , csak lemásoltuk és magunknak módosítottuk.
Tehát most hozzuk létre az s2i-web-alkalmazás-fürt feladatot:
$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/clustertasks/s2i-web-app-task.yaml
Ezt nem elemezzük részletesen, csak az OUTPUT_DIR paraméterre összpontosítunk:
params:
- name: OUTPUT_DIR
description: The location of the build output directory
default: build
Alapértelmezés szerint ez a paraméter megegyezik a build értékkel, amelybe a React helyezi az összeállított tartalmat. Más keretrendszerek különböző útvonalakat használnak, például az Emberben ez a dist. Első fürtfeladatunk kimenete egy kép lesz, amely az általunk összegyűjtött HTML-t, JavaScriptet és CSS-t tartalmazza.
Készítsen képet az NGINX alapján
Ami a második fürtfeladatunkat illeti, egy NGINX alapú képet kell készítenie nekünk, felhasználva a már felépített alkalmazás tartalmát. Lényegében ez az a része az előző résznek, ahol a láncolt buildeket néztük meg.
Ehhez - pontosan ugyanúgy, mint fent - létrehozunk egy webapp-build-runtime fürtfeladatot:
$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/clustertasks/webapp-build-runtime-task.yaml
Ha megnézi ezeknek a fürtfeladatoknak a kódját, láthatja, hogy nem határozza meg azt a Git-tárat, amellyel dolgozunk, vagy az általunk létrehozott képek nevét. Csak azt adjuk meg, hogy pontosan mit vigyünk át a Git-be, vagy egy bizonyos képet, ahol a végső képet kell kiadni. Ezért ezek a fürtfeladatok újra felhasználhatók más alkalmazásokkal való munka során.
És itt kecsesen áttérünk a következő pontra...
Ресурсы
Tehát, mivel, ahogy az imént mondtuk, a fürtfeladatoknak a lehető legáltalánosabbaknak kell lenniük, olyan erőforrásokat kell létrehoznunk, amelyeket bemenetként (a Git-tár) és kimenetként (a végső képek) használunk. Az első erőforrás, amire szükségünk van, 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 git típusú. A params részben lévő url kulcs egy adott tárhelyre mutat, és megadja a fő ágat (ez nem kötelező, de a teljesség kedvéért írjuk).
Most létre kell hoznunk egy erőforrást a képhez, ahol az s2i-web-app feladat eredményei mentésre kerülnek, ez a következőképpen történik:
# 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 kép típusú, és az url paraméter értéke a belső OpenShift Image Registry-re mutat, különösen arra, amely a webapp-pipeline névtérben található. Ne felejtse el módosítani ezt a beállítást, ha más névteret használ.
És végül, az utolsó erőforrás, amire szükségünk van, szintén image típusú lesz, és ez lesz az utolsó NGINX-kép, amelyet ezután a telepítés során használunk majd:
# 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 vegye figyelembe, hogy ez az erőforrás a belső OpenShift-nyilvántartásban tárolja a képet a webapp-pipeline névtérben.
Az összes erőforrás egyidejű létrehozásához a create parancsot használjuk:
$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/resources/resource.yaml
Győződjön meg arról, hogy az erőforrások a következőképpen lettek létrehozva:
$ tkn resource ls
Szállítószalag csővezeték
Most, hogy megvan az összes szükséges komponens, állítsunk össze belőlük egy folyamatot a következő paranccsal létrehozva:
$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/pipelines/build-and-deploy-react.yaml
De mielőtt ezt a parancsot futtatnánk, nézzük meg ezeket az összetevőket. Az első a név:
apiVersion: tekton.dev/v1alpha1
kind: Pipeline
metadata:
name: build-and-deploy-react
Ezután a specifikációs részben láthatjuk a korábban létrehozott erőforrások jelzé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 folyamatunknak el kell végeznie. Először is végre kell hajtania az általunk már létrehozott s2i-web-app feladatot:
tasks:
- name: build-web-application
taskRef:
name: s2i-web-app
kind: ClusterTask
Ez a feladat bemeneti (gir erőforrás) és kimeneti (beépített webalkalmazás-kép erőforrás) paramétereket vesz igénybe. Egy speciális paramétert is átadunk neki, hogy ne ellenőrizze a TLS-t, mivel önaláírt tanúsítványokat használunk:
resources:
inputs:
- name: source
resource: web-application-repo
outputs:
- name: image
resource: built-web-application-image
params:
- name: TLSVERIFY
value: "false"
A következő feladat szinte ugyanaz, csak itt az általunk már létrehozott webapp-build-runtime cluster feladat neve:
name: build-runtime-image
taskRef:
name: webapp-build-runtime
kind: ClusterTask
Az előző feladathoz hasonlóan itt is átadunk egy erőforrást, de ez most build-web-application-image (az előző feladatunk kimenete). És kimenetként ismét beállítjuk a képet. Mivel ezt a feladatot az előző után kell végrehajtani, hozzáadjuk a runAfter mezőt:
resources:
inputs:
- name: image
resource: built-web-application-image
outputs:
- name: image
resource: runtime-web-application-image
params:
- name: TLSVERIFY
value: "false"
runAfter:
- build-web-application
A következő két feladat a webalkalmazásunk k8s könyvtárában található szolgáltatás-, útvonal- és telepítési YAML-fájlok használatáért, valamint az új lemezképek létrehozásakor a telepítés frissítéséért felel. Ezt a két klaszterfeladatot definiáltuk a cikk elején.
A szállítószalag indítása
Tehát a folyamat minden része létrejön, és a következő paranccsal futtatjuk:
$ tkn pipeline start build-and-deploy-react
Ebben a szakaszban a parancssort interaktívan használják, és minden egyes kérésére ki kell választani a megfelelő erőforrásokat: a git erőforráshoz válassza a web-application-repo, majd az első képerőforrásnál a beépített webalkalmazást. -image, és végül a második képforráshoz –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
A folyamat elindítása és az alkalmazás telepítése után a következő paranccsal kérhetjük a közzétett útvonalat:
$ oc get route react-pipeline-example --template='http://{{.spec.host}}'
A jobb megjelenítés érdekében megtekintheti folyamatunkat a webkonzol Fejlesztői módjában a részben Csővezetékekábrán látható módon. 1.
1. ábra. A futó csővezetékek áttekintése.
Ha egy futó csővezetékre kattint, további részletek jelennek meg, amint az a 2. ábrán látható.
Rizs. 2. További információk a csővezetékről.
További információ után a futó alkalmazásokat láthatja a nézetben Topológia, amint azt a 3. ábra mutatja.
3. ábra. Elindult pod.
Az ikon jobb felső sarkában lévő körre kattintva megnyílik az alkalmazásunk, ahogy az a 4. ábrán látható.
Rizs. 4. A React alkalmazás futtatása.
Következtetés
Tehát megmutattuk, hogyan futtathat fejlesztőkiszolgálót az alkalmazásához az OpenShift-en, és hogyan szinkronizálhatja azt a helyi fájlrendszerrel. Azt is megvizsgáltuk, hogyan lehet szimulálni egy láncolt felépítésű sablont az OpenShift Pipelines használatával. A cikkben szereplő összes példakód megtalálható .
További források (EN)
- Ingyenes e-könyv
- Egyéb cikkek a a Red Hat honlapján
Közelgő webináriumok bejelentései
Pénteki webináriumok sorozatát indítjuk a Red Hat OpenShift Container Platform és a Kubernetes használatával kapcsolatos natív tapasztalatokról:
Forrás: will.com