🥇Moderní aplikace na OpenShift, část 3: OpenShift jako vývojové prostředí a konveje OpenShift Pipelines

Ahoj všem v tomto blogu! Dnes máte před sebou třetí příspěvek ze série, ve které ukazujeme, jak nasazovat moderní webové aplikace na Red Hat OpenShift.

V předchozích dvou příspěvcích jsme se podívali na to, jak nasadit moderní webové aplikace během několika málo kroků a jak používat nový obraz S2I v kombinaci s hotovým HTTP serverem, například NGINX, s pomocí propojených sestavení chained builds pro organizaci produkčního nasazení.

Dnes ukážeme, jak spustit na platformě OpenShift vývojový server pro svou aplikaci a synchronizovat ho s místním souborovým systémem, a také si povíme o tom, co jsou OpenShift Pipelines a jak je používat jako alternativu k propojeným sestavením.

OpenShift jako vývojové prostředí

Vývojový pracovní postup (development workflow)

Jak už bylo zmíněno v prvním příspěvku, standardní proces vývoje pro moderní webové aplikace je vlastně jen nějaký 'vývojový server', který sleduje změny v místních souborech. Když se tyto změny objeví, spustí se sestavení aplikace, a ta se pak aktualizuje v prohlížeči.

Většina moderních rámců má takový 'vývojový server' zabudovaný ve svých příslušných příkazových nástrojích.

Lokální příklad

Nejdříve se podíváme, jak to funguje v případě místního spuštění aplikací. Jako příklad použijeme aplikaci React z předchozích článků, ačkoliv stejné koncepty pracovního postupu se uplatňují i ve všech ostatních moderních rámcích.
Takže, abychom spustili 'vývojový server' v našem příkladu s React, zadejte následující příkaz:

$ npm run start

Pak v okně terminálu uvidíme přibližně toto:

A naše aplikace se otevře v prohlížeči podle výchozího nastavení:

Nyní, pokud provedeme změny v souboru, aplikace by se měla v prohlížeči aktualizovat.

OK, o vývoji v místním režimu je vše jasné, ale jak dosáhnout něčeho podobného na OpenShift?

Vývojový server na OpenShift

Pokud si pamatujete, v předchozím příspěvku, jsme probírali takzvanou fázi spuštění (run phase) obrazu S2I a viděli jsme, že našemu webovému aplikaci standardně obsluhuje modul serve.

Pokud se však podíváte pozorněji run script z toho příkladu, existuje proměnná prostředí $NPM_RUN, která umožňuje spuštění vlastního příkazu.

Například můžete použít modul nodeshift k nasazení naší aplikace:

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

Poznámka: výše uvedený příklad je uveden ve zjednodušené podobě, aby ilustroval celkovou myšlenku.

Zde jsme do našeho nasazení přidali proměnnou prostředí NPM_RUN, která říká prováděcímu kroku, že by měl spustit příkaz yarn start, který spustí vývojový server React uvnitř našeho OpenShift podu.

Pokud se podíváme na log běžícího podu, bude to přibližně následující:

Samozřejmě, to všechno nebude mít smysl, dokud nebudeme schopni synchronizovat místní kód s kódem, který je také kontrolován na změny, ale žije na vzdáleném serveru.

Synchronizace vzdáleného a místního kódu

Naštěstí s synchronizací snadno pomůže nodeshift a pro sledování změn můžeme použít příkaz watch.

Takže po provedení příkazu pro nasazení vývojového serveru pro naši aplikaci můžeme bez obav použít tento příkaz:

$ npx nodeshift watch

V důsledku toho se připojí k běžícímu podu, který jsme vytvořili o něco dříve, aktivuje synchronizaci našich místních souborů se vzdáleným klastrem a soubory na našem místním systému začnou být sledovány na změny.

Proto, pokud nyní aktualizujeme soubor src/App.js, systém na tyto změny zareaguje, zkopíruje je na vzdálený klastr a spustí vývojový server, který poté aktualizuje naši aplikaci v prohlížeči.

Pro úplnost ukážeme, jak tyto příkazy vypadají v celku:

$ 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, podrobnosti o tom, jak to funguje, se můžete dozvědět. zde.

To byl příklad pro React, ale stejnou metodu lze použít i s jinými frameworky, stačí správně zapsat proměnnou prostředí NPM_RUN.

Pipelines Openshift

Dále si povíme o nástroji OpenShift Pipelines a o tom, jak ho lze využít jako alternativu k souvisejícím sestavením chained build.

Co jsou OpenShift Pipelines

OpenShift Pipelines je cloudově orientovaný CI/CD systém pro kontinuální integraci a dodání, určený k organizaci pipeline s využitím Tektonu. Tekton je flexibilní Kubernetes-nativní CI/CD rámec s otevřeným kódem, který umožňuje automatizaci nasazení na různých platformách (Kubernetes, serverless, virtuální stroje atd.) tím, že abstrahuje od základní úrovně.

Pro porozumění tomuto článku jsou potřebné určité znalosti o Pipelines, proto důrazně doporučujeme nejprve se seznámit s oficiálním výukovým materiálem.

