ການພັດທະນາແອັບພລິເຄຊັນ ແລະການນຳໃຊ້ Blue-Green, ອີງໃສ່ The Twelve-Factor App methodology ທີ່ມີຕົວຢ່າງໃນ php ແລະ docker

ຫນ້າທໍາອິດ, ທິດສະດີເລັກນ້ອຍ. ເກີດ​ຫຍັງ​ຂຶ້ນ ແອັບສິບສອງປັດໃຈ?

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

ເອກະສານດັ່ງກ່າວໄດ້ຖືກສ້າງຂື້ນໂດຍນັກພັດທະນາຂອງເວທີ Heroku.

ແອັບ Twelve-Factor ສາມາດໃຊ້ກັບແອັບພລິເຄຊັ່ນທີ່ຂຽນເປັນພາສາການຂຽນໂປຣແກຣມໃດກໍໄດ້ ແລະນຳໃຊ້ການລວມກັນຂອງການບໍລິການສຳຮອງ (ຖານຂໍ້ມູນ, ແຖວຂໍ້ຄວາມ, ແຄສ, ແລະອື່ນໆ).

ໂດຍຫຍໍ້ກ່ຽວກັບປັດໃຈທີ່ວິທີການນີ້ແມ່ນອີງໃສ່:

1. codebase – ຫນຶ່ງ codebase ຕິດ ຕາມ ໃນ ການ ຄວບ ຄຸມ ສະ ບັບ - ການ ນໍາ ໃຊ້ ຫຼາຍ
2. ການເພິ່ງພາອາໄສ - ປະກາດຢ່າງຈະແຈ້ງ ແລະແຍກຕົວເພິ່ງພາອາໄສ
3. ການຕັ້ງຄ່າ - ຊ່ວຍ​ປະ​ຢັດ​ການ​ຕັ້ງ​ຄ່າ​ໃນ runtime​
4. ບໍລິການດ້ານຫຼັງ – ພິ​ຈາ​ລະ​ນາ​ການ​ບໍ​ລິ​ການ​ຮອງ​ຮັບ​ເປັນ​ຊັບ​ພະ​ຍາ​ກອນ​ສຽບ​ໃນ​
5. ກໍ່ສ້າງ, ປ່ອຍ, ແລ່ນ - ແຍກຂັ້ນຕອນການປະກອບ ແລະການປະຕິບັດຢ່າງເຂັ້ມງວດ
6. ຂະບວນການຕ່າງໆ - ດໍາເນີນການຄໍາຮ້ອງສະຫມັກເປັນຫນຶ່ງຫຼືຫຼາຍຂະບວນການທີ່ບໍ່ມີລັດ
7. ການຜູກມັດພອດ - ການ​ບໍ​ລິ​ການ​ສົ່ງ​ອອກ​ໂດຍ​ຜ່ານ​ການ​ຜູກ​ມັດ​ທ່າ​ເຮືອ​
8. ຂະຫນານ - ຂະ​ຫຍາຍ​ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ​ຂອງ​ທ່ານ​ໂດຍ​ນໍາ​ໃຊ້​ຂະ​ບວນ​ການ​
9. ຄວາມພິການ - ເພີ່ມປະສິດທິພາບຄວາມຫນ້າເຊື່ອຖືດ້ວຍການເລີ່ມຕົ້ນໄວແລະການປິດທີ່ສະອາດ
10. ການ​ພັດ​ທະ​ນາ​ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ / parity ການ​ດໍາ​ເນີນ​ງານ​ - ຮັກ​ສາ​ການ​ພັດ​ທະ​ນາ​, ຂັ້ນ​ຕອນ​, ແລະ​ສະ​ພາບ​ແວດ​ລ້ອມ​ການ​ຜະ​ລິດ​ຂອງ​ທ່ານ​ເປັນ​ທີ່​ຄ້າຍ​ຄື​ກັນ​ເທົ່າ​ທີ່​ເປັນ​ໄປ​ໄດ້​
11. ການຕັດໄມ້ - ເບິ່ງບັນທຶກເປັນກະແສຂອງເຫດການ
12. ວຽກງານບໍລິຫານ - ປະຕິບັດວຽກງານບໍລິຫານ / ການຄຸ້ມຄອງໂດຍໃຊ້ຂະບວນການສະເພາະ

