ແພລະຕະຟອມທີ່ທັນສະໄຫມສໍາລັບການພັດທະນາແລະການນໍາໃຊ້ຊອບແວ

ນີ້ແມ່ນຄັ້ງທໍາອິດໃນຊຸດຂອງຂໍ້ຄວາມກ່ຽວກັບການປ່ຽນແປງ, ການປັບປຸງ, ແລະການເພີ່ມເຕີມໃນການປັບປຸງໃຫມ່ Red Hat OpenShift platform 4.0 ທີ່ຈະຊ່ວຍໃຫ້ທ່ານກະກຽມສໍາລັບການຫັນປ່ຽນໄປສູ່ສະບັບໃຫມ່.

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

ແນ່ນອນ, ການປະກາດແຕ່ລະບໍລິການຟັງໃຫມ່ແມ່ນມາພ້ອມກັບການສົນທະນາຈໍານວນຫລາຍລະຫວ່າງຜູ້ຊ່ຽວຊານໃນ Twitter, ແລະການໂຕ້ວາທີໄດ້ຖືກດໍາເນີນໃນຫຼາຍໆຫົວຂໍ້ - ລວມທັງການສິ້ນສຸດຂອງຍຸກເປີດ, ການຫຼຸດລົງຂອງ IT ໃນສະຖານທີ່, ແລະຄວາມຫຼີກລ່ຽງບໍ່ໄດ້. ຂອງ​ການ​ຜູກ​ຂາດ​ຊອບ​ແວ​ໃຫມ່​ໃນ​ການ​ຟັງ​, ແລະ​ວິ​ທີ​ການ​ໃຫມ່ X paradigm ຈະ​ທົດ​ແທນ paradigms ອື່ນໆ​ທັງ​ຫມົດ​.

ບໍ່ຈໍາເປັນຕ້ອງເວົ້າ, ການຂັດແຍ້ງທັງຫມົດເຫຼົ່ານີ້ແມ່ນໂງ່ຫຼາຍ

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

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

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

ດ້ວຍວ່າ, ທີມງານ OpenShift ຖາມຄໍາຖາມງ່າຍໆຫນຶ່ງ:

ເຈົ້າສາມາດເຮັດໃຫ້ການເຮັດວຽກກັບ Kubernetes ງ່າຍຂຶ້ນ ແລະສະດວກກວ່າໄດ້ແນວໃດ?

ຄໍາຕອບແມ່ນຈະແຈ້ງທີ່ຫນ້າປະຫລາດໃຈ:

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

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

ວິທີການບັນລຸຜົນໄດ້ຮັບນີ້?

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

ໃນຕອນຕົ້ນຂອງ 2018, Red Hat ໄດ້ຊື້ໂຄງການ CoreOS, ທີ່ມີທັດສະນະທີ່ຄ້າຍຄືກັນກ່ຽວກັບອະນາຄົດ - ປອດໄພກວ່າແລະເຊື່ອຖືໄດ້, ສ້າງຂຶ້ນໃນຫຼັກການເປີດແຫຼ່ງ. ບໍລິສັດໄດ້ເຮັດວຽກເພື່ອພັດທະນາແນວຄວາມຄິດເຫຼົ່ານີ້ຕື່ມອີກແລະປະຕິບັດມັນ, ເອົາປັດຊະຍາຂອງພວກເຮົາໄປສູ່ການປະຕິບັດ - ພະຍາຍາມໃຫ້ແນ່ໃຈວ່າຊອບແວທັງຫມົດເຮັດວຽກຢ່າງປອດໄພ. ວຽກງານທັງໝົດນີ້ແມ່ນສ້າງຂຶ້ນໃນ Kubernetes, Linux, clouds ສາທາລະນະ, clouds ສ່ວນຕົວ, ແລະໂຄງການອື່ນໆຫຼາຍພັນໂຄງການທີ່ເນັ້ນໃສ່ລະບົບນິເວດດິຈິຕອນທີ່ທັນສະໄຫມຂອງພວກເຮົາ.

