ຄໍາຮ້ອງສະຫມັກທີ່ທັນສະໄຫມໃນ OpenShift, ສ່ວນທີ 3: OpenShift ເປັນສະພາບແວດລ້ອມການພັດທະນາແລະ OpenShift Pipelines

ສະບາຍດີທຸກຄົນໃນ blog ນີ້! ນີ້ແມ່ນການຕອບທີສາມໃນຊຸດທີ່ພວກເຮົາສະແດງວິທີການນໍາໃຊ້ເວັບທີ່ທັນສະໄຫມໃນ Red Hat OpenShift.

ໃນສອງຂໍ້ຄວາມທີ່ຜ່ານມາ, ພວກເຮົາໄດ້ສະແດງວິທີການນໍາໃຊ້ຄໍາຮ້ອງສະຫມັກເວັບທີ່ທັນສະໄຫມໃນສອງສາມຂັ້ນຕອນແລະວິທີການນໍາໃຊ້ຮູບພາບ S2I ໃຫມ່ພ້ອມກັບຮູບພາບ HTTP ອອກຈາກຊັ້ນວາງຂອງເຄື່ອງແມ່ຂ່າຍ, ເຊັ່ນ NGINX, ການນໍາໃຊ້ການສ້າງລະບົບຕ່ອງໂສ້ເພື່ອຈັດຕັ້ງການຜະລິດການຜະລິດ. .

ມື້ນີ້ພວກເຮົາຈະສະແດງວິທີການດໍາເນີນການເຊີຟເວີການພັດທະນາສໍາລັບຄໍາຮ້ອງສະຫມັກຂອງທ່ານໃນເວທີ OpenShift ແລະ synchronize ມັນກັບລະບົບໄຟລ໌ທ້ອງຖິ່ນ, ແລະຍັງເວົ້າກ່ຽວກັບ OpenShift Pipelines ແມ່ນຫຍັງແລະວິທີການທີ່ພວກເຂົາສາມາດຖືກນໍາໃຊ້ເປັນທາງເລືອກໃນການປະກອບການເຊື່ອມໂຍງ.

OpenShift ເປັນສະພາບແວດລ້ອມການພັດທະນາ

ຂະບວນການພັດທະນາ

ດັ່ງທີ່ໄດ້ກ່າວແລ້ວໃນ ຕອບທໍາອິດ, ຂະບວນການພັດທະນາແບບປົກກະຕິສໍາລັບຄໍາຮ້ອງສະຫມັກເວັບໄຊຕ໌ທີ່ທັນສະໄຫມແມ່ນພຽງແຕ່ບາງປະເພດຂອງ "ເຄື່ອງແມ່ຂ່າຍການພັດທະນາ" ທີ່ຕິດຕາມການປ່ຽນແປງໄຟລ໌ທ້ອງຖິ່ນ. ເມື່ອພວກມັນເກີດຂື້ນ, ການສ້າງແອັບພລິເຄຊັນຖືກກະຕຸ້ນແລະຫຼັງຈາກນັ້ນມັນຖືກປັບປຸງໃຫ້ກັບຕົວທ່ອງເວັບ.

ໃນກອບທີ່ທັນສະໄຫມທີ່ສຸດ, ດັ່ງກ່າວ "ເຄື່ອງແມ່ຂ່າຍການພັດທະນາ" ຖືກສ້າງຂຶ້ນໃນເຄື່ອງມືເສັ້ນຄໍາສັ່ງທີ່ສອດຄ້ອງກັນ.

ຕົວຢ່າງທ້ອງຖິ່ນ

ທໍາອິດ, ໃຫ້ເບິ່ງວິທີການເຮັດວຽກນີ້ໃນເວລາທີ່ແລ່ນຄໍາຮ້ອງສະຫມັກໃນທ້ອງຖິ່ນ. ໃຫ້ເອົາຄໍາຮ້ອງສະຫມັກເປັນຕົວຢ່າງ React ຈາກບົດຄວາມທີ່ຜ່ານມາ, ເຖິງແມ່ນວ່າແນວຄວາມຄິດຂອງຂະບວນການເຮັດວຽກເກືອບດຽວກັນໃຊ້ໃນກອບທີ່ທັນສະໄຫມອື່ນໆທັງຫມົດ.
ດັ່ງນັ້ນ, ເພື່ອເລີ່ມຕົ້ນ "dev server" ໃນຕົວຢ່າງ React ຂອງພວກເຮົາ, ພວກເຮົາຈະໃສ່ຄໍາສັ່ງຕໍ່ໄປນີ້:

$ npm run start

ຫຼັງ​ຈາກ​ນັ້ນ​, ໃນ​ປ່ອງ​ຢ້ຽມ terminal ພວກ​ເຮົາ​ຈະ​ເຫັນ​ບາງ​ສິ່ງ​ບາງ​ຢ່າງ​ເຊັ່ນ​ນີ້​:

ແລະແອັບພລິເຄຊັນຂອງພວກເຮົາຈະເປີດຢູ່ໃນຕົວທ່ອງເວັບເລີ່ມຕົ້ນ:

ໃນປັດຈຸບັນ, ຖ້າພວກເຮົາປ່ຽນແປງໄຟລ໌, ແອັບພລິເຄຊັນຄວນປັບປຸງໃນຕົວທ່ອງເວັບ.

