Salute à tutti nantu à stu blog ! Questu hè u terzu post in una serie in quale vi mostramu cumu implementà l'applicazioni web muderni nantu à Red Hat OpenShift.
In i dui posti precedenti, avemu dimustratu cumu implementà l'applicazioni web muderne in pochi passi è cumu utilizà una nova maghjina S2I cù una maghjina di u servitore HTTP off-the-shelf, cum'è NGINX, utilizendu custruzzioni incatenati per orchestrate implementazioni di produzzione. .
Oghje vi mustraremu cumu eseguisce un servitore di sviluppu per a vostra applicazione nantu à a piattaforma OpenShift è sincronizà cù u sistema di fugliale locale, è parlemu ancu di ciò chì OpenShift Pipelines sò è cumu si ponu esse utilizati com'è una alternativa à l'assemblee ligati.
OpenShift cum'è un ambiente di sviluppu
U flussu di travagliu di sviluppu
Cum'è digià dichjaratu in , U prucessu tipicu di sviluppu per l'applicazioni web muderni hè simplicemente un tipu di "servitore di sviluppu" chì traccia i cambiamenti à i schedarii lucali. Quandu si verificanu, a creazione di l'applicazione hè attivata è dopu hè aghjurnata à u navigatore.
In a maiò parte di i quadri muderni, un tali "servitore di sviluppu" hè custruitu in l'arnesi di linea di cummanda adattati.
Esempiu lucale
Prima, andemu à vede cumu si travaglia in u casu di eseguisce applicazioni in u locu. Pigliemu una applicazione cum'è un esempiu. da l'articuli precedenti, anche se quasi i stessi cuncetti di flussu di travagliu si applicanu in tutti l'altri quadri muderni.
Allora, per inizià u "servitore di sviluppu" in u nostru esempiu React, scriveremu u cumandimu seguente:
$ npm run start
Allora in a finestra di u terminal, vedemu qualcosa cum'è questu:
È a nostra applicazione si apre in u navigatore predeterminatu:
Avà, se facemu cambiamenti à u schedariu, l'applicazione deve rinfriscà in u navigatore.
OK, tuttu hè chjaru cù u sviluppu in modu lucale, ma cumu per ottene u stessu nantu à OpenShift?
Servitore di sviluppu nantu à OpenShift
Se vi ricordate, in , Fighjemu à a chjamata fase di run di l'imaghjini S2I è hà vistu chì per automaticamente, u modulu di serve hè rispunsevule per u serviziu di a nostra applicazione web.
Tuttavia, s'è vo fate un ochju più vicinu da quellu esempiu, allora hà a variabile d'ambiente $ NPM_RUN, chì permette di eseguisce u vostru propiu cumandamentu.
Per esempiu, pudemu usà u modulu di nodeshift per implementà a nostra applicazione:
$ npx nodeshift --deploy.env NPM_RUN="yarn start" --dockerImage=nodeshift/ubi8-s2i-web-app
Nota: L'esempiu supra hè abbreviatu per illustrà l'idea generale.
Quì, avemu aghjustatu a variabile d'ambiente NPM_RUN à a nostra implementazione, chì dice à u runtime per eseguisce u cumandamentu di partenza di filatu, chì principia u servitore di sviluppu React in u nostru pod OpenShift.
Se guardate u logu di un pod in esecuzione, allora ci sarà qualcosa cum'è questu:
Di sicuru, tuttu questu ùn serà nunda finu à chì pudemu sincronizà u codice lucale cù u codice, chì hè ancu monitoratu per i cambiamenti, ma vive in un servitore remotu.
Sincronizazione di u codice lucale è lucale
Fortunatamente, nodeshift pò aiutà facilmente cù a sincronizazione, è pudete aduprà u cumandamentu di watch per seguità i cambiamenti.
Allora dopu avè eseguitu u cumandamentu per implementà u servitore di sviluppu per a nostra applicazione, pudemu aduprà in modu sicuru u cumandimu seguente:
$ npx nodeshift watch
In u risultatu, una cunnessione serà fatta à u pod in esecuzione chì avemu creatu un pocu prima, a sincronizazione di i nostri fugliali lucali cù u cluster remota serà attivata, è i schedari nantu à u nostru sistema lucale cumincianu à esse monitoratu per i cambiamenti.
Dunque, se avemu avà aghjurnatu u schedariu src/App.js, u sistema reagisce à questi cambiamenti, copià à u cluster remoto è principià u servore di sviluppu, chì poi aghjurnà a nostra applicazione in u navigatore.
Per compie a stampa, mustramu ciò chì sò questi cumandamenti in tuttu:
$ 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
U cumandamentu di watch hè una astrazione in cima à u cumandamentu oc rsync, pudete amparà più nantu à cumu funziona. .
Questu era un esempiu per React, ma u stessu metudu exactu pò esse usatu cù altri frameworks, basta stabilisce a variabile di l'ambiente NPM_RUN quantu necessariu.
Openshift Pipelines
In seguitu, parlemu di un strumentu cum'è OpenShift Pipelines è cumu si pò esse usatu cum'è una alternativa à e custruzzioni incatenati.
Cosa sò OpenShift Pipelines
OpenShift Pipelines hè un sistema d'integrazione è di consegna cuntinuu CI / CD nativu in nuvola cuncepitu per urganizà pipeline cù Tekton. Tekton hè un framework CI / CD nativu di Kubernetes open-source flexible chì permette di automatizà l'implementazione in diverse piattaforme (Kubernetes, serverless, virtual machines, etc.) astrattendu da a capa sottostante.
Capisce stu articulu richiede una certa cunniscenza di Pipelines, cusì vi cunsigliemu fermamente di leghje prima .
Configurazione di u vostru ambiente di travagliu
Per ghjucà cù l'esempii in questu articulu, avete prima bisognu di preparà u vostru ambiente di travagliu:
- Installa è cunfigurà un cluster OpenShift 4. I nostri esempi utilizanu CodeReady Containers (CRD) per questu, struzzioni di installazione per quale si ponu truvà .
- Dopu chì u cluster hè prontu, avete bisognu di stallà u Pipeline Operator nantu à questu. Ùn àbbia paura, hè facile, struzzioni di stallazione .
- Scaricà (tkn) .
- Eseguite u strumentu di linea di cummanda create-react-app per creà una applicazione chì poi implementerà (questa hè una applicazione simplice ).
- (Opcional) Clone u repository per eseguisce l'app di mostra in u locu cù npm install è poi npm start.
U repositoriu di l'applicazioni avarà ancu un cartulare k8s, chì cuntene i YAML Kubernetes / OpenShift utilizati per implementà l'applicazione. Ci saranu Tasks, ClusterTasks, Risorse è Pipelines chì creeremu in questu .
Cuminciamu
U primu passu per u nostru esempiu hè di creà un novu prughjettu in u cluster OpenShift. Chjamemu stu prughjettu webapp-pipeline è creanu cù u cumandimu seguitu:
$ oc new-project webapp-pipeline
Stu nome di u prugettu appariscerà in u codice più tardi, perchè se decide di chjamà un altru, ùn vi scurdate di edità u codice di esempiu in cunseguenza. Partendu da questu puntu, ùn andemu micca in cima, ma in u fondu: vale à dì, prima crearemu tutti i cumpunenti di u trasportatore, è solu dopu u trasportatore stessu.
Allora, prima di tuttu...
I compiti
Creemu un coppiu di compiti (tasks), chì poi aiuteranu à implementà l'applicazione in u nostru pipeline di pipeline. U primu compitu, apply_manifests_task, hè rispunsevule per applicà u YAML di quelli risorse Kubernetes (serviziu, implementazione è rotta) chì si trovanu in u cartulare k8s di a nostra applicazione. U secondu compitu - update_deployment_task - hè rispunsevule per aghjurnà una maghjina digià implementata à quella creata da a nostra pipeline.
Ùn vi preoccupate micca s'ellu ùn hè ancu assai chjaru. In fatti, sti compiti sò quarchi cosa cum'è utilità, è l'avemu guardatu in più detail un pocu dopu. Per avà, creemu solu:
$ 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
Allora, utilizendu u cumandimu tkn CLI, verificate chì i travaglii sò stati creati:
$ tkn task ls
NAME AGE
apply-manifests 1 minute ago
update-deployment 1 minute ago
Nota: Quessi sò i travaglii lucali per u vostru prughjettu attuale.
Cumpete di cluster
I compiti di cluster sò basicamente listessi cum'è i compiti solu. Vale à dì, hè una cullizzioni reutilizabile di passi chì sò cumminati in un modu o un altru quandu un compitu particulari hè lanciatu. A diferenza hè chì u compitu di cluster hè dispunibule in ogni locu in u cluster. Per vede a lista di e cumpetenze di cluster chì sò creati automaticamente quandu un Operatore di Pipeline hè aghjuntu, utilizate u cumandimu tkn CLI di novu:
$ 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
Avà criemu dui compiti di cluster. U primu generà una maghjina S2I è u mandarà à u registru internu OpenShift; u sicondu hè di custruisce a nostra imagina basata in NGINX, utilizendu l'applicazione chì avemu digià custruitu cum'è cuntenutu.
Crea è mandate una maghjina
Quandu creanu u primu compitu, ripetemu ciò chì avemu digià fattu in l'articulu precedente nantu à l'assemblee ligati. Ricurdativi chì avemu usatu l'imaghjini S2I (ubi8-s2i-web-app) per "custruì" a nostra applicazione, è finisci cù una maghjina guardata in u registru internu OpenShift. Ora useremu questa maghjina di l'applicazione web S2I per creà un DockerFile per a nostra applicazione, è dopu aduprà Buildah per custruisce in realtà è spinghje l'imaghjina resultanti à u registru internu OpenShift, perchè questu hè esattamente ciò chì OpenShift faci quandu implementate e vostre applicazioni cù NodeShift.
Cumu sapemu tuttu questu, dumandate ? Da , avemu appena copiatu è finitu per noi.
Allora, ora creemu u compitu di cluster s2i-web-app:
$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/clustertasks/s2i-web-app-task.yaml
Ùn analizzeremu micca questu in dettagliu, ma ci concentreremu solu nantu à u paràmetru OUTPUT_DIR:
params:
- name: OUTPUT_DIR
description: The location of the build output directory
default: build
Per automaticamente, stu paràmetru hè uguali à custruisce, chì hè induve React mette u cuntenutu assemblatu. Altri frameworks usanu strade diffirenti, per esempiu, in Ember hè dist. L'output di u nostru primu compitu di cluster serà una maghjina chì cuntene l'HTML, JavaScript è CSS chì avemu cullatu.
Custruite una maghjina basatu annantu à NGINX
In quantu à u nostru secondu compitu di cluster, deve custruisce una maghjina basata in NGINX per noi utilizendu u cuntenutu di l'applicazione chì avemu digià custruitu. In fatti, questu hè a parte di a sezione precedente induve avemu vistu e custruzzioni incatenati.
Per fà questu, noi - esattamente u listessu cum'è sopra - creeremu un compitu di cluster webapp-build-runtime:
$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/clustertasks/webapp-build-runtime-task.yaml
Se fighjate à u codice di questi compiti di cluster, pudete vede chì ùn specifica micca u repository Git chì avemu travagliatu o i nomi di l'imaghjini chì avemu criatu. Specificemu solu ciò chì esattamente trasferemu à Git, o una certa maghjina induve l'imaghjini finali deve esse uscita. Hè per quessa chì questi compiti di cluster ponu esse riutilizzati quandu travaglianu cù altre applicazioni.
E poi passemu cun grazia à u puntu dopu ...
Risorse
Allora, postu chì, cum'è l'avemu dettu, i compiti di cluster deve esse u più genericu pussibule, avemu bisognu di creà risorse chì seranu utilizati in l'input (repository Git) è output (imaghjini finali). A prima risorsa chì avemu bisognu hè Git, induve a nostra applicazione reside, qualcosa cum'è questu:
# 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
Quì PipelineResource hè di tipu git. A chjave di l'url in a seccione params punta à un repositoriu specificu è stabilisce a ramu maestru (questu hè facultativu, ma l'avemu scrivite per completezza).
Avà avemu bisognu di creà una risorsa per l'imaghjini, induve i risultati di u travagliu s2i-web-app seranu salvati, questu hè fattu cusì:
# 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
Quì, u PipelineResource hè di tipu image, è u valore di u paràmetru url punta à u Registru internu di l'Image OpenShift, in particulare quellu in u webapp-pipeline namespace. Ricurdativi di cambià sta paràmetra se aduprate un spaziu di nomi diversu.
È infine, l'ultima risorsa chì avemu bisognu serà ancu di tippu image, è questu serà l'imagine finale NGINX, chì serà dopu aduprata durante a implementazione:
# 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
In novu, nutate chì sta risorsa guarda l'imaghjini in u registru internu OpenShift in u webapp-pipeline namespace.
Per creà tutte queste risorse in una volta, usemu u cumandamentu di creazione:
$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/resources/resource.yaml
Per assicurà chì e risorse sò state create, pudete fà questu:
$ tkn resource ls
Pipeline di trasportatore
Avà chì avemu tutti i cumpunenti necessarii, assembleremu un pipeline da elli creendu cù u cumandimu seguente:
$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/pipelines/build-and-deploy-react.yaml
Ma prima di eseguisce stu cumandamentu, fighjemu un ochju à sti cumpunenti. U primu hè u nome:
apiVersion: tekton.dev/v1alpha1
kind: Pipeline
metadata:
name: build-and-deploy-react
Allora, in a sezione spec, vedemu una indicazione di e risorse chì avemu creatu prima:
spec:
resources:
- name: web-application-repo
type: git
- name: built-web-application-image
type: image
- name: runtime-web-application-image
type: image
Dopu creemu i travaglii per u nostru pipeline per eseguisce. Prima di tuttu, deve eseguisce u compitu s2i-web-app chì avemu digià creatu:
tasks:
- name: build-web-application
taskRef:
name: s2i-web-app
kind: ClusterTask
Stu compitu piglia paràmetri di input (risorsa gir) è output (risorsa web-applicazione-imagine). Passemu ancu un paràmetru speciale in modu chì ùn verifica micca TLS postu chì usemu certificati autofirmati:
resources:
inputs:
- name: source
resource: web-application-repo
outputs:
- name: image
resource: built-web-application-image
params:
- name: TLSVERIFY
value: "false"
U prossimu compitu hè quasi u listessu, solu quì u compitu di cluster webapp-build-runtime chì avemu digià creatu hè chjamatu:
name: build-runtime-image
taskRef:
name: webapp-build-runtime
kind: ClusterTask
Cum'è cù u compitu precedente, passemu in una risorsa, ma avà hè custruitu-web-application-image (l'output di u nostru compitu precedente). È cum'è una output avemu torna stabilitu l'imaghjini. Siccomu questu compitu deve esse realizatu dopu à u precedente, aghjunghjemu u campu 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
I seguenti dui compiti sò rispunsevuli di applicà i schedari YAML di serviziu, rotta è implementazione chì campanu in u repertoriu k8s di a nostra applicazione web, è per aghjurnà sta implementazione quandu sò creati novi imagine. Avemu stabilitu sti dui compiti di cluster à u principiu di l'articulu.
Cumincià u trasportatore
Dunque, tutte e parte di u nostru pipeline sò creati, è l'avemu eseguitu cù u cumandimu seguente:
$ tkn pipeline start build-and-deploy-react
In questa fase, a linea di cumanda hè aduprata in modu interattivu è avete bisognu di selezziunà i risorsi adattati in risposta à ognuna di e so dumande: per a risorsa git, selezziunate web-application-repo, dopu per a prima risorsa d'imaghjini, built-web-application. -image, è infine, per a seconda risorsa di l'imagine -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
Avà verificate u statutu di u pipeline cù u cumandimu seguitu:
$ tkn pipeline logs -f
Una volta chì u pipeline hà iniziatu è l'applicazione hè stata implementata, pudemu dumandà a strada publicata cù u cumandimu seguente:
$ oc get route react-pipeline-example --template='http://{{.spec.host}}'
Per una visualizazione più grande, pudete vede a nostra pipeline in u Modu Sviluppatore di a cunsola web in a sezione Pipelines, cum'è mostra in Fig. 1.
Fig.1. Panoramica di i pipelines in esecuzione.
Cliccà nantu à una pipeline in esecuzione mostra dettagli supplementari, cum'è mostra in Figura 2.
Risu. 2. Informazioni supplementari nantu à u trasportatore.
Dopu più infurmazione, pudete vede l'applicazioni in esecuzione in a vista supratuttu, cum'è mostra in Fig.3.
Fig 3. Corsa pod.
Cliccà nant'à u circhiu in u cantonu supiriuri dritta di l 'icona apre a nostra dumanda, cum'è mostra in Fig.
Risu. 4. Running dumanda React.
cunchiusioni
Dunque, avemu dimustratu cumu fà un servitore di sviluppu per a vostra applicazione in OpenShift è sincronizà cù u sistema di fugliale locale. Avemu vistu ancu cumu simulà un mudellu di custruzzione in catena cù OpenShift Pipelines. Tutti i codici esempi da stu articulu ponu esse truvati .
Ressources additionnelles (FR)
- eBook gratuitu
- Altri articuli nantu à nant'à u situ web di Red Hat
L'annunzii di i webinars futuri
Cumincemu una seria di webinars di u venneri nantu à l'esperienza nativa cù Red Hat OpenShift Container Platform è Kubernetes:
Source: www.habr.com