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

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

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

Titles

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

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

ansible-playbook ດໍາເນີນການ playbook ໄດ້. playbook ແມ່ນໄຟລ໌ທີ່ມີນາມສະກຸນ yml/yaml, ພາຍໃນນັ້ນມີບາງສິ່ງບາງຢ່າງເຊັ່ນນີ້:

---
- hosts: group1
  roles:
    - role1

- hosts: group2,group3
  tasks:
    - debug:

ພວກ​ເຮົາ​ຮູ້​ແລ້ວ​ວ່າ​ໄຟລ​໌​ທັງ​ຫມົດ​ນີ້​ແມ່ນ playbook​. ພວກເຮົາສາມາດສະແດງໃຫ້ເຫັນວ່າບົດບາດຢູ່ໃສ ແລະໜ້າວຽກຢູ່ໃສ. ແຕ່ຫຼິ້ນຢູ່ໃສ? ແລະ ຄວາມແຕກຕ່າງກັນລະຫວ່າງບົດລະຄອນ ແລະ ບົດລະຄອນ ຫຼື ບົດລະຄອນ ແມ່ນຫຍັງ?

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

ດັ່ງນັ້ນ, ຈື່: Playbook ແມ່ນບັນຊີລາຍຊື່ປະກອບດ້ວຍການຫຼິ້ນແລະ import_playbook.
ນີ້​ແມ່ນ​ການ​ຫຼິ້ນ​ຫນຶ່ງ​:

- hosts: group1
  roles:
    - role1

ແລະ​ນີ້​ຍັງ​ເປັນ​ການ​ຫຼິ້ນ​ອີກ​ອັນ​ຫນຶ່ງ​:

- hosts: group2,group3
  tasks:
    - debug:

ການຫຼິ້ນແມ່ນຫຍັງ? ເປັນຫຍັງນາງ?

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

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

ງ່າຍດາຍ, ສິດ? ມັນເປັນໄປໄດ້ແນວໃດຖ້າບໍ່ດັ່ງນັ້ນ?

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

ຕົວ ຢ່າງ archetypal ແມ່ນ ການ ຕິດ ຕາມ. ຂ້າພະເຈົ້າຢາກຈະມີບົດບາດໃນການຕິດຕາມທີ່ຈະກໍານົດການຕິດຕາມກວດກາ. ພາລະບົດບາດຕິດຕາມກວດກາໄດ້ຖືກມອບຫມາຍໃຫ້ເຈົ້າພາບຕິດຕາມກວດກາ (ອີງຕາມການຫຼິ້ນ). ແຕ່ມັນ turns ໃຫ້ເຫັນວ່າສໍາລັບການຕິດຕາມກວດກາພວກເຮົາຈໍາເປັນຕ້ອງໄດ້ຈັດສົ່ງຊຸດກັບເຈົ້າພາບທີ່ພວກເຮົາກໍາລັງຕິດຕາມກວດກາ. ເປັນຫຍັງບໍ່ໃຊ້ຕົວແທນ? ນອກນັ້ນທ່ານຍັງຈໍາເປັນຕ້ອງໄດ້ configure iptables. ຜູ້ແທນ? ນອກນັ້ນທ່ານຍັງຈໍາເປັນຕ້ອງຂຽນ / ແກ້ໄຂການຕັ້ງຄ່າສໍາລັບ DBMS ເພື່ອເປີດໃຊ້ການຕິດຕາມ. ຜູ້ແທນ! ແລະຖ້າຫາກວ່າຄວາມຄິດສ້າງສັນແມ່ນຂາດ, ຫຼັງຈາກນັ້ນທ່ານສາມາດເຮັດຄະນະຜູ້ແທນ include_role ໃນ loop ຊ້ອນໂດຍໃຊ້ຕົວກອງ tricky ໃນບັນຊີລາຍຊື່ຂອງກຸ່ມ, ແລະພາຍໃນ include_role ເຈົ້າສາມາດເຮັດໄດ້ຫຼາຍກວ່ານັ້ນ delegate_to ອີກເທື່ອຫນຶ່ງ. ແລະ​ພວກ​ເຮົາ​ໄປ ...

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

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

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

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

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

