Saluton al ĉiuj! Ĉi tiu estas la dua afiŝo en nia serio, en kiu ni montras kiel disfaldi modernajn TTT-aplikaĵojn sur Red Hat OpenShift.
En la antaŭa afiŝo, ni iomete tuŝis la kapablojn de la nova S2I (fonto-al-bilda) konstruaĵbildo, kiu estas desegnita por konstrui kaj disfaldi modernajn TTT-aplikaĵojn sur la platformo OpenShift. Tiam ni interesiĝis pri la temo rapide deploji aplikaĵon, kaj hodiaŭ ni rigardos kiel uzi S2I-bildon kiel "puran" konstruan bildon kaj kombini ĝin kun rilataj OpenShift-asembleoj.
Pura konstruanto bildo
Kiel ni menciis en Parto XNUMX, la plej multaj modernaj TTT-aplikoj havas tiel nomatan konstrustadion, kiu kutime faras operaciojn kiel ekzemple kodtranspilado, multobla dosierkunligado kaj minigo. La dosieroj akiritaj kiel rezulto de ĉi tiuj operacioj - kaj ĉi tio estas senmova HTML, JavaScript kaj CSS - estas konservitaj en la eligdosierujo. La loko de ĉi tiu dosierujo kutime dependas de kiaj konstruaj iloj estas uzataj, kaj por React ĉi tio estos la ./build-dosierujo (ni revenos al ĉi tio pli detale sube).
Fonto-al-Bildo (S2I)
En ĉi tiu afiŝo ni ne tuŝas la temon "kio estas S2I kaj kiel uzi ĝin" (vi povas legi pli pri tio ), sed gravas esti klara pri la du paŝoj en ĉi tiu procezo por kompreni kion faras Web App Builder-bildo.
Asembla fazo
La asemblea fazo estas tre simila en naturo al tio, kio okazas kiam vi kuras docker build kaj finiĝas kun nova Docker-bildo. Sekve, ĉi tiu etapo okazas kiam oni komencas konstrui sur la platformo OpenShift.
En la kazo de bildo de Web App Builder, ĝi respondecas pri instali la dependecojn de via aplikaĵo kaj prizorgi la konstruon. . Defaŭlte, la konstruaĵbildo uzas la npm run konstrukonstruaĵon, sed ĉi tio povas esti anstataŭita per la mediovariablo NPM_BUILD.
Kiel ni diris antaŭe, la loko de la finita, jam konstruita aplikaĵo dependas de kiaj iloj vi uzas. Ekzemple, en la kazo de React ĉi tio estos la dosierujo ./build, kaj por Angularaj aplikoj ĝi estos la dosierujo projekt_nomo/dist. Kaj, kiel jam montrite en la antaŭa afiŝo, la loko de la eliga dosierujo, kiu estas agordita por konstrui defaŭlte, povas esti anstataŭita per la mediovariablo OUTPUT_DIR. Nu, ĉar la loko de la eligo-dosierujo diferencas de kadro al kadro, vi simple kopiu la generitan produktaĵon al la norma dosierujo en la bildo, nome /opt/apt-root/output. Ĉi tio gravas por kompreni la reston de ĉi tiu artikolo, sed nuntempe ni rapide rigardu la sekvan etapon - la kura fazo.
kura fazo
Ĉi tiu etapo okazas kiam voko al docker-kuro estas farita sur la nova bildo kreita dum la kunigstadio. La sama okazas dum deplojiĝo sur la OpenShift-platformo. Defaŭlte uzoj por servi senmovan enhavon situantan en la supra norma eliga dosierujo.
Ĉi tiu metodo estas bona por rapide disfaldi aplikaĵojn, sed ĝenerale ne rekomendas servi statikan enhavon tiel. Nu, ĉar fakte ni servas nur senmovan enhavon, ni ne bezonas Node.js instalitan ene de nia bildo - retservilo sufiĉos.
Alivorte, dum kunigo ni bezonas unu aferon, dum ekzekuto ni bezonas alian. En ĉi tiu situacio, ĉenitaj konstruoj utilas.
Ĉenitaj konstruoj
Jen pri kio ili skribas en la OpenShift-dokumentado:
"Du asembleoj povas esti ligitaj kune, kun unu generanta kompilitan enton kaj la alia gastiganta tiun enton en aparta bildo, kiu estas uzata por funkciigi tiun enton."
Alivorte, ni povas uzi la bildon de Web App Builder por ruli nian konstruon, kaj poste uzi la retservilan bildon, la saman NGINX, por servi nian enhavon.
Tiel, ni povas uzi la bildon de Web App Builder kiel "puran" konstruilon kaj samtempe havi malgrandan rultempan bildon.
Nun ni rigardu ĉi tion kun specifa ekzemplo.
Por trejnado ni uzos , kreita per la ilo de komandlinio create-react-app.
Ĝi helpos nin kunmeti ĉion .
Ni rigardu ĉi tiun dosieron pli detale, kaj komencu per la sekcio de parametroj.
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
Ĉio ĉi tie estas sufiĉe klara, sed indas atenti la parametron OUTPUT_DIR. Por la aplikaĵo React en nia ekzemplo, estas nenio zorgi pri tio, ĉar React uzas la defaŭltan valoron kiel la eligdosierujon, sed en la kazo de Angular aŭ io alia, ĉi tiu parametro devos esti ŝanĝita laŭbezone.
Nun ni rigardu la sekcion 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'
Rigardu la trian kaj kvaran bildojn. Ili ambaŭ estas difinitaj kiel Docker-bildoj, kaj vi povas klare vidi de kie ili venas.
La tria bildo estas web-app-builder kaj ĝi venas de nodeshift/ubi8-s2i-web-app etikedita 10.x sur .
La kvara estas NGINX-bildo (versio 1.12) kun la plej nova etikedo .
Nun ni rigardu la unuajn du bildojn. Ili ambaŭ estas malplenaj komence kaj estas kreitaj nur dum la konstrufazo. La unua bildo, react-web-app-builder, estos la rezulto de asemblea paŝo, kiu kombinos la bildon web-app-builder-runtime kaj nian fontkodon. Tial ni aldonis "-builder" al la nomo de ĉi tiu bildo.
La dua bildo - react-web-app-runtime - estos la rezulto de kombinado de nginx-image-runtime kaj iuj dosieroj de la bildo react-web-app-builder. Ĉi tiu bildo ankaŭ estos uzata dum deplojo kaj enhavos nur la retservilon kaj senmovan HTML, JavaScript, CSS de nia aplikaĵo.
Konfuzita? Nun ni rigardu la konstruajn agordojn kaj ĝi fariĝos iom pli klara.
Nia ŝablono havas du konstruajn agordojn. Jen la unua, kaj ĝi estas sufiĉe norma:
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
Kiel vi povas vidi, la linio kun etikedo 1 diras, ke la rezulto de ĉi tiu konstruo estos metita en la saman bildon de react-web-app-builder, kiun ni vidis iom pli frue en la sekcio ImageStreams.
La linio etikedita 2 diras al vi de kie akiri la kodon. En nia kazo, ĉi tio estas git-deponejo, kaj la loko, ref kaj kunteksta dosierujo estas determinitaj per la parametroj, kiujn ni jam vidis supre.
La linio etikedita 3 estas tio, kion ni jam vidis en la sekcio de parametroj. Ĝi aldonas la mediovariablon OUTPUT_DIR, kiu en nia ekzemplo estas konstruo.
La linio etikedita 4 diras uzi la retejo-app-builder-runtime-bildon, kiun ni jam vidis en la sekcio ImageStream.
Linio etikedita 5 diras, ke ni volas uzi pliigan konstruon se la S2I-bildo subtenas ĝin, kaj la Web App Builder-bildo faras. Ĉe la unua lanĉo, post kiam la munta stadio estas kompletigita, la bildo konservos la dosierujon node_modules en arkivan dosieron. Tiam, dum postaj kuroj, la bildo simple malzipos ĉi tiun dosierujon por redukti konstrutempon.
Kaj finfine, la linio etikedita 6 estas nur kelkaj ellasiloj por igi la konstruon funkcii aŭtomate, sen mana interveno, kiam io ŝanĝiĝas.
Ĝenerale ĉi tio estas sufiĉe norma konstruagordo.
Nun ni rigardu la duan konstruan agordon. Ĝi estas tre simila al la unua, sed estas unu grava diferenco.
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
Do la dua konstrua agordo estas react-web-app-runtime, kaj ĝi komenciĝas sufiĉe norma.
La linio etikedita 1 estas nenio nova - ĝi simple diras, ke la konstrurezulto estas metita en la bildon react-web-app-runtime.
La linio etikedita 2, kiel en la antaŭa agordo, indikas de kie akiri la fontkodon. Sed rimarku, ke ĉi tie ni diras, ke ĝi estas prenita el la bildo. Cetere, de la bildo, kiun ni ĵus kreis - de react-web-app-builder (indikita en linio etikedita 3). La dosieroj, kiujn ni volas uzi, estas ene de la bildo kaj ilia loko tie estas fiksita en linio etikedita 4, en nia kazo ĝi estas /opt/app-root/output/. Se vi memoras, ĉi tie estas stokitaj la dosieroj generitaj surbaze de la rezultoj de konstruado de nia aplikaĵo.
La celdosierujo specifita en la termino kun etikedo 5 estas simple la nuna dosierujo (ĉi tio estas ĉio, memoru, funkcianta en iu magia afero nomata OpenShift, kaj ne en via loka komputilo).
La strategia sekcio - linio etikedita 6 - ankaŭ similas al la unua konstrua agordo. Nur ĉi-foje ni uzos nginx-image-runtime, kiun ni jam vidis en la sekcio ImageStream.
Fine, la linio etikedita 7 estas sekcio de ellasiloj, kiuj aktivigos ĉi tiun konstruon ĉiufoje kiam la bildo de react-web-app-builder ŝanĝiĝas.
Alie, ĉi tiu ŝablono enhavas sufiĉe norman deplojan agordon, same kiel aferojn, kiuj rilatas al servoj kaj itineroj, sed ni ne tro detalos. Bonvolu noti, ke la bildo, kiu estos deplojita, estas la bildo react-web-app-runtime.
Apliko Deplojo
Do nun, ke ni rigardis la ŝablonon, ni vidu kiel uzi ĝin por disfaldi aplikaĵon.
Ni povas uzi la OpenShift-klienta ilo nomata oc por disfaldi nian ŝablonon:
$ 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 unua komando en la supra ekrankopio estas intence inĝenieristiko por trovi ŝablonon./openshiftio/application.yaml.
La dua komando simple kreas novan aplikaĵon bazitan sur ĉi tiu ŝablono.
Post kiam ĉi tiuj komandoj funkcias, ni vidos, ke ni havas du asembleojn:
Kaj revenante al la Superrigarda ekrano, ni vidos la lanĉitan pod:
Alklaku la ligilon kaj ni estos kondukitaj al nia programo, kiu estas la defaŭlta paĝo de React App:
Suplemento 1
Por Angula amantoj ni ankaŭ havas .
La ŝablono ĉi tie estas la sama, krom la variablo OUTPUT_DIR.
Suplemento 2
En ĉi tiu artikolo ni uzis NGINX kiel retservilon, sed estas sufiĉe facile anstataŭigi ĝin per Apache, simple ŝanĝu la ŝablonon en la dosiero. sur .
konkludo
En la unua parto de ĉi tiu serio, ni montris kiel rapide disfaldi modernajn TTT-aplikaĵojn sur la platformo OpenShift. Hodiaŭ ni rigardis kion faras Web App-bildo kaj kiel ĝi povas esti kombinita kun pura retservilo kiel NGINX uzante ĉenitajn konstruojn por krei pli produktadpretan aplikaĵon. En la sekva kaj fina artikolo en ĉi tiu serio, ni montros kiel ruli evoluservilon por via aplikaĵo sur OpenShift kaj certigi sinkronigon de lokaj kaj foraj dosieroj.
Enhavo de ĉi tiu serio de artikoloj
- Parto 1: ;
- Parto 2: Kiel uzi novan S2I-bildon kun ekzistanta HTTP-servila bildo, kiel NGINX, uzante asociitajn OpenShift-asembleojn por produktaddeplojo;
- Parto 3: kiel ruli evoluservilon por via aplikaĵo sur la platformo OpenShift kaj sinkronigi ĝin kun la loka dosiersistemo.
Pliaj Rimedoj
- Senpaga e-libro .
- Informoj pri .
fonto: www.habr.com