Hola a tots! Aquesta és la segona publicació de la nostra sèrie en què mostrem com implementar aplicacions web modernes a Red Hat OpenShift.
A la publicació anterior, vam tocar lleugerament les capacitats de la nova imatge del constructor S2I (font a imatge), que està dissenyada per crear i desplegar aplicacions web modernes a la plataforma OpenShift. Aleshores ens interessava el tema del desplegament ràpid d'una aplicació, i avui veurem com utilitzar una imatge S2I com a imatge de constructor "pura" i combinar-la amb conjunts d'OpenShift relacionats.
Imatge de constructor neta
Com hem esmentat a la part XNUMX, la majoria de les aplicacions web modernes tenen l'anomenada fase de construcció, que normalment realitza operacions com ara la transpilació de codi, la concatenació de fitxers múltiples i la minificació. Els fitxers obtinguts com a resultat d'aquestes operacions -i això és HTML estàtic, JavaScript i CSS- s'emmagatzemen a la carpeta de sortida. La ubicació d'aquesta carpeta depèn normalment de quines eines de compilació s'estan utilitzant, i per a React aquesta serà la carpeta ./build (tornarem a això amb més detall a continuació).
Font a imatge (S2I)
En aquesta entrada no toquem el tema "què és S2I i com utilitzar-lo" (podeu llegir més sobre això ), però és important tenir clar els dos passos d'aquest procés per entendre què fa una imatge de Web App Builder.
Fase de muntatge
La fase de muntatge és de naturalesa molt similar al que passa quan executeu la compilació de Docker i acabeu amb una nova imatge de Docker. En conseqüència, aquesta etapa es produeix quan s'inicia una compilació a la plataforma OpenShift.
En el cas d'una imatge de Web App Builder, és responsable d'instal·lar les dependències de l'aplicació i executar la compilació. . De manera predeterminada, la imatge del constructor utilitza la construcció npm run build, però aquesta es pot substituir mitjançant la variable d'entorn NPM_BUILD.
Com hem dit anteriorment, la ubicació de l'aplicació acabada i ja construïda depèn de quines eines utilitzeu. Per exemple, en el cas de React aquesta serà la carpeta ./build, i per a les aplicacions Angular serà la carpeta nom_projecte/dist. I, com ja es va mostrar a la publicació anterior, la ubicació del directori de sortida, que està configurat per construir-se per defecte, es pot substituir mitjançant la variable d'entorn OUTPUT_DIR. Bé, com que la ubicació de la carpeta de sortida difereix d'un marc a un altre, simplement copieu la sortida generada a la carpeta estàndard de la imatge, és a dir, /opt/apt-root/output. Això és important per entendre la resta d'aquest article, però de moment mirem ràpidament la següent etapa: la fase d'execució.
fase d'execució
Aquesta etapa es produeix quan es fa una trucada a l'execució de Docker a la nova imatge creada durant l'etapa de muntatge. El mateix passa quan es desplega a la plataforma OpenShift. Per defecte usos per publicar contingut estàtic situat al directori de sortida estàndard anterior.
Aquest mètode és bo per desplegar aplicacions ràpidament, però generalment no es recomana publicar contingut estàtic d'aquesta manera. Bé, com que en realitat només oferim contingut estàtic, no necessitem instal·lar Node.js a la nostra imatge: n'hi haurà prou amb un servidor web.
És a dir, a l'hora de muntar necessitem una cosa, a l'executar en necessitem una altra. En aquesta situació, les construccions encadenades són útils.
Construccions encadenades
Això és el que escriuen a la documentació d'OpenShift:
"Es poden enllaçar dos conjunts, un generant una entitat compilada i l'altre allotja aquesta entitat en una imatge separada que s'utilitza per executar aquesta entitat".
En altres paraules, podem utilitzar la imatge del Web App Builder per executar la nostra compilació i després utilitzar la imatge del servidor web, el mateix NGINX, per servir el nostre contingut.
Així, podem utilitzar la imatge del Web App Builder com a constructor "pur" i alhora tenir una petita imatge d'execució.
Vegem-ho ara amb un exemple concret.
Per a la formació utilitzarem , creat amb l'eina de línia d'ordres create-react-app.
Ens ajudarà a posar-ho tot junt .
Vegem aquest fitxer amb més detall i comencem per la secció de paràmetres.
parameters:
- name: SOURCE_REPOSITORY_URL
description: The source URL for the application
displayName: Source URL
required: true
- name: SOURCE_REPOSITORY_REF
description: The branch name for the application
displayName: Source Branch
value: master
required: true
- name: SOURCE_REPOSITORY_DIR
description: The location within the source repo of the application
displayName: Source Directory
value: .
required: true
- name: OUTPUT_DIR
description: The location of the compiled static files from your web apps builder
displayName: Output Directory
value: build
required: false
Tot aquí és bastant clar, però val la pena parar atenció al paràmetre OUTPUT_DIR. Per a l'aplicació React del nostre exemple, no hi ha res de què preocupar-se, ja que React utilitza el valor predeterminat com a carpeta de sortida, però en el cas d'Angular o una altra cosa, caldrà canviar aquest paràmetre segons sigui necessari.
Ara fem una ullada a la secció ImageStreams.
- apiVersion: v1
kind: ImageStream
metadata:
name: react-web-app-builder // 1
spec: {}
- apiVersion: v1
kind: ImageStream
metadata:
name: react-web-app-runtime // 2
spec: {}
- apiVersion: v1
kind: ImageStream
metadata:
name: web-app-builder-runtime // 3
spec:
tags:
- name: latest
from:
kind: DockerImage
name: nodeshift/ubi8-s2i-web-app:10.x
- apiVersion: v1
kind: ImageStream
metadata:
name: nginx-image-runtime // 4
spec:
tags:
- name: latest
from:
kind: DockerImage
name: 'centos/nginx-112-centos7:latest'
Mireu la tercera i la quarta imatge. Tots dos es defineixen com a imatges de Docker i podeu veure clarament d'on provenen.
La tercera imatge és web-app-builder i prové de nodeshift/ubi8-s2i-web-app etiquetada 10.x a .
La quarta és una imatge NGINX (versió 1.12) amb l'última etiqueta activada .
Ara mirem les dues primeres imatges. Tots dos estan buits a l'inici i només es creen durant la fase de construcció. La primera imatge, react-web-app-builder, serà el resultat d'un pas de muntatge que combinarà la imatge web-app-builder-runtime i el nostre codi font. És per això que hem afegit "-builder" al nom d'aquesta imatge.
La segona imatge, react-web-app-runtime, serà el resultat de combinar nginx-image-runtime i alguns fitxers de la imatge react-web-app-builder. Aquesta imatge també s'utilitzarà durant el desplegament i només contindrà el servidor web i HTML estàtic, JavaScript, CSS de la nostra aplicació.
Confós? Ara fem una ullada a les configuracions de construcció i quedarà una mica més clar.
La nostra plantilla té dues configuracions de compilació. Aquí teniu el primer, i és bastant estàndard:
apiVersion: v1
kind: BuildConfig
metadata:
name: react-web-app-builder
spec:
output:
to:
kind: ImageStreamTag
name: react-web-app-builder:latest // 1
source: // 2
git:
uri: ${SOURCE_REPOSITORY_URL}
ref: ${SOURCE_REPOSITORY_REF}
contextDir: ${SOURCE_REPOSITORY_DIR}
type: Git
strategy:
sourceStrategy:
env:
- name: OUTPUT_DIR // 3
value: ${OUTPUT_DIR}
from:
kind: ImageStreamTag
name: web-app-builder-runtime:latest // 4
incremental: true // 5
type: Source
triggers: // 6
- github:
secret: ${GITHUB_WEBHOOK_SECRET}
type: GitHub
- type: ConfigChange
- imageChange: {}
type: ImageChange
Com podeu veure, la línia amb l'etiqueta 1 diu que el resultat d'aquesta compilació es col·locarà a la mateixa imatge react-web-app-builder que vam veure una mica abans a la secció ImageStreams.
La línia anomenada 2 us indica d'on podeu obtenir el codi. En el nostre cas, es tracta d'un repositori git, i la ubicació, la referència i la carpeta de context estan determinats pels paràmetres que ja vam veure més amunt.
La línia anomenada 3 és la que ja vam veure a la secció de paràmetres. Afegeix la variable d'entorn OUTPUT_DIR, que en el nostre exemple és compilar.
La línia etiquetada 4 diu que utilitzeu la imatge web-app-builder-runtime, que ja vam veure a la secció ImageStream.
La línia amb l'etiqueta 5 diu que volem utilitzar una compilació incremental si la imatge S2I ho admet, i la imatge Web App Builder ho fa. En el primer llançament, un cop finalitzada l'etapa de muntatge, la imatge desarà la carpeta node_modules en un fitxer d'arxiu. Aleshores, en execucions posteriors, la imatge simplement descomprimirà aquesta carpeta per reduir el temps de creació.
I, finalment, la línia anomenada 6 són només uns quants desencadenants per fer que la compilació s'executi automàticament, sense intervenció manual, quan alguna cosa canvia.
En general, aquesta és una configuració de construcció força estàndard.
Ara fem una ullada a la segona configuració de construcció. És molt semblant al primer, però hi ha una diferència important.
apiVersion: v1
kind: BuildConfig
metadata:
name: react-web-app-runtime
spec:
output:
to:
kind: ImageStreamTag
name: react-web-app-runtime:latest // 1
source: // 2
type: Image
images:
- from:
kind: ImageStreamTag
name: react-web-app-builder:latest // 3
paths:
- sourcePath: /opt/app-root/output/. // 4
destinationDir: . // 5
strategy: // 6
sourceStrategy:
from:
kind: ImageStreamTag
name: nginx-image-runtime:latest
incremental: true
type: Source
triggers:
- github:
secret: ${GITHUB_WEBHOOK_SECRET}
type: GitHub
- type: ConfigChange
- type: ImageChange
imageChange: {}
- type: ImageChange
imageChange:
from:
kind: ImageStreamTag
name: react-web-app-builder:latest // 7
Per tant, la segona configuració de compilació és react-web-app-runtime, i comença bastant estàndard.
La línia anomenada 1 no és cap novetat: simplement diu que el resultat de la compilació es posa a la imatge react-web-app-runtime.
La línia anomenada 2, com en la configuració anterior, indica d'on es pot obtenir el codi font. Però observeu que aquí estem dient que està tret de la imatge. A més, a partir de la imatge que acabem de crear, de react-web-app-builder (indicat a la línia etiquetada 3). Els fitxers que volem utilitzar es troben dins de la imatge i la seva ubicació allà està establerta a la línia etiquetada 4, en el nostre cas és /opt/app-root/output/. Si ho recordeu, aquí és on s'emmagatzemen els fitxers generats a partir dels resultats de la construcció de la nostra aplicació.
La carpeta de destinació especificada en el terme amb l'etiqueta 5 és simplement el directori actual (això és tot, recordeu, que s'executa dins d'una cosa màgica anomenada OpenShift, i no al vostre ordinador local).
La secció d'estratègia (línia anomenada 6) també és similar a la configuració de la primera compilació. Només que aquesta vegada farem servir nginx-image-runtime, que ja vam veure a la secció ImageStream.
Finalment, la línia anomenada 7 és una secció d'activadors que activarà aquesta compilació cada vegada que canviï la imatge de react-web-app-builder.
En cas contrari, aquesta plantilla conté una configuració de desplegament força estàndard, així com coses relacionades amb serveis i rutes, però no entrarem en massa detalls. Tingueu en compte que la imatge que es desplegarà és la imatge react-web-app-runtime.
Desplegament d'aplicacions
Així que ara que hem mirat la plantilla, vegem com utilitzar-la per desplegar una aplicació.
Podem utilitzar l'eina de client OpenShift anomenada oc per desplegar la nostra plantilla:
$ find . | grep openshiftio | grep application | xargs -n 1 oc apply -f
$ oc new-app --template react-web-app -p SOURCE_REPOSITORY_URL=https://github.com/lholmquist/react-web-app
La primera ordre de la captura de pantalla anterior és una manera d'enginyeria deliberada de trobar una plantilla./openshiftio/application.yaml.
La segona ordre simplement crea una aplicació nova basada en aquesta plantilla.
Després de treballar aquestes ordres, veurem que tenim dos assemblatges:
I tornant a la pantalla de visió general, veurem el pod llançat:
Feu clic a l'enllaç i serem dirigits a la nostra aplicació, que és la pàgina predeterminada de l'aplicació React:
Suplement 1
Per als amants d'Angular també tenim .
El patró aquí és el mateix, excepte per a la variable OUTPUT_DIR.
Suplement 2
En aquest article hem utilitzat NGINX com a servidor web, però és bastant fàcil substituir-lo per Apache, només cal canviar la plantilla al fitxer en .
Conclusió
A la primera part d'aquesta sèrie, vam mostrar com implementar ràpidament aplicacions web modernes a la plataforma OpenShift. Avui hem vist què fa una imatge d'aplicació web i com es pot combinar amb un servidor web pur com NGINX mitjançant compilacions encadenades per crear una compilació d'aplicacions més preparada per a la producció. En el següent i últim article d'aquesta sèrie, mostrarem com executar un servidor de desenvolupament per a la vostra aplicació a OpenShift i garantir la sincronització dels fitxers locals i remots.
Continguts d'aquesta sèrie d'articles
- Part de 1: ;
- Part 2: Com utilitzar una imatge S2I nova amb una imatge de servidor HTTP existent, com ara NGINX, utilitzant conjunts OpenShift associats per al desplegament de producció;
- Part 3: com executar un servidor de desenvolupament per a la vostra aplicació a la plataforma OpenShift i sincronitzar-lo amb el sistema de fitxers local.
Recursos addicionals
- Llibre electrònic gratuït .
- Informació sobre .
Font: www.habr.com