ຂອບໃຈ, ເຈົ້າເວົ້າຖືກ. Play ຕັດສິນໃຈ (ຊັດເຈນກວ່ານັ້ນ, ມັນມີຂໍ້ມູນ) ກ່ຽວກັບວ່າໜ້າວຽກ ແລະ ບົດບາດອັນໃດທີ່ຈະເຮັດກັບເຈົ້າພາບໃດ.

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

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

ຫມາຍເຫດສໍາລັບ squeamish: ພາລະບົດບາດແນ່ນອນວ່າສາມາດມີອິດທິພົນຕໍ່ການໄຫຼເຂົ້າຂອງການຄວບຄຸມ. ກິນ delegate_to ແລະມັນມີການນໍາໃຊ້ທີ່ສົມເຫດສົມຜົນ. ກິນ meta: end host/play. ແຕ່! ຈື່ພວກເຮົາສອນພື້ນຖານບໍ? ລືມກ່ຽວກັບ delegate_to. ພວກເຮົາກໍາລັງເວົ້າກ່ຽວກັບລະຫັດ Ansible ທີ່ງ່າຍດາຍແລະສວຍງາມທີ່ສຸດ. ຊຶ່ງ​ເປັນ​ການ​ອ່ານ​ງ່າຍ​, ຂຽນ​ງ່າຍ​, ງ່າຍ​ທີ່​ຈະ debug​, ງ່າຍ​ທີ່​ຈະ​ທົດ​ສອບ​ແລະ​ງ່າຍ​ທີ່​ຈະ​ສໍາ​ເລັດ​. ດັ່ງນັ້ນ, ອີກເທື່ອຫນຶ່ງ:

ຫຼິ້ນແລະຫຼິ້ນພຽງແຕ່ຕັດສິນໃຈວ່າເຈົ້າພາບສິ່ງທີ່ຖືກປະຕິບັດ.

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

ໜ້າທີ່ ແລະ ບົດບາດ

ພິຈາລະນາຫຼິ້ນ:

- hosts: somegroup
  pre_tasks:
    - some_tasks1:
  roles:
     - role1
     - role2
  post_tasks:
     - some_task2:
     - some_task3:

ໃຫ້ເວົ້າວ່າທ່ານຈໍາເປັນຕ້ອງເຮັດ foo. ແລະເບິ່ງຄືວ່າ foo: name=foobar state=present. ຂ້ອຍຄວນຂຽນນີ້ຢູ່ໃສ? ລ່ວງໜ້າ? ຕອບ? ສ້າງບົດບາດ?

...ແລ້ວວຽກໄປໃສ?

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

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

ຄໍາສັ່ງຂອງພາກສ່ວນຂອງເຂົາເຈົ້າກັບວຽກງານແລະພາລະບົດບາດ: pre_tasks, roles, tasks, post_tasks. ເນື່ອງຈາກວ່າ semantic ຄໍາສັ່ງຂອງການປະຕິບັດແມ່ນລະຫວ່າງ tasks и roles ແມ່ນບໍ່ຊັດເຈນ, ຫຼັງຈາກນັ້ນການປະຕິບັດທີ່ດີທີ່ສຸດເວົ້າວ່າພວກເຮົາກໍາລັງເພີ່ມພາກສ່ວນ tasks, ພຽງແຕ່ຖ້າຫາກວ່າບໍ່ roles... ຖ້າມີ roles, ຫຼັງຈາກນັ້ນວຽກງານທີ່ຕິດຄັດມາທັງຫມົດແມ່ນຖືກຈັດໃສ່ໃນພາກສ່ວນຕ່າງໆ pre_tasks/post_tasks.

ທັງຫມົດທີ່ຍັງເຫຼືອແມ່ນວ່າທຸກສິ່ງທຸກຢ່າງແມ່ນຈະແຈ້ງ semanically: ທໍາອິດ pre_tasksຫຼັງຈາກນັ້ນ, rolesຫຼັງຈາກນັ້ນ, post_tasks.

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

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

