ຂໍ​ອະ​ໄພ OpenShift, ພວກ​ເຮົາ​ບໍ່​ໄດ້​ຂອບ​ໃຈ​ທ່ານ​ພຽງ​ພໍ​ແລະ​ໄດ້​ຮັບ​ການ​ອະ​ນຸ​ຍາດ​ໃຫ້​ທ່ານ

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

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

ໂດຍທົ່ວໄປແລ້ວ, ພວກເຮົາຄິດວ່າການຂຽນຂໍ້ຄວາມນີ້ດ້ວຍການສະຫລຸບເຊັ່ນ: "ຟັງ, ມັນບໍ່ສໍາຄັນທີ່ຈະແລ່ນລະຫັດ, ໃນ OpenShift ຫຼືໃນ AKS, ໃນ EKS, ໃນບາງ Kubernetes ກໍານົດເອງ, ຫຼືກ່ຽວກັບ Kubernetes ໃດກໍ່ຕາມ. (ເພື່ອຄວາມສັ້ນຂໍເອີ້ນມັນວ່າ KUK) "ມັນງ່າຍດາຍແທ້ໆ, ທັງຢູ່ທີ່ນັ້ນແລະບ່ອນນັ້ນ."

ຫຼັງຈາກນັ້ນ, ພວກເຮົາໄດ້ວາງແຜນທີ່ຈະເອົາ "ສະບາຍດີໂລກ" ທີ່ງ່າຍດາຍທີ່ສຸດແລະນໍາໃຊ້ຕົວຢ່າງຂອງມັນເພື່ອສະແດງໃຫ້ເຫັນສິ່ງທີ່ເປັນທໍາມະດາແລະຄວາມແຕກຕ່າງລະຫວ່າງ KUC ແລະ Red Hat OpenShift Container Platform (ຕໍ່ໄປນີ້, OCP ຫຼືພຽງແຕ່ OpenShift).

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

ໂດຍທົ່ວໄປແລ້ວ, ເວລາໄດ້ມາເຖິງສຳລັບການກັບໃຈຢ່າງຫ້າວຫັນ, ແລະ ດຽວນີ້ພວກເຮົາຈະປຽບທຽບການມອບໝາຍໃຫ້ “ສະບາຍດີໂລກ” ຂອງພວກເຮົາຢູ່ KUK ແລະ OpenShift, ແລະ ພວກເຮົາຈະເຮັດອັນນີ້ຕາມຈຸດປະສົງທີ່ເປັນໄປໄດ້ (ດີ, ຍົກເວັ້ນບາງຄັ້ງຈະສະແດງ ທັດສະນະຄະຕິສ່ວນຕົວຕໍ່ວິຊາ). ຖ້າ​ຫາກ​ວ່າ​ທ່ານ​ມີ​ຄວາມ​ສົນ​ໃຈ​ໃນ​ຄວາມ​ຄິດ​ເຫັນ​ທີ່​ແທ້​ຈິງ​ກ່ຽວ​ກັບ​ບັນ​ຫາ​ນີ້​, ທ່ານ​ສາ​ມາດ​ອ່ານ​ມັນ​ ທີ່ນີ້ (EN). ແລະໃນບົດຂຽນນີ້, ພວກເຮົາຈະຍຶດ ໝັ້ນ ກັບຂໍ້ເທັດຈິງແລະຂໍ້ເທັດຈິງເທົ່ານັ້ນ.

ກຸ່ມ

