ວິທີການເລີ່ມຕົ້ນການທົດສອບ Ansible, refactor ໂຄງການໃນປີແລະບໍ່ໄປ Crazy

ນີ້ແມ່ນການຖອດຂໍ້ຄວາມ ການສະແດງ ສຸດ DevOps-40 2020-03-18:

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

ການເກີດຂອງມໍລະດົກ

ວັນທີ 1: ຄົນເຈັບສູນ

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

ວັນທີ 89: ການເກີດຂອງມໍລະດົກ

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

• ພວກ​ເຮົາ​ມີ​ວຽກ​ງານ​ອັນ​ຮີບ​ດ່ວນ​ຢູ່​ທີ່​ນີ້​, ໃຫ້​ຂອງ​ເຮັດ​ການ hack ເປື້ອນ​ແລະ​ຫຼັງ​ຈາກ​ນັ້ນ​ແກ້​ໄຂ​ມັນ​.
• ທ່ານບໍ່ ຈຳ ເປັນຕ້ອງຂຽນເອກະສານແລະທຸກຢ່າງຈະແຈ້ງກ່ຽວກັບສິ່ງທີ່ ກຳ ລັງເກີດຂື້ນຢູ່ທີ່ນີ້.
• ຂ້ອຍຮູ້ຈັກ Ansible/Python/Bash/Terraform! ເບິ່ງວິທີທີ່ຂ້ອຍສາມາດຫລີກລ້ຽງໄດ້!
• ຂ້ອຍເປັນຜູ້ພັດທະນາ Full Stack Overflow ແລະຄັດລອກນີ້ມາຈາກ stackoverflow, ຂ້ອຍບໍ່ຮູ້ວ່າມັນເຮັດວຽກແນວໃດ, ແຕ່ມັນເບິ່ງຄືວ່າເຢັນແລະແກ້ໄຂບັນຫາ.

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

- hosts: localhost
  tasks:
    - shell: echo -n Z >> a.txt && cat a.txt
      register: output
      delay: 1
      retries: 5
      until: not output.stdout.find("ZZZ")

ມື້ #109: ຄວາມຮັບຮູ້ຂອງບັນຫາ

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

IaC refactoring

ມື້ທີ 139: ເຈົ້າຕ້ອງການ refactor ແທ້ໆບໍ?

ກ່ອນທີ່ທ່ານຈະຟ້າວໄປຫາ refactor, ທ່ານຕ້ອງຕອບຄໍາຖາມທີ່ສໍາຄັນຈໍານວນຫນຶ່ງ:

1. ເປັນຫຍັງທ່ານຕ້ອງການທັງຫມົດນີ້?
2. ເຈົ້າມີເວລາບໍ?
3. ຄວາມຮູ້ພຽງພໍບໍ?

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

ມື້ທີ 149: ການກະກຽມ refactoring

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

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

ຄວາມພະຍາຍາມທົດສອບ Ansible

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

ວັນທີ -997: ການສະຫນອງ SDS

ຄັ້ງທຳອິດທີ່ຂ້ອຍທົດສອບ Ansible ແມ່ນຢູ່ໃນໂຄງການພັດທະນາ SDS (Software Defined Storage). ມີບົດຄວາມແຍກຕ່າງຫາກກ່ຽວກັບຫົວຂໍ້ນີ້
ວິທີການທໍາລາຍລົດຖີບຜ່ານໄມ້ຄ້ອນໃນເວລາທີ່ການທົດສອບການແຈກຢາຍຂອງທ່ານ, ແຕ່ໃນສັ້ນ, ພວກເຮົາໄດ້ສິ້ນສຸດລົງດ້ວຍ pyramid ການທົດສອບ inverted ແລະການທົດສອບພວກເຮົາໃຊ້ເວລາ 60-90 ນາທີໃນຫນຶ່ງບົດບາດ, ຊຶ່ງເປັນເວລາດົນນານ. ພື້ນຖານແມ່ນການທົດສອບ e2e, i.e. ພວກ​ເຮົາ​ໄດ້​ນໍາ​ໃຊ້​ການ​ຕິດ​ຕັ້ງ​ຢ່າງ​ເຕັມ​ທີ່​ແລະ​ຫຼັງ​ຈາກ​ນັ້ນ​ການ​ທົດ​ສອບ​ມັນ​. ສິ່ງທີ່ຮ້າຍແຮງໄປກວ່ານັ້ນແມ່ນການປະດິດລົດຖີບຂອງຕົນເອງ. ແຕ່ຂ້ອຍຕ້ອງຍອມຮັບ, ການແກ້ໄຂນີ້ເຮັດວຽກແລະອະນຸຍາດໃຫ້ມີການປ່ອຍຕົວທີ່ຫມັ້ນຄົງ.

