ຂະບວນການພັດທະນາແລະການທົດສອບກັບ Docker ແລະ Gitlab CI

ຂ້າພະເຈົ້າແນະນໍາໃຫ້ທ່ານອ່ານບົດບັນທຶກຂອງບົດລາຍງານໂດຍ Alexander Sigachev ຈາກ Inventos "ຂະບວນການພັດທະນາແລະການທົດສອບກັບ Docker + Gitlab CI"

ຜູ້ທີ່ພຽງແຕ່ເລີ່ມຕົ້ນປະຕິບັດຂະບວນການພັດທະນາແລະການທົດສອບໂດຍອີງໃສ່ Docker + Gitlab CI ມັກຈະຖາມຄໍາຖາມພື້ນຖານ. ບ່ອນທີ່ຈະເລີ່ມຕົ້ນ? ການຈັດລະບຽບແນວໃດ? ການທົດສອບແນວໃດ?

ບົດລາຍງານນີ້ແມ່ນດີເພາະວ່າມັນສົນທະນາໃນແບບທີ່ມີໂຄງສ້າງກ່ຽວກັບຂະບວນການພັດທະນາແລະການທົດສອບໂດຍໃຊ້ Docker ແລະ Gitlab CI. ບົດລາຍງານຕົວມັນເອງແມ່ນມາຈາກ 2017. ຂ້າ​ພະ​ເຈົ້າ​ຄິດ​ວ່າ​ຈາກ​ບົດ​ລາຍ​ງານ​ນີ້​ທ່ານ​ສາ​ມາດ​ເກັບ​ກໍາ​ພື້ນ​ຖານ​, ວິ​ທີ​ການ​, ຄວາມ​ຄິດ​, ແລະ​ປະ​ສົບ​ການ​ຂອງ​ການ​ນໍາ​ໃຊ້​.

ໃຜສົນໃຈ, ກະລຸນາພາຍໃຕ້ແມວ.

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

ຫົວຂໍ້ຂອງບົດລາຍງານ: ຂະບວນການພັດທະນາໂດຍໃຊ້ Docker ແລະ Gitlab CI.

ນີ້ແມ່ນການສົນທະນາທີສອງຂອງຂ້ອຍກ່ຽວກັບ Docker. ໃນເວລາຂອງບົດລາຍງານຄັ້ງທໍາອິດ, ພວກເຮົາໄດ້ໃຊ້ Docker ພຽງແຕ່ໃນການພັດທະນາໃນເຄື່ອງຈັກນັກພັດທະນາ. ຈໍານວນພະນັກງານທີ່ໃຊ້ Docker ມີປະມານ 2-3 ຄົນ. ຄ່ອຍໆ, ປະສົບການໄດ້ຮັບແລະພວກເຮົາຍ້າຍໄປຕື່ມອີກເລັກນ້ອຍ. ເຊື່ອມຕໍ່ກັບພວກເຮົາ ບົດ​ລາຍ​ງານ​ຄັ້ງ​ທໍາ​ອິດ​.

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

ຄໍາຂວັນຂອງພວກເຮົາ: dockerize ທຸກສິ່ງທຸກຢ່າງທີ່ພວກເຮົາໄດ້ຮັບມືຂອງພວກເຮົາ.

ພວກເຮົາແກ້ໄຂບັນຫາຫຍັງແດ່?

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

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

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

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

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

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

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

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

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

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

ນັກພັດທະນາ frontend, ພັດທະນາໃນ JS, ເກືອບບໍ່ມີອິດທິພົນຕໍ່ backend. ນັກພັດທະນາ backend, ພັດທະນາ, ໃນກໍລະນີຂອງພວກເຮົາ, Ruby on Rails ແລະບໍ່ແຊກແຊງ Frondend. ການໂຕ້ຕອບແມ່ນດໍາເນີນການໂດຍໃຊ້ API.

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

ເຄື່ອງມື. ພວກເຮົາໃຊ້ຫຍັງ?