ທ່ານສາມາດໄດ້ຮັບຂໍ້ມູນເພີ່ມເຕີມກ່ຽວກັບ 12 ປັດໃຈຈາກຊັບພະຍາກອນຕໍ່ໄປນີ້:

• ແຫຼ່ງທີ່ເປັນທາງການ - ຕ້ອງ​ອ່ານ​
• ບົດຄວາມກ່ຽວກັບ habr. ແອັບສິບສອງປັດໃຈ — ການ​ແປ​ພາ​ສາ​ຢ່າງ​ເປັນ​ທາງ​ການ​
• ບົດຄວາມກ່ຽວກັບ habr. 7 ປັດໄຈທີ່ຂາດຫາຍໄປໃນ 12 ປັດໄຈ App - ເບິ່ງສົດ 12 ປັດໃຈ ໂດຍມີຈຸດປະສົງປັບປຸງ.

ການນຳໃຊ້ Blue-Green ແມ່ນຫຍັງ?

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

ຮູບແບບ BG Deploy ແບບຄລາສສິກເບິ່ງຄືກັບທີ່ສະແດງຢູ່ໃນຮູບຂ້າງລຸ່ມນີ້.

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

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

ຄໍາແນະນໍາທີ່ບໍ່ດີແລະດີ

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

ຕົວຢ່າງສ່ວນໃຫຍ່ຈະຢູ່ໃນວິທີການຫນຶ່ງຫຼືອື່ນທີ່ຕັດກັນກັບການພັດທະນາເວັບ (ນີ້ແມ່ນຄວາມແປກໃຈ), ມີ PHP ແລະ Docker.

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

1. Codebase

ໃຊ້ FTP ແລະ FileZilla ເພື່ອອັບໂຫລດໄຟລ໌ໄປຫາເຄື່ອງແມ່ຂ່າຍຫນຶ່ງຄັ້ງ, ຢ່າເກັບລະຫັດຢູ່ບ່ອນອື່ນນອກເຫນືອຈາກເຄື່ອງແມ່ຂ່າຍການຜະລິດ.

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

2. ຄວາມເພິ່ງພາອາໄສ

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

ໂຄງ​ການ​ຄວນ​ຈະ​ມີ​ບັນ​ຊີ​ລາຍ​ການ​ທີ່​ສາ​ມາດ​ເຂົ້າ​ໃຈ​ຢ່າງ​ຈະ​ແຈ້ງ​ຂອງ​ການ​ເພິ່ງ​ພາ​ອາ​ໄສ (ໂດຍ​ການ​ເພິ່ງ​ພາ​ອາ​ໄສ​ຂ້າ​ພະ​ເຈົ້າ​ຍັງ​ຫມາຍ​ເຖິງ​ສິ່ງ​ແວດ​ລ້ອມ​)​. ການເພິ່ງພາອາໄສທັງໝົດຈະຕ້ອງຖືກກຳນົດຢ່າງຈະແຈ້ງ ແລະໂດດດ່ຽວ.
ໃຫ້​ໃຊ້​ເວ​ລາ​ເປັນ​ຕົວ​ຢ່າງ​ ປະ и Docker.

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

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

3. ການຕັ້ງຄ່າ

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

ການຕັ້ງຄ່າ - ນີ້ແມ່ນວິທີດຽວທີ່ການປະຕິບັດໂຄງການຄວນແຕກຕ່າງກັນ. ໂດຍຫລັກການແລ້ວ, ການຕັ້ງຄ່າຄວນຈະຖືກສົ່ງຜ່ານຕົວແປສະພາບແວດລ້ອມ (env vars).