ມື້ # -701: ເຮືອນຄົວ Ansible ແລະທົດສອບ

ການ​ພັດ​ທະ​ນາ​ຂອງ​ຄວາມ​ຄິດ​ການ​ທົດ​ສອບ Ansible ແມ່ນ​ການ​ນໍາ​ໃຊ້​ເຄື່ອງ​ມື​ທີ່​ກຽມ​ພ້ອມ​, ຄື​ຫ້ອງ​ຄົວ​ທົດ​ສອບ / kitchen-ci ແລະ inspec​. ທາງເລືອກໄດ້ຖືກກໍານົດໂດຍຄວາມຮູ້ຂອງ Ruby (ສໍາລັບລາຍລະອຽດເພີ່ມເຕີມ, ເບິ່ງບົດຄວາມກ່ຽວກັບ Habré: ຜູ້ຂຽນໂປລແກລມ YML ຝັນຢາກທົດສອບ Ansible ບໍ?) ໄດ້ເຮັດວຽກໄວຂຶ້ນ, ປະມານ 40 ນາທີສໍາລັບ 10 ພາລະບົດບາດ. ພວກເຮົາສ້າງເຄື່ອງ virtual ແລະແລ່ນການທົດສອບພາຍໃນ.

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

ມື້ # -601: Ansible ແລະໂມເລກຸນ

Conceptually, ນີ້ແມ່ນຄ້າຍຄືກັນກັບ testkitchen, ພຽງແຕ່ພວກເຮົາຍ້າຍການທົດສອບບົດບາດເປັນ docker ແລະປ່ຽນ stack ໄດ້. ດັ່ງນັ້ນ, ເວລາໄດ້ຖືກຫຼຸດລົງເປັນຄວາມຫມັ້ນຄົງ 20-25 ນາທີສໍາລັບ 7 ພາລະບົດບາດ.

ໂດຍການເພີ່ມຈໍານວນຂອງບົດບາດການທົດສອບເປັນ 17 ແລະ linting 45 ພາລະບົດບາດ, ພວກເຮົາດໍາເນີນການນີ້ໃນ 28 ນາທີກ່ຽວກັບ 2 jenkins ສໍາລອງ.

ວັນທີ #167: ເພີ່ມການທົດສອບ Ansible ເຂົ້າໃນໂຄງການ

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

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

ການ refactoring ແມ່ນງ່າຍດາຍ:

• ກິນເຂົ້າ.
• ນອນ.
• ລະຫັດ.
• ການທົດສອບ IaC.
• Repeat

ແລະພວກເຮົາເຮັດເລື້ມຄືນນີ້ຈົນກ່ວາພວກເຮົາບັນລຸເປົ້າຫມາຍທີ່ຕັ້ງໄວ້.

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

ວັນທີ #181: Green Build Master

Linting ເປັນບາດກ້າວທໍາອິດຂະຫນາດນ້ອຍໄປສູ່ Green Build Master. ນີ້ຈະບໍ່ທໍາລາຍເກືອບທຸກຢ່າງ, ແຕ່ມັນຈະຊ່ວຍໃຫ້ທ່ານສາມາດແກ້ໄຂຂະບວນການຕ່າງໆແລະສ້າງການສ້າງສີຂຽວໃນ Jenkins. ແນວຄວາມຄິດແມ່ນເພື່ອພັດທະນານິໄສລະຫວ່າງທີມງານ:

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

