ມີຫຍັງໃຫມ່ໃນ Red Hat OpenShift 4.2 ແລະ 4.3?

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

ດ້ວຍການປ່ອຍ OpenShift 4.2, Red Hat ໄດ້ເຮັດໃຫ້ການເຮັດວຽກກັບ Kubernetes ງ່າຍຂຶ້ນ. ເຄື່ອງມື ແລະປລັກອິນໃໝ່ໄດ້ປະກົດຂຶ້ນສໍາລັບການສ້າງກ່ອງບັນຈຸ, ທໍ່ CI/CD ແລະການນຳໃຊ້ເຊີບເວີທີ່ບໍ່ມີຕົວຕົນ. ນະວັດຕະກໍາໃຫ້ໂອກາດນັກພັດທະນາສຸມໃສ່ການຂຽນລະຫັດ, ແລະບໍ່ແມ່ນການຈັດການກັບ Kubernetes.

ຕົວຈິງແລ້ວ, ມີຫຍັງໃຫມ່ໃນລຸ້ນ OpenShift 4.2 ແລະ 4.3?

ກ້າວໄປສູ່ເມກປະສົມ

ເມື່ອວາງແຜນໂຄງສ້າງພື້ນຖານດ້ານໄອທີໃຫມ່ຫຼືໃນເວລາທີ່ການພັດທະນາພູມສັນຖານ IT ທີ່ມີຢູ່ແລ້ວ, ບໍລິສັດກໍາລັງພິຈາລະນາວິທີການ cloud ຫຼາຍຂຶ້ນໃນການສະຫນອງຊັບພະຍາກອນ IT, ເຊິ່ງພວກເຂົາປະຕິບັດການແກ້ໄຂຄລາວສ່ວນຕົວຫຼືໃຊ້ພະລັງງານຂອງຜູ້ໃຫ້ບໍລິການຟັງສາທາລະນະ. ດັ່ງນັ້ນ, ໂຄງສ້າງພື້ນຖານດ້ານໄອທີທີ່ທັນສະ ໄໝ ໄດ້ຖືກສ້າງຂື້ນຂື້ນໂດຍອີງຕາມຮູບແບບຄລາວ "ປະສົມ", ເມື່ອທັງຊັບພະຍາກອນໃນພື້ນທີ່ແລະຊັບພະຍາກອນຄລາວສາທາລະນະທີ່ມີລະບົບການຄຸ້ມຄອງທົ່ວໄປຖືກນໍາໃຊ້. Red Hat OpenShift 4.2 ຖືກອອກແບບມາເປັນພິເສດເພື່ອງ່າຍການຫັນປ່ຽນໄປສູ່ຮູບແບບຄລາວແບບປະສົມ ແລະເຮັດໃຫ້ມັນງ່າຍຕໍ່ການເຊື່ອມຕໍ່ຊັບພະຍາກອນຈາກຜູ້ໃຫ້ບໍລິການເຊັ່ນ AWS, Azure ແລະ Google Cloud Platform ກັບກຸ່ມ, ພ້ອມກັບການໃຊ້ຄລາວສ່ວນຕົວໃນ VMware ແລະ OpenStack.

ວິທີການໃຫມ່ໃນການຕິດຕັ້ງ

ໃນຮຸ່ນ 4, ວິທີການຕິດຕັ້ງ OpenShift ໄດ້ປ່ຽນແປງ. Red Hat ສະຫນອງຜົນປະໂຫຍດພິເສດສໍາລັບການນໍາໃຊ້ກຸ່ມ OpenShift - openshift-install . ຜົນປະໂຫຍດແມ່ນໄຟລ໌ຄູ່ດຽວທີ່ຂຽນໃນ Go. Openshit-installer ກະກຽມໄຟລ໌ yaml ທີ່ມີການຕັ້ງຄ່າທີ່ຕ້ອງການສໍາລັບການຕິດຕັ້ງ.

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

