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

ນີ້ແມ່ນບົດບັນທຶກຂອງຂ້ອຍ ການສະແດງ ສຸດ DevopsConf 2019-05-28.

ສະໄລ້ ແລະວິດີໂອ

ສະບັບພາສາອັງກິດ
ສະບັບພາສາລັດເຊຍ
ແລ່ນແຫ້ງ 2019-04-24 SpbLUG
ວິດີໂອ(RU) ຈາກ DevopsConf 2019-05-28
ວິດີໂອ(RU) ຈາກ DINS DevOps EVENING 2019-06-20
ບໍລິການ

ພື້ນຖານໂຄງລ່າງເປັນປະຫວັດສາດ bash

ສົມມຸດວ່າເຈົ້າມາຫາໂຄງການໃໝ່, ແລະເຂົາເຈົ້າບອກເຈົ້າວ່າ: “ພວກເຮົາມີ ພື້ນຖານໂຄງລ່າງເປັນລະຫັດ". ໃນຄວາມເປັນຈິງ, ມັນ turns ອອກ ພື້ນຖານໂຄງລ່າງເປັນປະຫວັດສາດ bash ຫຼືຕົວຢ່າງ ເອກະສານເປັນປະຫວັດ bash. ນີ້ແມ່ນສະຖານະການທີ່ແທ້ຈິງຫຼາຍ, ສໍາລັບຕົວຢ່າງ, ກໍລະນີທີ່ຄ້າຍຄືກັນໄດ້ຖືກອະທິບາຍໂດຍ Denis Lysenko ໃນຄໍາເວົ້າ ວິທີການທົດແທນໂຄງສ້າງພື້ນຖານທັງຫມົດແລະເລີ່ມຕົ້ນນອນຢ່າງສະຫງົບ, ລາວບອກວິທີການທີ່ເຂົາເຈົ້າໄດ້ຮັບໂຄງສ້າງພື້ນຖານທີ່ສອດຄ່ອງກັນສໍາລັບໂຄງການຈາກປະຫວັດສາດ bash.

ດ້ວຍຄວາມປາຖະຫນາບາງຢ່າງ, ພວກເຮົາສາມາດເວົ້າໄດ້ ພື້ນຖານໂຄງລ່າງເປັນປະຫວັດສາດ bash ນີ້ແມ່ນຄ້າຍຄືລະຫັດ:

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

ຂ້ອຍຄວນເຮັດແນວໃດ?

ພື້ນຖານໂຄງລ່າງເປັນລະຫັດ

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

ແຫ້ງ

ໃນໂຄງການພັດທະນາລະບົບການເກັບຮັກສາ, ມີໜ້າວຽກຍ່ອຍ ກຳນົດຄ່າ SDS ເປັນໄລຍະ: ພວກເຮົາກໍາລັງປ່ອຍອອກມາໃຫມ່ - ມັນຈໍາເປັນຕ້ອງໄດ້ rolled ອອກສໍາລັບການທົດສອບເພີ່ມເຕີມ. ວຽກງານແມ່ນງ່າຍດາຍທີ່ສຸດ:

ເຂົ້າສູ່ລະບົບທີ່ນີ້ຜ່ານ ssh ແລະປະຕິບັດຄໍາສັ່ງ.
ສຳເນົາໄຟລ໌ຢູ່ທີ່ນັ້ນ.
ແກ້ໄຂການຕັ້ງຄ່າທີ່ນີ້.
ເລີ່ມການບໍລິການຢູ່ທີ່ນັ້ນ
...
ໂປຣໄຟລ໌!

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

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

SOLID ສໍາລັບ CFM

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

ຫຼັກການຄວາມຮັບຜິດຊອບດຽວ

ແຕ່ລະຫ້ອງຮຽນປະຕິບັດພຽງແຕ່ຫນຶ່ງຫນ້າວຽກ.

ບໍ່ຈໍາເປັນຕ້ອງປະສົມລະຫັດແລະເຮັດໃຫ້ monsters spaghetti ອັນສູງສົ່ງ monolithic. ໂຄງສ້າງພື້ນຖານຄວນປະກອບດ້ວຍອິດທີ່ງ່າຍດາຍ. ມັນ turns ໃຫ້ ເຫັນ ວ່າ ຖ້າ ຫາກ ວ່າ ທ່ານ ແບ່ງ ປັນ playbook Ansible ເປັນ ຕ່ອນ ຂະ ຫນາດ ນ້ອຍ, ອ່ານ ບົດ ບາດ Ansible, ຫຼັງ ຈາກ ນັ້ນ ພວກ ເຂົາ ເຈົ້າ ແມ່ນ ງ່າຍ ທີ່ ຈະ ຮັກ ສາ.

