Hi omnes! Haec est secunda tabella in serie nostra in qua ostendemus quomodo explicandas applicationes interretiales in Rubrum Hat OpenShift.
In priore poste paulum attigimus facultates imaginis novae S2I (fontis-ad-image) aedificatoris, quae ad aedificandas et explicandas applicationes recentiorum interretialem in suggestu OpenShift destinatur. Tunc quaerebamus thema celeriter explicandi applicationis, et hodie inspiciemus quomodo imaginem S2I ut "puri" fabricatoris imaginem adhibeamus et eam cum conventibus OpenShift affinibus coniungamus.
Tersus fabricator imaginis
Ut in Parte I memoravimus, maxime moderni applicationes interretiales scaenam aedificandi sic dictam habent, quae operationes typice exercet ut codicem transpilationem, multiplex fasciculi concatenatio, et minificatio. Fasciculi consecuti ex his operibus - et hoc static HTML, JavaScript et CSS - in output folder reponuntur. Locus huius folder plerumque pendet ex quibus instrumenta fabricandi adhibentur, et pro reac hoc erit folder ./aedificare (ad hoc subtilius infra revertemur).
Source-ad-Image (S2I)
In hoc post- thema non attingimus quid sit S2I et quomodo eo utendum sit (de hoc plura legere potes. ) sed magni momenti est de duobus gradibus in hoc processu perspicere quid imaginis Telae App conditoris facit.
Coetus phase
Coetus Phase simillimus est in natura quod fit cum currendo Faucibus aedificatis et cum nova Docker imagine terminatur. Itaque scaena haec incidit cum aedificaretur in suggestu OpenShift incipiens.
In casu imaginis Web App conditoris, reus est applicationes tuas clientelas inaugurari et aedificare currendo. . Defalta aedificator imaginis npm run constructum utitur, sed hoc opprimi potest per NPM_BUILD environment variabilis.
Ut supra diximus, locus perfecti, applicatio iam constructa pendet ab instrumentis uteris. Exempli gratia, in casu React hoc erit folder ./aedificare, et ad applicationes angulares erit folder project_name/dist. Et, ut iam in priore poste monstratum est, locus output presul, quod per defaltam aedificetur, opprimi potest per OUTPUT_DIR environment variabilis. Bene, cum locus output folder a compage ad compage differat, simpliciter generatum output ad vexillum folder in imagine imitare, nempe /opt/apt-root/output. Hoc magni momenti est ad intellegendum reliquos huius articuli, sed nunc celeriter inspiciamus gradum proximum - tempus cursus.
currere tempus
Hoc scaena accidit cum invitatio ad currendum currendum facta est in nova imagine in scaena conventus creata. Idem fit cum in OpenShift disponit suggestum. Default usus ad serviendum static contentum in suprascripto output presul positum.
Haec methodus bona est ad applicationes cito disponendi, sed plerumque non commendatur ut statice contentus hoc modo serviat. Bene, cum in re tantum contenti static serviamus, Node.js in imagine nostra inauguratus non indigemus - server tela sufficiet.
Id est, congregando aliud indigemus, aliud exequendo indigemus. In hoc situ vinctus aedificat venire in manus manus.
constructum builds
Hoc est quod scribunt de in OpenShift documentis:
"Duae coetus in unum coniungi possunt, una entitatem compositam generans, altera ens in imagine separata, quae ens illud currit".
Aliis verbis, imaginem Web App Conditoris uti possumus ad nostrum aedificandum currendum, ac deinde imaginem interretialem, eiusdem NGINX, utamur contenti nostro.
Ita uti possumus imaginem Web App conditorem tamquam "purum" aedificatorem simulque parvam imaginem runtim habere.
Nunc hoc cum speciali exemplo videamus.
Ad exercitationem utemur , crea-usa crea-react-app mandatum linea instrumentum.
Nos simul omnia adiuvabit .
Inspiciamus hunc fasciculum subtilius, et ab sectione parametri incipere.
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
Omnia hic satis clara sunt, sed pro OUTPUT_DIR parametri cura est. Pro applicatione React in exemplo nostro, nihil est quod cures, cum React valorem defaltam ut folder in output utatur, sed in casu angulari vel alio, hic modulus mutandus est sicut necesse est.
Nunc inspice sectionem 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'
Vide imagines tertiae et quartae. Ambae ut Docker imagines definiuntur, et unde sint videre potes.
Tertia imago est web-app-structor atque e nodeshift/ubi8-s2i-textus-app tagged 10.x in .
Quarta imago est NGINX (versio 1.12) cum tag on .
Nunc primum duas imagines videamus. Ambae in initio vacuae sunt et solum in aedificatione periodi creantur. Prima imago, reac-tela app-structor, ex gradu conventus erit qui coniunget imaginem telae app-aedificis runtim ac fontem nostrum codicem. Quam ob rem nomini huius imaginis addimus "aedificatorem".
Secunda imago - reac-texta app runtime - coniungenda erit ng-runtime imaginis imago et nonnullae imagini e react imaginis app-structoris. Haec imago etiam in instruere utendum erit et tantum continebit interretialem servitorem et static HTML, JavaScript, CSS applicationis nostrae.
Confusus? Nunc inspice figuras aedificandas et paulo clarius fiet.
Template has duas figuras aedificant. Hic primum est, et satis signum est;
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
Ut vides, linea cum pittacio 1 dicit exitum huius aedificationis in eodem imaginis reac-textae app-structoris collocari, quam paulo ante in sectione ImageStreams vidimus.
Linea intitulata 2 narrat tibi ubi codicem ex. In nobis, hoc repositum est git, et locus, ref et contextus folder per parametris iam supra vidimus determinantur.
Linea intitulata 3 est quam in sectione parametri iam vidimus. Addit OUTPUT_DIR environment variabilis, quae in nostro exemplo aedificatur.
Linea intitulata 4 dicit uti imagine telae app-aedificis runtime, quam in sectione ImageStream iam vidimus.
Linea intitulata 5 dicit nos velle uti aedificationis incrementi si S2I imago eam sustineat, et imaginem Web App conditorem facit. Ad primum launch, postquam scaena conventus peracta est, imago nodi_modulorum folder in tabulario archivo servabit. Deinde, in subsequentibus currit, imago simpliciter unzip hoc folder erit ad tempus aedificandi reducendum.
Ac tandem, linea intitulata 6 paucae tantum triggers ad faciendum currendum automatice, sine interventu manuali, cum mutationibus aliquid efficiunt.
Super haec regula pulchra figurae aedificationis est.
Nunc inspice figuram secundam aedificandi. Hoc priori simillimum est, sed una est magna differentia.
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
Secunda igitur figuratio constructio est reac-textus app-runtime, et incipit e forma satis.
Linea intitulata 1 nihil novi est - simpliciter dicit effectum constructum in imagine react-app-runtime positum.
Linea intitulata 2, ut in priori schemate, indicat, ubi ex codice fonte hauriatur. Sed attende quod hic dicimus ab imagine sumptum. Praeterea ab imagine quam mox creati sumus - a react-web-app-structore (line intitulato 3 indicata). Fasciculi, quos uti volumus, intra imaginem sunt et eorum locus in linea intitulata 4, in casu nostro /opt/app-root/output/ est constitutus. Si meministi, hoc est ubi generantur tabulae secundum eventum aedificationis nostrae applicationis repositae.
Destinatio folder in termino cum pittacio 5 determinatum simpliciter est directorium currentis (hoc est omnia, memento, intra rem magicam quamdam rem magicam vocatam OpenShift currere, et non in computatro locali tuo).
Sectio militaris - linea intitulata 6 - similis est etiam primae figurae constructae. Hoc tantum tempore uti nginx-runtime imagini- turi sumus, quod iam in sectione ImageStream vidimus.
Denique linea intitulata 7 sectio triggerum est quae hanc aedificationem excitabit omni tempore imaginis mutationes react-textus app-structoris.
Aliter, hoc template, satis vexillum instruere configurationem continet, ac ea quae ad officia et itinera pertinent, sed in hoc nimis subtiliter non ingredimur. Quaeso nota imaginem, quae explicabitur, imaginem reac-texti app-runtime.
Applicationem instruere
Nunc ergo exemplum inspeximus, quomodo usus explicandi applicatione videamus.
Usus clientis OpenShift possumus instrumento nomine oc ad explicandam formulam nostram:
$ 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
Primum mandatum in screenshot supra modum operandi est consilium invenire template./openshiftio/application.yaml.
Secundum mandatum simpliciter novam applicationem in hac template gignit.
Post haec mandata opus habemus, ut duas ecclesias habere videbimus;
Et ad screen Overview rediens, vasculum immissum videbimus;
Preme nexum et ad nostrum app feremus, quod est defalta React App pagina:
Supplementum 1
Nam amantes angularis nos etiam habemus .
Exemplar hic idem est, excepto OUTPUT_DIR variabili.
Supplementum 2
In hoc articulo NGINX pro servo telae usi sumus, sed perfacile est illud Apache reponere, sicut in tabella mutare exemplum. on .
conclusio,
In prima huius seriei parte docuimus quam cito explicabimus applicationes interretiales recentiores in suggestu OpenShift. Hodie inspeximus quid imago Web App facit et quomodo coniungi potest cum puro servo telae similis NGINX constructo utens catenato ad efficiendum promptiorem applicationem fabricandi. In proximo et ultimo articulo in hac serie, ostendemus quomodo servo progressionis currendi pro applicatione tua in OpenShift et synchronizationem locorum ac remotarum imaginum curet.
Contenta huius seriei capitulorum
- Pars II: ;
- Pars 2: Quomodo utatur nova S2I imagine cum imagine HTTP exsistens servo, ut NGINX, adhibitis conventibus OpenShift ad productionem instruere;
- Pars III: quomodo servo progressionem currere pro applicatione tua in suggestu OpenShift et illam cum systemate lima locali conformare.
Additional Resources
- Free e-book .
- Information on .
Source: www.habr.com