• Docker ຕົວຂອງມັນເອງ. Dockerfile ອະທິບາຍເຖິງຄວາມເພິ່ງພາອາໄສຂອງແອັບພລິເຄຊັນດຽວ.
• Docker-compose ແມ່ນຊຸດທີ່ນໍາເອົາຄໍາຮ້ອງສະຫມັກ Docker ຂອງພວກເຮົາຫຼາຍອັນ.
• ພວກເຮົາໃຊ້ GitLab ເພື່ອເກັບຮັກສາລະຫັດແຫຼ່ງ.
• ພວກເຮົາໃຊ້ GitLab-CI ສໍາລັບການເຊື່ອມໂຍງລະບົບ.

ບົດລາຍງານປະກອບດ້ວຍສອງພາກສ່ວນ.

ສ່ວນທໍາອິດຈະບອກທ່ານວິທີການດໍາເນີນການ Docker ໃນເຄື່ອງຂອງນັກພັດທະນາ.

ສ່ວນທີສອງຈະສົນທະນາກ່ຽວກັບວິທີການພົວພັນກັບ GitLab, ວິທີການທີ່ພວກເຮົາດໍາເນີນການທົດສອບແລະວິທີທີ່ພວກເຮົາເລື່ອນອອກໄປໃນ Staging.

Docker ແມ່ນເຕັກໂນໂລຢີທີ່ອະນຸຍາດໃຫ້ (ໃຊ້ວິທີການປະກາດ) ເພື່ອອະທິບາຍອົງປະກອບທີ່ຈໍາເປັນ. ນີ້ແມ່ນຕົວຢ່າງ Dockerfile. ໃນທີ່ນີ້ພວກເຮົາປະກາດວ່າພວກເຮົາໄດ້ຮັບມໍລະດົກຈາກຮູບພາບ Docker ຢ່າງເປັນທາງການຂອງ Ruby: 2.3.0. ມັນປະກອບດ້ວຍ Ruby ຮຸ່ນ 2.3 ຕິດຕັ້ງ. ພວກເຮົາຕິດຕັ້ງຫ້ອງສະຫມຸດປະກອບທີ່ຈໍາເປັນແລະ NodeJS. ພວກເຮົາອະທິບາຍວ່າພວກເຮົາກໍາລັງສ້າງໄດເລກະທໍລີ /app. ພວກເຮົາກໍານົດໄດເລກະທໍລີ app ເປັນໄດເລກະທໍລີທີ່ເຮັດວຽກ. ໃນໄດເລກະທໍລີນີ້ພວກເຮົາວາງ Gemfile ແລະ Gemfile.lock ຕໍາ່ສຸດທີ່ຕ້ອງການ. ຫຼັງຈາກນັ້ນ, ພວກເຮົາກໍ່ສ້າງໂຄງການທີ່ຕິດຕັ້ງຮູບພາບການເພິ່ງພາອາໄສນີ້. ພວກເຮົາຊີ້ບອກວ່າຕູ້ຄອນເທນເນີຈະພ້ອມທີ່ຈະຟັງຢູ່ໃນພອດພາຍນອກ 3000. ຄໍາສັ່ງສຸດທ້າຍແມ່ນຄໍາສັ່ງທີ່ເປີດຕົວຄໍາຮ້ອງສະຫມັກຂອງພວກເຮົາໂດຍກົງ. ຖ້າພວກເຮົາປະຕິບັດຄໍາສັ່ງດໍາເນີນການໂຄງການ, ແອັບພລິເຄຊັນຈະພະຍາຍາມແລ່ນແລະດໍາເນີນການຄໍາສັ່ງທີ່ກໍານົດໄວ້.

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

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

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

ກ່ອນຫນ້ານີ້, ນັກພັດທະນາສາມາດເຂົ້າຫາທີ່ຢູ່ IP ທີ່ມີຢູ່, ຕົວຢ່າງ, 127.0.0.1 ທີ່ຢູ່ IP ທ້ອງຖິ່ນຫຼືພາຍນອກຂອງເຄື່ອງ.