ມື້ #193: ຈາກ linting ກັບການທົດສອບຫນ່ວຍ

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

ວັນທີ #211: ຈາກຫນ່ວຍງານໄປຫາການທົດສອບການເຊື່ອມໂຍງ

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

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

Jenkins + Docker + Ansible = ການທົດສອບ

1. Checkout repo ແລະສ້າງຂັ້ນຕອນການກໍ່ສ້າງ.
2. ດໍາເນີນການຂັ້ນຕອນຂອງປື້ມຫຼິ້ນ lint ໃນຂະຫນານ.
3. ດໍາເນີນການຂັ້ນຕອນພາລະບົດບາດຂອງ lint ໃນຂະຫນານ.
4. ດໍາເນີນຂັ້ນຕອນການກວດສອບ syntax ໃນຂະຫນານ.
5. ດໍາເນີນຂັ້ນຕອນການທົດສອບບົດບາດໃນຂະຫນານ.
   1. ບົດບາດຂອງ Lint.
   2. ກວດສອບການຂຶ້ນກັບບົດບາດອື່ນໆ.
   3. ກວດເບິ່ງ syntax.
   4. ສ້າງ docker instance
   5. ດໍາເນີນການ molecule/default/playbook.yml.
   6. ກວດ​ສອບ​ຄວາມ​ເຂັ້ມ​ແຂງ​.
6. ດໍາເນີນການທົດສອບການເຊື່ອມໂຍງ
7. ສໍາ​ເລັດ​ຮູບ

ວັນທີ #271: ປັດໄຈລົດເມ

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

ແລະມັນຄວນຈະສະດວກສະບາຍຢູ່ທີ່ນີ້. ມັນສະດວກທີ່ຈະເຮັດການທົບທວນ, ເບິ່ງໃນຂອບຂອງສິ່ງທີ່ມັນເຮັດໄດ້, ແລະປະຫວັດສາດຂອງການສົນທະນາ. ພວກເຮົາໄດ້ປະສົມປະສານ jenkins + bitbucket + jira.

ແຕ່ດັ່ງນັ້ນ, ການທົບທວນຄືນບໍ່ແມ່ນ panacea; ບາງຢ່າງ, ພວກເຮົາໄດ້ເຂົ້າໄປໃນລະຫັດຕົ້ນສະບັບ, ເຊິ່ງເຮັດໃຫ້ພວກເຮົາທົດສອບ flop:

- get_url:
    url: "{{ actk_certs }}/{{ item.1 }}"
    dest: "{{ actk_src_tmp }}/"
    username: "{{ actk_mvn_user }}"
    password: "{{ actk_mvn_pass }}"
  with_subelements:
    - "{{ actk_cert_list }}"
    - "{{ actk_certs }}"
  delegate_to: localhost

- copy:
    src: "{{ actk_src_tmp }}/{{ item.1 }}"
    dest: "{{ actk_dst_tmp }}"
  with_subelements:
    - "{{ actk_cert_list }}"
    - "{{ actk_certs }}"

ຫຼັງຈາກນັ້ນ, ພວກເຂົາເຈົ້າໄດ້ແກ້ໄຂມັນ, ແຕ່ຕະກອນຍັງຄົງຢູ່.

get_url:
    url: "{{ actk_certs }}/{{ actk_item }}"
    dest: "{{ actk_src_tmp }}/{{ actk_item }}"
    username: "{{ actk_mvn_user }}"
    password: "{{ actk_mvn_pass }}"
  loop_control:
    loop_var: actk_item
  with_items: "{{ actk_cert_list }}"
  delegate_to: localhost