ໃນກໍລະນີຂອງການຕິດຕັ້ງໃນຊັບພະຍາກອນຄອມພິວເຕີ້ຂອງທ່ານເອງ, ສໍາລັບຕົວຢ່າງ, ເມື່ອໃຊ້ເມຄສ່ວນຕົວ (vSphere ແລະ OpenStack ໄດ້ຮັບການສະຫນັບສະຫນູນ) ຫຼືເມື່ອຕິດຕັ້ງໃນເຄື່ອງແມ່ຂ່າຍໂລຫະເປົ່າ, ທ່ານຈະຕ້ອງຕັ້ງຄ່າໂຄງສ້າງພື້ນຖານດ້ວຍຕົນເອງ - ກະກຽມເຄື່ອງ virtual ຕໍາ່ສຸດທີ່ຫຼື. ເຊີບເວີທີ່ຕ້ອງການເພື່ອສ້າງກຸ່ມ Control Plane, ກຳນົດຄ່າບໍລິການເຄືອຂ່າຍ. ຫຼັງ​ຈາກ​ການ​ຕັ້ງ​ຄ່າ​ນີ້​, ກຸ່ມ OpenShift ສາ​ມາດ​ໄດ້​ຮັບ​ການ​ສ້າງ​ຕັ້ງ​ຄ້າຍ​ຄື​ກັນ​ກັບ​ຄໍາ​ສັ່ງ​ຫນຶ່ງ​ຂອງ​ອຸ​ປະ​ກອນ​ການ​ຕິດ​ຕັ້ງ openshift​.

ການປັບປຸງໂຄງສ້າງພື້ນຖານ

ການເຊື່ອມໂຍງ CoreOS

ການປັບປຸງທີ່ສໍາຄັນແມ່ນການເຊື່ອມໂຍງກັບ Red Hat CoreOS. ດຽວນີ້ Red Hat OpenShift master nodes ສາມາດເຮັດວຽກໄດ້ ພຽງແຕ່ ໃນ OS ໃຫມ່. ນີ້ແມ່ນລະບົບປະຕິບັດການຟຣີຈາກ Red Hat ທີ່ຖືກອອກແບບມາສະເພາະສໍາລັບການແກ້ໄຂບັນຈຸ. Red Hat CoreOS ເປັນ Linux ທີ່ມີນ້ຳໜັກເບົາທີ່ປັບໃຫ້ເໝາະສົມສຳລັບການແລ່ນບັນຈຸ.

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

ສໍາລັບກຸ່ມທີ່ໃຊ້ RHCOS ສໍາລັບທຸກ nodes, ການຍົກລະດັບ OpenShift Container Platform ແມ່ນຂະບວນການທີ່ງ່າຍດາຍ ແລະອັດຕະໂນມັດສູງ.

ກ່ອນຫນ້ານີ້, ເພື່ອປັບປຸງ OpenShift, ກ່ອນອື່ນ ໝົດ ທ່ານຕ້ອງປັບປຸງລະບົບປະຕິບັດການທີ່ຜະລິດຕະພັນທີ່ເຮັດວຽກຢູ່ (ໃນເວລານັ້ນ, Red Hat Enterprise Linux). ພຽງແຕ່ຫຼັງຈາກນັ້ນ OpenShift ສາມາດໄດ້ຮັບການປັບປຸງຄ່ອຍໆ, node ໂດຍ node. ບໍ່ມີການສົນທະນາກ່ຽວກັບອັດຕະໂນມັດໃດໆຂອງຂະບວນການ.

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

CSI ໃຫມ່

