The Inside Playbook. ຄຸນສົມບັດເຄືອຂ່າຍໃນ Ansible Engine 2.9 ໃໝ່

ການປ່ອຍທີ່ຈະມາເຖິງຂອງ Red Hat Ansible Engine 2.9 ນໍາເອົາການປັບປຸງທີ່ຫນ້າຕື່ນເຕັ້ນ, ບາງອັນແມ່ນກວມເອົາໃນບົດຄວາມນີ້. ດັ່ງທີ່ເຄີຍມີມາ, ພວກເຮົາໄດ້ພັດທະນາການປັບປຸງເຄືອຂ່າຍ Ansible ຢ່າງເປີດເຜີຍ, ດ້ວຍການຊ່ວຍເຫຼືອຈາກຊຸມຊົນ. ເຂົ້າຮ່ວມກັບພວກເຮົາ - ເບິ່ງ ອອກກະດານກ່ຽວກັບ GitHub ແລະ​ສຶກ​ສາ​ແຜນ​ການ​ພັດ​ທະ​ນາ​ສໍາ​ລັບ​ການ​ ການປ່ອຍເຄື່ອງຈັກ Red Hat Ansible 2.9 ໃນຫນ້າ wiki ສໍາລັບ ເຄືອຂ່າຍ Ansible.

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

• Arista EOS
• Cisco IOS
• Cisco IOS XR
• Cisco NX-OS
• Juniper Junos
• VyOS

ສໍາລັບບັນຊີລາຍຊື່ເຕັມຂອງເວທີທີ່ໄດ້ຮັບການສະຫນັບສະຫນູນຢ່າງເຕັມທີ່ຈາກ Red Hat ໂດຍຜ່ານການສະຫມັກ Ansible Automation, ຈັດພີມມາຢູ່ທີ່ນີ້.

ພວກເຮົາໄດ້ຮຽນຮູ້ຫຍັງ

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

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

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

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

ການປັບປຸງຄວາມເປັນຈິງ

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

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

ຖ້າທ່ານຮູ້ວິທີການໃຊ້ Network Engine, ນີ້ແມ່ນວິທີທີ່ມີປະສິດທິພາບຫຼາຍໃນການເກັບກໍາ, ວິເຄາະ, ແລະມາດຕະຖານຂໍ້ມູນຄວາມເປັນຈິງສໍາລັບການນໍາໃຊ້ໃນ Ansible. ຂໍ້ເສຍຂອງບົດບາດນີ້ແມ່ນວ່າທ່ານຕ້ອງການສ້າງກຸ່ມ parser ທັງຫມົດສໍາລັບແຕ່ລະແພລະຕະຟອມແລະສໍາລັບກິດຈະກໍາເຄືອຂ່າຍທັງຫມົດ. ເພື່ອເຂົ້າໃຈວ່າມັນມີຄວາມຫຍຸ້ງຍາກແນວໃດໃນການສ້າງ, ຈັດສົ່ງ, ແລະຮັກສາຕົວວິເຄາະ, ໃຫ້ເບິ່ງ ຫຼາຍກວ່າ 1200 ຕົວວິເຄາະ ຈາກ guys ຢູ່ Cisco.

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

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

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

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

ໃນຂະນະທີ່ເກັບກໍາຂໍ້ເທັດຈິງ:

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

- hosts: arista
  module_defaults:
    eos_facts:
      gather_subset: min
      gather_network_resources:
      - interfaces
  gather_facts: True

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

ການນໍາໃຊ້ໂມດູນຄວາມເປັນຈິງເຄືອຂ່າຍໂດຍກົງ:

- name: collect interface configuration facts
  eos_facts:
    gather_subset: min
    gather_network_resources:
    - interfaces

playbook ສົ່ງຄືນຂໍ້ເທັດຈິງຕໍ່ໄປນີ້ກ່ຽວກັບການໂຕ້ຕອບ:

ansible_facts:
   ansible_network_resources:
      interfaces:
      - enabled: true
        name: Ethernet1
        mtu: '1476'
      - enabled: true
        name: Loopback0
      - enabled: true
        name: Loopback1
      - enabled: true
        mtu: '1476'
        name: Tunnel0
      - enabled: true
        name: Ethernet1
      - enabled: true
        name: Tunnel1
      - enabled: true
        name: Ethernet1

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

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