ແຖວສຸດທ້າຍບອກວ່າ web container ແມ່ນຂຶ້ນກັບ db container. ເມື່ອພວກເຮົາໂທຫາ web container ເພື່ອເປີດຕົວ, docker-compose ທໍາອິດຈະເປີດຕົວຖານຂໍ້ມູນສໍາລັບພວກເຮົາ. ແລ້ວໃນຕອນເລີ່ມຕົ້ນຂອງຖານຂໍ້ມູນ (ໃນຄວາມເປັນຈິງ, ຫຼັງຈາກການເປີດຕົວຂອງ container! ນີ້ບໍ່ໄດ້ຮັບປະກັນຄວາມພ້ອມຂອງຖານຂໍ້ມູນ) ມັນຈະເປີດຕົວຄໍາຮ້ອງສະຫມັກຂອງພວກເຮົາ, backend ຂອງພວກເຮົາ.

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

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

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

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

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

ໃນ Frontend ພວກເຮົາໃຊ້ JavaScipt ແລະ NodeJS.

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

ຕໍ່ໄປ, ວຽກງານຂອງການຕິດຕັ້ງ JavaScipt ໄດ້ຖືກເປີດຕົວແລະລະຫັດທີ່ປະກອບແບບຄົງທີ່ຈະຖືກສົ່ງຜ່ານ nginx, ປະຫຍັດຊັບພະຍາກອນ.

ໃນທີ່ນີ້ຂ້າພະເຈົ້າໄດ້ສະຫນອງແຜນວາດຂອງໂຄງການຫລ້າສຸດຂອງພວກເຮົາ.

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

ພວກເຮົາໄດ້ເຮັດຫຍັງສໍາລັບການນີ້?

ພວກເຮົາໄດ້ແບ່ງແອັບພລິເຄຊັນອອກເປັນອົງປະກອບດັ່ງຕໍ່ໄປນີ້: ພາກສ່ວນ admin ໃນ JS, backend ທີ່ເຮັດວຽກໂດຍຜ່ານການໂຕ້ຕອບ REST ພາຍໃຕ້ Ruby on Rails. Backend ພົວພັນກັບຖານຂໍ້ມູນ. ຜົນໄດ້ຮັບທີ່ຖືກສ້າງຂຶ້ນແມ່ນໃຫ້ລູກຄ້າ. ກະດານ admin ໂຕ້ຕອບກັບ backend ແລະຖານຂໍ້ມູນໂດຍຜ່ານການໂຕ້ຕອບ REST.

ພວກເຮົາຍັງມີຄວາມຕ້ອງການທີ່ຈະສົ່ງການແຈ້ງເຕືອນ Push. ກ່ອນນີ້, ພວກເຮົາມີໂຄງການທີ່ກົນໄກການຈັດຕັ້ງປະຕິບັດທີ່ມີຄວາມຮັບຜິດຊອບໃນການສົ່ງການແຈ້ງເຕືອນໄປຍັງແພລະຕະຟອມມືຖື.

ພວກເຮົາໄດ້ພັດທະນາໂຄງການຕໍ່ໄປນີ້: ຜູ້ປະກອບການຈາກຕົວທ່ອງເວັບພົວພັນກັບກະດານ admin, ກະດານ admin ພົວພັນກັບ backend, ວຽກງານແມ່ນເພື່ອສົ່ງການແຈ້ງເຕືອນ Push.

ການແຈ້ງເຕືອນການຊຸກຍູ້ພົວພັນກັບອົງປະກອບອື່ນທີ່ປະຕິບັດຢູ່ໃນ NodeJS.

ຄິວຖືກສ້າງຂຶ້ນແລະການແຈ້ງເຕືອນຖືກສົ່ງຕາມກົນໄກຂອງຕົນເອງ.

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

ສິ່ງດຽວກັນແຕ່ໃນຕົວເລກ. ການໃຊ້ລະຫັດຄືນໃຫມ່ແມ່ນມີຄວາມສໍາຄັນຢູ່ທີ່ນີ້.

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

ໃນ​ເວ​ລາ​ນັ້ນ​ພວກ​ເຮົາ​ໄດ້​ນໍາ​ໃຊ້​ສະ​ບັບ 4 ຂອງ NodeJS. ໃນປັດຈຸບັນ (ໃນປີ 2017 - ບັນທຶກຂອງບັນນາທິການ) ໃນການພັດທະນາຫລ້າສຸດຂອງພວກເຮົາພວກເຮົາໃຊ້ສະບັບ 7 ຂອງ NodeJS. ບໍ່ມີບັນຫາໃນອົງປະກອບໃຫມ່ທີ່ຈະກ່ຽວຂ້ອງກັບຫ້ອງສະຫມຸດຮຸ່ນໃຫມ່.