ອັນທີສອງ, CSI ໃຫມ່ແມ່ນຕົວຄວບຄຸມການໂຕ້ຕອບການເກັບຮັກສາທີ່ຊ່ວຍໃຫ້ທ່ານສາມາດເຊື່ອມຕໍ່ລະບົບການເກັບຮັກສາພາຍນອກຕ່າງໆກັບກຸ່ມ OpenShift. ຜູ້ໃຫ້ບໍລິການບ່ອນເກັບຂໍ້ມູນຈໍານວນຫລາຍສໍາລັບ OpenShift ໄດ້ຮັບການສະຫນັບສະຫນູນໂດຍອີງໃສ່ໄດເວີການເກັບຮັກສາທີ່ຖືກຂຽນໂດຍຜູ້ຜະລິດລະບົບການເກັບຮັກສາເອງ. ບັນຊີລາຍຊື່ຄົບຖ້ວນຂອງໄດເວີ CSI ທີ່ຮອງຮັບສາມາດພົບໄດ້ໃນເອກະສານນີ້: https://kubernetes-csi.github.io/docs/drivers.html. ໃນບັນຊີລາຍຊື່ນີ້, ທ່ານສາມາດຊອກຫາຮູບແບບຕົ້ນຕໍຂອງ disk arrays ຈາກຜູ້ຜະລິດຊັ້ນນໍາ (Dell/EMC, IBM, NetApp, Hitachi, HPE, PureStorage), SDS solutions (Ceph) ແລະການເກັບຮັກສາຟັງ (AWS, Azure, Google). OpenShift 4.2 ຮອງຮັບໄດເວີ CSI ຂອງສະເພາະ CSI ລຸ້ນ 1.1.

RedHat OpenShift ບໍລິການ Mesh

ອີງໃສ່ໂຄງການ Istio, Kiali ແລະ Jaeger, Red Hat OpenShift Service Mesh, ນອກເຫນືອໄປຈາກວຽກງານປົກກະຕິຂອງເສັ້ນທາງການຮ້ອງຂໍລະຫວ່າງການບໍລິການ, ອະນຸຍາດໃຫ້ມີການຕິດຕາມແລະການເບິ່ງເຫັນຂອງພວກເຂົາ. ນີ້ຊ່ວຍໃຫ້ນັກພັດທະນາຕິດຕໍ່ສື່ສານ, ຕິດຕາມ ແລະຈັດການແອັບພລິເຄຊັນທີ່ນຳໃຊ້ຢູ່ໃນ Red Hat OpenShift ໄດ້ຢ່າງງ່າຍດາຍ.

ການສະແດງພາບຂອງແອັບພລິເຄຊັນທີ່ມີສະຖາປັດຕະຍະກຳບໍລິການຈຸລະພາກໂດຍໃຊ້ Kiali

ເພື່ອເຮັດໃຫ້ການຕິດຕັ້ງ, ການບໍາລຸງຮັກສາ, ແລະການຄຸ້ມຄອງວົງຈອນຊີວິດຂອງ Service Mesh ງ່າຍຂຶ້ນຫຼາຍເທົ່າທີ່ເປັນໄປໄດ້, Red Hat OpenShift ໃຫ້ຜູ້ບໍລິຫານກັບຜູ້ປະຕິບັດການພິເສດ, Service Mesh Operator. ນີ້ແມ່ນຕົວປະຕິບັດການ Kubernetes ທີ່ອະນຸຍາດໃຫ້ທ່ານສາມາດປັບຕັ້ງຄ່າຊຸດ Istio, Kiali ແລະ Jaeger ຄືນໃໝ່ຢູ່ໃນກຸ່ມ, ເພີ່ມທະວີການເພີ່ມພາລະການບໍລິຫານຂອງການຈັດການແອັບພລິເຄຊັນ.

CRI-O ແທນ Docker

Docker runtime container ເລີ່ມຕົ້ນຖືກແທນທີ່ດ້ວຍ CRI-O. ມັນເປັນໄປໄດ້ທີ່ຈະໃຊ້ CRI-O ແລ້ວໃນຮຸ່ນ 3.11, ແຕ່ໃນ 4.2 ມັນໄດ້ກາຍເປັນຕົ້ນຕໍ. ບໍ່ດີຫຼືບໍ່ດີ, ແຕ່ບາງສິ່ງບາງຢ່າງທີ່ຕ້ອງຢູ່ໃນໃຈໃນເວລາທີ່ນໍາໃຊ້ຜະລິດຕະພັນ.

ຜູ້ປະຕິບັດການແລະການນໍາໃຊ້ຄໍາຮ້ອງສະຫມັກ

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

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