ແນ່ນອນ, ຄໍາເວົ້າຂອງຄໍາຖາມຊີ້ບອກວ່າມັນຈະແຕກ. ແຕ່ສິ່ງທີ່ແນ່ນອນ?

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

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

ບັດ​ນີ້​ໃຫ້​ຄິດ​ເບິ່ງ​ອີກ​ວ່າ​ເປັນ​ຫຍັງ​ພວກ​ເຮົາ​ຕ້ອງ​ການ pre_tasks и post_tasks? ຕົວຢ່າງ, ເພື່ອເຮັດສໍາເລັດທຸກຢ່າງທີ່ຈໍາເປັນ (ລວມທັງຕົວຈັດການ) ກ່ອນທີ່ຈະປະຕິບັດພາລະບົດບາດ. ກ post_tasks ຈະອະນຸຍາດໃຫ້ພວກເຮົາເຮັດວຽກກັບຜົນໄດ້ຮັບຂອງການປະຕິບັດພາລະບົດບາດ (ລວມທັງ handlers).

ຜູ້ຊ່ຽວຊານ Ansible ສະຫລາດຈະບອກພວກເຮົາວ່າມັນແມ່ນຫຍັງ. meta: flush_handlers, ແຕ່ເປັນຫຍັງພວກເຮົາຕ້ອງການ flush_handlers ຖ້າພວກເຮົາສາມາດອີງໃສ່ຄໍາສັ່ງຂອງການປະຕິບັດພາກສ່ວນຕ່າງໆໃນການຫຼິ້ນ? ຍິ່ງໄປກວ່ານັ້ນ, ການນໍາໃຊ້ meta: flush_handlers ສາມາດໃຫ້ພວກເຮົາສິ່ງທີ່ບໍ່ຄາດຄິດກັບຕົວຈັດການທີ່ຊ້ໍາກັນ, ໃຫ້ຄໍາເຕືອນທີ່ແປກປະຫຼາດໃຫ້ພວກເຮົາໃນເວລາທີ່ໃຊ້. when у block ແລະອື່ນໆ ຍິ່ງເຈົ້າຮູ້ຈັກ ansible ດີກວ່າ, ມີຫຼາຍອັນທີ່ເຈົ້າສາມາດຕັ້ງຊື່ໃຫ້ກັບການແກ້ໄຂ “ຍາກ”. ແລະການແກ້ໄຂທີ່ງ່າຍດາຍ - ການນໍາໃຊ້ການແບ່ງປັນທໍາມະຊາດລະຫວ່າງ pre / ພາລະບົດບາດ / post - ບໍ່ເຮັດໃຫ້ເກີດ nuances.

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

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

ຄວາມເຂົ້າໃຈພື້ນຖານຂອງ Ansible ໃຫ້ຄໍາຕອບທີ່ສົມເຫດສົມຜົນຕໍ່ຄໍາຖາມທີ່ເບິ່ງຄືວ່າມີລົດຊາດ.

ໜ້າທີ່ ແລະ ບົດບາດ (ພາກທີ 2)

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

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

ໃນປັດຈຸບັນ, ເອົາໃຈໃສ່. ສິ່ງທີ່ສາມາດເຮັດໄດ້ຈາກນີ້ໃນພາລະບົດບາດ? ທ່ານສະເຫມີຍິນດີຕ້ອນຮັບໂທຫາຜົນກະທົບຂ້າງຄຽງ, ນີ້ແມ່ນສໍາຄັນຂອງ Ansible ທັງຫມົດ - ເພື່ອສ້າງຜົນຂ້າງຄຽງ. ມີສາເຫດຂ້າງຄຽງ? ປະຖົມ. ແຕ່ກັບ "ຜ່ານມູນຄ່າແລະສົ່ງຄືນມັນ" - ນັ້ນແມ່ນບ່ອນທີ່ມັນບໍ່ເຮັດວຽກ. ກ່ອນອື່ນ ໝົດ, ທ່ານບໍ່ສາມາດສົ່ງຄ່າໃຫ້ກັບບົດບາດໃດ ໜຶ່ງ. ທ່ານສາມາດກໍານົດຕົວແປທົ່ວໂລກທີ່ມີຂະຫນາດຕະຫຼອດຊີວິດຂອງການຫຼິ້ນໃນພາກ vars ສໍາລັບບົດບາດ. ທ່ານສາມາດກໍານົດຕົວແປທົ່ວໂລກທີ່ມີຕະຫຼອດຊີວິດໃນການຫຼິ້ນພາຍໃນບົດບາດ. ຫຼື​ແມ່ນ​ແຕ່​ກັບ​ຊີ​ວິດ​ຂອງ playbooks (set_fact/register). ແຕ່ທ່ານບໍ່ສາມາດມີ "ຕົວແປທ້ອງຖິ່ນ". ທ່ານບໍ່ສາມາດ "ເອົາມູນຄ່າ" ແລະ "ສົ່ງຄືນມັນ".

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

