ຄອນເທນເນີແອັບພລິເຄຊັນແມ່ນຮູບແບບຂອງຄອນເທນເນີທີ່ໄດ້ຮັບຄວາມນິຍົມທີ່ສຸດ. ເຫຼົ່ານີ້ແມ່ນສິ່ງທີ່ນັກພັດທະນາ ແລະ ເຈົ້າຂອງແອັບພລິເຄຊັນໃຫ້ຄວາມສົນໃຈ. ຄອນເທນເນີແອັບພລິເຄຊັນປະກອບມີລະຫັດທີ່ນັກພັດທະນາເຮັດວຽກນຳ. ເຊິ່ງລວມມີ, ຕົວຢ່າງ: MySQL, Apache, MongoDB, ແລະ Node.js.

ໂດຍປົກກະຕິແລ້ວ ຄອນເທນເນີຖືກມອງວ່າເປັນເຕັກໂນໂລຊີທີ່ໃຊ້ສຳລັບການຕິດຕັ້ງແອັບພລິເຄຊັນທີ່ບໍ່ມີການປ່ຽນແປງ (immutable) ແລະ ສາມາດຕິດຕັ້ງໃໝ່ ຫຼື ປິດການເຮັດວຽກໄດ້ທຸກເວລາໂດຍບໍ່ສົ່ງຜົນກະທົບທີ່ຮ້າຍແຮງ. ເພື່ອເປັນການປຽບທຽບ, ສິ່ງເຫຼົ່ານີ້ມັກຈະຖືກເອີ້ນວ່າ "cattle" (ຝູງສັດ). ຄອນເທນເນີໃນສະພາບແວດລ້ອມການພັດທະນານີ້ບໍ່ມີ "ຕົວຕົນ", ຜູ້ໃຊ້ບໍ່ຈຳເປັນຕ້ອງສົນໃຈວ່າຄອນເທນເນີຈະຢູ່ບ່ອນໃດໃນຄລັສເຕີ (cluster), ຄອນເທນເນີຈະຖືກກູ້ຄືນໂດຍອັດຕະໂນມັດຫຼັງຈາກເກີດຂໍ້ຜິດພາດ ແລະ ສາມາດຂະຫຍາຍ ຫຼື ຫຼຸດຂະໜາດໄດ້ຕາມຄວາມຕ້ອງການ. ໃນທາງກົງກັນຂ້າມ, ເມື່ອຄອນເທນເນີແບບ "pet" (ສັດລ້ຽງ) ເກີດຂໍ້ຜິດພາດ, ແອັບພລິເຄຊັນທີ່ກຳລັງເຮັດວຽກຢູ່ຈະໄດ້ຮັບຜົນກະທົບໂດຍກົງ ແລະ ອາດຈະລົ້ມເຫຼວໄດ້ຄືກັນ. ເຊັ່ນດຽວກັນກັບສັດລ້ຽງ, ຄອນເທນເນີແບບ pet ຕ້ອງການການເອົາໃຈໃສ່ ແລະ ການຈັດການຈາກຜູ້ໃຊ້ຢ່າງໃກ້ຊິດ ແລະ ມັກຈະມີການກວດສອບສະຖານະ (health checks) ຢ່າງສະໝໍ່າສະເໝີ. ຕົວຢ່າງທີ່ຊັດເຈນຄື ຖານຂໍ້ມູນທີ່ເຮັດເປັນຄອນເທນເນີ.