ນັ້ນແມ່ນ, ເຖິງແມ່ນວ່າທ່ານຈະເກັບໄຟລ໌ການຕັ້ງຄ່າຫຼາຍ .config.prod .config.local ແລະປ່ຽນຊື່ມັນໃນເວລາທີ່ໃຊ້ເປັນ .config (ການຕັ້ງຄ່າຕົ້ນຕໍທີ່ແອັບພລິເຄຊັນອ່ານຂໍ້ມູນ) - ນີ້ຈະບໍ່ເປັນວິທີການທີ່ຖືກຕ້ອງ, ນັບຕັ້ງແຕ່. ໃນ​ກໍ​ລະ​ນີ​ນີ້​ຂໍ້​ມູນ​ຈາກ​ການ​ຕັ້ງ​ຄ່າ​ຈະ​ມີ​ໃຫ້​ສາ​ທາ​ລະ​ນະ​ສໍາ​ລັບ​ຜູ້​ພັດ​ທະ​ນາ​ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ​ທັງ​ຫມົດ​ແລະ​ຂໍ້​ມູນ​ຈາກ​ເຄື່ອງ​ແມ່​ຂ່າຍ​ຂອງ​ການ​ຜະ​ລິດ​ຈະ​ຖືກ​ລັກ​. ການກຳນົດຄ່າທັງໝົດຕ້ອງຖືກເກັບໄວ້ໂດຍກົງໃນລະບົບການນຳໃຊ້ (CI/CD) ແລະສ້າງຂື້ນສຳລັບສະພາບແວດລ້ອມຕ່າງໆ ດ້ວຍຄ່າທີ່ແຕກຕ່າງກັນທີ່ຈຳເປັນສຳລັບສະພາບແວດລ້ອມສະເພາະໃນເວລານຳໃຊ້.

4. ບໍລິການພາກສ່ວນທີສາມ

ຕິດກັບສະພາບແວດລ້ອມຢ່າງເຂັ້ມງວດ, ໃຊ້ການເຊື່ອມຕໍ່ທີ່ແຕກຕ່າງກັນສໍາລັບການບໍລິການດຽວກັນໃນບາງສະພາບແວດລ້ອມ.

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

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

5. ກໍ່ສ້າງ, ປົດປ່ອຍ, ປະຕິບັດ

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

ທຸກຂັ້ນຕອນຂອງການນຳໃຊ້ຕ້ອງແຍກອອກຈາກກັນ.

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

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

6. ຂະບວນການ

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

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

7. Port binding

ພຽງແຕ່ເຄື່ອງແມ່ຂ່າຍເວັບໄຊຕ໌ຄວນຮູ້ວິທີການເຮັດວຽກກັບບໍລິການພາກສ່ວນທີສາມ. ຫຼືດີກວ່າ, ຕິດຕັ້ງບໍລິການພາກສ່ວນທີສາມໂດຍກົງພາຍໃນເວັບເຊີບເວີ. ຕົວຢ່າງ, ເປັນໂມດູນ PHP ໃນ Apache.
ການບໍລິການທັງຫມົດຂອງເຈົ້າຕ້ອງສາມາດເຂົ້າເຖິງກັນແລະກັນໂດຍຜ່ານການເຂົ້າເຖິງບາງທີ່ຢູ່ແລະພອດ (localgost: 5432, localhost: 3000, nginx: 80, php-fpm: 9000), ນັ້ນແມ່ນ, ຈາກ nginx ຂ້ອຍສາມາດເຂົ້າເຖິງທັງ php-fpm ແລະໄປຫາ. postgres, ແລະຈາກ php-fpm ກັບ postgres ແລະ nginx ແລະຕົວຈິງແລ້ວຈາກແຕ່ລະບໍລິການຂ້ອຍສາມາດເຂົ້າເຖິງບໍລິການອື່ນ. ດ້ວຍວິທີນີ້, ຄວາມເປັນໄປໄດ້ຂອງການບໍລິການບໍ່ໄດ້ຜູກມັດກັບຄວາມເປັນໄປໄດ້ຂອງການບໍລິການອື່ນ.

8. ການຂະໜານ

ເຮັດວຽກກັບຂະບວນການດຽວ, ຖ້າບໍ່ດັ່ງນັ້ນຂະບວນການຫຼາຍຈະບໍ່ສາມາດເຂົ້າກັນໄດ້!

ອອກຈາກຫ້ອງສໍາລັບການປັບຂະຫນາດ. Docker swarm ແມ່ນດີເລີດສໍາລັບການນີ້.
Docker Swarm ເປັນເຄື່ອງມືໃນການສ້າງ ແລະ ຈັດການກຸ່ມຕູ້ບັນຈຸທັງລະຫວ່າງເຄື່ອງທີ່ຕ່າງກັນ ແລະຊຸດບັນຈຸບັນຈຸຢູ່ໃນເຄື່ອງດຽວກັນ.

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

9. Disposability

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

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

10. ການພັດທະນາແອັບພລິເຄຊັນ/ຄວາມສະເໝີພາບຂອງການປະຕິບັດງານ