ດັ່ງນັ້ນ, "ສະບາຍດີໂລກ" ຂອງພວກເຮົາຕ້ອງການກຸ່ມ. ພວກ​ເຮົາ​ຈະ​ເວົ້າ​ວ່າ “ບໍ່” ໃນ​ທັນ​ທີ​ກັບ​ຟັງ​ສາ​ທາ​ລະ​ນະ​ໃດ​ຫນຶ່ງ, ເພື່ອ​ບໍ່​ໃຫ້​ການ​ຈ່າຍ​ຄ່າ​ສໍາ​ລັບ​ເຄື່ອງ​ແມ່​ຂ່າຍ, ການ​ຈົດ​ທະ​ບຽນ, ເຄືອ​ຂ່າຍ, ການ​ໂອນ​ຂໍ້​ມູນ, ແລະ​ອື່ນໆ. ຕາມນັ້ນແລ້ວ, ພວກເຮົາເລືອກກຸ່ມແບບດ່ຽວແບບງ່າຍໆ ມິນິຄິບ (ສໍາລັບ KUK) ແລະ ຕູ້ຄອນເທນເນີທີ່ກຽມພ້ອມ (ສໍາລັບ OpenShift cluster). ທັງ​ສອງ​ທາງ​ເລືອກ​ເຫຼົ່າ​ນີ້​ແມ່ນ​ງ່າຍ​ທີ່​ຈະ​ຕິດ​ຕັ້ງ​, ແຕ່​ວ່າ​ຈະ​ຕ້ອງ​ການ​ຂ້ອນ​ຂ້າງ​ຫຼາຍ​ຂອງ​ຊັບ​ພະ​ຍາ​ກອນ​ໃນ​ຄອມ​ພິວ​ເຕີ​ຂອງ​ທ່ານ​.

ສະພາແຫ່ງ KUK-e

ສະນັ້ນໃຫ້ໄປ.

ຂັ້ນ​ຕອນ​ທີ 1 - ການ​ກໍ່​ສ້າງ​ຮູບ​ພາບ​ຕູ້​ຂອງ​ພວກ​ເຮົາ​

ເລີ່ມຕົ້ນໂດຍການໃຊ້ “ສະບາຍດີໂລກ” ຂອງພວກເຮົາໃສ່ minikube. ເພື່ອເຮັດສິ່ງນີ້, ທ່ານຈະຕ້ອງ:

1. 1. ຕິດຕັ້ງ Docker.
2. 2. Git ຕິດຕັ້ງ.
3. 3. ຕິດຕັ້ງ Maven (ຕົວຈິງແລ້ວ, ໂຄງການນີ້ໃຊ້ mvnw binary, ດັ່ງນັ້ນທ່ານສາມາດເຮັດໄດ້ໂດຍບໍ່ມີມັນ).
4. 4. ຕົວຈິງແລ້ວ, ແຫຼ່ງຕົວມັນເອງ, i.e. clone ຄັງເກັບມ້ຽນ github.com/gcolman/quarkus-hello-world.git

ຂັ້ນຕອນທໍາອິດແມ່ນການສ້າງໂຄງການ Quarkus. ຢ່າຕົກໃຈຖ້າທ່ານບໍ່ເຄີຍເຮັດວຽກກັບ Quarkus.io - ມັນງ່າຍ. ທ່ານພຽງແຕ່ເລືອກອົງປະກອບທີ່ທ່ານຕ້ອງການທີ່ຈະນໍາໃຊ້ໃນໂຄງການ (RestEasy, Hibernate, Amazon SQS, Camel, ແລະອື່ນໆ), ແລະຫຼັງຈາກນັ້ນ Quarkus ຕົວຂອງມັນເອງ, ໂດຍບໍ່ມີການເຂົ້າຮ່ວມໃດໆ, ກໍານົດ maven archetype ແລະວາງທຸກສິ່ງທຸກຢ່າງຢູ່ໃນ github. ນັ້ນແມ່ນ, ກົດປຸ່ມຫນຶ່ງຂອງຫນູແລະເຈົ້າເຮັດແລ້ວ. ນີ້ແມ່ນເຫດຜົນທີ່ພວກເຮົາຮັກ Quarkus.

