ວິວັດທະນາການຂອງເຄື່ອງມືການຈັດສົ່ງ, ຫຼືຄວາມຄິດກ່ຽວກັບ Docker, deb, jar ແລະອື່ນໆ

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

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

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

ສະນັ້ນ, ໃນຍຸກສະ ໄໝ ກ່ອນ ... ວິທີການຈັດສົ່ງຄັ້ງ ທຳ ອິດທີ່ຂ້ອຍພົບແມ່ນ tapes ຈາກເຄື່ອງບັນທຶກ tape. ຂ້ອຍມີຄອມພິວເຕີ BK-0010.01...

ຍຸກ​ຂອງ​ການ​ຄິດ​ໄລ່​

ບໍ່, ມີຊ່ວງເວລາກ່ອນໜ້ານີ້, ຍັງມີເຄື່ອງຄິດເລກ MK-61 и MK-52.

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

ການແກ້ໄຂຕໍ່ໄປແມ່ນເຄື່ອງຄິດເລກ MK-52, ມັນມີຄວາມຄ້າຍຄືກັນຂອງການເກັບຮັກສາຂໍ້ມູນທີ່ບໍ່ມີການເຫນັງຕີງບາງຢ່າງ. ໃນປັດຈຸບັນເກມຫຼືໂຄງການບໍ່ຈໍາເປັນຕ້ອງຖືກໃສ່ດ້ວຍຕົນເອງ, ແຕ່ຫຼັງຈາກປະຕິບັດບາງ magical passes ກັບປຸ່ມ, ມັນ loaded ຕົວຂອງມັນເອງ.

ຂະຫນາດຂອງໂປລແກລມທີ່ໃຫຍ່ທີ່ສຸດໃນເຄື່ອງຄິດເລກແມ່ນ 105 ຂັ້ນຕອນ, ແລະຂະຫນາດຂອງຫນ່ວຍຄວາມຈໍາຖາວອນໃນ MK-52 ແມ່ນ 512 ຂັ້ນຕອນ.

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

• Emulator MK-61 ສໍາລັບ Android
• ລາຍການລາຍການສໍາລັບ MK-61

A digression ສັ້ນກ່ຽວກັບ MK-52 (ຈາກ Wikipedia)

MK-52 ໄດ້ບິນຂຶ້ນສູ່ອາວະກາດເທິງຍານອະວະກາດ Soyuz TM-7. ມັນຄວນຈະຖືກນໍາໃຊ້ເພື່ອຄິດໄລ່ trajectory ລົງຈອດໃນກໍລະນີທີ່ຄອມພິວເຕີເທິງເຮືອລົ້ມເຫລວ.

ນັບຕັ້ງແ​​ຕ່ປີ 52, MK-1988 ກັບຫນ່ວຍຂະຫຍາຍຫນ່ວຍຄວາມຈໍາ Elektronika-Astro ໄດ້ຖືກສະຫນອງໃຫ້ແກ່ເຮືອກອງທັບເຮືອເປັນສ່ວນຫນຶ່ງຂອງຊຸດຄອມພິວເຕີ້ນໍາທາງ.

ຄອມພິວເຕີສ່ວນບຸກຄົນທໍາອິດ

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

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

ການປະກົດຕົວຂອງສື່ການເກັບຮັກສາທີ່ເຊື່ອຖືໄດ້ແລະຂະຫນາດໃຫຍ່

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

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

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

ໃນເວລານັ້ນ, ການມີຢູ່ຂອງ Linux ຍັງບໍ່ທັນເປີດໃຫ້ຂ້ອຍ; ຂ້ອຍອາໄສຢູ່ໃນໂລກຂອງ MS DOS ແລະຕໍ່ມາ, Windows, ແລະຂຽນໃນ Borland Pascal ແລະ Delphi, ບາງຄັ້ງກໍ່ຊອກຫາ C ++. ຫລາຍຄົນໄດ້ໃຊ້ InstallShield ເພື່ອຈັດສົ່ງຜະລິດຕະພັນໃນເວລານັ້ນ. ru.wikipedia.org/wiki/InstallShield, ເຊິ່ງຂ້ອນຂ້າງສໍາເລັດການແກ້ໄຂວຽກງານທີ່ໄດ້ຮັບມອບຫມາຍທັງຫມົດຂອງການຕິດຕັ້ງແລະການຕັ້ງຄ່າຊອບແວ.

ຍຸກອິນເຕີເນັດ

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

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

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

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

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

ຊຸດ RPM ແລະ DEB

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

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

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

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

ມັນເປັນມູນຄ່າທີ່ສັງເກດວ່າໃນປັດຈຸບັນມີບາງການເຄື່ອນໄຫວໄປສູ່ການຍ້າຍອອກໄປຈາກ deb ແລະປ່ຽນໄປຫາແພັກເກັດ snap, ແຕ່ມີຫຼາຍກວ່ານັ້ນຕໍ່ມາ.