ຖ້າຈໍາເປັນ, ທ່ານສາມາດ refactor ແລະຍົກສູງ NodeJS ສະບັບຂອງການບໍລິການແຈ້ງການ Push.

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

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

ເມື່ອສ້າງໂຄງການໃຫມ່, ພວກເຮົາສ້າງ Dockerfile ແລະອະທິບາຍລະບົບນິເວດທີ່ຕ້ອງການ (Python, Ruby, NodeJS). ໃນ docker-compose, ມັນອະທິບາຍເຖິງຄວາມເພິ່ງພາອາໄສທີ່ຈໍາເປັນ - ຖານຂໍ້ມູນ. ພວກ​ເຮົາ​ອະ​ທິ​ບາຍ​ວ່າ​ພວກ​ເຮົາ​ຕ້ອງ​ການ​ຖານ​ຂໍ້​ມູນ​ຂອງ​ສະ​ບັບ​ດັ່ງ​ກ່າວ​ແລະ​ດັ່ງ​ກ່າວ​, ເພື່ອ​ເກັບ​ຮັກ​ສາ​ຂໍ້​ມູນ​ທີ່​ນັ້ນ​ແລະ​ມີ​.

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

ເພື່ອເກັບຮັກສາການຕັ້ງຄ່າ nginx ແລະ mysql, ພວກເຮົາໄດ້ເພີ່ມໂຟນເດີ Docker ທີ່ພວກເຮົາເກັບຮັກສາການຕັ້ງຄ່າທີ່ຈໍາເປັນ. ເມື່ອນັກພັດທະນາສ້າງ git clone ຂອງ repository ໃນເຄື່ອງຂອງລາວ, ລາວມີໂຄງການທີ່ກຽມພ້ອມສໍາລັບການພັດທະນາທ້ອງຖິ່ນ. ບໍ່ມີຄໍາຖາມກ່ຽວກັບພອດໃດຫຼືການຕັ້ງຄ່າໃດທີ່ຈະນໍາໃຊ້.

ຕໍ່ໄປ, ພວກເຮົາມີຫຼາຍອົງປະກອບ: admin, info-API, push notifications.

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

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

ໃນທີ່ນີ້ພວກເຮົາໄດ້ນໍາໃຊ້ສອງໄຟລ໌ docker-compose. ນີ້ແມ່ນເຮັດເພື່ອໃຫ້ສາມາດເປີດຕົວໃນຂັ້ນຕອນຕ່າງໆ. ເມື່ອຜູ້ພັດທະນາເຮັດວຽກກັບ kernel, ລາວບໍ່ຕ້ອງການການແຈ້ງເຕືອນ Push, ລາວພຽງແຕ່ເປີດໄຟລ໌ docker-compose ແລະ, ຕາມນັ້ນ, ຊັບພະຍາກອນຈະຖືກບັນທຶກໄວ້.

ຖ້າມີຄວາມຈໍາເປັນສໍາລັບການເຊື່ອມໂຍງກັບການແຈ້ງເຕືອນ Push, ຫຼັງຈາກນັ້ນ docker-compose.yaml ແລະ docker-compose-push.yaml ຖືກເປີດຕົວ.

ເນື່ອງຈາກ docker-compose.yaml ແລະ docker-compose-push.yaml ຢູ່ໃນໂຟນເດີ, ເຄືອຂ່າຍ virtual ດຽວຈະຖືກສ້າງໂດຍອັດຕະໂນມັດ.

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

ນີ້ແມ່ນຮູບພາບ Docker ທີ່ກຽມພ້ອມທີ່ແລ່ນ nginx ແລະແອັບພລິເຄຊັນທີ່ຟັງຊ່ອງສຽບ Docker. ໄດນາມິກ, ເນື່ອງຈາກຕູ້ຄອນເທນເນີເປີດ ແລະປິດ, ການຕັ້ງຄ່າ nginx ຈະຖືກສ້າງໃໝ່. ພວກເຮົາແຈກຢາຍການຈັດການອົງປະກອບໂດຍໃຊ້ຊື່ໂດເມນລະດັບສາມ.