ຫຼັກການເປີດປິດ

ຫຼັກການເປີດ / ປິດ.

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

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

ຫຼັກການປ່ຽນແທນ Liskov

ຫຼັກການປ່ຽນແທນຂອງ Barbara Liskov. ວັດຖຸໃນໂປຣແກມຕ້ອງຖືກແທນທີ່ດ້ວຍ instances ຂອງ subtypes ຂອງມັນໂດຍບໍ່ຕ້ອງປ່ຽນການປະຕິບັດທີ່ຖືກຕ້ອງຂອງໂຄງການ.

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

ໃນກໍລະນີຂອງພວກເຮົາ, ມີຂໍ້ຕົກລົງພາຍໃນທີມງານໂຄງສ້າງພື້ນຖານວ່າຖ້າພວກເຮົາໄດ້ຕິດຕັ້ງບົດບາດ imbjava ຫຼື oraclejava, ພວກເຮົາມີ java binary executable. ນີ້ແມ່ນມີຄວາມຈໍາເປັນເພາະວ່າ ບົດບາດຂອງ Upstream ແມ່ນຂຶ້ນກັບພຶດຕິກໍານີ້; ໃນເວລາດຽວກັນ, ນີ້ຊ່ວຍໃຫ້ພວກເຮົາສາມາດທົດແທນການປະຕິບັດ / ຮຸ່ນ java ຫນຶ່ງກັບອີກຮຸ່ນຫນຶ່ງໂດຍບໍ່ມີການປ່ຽນເຫດຜົນຂອງການປະຕິບັດຄໍາຮ້ອງສະຫມັກ.

ບັນຫາຢູ່ທີ່ນີ້ແມ່ນຢູ່ໃນຄວາມຈິງທີ່ວ່າມັນເປັນໄປບໍ່ໄດ້ທີ່ຈະປະຕິບັດໃນ Ansible, ເປັນຜົນມາຈາກຂໍ້ຕົກລົງບາງຢ່າງທີ່ປາກົດຢູ່ໃນທີມງານ.

ຫຼັກການແບ່ງສ່ວນການໂຕ້ຕອບ

ຫຼັກການແຍກຕົວໂຕ້ຕອບ: “ສ່ວນບຸກຄົນຈໍານວນຫຼາຍການໂຕ້ຕອບສະເພາະແມ່ນດີກ່ວາຫນຶ່ງໃນການໂຕ້ຕອບຈຸດປະສົງທົ່ວໄປ.

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

ຫຼັກການປີ້ນກັບກັນທີ່ເພິ່ງພາອາໄສ

ຫຼັກການຂອງການປີ້ນກັນຂອງການເພິ່ງພາອາໄສ. ໂມດູນໃນລະດັບສູງກວ່າບໍ່ຄວນຂຶ້ນກັບໂມດູນໃນລະດັບຕ່ໍາ. ທັງສອງປະເພດຂອງໂມດູນຕ້ອງຂຶ້ນກັບ abstractions. Abstractions ບໍ່ຄວນຂຶ້ນກັບລາຍລະອຽດ. ລາຍລະອຽດຕ້ອງຂຶ້ນກັບບົດຄັດຫຍໍ້.

ໃນທີ່ນີ້ຕົວຢ່າງຈະອີງໃສ່ antipattern.

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

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

ການພົວພັນຮ່ວມກັນ

ໂຄງສ້າງພື້ນຖານເປັນລະຫັດບໍ່ພຽງແຕ່ກ່ຽວກັບລະຫັດ, ແຕ່ຍັງກ່ຽວກັບຄວາມສໍາພັນລະຫວ່າງລະຫັດແລະປະຊາຊົນ, ກ່ຽວກັບການພົວພັນລະຫວ່າງຜູ້ພັດທະນາໂຄງສ້າງພື້ນຖານ.

ປັດໄຈລົດເມ

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

ຄູ່ Devopsing

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

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