ດັ່ງນັ້ນ, ນັກພັດທະນາ cloud ຮຸ່ນໃຫມ່ນີ້, ຜູ້ທີ່ບໍ່ຮູ້ຈັກທັງ DEB ຫຼື RPM, ຍັງເຕີບໂຕຢ່າງຊ້າໆ, ໄດ້ຮັບປະສົບການ, ຜະລິດຕະພັນໄດ້ກາຍເປັນຄວາມສັບສົນຫຼາຍ, ແລະບາງວິທີການຈັດສົ່ງທີ່ສົມເຫດສົມຜົນແມ່ນຈໍາເປັນກວ່າ FTP, bash scripts ແລະເຄື່ອງຫັດຖະກໍານັກຮຽນທີ່ຄ້າຍຄືກັນ.
ແລະນີ້ແມ່ນບ່ອນທີ່ Docker ເຂົ້າມາໃນຮູບ, ປະເພດຂອງການປະສົມ virtualization, ການກໍານົດຊັບພະຍາກອນແລະວິທີການຈັດສົ່ງ. ມັນເປັນຄົນອັບເດດ: ແລະໄວຫນຸ່ມໃນປັດຈຸບັນ, ແຕ່ມັນຈໍາເປັນສໍາລັບທຸກສິ່ງທຸກຢ່າງບໍ? ນີ້ແມ່ນຢາຄຸມກຳເນີດບໍ?

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

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

ສະຄຣິບທີ່ຂຽນດ້ວຍຕົນເອງ

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

ແຕ່ scripts ມີຂໍ້ເສຍຫຼາຍ:

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

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

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

Docker

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

ພວກເຮົາພົບກັບຄວາມບໍ່ສະດວກອັນໃດ?

• ບັນຫາເຄືອຂ່າຍຢູ່ໃນໂໝດຂົວ
• ມັນບໍ່ສະດວກທີ່ຈະເບິ່ງບັນທຶກໃນຕູ້ຄອນເທນເນີ (ຖ້າພວກມັນບໍ່ໄດ້ຖືກເກັບໄວ້ແຍກຕ່າງຫາກໃນລະບົບໄຟລ໌ຂອງເຄື່ອງໂຮດ)
• ElasticSearch ເປັນບາງໂອກາດ freezes strangely ພາຍໃນບັນຈຸ, ເຫດຜົນຍັງບໍ່ໄດ້ຖືກກໍານົດ, ບັນຈຸແມ່ນຢ່າງເປັນທາງການ
• ມັນເປັນສິ່ງຈໍາເປັນທີ່ຈະໃຊ້ແກະພາຍໃນຖັງ - ທຸກສິ່ງທຸກຢ່າງຖືກຖອດອອກຫຼາຍ, ບໍ່ມີເຄື່ອງມືທີ່ຄຸ້ນເຄີຍ
• ຂະ​ຫນາດ​ໃຫຍ່​ຂອງ​ຖັງ​ເກັບ​ກໍາ - ລາ​ຄາ​ແພງ​ໃນ​ການ​ເກັບ​ຮັກ​ສາ​
• ເນື່ອງຈາກຂະຫນາດໃຫຍ່ຂອງບັນຈຸ, ມັນເປັນການຍາກທີ່ຈະສະຫນັບສະຫນູນຫຼາຍສະບັບ
• ເວລາສ້າງດົນຂຶ້ນ, ບໍ່ຄືກັບວິທີອື່ນ (ສະຄຣິບ ຫຼືຊຸດ deb)

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

ດັ່ງທີ່ການປະຕິບັດໄດ້ສະແດງໃຫ້ເຫັນ, ໃນຄວາມເປັນຈິງ, ນີ້ບໍ່ແມ່ນຄວາມຈໍາເປັນ, ຊຸດ deb ແມ່ນພຽງພໍໃນ 90% ຂອງກໍລະນີ.

ເມື່ອ deb ເກົ່າທີ່ດີລົ້ມເຫລວແລະພວກເຮົາຕ້ອງການ docker ແທ້ໆເມື່ອໃດ?

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

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

Snap ຊຸດ

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

ດັ່ງນັ້ນ, ໃນປັດຈຸບັນພວກເຮົາໃຊ້ທັງສອງແພັກເກັດ deb ແລະ docker containers ໃນການປະສົມປະສານທີ່ສົມເຫດສົມຜົນ, ເຊິ່ງ, ບາງທີ, ໃນບາງກໍລະນີພວກເຮົາຈະທົດແທນດ້ວຍແພັກເກັດ snap.

ພຽງແຕ່ຜູ້ໃຊ້ລົງທະບຽນສາມາດເຂົ້າຮ່ວມໃນການສໍາຫຼວດ. ເຂົ້າ​ສູ່​ລະ​ບົບກະລຸນາ.

ເຈົ້າໃຊ້ຫຍັງໃນການຈັດສົ່ງ?

• ສະຄຣິບທີ່ຂຽນດ້ວຍຕົນເອງ

• ສຳເນົາໃສ່ FTP ດ້ວຍຕົນເອງ

• deb packages

• ຊຸດ rpm

• ແພັກເກັດ snaps

• Docker-ຮູບພາບ

• ຮູບພາບເຄື່ອງ virtual

• Clone HDD ທັງໝົດ

• puppet

• ຕອບຮັບໄດ້

• ອື່ນໆ

109 ຜູ້ໃຊ້ລົງຄະແນນສຽງ. 32 ຜູ້ໃຊ້ງົດ.

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