🥇Applicationes Modernae in OpenShift, Pars II: Structurae Concatenatae

Salvete omnes! Bene advenistis ad secundum nuntium in serie nostra, qui demonstrabit quomodo applicationes interretiales modernas in Red Hat OpenShift disponantur.

In articulo nostro priori, breviter de facultatibus novae imaginis constructoris S2I (source-to-image) attigimus, quae ad construendas et disponendas applicationes interretiales modernas in suggestu OpenShift destinata est. Olim, in celeri dispositione applicationum operam dedimus, et hodie explorabimus quomodo imaginem S2I ut imaginem constructoris "puram" uti et eam cum constructionibus OpenShift similibus coniungere possimus.

Imago constructoris pura

Ut in prima parte diximus, pleraeque applicationes interretiales modernae stadium constructionis (seu "build stage") habent, quod typice operationes perficit, ut transpilationem codicis, concatenationem fasciculorum, et minificationem. Fasciculi resultantes — HTML staticus, JavaScript, et CSS — in fasciculo "output" (output folder) ponuntur. Locus huius fasciculi plerumque ab instrumentis constructionis adhibitis pendet, et pro React, fasciculus "./build" erit (ad hoc infra fusius redibimus).

Fons-ad-Imaginem (S2I)

In hoc scripto argumentum "quid est S2I et quomodo eo utendum est" non attingimus (plus de hoc hic legere potes). hic), sed interest duas partes huius processus perspicue intellegere ut quid imago Fabricatoris Applicationum Interretialium faciat intellegatur.

Phase congregationis

Gradus compositionis (vel "assembly") fere similis est ei qui fit cum "docker build" curris et novam imaginem Docker obtines. Proinde, hic gradus fit cum "build" in suggestu OpenShift curris.

In casu imaginis Fabricatoris Applicationum Interretialium, ea responsabilis est pro institutione dependentiarum applicationis tuae et constructionis currenda. scriptum componereImago constructoris per default constructum `npm run build` utitur, sed hoc per variabilem ambientis `NPM_BUILD` superari potest.

Ut antea disseruimus, locus applicationis perfectae et praeformatae ab instrumentis adhibitis pendet. Exempli gratia, pro React, haec erit fasciculus ./build, dum pro applicationibus Angular, est fasciculus project_name/dist. Et, ut in articulo priori demonstratum est, locus directorii output, qui ad build per default constitutus est, variabili ambitus OUTPUT_DIR substitui potest. Cum locus directorii output secundum structuram variet, output generatum simpliciter ad fasciculum default in imagine, scilicet /opt/apt-root/output, copias. Hoc magni momenti est ad reliquam partem huius articuli intellegendam, sed nunc, gradum proximum — phasin executionis — celeriter recognoscamus.

Phase cursus

Hoc stadium fit cum invocatio "docker run" ad novam imaginem, quae in stadio "assembly" creata est, fit. Etiam fit cum in suggestum OpenShift distribuitur. Per defectum... currere scriptor usus modulus serviendi ad contenta statica in directorio exitus normalis supra specificato sita exhibenda.

Haec methodus apta est ad celeriter applicationes disponendas, sed plerumque non commendatur ad contenta statica exhibenda. Cum tantum contenta statica exhibeamus, Node.js intra imaginem nostram installatum non requirimus—ipsus servus interretialis sufficiet.

Aliis verbis, una re nobis opus est per constructionem, altera per exsecutionem. In hac condicione, constructiones concatenatae utiles sunt.

Aedificia concatenata

De hoc scribunt structurae concatenatae in documentis OpenShift:

"Duae coetus inter se coniungi possunt, uno entitatem compilatam generante, altero autem entitatem illam in imagine separata collocante, quae ad illam entitatem currendam adhibetur."

Aliis verbis, imaginem Fabricatoris Applicationum Interretialium (Web App Builder) ad constructionem nostram exsequendam uti possumus, deinde imaginem servitoris interretialis, ut NGINX, ad contenta nostra exhibenda uti.

Hoc modo imaginem Fabricatoris Applicationum Interretialium (Web App Builder) tamquam fabricatorem "purum" uti possumus, et adhuc parvam imaginem temporis executionis habere.

Nunc hoc exemplo specifico inspiciamus.

Ad exercitationem utemur simplex applicatio React, creatum instrumento lineae mandati "create-react-app" utens.

Ut omnia coniungamus adiuvemur Fasciculus exemplaris OpenShift.

Hunc fasciculum propius inspiciamus, a sectione parametrorum incipientes.

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 per se manifesta sunt, sed operae pretium est parametro OUTPUT_DIR attendere. Pro applicatione React in exemplo nostro, nihil est de quo sollicitemur, cum React valorem implicitum pro directorio output utatur. Attamen, pro Angular vel alio quodam, hic parameter proinde mutandus erit.

Nunc sectionem ImageStreams inspiciamus.

- 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'

Inspice imagines tertiam et quartam. Ambae imagines Dockerianae definiuntur, et unde veniant perspicuum est.

Tertia imago est "web-app-builder" et sumpta est ex "nodeshift/ubi8-s2i-web-app" cum nota 10.x inscripta. Docker Hub.

Quarta est imago NGINX (versio 1.12) cum recentissima nota in... Docker Hub.

Nunc primas duas imagines inspiciamus. Ambae initio vacuae sunt et tantum in phase constructionis creantur. Prima imago, "react-web-app-builder", erit effectus phases constructionis, quae imaginem "web-app-builder-runtime" cum codice nostro fonte coniunget. Quam ob rem "-builder" in nomine imaginis inclusimus.