Nastavení pracovního prostředí

Abychom si mohli vyzkoušet příklady z tohoto článku, musíme nejprve připravit pracovní prostředí:

Nainstalujte a nastavte cluster OpenShift 4. V našich příkladech používáme CodeReady Containers (CRD), pokyny k instalaci najdete zde.
Jakmile bude cluster připraven, je třeba na něj nainstalovat Pipeline Operator. Nebojte se, je to snadné, pokyny k instalaci zde.
Načíst Tekton CLI (tkn) zde.
Spusťte nástroj příkazového řádku create-react-app pro vytvoření aplikace, která bude následně nasazena (je to jednoduchá aplikace React).
(Volitelně) Klonujte repozitář pro lokální spuštění příkladu aplikace pomocí příkazu npm install a poté npm start.

V repozitáři aplikace bude také složka k8s, kde budou umístěny YAML soubory Kubernetes/OpenShift používané pro nasazení aplikace. Tam budou úkoly, ClusterTasks, Resources a Pipelines, které vytvoříme v tomto repozitáře.

Začínáme

Nejdříve je třeba vytvořit nový projekt v clusteru OpenShift pro náš příklad. Nazveme tento projekt webapp-pipeline a vytvoříme ho následujícím příkazem:

$ oc new-project webapp-pipeline

Dále se toto jméno projektu bude objevovat v kódu, takže pokud se rozhodnete pojmenovat ho jinak, nezapomeňte odpovídajícím způsobem upravit kód z příkladů. Od této chvíle se nebudeme řídit shora dolů, ale zdola nahoru: tedy nejprve vytvoříme všechny komponenty pipeline a teprve potom samotnou pipeline.

Takže, nejprve…

Úkoly

Vytvoříme pár úloh (tasks), které potom pomohou nasadit aplikaci v rámci našeho pipeline. První úloha – apply_manifests_task – zajišťuje aplikaci YAML souborů Kubernetes-rozsahu (service, deployment a route), které se nachází ve složce k8s naší aplikace. Druhá úloha – update_deployment_task – zajišťuje aktualizaci již nasazeného obrazu na ten, který vytváří náš pipeline.

Nebojte se, pokud to zatím není úplně jasné. Tyto úlohy jsou vlastně něco jako utility, podrobněji se jimi budeme zabývat později. Teď si 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

Pak pomocí příkazu tkn CLI zkontrolujeme, že úlohy byly vytvořeny:

$ tkn task ls

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

Poznámka: Toto jsou lokální úlohy vašeho aktuálního projektu.

Klusterové úlohy Cluster tasks

Klusterové úlohy jsou v podstatě to samé jako jednoduché úlohy. To znamená, že se jedná o opakovaně použitelné kolekce kroků, které se kombinují určitým způsobem při spuštění konkrétní úlohy. Rozdíl spočívá v tom, že klusterová úloha je dostupná kdekoli v rámci klusteru. Abychom viděli seznam klusterových úloh, které se automaticky vytvářejí při přidá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

A nyní vytvoříme dvě klusterové úlohy. První bude generovat obraz S2I a odesílat jej do interního registru OpenShift; druhá – provede sestavení našeho obrazu na základě NGINX, používající jako obsah již sestavenou aplikaci.

Vytváříme a odesíláme obraz

Při vytváření první úlohy si zopakujeme to, co jsme již dělali v předchozím článku o propojených sestaveních. Připomínáme, že jsme použili obraz S2I (ubi8-s2i-web-app), abychom 'sestavili' naši aplikaci, a nakonec jsme získali obraz uložený v interním registru OpenShift. Nyní použijeme tento S2I obraz webové aplikace k vytvoření DockerFile pro naši aplikaci, a poté nasadíme Buildah, abychom provedli skutečné sestavení a poslali získaný obraz do interního registru OpenShift, protože právě to OpenShift dělá, když nasazujete své aplikace pomocí NodeShift.

Ptáte se, odkud jsme to všechno vzali? Z официальной версии official Node.js, jednoduše jsme jej zkopírovali a přizpůsobili si ho.

Tak, a nyní vytvoříme clusterovou úlohu s názvem s2i-web-app:

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

Nebudeme to podrobně rozebírat, pouze se zaměříme na parametr OUTPUT_DIR:

params:
      - name: OUTPUT_DIR
        description: Místo, kde se nachází výstupní adresář sestavení
        default: build

Ve výchozím nastavení má tento parametr hodnotu build, kam React ukládá sestavený obsah. V jiných frameworcích se používají jiné cesty, například v Ember je to dist. Výstup naší první clusterové úlohy bude obraz, který obsahuje HTML, JavaScript a CSS, které jsme sestavili.

Sestavujeme obraz založený na NGINX

Pokud jde o naši druhou clusterovou úlohu, ta by měla sestavovat obraz na základě NGINX s využitím obsahu již sestavené aplikace. V podstatě jde o tu část předchozího oddílu, kde jsme se zabývali propojenými sestaveními.