ສໍາລັບສະພາບແວດລ້ອມການພັດທະນາພວກເຮົາໃຊ້ໂດເມນ .dev - api.informer.dev . ແອັບພລິເຄຊັນທີ່ມີໂດເມນ .dev ມີຢູ່ໃນເຄື່ອງທ້ອງຖິ່ນຂອງຜູ້ພັດທະນາ.

ຫຼັງຈາກນັ້ນ, configs ໄດ້ຖືກໂອນໄປຫາແຕ່ລະໂຄງການແລະໂຄງການທັງຫມົດໄດ້ຖືກເປີດຕົວໃນເວລາດຽວກັນ.

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

ຕົວດຸ່ນດ່ຽງກໍານົດວ່າບັນຈຸໃດຕ້ອງໄດ້ຮັບການເຂົ້າເຖິງໂດຍອີງໃສ່ຊື່ໂດເມນ.

ນີ້ອາດຈະເປັນ nginx, ເຊິ່ງສະຫນອງ JS ໃຫ້ກັບກະດານ admin. ນີ້ສາມາດເຮັດໄດ້ໂດຍ nginx, ເຊິ່ງສະຫນອງ API, ຫຼືໄຟລ໌ static, ເຊິ່ງສະຫນອງໃຫ້ໂດຍ nginx ໃນຮູບແບບການໂຫຼດຮູບພາບ.

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

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

ຂ້ອຍຄວນເບິ່ງຕົວຢ່າງໃດເພື່ອ dockerize ຄໍາຮ້ອງສະຫມັກຂອງຂ້ອຍ? ໃນຄວາມຄິດເຫັນຂອງຂ້ອຍ, ຕົວຢ່າງທີ່ດີແມ່ນຮູບພາບ docker ຢ່າງເປັນທາງການສໍາລັບ MySQL.

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

Hub.docker.com ປົກກະຕິແລ້ວມີລິ້ງໄປຫາ github.com, ບ່ອນທີ່ຂໍ້ມູນດິບໄດ້ຖືກສະຫນອງໃຫ້ໂດຍກົງຈາກທີ່ທ່ານສາມາດສ້າງຮູບພາບຕົວທ່ານເອງ.

ນອກຈາກນັ້ນໃນ repository ນີ້ມີ script docker-endpoint.sh, ເຊິ່ງຮັບຜິດຊອບສໍາລັບການເລີ່ມຕົ້ນເບື້ອງຕົ້ນແລະການປຸງແຕ່ງຕື່ມອີກຂອງການເປີດຕົວແອັບພລິເຄຊັນ.

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

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

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

ນີ້ແມ່ນຕົວຢ່າງຂອງສະບັບສະເພາະຂອງ MySQL ເບິ່ງຄືວ່າຢູ່ໃນ github.com. ທ່ານສາມາດເປີດ Dockerfile ແລະເບິ່ງວ່າການຕິດຕັ້ງເກີດຂຶ້ນຢູ່ທີ່ນັ້ນໄດ້ແນວໃດ.

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

ຂໍໃຫ້ກ້າວໄປສູ່ພາກທີສອງ.

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

ຫນຶ່ງໃນອົງປະກອບ Gitlab ແມ່ນ Gitlab CI. ມັນອະນຸຍາດໃຫ້ທ່ານອະທິບາຍຊຸດຂອງຄໍາສັ່ງທີ່ຈະຖືກນໍາໃຊ້ໃນການຈັດລໍາດັບລະບົບການຈັດສົ່ງລະຫັດຫຼືດໍາເນີນການທົດສອບອັດຕະໂນມັດ.

ລາຍງານກ່ຽວກັບ Gitlab CI 2 https://goo.gl/uohKjI — ບົດ​ລາຍ​ງານ​ຈາກ​ສະ​ໂມ​ສອນ Ruby Russia ແມ່ນ​ຂ້ອນ​ຂ້າງ​ລະ​ອຽດ​ແລະ​ອາດ​ຈະ​ເປັນ​ທີ່​ສົນ​ໃຈ​ຂອງ​ທ່ານ​.

