🥇Modernaj aplikoj sur OpenShift, parto 3: OpenShift kiel evolumedio kaj OpenShift Pipelines

Saluton al ĉiuj en ĉi tiu blogo! Ĉi tiu estas la tria afiŝo en serio, en kiu ni montras kiel disfaldi modernajn TTT-aplikaĵojn sur Red Hat OpenShift.

En la antaŭaj du afiŝoj, ni montris kiel disfaldi modernajn TTT-aplikaĵojn en nur kelkaj paŝoj kaj kiel uzi novan S2I-bildon kune kun neŝparebla HTTP-servila bildo, kiel NGINX, uzante ĉenitajn konstruojn por reĝisori produktaddeplojojn. .

Hodiaŭ ni montros kiel ruli disvolvan servilon por via aplikaĵo sur la platformo OpenShift kaj sinkronigi ĝin kun la loka dosiersistemo, kaj ankaŭ parolos pri kio estas OpenShift Pipelines kaj kiel ili povas esti uzataj kiel alternativo al ligitaj kunigoj.

OpenShift kiel evolumedio

Disvolva laborfluo

Kiel jam dirite en unua afiŝo, la tipa evoluprocezo por modernaj TTT-aplikoj estas simple ia "evoluservilo" kiu spuras ŝanĝojn al lokaj dosieroj. Kiam ili okazas, la aplikaĵo estas ekigita kaj tiam ĝi estas ĝisdatigita al la retumilo.

En la plej multaj modernaj kadroj, tia "disvolva servilo" estas konstruita en la respondajn komandliniajn ilojn.

Loka ekzemplo

Unue, ni vidu kiel ĉi tio funkcias dum rulado de aplikaĵoj loke. Ni prenu la aplikaĵon kiel ekzemplon Reagi de antaŭaj artikoloj, kvankam preskaŭ la samaj laborflukonceptoj validas en ĉiuj aliaj modernaj kadroj.
Do, por komenci la "dev-servilon" en nia React-ekzemplo, ni enigos la sekvan komandon:

$ npm run start

Tiam en la fina fenestro ni vidos ion tian:

Kaj nia aplikaĵo malfermos en la defaŭlta retumilo:

Nun, se ni faras ŝanĝojn al la dosiero, la aplikaĵo devus ĝisdatigi en la retumilo.

Bone, ĉio estas klara kun evoluo en loka reĝimo, sed kiel atingi la samon en OpenShift?

Disvolva servilo sur OpenShift

Se vi memoras, en antaŭa afiŝo, ni rigardis la tielnomitan kuro-fazon de la S2I-bildo kaj vidis, ke defaŭlte, la servomodulo respondecas pri servado de nia retejo-aplikaĵo.

Tamen, se vi rigardas pli detale ruli skripton de tiu ekzemplo, ĝi enhavas la mediovariablon $NPM_RUN, kiu ebligas al vi ekzekuti vian komandon.

Ekzemple, ni povas uzi la nodeshift-modulon por deploji nian aplikaĵon:

$ npx nodeshift --deploy.env NPM_RUN="yarn start" --dockerImage=nodeshift/ubi8-s2i-web-app

Noto: La supra ekzemplo estas mallongigita por ilustri la ĝeneralan ideon.

Ĉi tie ni aldonis la mediovariablon NPM_RUN al nia deplojo, kiu diras al la rultempo ruli la komandon de lanĉado de fadeno, kiu lanĉas la disvolvan servilon React ene de nia OpenShift-podo.

Se vi rigardas la protokolon de kuranta pod, ĝi aspektos kiel ĉi tio:

Kompreneble, ĉio ĉi estos nenio ĝis ni povos sinkronigi la lokan kodon kun la kodo, kiu ankaŭ estas monitorita por ŝanĝoj, sed vivas en fora servilo.

Sinkronigante fora kaj loka kodo

Feliĉe, nodesshift povas facile helpi kun sinkronigado, kaj vi povas uzi la horloĝan komandon por spuri ŝanĝojn.

Do post kiam ni rulis la komandon por disfaldi la evoluservilon por nia aplikaĵo, ni povas sekure uzi la jenan komandon:

$ npx nodeshift watch

Kiel rezulto, konekto estos farita al la kuranta pod, kiun ni kreis iom pli frue, la sinkronigado de niaj lokaj dosieroj kun la fora areto estos aktivigita, kaj la dosieroj en nia loka sistemo komencos esti monitoritaj por ŝanĝoj.

Tial, se ni nun ĝisdatigas la src/App.js-dosieron, la sistemo reagos al ĉi tiuj ŝanĝoj, kopios ilin al la fora areto kaj lanĉos la evoluservilon, kiu tiam ĝisdatigos nian aplikaĵon en la retumilo.