ການປ່ອຍໃຫມ່ຂອງ OpenShift 4 ຈະມີຄວາມຊັດເຈນ, ອັດຕະໂນມັດແລະທໍາມະຊາດຫຼາຍຂຶ້ນ

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

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

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

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

OpenShift 4: ແພລະຕະຟອມ NoOps ທີ່ບໍ່ຕ້ອງການການບໍາລຸງຮັກສາ

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

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

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

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

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

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

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

Kubernetes ໃນ OpenShift ເປັນແພລະຕະຟອມທີ່ຖືກອອກແບບມາເພື່ອແກ້ໄຂບັນຫາຕົ້ນຕໍສອງຢ່າງ: ແທນທີ່ຈະບັງຄັບໃຫ້ທ່ານເຂົ້າໃຈເຄື່ອງຈັກ virtual ຫຼື load balancer APIs, ມັນເຮັດວຽກກັບ abstractions ທີ່ມີຄໍາສັ່ງສູງກວ່າ - ຂະບວນການແລະການບໍລິການ. ແທນທີ່ຈະຕິດຕັ້ງຊອບແວຕົວແທນ, ທ່ານສາມາດດໍາເນີນການບັນຈຸ, ແລະແທນທີ່ຈະຂຽນ stack ຕິດຕາມກວດກາຂອງທ່ານເອງ, ໃຊ້ເຄື່ອງມືທີ່ມີຢູ່ໃນເວທີ. ດັ່ງນັ້ນ, ຊອດລັບຂອງ OpenShift 4 ແມ່ນບໍ່ເປັນຄວາມລັບແທ້ໆ - ມັນເປັນພຽງແຕ່ການເອົາຫຼັກການ SRE ແລະແນວຄວາມຄິດເຊີຟເວີແລະນໍາມັນໄປສູ່ການສະຫລຸບຢ່າງມີເຫດຜົນເພື່ອຊ່ວຍໃຫ້ນັກພັດທະນາແລະວິສະວະກອນປະຕິບັດງານ:

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

ແຕ່ຄວາມແຕກຕ່າງລະຫວ່າງແພລະຕະຟອມ OpenShift 4 ແລະລຸ້ນກ່ອນຂອງມັນແລະຈາກວິທີການ "ມາດຕະຖານ" ໃນການແກ້ໄຂບັນຫາດັ່ງກ່າວແມ່ນຫຍັງ? ຂະໜາດໃດທີ່ເຮັດໃຫ້ທີມງານຈັດຕັ້ງປະຕິບັດ ແລະ ປະຕິບັດງານ? ເນື່ອງຈາກຄວາມຈິງທີ່ວ່າກະສັດໃນສະຖານະການນີ້ແມ່ນກຸ່ມ. ດັ່ງນັ້ນ,

• ພວກເຮົາໃຫ້ແນ່ໃຈວ່າຈຸດປະສົງຂອງກຸ່ມແມ່ນຈະແຈ້ງ (ທີ່ຮັກແພງ, ຂ້າພະເຈົ້າໄດ້ເລືອກເອົາກຸ່ມນີ້ເພາະວ່າຂ້ອຍສາມາດ)
• ເຄື່ອງຈັກ ແລະ ລະບົບປະຕິບັດການມີຢູ່ເພື່ອຮັບໃຊ້ກຸ່ມ (ກະສັດຂອງເຈົ້າ)
• ຈັດການສະຖານະຂອງເຈົ້າພາບຈາກກຸ່ມ, ຫຼຸດຜ່ອນການສ້າງຄືນໃຫມ່ຂອງພວກເຂົາ (ພຽງການລອຍລົມ).
• ສໍາລັບແຕ່ລະອົງປະກອບທີ່ສໍາຄັນຂອງລະບົບ, nanny (ກົນໄກ) ແມ່ນຈໍາເປັນທີ່ຈະຕິດຕາມກວດກາແລະລົບລ້າງບັນຫາ
• ຄວາມລົ້ມເຫຼວຂອງ * ທຸກໆດ້ານ * ຫຼືອົງປະກອບຂອງລະບົບແລະກົນໄກການຟື້ນຕົວທີ່ກ່ຽວຂ້ອງແມ່ນເປັນສ່ວນປົກກະຕິຂອງຊີວິດ
• ໂຄງລ່າງພື້ນຖານທັງໝົດຕ້ອງຖືກຕັ້ງຄ່າຜ່ານ API.
• ໃຊ້ Kubernetes ເພື່ອແລ່ນ Kubernetes. (ແມ່ນແລ້ວ, ມັນບໍ່ແມ່ນການພິມຜິດ)
• ການອັບເດດຄວນຈະງ່າຍແລະບໍ່ຫຍຸ້ງຍາກໃນການຕິດຕັ້ງ. ຖ້າມັນໃຊ້ເວລາຫຼາຍກວ່າຫນຶ່ງຄລິກເພື່ອຕິດຕັ້ງການອັບເດດ, ແນ່ນອນວ່າພວກເຮົາກໍາລັງເຮັດຫຍັງຜິດ.
• ການຕິດຕາມແລະການແກ້ບັນຫາອົງປະກອບໃດໆບໍ່ຄວນເປັນບັນຫາ, ແລະດັ່ງນັ້ນການຕິດຕາມແລະການລາຍງານທົ່ວໂຄງສ້າງພື້ນຖານທັງຫມົດຄວນຈະງ່າຍແລະສະດວກ.