ວິທີທີ່ງ່າຍທີ່ສຸດທີ່ຈະສ້າງ "ສະບາຍດີໂລກ" ຂອງພວກເຮົາເຂົ້າໄປໃນຮູບຖັງແມ່ນການນໍາໃຊ້ການຂະຫຍາຍ quarkus-maven ສໍາລັບ Docker, ເຊິ່ງຈະເຮັດວຽກທີ່ຈໍາເປັນທັງຫມົດ. ກັບການມາຮອດຂອງ Quarkus, ນີ້ໄດ້ກາຍເປັນເລື່ອງງ່າຍແລະງ່າຍດາຍ: ເພີ່ມສ່ວນຂະຫຍາຍ container-image-docker ແລະທ່ານສາມາດສ້າງຮູບພາບໂດຍໃຊ້ຄໍາສັ່ງ maven.

./mvnw quarkus:add-extension -Dextensions=”container-image-docker”

ສຸດທ້າຍ, ພວກເຮົາສ້າງຮູບພາບຂອງພວກເຮົາໂດຍໃຊ້ Maven. ດັ່ງນັ້ນ, ລະຫັດແຫຼ່ງຂອງພວກເຮົາຈຶ່ງປ່ຽນເປັນຮູບບັນຈຸທີ່ກຽມພ້ອມແລ້ວທີ່ສາມາດດໍາເນີນການໄດ້ໃນສະພາບແວດລ້ອມ runtime ຂອງກ່ອງບັນຈຸ.

./mvnw -X clean package -Dquarkus.container-image.build=true

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

docker run -i — rm -p 8080:8080 gcolman/quarkus-hello-world

ຫຼັງຈາກຕົວຢ່າງ container ໄດ້ເລີ່ມຕົ້ນ, ສິ່ງທີ່ຍັງເຫຼືອແມ່ນການກວດສອບດ້ວຍຄໍາສັ່ງ curl ວ່າບໍລິການຂອງພວກເຮົາກໍາລັງເຮັດວຽກຢູ່:

ດັ່ງນັ້ນທຸກສິ່ງທຸກຢ່າງເຮັດວຽກແລະມັນກໍ່ງ່າຍແລະງ່າຍດາຍ.

ຂັ້ນ​ຕອນ​ທີ 2 - ສົ່ງ​ພາ​ຊະ​ນະ​ຂອງ​ພວກ​ເຮົາ​ທີ່​ຈະ​ເກັບ​ກໍາ​ຮູບ​ພາບ​

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

ນີ້ແມ່ນຍັງງ່າຍດາຍຫຼາຍ, ແລະທັງຫມົດທີ່ທ່ານຕ້ອງການແມ່ນບັນຊີ dockerhub.

ດັ່ງນັ້ນ, ພວກເຮົາຕິດຕັ້ງ dockerhub ແລະສົ່ງຮູບພາບຂອງພວກເຮົາຢູ່ທີ່ນັ້ນ.

ຂັ້ນຕອນທີ 3 – ເປີດ Kubernetes

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

ກ່ອນອື່ນ, ໃຫ້ເປີດກຸ່ມ minikube:

minikube start

ຂັ້ນ​ຕອນ​ທີ 4 - ການ​ນໍາ​ໃຊ້​ຮູບ​ພາບ container ຂອງ​ພວກ​ເຮົາ​

ໃນປັດຈຸບັນພວກເຮົາຈໍາເປັນຕ້ອງໄດ້ປ່ຽນລະຫັດແລະຮູບພາບບັນຈຸຂອງພວກເຮົາເຂົ້າໄປໃນການຕັ້ງຄ່າ kubernetes. ໃນຄໍາສັບຕ່າງໆອື່ນໆ, ພວກເຮົາຕ້ອງການ pod ແລະຄໍານິຍາມການນໍາໃຊ້ທີ່ຊີ້ໄປຫາຮູບພາບບັນຈຸຂອງພວກເຮົາໃນ dockerhub. ຫນຶ່ງໃນວິທີທີ່ງ່າຍທີ່ສຸດທີ່ຈະເຮັດຄືການດໍາເນີນການສ້າງຄໍາສັ່ງ deployment ຊີ້ໄປຫາຮູບພາບຂອງພວກເຮົາ:

kubectl create deployment hello-quarkus — image =gcolman/quarkus-hello-world:1.0.0-SNAPSHOT

ດ້ວຍຄໍາສັ່ງນີ້, ພວກເຮົາບອກ COO ຂອງພວກເຮົາໃຫ້ສ້າງການຕັ້ງຄ່າການໃຊ້ງານ, ເຊິ່ງຄວນຈະມີຂໍ້ກໍານົດຂອງ pod ສໍາລັບຮູບພາບບັນຈຸຂອງພວກເຮົາ. ຄໍາສັ່ງນີ້ຍັງຈະນໍາໃຊ້ການຕັ້ງຄ່ານີ້ກັບກຸ່ມ minikube ຂອງພວກເຮົາ, ແລະສ້າງການນໍາໃຊ້ທີ່ຈະດາວໂຫລດຮູບພາບ container ຂອງພວກເຮົາແລະເປີດຕົວ pod ໃນ cluster.

ຂັ້ນຕອນທີ 5 - ເປີດການເຂົ້າເຖິງການບໍລິການຂອງພວກເຮົາ

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

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

kubectl expose deployment hello-quarkus — type=NodePort — port=8080

ໃຫ້ໃຊ້ເວລາເລັກນ້ອຍເພື່ອເບິ່ງທາງເລືອກ "-type" ຂອງຄໍາສັ່ງ expose.

ເມື່ອພວກເຮົາເປີດເຜີຍແລະສ້າງອົງປະກອບທີ່ຈໍາເປັນເພື່ອດໍາເນີນການບໍລິການຂອງພວກເຮົາ, ໃນບັນດາສິ່ງອື່ນໆ, ພວກເຮົາຈໍາເປັນຕ້ອງສາມາດເຊື່ອມຕໍ່ຈາກພາຍນອກໄປຫາບໍລິການ hello-quarkus, ເຊິ່ງຢູ່ໃນເຄືອຂ່າຍທີ່ກໍານົດໂດຍຊອບແວຂອງພວກເຮົາ. ແລະພາລາມິເຕີ ປະເພດ ອະນຸຍາດໃຫ້ພວກເຮົາສ້າງແລະເຊື່ອມຕໍ່ສິ່ງຕ່າງໆເຊັ່ນ: load balancers ເພື່ອສົ່ງການຈະລາຈອນໄປຫາເຄືອຂ່າຍນີ້.

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

ໃນຕົວຢ່າງຂອງພວກເຮົາ type=NodePort, ນັ້ນແມ່ນ, ການບໍລິການຂອງພວກເຮົາຖືກເຂົ້າເຖິງໂດຍທີ່ຢູ່ IP ຂອງ node ແລະຫມາຍເລກພອດ. ຕົວເລືອກນີ້ອະນຸຍາດໃຫ້ທ່ານບໍ່ໃຊ້ເມຄສາທາລະນະໃດໆ, ແຕ່ຮຽກຮ້ອງໃຫ້ມີຂັ້ນຕອນເພີ່ມເຕີມຈໍານວນຫນຶ່ງ. ກ່ອນອື່ນ ໝົດ, ທ່ານຕ້ອງການຕົວດຸ່ນດ່ຽງການໂຫຼດຂອງທ່ານເອງ, ສະນັ້ນພວກເຮົາຈະ ນຳ ໃຊ້ຕົວດຸ່ນດ່ຽງການໂຫຼດ NGINX ໃນກຸ່ມຂອງພວກເຮົາ.

ຂັ້ນ​ຕອນ​ທີ 6 - ຕິດ​ຕັ້ງ​ການ​ດຸ່ນ​ດ່ຽງ​ການ​ໂຫຼດ​