ເມື່ອສ້າງໂຄງສ້າງພື້ນຖານຄອນເທນເນີໃນໂຮສ (host) ທີ່ອອກແບບມາເພື່ອຄອນເທນເນີໂດຍສະເພາະ ເຊັ່ນ Atomic Host, ຜູ້ບໍລິຫານລະບົບຍັງຄົງຕ້ອງປະຕິບັດໜ້າທີ່ໃນການບໍລິຫານຈັດການ. ບໍ່ວ່າຈະໃຊ້ກັບລະບົບແບບກະຈາຍ ເຊັ່ນ Kubernetes ຫຼື OpenShift ຫຼື ໂຮສຄອນເທນເນີແບບສະແຕນອາໂລນ (standalone), ຄອນເທນເນີທີ່ມີສິດທິສູງພິເສດ (SPCs) ແມ່ນເຄື່ອງມືທີ່ມີປະສິດທິພາບ. SPCs ສາມາດເຮັດໄດ້ແມ່ນແຕ່ການໂຫຼດໂມດູນເຄີເນິລ (kernel modules) ສະເພາະ, ເຊັ່ນການໃຊ້ systemtap. ໃນໂຄງສ້າງພື້ນຖານທີ່ສ້າງຂຶ້ນເພື່ອແລ່ນຄອນເທນເນີ, ຜູ້ບໍລິຫານສ່ວນຫຼາຍຈະຕ້ອງໃຊ້ SPCs ເພື່ອເຮັດສິ່ງຕ່າງໆ ເຊັ່ນ ການຈັດການ, ການຕິດຕາມ, ການສຳຮອງຂໍ້ມູນ ແລະ ອື່ນໆ. ມັນເປັນສິ່ງສຳຄັນທີ່ຕ້ອງຮູ້ວ່າ ໂດຍປົກກະຕິແລ້ວຈະມີຄວາມກ່ຽວພັນກັນຢ່າງໃກ້ຊິດລະຫວ່າງ SPCs ແລະ ເຄີເນິລຂອງໂຮສ, ດັ່ງນັ້ນຜູ້ບໍລິຫານຈຶ່ງຕ້ອງເລືອກໂຮສຄອນເທນເນີທີ່ມີຄວາມສະຖຽນ ແລະ ເຮັດໃຫ້ເປັນມາດຕະຖານ, ໂດຍສະເພາະໃນສະພາບແວດລ້ອມແບບຄລັສເຕີ/ແບບກະຈາຍຂະໜາດໃຫຍ່ ເຊິ່ງການແກ້ໄຂບັນຫາຈະເຮັດໄດ້ຍາກກວ່າ. ຈາກນັ້ນ ພວກເຂົາຕ້ອງເລືອກຢູເຊີສເປສ (user space) ໃນ SPC ທີ່ເຂົ້າກັນໄດ້ກັບເຄີເນິລຂອງໂຮສ.

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

ເວົ້າງ່າຍໆກໍຄື, ຮູບພາບພື້ນຖານແມ່ນຮູບພາບທີ່ບໍ່ມີເລເຢີແມ່ (parent layer). ໂດຍປົກກະຕິແລ້ວ, ຮູບພາບພື້ນຖານຈະປະກອບມີສຳເນົາໃໝ່ຂອງລະບົບປະຕິບັດການ. ປົກກະຕິຮູບພາບພື້ນຖານຈະລວມມີເຄື່ອງມືລະບົບຫຼັກ ເຊັ່ນ bash ຫຼື coreutils ແລະ ເຄື່ອງມືທີ່ຈຳເປັນໃນການຕິດຕັ້ງແພັກເກດ ແລະ ອັບເດດຮູບພາບໃນອະນາຄົດ (yum, rpm, apt-get, dnf, microdnf…​) ໃນຂະນະທີ່ຮູບພາບພື້ນຖານສາມາດ “ສ້າງດ້ວຍມື” ໄດ້, ແຕ່ໃນທາງປະຕິບັດ ພວກມັນມັກຈະຖືກຜະລິດ ແລະ ເຜີຍແຜ່ໂດຍໂຄງການໂອເພນຊອດ (ເຊັ່ນ Debian, Fedora ຫຼື CentOS) ແລະ ຜູ້ຈຳໜ່າຍ (ເຊັ່ນ Red Hat). ແຫຼ່ງທີ່ມາຂອງຮູບພາບພື້ນຖານແມ່ນມີຄວາມສຳຄັນຫຼາຍສຳລັບຄວາມປອດໄພ. ສະຫຼຸບສັ້ນໆກໍຄື, ຈຸດປະສົງດຽວຂອງຮູບພາບພື້ນຖານແມ່ນເພື່ອສະໜອງຈຸດເລີ່ມຕົ້ນສຳລັບການສ້າງຮູບພາບອະນຸພັນ (derivative images) ຂອງທ່ານ. ເມື່ອໃຊ້ Dockerfile, ການເລືອກຮູບພາບພື້ນຖານທີ່ທ່ານກຳລັງໃຊ້ນັ້ນແມ່ນຈະແຈ້ງ: ` FROM registry.fedoraproject.org/fedora `

ນີ້ແມ່ນຮູບແບບພິເສດຂອງຮູບພາບຄອນເທນເນີ ເຊິ່ງເຮັດໜ້າທີ່ຜະລິດຮູບພາບຄອນເທນເນີແອັບພລິເຄຊັນອອກມາ. ພວກມັນປະກອບມີທຸກຢ່າງຍົກເວັ້ນລະຫັດຕົ້ນສະບັບ (source code) ຂອງນັກພັດທະນາ. ຮູບພາບຕົວສ້າງປະກອບມີໄລບຣາຣີຂອງລະບົບປະຕິບັດການ, ພາສາຣັນທາມ (language runtimes), ມິດເດິລແວ (middleware), ແລະ ເຄື່ອງມື source-to-image.

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