ໂມດູນຊັບພະຍາກອນ

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

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

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

- name: example of facts being pushed right back to device.
  hosts: arista
  gather_facts: false
  tasks:
  - name: grab arista eos facts
    eos_facts:
      gather_subset: min
      gather_network_resources: l3_interfaces

  - name: ensure that the IP address information is accurate
    eos_l3_interfaces:
      config: "{{ ansible_network_resources['l3_interfaces'] }}"
      register: result

  - name: ensure config did not change
    assert:
      that: not result.changed

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

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

ໂມດູນຊັບພະຍາກອນໃຫມ່ແຕກຕ່າງຈາກຊຸດທີ່ຜ່ານມາແນວໃດ?

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

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

2) ໂມດູນຊັບພະຍາກອນໃນປັດຈຸບັນປະກອບມີຄ່າຂອງລັດ.

• merged: ການຕັ້ງຄ່າຖືກລວມເຂົ້າກັບການຕັ້ງຄ່າທີ່ສະໜອງໃຫ້ (ຄ່າເລີ່ມຕົ້ນ);
• replaced: ການຕັ້ງຄ່າຊັບພະຍາກອນຈະຖືກແທນທີ່ດ້ວຍການຕັ້ງຄ່າທີ່ສະໜອງໃຫ້;
• overridden: ການຕັ້ງຄ່າຊັບພະຍາກອນຈະຖືກແທນທີ່ດ້ວຍການຕັ້ງຄ່າທີ່ສະໜອງໃຫ້; ຊັບພະຍາກອນທີ່ບໍ່ຈໍາເປັນຈະຖືກລຶບຖິ້ມ;
• deleted: ການກຳນົດຄ່າຊັບພະຍາກອນຈະຖືກລຶບ/ກູ້ຄືນເປັນຄ່າເລີ່ມຕົ້ນ.

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

• before: ການຕັ້ງຄ່າໃນອຸປະກອນໃນຮູບແບບຂອງຂໍ້ມູນທີ່ມີໂຄງສ້າງກ່ອນຫນ້າວຽກ;
• after: ຖ້າ​ຫາກ​ວ່າ​ອຸ​ປະ​ກອນ​ໄດ້​ມີ​ການ​ປ່ຽນ​ແປງ (ຫຼື​ອາດ​ຈະ​ມີ​ການ​ປ່ຽນ​ແປງ​ຖ້າ​ຫາກ​ວ່າ​ຮູບ​ແບບ​ການ​ທົດ​ສອບ​ໄດ້​ຖືກ​ນໍາ​ໃຊ້​)​, ການ​ຕັ້ງ​ຄ່າ​ຜົນ​ໄດ້​ຮັບ​ຈະ​ໄດ້​ຮັບ​ກັບ​ຄືນ​ໄປ​ບ່ອນ​ເປັນ​ຂໍ້​ມູນ​ໂຄງ​ສ້າງ​;
• commands: ຄຳສັ່ງການຕັ້ງຄ່າໃດກໍໄດ້ແລ່ນຢູ່ໃນອຸປະກອນເພື່ອນຳມັນເຂົ້າສູ່ສະຖານະທີ່ຕ້ອງການ.

ທັງໝົດນີ້ໝາຍຄວາມວ່າແນວໃດ? ເປັນຫຍັງມັນຈຶ່ງສໍາຄັນ?

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

