🥇Mga modernong application sa OpenShift, bahagi 3: OpenShift bilang isang development environment at OpenShift Pipelines

Kumusta sa lahat ng nasa blog na ito! Ito ang ikatlong post sa isang serye kung saan ipinapakita namin kung paano mag-deploy ng mga modernong web application sa Red Hat OpenShift.

Sa nakaraang dalawang post, ipinakita namin kung paano mag-deploy ng mga modernong web application sa ilang hakbang lang at kung paano gumamit ng bagong S2I na imahe kasama ang isang off-the-shelf na imahe ng HTTP server, gaya ng NGINX, gamit ang mga chained build para i-orkestrate ang mga deployment ng produksyon .

Ngayon ay ipapakita namin kung paano magpatakbo ng isang development server para sa iyong aplikasyon sa OpenShift platform at i-synchronize ito sa lokal na file system, at pag-uusapan din kung ano ang OpenShift Pipelines at kung paano ito magagamit bilang alternatibo sa mga naka-link na assemblies.

OpenShift bilang isang development environment

Daloy ng trabaho sa pag-unlad

Gaya ng nakasaad sa unang post, ang karaniwang proseso ng pag-develop para sa mga modernong web application ay isang uri lamang ng "development server" na sumusubaybay sa mga pagbabago sa mga lokal na file. Kapag nangyari ang mga ito, ma-trigger ang pagbuo ng application at pagkatapos ay ia-update ito sa browser.

Sa karamihan ng mga modernong balangkas, ang naturang "server ng pag-unlad" ay binuo sa kaukulang mga tool sa command line.

Lokal na halimbawa

Una, tingnan natin kung paano ito gumagana kapag lokal na nagpapatakbo ng mga application. Kunin natin ang aplikasyon bilang isang halimbawa Gantihin mula sa mga nakaraang artikulo, bagama't halos pareho ang mga konsepto ng daloy ng trabaho sa lahat ng iba pang modernong balangkas.
Kaya, upang simulan ang "dev server" sa aming React na halimbawa, ilalagay namin ang sumusunod na command:

$ npm run start

Pagkatapos ay sa terminal window makikita natin ang isang bagay na tulad nito:

At magbubukas ang aming application sa default na browser:

Ngayon, kung gumawa kami ng mga pagbabago sa file, ang application ay dapat mag-update sa browser.

OK, ang lahat ay malinaw sa pag-unlad sa lokal na mode, ngunit paano makamit ang pareho sa OpenShift?

Development server sa OpenShift

Kung naaalala mo, sa Nakaraang post, tiningnan namin ang tinatawag na run phase ng S2I image at nakita namin na bilang default, responsable ang serve module para sa pagseserbisyo sa aming web application.

Gayunpaman, kung titingnan mo nang mas malapitan patakbuhin ang script mula sa halimbawang iyon, naglalaman ito ng variable ng kapaligiran na $NPM_RUN, na nagbibigay-daan sa iyong isagawa ang iyong utos.

Halimbawa, maaari naming gamitin ang nodeshift module upang i-deploy ang aming application:

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

Tandaan: Ang halimbawa sa itaas ay pinaikli upang ilarawan ang pangkalahatang ideya.

Dito nagdagdag kami ng isang NPM_RUN environment variable sa aming deployment, na nagsasabi sa runtime na patakbuhin ang yarn start command, na magsisimula sa React development server sa loob ng aming OpenShift pod.

Kung titingnan mo ang log ng isang tumatakbong pod, magiging ganito ang hitsura:

Siyempre, ang lahat ng ito ay magiging wala hanggang sa ma-synchronize natin ang lokal na code sa code, na sinusubaybayan din para sa mga pagbabago, ngunit nabubuhay sa isang malayong server.

Pag-synchronize ng remote at lokal na code

Sa kabutihang palad, madaling tumulong ang nodeshift sa pag-synchronize, at magagamit mo ang command sa relo upang subaybayan ang mga pagbabago.

Kaya pagkatapos naming patakbuhin ang command na i-deploy ang development server para sa aming application, maaari naming ligtas na gamitin ang sumusunod na command:

$ npx nodeshift watch

Bilang resulta, ang isang koneksyon ay gagawin sa tumatakbong pod na ginawa namin nang mas maaga, ang pag-synchronize ng aming mga lokal na file sa remote cluster ay isaaktibo, at ang mga file sa aming lokal na system ay magsisimulang masubaybayan para sa mga pagbabago.

Samakatuwid, kung i-update namin ngayon ang src/App.js file, ang system ay magre-react sa mga pagbabagong ito, kopyahin ang mga ito sa remote cluster at simulan ang development server, na mag-a-update sa aming application sa browser.

Para kumpletuhin ang larawan, ipakita natin kung ano ang hitsura ng buong command na ito:

$ 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

Ang utos ng relo ay isang abstraction sa ibabaw ng oc rsync na utos, maaari kang matuto nang higit pa tungkol sa kung paano ito gumagana dito.

Ito ay isang halimbawa para sa React, ngunit ang eksaktong parehong paraan ay maaaring gamitin sa iba pang mga frameworks, itakda lamang ang NPM_RUN environment variable kung kinakailangan.

Mga Openhift Pipeline

Susunod na pag-uusapan natin ang tungkol sa isang tool tulad ng OpenShift Pipelines at kung paano ito magagamit bilang alternatibo sa mga chained build.

Ano ang OpenShift Pipelines

Ang OpenShift Pipelines ay isang cloud-native na CI/CD na tuluy-tuloy na pagsasama at sistema ng paghahatid na idinisenyo para sa pag-aayos ng mga pipeline gamit ang Tekton. Ang Tekton ay isang flexible na open-source na Kubernetes-native CI/CD framework na nagbibigay-daan sa iyong i-automate ang deployment sa iba't ibang platform (Kubernetes, serverless, virtual machine, atbp.) sa pamamagitan ng pag-abstract mula sa pinagbabatayan na layer.

Ang pag-unawa sa artikulong ito ay nangangailangan ng ilang kaalaman sa Pipelines, kaya lubos naming inirerekomenda na basahin mo muna opisyal na aklat-aralin.

Pag-set up ng iyong kapaligiran sa trabaho

Upang maglaro sa mga halimbawa sa artikulong ito, kailangan mo munang ihanda ang iyong kapaligiran sa pagtatrabaho:

Mag-install at mag-configure ng OpenShift 4 cluster. Gumagamit ang aming mga halimbawa ng CodeReady Containers (CRD) para dito, ang mga tagubilin sa pag-install kung saan makikita dito.
Matapos ang kumpol ay handa na, kailangan mong i-install ang Pipeline Operator dito. Huwag matakot, ito ay madali, mga tagubilin sa pag-install dito.
Mag-download Tekton CLI (tkn) dito.
Patakbuhin ang create-react-app na command line tool upang lumikha ng isang application na iyong i-deploy (ito ay isang simpleng application Gantihin).
(Opsyonal) I-clone ang repository upang patakbuhin ang halimbawang application nang lokal gamit ang npm install at pagkatapos ay npm start.

Magkakaroon din ng k8s folder ang repository ng application, na maglalaman ng mga Kubernetes/OpenShift YAML na ginamit sa pag-deploy ng application. Magkakaroon ng Tasks, ClusterTasks, Resources at Pipelines na gagawin namin dito mga repositoryo.

Magsimula na tayo

Ang unang hakbang para sa aming halimbawa ay ang lumikha ng bagong proyekto sa OpenShift cluster. Tawagan natin ang proyektong ito na webapp-pipeline at likhain ito gamit ang sumusunod na command:

$ oc new-project webapp-pipeline

Lalabas ang pangalan ng proyektong ito sa code sa ibang pagkakataon, kaya kung magpasya kang pangalanan ito sa ibang bagay, huwag kalimutang i-edit ang halimbawang code nang naaayon. Simula sa puntong ito, hindi kami pupunta sa itaas-pababa, ngunit sa ibaba-pataas: iyon ay, gagawa muna kami ng lahat ng mga bahagi ng conveyor, at pagkatapos ay ang conveyor mismo.

Kaya, una sa lahat...

Mga gawain

Gumawa tayo ng ilang gawain, na makakatulong sa pag-deploy ng application sa loob ng ating pipeline. Ang unang gawain - apply_manifests_task - ay responsable para sa paglalapat ng YAML ng mga mapagkukunan ng Kubernetes (serbisyo, deployment at ruta) na matatagpuan sa folder ng k8s ng aming application. Ang pangalawang gawain - update_deployment_task - ay responsable para sa pag-update ng isang naka-deploy na imahe sa isang nilikha ng aming pipeline.

Huwag mag-alala kung hindi pa masyadong malinaw. Sa katunayan, ang mga gawaing ito ay parang mga utility, at titingnan natin ang mga ito nang mas detalyado sa ibang pagkakataon. Sa ngayon, likhain na lang natin sila:

$ 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

Pagkatapos, gamit ang tkn CLI command, susuriin namin na ang mga gawain ay nalikha na:

$ tkn task ls

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

Tandaan: Ito ang mga lokal na gawain para sa iyong kasalukuyang proyekto.

Mga gawain sa pangkat

Ang mga gawain ng cluster ay karaniwang kapareho ng mga simpleng gawain. Iyon ay, ito ay isang magagamit muli na koleksyon ng mga hakbang na pinagsama sa isang paraan o iba pa kapag nagpapatakbo ng isang partikular na gawain. Ang pagkakaiba ay ang isang gawain ng kumpol ay magagamit saanman sa loob ng kumpol. Para makita ang listahan ng mga cluster task na awtomatikong nagagawa kapag nagdaragdag ng Pipeline Operator, muli naming gagamitin ang tkn CLI command:

$ 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

Ngayon, gumawa tayo ng dalawang cluster task. Ang una ay bubuo ng S2I na imahe at ipapadala ito sa panloob na OpenShift registry; ang pangalawa ay ang pagbuo ng aming imahe batay sa NGINX, gamit ang application na binuo na namin bilang nilalaman.

Lumikha at ipadala ang larawan

Kapag gumagawa ng unang gawain, uulitin namin ang ginawa na namin sa nakaraang artikulo tungkol sa mga naka-link na asembliya. Alalahanin na ginamit namin ang S2I na imahe (ubi8-s2i-web-app) upang "buuin" ang aming application, at nagtapos sa isang imahe na nakaimbak sa panloob na registry ng OpenShift. Ngayon ay gagamitin namin ang S2I web app na imahe na ito upang lumikha ng isang DockerFile para sa aming app at pagkatapos ay gamitin ang Buildah upang gawin ang aktwal na pagbuo at itulak ang magreresultang imahe sa panloob na registry ng OpenShift, dahil iyon mismo ang ginagawa ng OpenShift kapag nag-deploy ka ng iyong mga application gamit ang NodeShift .

Paano namin nalaman ang lahat ng ito, tanong mo? Mula sa opisyal na bersyon ng opisyal na Node.js, kinopya lang namin ito at binago para sa sarili namin.

Kaya, ngayon gawin natin ang s2i-web-app cluster task:

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

Hindi namin ito susuriin nang detalyado, ngunit tututuon lamang ang parameter na OUTPUT_DIR:

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

Bilang default, ang parameter na ito ay katumbas ng build, kung saan inilalagay ng React ang naka-assemble na content. Ang ibang mga framework ay gumagamit ng iba't ibang mga landas, halimbawa, sa Ember ito ay dist. Ang output ng aming unang cluster task ay isang larawang naglalaman ng HTML, JavaScript, at CSS na aming nakolekta.

Bumuo ng isang imahe batay sa NGINX

Para sa aming pangalawang gawain ng cluster, dapat itong bumuo ng isang NGINX-based na imahe para sa amin, gamit ang nilalaman ng application na naitayo na namin. Sa esensya, ito ang bahagi ng nakaraang seksyon kung saan tiningnan namin ang mga chained build.

Upang gawin ito, kami - eksaktong kapareho ng nasa itaas - ay gagawa ng isang cluster task na webapp-build-runtime:

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

Kung titingnan mo ang code ng mga cluster task na ito, makikita mo na hindi nito tinukoy ang Git repository na pinagtatrabahuhan namin o ang mga pangalan ng mga imaheng ginagawa namin. Tinukoy lang namin kung ano ang eksaktong inililipat namin sa Git, o isang partikular na imahe kung saan dapat na output ang huling larawan. Iyon ang dahilan kung bakit ang mga gawaing cluster na ito ay maaaring magamit muli kapag nagtatrabaho sa iba pang mga application.

At dito tayo ay magiliw na lumipat sa susunod na punto...

Mga Mapagkukunan

Kaya, dahil, tulad ng sinabi namin, ang mga gawain ng kumpol ay dapat na pangkalahatan hangga't maaari, kailangan naming lumikha ng mga mapagkukunan na gagamitin bilang input (ang Git repository) at bilang output (ang mga huling larawan). Ang unang mapagkukunan na kailangan namin ay ang Git, kung saan naninirahan ang aming application, tulad nito:

# 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

Narito ang PipelineResource ay may uri na git. Ang url key sa seksyon ng params ay tumuturo sa isang partikular na imbakan at tinutukoy ang master branch (ito ay opsyonal, ngunit isinusulat namin ito para sa pagkakumpleto).

Ngayon ay kailangan naming lumikha ng isang mapagkukunan para sa imahe kung saan ang mga resulta ng s2i-web-app na gawain ay mai-save, ito ay ginagawa tulad nito:

# 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

Narito ang PipelineResource ay may uri ng imahe, at ang halaga ng parameter ng url ay tumuturo sa panloob na OpenShift Image Registry, partikular ang isa na matatagpuan sa webapp-pipeline namespace. Huwag kalimutang baguhin ang setting na ito kung gumagamit ka ng ibang namespace.

At sa wakas, ang huling mapagkukunan na kailangan namin ay magiging uri din ng imahe at ito ang magiging huling NGINX na imahe na gagamitin sa panahon ng pag-deploy:

# 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

Muli, tandaan na ang mapagkukunang ito ay nag-iimbak ng imahe sa panloob na OpenShift registry sa webapp-pipeline namespace.