ການຜະລິດ, ຂັ້ນຕອນແລະສະບັບທ້ອງຖິ່ນຂອງຄໍາຮ້ອງສະຫມັກຕ້ອງແຕກຕ່າງກັນ. ໃນການຜະລິດພວກເຮົາໃຊ້ກອບ Yii Lite, ແລະຢູ່ໃນທ້ອງຖິ່ນ Yii, ເພື່ອໃຫ້ມັນເຮັດວຽກໄວໃນການຜະລິດ!

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

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

11. ບັນທຶກ

ພວກເຮົາຂຽນບັນທຶກໃສ່ໄຟລ໌ ແລະຖານຂໍ້ມູນ! ພວກເຮົາບໍ່ເຮັດຄວາມສະອາດໄຟລ໌ແລະຖານຂໍ້ມູນຈາກບັນທຶກ. ຂໍໃຫ້ຊື້ຮາດໄດທີ່ມີ 9000 Peta bytes ແລະນັ້ນດີ.

ບັນທຶກທັງໝົດຄວນຖືວ່າເປັນກະແສເຫດການ. ແອັບພລິເຄຊັນຕົວມັນເອງບໍ່ຄວນມີສ່ວນຮ່ວມໃນການບັນທຶກການປຸງແຕ່ງ. ບັນທຶກຄວນຈະຖືກສົ່ງອອກໄປ stdout ຫຼືສົ່ງຜ່ານໂປໂຕຄອນເຊັ່ນ udp, ດັ່ງນັ້ນການເຮັດວຽກກັບບັນທຶກຈະບໍ່ສ້າງບັນຫາໃດໆສໍາລັບແອັບພລິເຄຊັນ. greylog ແມ່ນດີສໍາລັບການນີ້. Graylog ຮັບບັນທຶກທັງຫມົດຜ່ານ udp (ໂປໂຕຄອນນີ້ບໍ່ຈໍາເປັນຕ້ອງລໍຖ້າການຕອບສະຫນອງກ່ຽວກັບການຕ້ອນຮັບທີ່ປະສົບຜົນສໍາເລັດຂອງແພັກເກັດ) ບໍ່ແຊກແຊງຄໍາຮ້ອງສະຫມັກໃນທາງໃດກໍ່ຕາມແລະພຽງແຕ່ຈັດການກັບໂຄງສ້າງແລະການປຸງແຕ່ງບັນທຶກ. ເຫດຜົນຂອງຄໍາຮ້ອງສະຫມັກບໍ່ປ່ຽນແປງເພື່ອເຮັດວຽກກັບວິທີການດັ່ງກ່າວ.

12. ວຽກງານບໍລິຫານ

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

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

ຕົວຢ່າງການປະຕິບັດໃນ PHP, Laravel, Laradock, Docker-Compose

PS ຕົວຢ່າງທັງຫມົດໄດ້ຖືກສ້າງຂື້ນໃນ MacOS. ພວກມັນສ່ວນໃຫຍ່ຍັງເຫມາະສົມສໍາລັບ Linux. ຜູ້ໃຊ້ Windows, ໃຫ້ອະໄພຂ້ອຍ, ແຕ່ຂ້ອຍບໍ່ໄດ້ເຮັດວຽກກັບ Windows ເປັນເວລາດົນນານ.

ໃຫ້ຈິນຕະນາການສະຖານະການທີ່ພວກເຮົາບໍ່ມີ PHP ລຸ້ນໃດຕິດຕັ້ງຢູ່ໃນ PC ຂອງພວກເຮົາແລະບໍ່ມີຫຍັງເລີຍ.
ຕິດຕັ້ງ docker ແລະ docker-compose ເວີຊັນຫຼ້າສຸດ. (ນີ້ສາມາດພົບໄດ້ໃນອິນເຕີເນັດ)

docker -v && 
docker-compose -v

1. ພວກເຮົາວາງ Laradock

git clone https://github.com/Laradock/laradock.git && 
ls

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

2. Configure Laradock ເພື່ອດໍາເນີນການຄໍາຮ້ອງສະຫມັກຂອງພວກເຮົາ.

cd laradock && 
cp env-example .env