ຕົກລົງ, ທຸກສິ່ງທຸກຢ່າງແມ່ນຈະແຈ້ງກັບການພັດທະນາໃນໂຫມດທ້ອງຖິ່ນ, ແຕ່ວິທີການບັນລຸດຽວກັນໃນ OpenShift?

ເຊີບເວີພັດທະນາໃນ OpenShift

ຖ້າທ່ານຈື່, ໃນ ຕອບຜ່ານມາ, ພວກເຮົາໄດ້ເບິ່ງໄລຍະການດໍາເນີນການທີ່ເອີ້ນວ່າຮູບພາບ S2I ແລະເຫັນວ່າໂດຍຄ່າເລີ່ມຕົ້ນ, ໂມດູນໃຫ້ບໍລິການແມ່ນຮັບຜິດຊອບໃນການບໍລິການຄໍາຮ້ອງສະຫມັກເວັບຂອງພວກເຮົາ.

ຢ່າງໃດກໍຕາມ, ຖ້າທ່ານເບິ່ງໃກ້ຊິດ ແລ່ນສະຄຣິບ ຈາກຕົວຢ່າງນັ້ນ, ມັນມີຕົວແປສະພາບແວດລ້ອມ $NPM_RUN, ເຊິ່ງຊ່ວຍໃຫ້ທ່ານສາມາດປະຕິບັດຄໍາສັ່ງຂອງທ່ານໄດ້.

ຕົວຢ່າງ, ພວກເຮົາສາມາດໃຊ້ໂມດູນ nodeshift ເພື່ອນຳໃຊ້ແອັບພລິເຄຊັນຂອງພວກເຮົາ:

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

ຫມາຍເຫດ: ຕົວຢ່າງຂ້າງເທິງນີ້ແມ່ນຫຍໍ້ເພື່ອສະແດງໃຫ້ເຫັນແນວຄວາມຄິດທົ່ວໄປ.

ໃນທີ່ນີ້ພວກເຮົາໄດ້ເພີ່ມຕົວແປສະພາບແວດລ້ອມ NPM_RUN ໃຫ້ກັບການໃຊ້ງານຂອງພວກເຮົາ, ເຊິ່ງບອກເວລາແລ່ນເພື່ອດໍາເນີນການຄໍາສັ່ງເລີ່ມຕົ້ນເສັ້ນດ້າຍ, ເຊິ່ງເລີ່ມຕົ້ນເຊີບເວີ React ພັດທະນາພາຍໃນ OpenShift pod ຂອງພວກເຮົາ.

ຖ້າ​ຫາກ​ວ່າ​ທ່ານ​ເບິ່ງ​ໄມ້​ຢືນ​ຕົ້ນ​ຂອງ​ການ​ແລ່ນ​, ມັນ​ຈະ​ມີ​ລັກ​ສະ​ນະ​ດັ່ງ​ນີ້​:

ແນ່ນອນ, ທັງຫມົດນີ້ຈະບໍ່ມີຫຍັງຈົນກ່ວາພວກເຮົາສາມາດ synchronize ລະຫັດທ້ອງຖິ່ນກັບລະຫັດ, ເຊິ່ງຍັງຕິດຕາມການປ່ຽນແປງ, ແຕ່ອາໄສຢູ່ໃນເຄື່ອງແມ່ຂ່າຍຫ່າງໄກສອກຫຼີກ.

ການຊິງໂຄຣໄນໄລຍະໄກ ແລະລະຫັດທ້ອງຖິ່ນ

ໂຊກດີ, nodeshift ສາມາດຊ່ວຍໃນການ synchronization ໄດ້ຢ່າງງ່າຍດາຍ, ແລະທ່ານສາມາດນໍາໃຊ້ຄໍາສັ່ງ watch ເພື່ອຕິດຕາມການປ່ຽນແປງ.

ດັ່ງນັ້ນ, ຫຼັງຈາກທີ່ພວກເຮົາດໍາເນີນການຄໍາສັ່ງທີ່ຈະນໍາໃຊ້ເຄື່ອງແມ່ຂ່າຍການພັດທະນາສໍາລັບຄໍາຮ້ອງສະຫມັກຂອງພວກເຮົາ, ພວກເຮົາສາມາດນໍາໃຊ້ຄໍາສັ່ງດັ່ງຕໍ່ໄປນີ້ໄດ້ຢ່າງປອດໄພ:

$ npx nodeshift watch

ດັ່ງນັ້ນ, ການເຊື່ອມຕໍ່ຈະເກີດຂຶ້ນກັບ pod ແລ່ນທີ່ພວກເຮົາສ້າງກ່ອນຫນ້ານີ້ເລັກນ້ອຍ, ການ synchronization ຂອງໄຟລ໌ທ້ອງຖິ່ນຂອງພວກເຮົາກັບ cluster ຫ່າງໄກສອກຫຼີກຈະຖືກເປີດໃຊ້, ແລະໄຟລ໌ໃນລະບົບທ້ອງຖິ່ນຂອງພວກເຮົາຈະເລີ່ມໄດ້ຮັບການຕິດຕາມການປ່ຽນແປງ.