Altera imago, quae "react-web-app-runtime" appellatur, ex coniunctione functionis "nginx-image-runtime" et nonnullorum fasciculorum ex imagine "react-web-app-builder" orta erit. Haec imago etiam ad distributionem adhibebitur et solum servum interretialem necnon HTML, JavaScript, et CSS statica applicationis nostrae continebit.

Confususne es? Configurationes constructionis inspiciamus et paulo clarius fiet.

Formula nostra duas configurationes aedificandi habet. Prima, quae satis communis est, ecce:

  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 videre possumus, linea notata 1 dicit exitum huius constructionis in eadem imagine react-web-app-builder collocatum iri quam paulo antea in sectione ImageStreams vidimus.

Linea inscripta "2" indicat ubi codicem acquirendum sit. In nostro casu, repositorium "git" est, et locus, "ref", et "context folder" a parametris iam supra vidimus determinantur.

Linea quae numerus 3 appellatur iam in sectione parametrorum vidimus est. Variabilem ambitus OUTPUT_DIR addit, quae in exemplo nostro aequalis est `build`.
Linea quarta inscripta nobis dicit ut imaginem `web-app-builder-runtime`, quam iam in sectione `ImageStream` vidimus, utamur.

Linea quinta specificat nos constructionem incrementalem uti velle si imago S2I eam sustinet, et imago Web App Builder sustinet. In prima executione, post gradum assembly perfectum, imago fasciculum node_modules in fasciculo archivo servabit. Deinde, in executionibus subsequentibus, imago hunc fasciculum simpliciter aperiet ut tempus constructionis minuatur.

Denique, linea sexta pauca tantum incitamenta est ad constructionem automatice currendam, sine interventione manuali, cum aliquid mutatur.

Summa summarum, haec est configuratio constructionis satis communis.

Nunc secundam configurationem constructionis inspiciamus. Primae valde similis est, sed una differentia magni momenti est.

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

Itaque, secunda configuratio constructionis est react-web-app-runtime, et initium satis commune habet.

Nihil novi in linea prima est — simpliciter dicit exitum constructionis in imaginem react-web-app-runtime poni.

Linea inscripta 2, sicut in configuratione priori, indicat ubi codicem fontem acquirendum sit. Sed nota hic nos specificare eum ex imagine sumptum esse. Speciatim, ex imagine quam modo creavimus—react-web-app-builder (in linea inscripta 3 specificata). Fasciculi quos uti volumus intra imaginem sita sunt, et locus eorum in linea inscripta 4 specificatur; in nostro casu, est /opt/app-root/output/. Si meministi, hic fasciculi generati per constructionem applicationis nostrae servantur.

Directorium destinatum in linea sub inscriptione "5" specificatum simpliciter est directorium praesens (haec omnia, memento, intra rem magicam nomine OpenShift currunt, non in computatro tuo locali).

Pars de consilio — linea sexta — etiam similis est primae configurationi constructionis. Hoc autem tempore, `nginx-image-runtime` utemur, quod iam in parte `ImageStream` vidimus.

Denique, linea notata 7 est sectio "triggers" quae hanc constructionem quotiescumque imago react-web-app-builder mutatur excitabit.

Alioquin, hoc exemplar configurationem distributionis satis communem continet, necnon res ad officia et vias pertinentes, sed de hoc non progrediemur. Nota imaginem quae distribuetur esse imaginem react-web-app-runtime.

Applicationem instruere

Itaque nunc, cum exemplar inspeximus, videamus quomodo eo utamur ad applicationem disponendam.

Instrumento clienti OpenShift nomine "oc" uti possumus ad exemplar nostrum disponendum:

$ 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 imagine supra posita via de industria machinata est ad inveniendum exemplar `template./openshiftio/application.yaml`.

Secundum mandatum simpliciter novam applicationem in hoc exemplo fundatam creat.

Postquam haec mandata exsecuta sunt, videbimus nos duas congregationes habere:

Et ad paginam "Conspectus" revertentes, videbimus pod currentem:

Premendo nexum, ad applicationem nostram ducemur, quae est pagina React App implicita:

Supplementum 1

Amantibus Angularis etiam habemus exemplum applicationis.

Formula hic eadem est, excepta variabili OUTPUT_DIR.

Supplementum 2

In hoc articulo NGINX ut servitorem interretialem usi sumus, sed facile est eum cum Apache substituere, tantum exemplar in fasciculo mutandum est. Imago NGINX on Imago Apache.

conclusio,

In prima parte huius seriei, demonstravimus quomodo celeriter applicationes interretiales modernas in suggestu OpenShift disponas. Hodie, inspeximus quid imago Applicationis Interretialis faciat et quomodo cum servo interretiali nativo, ut NGINX, per structuras concatenatas coniungi possit ad structuram applicationis productioni magis paratam creandam. In proximo et ultimo articulo huius seriei, demonstrabimus quomodo servum progressionis pro applicatione tua in OpenShift incipias et fasciculos locales et remotos synchronizatos serves.

Contenta huius seriei articulorum

Pars II: Quomodo applicationes interretiales modernas paucis tantum gradibus instruere;
Pars II: Quomodo nova imago S2I una cum imagine servi HTTP iam exsistente, ut NGINX, per structuras OpenShift conexas adhibeatur ad distributionem productionis efficiendam;
Pars III: Quomodo servum evolutionis pro applicatione tua in suggestu OpenShift currere et cum systemate fasciculorum locali synchronizare.