Ahojte všetci na tomto blogu! Toto je tretí príspevok v sérii, v ktorej ukážeme, ako nasadiť moderné webové aplikácie na Red Hat OpenShift.
V predchádzajúcich dvoch príspevkoch sme ukázali, ako nasadiť moderné webové aplikácie v niekoľkých krokoch a ako používať nový obraz S2I spolu s bežným obrazom servera HTTP, ako je NGINX, pomocou reťazených zostavení na organizáciu produkčných nasadení. .
Dnes si ukážeme, ako spustiť vývojový server pre vašu aplikáciu na platforme OpenShift a synchronizovať ho s lokálnym súborovým systémom, a tiež si povieme, čo sú OpenShift Pipelines a ako ich možno použiť ako alternatívu k prepojeným zostavám.
OpenShift ako vývojové prostredie
Vývojový pracovný postup
Ako už bolo uvedené v , typický vývojový proces pre moderné webové aplikácie je jednoducho nejaký „vývojový server“, ktorý sleduje zmeny v lokálnych súboroch. Keď sa vyskytnú, spustí sa zostava aplikácie a potom sa aktualizuje do prehliadača.
Vo väčšine moderných rámcov je takýto „vývojový server“ zabudovaný do príslušných nástrojov príkazového riadku.
Miestny príklad
Najprv sa pozrime, ako to funguje pri lokálnom spúšťaní aplikácií. Zoberme si aplikáciu ako príklad z predchádzajúcich článkov, hoci takmer rovnaké koncepty pracovného toku platia vo všetkých ostatných moderných frameworkoch.
Na spustenie „dev servera“ v našom príklade React teda zadáme nasledujúci príkaz:
$ npm run start
Potom v okne terminálu uvidíme niečo takéto:
A naša aplikácia sa otvorí v predvolenom prehliadači:
Ak teraz vykonáme zmeny v súbore, aplikácia by sa mala aktualizovať v prehliadači.
OK, všetko je jasné s vývojom v lokálnom režime, ale ako dosiahnuť to isté na OpenShift?
Vývojový server na OpenShift
Ak si pamätáte, v , pozreli sme sa na takzvanú fázu spustenia obrazu S2I a zistili sme, že v predvolenom nastavení je za obsluhu našej webovej aplikácie zodpovedný servisný modul.
Ak sa však pozriete bližšie z tohto príkladu obsahuje premennú prostredia $NPM_RUN, ktorá vám umožňuje vykonať váš príkaz.
Na nasadenie našej aplikácie môžeme napríklad použiť modul nodeshift:
$ npx nodeshift --deploy.env NPM_RUN="yarn start" --dockerImage=nodeshift/ubi8-s2i-web-app
Poznámka: Vyššie uvedený príklad je skrátený na ilustráciu všeobecnej myšlienky.
Tu sme do nášho nasadenia pridali premennú prostredia NPM_RUN, ktorá hovorí runtime, aby spustilo príkaz yarn start, ktorý spustí vývojový server React v našom module OpenShift.
Ak sa pozriete na denník bežiaceho modulu, bude to vyzerať asi takto:
Samozrejme, toto všetko nebude nič, kým nebudeme môcť synchronizovať lokálny kód s kódom, ktorý je tiež monitorovaný na zmeny, ale žije na vzdialenom serveri.
Synchronizácia vzdialeného a lokálneho kódu
Našťastie nodeshift môže jednoducho pomôcť so synchronizáciou a na sledovanie zmien môžete použiť príkaz watch.
Takže po spustení príkazu na nasadenie vývojového servera pre našu aplikáciu môžeme bezpečne použiť nasledujúci príkaz:
$ npx nodeshift watch
V dôsledku toho sa vytvorí pripojenie k bežiacemu modulu, ktorý sme vytvorili o niečo skôr, aktivuje sa synchronizácia našich lokálnych súborov so vzdialeným klastrom a súbory v našom lokálnom systéme sa začnú monitorovať z hľadiska zmien.
Ak teda teraz aktualizujeme súbor src/App.js, systém na tieto zmeny zareaguje, skopíruje ich do vzdialeného klastra a spustí vývojový server, ktorý následne aktualizuje našu aplikáciu v prehliadači.
Na dokončenie obrázku si ukážme, ako vyzerajú celé tieto príkazy:
$ 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
Príkaz watch je abstrakcia nad príkazom oc rsync, môžete sa dozvedieť viac o tom, ako to funguje .
Toto bol príklad pre React, ale presne tú istú metódu možno použiť aj s inými rámcami, stačí nastaviť premennú prostredia NPM_RUN podľa potreby.
Potrubie Openshift
Ďalej si povieme o nástroji, akým je OpenShift Pipelines, a o tom, ako ho možno použiť ako alternatívu k reťazeným zostavám.
Čo sú to OpenShift Pipelines
OpenShift Pipelines je natívny cloudový CI/CD systém kontinuálnej integrácie a doručovania navrhnutý na organizovanie potrubí pomocou Tekton. Tekton je flexibilný open-source Kubernetes-native CI/CD framework, ktorý vám umožňuje automatizovať nasadenie na rôznych platformách (Kubernetes, bezserverové, virtuálne stroje atď.) abstrahovaním od základnej vrstvy.
Pochopenie tohto článku si vyžaduje určité znalosti o Pipelines, preto dôrazne odporúčame, aby ste si ho najskôr prečítali .
Nastavenie pracovného prostredia
Ak si chcete pohrať s príkladmi v tomto článku, musíte si najskôr pripraviť pracovné prostredie:
- Nainštalujte a nakonfigurujte klaster OpenShift 4. Naše príklady na to používajú kontajnery CodeReady (CRD), návod na inštaláciu nájdete .
- Keď je klaster pripravený, musíte naň nainštalovať Pipeline Operator. Nebojte sa, je to jednoduché, návod na inštaláciu .
- Na stiahnutie (tkn) .
- Spustite nástroj príkazového riadka create-react-app a vytvorte aplikáciu, ktorú potom nasadíte (toto je jednoduchá aplikácia ).
- (Voliteľné) Naklonujte úložisko, aby sa vzorová aplikácia spúšťala lokálne s npm install a potom npm start.
Repozitár aplikácií bude mať aj priečinok k8s, ktorý bude obsahovať Kubernetes/OpenShift YAML použité na nasadenie aplikácie. V tomto vytvoríme úlohy, úlohy klastra, zdroje a potrubia .
Začnime
Prvým krokom pre náš príklad je vytvorenie nového projektu v klastri OpenShift. Nazvime tento projekt webapp-pipeline a vytvorte ho pomocou nasledujúceho príkazu:
$ oc new-project webapp-pipeline
Tento názov projektu sa neskôr objaví v kóde, takže ak sa ho rozhodnete pomenovať inak, nezabudnite zodpovedajúcim spôsobom upraviť vzorový kód. Od tohto bodu nepôjdeme zhora nadol, ale zdola nahor: to znamená, že najskôr vytvoríme všetky komponenty dopravníka a až potom samotný dopravník.
Takže v prvom rade...
Úlohy
Vytvorme si pár úloh, ktoré nám potom pomôžu nasadiť aplikáciu v rámci nášho potrubia. Prvá úloha – apply_manifests_task – je zodpovedná za aplikáciu YAML tých zdrojov Kubernetes (služba, nasadenie a trasa), ktoré sa nachádzajú v priečinku k8s našej aplikácie. Druhá úloha – update_deployment_task – je zodpovedná za aktualizáciu už nasadeného obrazu na ten vytvorený naším kanálom.
Nebojte sa, ak to ešte nie je úplne jasné. V skutočnosti sú tieto úlohy niečo ako pomocné programy a podrobnejšie sa na ne pozrieme o niečo neskôr. Zatiaľ ich len vytvoríme:
$ 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
Potom pomocou príkazu tkn CLI skontrolujeme, či boli úlohy vytvorené:
$ tkn task ls
NAME AGE
apply-manifests 1 minute ago
update-deployment 1 minute ago
Poznámka: Toto sú lokálne úlohy pre váš aktuálny projekt.
Klastrové úlohy
Klastrové úlohy sú v podstate rovnaké ako jednoduché úlohy. To znamená, že ide o opakovane použiteľnú kolekciu krokov, ktoré sa pri spustení konkrétnej úlohy kombinujú tak či onak. Rozdiel je v tom, že úloha klastra je dostupná všade v rámci klastra. Na zobrazenie zoznamu klastrových úloh, ktoré sa automaticky vytvoria pri pridávaní Pipeline Operator, opäť použijeme príkaz tkn CLI:
$ 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
Teraz vytvorme dve klastrové úlohy. Prvý vygeneruje obraz S2I a odošle ho do interného registra OpenShift; druhým je vytvoriť náš imidž založený na NGINX pomocou aplikácie, ktorú sme už vytvorili ako obsah.
Vytvorte a odošlite obrázok
Pri vytváraní prvej úlohy zopakujeme to, čo sme už urobili v predchádzajúcom článku o prepojených zostavách. Pripomeňme, že sme použili obrázok S2I (ubi8-s2i-web-app) na „zostavenie“ našej aplikácie a skončili sme s obrázkom uloženým v internom registri OpenShift. Teraz použijeme tento obrázok webovej aplikácie S2I na vytvorenie súboru DockerFile pre našu aplikáciu a potom použijeme Buildah na vytvorenie skutočného zostavenia a vloženie výsledného obrázka do interného registra OpenShift, pretože presne to robí OpenShift, keď nasadíte svoje aplikácie pomocou NodeShift. .
Ako sme to všetko vedeli, pýtate sa? Od , len sme si ho skopírovali a upravili pre seba.
Takže teraz vytvorte úlohu klastra s2i-web-app:
$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/clustertasks/s2i-web-app-task.yaml
Nebudeme to podrobne analyzovať, ale zameriame sa iba na parameter OUTPUT_DIR:
params:
- name: OUTPUT_DIR
description: The location of the build output directory
default: build
V predvolenom nastavení sa tento parameter rovná build, čo je miesto, kam React umiestňuje zostavený obsah. Iné frameworky používajú iné cesty, napríklad v Ember je to dist. Výstupom našej prvej klastrovej úlohy bude obrázok obsahujúci HTML, JavaScript a CSS, ktoré sme zhromaždili.
Vytvorte obrázok založený na NGINX
Pokiaľ ide o našu druhú klastrovú úlohu, mala by pre nás vytvoriť obraz založený na NGINX pomocou obsahu aplikácie, ktorú sme už vytvorili. Toto je v podstate časť predchádzajúcej časti, kde sme sa pozreli na reťazené zostavy.
Aby sme to urobili, presne tak, ako vyššie, vytvoríme klastrovú úlohu webapp-build-runtime:
$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/clustertasks/webapp-build-runtime-task.yaml
Ak sa pozriete na kód týchto klastrových úloh, môžete vidieť, že nešpecifikuje úložisko Git, s ktorým pracujeme, ani názvy obrázkov, ktoré vytvárame. Špecifikujeme iba to, čo presne prenášame do Gitu, alebo určitý obrázok, kde má byť výstupný výsledný obrázok. Preto je možné tieto klastrové úlohy opätovne použiť pri práci s inými aplikáciami.
A tu elegantne prejdeme k ďalšiemu bodu...
zdroje
Takže, ako sme práve povedali, klastrové úlohy by mali byť čo najvšeobecnejšie, musíme vytvoriť zdroje, ktoré sa použijú ako vstup (úložisko Git) a ako výstup (finálne obrázky). Prvým zdrojom, ktorý potrebujeme, je Git, kde sa nachádza naša aplikácia, niečo takéto:
# 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
Tu je PipelineResource typu git. Kľúč url v sekcii params ukazuje na konkrétny repozitár a určuje hlavnú vetvu (toto je voliteľné, ale pre úplnosť to píšeme).
Teraz musíme vytvoriť zdroj pre obrázok, kde sa uložia výsledky úlohy s2i-web-app, a to takto:
# 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
Tu je PipelineResource typu image a hodnota parametra url ukazuje na interný register obrázkov OpenShift, konkrétne ten, ktorý sa nachádza v mennom priestore webapp-pipeline. Ak používate iný menný priestor, nezabudnite toto nastavenie zmeniť.
A nakoniec, posledný zdroj, ktorý potrebujeme, bude tiež typu image a toto bude konečný obrázok NGINX, ktorý sa potom použije počas nasadenia:
# 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
Opäť si všimnite, že tento prostriedok ukladá obrázok do interného registra OpenShift v mennom priestore webapp-pipeline.
Na vytvorenie všetkých týchto zdrojov naraz použijeme príkaz create:
$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/resources/resource.yaml
Môžete sa uistiť, že zdroje boli vytvorené takto:
$ tkn resource ls
Dopravné potrubie
Teraz, keď máme všetky potrebné komponenty, zostavme z nich potrubie tak, že ho vytvoríme pomocou nasledujúceho príkazu:
$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/pipelines/build-and-deploy-react.yaml
Ale predtým, ako spustíme tento príkaz, pozrime sa na tieto komponenty. Prvým je názov:
apiVersion: tekton.dev/v1alpha1
kind: Pipeline
metadata:
name: build-and-deploy-react
Potom v sekcii špecifikácií vidíme označenie zdrojov, ktoré sme vytvorili predtým:
spec:
resources:
- name: web-application-repo
type: git
- name: built-web-application-image
type: image
- name: runtime-web-application-image
type: image
Potom vytvoríme úlohy, ktoré náš kanál potrebuje dokončiť. Najprv musí vykonať úlohu s2i-web-app, ktorú sme už vytvorili:
tasks:
- name: build-web-application
taskRef:
name: s2i-web-app
kind: ClusterTask
Táto úloha preberá vstupné (zdroj GIR) a výstup (zdroj vstavanej webovej aplikácie-obrázku). Odovzdáme mu aj špeciálny parameter, aby neoveril TLS, pretože používame certifikáty s vlastným podpisom:
resources:
inputs:
- name: source
resource: web-application-repo
outputs:
- name: image
resource: built-web-application-image
params:
- name: TLSVERIFY
value: "false"
Ďalšia úloha je takmer rovnaká, len tu sa volá klastrová úloha webapp-build-runtime, ktorú sme už vytvorili:
name: build-runtime-image
taskRef:
name: webapp-build-runtime
kind: ClusterTask
Rovnako ako pri predchádzajúcej úlohe odovzdáme zdroj, ale teraz je to vstavaný obrázok webovej aplikácie (výstup našej predchádzajúcej úlohy). A ako výstup opäť nastavíme obrázok. Keďže táto úloha musí byť vykonaná po predchádzajúcej, pridáme pole runAfter:
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
Ďalšie dve úlohy sú zodpovedné za používanie služby, smerovania a nasadenia YAML súborov, ktoré sa nachádzajú v adresári k8s našej webovej aplikácie, a tiež za aktualizáciu tohto nasadenia pri vytváraní nových obrázkov. Tieto dve klastrové úlohy sme definovali na začiatku článku.
Spustenie dopravníka
Všetky časti nášho potrubia sú teda vytvorené a spustíme ho nasledujúcim príkazom:
$ tkn pipeline start build-and-deploy-react
V tejto fáze sa príkazový riadok používa interaktívne a musíte vybrať vhodné zdroje ako odpoveď na každú z jeho požiadaviek: pre zdroj git vyberte web-application-repo, potom pre prvý zdroj obrázka, vstavanú webovú aplikáciu -image a nakoniec pre zdroj druhého obrázka –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
Teraz skontrolujeme stav potrubia pomocou nasledujúceho príkazu:
$ tkn pipeline logs -f
Po spustení potrubia a nasadení aplikácie môžeme požiadať o zverejnenú trasu pomocou nasledujúceho príkazu:
$ oc get route react-pipeline-example --template='http://{{.spec.host}}'
Pre lepšiu vizualizáciu si náš kanál môžete pozrieť v režime vývojára webovej konzoly v sekcii Potrubie, ako je znázornené na obr. 1.
Obr.1. Preskúmanie bežiacich potrubí.
Kliknutím na prebiehajúce potrubie sa zobrazia ďalšie podrobnosti, ako je znázornené na obrázku 2.
Ryža. 2. Ďalšie informácie o potrubí.
Po ďalších informáciách môžete v zobrazení vidieť spustené aplikácie topológia3, ako je znázornené na obr.
Obr 3. Spustený modul.
Kliknutím na krúžok v pravom hornom rohu ikony otvoríme našu aplikáciu, ako je znázornené na obr.
Ryža. 4. Spustenie aplikácie React.
Záver
Ukázali sme teda, ako spustiť vývojový server pre vašu aplikáciu na OpenShift a synchronizovať ho s lokálnym súborovým systémom. Tiež sme sa pozreli na to, ako simulovať šablónu s reťazou zostavy pomocou OpenShift Pipelines. Všetky príklady kódov z tohto článku nájdete .
Ďalšie zdroje (EN)
- Bezplatná e-kniha
- Ďalšie články o na webovej stránke Red Hat
Oznámenia o nadchádzajúcich webinároch
Začíname sériu piatkových webinárov o natívnych skúsenostiach s použitím Red Hat OpenShift Container Platform a Kubernetes:
Zdroj: hab.com