ການທົບທວນລະຫັດ

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

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

ຈຸດເດັ່ນຢູ່ທີ່ນີ້ແມ່ນວ່ານັກທົບທວນໄດ້ຖືກເລືອກຫນຶ່ງໂດຍຫນຶ່ງ, ອີງຕາມຕາຕະລາງ, i.e. ດ້ວຍລະດັບຄວາມເປັນໄປໄດ້ທີ່ເຈົ້າຈະກ້າວເຂົ້າສູ່ໂຄງສ້າງພື້ນຖານໃໝ່.

ຮູບແບບລະຫັດ

ເມື່ອເວລາຜ່ານໄປ, ການສົນທະນາເລີ່ມປາກົດໃນລະຫວ່າງການທົບທວນ, ເພາະວ່າ ... ຜູ້ທົບທວນມີຮູບແບບຂອງຕົນເອງແລະການຫມຸນຂອງຜູ້ທົບທວນ stacked ໃຫ້ເຂົາເຈົ້າມີຮູບແບບທີ່ແຕກຕ່າງກັນ: 2 spaces ຫຼື 4, camelCase ຫຼື snake_case. ມັນເປັນໄປບໍ່ໄດ້ທີ່ຈະປະຕິບັດນີ້ທັນທີ.

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

Green Build Master

ເວລາຜ່ານໄປ, ແລະພວກເຮົາໄດ້ສະຫຼຸບວ່າຄໍາຫມັ້ນສັນຍາທີ່ບໍ່ຜ່ານການທົດສອບບາງຢ່າງບໍ່ສາມາດອະນຸຍາດໃຫ້ເຂົ້າໄປໃນແມ່ບົດໄດ້. ວ້າວ! ພວກເຮົາໄດ້ຄິດຄົ້ນ Green Build Master, ເຊິ່ງໄດ້ປະຕິບັດໃນການພັດທະນາຊອບແວເປັນເວລາດົນນານ:

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

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

ການທົດສອບ IaC

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

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

Pyramid ການທົດສອບ IaC

ການທົດສອບ IaC: ການວິເຄາະຄົງທີ່

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

Bash ແມ່ນ tricky

ໃຫ້ເຮົາມາເບິ່ງຕົວຢ່າງຫຍໍ້ໆ. ເລືອກໄຟລ໌ທັງໝົດໃນໄດເລກະທໍລີປັດຈຸບັນ ແລະສຳເນົາໄປໃສ່ບ່ອນອື່ນ. ສິ່ງທໍາອິດທີ່ຢູ່ໃນໃຈ:

for i in * ; do 
    cp $i /some/path/$i.bak
done

ຈະເປັນແນວໃດຖ້າມີຊ່ອງຫວ່າງໃນຊື່ໄຟລ໌? ແລ້ວ, ດີ, ພວກເຮົາສະຫລາດ, ພວກເຮົາຮູ້ວິທີການໃຊ້ຄໍາເວົ້າ:

for i in * ; do cp "$i" "/some/path/$i.bak" ; done

ເຮັດໄດ້ດີບໍ? ບໍ່! ຈະເປັນແນວໃດຖ້າບໍ່ມີຫຍັງຢູ່ໃນໄດເລກະທໍລີ, i.e. globbing ຈະບໍ່ເຮັດວຽກ.

find . -type f -exec mv -v {} dst/{}.bak ;

ເຮັດໄດ້ດີແລ້ວບໍ? ບໍ່... ລືມສິ່ງທີ່ສາມາດຢູ່ໃນຊື່ໄຟລ໌ n.

touch x
mv x  "$(printf "foonbar")"
find . -type f -print0 | xargs -0 mv -t /path/to/target-dir

ເຄື່ອງມືການວິເຄາະຄົງທີ່

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

ພາສາ
ເຄື່ອງມື

bash
Shellcheck

Ruby
RuboCop

python
ປິລິນ

ຕອບຮັບໄດ້
Ansible Lint

ການທົດສອບ IaC: ການທົດສອບຫນ່ວຍ

