Zdravím všechny na tomto blogu! Toto je třetí příspěvek v sérii, ve které ukazujeme, jak nasadit moderní webové aplikace na Red Hat OpenShift.
V předchozích dvou příspěvcích jsme ukázali, jak nasadit moderní webové aplikace v několika krocích a jak používat nový obraz S2I spolu s běžným obrazem HTTP serveru, jako je NGINX, pomocí zřetězených sestavení k orchestraci produkčních nasazení. .
Dnes si ukážeme, jak spustit vývojový server pro vaši aplikaci na platformě OpenShift a synchronizovat jej s lokálním souborovým systémem, a také si povíme, co jsou OpenShift Pipelines a jak je lze použít jako alternativu k propojeným sestavením.
OpenShift jako vývojové prostředí
Vývojový pracovní postup
Jak již bylo uvedeno v , typický vývojový proces pro moderní webové aplikace je prostě nějaký druh „vývojového serveru“, který sleduje změny v místních souborech. Když k nim dojde, spustí se sestavení aplikace a poté se aktualizuje do prohlížeče.
Ve většině moderních frameworků je takový „vývojový server“ zabudován do odpovídajících nástrojů příkazového řádku.
Místní příklad
Nejprve se podívejme, jak to funguje při místním spouštění aplikací. Vezměme si jako příklad aplikaci z předchozích článků, ačkoli téměř stejné koncepty pracovních postupů platí ve všech ostatních moderních frameworkech.
Pro spuštění "dev serveru" v našem příkladu React zadáme následující příkaz:
$ npm run start
Poté v okně terminálu uvidíme něco takového:
A naše aplikace se otevře ve výchozím prohlížeči:
Nyní, pokud provedeme změny v souboru, aplikace by se měla aktualizovat v prohlížeči.
OK, s vývojem v lokálním režimu je vše jasné, ale jak toho dosáhnout na OpenShift?
Vývojový server na OpenShift
Pokud si vzpomínáte, v , podívali jsme se na takzvanou fázi běhu obrazu S2I a zjistili jsme, že ve výchozím nastavení je za obsluhu naší webové aplikace zodpovědný modul služby.
Pokud se však podíváte blíže z tohoto příkladu obsahuje proměnnou prostředí $NPM_RUN, která vám umožňuje provést váš příkaz.
K nasazení naší aplikace můžeme například použít modul nodeshift:
$ npx nodeshift --deploy.env NPM_RUN="yarn start" --dockerImage=nodeshift/ubi8-s2i-web-app
Poznámka: Výše uvedený příklad je zkrácen pro ilustraci obecné myšlenky.
Zde jsme do našeho nasazení přidali proměnnou prostředí NPM_RUN, která běhovému prostředí říká, aby spustilo příkaz yarn start, který spustí vývojový server React v našem modulu OpenShift.
Když se podíváte na záznam běžícího modulu, bude to vypadat nějak takto:
To vše samozřejmě nebude nic, dokud nebudeme moci synchronizovat místní kód s kódem, u kterého jsou také sledovány změny, ale žije na vzdáleném serveru.
Synchronizace vzdáleného a místního kódu
Naštěstí nodeshift může snadno pomoci se synchronizací a ke sledování změn můžete použít příkaz watch.
Takže poté, co spustíme příkaz k nasazení vývojového serveru pro naši aplikaci, můžeme bezpečně použít následující příkaz:
$ npx nodeshift watch
V důsledku toho bude vytvořeno připojení k běžícímu modulu, který jsme vytvořili o něco dříve, bude aktivována synchronizace našich lokálních souborů se vzdáleným clusterem a soubory v našem lokálním systému začnou být sledovány kvůli změnám.
Pokud tedy nyní aktualizujeme soubor src/App.js, systém na tyto změny zareaguje, zkopíruje je do vzdáleného clusteru a spustí vývojový server, který následně aktualizuje naši aplikaci v prohlížeči.
Pro dokončení obrázku si ukažme, jak vypadají celé tyto pří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
Příkaz watch je abstrakcí nad příkazem oc rsync, můžete se dozvědět více o tom, jak to funguje .
Toto byl příklad pro React, ale úplně stejnou metodu lze použít s jinými frameworky, stačí nastavit proměnnou prostředí NPM_RUN podle potřeby.
Potrubí Openshift
Dále si povíme o nástroji, jako je OpenShift Pipelines, a o tom, jak jej lze použít jako alternativu k zřetězeným sestavením.
Co jsou OpenShift Pipelines
OpenShift Pipelines je nativní cloudový CI/CD kontinuální integrační a doručovací systém navržený pro organizaci potrubí pomocí Tekton. Tekton je flexibilní open-source Kubernetes-native CI/CD framework, který vám umožňuje automatizovat nasazení na různých platformách (Kubernetes, bez serverů, virtuální stroje atd.) abstrahováním od základní vrstvy.
Pochopení tohoto článku vyžaduje určitou znalost Pipelines, proto důrazně doporučujeme, abyste si jej nejprve přečetli .
Nastavení vašeho pracovního prostředí
Chcete-li si pohrát s příklady v tomto článku, musíte nejprve připravit své pracovní prostředí:
- Nainstalujte a nakonfigurujte cluster OpenShift 4. Naše příklady k tomu používají CodeReady Containers (CRD), návod k instalaci naleznete .
- Jakmile je cluster připraven, musíte na něj nainstalovat Pipeline Operator. Nebojte se, je to snadné, návod k instalaci .
- Stažení (tkn) .
- Spusťte nástroj příkazového řádku create-react-app a vytvořte aplikaci, kterou poté nasadíte (jedná se o jednoduchou aplikaci ).
- (Volitelné) Naklonujte úložiště, aby se ukázková aplikace spustila lokálně pomocí npm install a poté npm start.
Úložiště aplikací bude mít také složku k8s, která bude obsahovat Kubernetes/OpenShift YAML použité k nasazení aplikace. Budou zde úkoly, klastrové úkoly, zdroje a potrubí, které zde vytvoříme .
Dostat se dolů
Prvním krokem pro náš příklad je vytvoření nového projektu v clusteru OpenShift. Nazvěme tento projekt webapp-pipeline a vytvořte jej pomocí následujícího příkazu:
$ oc new-project webapp-pipeline
Tento název projektu se později objeví v kódu, takže pokud se rozhodnete jej pojmenovat jinak, nezapomeňte odpovídajícím způsobem upravit vzorový kód. Počínaje tímto bodem nepůjdeme shora dolů, ale zdola nahoru: to znamená, že nejprve vytvoříme všechny součásti dopravníku a teprve potom samotný dopravník.
Tak za prvé...
Úkoly
Vytvořme pár úkolů, které následně pomohou nasadit aplikaci v rámci našeho potrubí. První úkol – apply_manifests_task – je zodpovědný za aplikaci YAML těch zdrojů Kubernetes (služby, nasazení a trasy), které jsou umístěny ve složce k8s naší aplikace. Druhý úkol – update_deployment_task – je zodpovědný za aktualizaci již nasazeného obrazu na ten vytvořený naším kanálem.
Nebojte se, pokud to ještě není příliš jasné. Ve skutečnosti jsou tyto úlohy něco jako utility a podíváme se na ně podrobněji o něco později. Prozatím je jen vytvoří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
Poté pomocí příkazu tkn CLI zkontrolujeme, zda byly úlohy vytvořeny:
$ tkn task ls
NAME AGE
apply-manifests 1 minute ago
update-deployment 1 minute ago
Poznámka: Toto jsou místní úkoly pro váš aktuální projekt.
Clusterové úkoly
Clusterové úlohy jsou v zásadě stejné jako jednoduché úlohy. To znamená, že se jedná o opakovaně použitelnou kolekci kroků, které jsou při spouštění konkrétní úlohy tak či onak kombinovány. Rozdíl je v tom, že úloha clusteru je dostupná všude v rámci clusteru. Chcete-li zobrazit seznam úloh clusteru, které se automaticky vytvoří při přidávání Pipeline Operator, znovu použijeme pří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
Nyní vytvoříme dvě klastrové úlohy. První vygeneruje obraz S2I a odešle jej do interního registru OpenShift; druhým je vytvořit naši image založenou na NGINX pomocí aplikace, kterou jsme již vytvořili jako obsah.
Vytvořte a odešlete obrázek
Při vytváření první úlohy zopakujeme to, co jsme již dělali v předchozím článku o propojených sestavách. Připomeňme, že jsme použili obrázek S2I (ubi8-s2i-web-app) k „sestavení“ naší aplikace a skončili jsme s obrázkem uloženým v interním registru OpenShift. Nyní použijeme tento obrázek webové aplikace S2I k vytvoření souboru DockerFile pro naši aplikaci a poté použijeme Buildah k provedení skutečného sestavení a odeslání výsledného obrázku do interního registru OpenShift, protože to je přesně to, co OpenShift dělá, když nasazujete své aplikace pomocí NodeShift. .
Jak jsme to všechno věděli, ptáte se? Z , jen jsme to zkopírovali a upravili pro sebe.
Nyní tedy vytvoříme úlohu clusteru s2i-web-app:
$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/clustertasks/s2i-web-app-task.yaml
Nebudeme to podrobně analyzovat, ale zaměříme se pouze na parametr OUTPUT_DIR:
params:
- name: OUTPUT_DIR
description: The location of the build output directory
default: build
Ve výchozím nastavení je tento parametr roven buildu, což je místo, kam React umístí sestavený obsah. Jiné frameworky používají jiné cesty, například v Emberu je to dist. Výstupem naší první úlohy clusteru bude obrázek obsahující HTML, JavaScript a CSS, které jsme shromáždili.
Vytvořte obrázek založený na NGINX
Pokud jde o náš druhý klastrový úkol, měl by pro nás vytvořit obraz založený na NGINX s využitím obsahu aplikace, kterou jsme již vytvořili. Toto je v podstatě část předchozí části, kde jsme se podívali na zřetězené sestavení.
Abychom to provedli, – přesně stejně jako výše – vytvoříme klastrovou úlohu webapp-build-runtime:
$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/clustertasks/webapp-build-runtime-task.yaml
Pokud se podíváte na kód pro tyto úlohy clusteru, můžete vidět, že neurčuje úložiště Git, se kterým pracujeme, ani názvy obrázků, které vytváříme. Specifikujeme pouze to, co přesně do Gitu přenášíme, nebo určitý obrázek, kde má být výsledný obrázek vyveden. To je důvod, proč lze tyto klastrové úlohy znovu použít při práci s jinými aplikacemi.
A zde elegantně přejdeme k dalšímu bodu...
Ресурсы
Takže, jak jsme právě řekli, klastrové úlohy by měly být co nejobecnější, musíme vytvořit zdroje, které budou použity jako vstup (úložiště Git) a jako výstup (finální obrázky). První zdroj, který potřebujeme, je Git, kde sídlí naše aplikace, něco takového:
# 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
Zde je PipelineResource typu git. Klíč url v sekci params ukazuje na konkrétní úložiště a určuje hlavní větev (to je volitelné, ale pro úplnost to píšeme).
Nyní musíme vytvořit zdroj pro obrázek, kde budou uloženy výsledky úlohy s2i-web-app, to se provádí 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
Zde je PipelineResource typu image a hodnota parametru url ukazuje na interní registr obrázků OpenShift, konkrétně ten, který se nachází ve jmenném prostoru webapp-pipeline. Pokud používáte jiný jmenný prostor, nezapomeňte toto nastavení změnit.
A konečně poslední zdroj, který potřebujeme, bude také typu image a toto bude finální obraz NGINX, který bude poté použit během nasazení:
# 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
Znovu si všimněte, že tento prostředek ukládá obraz do interního registru OpenShift ve jmenném prostoru webapp-pipeline.
K vytvoření všech těchto zdrojů najednou použijeme příkaz create:
$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/resources/resource.yaml
Můžete se ujistit, že zdroje byly vytvořeny takto:
$ tkn resource ls
Dopravní potrubí
Nyní, když máme všechny potřebné komponenty, sestavme z nich potrubí vytvořením pomocí následujícího příkazu:
$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/pipelines/build-and-deploy-react.yaml
Než ale spustíme tento příkaz, podívejme se na tyto komponenty. První je název:
apiVersion: tekton.dev/v1alpha1
kind: Pipeline
metadata:
name: build-and-deploy-react
Poté v sekci specifikací vidíme označení zdrojů, které jsme vytvořili dříve:
spec:
resources:
- name: web-application-repo
type: git
- name: built-web-application-image
type: image
- name: runtime-web-application-image
type: image
Poté vytvoříme úkoly, které naše potrubí potřebuje splnit. Nejprve musí provést úlohu s2i-web-app, kterou jsme již vytvořili:
tasks:
- name: build-web-application
taskRef:
name: s2i-web-app
kind: ClusterTask
Tato úloha přebírá vstupní (zdroj Gir) a výstupní (zdroj vestavěné-webové-aplikace-image) parametry. Předáme mu také speciální parametr, aby neověřoval TLS, protože používáme certifikáty s vlastním podpisem:
resources:
inputs:
- name: source
resource: web-application-repo
outputs:
- name: image
resource: built-web-application-image
params:
- name: TLSVERIFY
value: "false"
Další úloha je téměř stejná, pouze zde se nazývá clusterová úloha webapp-build-runtime, kterou jsme již vytvořili:
name: build-runtime-image
taskRef:
name: webapp-build-runtime
kind: ClusterTask
Stejně jako u předchozího úkolu předáme zdroj, ale nyní je to vestavěný obrázek-webové aplikace (výstup našeho předchozího úkolu). A jako výstup opět nastavíme obrázek. Protože tato úloha musí být provedena po předchozí, přidá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
Další dva úkoly zodpovídají za používání souborů YAML služby, směrování a nasazení, které se nacházejí v adresáři k8s naší webové aplikace, a také za aktualizaci tohoto nasazení při vytváření nových obrázků. Tyto dva klastrové úlohy jsme definovali na začátku článku.
Spuštění dopravníku
Všechny části našeho potrubí jsou tedy vytvořeny a spustíme jej pomocí následujícího příkazu:
$ tkn pipeline start build-and-deploy-react
V této fázi se příkazový řádek používá interaktivně a je třeba vybrat vhodné zdroje v reakci na každý z jeho požadavků: pro zdroj git vyberte web-application-repo, pak pro první zdroj obrázku, built-web-application -image a nakonec pro zdroj druhého obrázku –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
Nyní zkontrolujeme stav potrubí pomocí následujícího příkazu:
$ tkn pipeline logs -f
Po spuštění kanálu a nasazení aplikace můžeme požádat o zveřejněnou trasu pomocí následujícího příkazu:
$ oc get route react-pipeline-example --template='http://{{.spec.host}}'
Pro větší vizualizaci si můžete náš pipeline prohlédnout ve vývojářském režimu webové konzole v sekci Potrubí, jak je znázorněno na Obr. 1.
Obr. 1. Revize běžících potrubí.
Kliknutím na běžící potrubí zobrazíte další podrobnosti, jak je znázorněno na obrázku 2.
Rýže. 2. Další informace o potrubí.
Po dalších informacích můžete v zobrazení vidět spuštěné aplikace topologie, jak je znázorněno na Obr.
Obr 3. Vypuštěný modul.
Kliknutím na kroužek v pravém horním rohu ikony se otevře naše aplikace, jak je znázorněno na obr. 4.
Rýže. 4. Spuštění aplikace React.
Závěr
Ukázali jsme tedy, jak spustit vývojový server pro vaši aplikaci na OpenShift a synchronizovat jej s místním souborovým systémem. Podívali jsme se také na to, jak simulovat šablonu zřetězeného sestavení pomocí OpenShift Pipelines. Všechny příklady kódů z tohoto článku lze nalézt .
Další zdroje (EN)
- Zdarma e-kniha
- Další články o na webu Red Hat
Oznámení o nadcházejících webinářích
Začínáme sérii pátečních webinářů o nativním zážitku pomocí Red Hat OpenShift Container Platform a Kubernetes:
Zdroj: www.habr.com