ເນື້ອໃນຂອງຮູບພາບ

ເນື້ອໃນທີ່ອະນຸຍາດ

Dockerfiles ໃນ Fedora ບໍ່ຄວນມີລະຫັດ (code) ໃໝ່ທີ່ຍັງບໍ່ທັນໄດ້ຜ່ານການແພັກເກດ. ຄວາມໝາຍຄື ຊອບແວຄວນຖືກແພັກເກດໃຫ້ຖືກຕ້ອງເປັນ RPM ແລະ ວາງໄວ້ໃນຄັງເກັບ (repositories) ຂອງ Fedora, Dockerfiles ເປັນພຽງກົນໄກການຈັດສົ່ງສຳລັບການກຳນົດຄ່າ "ພ້ອມໃຊ້ງານ" ທີ່ຕັ້ງໄວ້ລ່ວງໜ້າເທົ່ານັ້ນ. ເນື້ອໃນໃດໆທີ່ຈະມານຳ Dockerfile ຕ້ອງເປັນໄຟລ໌ກຳນົດຄ່າ (configuration files) ຫຼື ສະຄຣິບເລີ່ມຕົ້ນ/ຈັດການ (startup/orchestration scripts). ເປົ້າໝາຍຂອງສິ່ງນີ້ແມ່ນເພື່ອໃຫ້ພວກເຮົາປະຕິບັດຕາມຈຸດສຳຄັນຂອງ ປັດຊະຍາວິສະວະກຳການປ່ອຍຕົວຂອງ Fedora.

ການຈັດວາງໄຟລ໌

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

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

ຕຳແໜ່ງ ແລະ ຮູບແບບການຕັ້ງຊື່ທີ່ແນະນຳມີດັ່ງນີ້ (ໂດຍໃຊ້ MySQL ເປັນຕົວຢ່າງ):

Table 1. ຕຳແໜ່ງຂອງໄຟລ໌ສະໜັບສະໜູນ

ຕຳແໜ່ງ

ຄຳອະທິບາຍ

/usr/bin/run-mysqld

ໄຟລ໌ທີ່ໃຊ້ປະມວນຜົນຫຼັກທີ່ຜູ້ໃຊ້ມັກໃຊ້; ປົກກະຕິແລ້ວອັນໜຶ່ງຈະຖືກຕັ້ງເປັນ CMD ເລີ່ມຕົ້ນ

/usr/libexec/container-setup

ສະຄຣິບທີ່ຖືກລັນໃນລະຫວ່າງການສ້າງຄອນເທນເນີເພື່ອຕຽມເນື້ອໃນຄອນເທນເນີ; ດ້ວຍຄຳສັ່ງນີ້ ພວກເຮົາສາມາດລັນພຽງຄຳສັ່ງດຽວແທນທີ່ຈະມີສະຄຣິບທີ່ຊັບຊ້ອນຢູ່ໃນ Dockerfile ໂດຍກົງ

/etc/my.cnf

ໄຟລ໌ກຳນົດຄ່າຫຼັກສຳລັບ daemon, ຕຳແໜ່ງຂອງໄຟລ໌ກຳນົດຄ່າຄວນຈະຄືກັນກັບໃນ RPM, ເພາະວ່າມັນແມ່ນສິ່ງທີ່ຜູ້ໃຊ້ຄາດຫວັງ

/usr/share/container-scripts/mysql/my-tuning.cnf.template

ແມ່ແບບສຳລັບໄຟລ໌ກຳນົດຄ່າອື່ນ, ເນື້ອໃນຂອງມັນອາດຈະຖືກປະມວນຜົນໂດຍໃຊ້ເຄື່ອງມື envsubst, ດັ່ງນັ້ນຄ່າທີ່ແນ່ນອນຈະຖືກຕັ້ງຕາມຕົວປ່ຽນສະພາບແວດລ້ອມ (environment variables) ທີ່ໃຫ້ມາເປັນອາຣ໌ກິວເມັນ (argument) ໃຫ້ກັບຄຳສັ່ງ docker run