Upang gawin ang lahat ng mga mapagkukunang ito nang sabay-sabay, ginagamit namin ang command na lumikha:

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

Maaari mong tiyakin na ang mga mapagkukunan ay ginawa tulad nito:

$ tkn resource ls

Pipeline ng conveyor

Ngayon na mayroon na tayo ng lahat ng kinakailangang sangkap, mag-assemble tayo ng pipeline mula sa kanila sa pamamagitan ng paggawa nito gamit ang sumusunod na command:

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

Ngunit bago natin patakbuhin ang utos na ito, tingnan natin ang mga bahaging ito. Ang una ay ang pangalan:

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

Pagkatapos, sa seksyon ng spec nakikita namin ang isang indikasyon ng mga mapagkukunang ginawa namin kanina:

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

Pagkatapos ay gagawin namin ang mga gawain na kailangang tapusin ng aming pipeline. Una sa lahat, dapat nitong isagawa ang s2i-web-app na gawain na nagawa na namin:

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

Ang gawaing ito ay tumatagal ng mga parameter ng input (gir resource) at output (built-web-application-image resource). Ipinapasa din namin ito ng isang espesyal na parameter upang hindi nito ma-verify ang TLS dahil gumagamit kami ng mga self-signed na certificate:

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

Ang susunod na gawain ay halos pareho, dito lamang ang webapp-build-runtime cluster task na nagawa na natin ay tinatawag na:

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

Tulad ng sa nakaraang gawain, pumasa kami sa isang mapagkukunan, ngunit ngayon ito ay built-web-application-image (ang output ng aming nakaraang gawain). At bilang isang output muli naming itinakda ang imahe. Dahil ang gawaing ito ay dapat isagawa pagkatapos ng nauna, idinagdag namin ang runAfter na patlang:

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

Ang susunod na dalawang gawain ay responsable para sa paggamit ng serbisyo, ruta at pag-deploy ng mga YAML file na nakatira sa k8s na direktoryo ng aming web application, at para din sa pag-update ng deployment na ito kapag gumagawa ng mga bagong larawan. Tinukoy namin ang dalawang gawaing kumpol na ito sa simula ng artikulo.

Pagsisimula ng conveyor

Kaya, ang lahat ng bahagi ng aming pipeline ay nilikha, at patakbuhin namin ito gamit ang sumusunod na command:

$ tkn pipeline start build-and-deploy-react

Sa yugtong ito, interactive na ginagamit ang command line at kailangan mong piliin ang naaangkop na mapagkukunan bilang tugon sa bawat kahilingan nito: para sa git resource, piliin ang web-application-repo, pagkatapos ay para sa unang mapagkukunan ng imahe, built-web-application. -image, at panghuli, para sa pangalawang mapagkukunan ng imahe –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

Ngayon suriin natin ang katayuan ng pipeline gamit ang sumusunod na command:

$ tkn pipeline logs -f

Kapag nagsimula na ang pipeline at nai-deploy na ang application, maaari naming hilingin ang na-publish na ruta gamit ang sumusunod na command:

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

Para sa mas malawak na visualization, maaari mong tingnan ang aming pipeline sa Developer mode ng web console sa seksyon Pipelines, tulad ng ipinapakita sa Fig. 1.

Fig.1. Pagsusuri ng mga tumatakbong pipeline.

Ang pag-click sa tumatakbong pipeline ay nagpapakita ng mga karagdagang detalye, tulad ng ipinapakita sa Figure 2.

kanin. 2. Karagdagang impormasyon tungkol sa pipeline.

Pagkatapos ng higit pang impormasyon, makikita mo ang mga tumatakbong application sa view topology, tulad ng ipinapakita sa Fig.3.

Fig 3. Inilunsad ang pod.

Ang pag-click sa bilog sa kanang sulok sa itaas ng icon ay magbubukas sa aming application, tulad ng ipinapakita sa Fig. 4.

kanin. 4. Running React application.

Konklusyon

Kaya, ipinakita namin kung paano magpatakbo ng isang development server para sa iyong aplikasyon sa OpenShift at i-synchronize ito sa lokal na file system. Tiningnan din namin kung paano gayahin ang isang chained-build na template gamit ang OpenShift Pipelines. Ang lahat ng mga halimbawang code mula sa artikulong ito ay matatagpuan dito.

Mga karagdagang mapagkukunan (EN)

Mga anunsyo ng paparating na mga webinar

Nagsisimula kami ng serye ng mga webinar sa Biyernes tungkol sa katutubong karanasan gamit ang Red Hat OpenShift Container Platform at Kubernetes:

Pinagmulan: www.habr.com

Mga modernong application sa OpenShift, bahagi 3: OpenShift bilang isang development environment at OpenShift Pipelines