ຕົວຢ່າງ, ຖ້ານັກພັດທະນາມີລະຫັດ PHP ແລະ ພວກເຂົາຕ້ອງການແລ່ນມັນໃນຄອນເທນເນີ, ພວກເຂົາສາມາດໃຊ້ຮູບພາບຕົວສ້າງ PHP ເພື່ອຜະລິດຮູບພາບຄອນເທນເນີແອັບພລິເຄຊັນທີ່ພ້ອມໃຊ້ງານໄດ້. ນັກພັດທະນາຈະສົ່ງ URL ຂອງ GitHub ບ່ອນທີ່ເກັບລະຫັດໄວ້ ແລະ ຮູບພາບຕົວສ້າງຈະຈັດການສ່ວນທີ່ເຫຼືອໃຫ້ເອງ. ຜົນໄດ້ຮັບຂອງຄອນເທນເນີຕົວສ້າງແມ່ນຮູບພາບຄອນເທນເນີແອັບພລິເຄຊັນ ເຊິ່ງລວມມີ Red Hat Enterprise Linux, PHP ຈາກ Software Collections, ແລະ ລະຫັດຂອງນັກພັດທະນາເຂົ້າໄວ້ນຳກັນ ແລະ ພ້ອມໃຊ້ງານ. ຮູບພາບຕົວສ້າງສະໜອງວິທີການທີ່ມີປະສິດທິພາບໃນການປ່ຽນຈາກລະຫັດໄປເປັນຄອນເທນເນີໄດ້ຢ່າງວ່ອງໄວ ແລະ ງ່າຍດາຍ ໂດຍສ້າງຂຶ້ນຈາກອົງປະກອບທີ່ເຊື່ອຖືໄດ້.

ຮູບພາບຕົວສ້າງບາງອັນຖືກສ້າງຂຶ້ນໃນຮູບແບບທີ່ຊ່ວຍໃຫ້ນັກພັດທະນາບໍ່ພຽງແຕ່ສະໜອງລະຫັດຕົ້ນສະບັບເທົ່ານັ້ນ, ແຕ່ຍັງສາມາດກຳນົດຄ່າ (custom configuration) ສຳລັບຊອບແວທີ່ຕິດຕັ້ງມາໃນຮູບພາບນຳອີກ. ຕົວຢ່າງໜຶ່ງແມ່ນ ຮູບພາບຕົວສ້າງ Nginx ໃນຄັງເກັບ source-to-image ຕົ້ນທາງ.

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

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

ຮູບພາບຄອນເທນເນີແບບປະສົມ (Intermodal) ແມ່ນຮູບພາບທີ່ມີໂຄງສ້າງແບບໄຮບຣິດ (hybrid). ຕົວຢ່າງ, ຮູບພາບ Red Hat Software Collections ຫຼາຍອັນສາມາດນຳໃຊ້ໄດ້ສອງວິທີ.

ທຳອິດ, ພວກມັນສາມາດໃຊ້ເປັນຄອນເທນເນີແອັບພລິເຄຊັນທົ່ວໄປທີ່ແລ່ນ Ruby on Rails ແລະ Apache server ຢ່າງຄົບຖ້ວນໃນຕົວ.

ທີສອງ, ພວກມັນສາມາດໃຊ້ເປັນຮູບພາບຕົວສ້າງພາຍໃນ OpenShift Container Platform. ໃນກໍລະນີນີ້, ຮູບພາບລູກທີ່ໄດ້ຈະປະກອບມີ Ruby on Rails, Apache, ແລະ ລະຫັດແອັບພລິເຄຊັນທີ່ຂະບວນການ source-to-image ຊີ້ໄປຫາໃນລະຫວ່າງຂັ້ນຕອນການສ້າງ.

ຮູບແບບປະສົມກຳລັງກາຍມາເປັນທີ່ນິຍົມຫຼາຍຂຶ້ນເລື້ອຍໆ ເພື່ອແກ້ໄຂບັນຫາທຸລະກິດສອງຢ່າງດ້ວຍຮູບພາບຄອນເທນເນີດຽວ.

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

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

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

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

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