ຕອນນີ້ພວກເຮົາຈະເບິ່ງສິ່ງທີ່ຕ້ອງການເພື່ອເປີດໃຊ້ Gitlab CI. ເພື່ອເປີດຕົວ Gitlab CI, ພວກເຮົາພຽງແຕ່ຕ້ອງການໃສ່ໄຟລ໌ .gitlab-ci.yml ຢູ່ໃນຮາກຂອງໂຄງການ.

ໃນທີ່ນີ້ພວກເຮົາອະທິບາຍວ່າພວກເຮົາຕ້ອງການທີ່ຈະປະຕິບັດລໍາດັບຂອງລັດເຊັ່ນ: ການທົດສອບ, ການປະຕິບັດ.

ພວກເຮົາປະຕິບັດ scripts ໂດຍກົງໂທຫາ docker-compose build ຂອງຄໍາຮ້ອງສະຫມັກຂອງພວກເຮົາ. ນີ້ແມ່ນຕົວຢ່າງຂອງພຽງແຕ່ backend.

ຕໍ່ໄປພວກເຮົາເວົ້າວ່າມັນຈໍາເປັນຕ້ອງດໍາເນີນການເຄື່ອນຍ້າຍເພື່ອປ່ຽນຖານຂໍ້ມູນແລະດໍາເນີນການທົດສອບ.

ຖ້າສະຄຣິບຖືກປະຕິບັດຢ່າງຖືກຕ້ອງແລະບໍ່ສົ່ງຄືນລະຫັດຂໍ້ຜິດພາດ, ຫຼັງຈາກນັ້ນລະບົບຈະດໍາເນີນຂັ້ນຕອນທີສອງຂອງການຕິດຕັ້ງ.

ປະຈຸບັນນີ້, ຂັ້ນຕອນການຈັດຕັ້ງປະຕິບັດແມ່ນໄດ້ຖືກຈັດຕັ້ງປະຕິບັດ. ພວກເຮົາບໍ່ໄດ້ຈັດຕັ້ງການປິດເປີດໃໝ່.

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

ໃຫ້ດໍາເນີນການຍ້າຍຖານຂໍ້ມູນທີ່ຖືກຂຽນໂດຍນັກພັດທະນາສໍາລັບສະພາບແວດລ້ອມທີ່ມີການປ່ຽນແປງໃນປະຈຸບັນ.

ມີຂໍ້ສັງເກດວ່ານີ້ຄວນຈະຖືກນໍາໃຊ້ກັບສາຂາຕົ້ນສະບັບເທົ່ານັ້ນ.

ໃຊ້ບໍ່ໄດ້ເມື່ອປ່ຽນສາຂາອື່ນ.

ມັນເປັນໄປໄດ້ທີ່ຈະຈັດລະບຽບມ້ວນຕາມສາຂາ.

ເພື່ອຈັດຕັ້ງອັນນີ້ຕື່ມອີກ, ພວກເຮົາຈໍາເປັນຕ້ອງໄດ້ຕິດຕັ້ງ Gitlab Runner.

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

ໃນຕອນເລີ່ມຕົ້ນພວກເຮົາລົງທະບຽນ Gitlab Runner.

ພວກເຮົາໄດ້ຮັບລະຫັດໃນການໂຕ້ຕອບເວັບໄຊຕ໌ Gitlab.

ຫຼັງຈາກນັ້ນ, ພວກເຮົາໂທຫາຄໍາສັ່ງເລີ່ມຕົ້ນໃນເສັ້ນຄໍາສັ່ງ.

ກຳນົດຄ່າ Gitlab Runner ໃນໂໝດໂຕ້ຕອບ (Shell, Docker, VirtualBox, SSH)

ລະຫັດໃນ Gitlab Runner ຈະປະຕິບັດໃນທຸກໆ commit ຂຶ້ນກັບການຕັ້ງຄ່າ .gitlab-ci.yml.