ດັ່ງທີ່ພວກເຮົາໄດ້ເຫັນຈາກຕົວຢ່າງທີ່ຜ່ານມາ, linters ບໍ່ແມ່ນ omnipotent ແລະບໍ່ສາມາດຊີ້ໃຫ້ເຫັນທຸກຂົງເຂດບັນຫາ. ນອກຈາກນັ້ນ, ໂດຍການປຽບທຽບກັບການທົດສອບໃນການພັດທະນາຊອບແວ, ພວກເຮົາສາມາດເອີ້ນຄືນການທົດສອບຫນ່ວຍງານ. ທີ່ນີ້ທັນທີທັນໃດມາໃນໃຈ ຊຸນນິດ, junit, rspec, pytest. ແຕ່ສິ່ງທີ່ຕ້ອງເຮັດກັບ ansible, chef, saltstack ແລະອື່ນໆເຊັ່ນພວກເຂົາ?

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

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

ການທົດສອບ IaC: ເຄື່ອງມືການທົດສອບຫນ່ວຍ

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

CFM
ເຄື່ອງມື

ຄວາມເຂົ້າໃຈ
ທົດສອບອິນຟາ

ຫົວ
ການກວດກາ

ຫົວ
ເຊີບເວີ

ເກືອ
ນິນທາ

ຕົວຢ່າງສໍາລັບ testinfra, ກວດເບິ່ງຜູ້ໃຊ້ນັ້ນ test1, test2 ມີຢູ່ແລະຢູ່ໃນກຸ່ມ sshusers:

def test_default_users(host):
    users = ['test1', 'test2' ]
    for login in users:
        assert host.user(login).exists
        assert 'sshusers' in host.user(login).groups

ສິ່ງທີ່ຈະເລືອກເອົາ? ຄໍາຖາມແມ່ນສັບສົນແລະບໍ່ຊັດເຈນ, ນີ້ແມ່ນຕົວຢ່າງຂອງການປ່ຽນແປງໂຄງການໃນ github ສໍາລັບ 2018-2019:

ກອບການທົດສອບ IaC

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

CFM
ເຄື່ອງມື

ຄວາມເຂົ້າໃຈ
ໂມເລກຸນ

ຫົວ
ເຮືອນຄົວທົດສອບ

Terraform
ທີ່ສຸດ

ຕົວຢ່າງການປ່ຽນແປງໃນໂຄງການໃນ github ສໍາລັບ 2018-2019:

ໂມເລກຸນ vs. ເຮືອນຄົວທົດສອບ

ໃນເບື້ອງຕົ້ນພວກເຮົາ ພະຍາຍາມໃຊ້ຫ້ອງທົດລອງ:

ສ້າງ VM ໃນຂະຫນານ.
ນຳໃຊ້ບົດບາດ Ansible.
ດໍາເນີນການກວດກາ.

ສໍາລັບ 25-35 ພາລະບົດບາດມັນເຮັດວຽກ 40-70 ນາທີ, ເຊິ່ງຍາວ.

ຂັ້ນຕອນຕໍ່ໄປແມ່ນການຫັນໄປສູ່ jenkins/docker/ansible/molecule. Idiologically ທຸກສິ່ງທຸກຢ່າງແມ່ນຄືກັນ

Lint ປຶ້ມຫຼິ້ນ.
ກໍານົດພາລະບົດບາດ.
ເປີດຕົວບັນຈຸ
ນຳໃຊ້ບົດບາດ Ansible.
ແລ່ນ testinfra.
ກວດເບິ່ງຄວາມບໍ່ເຂັ້ມແຂງ.

Linting ສໍາລັບ 40 ພາລະບົດບາດແລະການທົດສອບສໍາລັບອາຍແກັໄດ້ເລີ່ມຕົ້ນໃຊ້ເວລາປະມານ 15 ນາທີ.

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

ການທົດສອບ IaC: ການທົດສອບການປະສົມປະສານ

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

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

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

ການທົດສອບ IaC: End to End Test

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

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

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

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

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

ສະຫຼຸບ

ໂຄງສ້າງພື້ນຖານເປັນລະຫັດ

ລະຫັດໃນ repository.
ການໂຕ້ຕອບຂອງມະນຸດ.
ການທົດສອບໂຄງສ້າງພື້ນຖານ.

ການເຊື່ອມຕໍ່

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

ສິ່ງທີ່ຂ້ອຍໄດ້ຮຽນຮູ້ຈາກການທົດສອບ 200 ເສັ້ນຂອງລະຫັດໂຄງສ້າງພື້ນຖານ