K tomu – přesně tak, jak jsme to udělali výše – vytvoříme clusterovou ú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 těchto clusterových úloh, uvidíte, že tam není konkretizováno Git repozitář, se kterým pracujeme, nebo názvy obrazů, které vytváříme. Určujeme pouze, co skutečně předáváme do Gitu, nebo nějaký obraz, kam je třeba vyexportovat výsledný obraz. Právě proto lze tyto clusterové úlohy opětovně použít i při práci s jinými aplikacemi.

A zde elegantně přecházíme k dalšímu bodu…

Zdroje

Takže, jak jsme právě řekli, clusteringové úkoly by měly být co nejvíce obecné. Musíme vytvořit zdroje, které budou použity na vstupu (Git repozitář) a na výstupu (konečné obrazy). Prvním zdrojem, který potřebujeme, je Git, kde se nachází naše aplikace, něco jako toto:

# 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 má PipelineResource typ git. Klíč url v sekci params ukazuje na konkrétní repozitář a nastavuje větev master (to je volitelné, ale píšeme to pro kompletnost).

Nyní musíme vytvořit zdroj pro obraz, kam budou ukládány výsledky vykonání úkolu s2i-web-app, dělá se 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

Zde má PipelineResource typ image a hodnota parametru url ukazuje na interní OpenShift Image Registry, konkrétně na ten, který se nachází v prostoru webapp-pipeline. Nezapomeňte změnit tento parametr, pokud používáte jiný prostor.

A konečně, poslední zdroj, který budeme potřebovat, bude také mít typ image a to bude konečný obraz NGINX, který bude použit při 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

Opět si dejte pozor, že tento zdroj ukládá obraz do interního registru OpenShift ve jmenném prostoru webapp-pipeline.

Abychom mohli vytvořit všechny tyto zdroje najednou, použijeme příkaz create:

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

Možné ověřit, že byly zdroje vytvořeny, lze takto:

$ tkn resource ls

Pipeline

Teď, když máme všechny potřebné komponenty, složíme z nich pipeline tímto příkazem:

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

Ale než spustíme tento příkaz, podívejme se na tyto komponenty. Prvním je název:

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

Poté v sekci spec vidíme urč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é vytváříme úkoly, které musí náš pipeline splnit. Nejdříve musí vykonat námi již vytvořený úkol s2i-web-app:

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

Tento úkol bere vstupní (gir-zdroj) a výstupní (zdroj built-web-application-image) parametry. Také jí předáváme speciální parametr, aby neověřovala TLS, protože používáme self-signed certifikáty:

resources:
        inputs:
          - name: source
            resource: web-application-repo
        outputs:
          - name: image
            resource: built-web-application-image
      params:
        - name: TLSVERIFY
          value: "false"

Další úkol je téměř stejný, jen zde se volá již vytvořený clusterový úkol webapp-build-runtime:

name: build-runtime-image
    taskRef:
      name: webapp-build-runtime
      kind: ClusterTask

Stejně jako u předchozího úkolu předáváme zdroj, ale nyní je to built-web-application-image (výstup našeho předchozího úkolu). A jako výstup opět definujeme obraz. Protože tento úkol musí být proveden po předchozím, 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

Následující dvě úkoly odpovídají za aplikaci YAML souborů služby, trasy a nasazení, které se nacházejí v adresáři k8s našeho webové aplikace, a také za aktualizaci tohoto nasazení při vytváření nových obrazů. Tyto dvě clusterové úkoly jsme definovali na začátku článku.

Spuštění kanálového zpracování

Takže všechny části našeho pipeline jsou vytvořeny a spustíme ji následujícím příkazem:

$ tkn pipeline start build-and-deploy-react

V této fázi se příkazový řádek používá v interaktivním režimu a je třeba vybírat odpovídající zdroje v odpovědi na každý jeho dotaz: pro zdroj git vybereme web-application-repo, poté pro zdroj prvního obrazu – built-web-application-image, a nakonec pro zdroj druhého obrazu – 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 pipeline pomocí následujícího příkazu:

$ tkn pipeline logs -f

Poté, co pipeline spustí a aplikace se nasadí, požádáme o zveřejněnou trasu následujícím příkazem:

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

Pro lepší vizualizaci můžeme podívat na naši pipeline v režimu Developer webové konzole v sekci Pipeline, jak je znázorněno na Obr. 1.

Obr.1. Přehled spuštěných pipeline.

Kliknutím na spuštěnou pipeline se zobrazí další informace, jak je znázorněno na Obr.2.

Obr. 2. Další informace o pipeline.

Po dalších informacích si můžeme prohlédnout spuštěné aplikace ve zobrazení Topology, jak je znázorněno na Obr.3.

Obr 3. Spuštěný pod.

Kliknutím na kruhovou ikonu v pravém horním rohu ikony otevře naši aplikaci, jak je znázorněno na Obr.4.

Obr. 4. Spuštěná aplikace React.

Závěr

Takže jsme ukázali, jak spustit na OpenShift vývojový server pro svou aplikaci a synchronizovat jej s místním souborovým systémem. Také jsme se podívali, jak simulovat chained-build template pomocí OpenShift Pipelines. Všechny kódy příkladů z tohoto článku najdete zde.