ມັນເບິ່ງແນວໃດໃນ Gitlab ໃນການໂຕ້ຕອບເວັບ. ຫຼັງຈາກການເຊື່ອມຕໍ່ GITlab CI, ພວກເຮົາມີທຸງທີ່ສະແດງໃຫ້ເຫັນວ່າສິ່ງທີ່ການກໍ່ສ້າງແມ່ນຢູ່ໃນປັດຈຸບັນ.

ພວກເຮົາເຫັນວ່າ 4 ນາທີກ່ອນຫນ້ານີ້ມີຄໍາຫມັ້ນສັນຍາທີ່ຜ່ານການທົດສອບທັງຫມົດແລະບໍ່ໄດ້ເຮັດໃຫ້ເກີດບັນຫາໃດໆ.

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

ຖ້າພວກເຮົາຄລິກໃສ່ການກໍ່ສ້າງສະເພາະ, ຈະມີຜົນຜະລິດ console ຂອງຄໍາສັ່ງທີ່ຖືກເປີດຕົວໃນຂະບວນການຕາມ .gitlab-ci.yml.

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

ບັນຫາຫຍັງທີ່ພວກເຮົາໄດ້ແກ້ໄຂໃນຂັ້ນຕອນໃນເວລາທີ່ພວກເຮົາປະຕິບັດ docker? ລະບົບຂອງພວກເຮົາປະກອບດ້ວຍອົງປະກອບແລະພວກເຮົາຕ້ອງການ restart ພຽງແຕ່ບາງສ່ວນຂອງອົງປະກອບທີ່ຖືກປັບປຸງໃນ repository, ແລະບໍ່ແມ່ນລະບົບທັງຫມົດ.

ເພື່ອເຮັດສິ່ງນີ້, ພວກເຮົາຕ້ອງແຍກທຸກສິ່ງທຸກຢ່າງອອກເປັນໂຟນເດີແຍກຕ່າງຫາກ.

ຫຼັງຈາກທີ່ພວກເຮົາເຮັດສິ່ງນີ້, ພວກເຮົາມີບັນຫາກັບຄວາມຈິງທີ່ວ່າ Docker-compose ສ້າງພື້ນທີ່ເຄືອຂ່າຍຂອງຕົນເອງສໍາລັບແຕ່ລະໂຟເດີແລະບໍ່ເຫັນອົງປະກອບຂອງເພື່ອນບ້ານຂອງມັນ.

ເພື່ອໄປມາ, ພວກເຮົາສ້າງເຄືອຂ່າຍດ້ວຍຕົນເອງໃນ Docker. ໃນ Docker-compose ມັນໄດ້ຖືກຂຽນວ່າທ່ານຄວນໃຊ້ເຄືອຂ່າຍດັ່ງກ່າວສໍາລັບໂຄງການນີ້.

ດັ່ງນັ້ນ, ແຕ່ລະອົງປະກອບທີ່ເລີ່ມຕົ້ນດ້ວຍຕາຫນ່າງນີ້ເຫັນອົງປະກອບໃນພາກສ່ວນອື່ນໆຂອງລະບົບ.

ບັນຫາຕໍ່ໄປແມ່ນການແບ່ງປັນຂັ້ນຕອນລະຫວ່າງໂຄງການຈໍານວນຫນຶ່ງ.

ເນື່ອງຈາກວ່າທັງຫມົດນີ້ເບິ່ງງາມແລະໃກ້ຊິດເທົ່າທີ່ເປັນໄປໄດ້ໃນການຜະລິດ, ມັນເປັນການດີທີ່ຈະໃຊ້ພອດ 80 ຫຼື 443, ເຊິ່ງຖືກນໍາໃຊ້ຢູ່ທົ່ວທຸກແຫ່ງໃນເວັບ.

ພວກເຮົາໄດ້ແກ້ໄຂນີ້ແນວໃດ? ພວກເຮົາໄດ້ມອບຫມາຍນັກແລ່ນ Gitlab ຫນຶ່ງໃຫ້ກັບໂຄງການຂະຫນາດໃຫຍ່ທັງຫມົດ.

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

ເພື່ອຫຼີກເວັ້ນບັນຫາໃນເຮືອນ, ພວກເຮົາຈໍາກັດກຸ່ມໂຄງການຂອງພວກເຮົາໃຫ້ຫນຶ່ງ Gitlab Runner, ເຊິ່ງຮັບມືກັບປະລິມານຂອງພວກເຮົາໂດຍບໍ່ມີບັນຫາ.

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