2.1. ເປີດໄດເລກະທໍລີ habr (ໂຟນເດີຫຼັກທີ່ laradock ຖືກ cloned) ໃນບາງບັນນາທິການ. (ໃນກໍລະນີ PHPStorm ຂອງຂ້ອຍ)

ໃນຂັ້ນຕອນນີ້ພວກເຮົາພຽງແຕ່ໃຫ້ຊື່ໂຄງການ.

2.2. ເປີດຕົວຮູບພາບພື້ນທີ່ເຮັດວຽກ. (ໃນກໍລະນີຂອງທ່ານ, ຮູບພາບຕ່າງໆຈະໃຊ້ເວລາໃນການສ້າງ)
ພື້ນທີ່ເຮັດວຽກແມ່ນຮູບພາບທີ່ກຽມໄວ້ເປັນພິເສດສຳລັບການເຮັດວຽກກັບກອບໃນນາມຂອງຜູ້ພັດທະນາ.

ພວກເຮົາເຂົ້າໄປໃນຖັງໂດຍໃຊ້

docker-compose up -d workspace && 
docker-compose exec workspace bash

2.3. ການຕິດຕັ້ງ Laravel

composer create-project --prefer-dist laravel/laravel application

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

ls
exit
docker-compose down

2.5. ໃຫ້ກັບຄືນໄປບ່ອນ PHPStorm ແລະກໍານົດເສັ້ນທາງທີ່ຖືກຕ້ອງກັບຄໍາຮ້ອງສະຫມັກ laravel ຂອງພວກເຮົາໃນໄຟລ໌ .env.

3. ເພີ່ມລະຫັດທັງຫມົດໃສ່ Git.

ເພື່ອເຮັດສິ່ງນີ້, ພວກເຮົາຈະສ້າງ repository ໃນ Github (ຫຼືບ່ອນອື່ນ). ໃຫ້ໄປທີ່ໄດເລກະທໍລີ habr ໃນ terminal ແລະປະຕິບັດລະຫັດຕໍ່ໄປນີ້.

echo "# habr-12factor" >> README.md
git init
git add README.md
git commit -m "first commit"
git remote add origin [email protected]:nzulfigarov/habr-12factor.git # здесь будет ссылка на ваш репо
git push -u origin master
git status

ໃຫ້ກວດເບິ່ງວ່າທຸກສິ່ງທຸກຢ່າງແມ່ນຢູ່ໃນຄໍາສັ່ງ.

ເພື່ອຄວາມສະດວກສະບາຍ, ຂ້ອຍຂໍແນະນໍາໃຫ້ໃຊ້ການໂຕ້ຕອບສາຍຕາສໍາລັບ Git, ໃນກໍລະນີຂອງຂ້ອຍ GitKraken. (ນີ້ແມ່ນລິ້ງອ້າງອີງ)

4. ເປີດຕົວ!

ກ່ອນທີ່ຈະເລີ່ມຕົ້ນ, ໃຫ້ແນ່ໃຈວ່າບໍ່ມີຫຍັງຕິດຢູ່ໃນພອດ 80 ແລະ 443.

docker-compose up -d nginx php-fpm

ດັ່ງນັ້ນ, ໂຄງການຂອງພວກເຮົາປະກອບດ້ວຍ 3 ບໍລິການແຍກຕ່າງຫາກ:

• nginx - ເຄື່ອງແມ່ຂ່າຍເວັບໄຊຕ໌
• php-fpm - php ສໍາລັບການໄດ້ຮັບການຮ້ອງຂໍຈາກເຄື່ອງແມ່ຂ່າຍເວັບໄຊຕ໌
• ພື້ນທີ່ເຮັດວຽກ - php ສໍາລັບນັກພັດທະນາ

ໃນປັດຈຸບັນ, ພວກເຮົາບັນລຸໄດ້ທີ່ພວກເຮົາໄດ້ສ້າງຄໍາຮ້ອງສະຫມັກທີ່ຕອບສະຫນອງ 4 ຈຸດໃນຈໍານວນ 12, ຄື:

1. codebase — ລະຫັດທັງໝົດຢູ່ໃນບ່ອນເກັບມ້ຽນອັນດຽວ (ໝາຍເຫດນ້ອຍໆ: ມັນອາດຈະຖືກຕ້ອງທີ່ຈະເພີ່ມ docker ພາຍໃນໂຄງການ laravel, ແຕ່ມັນບໍ່ສຳຄັນ).