Por kompletigi la bildon, ni montru kiel aspektas ĉi tiuj tutaj komandoj:

$ 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

La watch-komando estas abstraktaĵo supre de la oc rsync-komando, vi povas lerni pli pri kiel ĝi funkcias tie.

Ĉi tio estis ekzemplo por React, sed la ĝusta sama metodo povas esti uzata kun aliaj kadroj, simple agordu la mediovariablon NPM_RUN kiel necese.

Openshift Pipelines

Poste ni parolos pri ilo kiel OpenShift Pipelines kaj kiel ĝi povas esti uzata kiel alternativo al ĉenitaj konstruoj.

Kio estas OpenShift Pipelines

OpenShift Pipelines estas nub-indiĝena CI/KD kontinua integriĝo kaj liversistemo dizajnita por organizado de duktoj uzante Tekton. Tekton estas fleksebla malfermfonta Kubernetes-denaska CI/KD-kadro, kiu ebligas al vi aŭtomatigi deplojon sur diversaj platformoj (Kubernetes, senservila, virtualaj maŝinoj, ktp.) per abstraktado de la subesta tavolo.

Kompreni ĉi tiun artikolon postulas iom da scio pri Pipelines, do ni forte rekomendas, ke vi unue legu oficiala lernolibro.

Agordi vian labormedion

Por ludi kun la ekzemploj en ĉi tiu artikolo, vi unue devas prepari vian labormedion:

Instalu kaj agordu OpenShift 4-grupon. Niaj ekzemploj uzas CodeReady Containers (CRD) por tio, por kiuj troviĝas instrukcioj pri instalado. tie.
Post kiam la areto estas preta, vi devas instali Pipeline Operator sur ĝi. Ne timu, ĝi estas facila, instrukcioj pri instalado tie.
Elŝutu Tekton CLI (tkn) tie.
Rulu la ilon de komandlinio create-react-app por krei aplikaĵon, kiun vi poste disfaldigos (ĉi tio estas simpla aplikaĵo Reagi).
(Laŭvola) Klonu la deponejon por ruli la ekzemplaplikaĵon loke kun npm instalo kaj poste npm start.

La aplikaĵa deponejo ankaŭ havos k8s-dosierujon, kiu enhavos la Kubernetes/OpenShift-YAMLs uzatajn por disfaldi la aplikaĵon. Estos Taskoj, ClusterTasks, Rimedoj kaj Duktoj, kiujn ni kreos en ĉi tiu deponejoj.

Ni komencu

La unua paŝo por nia ekzemplo estas krei novan projekton en la OpenShift-grupo. Ni nomu ĉi tiun projekton webapp-pipeline kaj kreu ĝin per la sekva komando:

$ oc new-project webapp-pipeline

Ĉi tiu projektnomo aperos en la kodo poste, do se vi decidas nomi ĝin alie, ne forgesu redakti la ekzemplan kodon laŭe. Komencante de ĉi tiu punkto, ni ne iros desupre, sed de sube: tio estas, ni unue kreos ĉiujn komponantojn de la transportilo, kaj nur tiam la transportilo mem.

Do, antaŭ ĉio...

Taskoj

Ni kreu kelkajn taskojn, kiuj tiam helpos disfaldi la aplikaĵon ene de nia dukto. La unua tasko - apply_manifests_task - respondecas pri aplikado de la YAML de tiuj Kubernetes-resursoj (servo, deplojo kaj itinero) kiuj troviĝas en la dosierujo k8s de nia aplikaĵo. La dua tasko - update_deployment_task - respondecas pri ĝisdatigo de jam deplojita bildo al tiu kreita de nia dukto.

Ne zorgu, se ĝi ankoraŭ ne estas tre klara. Fakte, ĉi tiuj taskoj estas io kiel utilecoj, kaj ni rigardos ilin pli detale iom poste. Nuntempe, ni simple kreu ilin:

$ 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

Poste, uzante la komandon tkn CLI, ni kontrolos, ke la taskoj estas kreitaj:

$ tkn task ls

NAME                AGE
apply-manifests     1 minute ago
update-deployment   1 minute ago

Noto: Ĉi tiuj estas lokaj taskoj por via nuna projekto.

Aretaj taskoj

Aretaj taskoj estas esence la samaj kiel simplaj taskoj. Tio estas, ĝi estas reuzebla kolekto de paŝoj, kiuj estas kombinitaj laŭ unu maniero aŭ alia kiam ruliĝas specifa tasko. La diferenco estas, ke clustertasko disponeblas ĉie ene de la areto. Por vidi la liston de grapoltaskoj, kiuj aŭtomate kreiĝas aldonante Pipeline Operator, ni denove uzos la komandon 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