ອົງການຈັດຕັ້ງກໍາລັງຮັບຮູ້ວ່າອັດຕະໂນມັດແມ່ແບບເຄືອຂ່າຍສ່ວນບຸກຄົນບໍ່ໄດ້ແກ້ໄຂບັນຫາຂອງ silos ແລະພຽງແຕ່ເພີ່ມປະສິດທິພາບໃນລະດັບໃດຫນຶ່ງ. Red Hat Ansible Automation Platform ສະໜອງຮູບແບບຂໍ້ມູນຊັບພະຍາກອນທີ່ເຂັ້ມງວດ ແລະເປັນມາດຕະຖານເພື່ອຈັດການຂໍ້ມູນພື້ນຖານໃນອຸປະກອນເຄືອຂ່າຍຢ່າງເປັນໂປຣແກຣມ. ນັ້ນແມ່ນ, ຜູ້ໃຊ້ກໍາລັງຄ່ອຍໆປະຖິ້ມວິທີການກໍານົດຄ່າສ່ວນບຸກຄົນເພື່ອສະຫນັບສະຫນູນວິທີການທີ່ທັນສະໄຫມຫຼາຍໂດຍເນັ້ນຫນັກໃສ່ເຕັກໂນໂລຢີ (ຕົວຢ່າງ, ທີ່ຢູ່ IP, VLANs, LLDP, ແລະອື່ນໆ), ແທນທີ່ຈະເປັນການປະຕິບັດສະເພາະຂອງຜູ້ຂາຍ.

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

ໂມດູນຊັບພະຍາກອນໃດທີ່ຈະມາໃນ Ansible Engine 2.9?

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

ພວກເຮົາໄດ້ກໍານົດ 7 ປະເພດແລະມອບຫມາຍຊັບພະຍາກອນເຄືອຂ່າຍສະເພາະໃຫ້ແຕ່ລະຄົນ:

ໝາຍເຫດ: ຊັບພະຍາກອນທີ່ເປັນຕົວໜາໄດ້ຖືກວາງແຜນ ແລະຈັດຕັ້ງປະຕິບັດໃນ Ansible 2.9.
ອີງຕາມຄໍາຄຶດຄໍາເຫັນຈາກລູກຄ້າວິສາຫະກິດແລະຊຸມຊົນ, ມັນເປັນເຫດຜົນທໍາອິດທີ່ຈະຈັດການກັບໂມດູນເຫຼົ່ານັ້ນທີ່ກ່ຽວຂ້ອງກັບໂປໂຕຄອນເຄືອຂ່າຍ topology, virtualization, ແລະການໂຕ້ຕອບ.
ໂມດູນຊັບພະຍາກອນຕໍ່ໄປນີ້ຖືກພັດທະນາໂດຍທີມງານເຄືອຂ່າຍ Ansible ແລະສອດຄ່ອງກັບເວທີທີ່ສະຫນັບສະຫນູນໂດຍ Red Hat:

ໂມດູນຕໍ່ໄປນີ້ຖືກພັດທະນາໂດຍຊຸມຊົນ Ansible:

• exos_lldp_global - ຈາກ Extreme Networks.
• nxos_bfd_interfaces - ຈາກ Cisco
• nxos_telemetry - ຈາກ Cisco

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

ແຜນການສໍາລັບ Ansible 2.10 ແລະຫຼາຍກວ່ານັ້ນ

ເມື່ອ Ansible 2.9 ຖືກປ່ອຍອອກມາ, ພວກເຮົາຈະເຮັດວຽກຊຸດຕໍ່ໄປຂອງໂມດູນຊັບພະຍາກອນສໍາລັບ Ansible 2.10, ເຊິ່ງສາມາດຖືກນໍາໃຊ້ເພື່ອກໍານົດໂຄງສ້າງເຄືອຂ່າຍແລະນະໂຍບາຍເພີ່ມເຕີມ, e.g. ACL, OSPF ແລະ BGP. ແຜນພັດທະນາຍັງສາມາດປັບປ່ຽນໄດ້, ສະນັ້ນ ຖ້າເຈົ້າມີຄຳເຫັນກະລຸນາລາຍງານມາຍັງ ຊຸມຊົນເຄືອຂ່າຍ Ansible.

ຊັບພະຍາກອນແລະການເລີ່ມຕົ້ນ

ຖະແຫຼງຂ່າວກ່ຽວກັບ Ansible Automation Platform
ບລັອກເວທີອັດຕະໂນມັດ Ansible
ອະນາຄົດຂອງການຈັດສົ່ງເນື້ອຫາໃນ Ansible
ການສະທ້ອນເຖິງການປ່ຽນແປງໂຄງສ້າງໂຄງການ Ansible

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