ດັ່ງນັ້ນ, ຖ້າພວກເຮົາປັບປຸງໄຟລ໌ src/App.js ໃນປັດຈຸບັນ, ລະບົບຈະຕອບສະຫນອງຕໍ່ການປ່ຽນແປງເຫຼົ່ານີ້, ຄັດລອກພວກມັນໄປທີ່ກຸ່ມຫ່າງໄກສອກຫຼີກແລະເລີ່ມຕົ້ນເຄື່ອງແມ່ຂ່າຍຂອງການພັດທະນາ, ເຊິ່ງຈະປັບປຸງຄໍາຮ້ອງສະຫມັກຂອງພວກເຮົາໃນຕົວທ່ອງເວັບ.

ເພື່ອເຮັດສໍາເລັດຮູບ, ໃຫ້ສະແດງສິ່ງທີ່ຄໍາສັ່ງທັງຫມົດເຫຼົ່ານີ້ເບິ່ງຄື:

$ 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

ຄໍາສັ່ງໂມງແມ່ນເປັນ abstraction ຢູ່ເທິງສຸດຂອງຄໍາສັ່ງ oc rsync, ທ່ານສາມາດຮຽນຮູ້ເພີ່ມເຕີມກ່ຽວກັບວິທີການເຮັດວຽກ. ທີ່ນີ້.

ນີ້ແມ່ນຕົວຢ່າງສໍາລັບ React, ແຕ່ວິທີການດຽວກັນຄືກັນອ້ອຍຕ້ອຍສາມາດນໍາໃຊ້ກັບກອບອື່ນໆ, ພຽງແຕ່ກໍານົດຕົວແປສະພາບແວດລ້ອມ NPM_RUN ຕາມຄວາມຈໍາເປັນ.
 

Openshift Pipelines

ຕໍ່ໄປພວກເຮົາຈະສົນທະນາກ່ຽວກັບເຄື່ອງມືເຊັ່ນ OpenShift Pipelines ແລະວິທີທີ່ມັນສາມາດຖືກນໍາໃຊ້ເປັນທາງເລືອກໃນການກໍ່ສ້າງລະບົບຕ່ອງໂສ້.

OpenShift Pipelines ແມ່ນຫຍັງ

OpenShift Pipelines ແມ່ນລະບົບການລວມເຂົ້າກັນຢ່າງຕໍ່ເນື່ອງ CI/CD cloud-native CI/CD ທີ່ອອກແບບມາສໍາລັບການຈັດວາງທໍ່ໂດຍໃຊ້ Tekton. Tekton ເປັນກອບໂອເພນຊອດ Kubernetes-native CI/CD ທີ່ມີຄວາມຍືດຫຍຸ່ນທີ່ຊ່ວຍໃຫ້ທ່ານສາມາດນໍາໄປໃຊ້ໂດຍອັດຕະໂນມັດໃນເວທີຕ່າງໆ (Kubernetes, serverless, virtual machines, ແລະອື່ນໆ) ໂດຍຫຍໍ້ມາຈາກຊັ້ນຂໍ້ມູນເບື້ອງຕົ້ນ.

ຄວາມເຂົ້າໃຈໃນບົດຄວາມນີ້ຕ້ອງການຄວາມຮູ້ບາງຢ່າງກ່ຽວກັບ Pipelines, ດັ່ງນັ້ນພວກເຮົາແນະນໍາໃຫ້ທ່ານອ່ານທໍາອິດ ປື້ມແບບຮຽນຢ່າງເປັນທາງການ.

ການຕັ້ງຄ່າສະພາບແວດລ້ອມບ່ອນເຮັດວຽກຂອງທ່ານ

ເພື່ອຫຼີ້ນກັບຕົວຢ່າງໃນບົດຄວາມນີ້, ກ່ອນອື່ນ ໝົດ ທ່ານຕ້ອງກະກຽມສະພາບແວດລ້ອມການເຮັດວຽກຂອງທ່ານ:

1. ຕິດຕັ້ງ ແລະຕັ້ງຄ່າກຸ່ມ OpenShift 4. ຕົວຢ່າງຂອງພວກເຮົາໃຊ້ CodeReady Containers (CRD) ສໍາລັບການນີ້, ຄໍາແນະນໍາການຕິດຕັ້ງສໍາລັບສິ່ງທີ່ສາມາດພົບໄດ້. ທີ່ນີ້.
2. ຫຼັງຈາກ cluster ແມ່ນກຽມພ້ອມ, ທ່ານຈໍາເປັນຕ້ອງຕິດຕັ້ງ Pipeline Operator ໃສ່ມັນ. ຢ່າຢ້ານ, ມັນງ່າຍ, ຄໍາແນະນໍາການຕິດຕັ້ງ ທີ່ນີ້.
3. ດາວໂຫລດ Tekton CLI (tkn) ທີ່ນີ້.
4. ແລ່ນເຄື່ອງມືສາຍຄຳສັ່ງ create-react-app ເພື່ອສ້າງແອັບພລິເຄຊັນທີ່ເຈົ້າຈະນຳໃຊ້ (ນີ້ເປັນແອັບພລິເຄຊັນທີ່ງ່າຍດາຍ React).
5. (ທາງເລືອກ) Clone repository ເພື່ອດໍາເນີນການຄໍາຮ້ອງສະຫມັກຕົວຢ່າງໃນທ້ອງຖິ່ນດ້ວຍການຕິດຕັ້ງ npm ແລະຫຼັງຈາກນັ້ນ npm ເລີ່ມ.