- copy:
    src: "{{ actk_src_tmp }}/{{ actk_item }}"
    dest: "{{ actk_dst_tmp }}"
  loop_control:
    loop_var: actk_item
  with_items: "{{ actk_cert_list }}"

ວັນທີ #311: ເລັ່ງການທົດສອບ

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

ເວົ້າຢ່າງເຂັ້ມງວດ, ມີຊຸດຂອງມາດຕະການ:

1. ປ່ຽນເປັນ docker.
2. ເອົາການທົດສອບບົດບາດ, ທີ່ຊ້ໍາກັນເນື່ອງຈາກການຂຶ້ນກັບ.
3. ເພີ່ມຈໍານວນສໍາລອງ.
4. ທົດສອບຄໍາສັ່ງແລ່ນ.
5. ຄວາມສາມາດໃນການ lint ທັງໝົດ ທ້ອງຖິ່ນດ້ວຍຄໍາສັ່ງດຽວ.

ດັ່ງນັ້ນ, Pipeline on jenkins ຍັງໄດ້ເປັນເອກະພາບ

1. ສ້າງຂັ້ນຕອນການກໍ່ສ້າງ.
2. Lint ທັງຫມົດໃນຂະຫນານ.
3. ດໍາເນີນຂັ້ນຕອນການທົດສອບບົດບາດໃນຂະຫນານ.
4. Finish

ຖອດ​ຖອນ​ບົດ​ຮຽນ

ຫຼີກເວັ້ນຕົວແປທົ່ວໂລກ

Ansible ໃຊ້ຕົວແປທົ່ວໂລກ, ມີການແກ້ໄຂບາງສ່ວນໃນຮູບແບບ private_role_vars, ແຕ່ນີ້ບໍ່ແມ່ນ panacea.

ໃຫ້ຂ້ອຍຍົກຕົວຢ່າງໃຫ້ເຈົ້າ. ໃຫ້ພວກເຮົາມີ role_a и role_b

# cat role_a/defaults/main.yml
---
msg: a

# cat role_a/tasks/main.yml
---
- debug:
    msg: role_a={{ msg }}

# cat role_b/defaults/main.yml
---
msg: b

# cat role_b/tasks/main.yml
---
- set_fact:
    msg: b
- debug:
    msg: role_b={{ msg }}

- hosts: localhost
  vars:
    msg: hello
  roles:
    - role: role_a
    - role: role_b
  tasks:
    - debug:
        msg: play={{msg}}

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

BAD: ໃຊ້ຕົວແປທົ່ວໂລກ.

# cat roles/some_role/tasks/main.yml
---
debug:
  var: java_home

GOOD: ວີ defaults ກໍານົດຕົວແປທີ່ຈໍາເປັນແລະຕໍ່ມາໃຊ້ພຽງແຕ່ພວກມັນ.

# cat roles/some_role/defaults/main.yml
---
r__java_home:
 "{{ java_home | default('/path') }}"

# cat roles/some_role/tasks/main.yml
---
debug:
  var: r__java_home

ຄຳນຳໜ້າຕົວແປບົດບາດ

BAD: ໃຊ້ຕົວແປທົ່ວໂລກ.

# cat roles/some_role/defaults/main.yml
---
db_port: 5432

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

# cat roles/some_role/defaults/main.yml
---
some_role__db_port: 5432

ໃຊ້ຕົວແປການຄວບຄຸມ loop

BAD: ໃຊ້ຕົວແປມາດຕະຖານໃນ loops item, ຖ້າວຽກງານ / playbook ນີ້ຖືກລວມຢູ່ບ່ອນໃດຫນຶ່ງ, ນີ້ອາດຈະນໍາໄປສູ່ພຶດຕິກໍາທີ່ບໍ່ຄາດຄິດ

---
- hosts: localhost
  tasks:
    - debug:
        msg: "{{ item }}"
      loop:
        - item1
        - item2

GOOD: ກໍານົດຕົວແປຄືນໃຫມ່ໃນ loop ຜ່ານ loop_var.