minikube ມີຈໍານວນຫນ້າທີ່ຂອງແພລະຕະຟອມທີ່ເຮັດໃຫ້ມັນງ່າຍຕໍ່ການສ້າງອົງປະກອບທີ່ສາມາດເຂົ້າເຖິງພາຍນອກໄດ້, ເຊັ່ນ: ຕົວຄວບຄຸມ ingress. Minikube ມາພ້ອມກັບຕົວຄວບຄຸມ ingress Nginx, ແລະສິ່ງທີ່ພວກເຮົາຕ້ອງເຮັດແມ່ນເປີດໃຊ້ມັນແລະຕັ້ງຄ່າມັນ.

minikube addons enable ingress

ຕອນນີ້ພວກເຮົາຈະສ້າງຕົວຄວບຄຸມ Nginx ingress ດ້ວຍຄໍາສັ່ງດຽວ, ເຊິ່ງຈະເຮັດວຽກຢູ່ໃນກຸ່ມ minikube ຂອງພວກເຮົາ:

ingress-nginx-controller-69ccf5d9d8-j5gs9 1/1 Running 1 33m

ຂັ້ນຕອນທີ 7 - ການຕັ້ງຄ່າ ingress

ຕອນນີ້ພວກເຮົາຈໍາເປັນຕ້ອງຕັ້ງຄ່າຕົວຄວບຄຸມ Nginx ingress ເພື່ອໃຫ້ມັນຍອມຮັບຄໍາຮ້ອງຂໍ hello-quarkus.

ແລະສຸດທ້າຍ, ພວກເຮົາຈໍາເປັນຕ້ອງໄດ້ນໍາໃຊ້ການຕັ້ງຄ່ານີ້.

kubectl apply -f ingress.yml

ເນື່ອງຈາກພວກເຮົາກໍາລັງເຮັດທັງຫມົດນີ້ຢູ່ໃນຄອມພິວເຕີຂອງພວກເຮົາເອງ, ພວກເຮົາພຽງແຕ່ເພີ່ມທີ່ຢູ່ IP ຂອງ node ຂອງພວກເຮົາໃສ່ໄຟລ໌ /etc/ hosts ເພື່ອສົ່ງເສັ້ນທາງການຮ້ອງຂໍ http ໄປຫາ minikube ຂອງພວກເຮົາໄປຫາ NGINX load balancer.

192.168.99.100 hello-quarkus.info

ນັ້ນແມ່ນ, ດຽວນີ້ການບໍລິການ minikube ຂອງພວກເຮົາສາມາດເຂົ້າເຖິງພາຍນອກໄດ້ຜ່ານຕົວຄວບຄຸມ Nginx ingress.

ແລ້ວ, ມັນງ່າຍ, ແມ່ນບໍ? ຫຼືບໍ່ຫຼາຍ?

ແລ່ນໃນ OpenShift (Code Ready Containers)

ຕອນນີ້ໃຫ້ເຮົາເບິ່ງວິທີການທັງໝົດນີ້ໃນ Red Hat OpenShift Container Platform (OCP).

ເຊັ່ນດຽວກັນກັບ minikube, ພວກເຮົາເລືອກການອອກແບບກຸ່ມ OpenShift ໂຫນດດຽວໃນຮູບແບບຂອງ Code Ready Containers (CRC). ໃນເມື່ອກ່ອນ, ມັນຖືກເອີ້ນວ່າ minishift ແລະອີງໃສ່ໂຄງການ OpenShift Origin, ແຕ່ໃນປັດຈຸບັນມັນເປັນ CRC ແລະກໍ່ສ້າງຢູ່ໃນເວທີ OpenShift Container Platform ຂອງ Red Hat.

ນີ້, ຂໍອະໄພ, ບໍ່ສາມາດຊ່ວຍໄດ້ແຕ່ເວົ້າວ່າ: "OpenShift ແມ່ນສິ່ງມະຫັດ!"

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

ໃຫ້ຜ່ານຂະບວນການແລະເບິ່ງສິ່ງທີ່ພວກເຮົາຈໍາເປັນຕ້ອງເຮັດ.