ຄັງເກັບຂໍ້ມູນແອັບພລິເຄຊັນຍັງຈະມີໂຟນເດີ k8s, ເຊິ່ງຈະມີ Kubernetes/OpenShift YAMLs ທີ່ໃຊ້ເພື່ອນຳໃຊ້ແອັບພລິເຄຊັນ. ຈະມີ Tasks, ClusterTasks, Resources ແລະ Pipelines ທີ່ພວກເຮົາຈະສ້າງໃນນີ້ ຄັງເກັບມ້ຽນ.

ໃຫ້ເລີ່ມຕົ້ນ

ຂັ້ນຕອນທໍາອິດສໍາລັບຕົວຢ່າງຂອງພວກເຮົາແມ່ນການສ້າງໂຄງການໃຫມ່ໃນກຸ່ມ OpenShift. ໃຫ້ໂທຫາໂຄງການນີ້ webapp-pipeline ແລະສ້າງມັນດ້ວຍຄໍາສັ່ງຕໍ່ໄປນີ້:

$ oc new-project webapp-pipeline

ຊື່ໂຄງການນີ້ຈະປາກົດຢູ່ໃນລະຫັດຕໍ່ມາ, ດັ່ງນັ້ນຖ້າທ່ານຕັດສິນໃຈຕັ້ງຊື່ມັນຢ່າງອື່ນ, ຢ່າລືມແກ້ໄຂລະຫັດຕົວຢ່າງຕາມຄວາມເຫມາະສົມ. ເລີ່ມຕົ້ນຈາກຈຸດນີ້, ພວກເຮົາຈະບໍ່ຂຶ້ນເທິງລົງ, ແຕ່ລຸ່ມສຸດ: ນັ້ນແມ່ນ, ທໍາອິດພວກເຮົາຈະສ້າງອົງປະກອບທັງຫມົດຂອງລໍາລຽງ, ແລະພຽງແຕ່ຫຼັງຈາກນັ້ນ conveyor ຕົວຂອງມັນເອງ.

ດັ່ງນັ້ນ, ກ່ອນອື່ນ ໝົດ ...

ວຽກງານ

ໃຫ້ພວກເຮົາສ້າງວຽກງານສອງຢ່າງ, ເຊິ່ງຈະຊ່ວຍໃຫ້ການນໍາໃຊ້ຄໍາຮ້ອງສະຫມັກພາຍໃນທໍ່ຂອງພວກເຮົາ. ວຽກງານທໍາອິດ - apply_manifests_task - ຮັບຜິດຊອບສໍາລັບການນໍາໃຊ້ YAML ຂອງຊັບພະຍາກອນ Kubernetes ເຫຼົ່ານັ້ນ (ການບໍລິການ, ການປະຕິບັດແລະເສັ້ນທາງ) ທີ່ຢູ່ໃນໂຟນເດີ k8s ຂອງຄໍາຮ້ອງສະຫມັກຂອງພວກເຮົາ. ວຽກງານທີສອງ – update_deployment_task – ແມ່ນຮັບຜິດຊອບໃນການປັບປຸງຮູບພາບທີ່ໃຊ້ແລ້ວກັບອັນທີ່ສ້າງໂດຍທໍ່ຂອງພວກເຮົາ.

ຢ່າກັງວົນຖ້າມັນຍັງບໍ່ຊັດເຈນຫຼາຍ. ໃນຄວາມເປັນຈິງ, ວຽກງານເຫຼົ່ານີ້ແມ່ນບາງສິ່ງບາງຢ່າງເຊັ່ນ: ຜົນປະໂຫຍດ, ແລະພວກເຮົາຈະເບິ່ງໃຫ້ເຂົາເຈົ້າໃນລາຍລະອຽດເພີ່ມເຕີມເລັກນ້ອຍຕໍ່ມາ. ສໍາລັບໃນປັດຈຸບັນ, ໃຫ້ພຽງແຕ່ສ້າງໃຫ້ເຂົາເຈົ້າ:

$ 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

ຫຼັງຈາກນັ້ນ, ການນໍາໃຊ້ຄໍາສັ່ງ tkn CLI, ພວກເຮົາຈະກວດເບິ່ງວ່າວຽກງານໄດ້ຖືກສ້າງຂື້ນ:

$ tkn task ls

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

ໝາຍເຫດ: ນີ້ແມ່ນວຽກທ້ອງຖິ່ນສຳລັບໂຄງການປັດຈຸບັນຂອງທ່ານ.

ວຽກງານກຸ່ມ

ວຽກງານກຸ່ມແມ່ນພື້ນຖານຄືກັນກັບວຽກງານທີ່ງ່າຍດາຍ. ນັ້ນແມ່ນ, ມັນເປັນການລວບລວມຂັ້ນຕອນທີ່ສາມາດນໍາໃຊ້ຄືນໄດ້ທີ່ປະສົມປະສານໃນວິທີການຫນຶ່ງຫຼືອື່ນໃນເວລາທີ່ເຮັດວຽກສະເພາະ. ຄວາມແຕກຕ່າງແມ່ນວ່າວຽກງານຂອງກຸ່ມແມ່ນມີຢູ່ທົ່ວທຸກແຫ່ງພາຍໃນກຸ່ມ. ເພື່ອເບິ່ງລາຍຊື່ວຽກງານຂອງກຸ່ມທີ່ຖືກສ້າງຂຶ້ນໂດຍອັດຕະໂນມັດເມື່ອເພີ່ມ Pipeline Operator, ພວກເຮົາຈະໃຊ້ຄໍາສັ່ງ 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