Nun ni kreu du grupajn taskojn. La unua generos la S2I-bildon kaj sendos ĝin al la interna OpenShift-registro; la dua estas konstrui nian bildon bazitan sur NGINX, uzante la aplikaĵon, kiun ni jam konstruis kiel enhavo.

Kreu kaj sendu la bildon

Kreante la unuan taskon, ni ripetos tion, kion ni jam faris en la antaŭa artikolo pri ligitaj asembleoj. Memoru, ke ni uzis la S2I-bildon (ubi8-s2i-web-app) por "konstrui" nian aplikaĵon, kaj finis kun bildo konservita en la interna registro de OpenShift. Nun ni uzos ĉi tiun bildon de la retejo de S2I por krei DockerFile por nia programo kaj poste uzos Buildah por fari la realan konstruon kaj puŝi la rezultan bildon al la interna registro de OpenShift, ĉar ĝuste tion OpenShift faras kiam vi deplojas viajn aplikaĵojn uzante NodeShift. .

Kiel ni sciis ĉion ĉi, vi demandas? De oficiala versio de oficiala Node.js, ni nur kopiis ĝin kaj modifis ĝin por ni mem.

Do, nun ni kreu la taskon s2i-web-app-grupo:

$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/clustertasks/s2i-web-app-task.yaml

Ni ne analizos ĉi tion detale, sed nur koncentriĝos pri la parametro OUTPUT_DIR:

params:
      - name: OUTPUT_DIR
        description: The location of the build output directory
        default: build

Defaŭlte, ĉi tiu parametro estas egala al konstruo, kiu estas kie React metas la kunmetitan enhavon. Aliaj kadroj uzas malsamajn vojojn, ekzemple, en Ember ĝi estas dist. La eligo de nia unua clustertasko estos bildo enhavanta la HTML, JavaScript kaj CSS, kiujn ni kolektis.

Konstruu bildon bazitan sur NGINX

Koncerne al nia dua cluster-tasko, ĝi devus konstrui NGINX-bazitan bildon por ni, uzante la enhavon de la aplikaĵo, kiun ni jam konstruis. Esence, ĉi tio estas la parto de la antaŭa sekcio, kie ni rigardis ĉenitajn konstruojn.

Por fari tion, ni - ekzakte la sama kiel ĵus supre - kreos grapoltaskon webapp-build-runtime:

$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/clustertasks/webapp-build-runtime-task.yaml

Se vi rigardas la kodon por ĉi tiuj clustertaskoj, vi povas vidi, ke ĝi ne specifas la Git-deponejon, kun kiu ni laboras, aŭ la nomojn de la bildoj, kiujn ni kreas. Ni nur precizigas, kion ni transdonas al Git, aŭ certan bildon, kie la fina bildo estu eligita. Tial ĉi tiuj arettaskoj povas esti reuzitaj kiam oni laboras kun aliaj aplikoj.

Kaj ĉi tie ni gracie transiras al la sekva punkto...

Rimedoj

Do, ĉar, kiel ni ĵus diris, clustertaskoj devus esti kiel eble plej ĝeneralaj, ni devas krei rimedojn kiuj estos uzataj kiel enigo (la Git-deponejo) kaj kiel eligo (la finaj bildoj). La unua rimedo, kiun ni bezonas, estas Git, kie loĝas nia aplikaĵo, io kiel ĉi tio:

# 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

Ĉi tie PipelineResource estas de tipo git. La url-ŝlosilo en la sekcio params montras al specifa deponejo kaj specifas la majstran branĉon (ĉi tio estas laŭvola, sed ni skribas ĝin por kompleteco).

Nun ni devas krei rimedon por la bildo, kie la rezultoj de la tasko s2i-web-app estos konservitaj, ĉi tio fariĝas jene:

# 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

Ĉi tie la PipelineResource estas de tipo bildo, kaj la valoro de la url-parametro montras al la interna OpenShift Image Registry, specife tiu situanta en la webapp-pipeline nomspaco. Ne forgesu ŝanĝi ĉi tiun agordon se vi uzas alian nomspacon.

Kaj finfine, la lasta rimedo, kiun ni bezonas, ankaŭ estos de tipo bildo kaj ĉi tio estos la fina bildo NGINX, kiu tiam estos uzata dum deplojo:

# 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

Denove, notu, ke ĉi tiu rimedo konservas la bildon en la interna OpenShift-registro en la webapp-pipeline nomspaco.

Por krei ĉiujn ĉi tiujn rimedojn samtempe, ni uzas la krei komandon:

$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/resources/resource.yaml

Vi povas certigi, ke la rimedoj estas kreitaj tiel:

$ tkn resource ls

Transportildukto

Nun kiam ni havas ĉiujn necesajn komponantojn, ni kunvenu dukton de ili kreante ĝin per la sekva komando:

$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/pipelines/build-and-deploy-react.yaml

Sed antaŭ ol ni ruli ĉi tiun komandon, ni rigardu ĉi tiujn komponantojn. La unua estas la nomo:

apiVersion: tekton.dev/v1alpha1
kind: Pipeline
metadata:
  name: build-and-deploy-react

Tiam en la specsekcio ni vidas indikon pri la rimedoj, kiujn ni kreis pli frue:

spec:
  resources:
    - name: web-application-repo
      type: git
    - name: built-web-application-image
      type: image
    - name: runtime-web-application-image
      type: image

Ni tiam kreas la taskojn, kiujn nia dukto devas plenumi. Antaŭ ĉio, ĝi devas ekzekuti la taskon s2i-web-app, kiun ni jam kreis:

tasks:
    - name: build-web-application
      taskRef:
        name: s2i-web-app
        kind: ClusterTask

Ĉi tiu tasko prenas parametrojn de enigo (gir-rimedo) kaj eligo (konstruita-ret-apliko-bilda rimedo). Ni ankaŭ pasas al ĝi specialan parametron por ke ĝi ne konfirmu TLS ĉar ni uzas memsubskribitajn atestojn:

resources:
        inputs:
          - name: source
            resource: web-application-repo
        outputs:
          - name: image
            resource: built-web-application-image
      params:
        - name: TLSVERIFY
          value: "false"

La sekva tasko estas preskaŭ la sama, nur ĉi tie la tasko webapp-build-runtime cluster, kiun ni jam kreis, nomiĝas:

name: build-runtime-image
    taskRef:
      name: webapp-build-runtime
      kind: ClusterTask

Kiel ĉe la antaŭa tasko, ni endonas rimedon, sed nun ĝi estas konstruita-ret-aplikaĵo-bildo (la eligo de nia antaŭa tasko). Kaj kiel eligo ni denove starigas la bildon. Ĉar ĉi tiu tasko devas esti plenumita post la antaŭa, ni aldonas la kampon 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

La sekvaj du taskoj respondecas pri uzado de la YAML-dosieroj de servo, itinero kaj deplojo, kiuj loĝas en la dosierujo k8s de nia retejo, kaj ankaŭ por ĝisdatigi ĉi tiun disfaldiĝon dum kreado de novaj bildoj. Ni difinis ĉi tiujn du grupajn taskojn komence de la artikolo.

Ekfunkciigante la transportilon

Do, ĉiuj partoj de nia dukto estas kreitaj, kaj ni rulos ĝin per la sekva komando:

$ tkn pipeline start build-and-deploy-react

En ĉi tiu etapo, la komandlinio estas uzata interage kaj vi devas elekti la taŭgajn rimedojn responde al ĉiu el ĝiaj petoj: por la git-rimedo, elektu web-application-repo, tiam por la unua bilda rimedo, built-web-application. -image, kaj finfine, por dua bilda rimedo -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

Nun ni kontrolu la staton de la dukto per la sekva komando:

$ tkn pipeline logs -f

Post kiam la dukto komenciĝis kaj la aplikaĵo estas deplojita, ni povas peti la publikigitan itineron per la sekva komando:

$ oc get route react-pipeline-example --template='http://{{.spec.host}}'

Por pli granda bildigo, vi povas vidi nian dukton en la Ellaboranto-reĝimo de la retejo-konzolo en la sekcio Duktoj, kiel montrite en Fig. 1.

Fig.1. Revizio de kurantaj duktoj.

Klako sur kuranta dukto montras pliajn detalojn, kiel montrite en Figuro 2.

Rizo. 2. Pliaj informoj pri la dukto.

Post pli da informoj, vi povas vidi kurantajn aplikojn en la vido Topologio, kiel montrite en Fig.3.

Figo 3. Lanĉita pod.

Alklakante la cirklon en la supra dekstra angulo de la ikono malfermas nian aplikaĵon, kiel montrite en Fig. 4.

Rizo. 4. Kurante React-aplikaĵon.

konkludo

Do, ni montris kiel ruli evoluservilon por via aplikaĵo sur OpenShift kaj sinkronigi ĝin kun la loka dosiersistemo. Ni ankaŭ rigardis kiel simuli ĉenkonstruitan ŝablonon uzante OpenShift Pipelines. Ĉiuj ekzemplaj kodoj de ĉi tiu artikolo troveblas tie.

Kromaj rimedoj (EN)

Anoncoj de venontaj retseminarioj

Ni komencas serion de vendredaj retseminarioj pri denaska sperto uzante Red Hat OpenShift Container Platform kaj Kubernetes:

fonto: www.habr.com

Modernaj aplikoj sur OpenShift, parto 3: OpenShift kiel evolumedio kaj OpenShift Pipelines