ໂຄງ​ການ​ຂອງ​ພວກ​ເຮົາ​ມີ​ຕາ​ຂ່າຍ​ໄຟ​ຟ້າ​ຫນຶ່ງ​, ແລະ balancer ມີ​ຕາ​ຂ່າຍ​ໄຟ​ຟ້າ​ຈໍາ​ນວນ​ຫນຶ່ງ​ອີງ​ຕາມ​ຊື່​ໂຄງ​ການ​. ມັນສາມາດເປັນຕົວແທນຕື່ມອີກໂດຍຊື່ໂດເມນ.

ການຮ້ອງຂໍຂອງພວກເຮົາມາຜ່ານໂດເມນໃນພອດ 80 ແລະຖືກແກ້ໄຂໃຫ້ກັບກຸ່ມບັນຈຸທີ່ໃຫ້ບໍລິການໂດເມນນີ້.

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

ຢ່າງໃດກໍຕາມ, ຖ້າທ່ານເຂົ້າໄປໃນບັນຈຸ, ມັນຈະເປັນຮາກແລະໄຟລ໌ທີ່ພວກເຮົາສ້າງຢູ່ໃນບັນຈຸນີ້ໄດ້ຮັບສິດທິຮາກ.

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

ນີ້ຈະແກ້ໄຂໄດ້ແນວໃດ? ທ່ານສາມາດເພີ່ມຜູ້ໃຊ້ທີ່ຈະຢູ່ໃນບັນຈຸ.

ບັນຫາຫຍັງເກີດຂຶ້ນເມື່ອພວກເຮົາເພີ່ມຜູ້ໃຊ້?

ເມື່ອສ້າງຜູ້ໃຊ້, ID ກຸ່ມ (UID) ແລະ ID ຜູ້ໃຊ້ (GID) ມັກຈະບໍ່ກົງກັນ.

ເພື່ອແກ້ໄຂບັນຫານີ້ຢູ່ໃນ container ພວກເຮົາໃຊ້ຜູ້ໃຊ້ທີ່ມີ ID 1000.

ໃນກໍລະນີຂອງພວກເຮົາ, ນີ້ກົງກັນກັບຄວາມຈິງທີ່ວ່ານັກພັດທະນາເກືອບທັງຫມົດໃຊ້ Ubuntu OS. ແລະໃນ Ubuntu OS ຜູ້ໃຊ້ທໍາອິດມີ ID 1000.

ພວກເຮົາມີແຜນການບໍ?

ອ່ານເອກະສານ Docker ຄືນໃໝ່. ໂຄງການດັ່ງກ່າວກໍາລັງພັດທະນາຢ່າງຫ້າວຫັນ, ເອກະສານກໍາລັງປ່ຽນແປງ. ຂໍ້​ມູນ​ທີ່​ໄດ້​ມາ​ໃນ​ສອງ​ຫາ​ສາມ​ເດືອນ​ກ່ອນ​ນີ້​ແມ່ນ​ຊ້າ​ກາຍ​ເປັນ​ຊ້າ​.

ບາງບັນຫາທີ່ພວກເຮົາແກ້ໄຂແລ້ວອາດຈະໄດ້ຮັບການແກ້ໄຂດ້ວຍວິທີມາດຕະຖານແລ້ວ.

ຂ້າພະເຈົ້າກໍ່ຕ້ອງການທີ່ຈະກ້າວຕໍ່ໄປແລະຍ້າຍໂດຍກົງກັບ orchestration.

ຕົວຢ່າງຫນຶ່ງແມ່ນກົນໄກທີ່ສ້າງຂຶ້ນໃນ Docker ທີ່ເອີ້ນວ່າ Docker Swarm, ເຊິ່ງອອກມາຈາກກ່ອງ. ຂ້າພະເຈົ້າຢາກຈະເປີດຕົວບາງສິ່ງບາງຢ່າງໃນການຜະລິດໂດຍອີງໃສ່ເທກໂນໂລຍີ Docker Swarm.

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

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