ຕອນນີ້ໃຫ້ພວກເຮົາສ້າງສອງວຽກງານຂອງກຸ່ມ. ທໍາອິດຈະສ້າງຮູບພາບ S2I ແລະສົ່ງມັນໄປຍັງບັນຊີ OpenShift ພາຍໃນ; ອັນທີສອງແມ່ນການສ້າງຮູບພາບຂອງພວກເຮົາໂດຍອີງໃສ່ NGINX, ການນໍາໃຊ້ຄໍາຮ້ອງສະຫມັກທີ່ພວກເຮົາໄດ້ສ້າງເປັນເນື້ອຫາ.

ສ້າງ​ແລະ​ສົ່ງ​ຮູບ​ພາບ​

ເມື່ອສ້າງວຽກງານທໍາອິດ, ພວກເຮົາຈະເຮັດຊ້ໍາສິ່ງທີ່ພວກເຮົາໄດ້ເຮັດແລ້ວໃນບົດຄວາມທີ່ຜ່ານມາກ່ຽວກັບການປະກອບການເຊື່ອມໂຍງ. ຈື່ໄວ້ວ່າພວກເຮົາໄດ້ໃຊ້ຮູບພາບ S2I (ubi8-s2i-web-app) ເພື່ອ "ສ້າງ" ແອັບພລິເຄຊັນຂອງພວກເຮົາ, ແລະສິ້ນສຸດລົງດ້ວຍຮູບພາບທີ່ເກັບໄວ້ໃນ OpenShift ພາຍໃນ. ຕອນນີ້ພວກເຮົາຈະໃຊ້ຮູບພາບຂອງແອັບຯເວັບ S2I ນີ້ເພື່ອສ້າງ DockerFile ສໍາລັບແອັບຯຂອງພວກເຮົາແລະຫຼັງຈາກນັ້ນໃຊ້ Buildah ເພື່ອສ້າງຕົວຈິງແລະຊຸກດັນໃຫ້ຮູບພາບຜົນໄດ້ຮັບໄປສູ່ OpenShift ລີຈິດຊີພາຍໃນ, ເພາະວ່ານັ້ນແມ່ນສິ່ງທີ່ OpenShift ເຮັດໃນເວລາທີ່ທ່ານນໍາໃຊ້ຄໍາຮ້ອງສະຫມັກຂອງທ່ານໂດຍໃຊ້ NodeShift. .

ພວກ​ເຮົາ​ຮູ້​ທັງ​ຫມົດ​ນີ້​ໄດ້​ແນວ​ໃດ​, ທ່ານ​ຖາມ​? ຈາກ ສະບັບທາງການຂອງ Node.js ຢ່າງເປັນທາງການ, ພວກເຮົາພຽງແຕ່ຄັດລອກມັນແລະດັດແປງມັນສໍາລັບຕົວເຮົາເອງ.

ດັ່ງນັ້ນ, ຕອນນີ້ໃຫ້ພວກເຮົາສ້າງ s2i-web-app cluster task:

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

ພວກເຮົາຈະບໍ່ວິເຄາະລາຍລະອຽດນີ້, ແຕ່ຈະເນັ້ນໃສ່ພາລາມິເຕີ OUTPUT_DIR ເທົ່ານັ້ນ:

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

ໂດຍຄ່າເລີ່ມຕົ້ນ, ພາລາມິເຕີນີ້ເທົ່າກັບການກໍ່ສ້າງ, ເຊິ່ງເປັນບ່ອນທີ່ React ເອົາເນື້ອຫາທີ່ປະກອບ. ກອບອື່ນໆໃຊ້ເສັ້ນທາງທີ່ແຕກຕ່າງກັນ, ສໍາລັບການຍົກຕົວຢ່າງ, ໃນ Ember ມັນຫ່າງໄກ. ຜົນໄດ້ຮັບຂອງວຽກງານກຸ່ມທໍາອິດຂອງພວກເຮົາຈະເປັນຮູບພາບທີ່ມີ HTML, JavaScript, ແລະ CSS ທີ່ພວກເຮົາເກັບກໍາ.

ສ້າງຮູບພາບໂດຍອີງໃສ່ NGINX

ສໍາລັບວຽກງານກຸ່ມທີສອງຂອງພວກເຮົາ, ມັນຄວນຈະສ້າງຮູບພາບທີ່ອີງໃສ່ NGINX ສໍາລັບພວກເຮົາ, ໂດຍນໍາໃຊ້ເນື້ອໃນຂອງຄໍາຮ້ອງສະຫມັກທີ່ພວກເຮົາໄດ້ສ້າງແລ້ວ. ໂດຍພື້ນຖານແລ້ວ, ນີ້ແມ່ນສ່ວນຂອງພາກກ່ອນທີ່ພວກເຮົາໄດ້ເບິ່ງການກໍ່ສ້າງແບບຕ່ອງໂສ້.

ເພື່ອເຮັດສິ່ງນີ້, ພວກເຮົາ - ຄືກັນກັບຂ້າງເທິງ - ຈະສ້າງການເຮັດວຽກຂອງກຸ່ມ webapp-build-runtime:

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