ຕ້ອງການເບິ່ງຄວາມສາມາດຂອງເວທີໃນການປະຕິບັດບໍ?

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

1. ເພື່ອເລີ່ມຕົ້ນ, ໄປທີ່ try.openshift.com ແລະກົດ "ເລີ່ມຕົ້ນ".
2. ເຂົ້າສູ່ລະບົບບັນຊີ Red Hat ຂອງທ່ານ (ຫຼືສ້າງອັນໃຫມ່) ແລະປະຕິບັດຕາມຄໍາແນະນໍາເພື່ອຕັ້ງຄ່າກຸ່ມທໍາອິດຂອງທ່ານ.

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

ລອງລຸ້ນ OpenShift ໃໝ່ ແລະແບ່ງປັນຄວາມຄິດເຫັນຂອງທ່ານ. ພວກເຮົາມຸ່ງໝັ້ນທີ່ຈະເຮັດໃຫ້ການເຮັດວຽກກັບ Kumbernetes ເຂົ້າເຖິງໄດ້ ແລະຫຍຸ້ງຍາກເທົ່າທີ່ຈະເປັນໄປໄດ້—ອະນາຄົດຂອງ NoOps ເລີ່ມຕົ້ນໃນມື້ນີ້.

ດຽວນີ້ເອົາໃຈໃສ່!
ໃນກອງປະຊຸມ DevOpsForum 2019 ໃນວັນທີ 20 ເດືອນເມສາ, ຫນຶ່ງໃນນັກພັດທະນາ OpenShift, Vadim Rutkovsky, ຈະຖືຫ້ອງຮຽນຕົ້ນສະບັບ - ລາວຈະທໍາລາຍສິບກຸ່ມແລະບັງຄັບໃຫ້ພວກເຂົາແກ້ໄຂ. ກອງປະຊຸມແມ່ນຈ່າຍ, ແຕ່ດ້ວຍລະຫັດສົ່ງເສີມການຂາຍ #RedHat ທ່ານໄດ້ຮັບສ່ວນຫຼຸດ 37%.

ຫ້ອງຮຽນ ປະລິນຍາໂທ ເວລາ 17:15 - 18:15 ໂມງ ແລະ ຫໍພັກແມ່ນເປີດຕະຫຼອດມື້. ເສື້ອທີເຊີດ, ໝວກ, ສະຕິກເກີ - ປົກກະຕິ!

ຫ້ອງ #2
"ທີ່ນີ້ລະບົບທັງຫມົດຕ້ອງໄດ້ຮັບການປ່ຽນແປງ: ພວກເຮົາສ້ອມແປງກຸ່ມ k8s ທີ່ແຕກຫັກພ້ອມກັບກົນໄກທີ່ໄດ້ຮັບການຢັ້ງຢືນ."

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