ລວມ: ບົດບາດບໍ່ແມ່ນຫນ້າທີ່.

ແມ່ນຫຍັງດີກ່ຽວກັບບົດບາດ? ຫນ້າທໍາອິດ, ບົດບາດມີຄ່າເລີ່ມຕົ້ນ (/default/main.yaml), ອັນທີສອງ, ພາລະບົດບາດມີໄດເລກະທໍລີເພີ່ມເຕີມສໍາລັບການເກັບຮັກສາໄຟລ໌.

ຜົນປະໂຫຍດຂອງຄ່າເລີ່ມຕົ້ນແມ່ນຫຍັງ? ເນື່ອງຈາກວ່າໃນ pyramid ຂອງ Maslow, ຕາຕະລາງການບິດເບືອນຂອງ Ansible ແທນທີ່ຈະເປັນບູລິມະສິດຂອງຕົວປ່ຽນແປງ, ບົດບາດເລີ່ມຕົ້ນແມ່ນຄວາມສໍາຄັນຕ່ໍາທີ່ສຸດ (ລົບຕົວກໍານົດການເສັ້ນຄໍາສັ່ງ Ansible). ນີ້ຫມາຍຄວາມວ່າຖ້າທ່ານຕ້ອງການໃຫ້ຄ່າເລີ່ມຕົ້ນແລະບໍ່ກັງວົນກ່ຽວກັບພວກມັນ overriding ຄ່າຈາກສິນຄ້າຄົງຄັງຫຼືຕົວແປກຸ່ມ, ຫຼັງຈາກນັ້ນ, ບົດບາດເລີ່ມຕົ້ນແມ່ນບ່ອນດຽວທີ່ເຫມາະສົມສໍາລັບທ່ານ. (ຂ້ອຍເວົ້າຕົວະເລັກນ້ອຍ - ມີຫຼາຍກວ່ານັ້ນ |d(your_default_here), ແຕ່ຖ້າພວກເຮົາສົນທະນາກ່ຽວກັບສະຖານທີ່ stationary, ຫຼັງຈາກນັ້ນພຽງແຕ່ບົດບາດເລີ່ມຕົ້ນ).

ມີຫຍັງອີກແດ່ທີ່ຍິ່ງໃຫຍ່ກ່ຽວກັບບົດບາດ? ເນື່ອງຈາກວ່າພວກເຂົາມີລາຍການຂອງຕົນເອງ. ເຫຼົ່ານີ້ແມ່ນໄດເລກະທໍລີສໍາລັບຕົວແປ, ທັງຄົງທີ່ (i. e. ຄິດໄລ່ສໍາລັບບົດບາດ) ແລະແບບເຄື່ອນໄຫວ (ມີຮູບແບບຫຼືຮູບແບບຕ້ານ -. include_vars ພ້ອມດ້ວຍ {{ ansible_distribution }}-{{ ansible_distribution_major_version }}.yml.). ເຫຼົ່ານີ້ແມ່ນໄດເລກະທໍລີສໍາລັບ files/, templates/. ນອກຈາກນີ້, ມັນອະນຸຍາດໃຫ້ທ່ານມີໂມດູນແລະ plugins ຂອງທ່ານເອງ (library/). ແຕ່, ໃນການສົມທຽບກັບວຽກງານໃນປື້ມຫຼິ້ນ (ເຊິ່ງສາມາດມີທັງຫມົດນີ້), ຜົນປະໂຫຍດພຽງແຕ່ຢູ່ທີ່ນີ້ແມ່ນວ່າໄຟລ໌ບໍ່ໄດ້ຖືກຖິ້ມເຂົ້າໄປໃນຫນຶ່ງ pile, ແຕ່ຫຼາຍ piles ແຍກຕ່າງຫາກ.