OperatorHub ແມ່ນສາມາດເຂົ້າເຖິງໄດ້ໂດຍກົງຈາກສ່ວນຕິດຕໍ່ເວັບຂອງ console ການຈັດການ. ມັນເປັນບັນຊີລາຍການຄໍາຮ້ອງສະຫມັກສໍາລັບ OpenShift ຮັກສາໄວ້ໂດຍ Red Hat. ເຫຼົ່ານັ້ນ. ຜູ້ປະກອບການທີ່ໄດ້ຮັບອະນຸມັດ Red Hat ທັງໝົດຈະຖືກຄຸ້ມຄອງໂດຍການສະໜັບສະໜູນຜູ້ຂາຍ.

ປະຕູ OperatorHub ໃນ console ການຈັດການ OpenShift

ຮູບພາບພື້ນຖານທົ່ວໄປ

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

ເຄື່ອງ​ມື CI/CD

ໃນ RedHat OpenShif 4.2, ມັນເປັນໄປໄດ້ທີ່ຈະເລືອກເອົາລະຫວ່າງ Jenkins ແລະ OpenShift Pipelines ໂດຍອີງໃສ່ Tekton Pipelines.

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

OpenShift Pipelines ປະຈຸບັນຢູ່ໃນ Developer Preview ແລະມີໃຫ້ເປັນຜູ້ປະຕິບັດການຢູ່ໃນກຸ່ມ OpenShift 4. ແນ່ນອນ, ຜູ້ໃຊ້ OpenShift ຍັງສາມາດໃຊ້ Jenkins ໃນ RedHat OpenShift 4 ໄດ້.

ການອັບເດດການຄຸ້ມຄອງຜູ້ພັດທະນາ

ໃນ 4.2 OpenShift, ການໂຕ້ຕອບເວັບໄດ້ຖືກປັບປຸງຢ່າງສົມບູນສໍາລັບທັງນັກພັດທະນາແລະຜູ້ບໍລິຫານ.

ໃນລຸ້ນກ່ອນໜ້າຂອງ OpenShift, ທຸກຄົນໄດ້ເຮັດວຽກຢູ່ໃນສາມ consoles: ໄດເລກະທໍລີບໍລິການ, ຄອນໂຊຜູ້ເບິ່ງແຍງລະບົບ ແລະບ່ອນເຮັດວຽກ. ໃນປັດຈຸບັນ cluster ໄດ້ຖືກແບ່ງອອກເປັນພຽງແຕ່ສອງສ່ວນ - administrator console ແລະ developer console .

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

ປະຕູນັກພັດທະນາໃນ console ການຈັດການ OpenShift

ຂ້ອຍ​ໄດ້​ຍິນ

Odo ເປັນ​ປະ​ສິດ​ທິ​ຜົນ​ເສັ້ນ​ຄໍາ​ສັ່ງ​ທີ່​ຮັດ​ກຸມ​ຜູ້​ພັດ​ທະ​ນາ​ທີ່​ເຮັດ​ໃຫ້​ການ​ພັດ​ທະ​ນາ​ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ​ງ່າຍ​ໃນ OpenShift​. ການນໍາໃຊ້ການສື່ສານແບບ git push, CLI ນີ້ຊ່ວຍໃຫ້ນັກພັດທະນາໃຫມ່ຂອງ Kubernetes ສ້າງແອັບພລິເຄຊັນໃນ OpenShift.

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

ດຽວນີ້ນັກພັດທະນາສາມາດສ້າງ, ແກ້ບັນຫາ ແລະນຳໃຊ້ແອັບພລິເຄຊັນຂອງເຂົາເຈົ້າໃນ OpenShift ໂດຍບໍ່ຕ້ອງອອກຈາກສະພາບແວດລ້ອມການພັດທະນາລະຫັດທີ່ເຂົາເຈົ້າມັກ, ເຊັ່ນ Microsoft Visual Studio, JetBrains (ລວມທັງ IntelliJ), Eclipse Desktop, ແລະອື່ນໆ.