ຖ້າທ່ານເບິ່ງລະຫັດຂອງວຽກງານຂອງກຸ່ມເຫຼົ່ານີ້, ທ່ານສາມາດເບິ່ງວ່າມັນບໍ່ລະບຸບ່ອນເກັບມ້ຽນ Git ທີ່ພວກເຮົາກໍາລັງເຮັດວຽກກັບຫຼືຊື່ຂອງຮູບພາບທີ່ພວກເຮົາກໍາລັງສ້າງ. ພວກເຮົາພຽງແຕ່ລະບຸສິ່ງທີ່ພວກເຮົາໂອນໄປຫາ Git, ຫຼືຮູບພາບທີ່ແນ່ນອນທີ່ຮູບພາບສຸດທ້າຍຄວນຈະເປັນຜົນຜະລິດ. ນັ້ນແມ່ນເຫດຜົນທີ່ວ່າວຽກງານກຸ່ມເຫຼົ່ານີ້ສາມາດຖືກນໍາໃຊ້ຄືນເມື່ອເຮັດວຽກກັບແອັບພລິເຄຊັນອື່ນ.

ແລະນີ້ພວກເຮົາກ້າວໄປສູ່ຈຸດຕໍ່ໄປຢ່າງສະຫງ່າງາມ ...

ຊັບພະຍາກອນ

ດັ່ງນັ້ນ, ເນື່ອງຈາກວ່າ, ດັ່ງທີ່ພວກເຮົາພຽງແຕ່ເວົ້າ, ວຽກງານຂອງກຸ່ມຄວນຈະເປັນທົ່ວໄປເທົ່າທີ່ເປັນໄປໄດ້, ພວກເຮົາຈໍາເປັນຕ້ອງສ້າງຊັບພະຍາກອນທີ່ຈະຖືກນໍາໃຊ້ເປັນວັດສະດຸປ້ອນ (ບ່ອນເກັບຂໍ້ມູນ Git) ແລະເປັນຜົນຜະລິດ (ຮູບພາບສຸດທ້າຍ). ຊັບພະຍາກອນທໍາອິດທີ່ພວກເຮົາຕ້ອງການແມ່ນ Git, ບ່ອນທີ່ຄໍາຮ້ອງສະຫມັກຂອງພວກເຮົາອາໄສຢູ່, ບາງສິ່ງບາງຢ່າງເຊັ່ນນີ້:

# 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

ທີ່ນີ້ PipelineResource ແມ່ນປະເພດ git. ລະຫັດ url ໃນພາກ params ຊີ້ໄປຫາບ່ອນເກັບມ້ຽນສະເພາະແລະກໍານົດສາຂາຕົ້ນສະບັບ (ນີ້ແມ່ນທາງເລືອກ, ແຕ່ພວກເຮົາຂຽນມັນເພື່ອຄວາມສົມບູນ).

ໃນປັດຈຸບັນພວກເຮົາຈໍາເປັນຕ້ອງສ້າງຊັບພະຍາກອນສໍາລັບຮູບພາບທີ່ຜົນໄດ້ຮັບຂອງວຽກງານ s2i-web-app ຈະຖືກບັນທຶກໄວ້, ນີ້ແມ່ນເຮັດເຊັ່ນນີ້:

# 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

ທີ່ນີ້ PipelineResource ແມ່ນຮູບພາບປະເພດ, ແລະຄ່າຂອງພາລາມິເຕີ url ຊີ້ໄປຫາ OpenShift Image Registry ພາຍໃນ, ໂດຍສະເພາະທີ່ຕັ້ງຢູ່ໃນ webapp-pipeline namespace. ຢ່າລືມປ່ຽນການຕັ້ງຄ່ານີ້ຖ້າທ່ານໃຊ້ namespace ອື່ນ.

ແລະສຸດທ້າຍ, ຊັບພະຍາກອນສຸດທ້າຍທີ່ພວກເຮົາຕ້ອງການຈະເປັນຮູບພາບປະເພດແລະນີ້ຈະເປັນຮູບພາບ NGINX ສຸດທ້າຍທີ່ຈະຖືກນໍາໃຊ້ໃນລະຫວ່າງການປະຕິບັດ:

# 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

ອີກເທື່ອຫນຶ່ງ, ໃຫ້ສັງເກດວ່າຊັບພະຍາກອນນີ້ເກັບຮັກສາຮູບພາບຢູ່ໃນການລົງທະບຽນ OpenShift ພາຍໃນຢູ່ໃນ namespace webapp-pipeline.

ເພື່ອສ້າງຊັບພະຍາກອນທັງຫມົດເຫຼົ່ານີ້ໃນເວລາດຽວກັນ, ພວກເຮົາໃຊ້ຄໍາສັ່ງສ້າງ:

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

ທ່ານສາມາດໃຫ້ແນ່ໃຈວ່າຊັບພະຍາກອນໄດ້ຖືກສ້າງຂື້ນແບບນີ້:

$ tkn resource ls

ທໍ່ລໍາລຽງ

ຕອນນີ້ພວກເຮົາມີອົງປະກອບທີ່ຈໍາເປັນທັງຫມົດ, ໃຫ້ລວບລວມທໍ່ຈາກພວກມັນໂດຍການສ້າງມັນດ້ວຍຄໍາສັ່ງຕໍ່ໄປນີ້:

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