ລາຍລະອຽດເພີ່ມເຕີມອີກອັນໜຶ່ງ: ທ່ານສາມາດພະຍາຍາມສ້າງບົດບາດທີ່ມີໃຫ້ນຳໃຊ້ຄືນໃໝ່ (ຜ່ານ galaxy). ກັບການມາເຖິງຂອງການເກັບກໍາ, ການແຈກຢາຍບົດບາດສາມາດຖືກພິຈາລະນາເກືອບລືມ.

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

ກັບຄືນໄປຫາຄໍາຖາມຕົ້ນສະບັບ: ເວລາໃດທີ່ຈະເຮັດວຽກແລະເວລາທີ່ຈະເຮັດພາລະບົດບາດ? ວຽກງານໃນປຶ້ມຫຼິ້ນມັກຈະຖືກໃຊ້ເປັນ “ກາວ” ກ່ອນ/ຫຼັງບົດບາດ, ຫຼືເປັນອົງປະກອບກໍ່ສ້າງເອກະລາດ (ຫຼັງຈາກນັ້ນບໍ່ຄວນມີບົດບາດໃນລະຫັດ). ວຽກ​ງານ​ປົກ​ກະ​ຕິ​ປະ​ສົມ​ກັບ​ພາ​ລະ​ບົດ​ບາດ​ແມ່ນ​ຄວາມ​ຫຍາບ​ຄາຍ​ທີ່​ບໍ່​ແນ່​ນອນ. ທ່ານຄວນຍຶດຫມັ້ນກັບແບບສະເພາະ - ບໍ່ວ່າຈະເປັນວຽກງານຫຼືບົດບາດ. ພາລະບົດບາດສະຫນອງການແຍກຕ່າງຫາກຂອງຫນ່ວຍງານແລະຄ່າເລີ່ມຕົ້ນ, ວຽກງານຊ່ວຍໃຫ້ທ່ານສາມາດອ່ານລະຫັດໄດ້ໄວຂຶ້ນ. ປົກກະຕິແລ້ວ, ລະຫັດ "stationary" (ທີ່ສໍາຄັນແລະສະລັບສັບຊ້ອນ) ຫຼາຍແມ່ນໃສ່ໃນພາລະບົດບາດ, ແລະ scripts auxiliary ແມ່ນລາຍລັກອັກສອນໃນລັກສະນະວຽກງານ.

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

ຜູ້ອ່ານທີ່ສະຫລາດອາດຈະເວົ້າວ່າບົດບາດສາມາດນໍາເຂົ້າພາລະບົດບາດ, ພາລະບົດບາດສາມາດມີຄວາມເພິ່ງພາອາໄສຜ່ານ galaxy.yml, ແລະຍັງມີຄວາມຂີ້ຮ້າຍແລະຂີ້ຮ້າຍ. include_role — ຂ້າ​ພະ​ເຈົ້າ​ເຕືອນ​ທ່ານ​ວ່າ​ພວກ​ເຮົາ​ກໍາ​ລັງ​ປັບ​ປຸງ​ຄວາມ​ສາ​ມາດ​ໃນ Ansible ພື້ນ​ຖານ​, ແລະ​ບໍ່​ແມ່ນ​ໃນ gymnastics ຮູບ​.

ຜູ້​ຈັດ​ການ​ແລະ​ວຽກ​ງານ​

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

ເນື່ອງຈາກພວກເຮົາຈື່ຈໍາພື້ນຖານ, ນີ້ແມ່ນຕົວຢ່າງ:

- hosts: group1
  tasks:
    - foo:
      notify: handler1
  handlers:
     - name: handler1
       bar:

ຕົວຈັດການບົດບາດແມ່ນຕັ້ງຢູ່ໃນ rolename/handlers/main.yaml. Handlers rummage ລະ​ຫວ່າງ​ຜູ້​ເຂົ້າ​ຮ່ວມ​ການ​ຫຼິ້ນ​ທັງ​ຫມົດ​: pre/post_tasks ສາ​ມາດ​ດຶງ​ຕົວ​ຈັດ​ການ​ພາ​ລະ​ບົດ​ບາດ​, ແລະ​ບົດ​ບາດ​ສາ​ມາດ​ດຶງ handlers ຈາກ​ການ​ຫຼິ້ນ​. ຢ່າງໃດກໍ່ຕາມ, ການໂທຫາ "ຂ້າມບົດບາດ" ກັບຕົວຈັດການເຮັດໃຫ້ເກີດ wtf ຫຼາຍກ່ວາການເຮັດຊ້ໍາຕົວຈັດການເລັກນ້ອຍ. (ອົງປະກອບອື່ນຂອງການປະຕິບັດທີ່ດີທີ່ສຸດແມ່ນການພະຍາຍາມບໍ່ຊ້ໍາຊື່ handler).

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

ສະຖານະການທີ່ມີ config ບໍ່ສາມາດແກ້ໄຂໄດ້ (ທີ່ຊັດເຈນກວ່ານັ້ນ, ທ່ານສາມາດສ້າງໂປໂຕຄອນ restart ພິເສດສໍາລັບຕົວທ່ານເອງດ້ວຍທຸງໄຟລ໌, ແລະອື່ນໆ, ແຕ່ນີ້ບໍ່ແມ່ນ 'ພື້ນຖານ ansible' ໃນຮູບແບບໃດກໍ່ຕາມ). ແຕ່ມີເລື່ອງທົ່ວໄປອີກຢ່າງຫນຶ່ງ: ພວກເຮົາຕິດຕັ້ງແອັບພລິເຄຊັນ, ບັນທຶກມັນ .service-file, ແລະໃນປັດຈຸບັນພວກເຮົາຕ້ອງການມັນ daemon_reload и state=started. ແລະສະຖານທີ່ທໍາມະຊາດສໍາລັບການນີ້ເບິ່ງຄືວ່າເປັນຜູ້ຈັດການ. ແຕ່ຖ້າທ່ານເຮັດໃຫ້ມັນບໍ່ແມ່ນຕົວຈັດການແຕ່ເປັນວຽກງານໃນຕອນທ້າຍຂອງບັນຊີລາຍຊື່ວຽກຫຼືບົດບາດ, ຫຼັງຈາກນັ້ນມັນຈະຖືກປະຕິບັດຢ່າງບໍ່ຢຸດຢັ້ງທຸກຄັ້ງ. ເຖິງແມ່ນວ່າ playbook broke ຢູ່ເຄິ່ງກາງ. ນີ້ບໍ່ໄດ້ແກ້ໄຂບັນຫາການເລີ່ມຕົ້ນໃຫມ່ທັງຫມົດ (ທ່ານບໍ່ສາມາດເຮັດວຽກກັບຄຸນລັກສະນະທີ່ເລີ່ມຕົ້ນໃຫມ່, ເພາະວ່າ idempotency ສູນເສຍ), ແຕ່ແນ່ນອນມັນຄຸ້ມຄ່າທີ່ຈະເຮັດ state=started, ຄວາມຫມັ້ນຄົງໂດຍລວມຂອງ playbooks ເພີ່ມຂຶ້ນ, ເພາະວ່າ. ຈໍານວນຂອງການເຊື່ອມຕໍ່ແລະລັດເຄື່ອນໄຫວຫຼຸດລົງ.

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

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

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

