Hola a tots en aquest blog! Aquesta és la tercera publicació d'una sèrie en què us mostrem com implementar aplicacions web modernes a Red Hat OpenShift.
A les dues publicacions anteriors, hem tractat com implementar aplicacions web modernes en només uns quants passos i com utilitzar una nova imatge S2I juntament amb una imatge de servidor HTTP preconstruïda com NGINX mitjançant compilacions encadenades per al desplegament de producció.
Avui us mostrarem com executar un servidor de desenvolupament per a la vostra aplicació a la plataforma OpenShift i sincronitzar-lo amb el sistema de fitxers local, així com parlarem sobre què són OpenShift Pipelines i com es poden utilitzar com a alternativa als assemblatges enllaçats.
OpenShift com a entorn de desenvolupament
flux de treball de desenvolupament
Com ja s'ha dit a , el procés de desenvolupament típic de les aplicacions web modernes és simplement un "servidor de desenvolupament" que fa un seguiment dels canvis als fitxers locals. Quan succeeixen, s'activa la creació de l'aplicació i després s'actualitza al navegador.
A la majoria de marcs moderns, aquest "servidor de desenvolupament" està integrat a les eines de línia d'ordres adequades.
Exemple local
Primer, vegem com funciona en el cas d'executar aplicacions localment. Prenem com a exemple una aplicació. dels articles anteriors, encara que gairebé els mateixos conceptes de flux de treball s'apliquen a tots els altres marcs moderns.
Per tant, per iniciar el "servidor de desenvolupament" al nostre exemple de React, escriurem l'ordre següent:
$ npm run start
Aleshores a la finestra del terminal veurem alguna cosa com això:
I la nostra aplicació s'obrirà al navegador predeterminat:
Ara, si fem canvis al fitxer, l'aplicació s'hauria d'actualitzar al navegador.
D'acord, amb el desenvolupament en mode local, tot està clar, però com aconseguir el mateix a OpenShift?
Servidor de desenvolupament a OpenShift
Si recordeu a , vam analitzar l'anomenada fase d'execució (fase d'execució) de la imatge S2I i vam veure que, per defecte, la nostra aplicació web està servida pel mòdul de servei.
Tanmateix, si mireu més de prop d'aquest exemple, té la variable d'entorn $NPM_RUN, que us permet executar la vostra pròpia ordre.
Per exemple, podem utilitzar el mòdul nodeshift per desplegar la nostra aplicació:
$ npx nodeshift --deploy.env NPM_RUN="yarn start" --dockerImage=nodeshift/ubi8-s2i-web-app
Nota: l'exemple anterior està abreujat per il·lustrar la idea general.
Aquí, hem afegit la variable d'entorn NPM_RUN al nostre desplegament, que indica al temps d'execució que executi l'ordre d'inici de fil, que inicia el servidor de desenvolupament React dins del nostre pod OpenShift.
Si mireu el registre d'un pod en execució, hi haurà alguna cosa com això:
Per descomptat, tot això no serà res fins que no puguem sincronitzar el codi local amb el codi, que també es controla per als canvis, però viu en un servidor remot.
Sincronització de codi local i remot
Afortunadament, nodeshift pot ajudar fàcilment amb la sincronització i podeu utilitzar l'ordre watch per fer un seguiment dels canvis.
Així, després d'executar l'ordre per desplegar el servidor de desenvolupament per a la nostra aplicació, podem utilitzar aquesta comanda amb seguretat:
$ npx nodeshift watch
Com a resultat, es connectarà al pod en execució que hem creat una mica abans, s'activarà la sincronització dels nostres fitxers locals amb el clúster remot i es començarà a supervisar els fitxers del nostre sistema local per detectar canvis.
Per tant, si ara actualitzem el fitxer src/App.js, el sistema reaccionarà a aquests canvis, els copiarà al clúster remot i iniciarà el servidor de desenvolupament, que després actualitzarà la nostra aplicació al navegador.
Per completar la imatge, mostrem com són aquestes ordres en la seva totalitat:
$ 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
L'ordre watch és una abstracció a la part superior de l'ordre oc rsync, podeu obtenir més informació sobre com funciona. .
Aquest va ser un exemple per a React, però es pot utilitzar exactament el mateix mètode amb altres marcs, només cal que configureu la variable d'entorn NPM_RUN segons sigui necessari.
Openshift Pipelines
A continuació, parlarem d'una eina com OpenShift Pipelines i de com es pot utilitzar com a alternativa a les compilacions encadenades.
Què és OpenShift Pipelines
OpenShift Pipelines és un sistema de lliurament i integració contínua CI/CD basat en núvol per a canonades que utilitzen Tekton. Tekton és un marc CI/CD natiu de Kubernetes de codi obert flexible que automatitza el desplegament en múltiples plataformes (Kubernetes, sense servidor, màquines virtuals, etc.) abstraint-se de la capa subjacent.
Entendre aquest article requereix un cert coneixement de Pipelines, per la qual cosa us recomanem que primer llegiu .
Configuració de l'entorn de treball
Per jugar amb els exemples d'aquest article, primer heu de configurar un entorn de treball:
- Instal·leu i configureu un clúster OpenShift 4. Els nostres exemples utilitzen CodeReady Containers (CRD) per a això, les instruccions d'instal·lació dels quals es poden trobar .
- Quan el clúster estigui llest, cal que hi instal·leu l'operador de pipeline. No tingueu por, és fàcil, instruccions d'instal·lació .
- descarregar (tkn) .
- Executeu l'eina de línia d'ordres create-react-app per crear una aplicació que després es desplegarà (aquesta és una aplicació senzilla ).
- (Opcional) Cloneu el dipòsit per executar l'aplicació d'exemple localment amb npm install i després npm start.
El repositori d'aplicacions també tindrà una carpeta k8s, que contindrà els YAML Kubernetes/OpenShift utilitzats per desplegar l'aplicació. Hi haurà Tasks, ClusterTasks, Recursos i Pipelines que crearem en aquest .
Començant
El primer pas del nostre exemple és crear un nou projecte al clúster OpenShift. Anomenem aquest projecte webapp-pipeline i creem-lo amb l'ordre següent:
$ oc new-project webapp-pipeline
Més tard, aquest nom del projecte apareixerà al codi, de manera que si decidiu posar-li un altre nom, no us oblideu d'editar el codi dels exemples en conseqüència. A partir d'aquest punt, no anirem de dalt a baix, sinó de baix a dalt: és a dir, primer crearem tots els components del transportador, i només després ell mateix.
Per tant, primer de tot…
Tasques
Creem un parell de tasques (tasques), que després ajudaran a desplegar l'aplicació dins del nostre pipeline. La primera tasca, apply_manifests_task, s'encarrega d'aplicar el YAML d'aquells recursos de Kubernetes (servei, desplegament i ruta) que es troben a la carpeta k8s de la nostra aplicació. La segona tasca - update_deployment_task - s'encarrega d'actualitzar una imatge ja desplegada a la creada pel nostre pipeline.
No et preocupis si encara no està molt clar. De fet, aquestes tasques són una cosa semblant a les utilitats, i les analitzarem amb més detall una mica més endavant. De moment, anem a crear-los:
$ 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
A continuació, mitjançant l'ordre tkn CLI, comproveu que les tasques s'han creat:
$ tkn task ls
NAME AGE
apply-manifests 1 minute ago
update-deployment 1 minute ago
Nota: aquestes són tasques locals per al vostre projecte actual.
Tasques de clúster
Les tasques de clúster són bàsicament les mateixes que només les tasques. És a dir, és una col·lecció reutilitzable de passos que es combinen d'una manera o altra quan s'inicia una tasca concreta. La diferència és que la tasca del clúster està disponible a tot arreu del clúster. Per veure la llista de tasques de clúster que es creen automàticament quan s'afegeix un operador de pipeline, torneu a utilitzar l'ordre CLI tkn:
$ 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
Ara creem dues tasques de clúster. El primer generarà una imatge S2I i l'enviarà al registre intern d'OpenShift; el segon és construir la nostra imatge basada en NGINX utilitzant l'aplicació que ja hem creat com a contingut.
Crear i enviar una imatge
En crear la primera tasca, repetirem el que ja vam fer a l'article anterior sobre els assemblatges enllaçats. Recordem que vam utilitzar la imatge S2I (ubi8-s2i-web-app) per "crear" la nostra aplicació i vam acabar amb una imatge emmagatzemada al registre intern d'OpenShift. Ara utilitzarem aquesta imatge de l'aplicació web S2I per crear un DockerFile per a la nostra aplicació i després utilitzarem Buildah per crear i enviar la imatge resultant al registre intern d'OpenShift, ja que això és exactament el que fa OpenShift quan desplegueu les vostres aplicacions amb NodeShift.
Com ho sabem tot això, et preguntes? Des de , l'acabem de copiar i l'hem acabat per nosaltres mateixos.
Per tant, ara creem la tasca del clúster s2i-web-app:
$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/clustertasks/s2i-web-app-task.yaml
No analitzarem això en detall, sinó que només ens detenem en el paràmetre OUTPUT_DIR:
params:
- name: OUTPUT_DIR
description: The location of the build output directory
default: build
Per defecte, aquest paràmetre és build, que és on React posa el contingut construït. Altres frameworks utilitzen camins diferents, per exemple a Ember és dist. La sortida de la nostra primera tasca de clúster serà una imatge que conté l'HTML, JavaScript i CSS que hem recollit.
Construïm una imatge basada en NGINX
Pel que fa a la nostra segona tasca de clúster, hauria de crear una imatge basada en NGINX utilitzant el contingut de l'aplicació que ja hem construït. De fet, aquesta és la part de la secció anterior on vam analitzar les compilacions encadenades.
Per fer-ho, de la mateixa manera que una mica més amunt, crearem una tasca de clúster en temps d'execució d'aplicació web:
$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/clustertasks/webapp-build-runtime-task.yaml
Si mireu el codi d'aquestes tasques de clúster, podeu veure que no especifica el repositori Git amb el qual estem treballant, ni els noms de les imatges que estem creant. Només especifiquem què passem exactament a Git, o alguna imatge on volem sortir la imatge final. És per això que aquestes tasques agrupades es poden reutilitzar quan es treballa amb altres aplicacions.
I després passem amb gràcia al següent punt...
Recursos
Per tant, com que, com acabem de dir, les tasques de clúster han de ser el més genèriques possible, hem de crear recursos que s'utilitzaran a l'entrada (repositori Git) i a la sortida (imatges finals). El primer recurs que necessitem és Git, on resideix la nostra aplicació, una cosa així:
# 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
Aquí PipelineResource és de tipus git. La clau d'url de la secció de paràmetres apunta a un repositori específic i estableix la branca mestra (això és opcional, però ho escrivim per completar-ho).
Ara hem de crear un recurs per a la imatge, on es desaran els resultats de la tasca s2i-web-app, això es fa de la següent manera:
# 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
Aquí, el PipelineResource és de tipus imatge i el valor del paràmetre d'URL apunta al registre d'imatges intern d'OpenShift, concretament el de l'espai de noms webapp-pipeline. Recordeu canviar aquesta configuració si feu servir un espai de noms diferent.
I finalment, l'últim recurs que necessitarem també serà de tipus imatge, i aquesta serà la imatge NGINX final, que després s'utilitzarà durant el desplegament:
# 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
De nou, tingueu en compte que aquest recurs emmagatzema la imatge al registre intern d'OpenShift a l'espai de noms webapp-pipeline.
Per crear tots aquests recursos alhora, fem servir l'ordre create:
$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/resources/resource.yaml
Per assegurar-vos que els recursos s'han creat, podeu fer això:
$ tkn resource ls
canonada
Ara que tenim tots els components necessaris, muntarem un pipeline a partir d'ells creant-lo amb l'ordre següent:
$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/pipelines/build-and-deploy-react.yaml
Però abans d'executar aquesta ordre, fem una ullada a aquests components. El primer és el nom:
apiVersion: tekton.dev/v1alpha1
kind: Pipeline
metadata:
name: build-and-deploy-react
A continuació, a la secció d'especificacions, veiem una indicació dels recursos que hem creat anteriorment:
spec:
resources:
- name: web-application-repo
type: git
- name: built-web-application-image
type: image
- name: runtime-web-application-image
type: image
Aleshores creem tasques perquè s'executi el nostre pipeline. En primer lloc, ha d'executar la tasca s2i-web-app que ja hem creat:
tasks:
- name: build-web-application
taskRef:
name: s2i-web-app
kind: ClusterTask
Aquesta tasca pren paràmetres d'entrada (recurs gir) i de sortida (recurs d'imatge d'aplicació web integrada). També li passem un paràmetre especial perquè no verifiqui TLS ja que estem utilitzant certificats autofirmats:
resources:
inputs:
- name: source
resource: web-application-repo
outputs:
- name: image
resource: built-web-application-image
params:
- name: TLSVERIFY
value: "false"
La següent tasca és gairebé la mateixa, només aquí s'anomena la tasca del clúster webapp-build-runtime que ja hem creat:
name: build-runtime-image
taskRef:
name: webapp-build-runtime
kind: ClusterTask
Igual que amb la tasca anterior, estem passant un recurs, però ara és una imatge-aplicació-web integrada (la sortida de la nostra tasca anterior). I com a conclusió, tornem a posar la imatge. Com que aquesta tasca s'ha de realitzar després de l'anterior, afegim el camp 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
Les dues tasques següents s'encarreguen d'aplicar els fitxers YAML del servei, la ruta i el desplegament que es troben al directori k8s de la nostra aplicació web i d'actualitzar aquest desplegament quan es creen imatges noves. Hem establert aquestes dues tasques de clúster al principi de l'article.
Execució de la canonada
Per tant, es creen totes les parts del nostre pipeline i l'iniciarem amb l'ordre següent:
$ tkn pipeline start build-and-deploy-react
En aquest punt, la línia d'ordres s'utilitza de manera interactiva i s'han de seleccionar els recursos adequats en resposta a cadascuna de les seves sol·licituds: per al recurs git, seleccioneu web-application-repo, i per al primer recurs d'imatge, built-web-application- imatge i, finalment, per al segon recurs d'imatge –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
Ara comproveu l'estat de la canalització amb l'ordre següent:
$ tkn pipeline logs -f
Un cop s'iniciï la canalització i s'hagi desplegat l'aplicació, consulteu la ruta publicada amb l'ordre següent:
$ oc get route react-pipeline-example --template='http://{{.spec.host}}'
Per a una major visibilitat, podeu veure el nostre pipeline en el mode Desenvolupador de la consola web a la secció Canonadescom es mostra a la Fig. 1.
Fig.1. Visió general de les canonades en funcionament.
Si feu clic a una canalització en execució, es mostren detalls addicionals, tal com es mostra a la figura 2.
Arròs. 2. Informació addicional sobre el transportador.
Després de més detalls, podeu veure les aplicacions en execució a la vista topologia, com es mostra a la Fig.3.
Fig 3. Pod per córrer.
Si feu clic al cercle a la cantonada superior dreta de la icona, s'obre la nostra aplicació, tal com es mostra a la figura 4.
Arròs. 4. Una aplicació React en execució.
Conclusió
Per tant, hem mostrat com executar un servidor de desenvolupament per a la vostra aplicació a OpenShift i sincronitzar-lo amb el sistema de fitxers local. També vam analitzar com simular una plantilla de construcció encadenada mitjançant OpenShift Pipelines. Es poden trobar tots els codis d'exemple d'aquest article .
Recursos addicionals
- Llibre electrònic gratuït
- Altres articles sobre al lloc web de Red Hat
Anuncis dels propers seminaris web
Comencem una sèrie de seminaris web de divendres sobre l'experiència nativa d'utilitzar Red Hat OpenShift Container Platform i Kubernetes:
Font: www.habr.com