ສ່ວນຂະຫຍາຍການໃຊ້ Red Hat OpenShift ສໍາລັບ Microsoft Azure DevOps

ສ່ວນຂະຫຍາຍ Red Hat OpenShift Deployment ສໍາລັບ Microsoft Azure DevOps ໄດ້ຖືກປ່ອຍອອກມາ. ຜູ້ໃຊ້ຊຸດເຄື່ອງມື DevOps ດຽວນີ້ສາມາດນຳໃຊ້ແອັບພລິເຄຊັນຂອງພວກເຂົາໄປໃສ່ Azure Red Hat OpenShift ຫຼືກຸ່ມ OpenShift ອື່ນໆໄດ້ໂດຍກົງຈາກ Microsoft Azure DevOps.

ການ​ຫັນ​ປ່ຽນ​ຈາກ​ສະ​ບັບ​ທີ​ສາມ​ໄປ​ຫາ​ສີ່​

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

ແຕ່ມີຂ່າວດີ: Red Hat ສະຫນອງເຄື່ອງມືສໍາລັບການເຄື່ອນຍ້າຍໂຄງການຈາກ 3.7 ຫາ 4.2. ທ່ານສາມາດຍ້າຍວຽກຂອງແອັບພລິເຄຊັນໄດ້ໂດຍໃຊ້ Cluster Application Migration (CAM). CAM ອະນຸຍາດໃຫ້ທ່ານສາມາດຄວບຄຸມການເຄື່ອນຍ້າຍແລະຫຼຸດຜ່ອນການຢຸດຄໍາຮ້ອງສະຫມັກ.

OpenShift 4.3

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

ອັບເດດ Kubernetes ເວີຊັນ 1.16.

ສະບັບໄດ້ຖືກຍົກລະດັບໂດຍສອງຂັ້ນຕອນໃນເວລາດຽວກັນ; ໃນ OpenShift 4.2 ມັນແມ່ນ 1.14.

ການເຂົ້າລະຫັດຂໍ້ມູນ ເປັນຕົ້ນ

ເລີ່ມຕົ້ນດ້ວຍຮຸ່ນ 4.3, ມັນເປັນໄປໄດ້ທີ່ຈະເຂົ້າລະຫັດຂໍ້ມູນໃນຖານຂໍ້ມູນ etcd. ເມື່ອການເຂົ້າລະຫັດຖືກເປີດໃຊ້, ມັນຈະສາມາດເຂົ້າລະຫັດຊັບພະຍາກອນ OpenShift API ແລະ Kubernetes API ຕໍ່ໄປນີ້: ຄວາມລັບ, ConfigMaps, ເສັ້ນທາງ, tokens ການເຂົ້າເຖິງ, ແລະການອະນຸຍາດ OAuth.

Helm

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

ການປັບປຸງ Dashboard ໂຄງການ

ໃນສະບັບໃຫມ່, Project Dashboard ສະຫນອງຂໍ້ມູນເພີ່ມເຕີມໃນຫນ້າໂຄງການ: ສະຖານະພາບໂຄງການ, ການນໍາໃຊ້ຊັບພະຍາກອນ, ແລະໂຄຕ້າໂຄງການ.

ສະແດງຊ່ອງໂຫວ່ສໍາລັບ quay ໃນ Web console

ຄຸນສົມບັດໄດ້ຖືກເພີ່ມໃສ່ console ການຈັດການເພື່ອສະແດງຈຸດອ່ອນທີ່ຮູ້ຈັກສໍາລັບຮູບພາບໃນບ່ອນເກັບມ້ຽນ Quay. ສະ​ແດງ​ຄວາມ​ສ່ຽງ​ສໍາ​ລັບ​ການ repositories ທ້ອງ​ຖິ່ນ​ແລະ​ພາຍ​ນອກ​ແມ່ນ​ສະ​ຫນັບ​ສະ​ຫນູນ​.

ການສ້າງແບບງ່າຍດາຍຂອງ operatorhub ອອບໄລນ໌

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

ຜູ້ຂຽນ:
Victor Puchkov, Yuri Semenyukov

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