2. ການເພິ່ງພາອາໄສ - ການເພິ່ງພາອາໄສທັງໝົດຂອງພວກເຮົາຖືກຂຽນຢ່າງຈະແຈ້ງໃນແອັບພລິເຄຊັນ/composer.json ແລະໃນແຕ່ລະ Dockerfile ຂອງແຕ່ລະບັນຈຸ.

3. ບໍລິການດ້ານຫຼັງ — ແຕ່ລະບໍລິການ (php-fom, nignx, workspace) ໃຊ້ຊີວິດຂອງຕົນເອງແລະເຊື່ອມຕໍ່ຈາກພາຍນອກແລະເມື່ອເຮັດວຽກກັບບໍລິການຫນຶ່ງ, ອີກບໍລິການຫນຶ່ງຈະບໍ່ໄດ້ຮັບຜົນກະທົບ.

4. ຂະບວນການຕ່າງໆ — ແຕ່​ລະ​ການ​ບໍ​ລິ​ການ​ແມ່ນ​ຫນຶ່ງ​ຂະ​ບວນ​ການ​. ແຕ່ລະບໍລິການບໍ່ໄດ້ຮັກສາສະຖານະພາຍໃນ.

5. ການຜູກມັດພອດ

docker ps

ດັ່ງທີ່ພວກເຮົາສາມາດເຫັນໄດ້, ແຕ່ລະບໍລິການດໍາເນີນການຢູ່ໃນທ່າເຮືອຂອງຕົນເອງແລະສາມາດເຂົ້າເຖິງບໍລິການອື່ນໆທັງຫມົດ.

6. ຂະຫນານ

Docker ອະນຸຍາດໃຫ້ພວກເຮົາສ້າງຂະບວນການຫຼາຍອັນຂອງການບໍລິການດຽວກັນດ້ວຍການດຸ່ນດ່ຽງການໂຫຼດອັດຕະໂນມັດລະຫວ່າງພວກມັນ.

ໃຫ້ຢຸດເຊົາການບັນຈຸແລະແລ່ນໃຫ້ເຂົາເຈົ້າຜ່ານທຸງ --scale

docker-compose down && 
docker-compose up -d --scale php-fpm=3 nginx php-fpm

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

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

8. ການ​ພັດ​ທະ​ນາ​ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ / parity ການ​ດໍາ​ເນີນ​ງານ​ - ສະພາບແວດລ້ອມຂອງພວກເຮົາທັງຫມົດແມ່ນຄືກັນ. ໂດຍການເຮັດວຽກຂອງລະບົບໃນເຄື່ອງແມ່ຂ່າຍໃນການຜະລິດ, ທ່ານຈະບໍ່ຈໍາເປັນຕ້ອງມີການປ່ຽນແປງຫຍັງໃນຄໍາສັ່ງຂອງທ່ານ. ທຸກສິ່ງທຸກຢ່າງຈະອີງໃສ່ Docker ໃນທາງດຽວກັນ.

9. ການຕັດໄມ້ — ບັນ​ທຶກ​ທັງ​ຫມົດ​ໃນ​ບັນ​ຈຸ​ເຫຼົ່າ​ນີ້​ໄປ​ສະ​ຕ​ຣີມ​ແລະ​ສາ​ມາດ​ເບິ່ງ​ເຫັນ​ຢູ່​ໃນ Docker console​. (ໃນ​ກໍ​ລະ​ນີ​ນີ້​, ໃນ​ຄວາມ​ເປັນ​ຈິງ​, ມີ​ພາ​ຊະ​ນະ​ທີ່​ເຮັດ​ດ້ວຍ​ເຮືອນ​ອື່ນໆ​, ນີ້​ອາດ​ຈະ​ບໍ່​ແມ່ນ​ຖ້າ​ຫາກ​ວ່າ​ທ່ານ​ບໍ່​ໄດ້​ດູ​ແລ​ມັນ​)

 docker-compose logs -f

ແຕ່, ມີການຈັບໄດ້ວ່າຄ່າ Default ໃນ PHP ແລະ Nginx ຍັງຂຽນບັນທຶກໃສ່ໄຟລ໌. ເພື່ອຕອບສະຫນອງ 12 ປັດໃຈ, ມັນເປັນສິ່ງຈໍາເປັນ ຕັດຂາດ ການຂຽນບັນທຶກໃສ່ໄຟລ໌ໃນການຕັ້ງຄ່າຂອງແຕ່ລະ container ແຍກຕ່າງຫາກ.