ແຕ່ກ່ອນທີ່ພວກເຮົາຈະດໍາເນີນການຄໍາສັ່ງນີ້, ໃຫ້ເບິ່ງອົງປະກອບເຫຼົ່ານີ້. ທໍາອິດແມ່ນຊື່:

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

ຫຼັງຈາກນັ້ນ, ໃນພາກ spec ພວກເຮົາເຫັນຕົວຊີ້ບອກຂອງຊັບພະຍາກອນທີ່ພວກເຮົາສ້າງກ່ອນຫນ້ານີ້:

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

ຫຼັງຈາກນັ້ນ, ພວກເຮົາສ້າງວຽກງານທີ່ທໍ່ຂອງພວກເຮົາຕ້ອງການໃຫ້ສໍາເລັດ. ກ່ອນອື່ນ ໝົດ, ມັນຕ້ອງປະຕິບັດວຽກງານ s2i-web-app ທີ່ພວກເຮົາໄດ້ສ້າງແລ້ວ:

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

ວຽກງານນີ້ໃຊ້ເວລາການປ້ອນຂໍ້ມູນ (ຊັບພະຍາກອນ gir) ແລະຜົນຜະລິດ (built-web-application-image resource) ພາລາມິເຕີ. ພວກເຮົາຍັງຜ່ານມັນຕົວກໍານົດການພິເສດເພື່ອບໍ່ໃຫ້ມັນກວດສອບ TLS ເນື່ອງຈາກພວກເຮົາກໍາລັງໃຊ້ໃບຢັ້ງຢືນການເຊັນດ້ວຍຕົນເອງ:

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

ວຽກງານຕໍ່ໄປແມ່ນເກືອບຄືກັນ, ພຽງແຕ່ທີ່ນີ້ webapp-build-runtime cluster ວຽກທີ່ພວກເຮົາໄດ້ສ້າງແລ້ວເອີ້ນວ່າ:

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

ເຊັ່ນດຽວກັນກັບວຽກງານທີ່ຜ່ານມາ, ພວກເຮົາຜ່ານໃນຊັບພະຍາກອນ, ແຕ່ໃນປັດຈຸບັນມັນເປັນການສ້າງເວັບ - ຄໍາຮ້ອງສະຫມັກ - ຮູບພາບ (ຜົນໄດ້ຮັບຂອງວຽກງານທີ່ຜ່ານມາຂອງພວກເຮົາ). ແລະເປັນຜົນຜະລິດພວກເຮົາອີກເທື່ອຫນຶ່ງກໍານົດຮູບພາບ. ເນື່ອງຈາກວຽກງານນີ້ຕ້ອງໄດ້ຮັບການປະຕິບັດຫຼັງຈາກອັນທີ່ຜ່ານມາ, ພວກເຮົາເພີ່ມພາກສະຫນາມ 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

ວຽກງານສອງອັນຕໍ່ໄປແມ່ນຮັບຜິດຊອບໃນການນໍາໃຊ້ການບໍລິການ, ເສັ້ນທາງແລະການນໍາໃຊ້ໄຟລ໌ YAML ທີ່ອາໄສຢູ່ໃນໄດເລກະທໍລີ k8s ຂອງແອັບພລິເຄຊັນເວັບຂອງພວກເຮົາ, ແລະຍັງສໍາລັບການປັບປຸງການໃຊ້ງານນີ້ໃນເວລາສ້າງຮູບພາບໃຫມ່. ພວກເຮົາໄດ້ກໍານົດສອງວຽກງານກຸ່ມນີ້ໃນຕອນຕົ້ນຂອງບົດຄວາມ.

ການເລີ່ມຕົ້ນ conveyor ໄດ້

ດັ່ງນັ້ນ, ທຸກພາກສ່ວນຂອງທໍ່ຂອງພວກເຮົາຖືກສ້າງຂື້ນ, ແລະພວກເຮົາຈະດໍາເນີນການມັນດ້ວຍຄໍາສັ່ງຕໍ່ໄປນີ້:

$ tkn pipeline start build-and-deploy-react

ໃນຂັ້ນຕອນນີ້, ເສັ້ນຄໍາສັ່ງຖືກນໍາໃຊ້ແບບໂຕ້ຕອບແລະທ່ານຈໍາເປັນຕ້ອງເລືອກຊັບພະຍາກອນທີ່ເຫມາະສົມເພື່ອຕອບສະຫນອງແຕ່ລະຄໍາຮ້ອງຂໍຂອງມັນ: ສໍາລັບຊັບພະຍາກອນ git ພວກເຮົາເລືອກ web-application-repo, ຫຼັງຈາກນັ້ນສໍາລັບຊັບພະຍາກອນຮູບພາບທໍາອິດ - build-web-application -image, ແລະສຸດທ້າຍສໍາລັບຊັບພະຍາກອນຮູບພາບທີສອງ -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

ຕອນນີ້ໃຫ້ພວກເຮົາກວດເບິ່ງສະຖານະຂອງທໍ່ໂດຍໃຊ້ຄໍາສັ່ງຕໍ່ໄປນີ້:

$ tkn pipeline logs -f