---
- hosts: localhost
  tasks:
    - debug:
        msg: "{{ item_name }}"
      loop:
        - item1
        - item2
      loop_control:
        loop_var: item_name

ກວດເບິ່ງຕົວແປການປ້ອນຂໍ້ມູນ

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

GOOD: ກວດເບິ່ງຕົວແປ.

- name: "Verify that required string variables are defined"
  assert:
    that: ahs_var is defined and ahs_var | length > 0 and ahs_var != None
    fail_msg: "{{ ahs_var }} needs to be set for the role to work "
    success_msg: "Required variables {{ ahs_var }} is defined"
  loop_control:
    loop_var: ahs_var
  with_items:
    - ahs_item1
    - ahs_item2
    - ahs_item3

ຫຼີກເວັ້ນວັດຈະນານຸກົມ hashes, ໃຊ້ໂຄງສ້າງຮາບພຽງ

ຖ້າບົດບາດຄາດວ່າຈະມີ hash/dictionary ຢູ່ໃນຕົວກໍານົດການຫນຶ່ງຂອງມັນ, ຫຼັງຈາກນັ້ນ, ຖ້າພວກເຮົາຕ້ອງການປ່ຽນພາລາມິເຕີຂອງລູກຫນຶ່ງ, ພວກເຮົາຈະຕ້ອງ override hash/dictionary ທັງຫມົດ, ເຊິ່ງຈະເພີ່ມຄວາມສັບສົນໃນການຕັ້ງຄ່າ.

BAD: ໃຊ້ hash/dictionary.

---
user:
  name: admin
  group: admin

GOOD: ໃຊ້ໂຄງສ້າງຕົວແປແປ.

---
user_name: admin
user_group: "{{ user_name }}"

ສ້າງປຶ້ມຫຼິ້ນ ແລະບົດບາດທີ່ບໍ່ເໝາະສົມ

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

ຫຼີກເວັ້ນການນໍາໃຊ້ໂມດູນ shell ຄໍາສັ່ງ

ການໃຊ້ໂມດູນ shell ສົ່ງຜົນໃຫ້ມີ paradigm ຄໍາອະທິບາຍທີ່ຈໍາເປັນ, ແທນທີ່ຈະເປັນການປະກາດ, ເຊິ່ງເປັນຫຼັກຂອງ Ansible.

ທົດສອບບົດບາດຂອງເຈົ້າຜ່ານໂມເລກຸນ

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

ໂມເລກຸນຫຼາຍຕົວຢ່າງ

В molecule.yml ໃນພາກ platforms ທ່ານສາມາດອະທິບາຍ hosts ຈໍານວນຫຼາຍທີ່ທ່ານສາມາດ deploy.

---
    driver:
      name: docker
    platforms:
      - name: postgresql-instance
        hostname: postgresql-instance
        image: registry.example.com/postgres10:latest
        pre_build_image: true
        override_command: false
        network_mode: host
      - name: app-instance
        hostname: app-instance
        pre_build_image: true
        image: registry.example.com/docker_centos_ansible_tests
        network_mode: host

ຕາມນັ້ນແລ້ວ, ເຈົ້າພາບເຫຼົ່ານີ້ສາມາດເປັນ converge.yml ໃຊ້:

---
- name: Converge all
  hosts: all
  vars:
    ansible_user: root
  roles:
    - role: some_role

- name: Converge db
  hosts: db-instance
  roles:
    - role: some_db_role

- name: Converge app
  hosts: app-instance
  roles:
    - role: some_app_role

ຕົວພິສູດຢືນຢັນ

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

---
- name: Verify
  hosts: all
  tasks:
    - name: copy config
      copy:
        src: expected_standalone.conf
        dest: /root/wildfly/bin/standalone.conf
        mode: "0644"
        owner: root
        group: root
      register: config_copy_result

    - name: Certify that standalone.conf changed
      assert:
        that: not config_copy_result.changed