ດັ່ງນັ້ນ, ໃນຕົວຢ່າງ minikube, ພວກເຮົາເລີ່ມຕົ້ນດ້ວຍ Docker ... ລໍຖ້າ, ພວກເຮົາບໍ່ຕ້ອງການ Docker ຕິດຕັ້ງຢູ່ໃນເຄື່ອງ.

ແລະພວກເຮົາບໍ່ຕ້ອງການ git ທ້ອງຖິ່ນ.
ແລະ Maven ບໍ່ຈໍາເປັນ.
ແລະທ່ານບໍ່ ຈຳ ເປັນຕ້ອງສ້າງຮູບຖັງດ້ວຍມືຂອງທ່ານ.
ແລະທ່ານບໍ່ ຈຳ ເປັນຕ້ອງຊອກຫາບ່ອນເກັບມ້ຽນຮູບພາບບັນຈຸໃດ ໜຶ່ງ.
ແລະບໍ່ຈໍາເປັນຕ້ອງຕິດຕັ້ງຕົວຄວບຄຸມ ingress.
ແລະທ່ານບໍ່ຈໍາເປັນຕ້ອງ configure ingress.

ເຈົ້າເຂົ້າໃຈ, ແມ່ນບໍ? ເພື່ອນຳໃຊ້ ແລະເປີດໃຊ້ແອັບພລິເຄຊັນຂອງພວກເຮົາໃນ OpenShift, ທ່ານບໍ່ຕ້ອງການອັນໃດອັນໜຶ່ງຂ້າງເທິງ. ແລະຂະບວນການຕົວມັນເອງເບິ່ງຄືວ່ານີ້.

ຂັ້ນຕອນທີ 1 - ເປີດຕົວກຸ່ມ OpenShift ຂອງທ່ານ

ພວກເຮົາໃຊ້ Code Ready Containers ຈາກ Red Hat, ເຊິ່ງໂດຍພື້ນຖານແລ້ວແມ່ນ Minikube ດຽວກັນ, ແຕ່ມີກຸ່ມ Openshift ດຽວທີ່ເຕັມຮູບແບບ.

crc start

ຂັ້ນ​ຕອນ​ທີ 2 – ສ້າງ​ແລະ​ນໍາ​ໃຊ້​ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ​ກັບ​ກຸ່ມ OpenShift​

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

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

ພວກເຮົາຈະໃຊ້ຂະບວນການ OpenShift's Source 2 Image (S2I), ເຊິ່ງມີຫຼາຍວິທີທີ່ແຕກຕ່າງກັນເພື່ອເອົາແຫຼ່ງຂອງພວກເຮົາ (ລະຫັດ ຫຼື binaries) ແລະປ່ຽນມັນໃຫ້ເປັນຮູບບັນຈຸທີ່ເຮັດວຽກຢູ່ໃນກຸ່ມ OpenShift.

ເພື່ອເຮັດສິ່ງນີ້, ພວກເຮົາຕ້ອງການສອງຢ່າງ:

• ລະຫັດແຫຼ່ງຂອງພວກເຮົາແມ່ນຢູ່ໃນ git repository
• ຮູບພາບ Builder ບົນພື້ນຖານທີ່ການກໍ່ສ້າງຈະໄດ້ຮັບການປະຕິບັດ.

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

ທ່ານສາມາດດໍາເນີນການ S2I build ທັງຈາກ OpenShift Developer graphical console ແລະຈາກເສັ້ນຄໍາສັ່ງ. ພວກເຮົາຈະໃຊ້ຄໍາສັ່ງ app ໃຫມ່, ບອກມັນບ່ອນທີ່ຈະເອົາຮູບພາບ builder ແລະລະຫັດແຫຼ່ງຂອງພວກເຮົາ.

oc new-app registry.access.redhat.com/ubi8/openjdk-11:latest~https://github.com/gcolman/quarkus-hello-world.git

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