ເມື່ອທໍ່ໄດ້ເລີ່ມຕົ້ນແລະຄໍາຮ້ອງສະຫມັກໄດ້ຖືກນໍາໄປໃຊ້, ພວກເຮົາສາມາດຮ້ອງຂໍເສັ້ນທາງທີ່ຖືກເຜີຍແຜ່ດ້ວຍຄໍາສັ່ງຕໍ່ໄປນີ້:

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

ສໍາລັບການເບິ່ງເຫັນຫຼາຍກວ່າເກົ່າ, ທ່ານສາມາດເບິ່ງທໍ່ຂອງພວກເຮົາໃນໂຫມດນັກພັດທະນາຂອງ web console ໃນພາກ ທໍ່, ດັ່ງທີ່ສະແດງຢູ່ໃນຮູບ. 1.

Fig.1. ການທົບທວນຄືນຂອງທໍ່ແລ່ນ.

ການຄລິກໃສ່ທໍ່ແລ່ນສະແດງລາຍລະອຽດເພີ່ມເຕີມ, ດັ່ງທີ່ສະແດງຢູ່ໃນຮູບ 2.

ເຂົ້າ. 2. ຂໍ້ມູນເພີ່ມເຕີມກ່ຽວກັບທໍ່.

ຫຼັງຈາກຂໍ້ມູນເພີ່ມເຕີມ, ທ່ານສາມາດເບິ່ງຄໍາຮ້ອງສະຫມັກທີ່ເຮັດວຽກຢູ່ໃນມຸມເບິ່ງ Topology, ດັ່ງທີ່ສະແດງຢູ່ໃນ Fig.3.

Fig 3. ຝັກເປີດຕົວ.

ການຄລິກໃສ່ຮູບວົງມົນຢູ່ໃນມຸມຂວາເທິງຂອງໄອຄອນເປີດຄໍາຮ້ອງສະຫມັກຂອງພວກເຮົາ, ດັ່ງທີ່ສະແດງຢູ່ໃນຮູບທີ 4.

ເຂົ້າ. 4. ແລ່ນແອັບພລິເຄຊັນ React.

ສະຫລຸບ

ດັ່ງນັ້ນ, ພວກເຮົາໄດ້ສະແດງວິທີການດໍາເນີນການເຄື່ອງແມ່ຂ່າຍການພັດທະນາສໍາລັບຄໍາຮ້ອງສະຫມັກຂອງທ່ານໃນ OpenShift ແລະ synchronize ມັນກັບລະບົບໄຟລ໌ທ້ອງຖິ່ນ. ພວກເຮົາຍັງໄດ້ເບິ່ງວິທີການຈໍາລອງແມ່ແບບການສ້າງລະບົບຕ່ອງໂສ້ໂດຍໃຊ້ OpenShift Pipelines. ລະຫັດຕົວຢ່າງທັງໝົດຈາກບົດຄວາມນີ້ສາມາດພົບໄດ້ ທີ່ນີ້.

ຊັບພະຍາກອນເພີ່ມເຕີມ (EN)

• e-book ຟຣີ "ການພັດທະນາໃນ OpenShift: ຄູ່ມືສໍາລັບຄວາມອົດທົນ"
• ການສ້າງແອັບພລິເຄຊັນ Node.js ທີ່ເປັນຈຸດໃຈກາງຂອງ container ໂດຍໃຊ້ Red Hat OpenShift Application Runtimes ແລະ Istio
• ການດີບັກແອັບພລິເຄຊັນ Node.js ໃນ OpenShift ໂດຍໃຊ້ Chrome DevTools
• ສາມຄໍາສັ່ງເພື່ອຊໍານິຊໍານານ Express ໃນ OpenShift ຈາກ scratch
• ປະກາດສະບັບທົ່ວໄປຂອງ Node.js ເປັນສ່ວນຫນຶ່ງຂອງ Red Hat OpenShift Application Runtimes
• ການຕິດຕາມຄໍາຮ້ອງສະຫມັກ Node.js ໃນ OpenShift ກັບ Prometheus
• ບົດຂຽນອື່ນໆກ່ຽວກັບ OpenShift ແລະ Kubernetes ຢູ່ໃນເວັບໄຊທ໌ Red Hat

ປະກາດຂອງ webinars ທີ່ຈະມາເຖິງ

ພວກເຮົາກຳລັງເລີ່ມການເຝິກອົບຮົມໃນວັນສຸກກ່ຽວກັບປະສົບການພື້ນເມືອງທີ່ໃຊ້ Red Hat OpenShift Container Platform ແລະ Kubernetes:

• ວັນທີ 28 ສິງຫາ, webinar Emperor “Operator”: ຜູ້ປະກອບການໃນ OpenShift ແລະ Kubernetes
• ວັນທີ 11 ກັນຍາ, DeploymentConfig vs Deployment – ​​OpenShift-specific magic for build and deploying applications
• ວັນທີ 25 ກັນຍາ, Red Hat OpenShift ແລະ Machine API
• ວັນທີ 9 ຕຸລາ, ວິທີການຮັບມືກັບການເພີ່ມຂຶ້ນຢ່າງກະທັນຫັນຂອງວຽກງານ
• ວັນທີ 23 ຕຸລາ, ຝັງ Jenkins, Pipeline-builds, Tekton in Red Hat OpenShift Container Platform

ແຫຼ່ງຂໍ້ມູນ: www.habr.com