Docker ຍັງສະຫນອງຄວາມສາມາດໃນການສົ່ງບັນທຶກບໍ່ພຽງແຕ່ stdout, ແຕ່ຍັງກັບສິ່ງຕ່າງໆເຊັ່ນ greylog, ທີ່ຂ້າພະເຈົ້າໄດ້ກ່າວມາຂ້າງເທິງ. ແລະພາຍໃນ greylog, ພວກເຮົາສາມາດດໍາເນີນການບັນທຶກຕາມທີ່ພວກເຮົາກະລຸນາແລະຄໍາຮ້ອງສະຫມັກຂອງພວກເຮົາຈະບໍ່ສັງເກດເຫັນນີ້ໃນທາງໃດກໍ່ຕາມ.

10​. ວຽກງານບໍລິຫານ — ວຽກບໍລິຫານທັງໝົດຖືກແກ້ໄຂໂດຍ laravel ຂອບໃຈກັບເຄື່ອງມືຊ່າງຊ່າງຢ່າງແນ່ນອນຕາມທີ່ຜູ້ສ້າງແອັບພລິເຄຊັ່ນ 12 ຕ້ອງການ.

ເປັນຕົວຢ່າງ, ຂ້ອຍຈະສະແດງວິທີການປະຕິບັດຄໍາສັ່ງບາງຢ່າງ.
ພວກເຮົາເຂົ້າໄປໃນຖັງ.

 
docker-compose exec workspace bash
php artisan list

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

11​. ການຕັ້ງຄ່າ ແລະ 12. ກໍ່ສ້າງ, ປ່ອຍ, ແລ່ນ

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

ໃນສັ້ນ, ແນວຄວາມຄິດແມ່ນອີງໃສ່ລະບົບ CI / CD ເຊັ່ນ Jenkins и Gitlab CI. ໃນທັງສອງ, ທ່ານສາມາດກໍານົດຕົວແປສະພາບແວດລ້ອມທີ່ກ່ຽວຂ້ອງກັບສະພາບແວດລ້ອມສະເພາະ. ຕາມ​ນັ້ນ​ແລ້ວ, ​ໃນ​ສະພາບ​ການ​ດັ່ງກ່າວ, ຈຸດ C ຈະ​ໄດ້​ຮັບ​ການ​ປະຕິບັດ ການຕັ້ງຄ່າ.

ແລະຈຸດກ່ຽວກັບ ກໍ່ສ້າງ, ປ່ອຍ, ແລ່ນ ຖືກແກ້ໄຂໂດຍຟັງຊັນທີ່ສ້າງຂຶ້ນດ້ວຍຊື່ ທໍ່ນ້ໍາ.

ທໍ່ນ້ໍາ ຊ່ວຍໃຫ້ທ່ານສາມາດແບ່ງຂະບວນການຕິດຕັ້ງອອກເປັນຫຼາຍຂັ້ນຕອນ, ເນັ້ນໃສ່ຂັ້ນຕອນຂອງການປະກອບ, ການປ່ອຍແລະການປະຕິບັດ. ນອກຈາກນີ້ໃນ Pipeline, ທ່ານສາມາດສ້າງການສໍາຮອງຂໍ້ມູນ, ແລະອັນໃດອັນຫນຶ່ງ. ນີ້ແມ່ນເຄື່ອງມືທີ່ມີທ່າແຮງທີ່ບໍ່ມີຂອບເຂດ.

ລະຫັດຄໍາຮ້ອງສະຫມັກແມ່ນຢູ່ທີ່ GitHub.
ຢ່າລືມເລີ່ມຕົ້ນໂມດູນຍ່ອຍໃນເວລາທີ່ cloning repository ນີ້.

PS: ວິທີການທັງຫມົດເຫຼົ່ານີ້ສາມາດນໍາໃຊ້ກັບອຸປະກອນແລະພາສາການຂຽນໂປຼແກຼມອື່ນໆ. ສິ່ງທີ່ ສຳ ຄັນແມ່ນວ່າເນື້ອໃນບໍ່ແຕກຕ່າງກັນ.

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