Salutare tuturor de pe acest blog! Aceasta este a treia postare dintr-o serie în care arătăm cum să implementăm aplicații web moderne pe Red Hat OpenShift.
În cele două postări anterioare, am arătat cum să implementăm aplicații web moderne în doar câțiva pași și cum să folosim o nouă imagine S2I împreună cu o imagine de server HTTP standard, cum ar fi NGINX, folosind versiuni în lanț pentru a orchestra implementările de producție. .
Astăzi vom arăta cum să rulați un server de dezvoltare pentru aplicația dvs. pe platforma OpenShift și să îl sincronizați cu sistemul de fișiere local și, de asemenea, vom vorbi despre ce sunt OpenShift Pipelines și cum pot fi utilizate ca alternativă la ansamblurile legate.
OpenShift ca mediu de dezvoltare
Flux de lucru de dezvoltare
După cum sa menționat deja în , procesul de dezvoltare tipic pentru aplicațiile web moderne este pur și simplu un fel de „server de dezvoltare” care urmărește modificările aduse fișierelor locale. Când apar, construirea aplicației este declanșată și apoi este actualizată în browser.
În majoritatea cadrelor moderne, un astfel de „server de dezvoltare” este încorporat în instrumentele corespunzătoare din linia de comandă.
Exemplu local
Mai întâi, să vedem cum funcționează acest lucru atunci când rulează aplicații la nivel local. Să luăm aplicația ca exemplu din articolele anterioare, deși aproape aceleași concepte de flux de lucru se aplică în toate celelalte cadre moderne.
Deci, pentru a porni „serverul de dezvoltare” în exemplul nostru React, vom introduce următoarea comandă:
$ npm run start
Apoi, în fereastra terminalului vom vedea ceva de genul acesta:
Și aplicația noastră se va deschide în browserul implicit:
Acum, dacă facem modificări la fișier, aplicația ar trebui să se actualizeze în browser.
OK, totul este clar cu dezvoltarea în modul local, dar cum să obții același lucru pe OpenShift?
Server de dezvoltare pe OpenShift
Dacă vă amintiți, în , ne-am uitat la așa-numita fază de rulare a imaginii S2I și am văzut că implicit, modulul de servire este responsabil pentru deservirea aplicației noastre web.
Cu toate acestea, dacă aruncați o privire mai atentă din acel exemplu, conține variabila de mediu $NPM_RUN, care vă permite să executați comanda.
De exemplu, putem folosi modulul nodeshift pentru a implementa aplicația noastră:
$ npx nodeshift --deploy.env NPM_RUN="yarn start" --dockerImage=nodeshift/ubi8-s2i-web-app
Notă: Exemplul de mai sus este prescurtat pentru a ilustra ideea generală.
Aici am adăugat variabila de mediu NPM_RUN la implementarea noastră, care îi spune timpului de execuție să ruleze comanda yarn start, care pornește serverul de dezvoltare React în interiorul podului nostru OpenShift.
Dacă te uiți la jurnalul unui pod care rulează, va arăta cam așa:
Desigur, toate acestea nu vor fi nimic până când nu vom putea sincroniza codul local cu codul, care este, de asemenea, monitorizat pentru modificări, dar trăiește pe un server la distanță.
Sincronizarea codului de la distanță și local
Din fericire, nodeshift poate ajuta cu ușurință la sincronizare și puteți folosi comanda watch pentru a urmări modificările.
Deci, după ce am rulat comanda pentru a implementa serverul de dezvoltare pentru aplicația noastră, putem folosi în siguranță următoarea comandă:
$ npx nodeshift watch
Ca urmare, se va face o conexiune la podul care rulează pe care l-am creat puțin mai devreme, va fi activată sincronizarea fișierelor noastre locale cu clusterul de la distanță, iar fișierele de pe sistemul nostru local vor începe să fie monitorizate pentru modificări.
Prin urmare, dacă acum actualizăm fișierul src/App.js, sistemul va reacționa la aceste modificări, le va copia în clusterul de la distanță și va porni serverul de dezvoltare, care va actualiza apoi aplicația noastră în browser.
Pentru a completa imaginea, să arătăm cum arată toate aceste comenzi:
$ 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
Comanda watch este o abstractizare deasupra comenzii oc rsync, puteți afla mai multe despre cum funcționează .
Acesta a fost un exemplu pentru React, dar exact aceeași metodă poate fi utilizată cu alte cadre, doar setați variabila de mediu NPM_RUN după cum este necesar.
Openshift Pipelines
În continuare, vom vorbi despre un instrument precum OpenShift Pipelines și despre cum poate fi folosit ca alternativă la build-urile înlănțuite.
Ce sunt OpenShift Pipelines
OpenShift Pipelines este un sistem de integrare și livrare continuă CI/CD nativ în cloud, conceput pentru organizarea conductelor folosind Tekton. Tekton este un cadru CI/CD nativ pentru Kubernetes cu sursă deschisă flexibil, care vă permite să automatizați implementarea pe diverse platforme (Kubernetes, serverless, mașini virtuale etc.) prin abstracția din stratul de bază.
Înțelegerea acestui articol necesită cunoștințe despre Pipelines, așa că vă recomandăm insistent să citiți mai întâi .
Configurarea mediului de lucru
Pentru a vă juca cu exemplele din acest articol, mai întâi trebuie să vă pregătiți mediul de lucru:
- Instalați și configurați un cluster OpenShift 4. Exemplele noastre folosesc CodeReady Containers (CRD) pentru aceasta, instrucțiuni de instalare pentru care pot fi găsite .
- După ce clusterul este gata, trebuie să instalați Pipeline Operator pe el. Nu vă fie teamă, este ușor, instrucțiuni de instalare .
- Descarca (tkn) .
- Rulați instrumentul de linie de comandă create-react-app pentru a crea o aplicație pe care apoi o veți implementa (aceasta este o aplicație simplă ).
- (Opțional) Clonați depozitul pentru a rula aplicația exemplu local cu instalarea npm și apoi pornirea npm.
Depozitul aplicației va avea, de asemenea, un folder k8s, care va conține YAML-urile Kubernetes/OpenShift utilizate pentru implementarea aplicației. Vor exista Sarcini, ClusterTasks, Resurse și Pipelines pe care le vom crea în acest .
Să începem
Primul pas pentru exemplul nostru este să creați un nou proiect în clusterul OpenShift. Să numim acest proiect webapp-pipeline și să-l creăm cu următoarea comandă:
$ oc new-project webapp-pipeline
Acest nume de proiect va apărea în cod mai târziu, așa că dacă decideți să-i denumiți altceva, nu uitați să editați codul exemplu în consecință. Pornind de la acest punct, nu vom merge de sus în jos, ci de jos în sus: adică, vom crea mai întâi toate componentele transportorului și abia apoi transportorul în sine.
Deci, in primul rand...
Sarcini
Să creăm câteva sarcini, care vor ajuta apoi la implementarea aplicației în conducta noastră. Prima sarcină - apply_manifests_task - este responsabilă pentru aplicarea YAML acelor resurse Kubernetes (serviciu, implementare și rută) care se află în folderul k8s al aplicației noastre. A doua sarcină – update_deployment_task – este responsabilă pentru actualizarea unei imagini deja implementate la cea creată de pipeline-ul nostru.
Nu vă faceți griji dacă nu este încă foarte clar. De fapt, aceste sarcini sunt ceva de genul utilităților și le vom analiza mai detaliat puțin mai târziu. Deocamdată, să le creăm:
$ 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
Apoi, folosind comanda tkn CLI, vom verifica dacă sarcinile au fost create:
$ tkn task ls
NAME AGE
apply-manifests 1 minute ago
update-deployment 1 minute ago
Notă: Acestea sunt sarcini locale pentru proiectul dvs. curent.
Sarcini în cluster
Sarcinile cluster sunt practic aceleași cu sarcinile simple. Adică, este o colecție reutilizabilă de pași care sunt combinați într-un fel sau altul atunci când rulează o anumită sarcină. Diferența este că o sarcină de cluster este disponibilă peste tot în cadrul clusterului. Pentru a vedea lista de sarcini de cluster care sunt create automat la adăugarea Pipeline Operator, vom folosi din nou comanda 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
Acum să creăm două sarcini cluster. Primul va genera imaginea S2I și o va trimite la registrul intern OpenShift; al doilea este să ne construim imaginea bazată pe NGINX, folosind aplicația pe care am construit-o deja ca conținut.
Creați și trimiteți imaginea
La crearea primei sarcini, vom repeta ceea ce am făcut deja în articolul anterior despre ansamblurile legate. Amintiți-vă că am folosit imaginea S2I (ubi8-s2i-web-app) pentru a „construi” aplicația noastră și am ajuns cu o imagine stocată în registrul intern OpenShift. Acum vom folosi această imagine a aplicației web S2I pentru a crea un DockerFile pentru aplicația noastră și apoi vom folosi Buildah pentru a face construirea reală și a împinge imaginea rezultată în registrul intern OpenShift, deoarece asta este exact ceea ce face OpenShift când implementați aplicațiile folosind NodeShift. .
De unde știam noi toate astea, te întrebi? Din , doar l-am copiat și l-am modificat pentru noi înșine.
Deci, acum să creăm sarcina cluster s2i-web-app:
$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/clustertasks/s2i-web-app-task.yaml
Nu vom analiza acest lucru în detaliu, ci ne vom concentra doar pe parametrul OUTPUT_DIR:
params:
- name: OUTPUT_DIR
description: The location of the build output directory
default: build
În mod implicit, acest parametru este egal cu build, care este locul în care React plasează conținutul asamblat. Alte cadre folosesc căi diferite, de exemplu, în Ember este dist. Rezultatul primei noastre sarcini de cluster va fi o imagine care conține HTML, JavaScript și CSS pe care le-am colectat.
Creați o imagine bazată pe NGINX
În ceea ce privește a doua noastră sarcină de cluster, ar trebui să construiască o imagine bazată pe NGINX pentru noi, folosind conținutul aplicației pe care am construit-o deja. În esență, aceasta este partea din secțiunea anterioară în care ne-am uitat la versiunile înlănțuite.
Pentru a face acest lucru, noi - exact la fel ca mai sus - vom crea o sarcină de cluster webapp-build-runtime:
$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/clustertasks/webapp-build-runtime-task.yaml
Dacă vă uitați la codul pentru aceste sarcini de cluster, puteți vedea că nu specifică depozitul Git cu care lucrăm sau numele imaginilor pe care le creăm. Specificăm doar ce anume transferăm în Git sau o anumită imagine în care ar trebui să iasă imaginea finală. Acesta este motivul pentru care aceste sarcini de cluster pot fi reutilizate atunci când lucrați cu alte aplicații.
Și aici trecem cu grație la următorul punct...
Ресурсы
Deci, deoarece, așa cum tocmai am spus, sarcinile cluster ar trebui să fie cât mai generale posibil, trebuie să creăm resurse care vor fi folosite ca intrare (depozitul Git) și ca rezultat (imaginile finale). Prima resursă de care avem nevoie este Git, unde se află aplicația noastră, cam așa:
# 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
Aici PipelineResource este de tip git. Cheia URL din secțiunea params indică un anumit depozit și specifică ramura principală (aceasta este opțională, dar o scriem pentru a fi completă).
Acum trebuie să creăm o resursă pentru imaginea în care vor fi salvate rezultatele sarcinii s2i-web-app, acest lucru se face astfel:
# 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
Aici PipelineResource este de tip imagine, iar valoarea parametrului url indică către Registrul de imagini intern OpenShift, în special cel situat în spațiul de nume webapp-pipeline. Nu uitați să schimbați această setare dacă utilizați un spațiu de nume diferit.
Și, în sfârșit, ultima resursă de care avem nevoie va fi, de asemenea, de tip imagine și aceasta va fi imaginea finală NGINX care va fi apoi utilizată în timpul implementării:
# 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
Din nou, rețineți că această resursă stochează imaginea în registrul intern OpenShift în spațiul de nume webapp-pipeline.
Pentru a crea toate aceste resurse simultan, folosim comanda create:
$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/resources/resource.yaml
Vă puteți asigura că resursele au fost create astfel:
$ tkn resource ls
Conducta transportoare
Acum că avem toate componentele necesare, să asamblam o conductă din ele creând-o cu următoarea comandă:
$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/pipelines/build-and-deploy-react.yaml
Dar înainte de a rula această comandă, să ne uităm la aceste componente. Primul este numele:
apiVersion: tekton.dev/v1alpha1
kind: Pipeline
metadata:
name: build-and-deploy-react
Apoi, în secțiunea de specificații, vedem o indicație a resurselor pe care le-am creat mai devreme:
spec:
resources:
- name: web-application-repo
type: git
- name: built-web-application-image
type: image
- name: runtime-web-application-image
type: image
Apoi creăm sarcinile pe care conducta noastră trebuie să le finalizeze. În primul rând, trebuie să execute sarcina s2i-web-app pe care am creat-o deja:
tasks:
- name: build-web-application
taskRef:
name: s2i-web-app
kind: ClusterTask
Această sarcină preia parametrii de intrare (resursa gir) și de ieșire (resursă de imagine-aplicație web construită). De asemenea, îi transmitem un parametru special, astfel încât să nu verifice TLS, deoarece folosim certificate autosemnate:
resources:
inputs:
- name: source
resource: web-application-repo
outputs:
- name: image
resource: built-web-application-image
params:
- name: TLSVERIFY
value: "false"
Următoarea sarcină este aproape aceeași, doar că aici sarcina cluster webapp-build-runtime pe care am creat-o deja se numește:
name: build-runtime-image
taskRef:
name: webapp-build-runtime
kind: ClusterTask
La fel ca în sarcina anterioară, trecem o resursă, dar acum este imaginea-aplicație-web-build (ieșirea sarcinii noastre anterioare). Și ca ieșire setăm din nou imaginea. Deoarece această sarcină trebuie executată după cea anterioară, adăugăm câmpul 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
Următoarele două sarcini sunt responsabile pentru utilizarea fișierelor YAML de serviciu, rută și implementare care se află în directorul k8s al aplicației noastre web și, de asemenea, pentru actualizarea acestei implementări atunci când se creează imagini noi. Am definit aceste două sarcini cluster la începutul articolului.
Pornirea transportorului
Deci, toate părțile conductei noastre sunt create și o vom rula cu următoarea comandă:
$ tkn pipeline start build-and-deploy-react
În această etapă, linia de comandă este utilizată interactiv și trebuie să selectați resursele adecvate ca răspuns la fiecare dintre solicitările sale: pentru resursa git, selectați web-application-repo, apoi pentru prima resursă imagine, built-web-application -imagine și, în sfârșit, pentru a doua resursă de 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
Acum să verificăm starea conductei folosind următoarea comandă:
$ tkn pipeline logs -f
Odată ce conducta a început și aplicația a fost implementată, putem solicita ruta publicată cu următoarea comandă:
$ oc get route react-pipeline-example --template='http://{{.spec.host}}'
Pentru o vizualizare mai bună, puteți vizualiza pipeline-ul nostru în modul Dezvoltator al consolei web din secțiunea Conducte, așa cum se arată în fig. 1.
Fig.1. Revizuirea conductelor în funcțiune.
Făcând clic pe o conductă care rulează, se afișează detalii suplimentare, așa cum se arată în Figura 2.
Orez. 2. Informații suplimentare despre conductă.
După mai multe informații, puteți vedea aplicațiile care rulează în vizualizare Topologie, așa cum se arată în Fig.3.
Fig 3. Pod lansat.
Făcând clic pe cercul din colțul din dreapta sus al pictogramei, se deschide aplicația noastră, așa cum se arată în Fig. 4.
Orez. 4. Rularea aplicației React.
Concluzie
Așadar, am arătat cum să rulați un server de dezvoltare pentru aplicația dvs. pe OpenShift și să îl sincronizați cu sistemul de fișiere local. De asemenea, am analizat cum să simulăm un șablon de construcție înlănțuită folosind OpenShift Pipelines. Toate exemplele de coduri din acest articol pot fi găsite .
Resurse suplimentare (EN)
- Carte electronică gratuită
- Alte articole pe pe site-ul Red Hat
Anunțuri privind viitoarele webinarii
Începem o serie de seminarii web de vineri despre experiența nativă folosind Red Hat OpenShift Container Platform și Kubernetes:
Sursa: www.habr.com