ຜູ້ອ່ານ corrosive ຊີ້ຢ່າງຖືກຕ້ອງວ່າພວກເຮົາບໍ່ໄດ້ສົນທະນາ listenທີ່ handler ສາມາດໂທຫາການແຈ້ງເຕືອນສໍາລັບ handler ອື່ນ, ທີ່ handler ສາມາດປະກອບມີ import_tasks (ເຊິ່ງສາມາດເຮັດໄດ້ include_role ກັບ with_items), ວ່າລະບົບ handler ໃນ Ansible ແມ່ນ Turing-complete, ທີ່ handler ຈາກ include_role ຕັດກັນໃນວິທີການ curious ກັບ handlers ຈາກການຫຼິ້ນ, ແລະອື່ນໆ..ງ. - ທັງ​ຫມົດ​ນີ້​ແມ່ນ​ຈະ​ແຈ້ງ​ບໍ່​ແມ່ນ "ພື້ນ​ຖານ​"​)​.

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

ແຍກຕ່າງຫາກ, ຂ້ອຍຕ້ອງການເວົ້າສອງສາມຄໍາກ່ຽວກັບບົດບາດທີ່ສາມາດນໍາມາໃຊ້ຄືນໄດ້. ກ່ອນທີ່ຈະລວບລວມຂໍ້ມູນປາກົດ, ມີຄວາມຄິດທີ່ວ່າເຈົ້າສາມາດສ້າງບົດບາດທົ່ວໄປທີ່ອາດຈະເປັນ ansible-galaxy install ແລະໄປ. ເຮັດ​ວຽກ​ກ່ຽວ​ກັບ OS ທັງ​ຫມົດ​ຂອງ​ຕົວ​ແປ​ທັງ​ຫມົດ​ໃນ​ທຸກ​ສະ​ຖາ​ນະ​ການ​. ດັ່ງນັ້ນ, ຄວາມຄິດເຫັນຂອງຂ້ອຍ: ມັນບໍ່ໄດ້ຜົນ. ບົດບາດທີ່ມີມະຫາຊົນ include_vars, ສະຫນັບສະຫນູນ 100500 ກໍລະນີ, ແມ່ນ doomed ກັບ abyss ຂອງແມງໄມ້ກໍລະນີແຈ. ພວກເຂົາສາມາດຖືກສຽບດ້ວຍການທົດສອບຂະຫນາດໃຫຍ່, ແຕ່ເຊັ່ນດຽວກັນກັບການທົດສອບໃດກໍ່ຕາມ, ທ່ານມີຜະລິດຕະພັນ Cartesian ຂອງມູນຄ່າການປ້ອນຂໍ້ມູນແລະຫນ້າທີ່ທັງຫມົດ, ຫຼືທ່ານມີ "ສະຖານະການສ່ວນບຸກຄົນທີ່ກວມເອົາ." ຄວາມຄິດເຫັນຂອງຂ້ອຍແມ່ນວ່າມັນຈະດີກວ່າຫຼາຍຖ້າບົດບາດເປັນເສັ້ນ (ຄວາມສັບສົນຂອງວົງຈອນ 1).

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

ໃນພາກສ່ວນຕໍ່ໄປນີ້

• ເລັກນ້ອຍກ່ຽວກັບສິນຄ້າຄົງຄັງ, ຕົວແປກຸ່ມ, host_group_vars plugin, hostvars. ວິທີການຜູກມັດ Gordian ກັບ spaghetti. ຂອບເຂດ ແລະຕົວແປກ່ອນໜ້າ, ແບບຈຳລອງຄວາມຊົງຈຳ Ansible. "ດັ່ງນັ້ນພວກເຮົາເກັບຮັກສາຊື່ຜູ້ໃຊ້ສໍາລັບຖານຂໍ້ມູນຢູ່ໃສ?"
• jinja: {{ jinja }} — nosql notype nosense plasticine ອ່ອນ. ມັນຢູ່ທົ່ວທຸກແຫ່ງ, ເຖິງແມ່ນບ່ອນທີ່ທ່ານບໍ່ຄາດຄິດ. ເລັກນ້ອຍກ່ຽວກັບ !!unsafe ແລະ yaml delicious.

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