ຫຼືນຳໃຊ້ການບໍລິການ, ລໍຖ້າໃຫ້ມັນສາມາດໃຊ້ໄດ້ ແລະ ທົດສອບຄວັນໄຟ:

---
  - name: Verify
    hosts: solr
    tasks:
      - command: /blah/solr/bin/solr start -s /solr_home -p 8983 -force
      - uri:
          url: http://127.0.0.1:8983/solr
          method: GET
          status_code: 200
        register: uri_result
        until: uri_result is not failed
        retries: 12
        delay: 10
      - name: Post documents to solr
        command: /blah/solr/bin/post -c master /exampledocs/books.csv

ເອົາເຫດຜົນທີ່ສັບສົນເຂົ້າໄປໃນໂມດູນ & plugins

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

ສະຫຼຸບເຄັດລັບ & Tricks

1. ຫຼີກເວັ້ນຕົວແປທົ່ວໂລກ.
2. ຄຳນຳໜ້າຕົວແປບົດບາດ.
3. ໃຊ້ຕົວແປການຄວບຄຸມ loop.
4. ກວດເບິ່ງຕົວແປການປ້ອນຂໍ້ມູນ.
5. ຫຼີກເວັ້ນວັດຈະນານຸກົມ hashes, ໃຊ້ໂຄງສ້າງຮາບພຽງ.
6. ສ້າງປຶ້ມຫຼິ້ນ ແລະບົດບາດທີ່ບໍ່ເໝາະສົມ.
7. ຫຼີກເວັ້ນການນໍາໃຊ້ໂມດູນ shell ຄໍາສັ່ງ.
8. ທົດສອບບົດບາດຂອງເຈົ້າຜ່ານໂມເລກຸນ.
9. ເອົາເຫດຜົນທີ່ສັບສົນເຂົ້າໄປໃນໂມດູນ & plugins.

ສະຫລຸບ

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

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

• ບໍລິການ ວິທີການທົດສອບ Ansible ແລະບໍ່ເປັນແກ່ນ
• ວິດີໂອ ວິທີການທົດສອບ Ansible ແລະບໍ່ເປັນແກ່ນ
• ສິ່ງທີ່ຂ້ອຍໄດ້ຮຽນຮູ້ຈາກການທົດສອບ 200 ເສັ້ນຂອງລະຫັດໂຄງສ້າງພື້ນຖານ
• Ansible: ການຍ້າຍການຕັ້ງຄ່າ 120 VM ຈາກ Coreos ໄປ Centos ໃນ 18 ເດືອນ
• ວິທີການທໍາລາຍລົດຖີບຜ່ານໄມ້ຄ້ອນໃນເວລາທີ່ການທົດສອບການແຈກຢາຍຂອງທ່ານ
• ທົດສອບຂ້ອຍວ່າເຈົ້າສາມາດຫຼືເຮັດໂຄງການ YML ຝັນຂອງການທົດສອບ Ansible?
• ບັນຊີລາຍຊື່ຂອງບົດຄວາມການທົດສອບ IaC ທີ່ດີເລີດ, ຄໍາປາໄສ & ການເຊື່ອມຕໍ່
• ຂ້າມໄປສະນີ
• ສະບັບພາສາອັງກິດ

UPD1 2020.05.01 20:30 — ສໍາ​ລັບ profile ຕົ້ນ​ຕໍ​ຂອງ playbooks ທ່ານ​ສາ​ມາດ​ນໍາ​ໃຊ້​ callback_whitelist = profile_tasks ເພື່ອເຂົ້າໃຈສິ່ງທີ່ແນ່ນອນເຮັດວຽກເປັນເວລາດົນນານ. ຫຼັງຈາກນັ້ນ, ພວກເຮົາຜ່ານ ຄລາສສິກການເລັ່ງ Ansible. ນອກນັ້ນທ່ານຍັງສາມາດພະຍາຍາມ ໄມໂຕເຈນ
UPD2 2020.05.03 16:34 - ສະບັບພາສາອັງກິດ

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