• ສ້າງບໍລິການ build-pod ສໍາລັບທຸກປະເພດຂອງສິ່ງຕ່າງໆທີ່ກ່ຽວຂ້ອງກັບການກໍ່ສ້າງຄໍາຮ້ອງສະຫມັກ.
• ສ້າງການຕັ້ງຄ່າ OpenShift Build.
• ຂ້ອຍໄດ້ດາວໂຫລດຮູບພາບ builder ໄປທີ່ OpenShift docker registry ພາຍໃນ.
• Cloned "ສະບາຍດີໂລກ" ກັບ repository ທ້ອງຖິ່ນ.
• ຂ້າພະເຈົ້າໄດ້ເຫັນວ່າມີ maven pom ຢູ່ທີ່ນັ້ນ, ດັ່ງນັ້ນຂ້າພະເຈົ້າໄດ້ລວບລວມຄໍາຮ້ອງສະຫມັກໂດຍໃຊ້ maven.
• ສ້າງຮູບພາບບັນຈຸໃຫມ່ທີ່ມີຄໍາຮ້ອງສະຫມັກ Java ທີ່ລວບລວມແລະເອົາຮູບພາບນີ້ເຂົ້າໄປໃນທະບຽນບັນຈຸພາຍໃນ.
• ສ້າງການນຳໃຊ້ Kubernetes ໂດຍມີສະເພາະສຳລັບພອດ, ບໍລິການ, ແລະອື່ນໆ.
• ຂ້ອຍເລີ່ມນຳໃຊ້ຮູບບັນຈຸ.
• ລຶບບໍລິການ build-pod ອອກແລ້ວ.

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

ຖ້າທ່ານຕິດຕາມເບິ່ງການເປີດຕົວຂອງ S2I ໃນ console, ທ່ານສາມາດເບິ່ງວິທີການສ້າງ pod ເປີດຕົວເມື່ອການກໍ່ສ້າງສໍາເລັດ.

ຕອນນີ້ໃຫ້ເບິ່ງບັນທຶກຂອງ builder pod: ກ່ອນອື່ນ, ມັນສະແດງໃຫ້ເຫັນວ່າ maven ເຮັດວຽກຂອງມັນໄດ້ແນວໃດແລະດາວໂຫລດ dependencies ເພື່ອສ້າງຄໍາຮ້ອງສະຫມັກ java ຂອງພວກເຮົາ.

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

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

oc get service

ຫມົດ​ເທົ່າ​ນີ້. ແລະພຽງແຕ່ທີມງານດຽວ. ທັງ​ຫມົດ​ທີ່​ພວກ​ເຮົາ​ຕ້ອງ​ເຮັດ​ແມ່ນ expose ການ​ບໍ​ລິ​ການ​ນີ້​ສໍາ​ລັບ​ການ​ເຂົ້າ​ເຖິງ​ຈາກ​ພາຍ​ນອກ​.

ຂັ້ນຕອນທີ 3 – ເປີດເຜີຍການບໍລິການສໍາລັບການເຂົ້າເຖິງຈາກພາຍນອກ