/var/lib/mysql/data

ເສັ້ນທາງໄປຫາຂໍ້ມູນ, ເຊິ່ງມັກຈະເປັນ docker VOLUME; ສ່ວນ data ແມ່ນມີຄວາມສຳຄັນເພື່ອໃຫ້ໄດເຣັກທໍຣີທີ່ເຊື່ອມຕໍ່ແບບ volume ບໍ່ມີໂຟນເດີແມ່ທີ່ເປັນຂອງ root

ເພື່ອເຮັດໃຫ້ Dockerfile ສະອາດ, ມັນເປັນວິທີທີ່ດີທີ່ຈະເອົາໄຟລ໌ທັງໝົດໄວ້ໃນໄດເຣັກທໍຣີດຽວ ແລະ ໃຊ້ຕຳແໜ່ງສຸດທ້າຍຂອງພວກມັນພາຍໃຕ້ໄດເຣັກທໍຣີນັ້ນ. ໃນກໍລະນີຂອງຕົວຢ່າງ MySQL ຂ້າງເທິງ, ມັນອາດຈະມີລັກສະນະດັ່ງນີ້:

ການເພີ່ມໄຟລ໌ທັງໝົດໃນ Dockerfile ສາມາດເຮັດໄດ້ງ່າຍໆດັ່ງນີ້:

``` COPY root / ```

ໄຟລ໌ຕົ້ນສະບັບອາດຈະຖືກເກັບໄວ້ໃນ FTP ຫຼື ສື່ກາງອື່ນໆທີ່ບໍ່ຮັກສາຄຸນລັກສະນະຂອງໄຟລ໌ UNIX, ດັ່ງນັ້ນ Dockerfile ຫຼື ສະຄຣິບ `container-setup` ຄວນກວດສອບໃຫ້ແນ່ໃຈວ່າໄຟລ໌ຈະມີການຕັ້ງຄ່າຄຸນລັກສະນະທີ່ເໝາະສົມ, ເຊັ່ນວ່າໄຟລ໌ໃນ `/usr/bin/*` ຕ້ອງສາມາດປະມວນຜົນ (executable) ໄດ້, ແລະ ອື່ນໆ.


=== ບໍລິການແບບຫຼາຍຄອນເທນເນີ (Multi Container Services)

ແຕ່ລະຮູບພາບຄອນເທນເນີຄວນໃຫ້ບໍລິການພຽງແຕ່ "ບໍລິການ" ດຽວ ແລະ ບໍລິການແບບຫຼາຍຄອນເທນເນີຄວນຖືກຈັດການໂດຍເຄື່ອງມືຈັດການ (orchestration tool) ພາຍນອກຕາມການຕັດສິນໃຈຂອງຜູ້ໃຊ້ ເຊັ່ນ [https://www.openshift.org/ OpenShift Origin], [http://kubernetes.io/ kubernetes], [http://deis.io/ deis], [https://docs.docker.com/swarm/ Docker Swarm], [https://docs.docker.com/compose/ Docker Compose], [https://dcos.io/ DC/OS], [https://www.cloudfoundry.org/ Cloud Foundry], [https://mesos.apache.org/ Apache Mesos], ແລະ ອື່ນໆ.

ບໍລິການແບບຫຼາຍຄອນເທນເນີປະເພດເຫຼົ່ານີ້ຄວນຖືກບັນທຶກໄວ້ໃນລັກສະນະທີ່ຜູ້ໃຊ້ສາມາດປັບປ່ຽນໃຫ້ເຂົ້າກັບຄວາມຕ້ອງການຂອງພວກເຂົາໄດ້. ຕົວຢ່າງໜຶ່ງແມ່ນການໃຊ້ຂໍ້ກຳນົດຂອງ [https://projectatomic.io Project Atomic] [https://github.com/projectatomic/nulecule nulecule].