ເຊັ່ນດຽວກັນກັບກໍລະນີຂອງ KUC, ໃນເວທີ OpenShift "ສະບາຍດີໂລກ" ຂອງພວກເຮົາຍັງຕ້ອງການ router ເພື່ອນໍາການຈະລາຈອນພາຍນອກໄປຫາບໍລິການພາຍໃນກຸ່ມ. OpenShift ເຮັດໃຫ້ມັນງ່າຍຫຼາຍ. ກ່ອນອື່ນ ໝົດ, ອົງປະກອບເສັ້ນທາງ HAProxy ຖືກຕິດຕັ້ງຢູ່ໃນກຸ່ມໂດຍຄ່າເລີ່ມຕົ້ນ (ມັນສາມາດປ່ຽນເປັນ NGINX ດຽວກັນ). ອັນທີສອງ, ມີຊັບພະຍາກອນພິເສດແລະການຕັ້ງຄ່າສູງທີ່ເອີ້ນວ່າ Routes ແລະ reminiscent ຂອງ Ingress objects ໃນ Kubernetes ເກົ່າທີ່ດີ (ໃນຄວາມເປັນຈິງ, OpenShift's Routes ມີອິດທິພົນຢ່າງຫຼວງຫຼາຍຕໍ່ການອອກແບບຂອງ Ingress objects, ເຊິ່ງໃນປັດຈຸບັນສາມາດນໍາໃຊ້ໃນ OpenShift), ແຕ່ສໍາລັບ "ສະບາຍດີໂລກ" ຂອງພວກເຮົາ. , ແລະໃນເກືອບທຸກກໍລະນີ, ເສັ້ນທາງມາດຕະຖານແມ່ນພຽງພໍສໍາລັບພວກເຮົາໂດຍບໍ່ມີການກໍາຫນົດຄ່າເພີ່ມເຕີມ.

ເພື່ອສ້າງ FQDN ທີ່ສາມາດສົ່ງໄດ້ສໍາລັບ "ສະບາຍດີໂລກ" (ແມ່ນແລ້ວ, OpenShiift ມີ DNS ຂອງຕົນເອງສໍາລັບການກໍານົດເສັ້ນທາງໂດຍຊື່ການບໍລິການ), ພວກເຮົາຈະເປີດເຜີຍການບໍລິການຂອງພວກເຮົາ:

oc expose service quarkus-hello-world

ຖ້າທ່ານເບິ່ງເສັ້ນທາງທີ່ສ້າງໃຫມ່, ທ່ານສາມາດຊອກຫາ FQDN ແລະຂໍ້ມູນເສັ້ນທາງອື່ນໆຢູ່ທີ່ນັ້ນ:

oc get route

ແລະສຸດທ້າຍ, ພວກເຮົາເຂົ້າເຖິງການບໍລິການຂອງພວກເຮົາຈາກຕົວທ່ອງເວັບ:

ແຕ່ດຽວນີ້ມັນງ່າຍແທ້ໆ!

ພວກເຮົາຮັກ Kubernetes ແລະທຸກສິ່ງທຸກຢ່າງທີ່ເຕັກໂນໂລຢີນີ້ອະນຸຍາດໃຫ້ພວກເຮົາເຮັດ, ແລະພວກເຮົາຍັງຮັກຄວາມງ່າຍດາຍແລະຄວາມງ່າຍດາຍ. Kubernetes ໄດ້ຖືກສ້າງຂື້ນເພື່ອຄວາມງ່າຍຂອງການເຮັດວຽກຂອງບັນຈຸທີ່ແຈກຢາຍ, ສາມາດຂະຫຍາຍໄດ້ຢ່າງງ່າຍດາຍ, ແຕ່ຄວາມງ່າຍດາຍຂອງມັນບໍ່ໄດ້ພຽງພໍທີ່ຈະເອົາແອັບພລິເຄຊັນເຂົ້າມາໃນການຜະລິດໃນມື້ນີ້. ນີ້ແມ່ນບ່ອນທີ່ OpenShift ເຂົ້າມາຫຼິ້ນ, ຕິດຕາມເວລາແລະສະເຫນີ Kubernetes, ແນໃສ່ນັກພັດທະນາຕົ້ນຕໍ. ຄວາມພະຍາຍາມຫຼາຍໄດ້ຖືກລົງທຶນເພື່ອປັບແຕ່ງແພລະຕະຟອມ OpenShift ໂດຍສະເພາະສໍາລັບນັກພັດທະນາ, ລວມທັງການສ້າງເຄື່ອງມືເຊັ່ນ S2I, ODI, Developer Portal, OpenShift Operator Framework, IDE integration, Developer Catalogues, Helm integration, monitoring ແລະອື່ນໆຈໍານວນຫຼາຍ.

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

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