ഇൻസൈഡ് പ്ലേബുക്ക്. പുതിയ അൻസിബിൾ എഞ്ചിനിലെ നെറ്റ്‌വർക്കിംഗ് സവിശേഷതകൾ 2.9

Red Hat Ansible Engine 2.9-ന്റെ വരാനിരിക്കുന്ന റിലീസ് ആവേശകരമായ മെച്ചപ്പെടുത്തലുകൾ കൊണ്ടുവരുന്നു, അവയിൽ ചിലത് ഈ ലേഖനത്തിൽ ഉൾപ്പെടുത്തിയിട്ടുണ്ട്. എല്ലായ്‌പ്പോഴും എന്നപോലെ, കമ്മ്യൂണിറ്റി പിന്തുണയോടെ ഞങ്ങൾ അൻസിബിൾ നെറ്റ്‌വർക്ക് മെച്ചപ്പെടുത്തലുകൾ പരസ്യമായി വികസിപ്പിക്കുന്നു. ഞങ്ങളോടൊപ്പം ചേരൂ - നോക്കൂ GitHub-ലെ ഇഷ്യൂ ബോർഡ് കൂടാതെ വികസന പദ്ധതി പഠിക്കുക Red Hat Ansible Engine 2.9-ന്റെ റിലീസ് എന്നതിനായുള്ള വിക്കി പേജിൽ അൻസിബിൾ നെറ്റ്‌വർക്ക്.

ഞങ്ങൾ അടുത്തിടെ പ്രഖ്യാപിച്ചതുപോലെ, Red Hat Ansible ഓട്ടോമേഷൻ പ്ലാറ്റ്ഫോം ഇപ്പോൾ അൻസിബിൾ ടവർ, അൻസിബിൾ എഞ്ചിൻ, എല്ലാ അൻസിബിൾ നെറ്റ്‌വർക്ക് ഉള്ളടക്കവും ഉൾപ്പെടുന്നു. ഇക്കാലത്ത്, ഏറ്റവും ജനപ്രിയമായ നെറ്റ്‌വർക്കിംഗ് പ്ലാറ്റ്‌ഫോമുകൾ നടപ്പിലാക്കുന്നത് അൻസിബിൾ മൊഡ്യൂളുകൾ വഴിയാണ്. ഉദാഹരണത്തിന്:

• അരിസ്റ്റ ഇഒഎസ്
• സിസ്കോ ഐഒഎസ്
• സിസ്കോ IOS XR
• സിസ്കോ NX-OS
• ജുനൈപ്പർ ജൂനോസ്
• VyOS

അൻസിബിൾ ഓട്ടോമേഷൻ സബ്‌സ്‌ക്രിപ്‌ഷനിലൂടെ Red Hat പൂർണ്ണമായും പിന്തുണയ്‌ക്കുന്ന പ്ലാറ്റ്‌ഫോമുകളുടെ പൂർണ്ണമായ ലിസ്‌റ്റിനായി, ഇവിടെ പ്രസിദ്ധീകരിച്ചു.

നമ്മൾ എന്താണ് പഠിച്ചത്

കഴിഞ്ഞ നാല് വർഷമായി, ഒരു നെറ്റ്‌വർക്ക് ഓട്ടോമേഷൻ പ്ലാറ്റ്‌ഫോം വികസിപ്പിക്കുന്നതിനെക്കുറിച്ച് ഞങ്ങൾ ധാരാളം കാര്യങ്ങൾ പഠിച്ചു. അത് ഞങ്ങളും പഠിച്ചു എങ്ങനെ പ്ലാറ്റ്ഫോം ആർട്ടിഫാക്റ്റുകൾ അൻസിബിൾ പ്ലേബുക്കുകളിലും അന്തിമ ഉപയോക്താക്കളുടെ റോളുകളിലും ഉപയോഗിക്കുന്നു. ഞങ്ങൾ കണ്ടെത്തിയത് ഇതാ:

• ഓർഗനൈസേഷനുകൾ ഒന്നിൽ നിന്ന് മാത്രമല്ല, നിരവധി വെണ്ടർമാരിൽ നിന്നും ഉപകരണങ്ങൾ ഓട്ടോമേറ്റ് ചെയ്യുന്നു.
• ഓട്ടോമേഷൻ ഒരു സാങ്കേതിക പ്രതിഭാസം മാത്രമല്ല, സാംസ്കാരികവും കൂടിയാണ്.
• ഓട്ടോമേഷൻ ഡിസൈനിന്റെ അടിസ്ഥാന വാസ്തുവിദ്യാ തത്വങ്ങൾ കാരണം നെറ്റ്‌വർക്കുകൾ സ്കെയിലിൽ ഓട്ടോമേറ്റ് ചെയ്യുന്നത് തോന്നുന്നതിനേക്കാൾ ബുദ്ധിമുട്ടാണ്.

ഒരു വർഷം മുമ്പ് ഞങ്ങളുടെ ദീർഘകാല വളർച്ചാ പദ്ധതികളെക്കുറിച്ച് ഞങ്ങൾ ചർച്ച ചെയ്തപ്പോൾ, ഞങ്ങളുടെ കോർപ്പറേറ്റ് ക്ലയന്റുകൾ ഇനിപ്പറയുന്നവ ആവശ്യപ്പെട്ടു:

• വസ്തുതാ ശേഖരണം മികച്ച നിലവാരം പുലർത്തുകയും എല്ലാ ഉപകരണങ്ങളിലും ഓട്ടോമേഷൻ വർക്ക്ഫ്ലോകളുമായി വിന്യസിക്കുകയും വേണം.
• ഉപകരണത്തിലെ കോൺഫിഗറേഷനുകൾ അപ്‌ഡേറ്റ് ചെയ്യുന്നത് സ്റ്റാൻഡേർഡ് ചെയ്യുകയും സ്ഥിരത പുലർത്തുകയും ചെയ്യേണ്ടത് ആവശ്യമാണ്, അതിനാൽ വസ്തുതകൾ ശേഖരിച്ച ശേഷം സൈക്കിളിന്റെ രണ്ടാം പകുതിയിൽ അൻസിബിൾ മൊഡ്യൂളുകൾ കൈകാര്യം ചെയ്യും.
• ഉപകരണ കോൺഫിഗറേഷൻ ഘടനാപരമായ ഡാറ്റയിലേക്ക് പരിവർത്തനം ചെയ്യുന്നതിന് ഞങ്ങൾക്ക് കർശനവും പിന്തുണയുള്ളതുമായ രീതികൾ ആവശ്യമാണ്. ഇതിന്റെ അടിസ്ഥാനത്തിൽ, നെറ്റ്‌വർക്ക് ഉപകരണത്തിൽ നിന്ന് സത്യത്തിന്റെ ഉറവിടം നീക്കാൻ കഴിയും.

വസ്തുത മെച്ചപ്പെടുത്തലുകൾ

അൻസിബിൾ ഉപയോഗിച്ച് നെറ്റ്‌വർക്ക് ഉപകരണങ്ങളിൽ നിന്ന് വസ്തുതകൾ ശേഖരിക്കുന്നത് പലപ്പോഴും ക്രമരഹിതമായി സംഭവിക്കുന്നു. വെബ്-അധിഷ്‌ഠിത പ്ലാറ്റ്‌ഫോമുകൾക്ക് വ്യത്യസ്ത അളവിലുള്ള വസ്തുതകൾ ശേഖരിക്കാനുള്ള കഴിവുകളുണ്ട്, പക്ഷേ അവയ്‌ക്ക് കീ-വാല്യൂ ജോഡികളിലെ ഡാറ്റയുടെ പ്രാതിനിധ്യം പാഴ്‌സ് ചെയ്യുന്നതിനും സ്റ്റാൻഡേർഡ് ചെയ്യുന്നതിനുമുള്ള പ്രവർത്തനക്ഷമത കുറവാണ്. വായിക്കുക ഒരു പോസ്റ്റ് വസ്തുതാപരമായ ഡാറ്റ വിശകലനം ചെയ്യുന്നതും നിലവാരം പുലർത്തുന്നതും എത്രത്തോളം ബുദ്ധിമുട്ടുള്ളതും വേദനാജനകവുമാണെന്ന് കെൻ സെലെൻസ.

അൻസിബിൾ നെറ്റ്‌വർക്ക് എഞ്ചിൻ റോളിൽ ഞങ്ങൾ പ്രവർത്തിക്കുന്നത് നിങ്ങൾ ശ്രദ്ധിച്ചിരിക്കാം. സ്വാഭാവികമായും, 24K ഡൗൺലോഡുകൾ പിന്നീട്, നെറ്റ്‌വർക്ക് എഞ്ചിൻ റോൾ, നെറ്റ്‌വർക്ക് ഓട്ടോമേഷൻ സാഹചര്യങ്ങൾക്കായി അൻസിബിൾ ഗാലക്‌സിയിലെ ഏറ്റവും ജനപ്രിയമായ അൻസിബിൾ റോളുകളിൽ ഒന്നായി മാറി. Ansible 2.8-ൽ എന്താണ് വേണ്ടതെന്ന് തയ്യാറാക്കാൻ ഞങ്ങൾ ഇതിൽ ഭൂരിഭാഗവും Ansible 2.9-ലേക്ക് നീക്കുന്നതിന് മുമ്പ്, കമാൻഡുകൾ പാഴ്‌സ് ചെയ്യാനും കമാൻഡുകൾ നിയന്ത്രിക്കാനും നെറ്റ്‌വർക്ക് ഉപകരണങ്ങൾക്കായി ഡാറ്റ ശേഖരിക്കാനും സഹായിക്കുന്ന ആദ്യ സെറ്റ് ടൂളുകൾ ഈ Ansible റോൾ നൽകി.

നെറ്റ്‌വർക്ക് എഞ്ചിൻ എങ്ങനെ ഉപയോഗിക്കണമെന്ന് നിങ്ങൾക്കറിയാമെങ്കിൽ, അൻസിബിളിൽ ഉപയോഗിക്കുന്നതിന് വസ്തുതാ ഡാറ്റ ശേഖരിക്കുന്നതിനും പാഴ്‌സ് ചെയ്യുന്നതിനും സ്റ്റാൻഡേർഡ് ചെയ്യുന്നതിനുമുള്ള വളരെ കാര്യക്ഷമമായ മാർഗമാണിത്. ഈ റോളിന്റെ പോരായ്മ, ഓരോ പ്ലാറ്റ്‌ഫോമിനും എല്ലാ നെറ്റ്‌വർക്ക് പ്രവർത്തനങ്ങൾക്കുമായി നിങ്ങൾ ഒരു കൂട്ടം പാഴ്‌സറുകൾ സൃഷ്ടിക്കേണ്ടതുണ്ട് എന്നതാണ്. പാഴ്‌സറുകൾ സൃഷ്‌ടിക്കുകയും ഷിപ്പുചെയ്യുകയും പരിപാലിക്കുകയും ചെയ്യുന്നത് എത്ര ബുദ്ധിമുട്ടാണെന്ന് മനസിലാക്കാൻ, ഒന്ന് നോക്കൂ 1200-ലധികം പാഴ്‌സറുകൾ സിസ്‌കോയിലെ ആൺകുട്ടികളിൽ നിന്ന്.

ചുരുക്കത്തിൽ, ഉപകരണങ്ങളിൽ നിന്ന് വസ്തുതകൾ നേടുകയും അവയെ കീ-വാല്യൂ ജോഡികളാക്കി നോർമലൈസ് ചെയ്യുകയും ചെയ്യുന്നത് സ്കെയിലിൽ ഓട്ടോമേഷന് അത്യാവശ്യമാണ്, എന്നാൽ നിങ്ങൾക്ക് ധാരാളം വെണ്ടർമാരും നെറ്റ്‌വർക്ക് പ്ലാറ്റ്‌ഫോമുകളും ഉള്ളപ്പോൾ ഇത് നേടുന്നത് ബുദ്ധിമുട്ടാണ്.

അൻസിബിൾ 2.9 ലെ ഓരോ നെറ്റ്‌വർക്ക് ഫാക്‌ട് മൊഡ്യൂളിനും ഇപ്പോൾ ഒരു നെറ്റ്‌വർക്ക് ഉപകരണത്തിന്റെ കോൺഫിഗറേഷൻ വിശകലനം ചെയ്യാനും ഘടനാപരമായ ഡാറ്റ തിരികെ നൽകാനും കഴിയും - അധിക ലൈബ്രറികളോ അൻസിബിൾ റോളുകളോ ഇഷ്‌ടാനുസൃത പാഴ്‌സറുകളോ ഇല്ലാതെ.

Ansible 2.9 മുതൽ, ഓരോ തവണയും അപ്‌ഡേറ്റ് ചെയ്ത നെറ്റ്‌വർക്ക് മൊഡ്യൂൾ റിലീസ് ചെയ്യുമ്പോൾ, കോൺഫിഗറേഷന്റെ ഈ വിഭാഗത്തെക്കുറിച്ചുള്ള ഡാറ്റ നൽകുന്നതിന് ഫാക്‌ട് മൊഡ്യൂൾ മെച്ചപ്പെടുത്തുന്നു. അതായത്, വസ്തുതകളുടെയും മൊഡ്യൂളുകളുടെയും വികസനം ഇപ്പോൾ ഒരേ വേഗതയിൽ സംഭവിക്കുന്നു, അവയ്ക്ക് എല്ലായ്പ്പോഴും ഒരു പൊതു ഡാറ്റ ഘടന ഉണ്ടായിരിക്കും.

ഒരു നെറ്റ്‌വർക്ക് ഉപകരണത്തിലെ ഉറവിടങ്ങളുടെ കോൺഫിഗറേഷൻ വീണ്ടെടുക്കാനും ഘടനാപരമായ ഡാറ്റയായി പരിവർത്തനം ചെയ്യാനും രണ്ട് വഴികളിലൂടെ കഴിയും. രണ്ട് വഴികളിലും, നിങ്ങൾക്ക് ഒരു പുതിയ കീവേഡ് ഉപയോഗിച്ച് ഉറവിടങ്ങളുടെ ഒരു പ്രത്യേക ലിസ്റ്റ് ശേഖരിക്കാനും രൂപാന്തരപ്പെടുത്താനും കഴിയും gather_network_resources. റിസോഴ്സ് പേരുകൾ മൊഡ്യൂൾ പേരുകളുമായി പൊരുത്തപ്പെടുന്നു, അത് വളരെ സൗകര്യപ്രദമാണ്.

വസ്തുതകൾ ശേഖരിക്കുമ്പോൾ:

ഒരു കീവേഡ് ഉപയോഗിക്കുന്നു gather_facts പ്ലേബുക്കിന്റെ തുടക്കത്തിൽ നിങ്ങൾക്ക് നിലവിലെ ഉപകരണ കോൺഫിഗറേഷൻ വീണ്ടെടുക്കാം, തുടർന്ന് അത് മുഴുവൻ പ്ലേബുക്കിലും ഉപയോഗിക്കാം. ഉപകരണത്തിൽ നിന്ന് വീണ്ടെടുക്കേണ്ട വ്യക്തിഗത ഉറവിടങ്ങൾ വ്യക്തമാക്കുക.

- 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

പ്ലേബുക്ക് ഇന്റർഫേസിനെക്കുറിച്ചുള്ള ഇനിപ്പറയുന്ന വസ്തുതകൾ നൽകുന്നു:

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

Arista ഉപകരണത്തിൽ നിന്ന് അൻസിബിൾ നേറ്റീവ് കോൺഫിഗറേഷൻ വീണ്ടെടുക്കുന്നതും ഡൗൺസ്‌ട്രീം ടാസ്‌ക്കുകൾക്കും ഓപ്പറേഷനുകൾക്കുമായി സ്റ്റാൻഡേർഡ് കീ-വാല്യൂ ജോഡികളായി ഉപയോഗിക്കുന്നതിന് ഘടനാപരമായ ഡാറ്റയാക്കി മാറ്റുന്നത് എങ്ങനെയെന്ന് ശ്രദ്ധിക്കുക.

ഇന്റർഫേസ് വസ്തുതകൾ അൻസിബിൾ സംഭരിച്ച വേരിയബിളുകളിലേക്ക് ചേർക്കാനും റിസോഴ്സ് മൊഡ്യൂളിലേക്കുള്ള ഇൻപുട്ടായി ഉടനടി അല്ലെങ്കിൽ പിന്നീട് ഉപയോഗിക്കാനും കഴിയും. eos_interfaces അധിക പ്രോസസ്സിംഗ് അല്ലെങ്കിൽ പരിവർത്തനം ഇല്ലാതെ.

റിസോഴ്സ് മൊഡ്യൂളുകൾ

അതിനാൽ, ഞങ്ങൾ വസ്‌തുതകൾ എക്‌സ്‌ട്രാക്‌റ്റ് ചെയ്‌തു, ഡാറ്റ നോർമലൈസ് ചെയ്‌തു, അവയെ ഒരു സ്റ്റാൻഡേർഡ് ഇന്റേണൽ ഡാറ്റാ സ്‌ട്രക്‌ചർ ഡയഗ്രാമിലേക്ക് ഘടിപ്പിക്കുകയും സത്യത്തിന്റെ ഒരു റെഡിമെയ്ഡ് ഉറവിടം ലഭിക്കുകയും ചെയ്‌തു. ഹൂറേ! തീർച്ചയായും ഇത് വളരെ മികച്ചതാണ്, പക്ഷേ ഞങ്ങൾ ഇപ്പോഴും കീ-വാല്യൂ ജോഡികളെ നിർദ്ദിഷ്ട ഉപകരണ പ്ലാറ്റ്ഫോം പ്രതീക്ഷിക്കുന്ന നിർദ്ദിഷ്ട കോൺഫിഗറേഷനിലേക്ക് എങ്ങനെയെങ്കിലും പരിവർത്തനം ചെയ്യേണ്ടതുണ്ട്. ഈ പുതിയ വസ്തുത ശേഖരണത്തിനും സാധാരണവൽക്കരണത്തിനും ആവശ്യമായ പ്ലാറ്റ്‌ഫോം-നിർദ്ദിഷ്ട മൊഡ്യൂളുകൾ ഞങ്ങൾക്ക് ഇപ്പോൾ ആവശ്യമാണ്.

എന്താണ് ഒരു റിസോഴ്സ് മൊഡ്യൂൾ? ഒരു ഉപകരണത്തിന്റെ കോൺഫിഗറേഷൻ വിഭാഗങ്ങളെ ആ ഉപകരണം നൽകുന്ന ഉറവിടങ്ങളായി നിങ്ങൾക്ക് ചിന്തിക്കാം. നെറ്റ്‌വർക്ക് റിസോഴ്‌സ് മൊഡ്യൂളുകൾ മനഃപൂർവ്വം ഒരൊറ്റ റിസോഴ്‌സിലേക്ക് പരിമിതപ്പെടുത്തിയിരിക്കുന്നു കൂടാതെ സങ്കീർണ്ണമായ നെറ്റ്‌വർക്ക് സേവനങ്ങൾ ക്രമീകരിക്കുന്നതിന് ബിൽഡിംഗ് ബ്ലോക്കുകൾ പോലെ അടുക്കിവെക്കാനും കഴിയും. തൽഫലമായി, റിസോഴ്‌സ് മൊഡ്യൂളിന് വായിക്കാൻ കഴിയുന്നതിനാൽ, ഒരു റിസോഴ്‌സ് മൊഡ്യൂളിന്റെ ആവശ്യകതകളും സ്പെസിഫിക്കേഷനും സ്വാഭാവികമായും ലളിതമാക്കിയിരിക്കുന്നു. и ഒരു നെറ്റ്‌വർക്ക് ഉപകരണത്തിൽ ഒരു പ്രത്യേക നെറ്റ്‌വർക്ക് സേവനം കോൺഫിഗർ ചെയ്യുക.

ഒരു റിസോഴ്‌സ് മൊഡ്യൂൾ എന്താണ് ചെയ്യുന്നതെന്ന് വിശദീകരിക്കാൻ, പുതിയ നെറ്റ്‌വർക്ക് റിസോഴ്‌സ് വസ്തുതകളും മൊഡ്യൂളും ഉപയോഗിച്ച് ഒരു ഇഡെമ്പൊഡന്റ് ഓപ്പറേഷൻ കാണിക്കുന്ന ഒരു ഉദാഹരണ പ്ലേബുക്ക് നോക്കാം. 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

നിങ്ങൾക്ക് കാണാനാകുന്നതുപോലെ, ഉപകരണത്തിൽ നിന്ന് ശേഖരിച്ച ഡാറ്റ പരിവർത്തനം ചെയ്യാതെ തന്നെ അനുബന്ധ റിസോഴ്സ് മൊഡ്യൂളിലേക്ക് നേരിട്ട് കൈമാറുന്നു. സമാരംഭിക്കുമ്പോൾ, പ്ലേബുക്ക് ഉപകരണത്തിൽ നിന്ന് മൂല്യങ്ങൾ വീണ്ടെടുക്കുകയും പ്രതീക്ഷിക്കുന്ന മൂല്യങ്ങളുമായി താരതമ്യം ചെയ്യുകയും ചെയ്യുന്നു. ഈ ഉദാഹരണത്തിൽ, മടങ്ങിയ മൂല്യങ്ങൾ പ്രതീക്ഷിച്ചതുപോലെയാണ് (അതായത്, ഇത് കോൺഫിഗറേഷൻ വ്യതിയാനങ്ങൾക്കായി പരിശോധിക്കുന്നു) കൂടാതെ കോൺഫിഗറേഷൻ മാറിയിട്ടുണ്ടോ എന്ന് റിപ്പോർട്ടുചെയ്യുന്നു.

കോൺഫിഗറേഷൻ ഡ്രിഫ്റ്റ് കണ്ടെത്തുന്നതിനുള്ള ഏറ്റവും അനുയോജ്യമായ മാർഗ്ഗം, വസ്തുതകൾ അൻസിബിൾ സംഭരിച്ച വേരിയബിളുകളിൽ സംഭരിക്കുകയും പരിശോധന മോഡിൽ റിസോഴ്സ് മൊഡ്യൂളിനൊപ്പം ഇടയ്ക്കിടെ ഉപയോഗിക്കുകയുമാണ്. മൂല്യങ്ങൾ ആരെങ്കിലും സ്വമേധയാ മാറ്റിയിട്ടുണ്ടോ എന്ന് കാണാനുള്ള ഒരു ലളിതമായ രീതിയാണിത്. മിക്ക കേസുകളിലും, ഓർഗനൈസേഷനുകൾ മാറ്റങ്ങളും കോൺഫിഗറേഷനും സ്വമേധയാ അനുവദിക്കുന്നു, എന്നിരുന്നാലും നിരവധി പ്രവർത്തനങ്ങൾ അൻസിബിൾ ഓട്ടോമേഷൻ വഴിയാണ് നടത്തുന്നത്.

പുതിയ റിസോഴ്സ് മൊഡ്യൂളുകൾ മുമ്പത്തേതിൽ നിന്ന് എങ്ങനെ വ്യത്യാസപ്പെട്ടിരിക്കുന്നു?

ഒരു നെറ്റ്‌വർക്ക് ഓട്ടോമേഷൻ എഞ്ചിനീയർക്ക്, അൻസിബിൾ 3-ലെയും മുമ്പത്തെ പതിപ്പുകളിലെയും റിസോഴ്‌സ് മൊഡ്യൂളുകൾ തമ്മിൽ 2.9 പ്രധാന വ്യത്യാസങ്ങളുണ്ട്.

1) നൽകിയിരിക്കുന്ന ഒരു നെറ്റ്‌വർക്ക് റിസോഴ്‌സിന് (ഇത് ഒരു കോൺഫിഗറേഷൻ വിഭാഗമായും കണക്കാക്കാം), മൊഡ്യൂളുകളും വസ്തുതകളും പിന്തുണയ്‌ക്കുന്ന എല്ലാ നെറ്റ്‌വർക്ക് ഓപ്പറേറ്റിംഗ് സിസ്റ്റങ്ങളിലും ഒരേസമയം വികസിക്കും. ഒരു നെറ്റ്‌വർക്ക് പ്ലാറ്റ്‌ഫോമിൽ റിസോഴ്‌സ് കോൺഫിഗറേഷനെ അൻസിബിൾ പിന്തുണയ്‌ക്കുകയാണെങ്കിൽ, ഞങ്ങൾ അതിനെ എല്ലായിടത്തും പിന്തുണയ്‌ക്കണമെന്ന് ഞങ്ങൾ കരുതുന്നു. ഇത് റിസോഴ്‌സ് മൊഡ്യൂളുകളുടെ ഉപയോഗം ലളിതമാക്കുന്നു, കാരണം ഒരു നെറ്റ്‌വർക്ക് ഓട്ടോമേഷൻ എഞ്ചിനീയർക്ക് ഇപ്പോൾ എല്ലാ നെറ്റ്‌വർക്ക് ഓപ്പറേറ്റിംഗ് സിസ്റ്റങ്ങളിലും നേറ്റീവ്, പിന്തുണയുള്ള മൊഡ്യൂളുകൾ ഉപയോഗിച്ച് ഒരു റിസോഴ്‌സ് (എൽഎൽഡിപി പോലുള്ളവ) കോൺഫിഗർ ചെയ്യാൻ കഴിയും.

2) റിസോഴ്സ് മൊഡ്യൂളുകളിൽ ഇപ്പോൾ ഒരു സംസ്ഥാന മൂല്യം ഉൾപ്പെടുന്നു.

• merged: കോൺഫിഗറേഷൻ നൽകിയിരിക്കുന്ന കോൺഫിഗറേഷനുമായി ലയിപ്പിച്ചിരിക്കുന്നു (സ്ഥിരസ്ഥിതി);
• replaced: റിസോഴ്സ് കോൺഫിഗറേഷൻ നൽകിയ കോൺഫിഗറേഷൻ ഉപയോഗിച്ച് മാറ്റിസ്ഥാപിക്കും;
• overridden: റിസോഴ്സ് കോൺഫിഗറേഷൻ നൽകിയ കോൺഫിഗറേഷൻ ഉപയോഗിച്ച് മാറ്റിസ്ഥാപിക്കും; അനാവശ്യ റിസോഴ്സ് സംഭവങ്ങൾ ഇല്ലാതാക്കപ്പെടും;
• deleted: റിസോഴ്സ് കോൺഫിഗറേഷൻ ഇല്ലാതാക്കപ്പെടും/ഡിഫോൾട്ടായി പുനഃസ്ഥാപിക്കും.

3) റിസോഴ്സ് മൊഡ്യൂളുകളിൽ ഇപ്പോൾ സ്ഥിരമായ റിട്ടേൺ മൂല്യങ്ങൾ ഉൾപ്പെടുന്നു. നെറ്റ്‌വർക്ക് റിസോഴ്‌സ് മൊഡ്യൂൾ നെറ്റ്‌വർക്ക് ഉപകരണത്തിൽ ആവശ്യമായ മാറ്റങ്ങൾ വരുത്തുമ്പോൾ (അല്ലെങ്കിൽ നിർദ്ദേശിച്ചിരിക്കുന്നു), അത് പ്ലേബുക്കിലേക്ക് അതേ കീ-വാല്യൂ ജോഡികൾ നൽകുന്നു.

• before: ടാസ്ക്കിന് മുമ്പുള്ള ഘടനാപരമായ ഡാറ്റയുടെ രൂപത്തിൽ ഉപകരണത്തിലെ കോൺഫിഗറേഷൻ;
• after: ഉപകരണം മാറിയിട്ടുണ്ടെങ്കിൽ (അല്ലെങ്കിൽ ടെസ്റ്റ് മോഡ് ഉപയോഗിക്കുകയാണെങ്കിൽ മാറിയേക്കാം), തത്ഫലമായുണ്ടാകുന്ന കോൺഫിഗറേഷൻ ഘടനാപരമായ ഡാറ്റയായി നൽകും;
• commands: ഏത് കോൺഫിഗറേഷൻ കമാൻഡുകളും ഉപകരണത്തെ ആവശ്യമുള്ള അവസ്ഥയിലേക്ക് കൊണ്ടുവരാൻ അതിൽ പ്രവർത്തിക്കുന്നു.

ഇതെല്ലാം എന്താണ് അർത്ഥമാക്കുന്നത്? എന്തുകൊണ്ട് അത് പ്രധാനമാണ്?

ഈ കുറിപ്പ് വളരെയധികം സങ്കീർണ്ണമായ ആശയങ്ങൾ ഉൾക്കൊള്ളുന്നു, എന്നാൽ ഒരു ഓട്ടോമേഷൻ പ്ലാറ്റ്‌ഫോമിനായുള്ള യഥാർത്ഥ ശേഖരണം, ഡാറ്റ നോർമലൈസേഷൻ, ലൂപ്പ് കോൺഫിഗറേഷൻ എന്നിവയിൽ എന്റർപ്രൈസ് ക്ലയന്റുകൾ എന്താണ് ആവശ്യപ്പെടുന്നത് എന്നതിനെക്കുറിച്ച് അവസാനം നിങ്ങൾക്ക് നന്നായി മനസ്സിലാക്കാൻ കഴിയുമെന്ന് ഞങ്ങൾ പ്രതീക്ഷിക്കുന്നു. എന്നാൽ എന്തുകൊണ്ടാണ് അവർക്ക് ഈ മെച്ചപ്പെടുത്തലുകൾ ആവശ്യമായി വരുന്നത്? പല ഓർഗനൈസേഷനുകളും ഇപ്പോൾ തങ്ങളുടെ ഐടി പരിതസ്ഥിതികളെ കൂടുതൽ ചടുലവും മത്സരപരവുമാക്കാൻ ഡിജിറ്റൽ പരിവർത്തനം പിന്തുടരുന്നു. നല്ലതോ ചീത്തയോ ആയാലും, പല നെറ്റ്‌വർക്ക് എഞ്ചിനീയർമാരും നെറ്റ്‌വർക്ക് ഡെവലപ്പർമാരാകുന്നത് ഒന്നുകിൽ സ്വന്തം താൽപ്പര്യം കൊണ്ടോ മാനേജ്‌മെന്റിന്റെ നിർദ്ദേശപ്രകാരമോ ആണ്.

വ്യക്തിഗത നെറ്റ്‌വർക്ക് ടെംപ്ലേറ്റുകൾ ഓട്ടോമേറ്റ് ചെയ്യുന്നത് സിലോസിന്റെ പ്രശ്നം പരിഹരിക്കില്ലെന്നും ഒരു പരിധിവരെ കാര്യക്ഷമത വർദ്ധിപ്പിക്കുമെന്നും ഓർഗനൈസേഷനുകൾ മനസ്സിലാക്കുന്നു. Red Hat Ansible Automation പ്ലാറ്റ്‌ഫോം ഒരു നെറ്റ്‌വർക്ക് ഉപകരണത്തിലെ അടിസ്ഥാന ഡാറ്റ പ്രോഗ്രമാറ്റിക്കായി കൈകാര്യം ചെയ്യുന്നതിനായി കർശനവും മാനദണ്ഡവുമായ റിസോഴ്‌സ് ഡാറ്റ മോഡലുകൾ നൽകുന്നു. അതായത്, ഉപയോക്താക്കൾ വ്യക്തിഗത കോൺഫിഗറേഷൻ രീതികൾ ക്രമേണ ഉപേക്ഷിക്കുന്നു, കൂടുതൽ ആധുനിക രീതികൾക്ക് അനുകൂലമായി സാങ്കേതികവിദ്യകൾക്ക് ഊന്നൽ നൽകുന്നു (ഉദാഹരണത്തിന്, IP വിലാസങ്ങൾ, VLAN-കൾ, LLDP മുതലായവ), ഒരു പ്രത്യേക വെണ്ടർ നടപ്പിലാക്കുന്നതിനുപകരം.

വിശ്വസനീയവും തെളിയിക്കപ്പെട്ടതുമായ കമാൻഡ് മൊഡ്യൂളുകളുടെയും കോൺഫിഗറേഷന്റെയും ദിവസങ്ങൾ എണ്ണപ്പെട്ടു എന്നാണോ ഇതിനർത്ഥം? ഒരു സാഹചര്യത്തിലും. പ്രതീക്ഷിക്കുന്ന നെറ്റ്‌വർക്ക് റിസോഴ്‌സ് മൊഡ്യൂളുകൾ എല്ലാ സാഹചര്യങ്ങളിലും അല്ലെങ്കിൽ എല്ലാ വെണ്ടർമാർക്കും ബാധകമാകില്ല, അതിനാൽ ചില നിർവ്വഹണങ്ങൾക്ക് നെറ്റ്‌വർക്ക് എഞ്ചിനീയർമാർക്ക് കമാൻഡും കോൺഫിഗറേഷൻ മൊഡ്യൂളുകളും ആവശ്യമായി വരും. വലിയ ജിഞ്ച ടെംപ്ലേറ്റുകൾ ലളിതമാക്കുകയും ഘടനാപരമായ JSON ഫോർമാറ്റിലേക്ക് ഘടനയില്ലാത്ത ഉപകരണ കോൺഫിഗറേഷനുകൾ സാധാരണമാക്കുകയും ചെയ്യുക എന്നതാണ് റിസോഴ്സ് മൊഡ്യൂളുകളുടെ ലക്ഷ്യം. റിസോഴ്‌സ് മൊഡ്യൂളുകൾ ഉപയോഗിച്ച്, നിലവിലുള്ള നെറ്റ്‌വർക്കുകൾക്ക് അവയുടെ കോൺഫിഗറേഷനെ ഘടനാപരമായ കീ-വാല്യൂ ജോഡികളാക്കി മാറ്റുന്നത് എളുപ്പമായിരിക്കും, അത് സത്യത്തിന്റെ എളുപ്പത്തിൽ വായിക്കാവുന്ന ഉറവിടത്തെ പ്രതിനിധീകരിക്കുന്നു. ഘടനാപരമായ കീ-മൂല്യം ജോഡികൾ ഉപയോഗിക്കുന്നതിലൂടെ, നിങ്ങൾക്ക് ഓരോ ഉപകരണത്തിലും പ്രവർത്തിക്കുന്ന കോൺഫിഗറേഷനുകളിൽ നിന്ന് സ്വതന്ത്ര ഘടനാപരമായ ഡാറ്റയുമായി പ്രവർത്തിക്കാനും നെറ്റ്‌വർക്കുകളെ ഒരു ഇൻഫ്രാസ്ട്രക്ചർ കോഡ് സമീപനത്തിന്റെ മുൻനിരയിലേക്ക് കൊണ്ടുവരാനും കഴിയും.

അൻസിബിൾ എഞ്ചിൻ 2.9 ൽ എന്ത് റിസോഴ്സ് മൊഡ്യൂളുകളാണ് വരുന്നത്?

അൻസിബിൾ 2.9-ൽ എന്ത് സംഭവിക്കുമെന്ന് ഞങ്ങൾ നിങ്ങളോട് വിശദമായി പറയുന്നതിന് മുമ്പ്, ജോലിയുടെ മുഴുവൻ വ്യാപ്തിയും ഞങ്ങൾ എങ്ങനെ വിഭജിച്ചുവെന്ന് ഓർക്കുക.

ഞങ്ങൾ 7 വിഭാഗങ്ങൾ തിരിച്ചറിയുകയും ഓരോന്നിനും പ്രത്യേക നെറ്റ്‌വർക്ക് ഉറവിടങ്ങൾ നൽകുകയും ചെയ്തു:

ശ്രദ്ധിക്കുക: ബോൾഡിലുള്ള ഉറവിടങ്ങൾ Ansible 2.9-ൽ ആസൂത്രണം ചെയ്യുകയും നടപ്പിലാക്കുകയും ചെയ്തു.
എന്റർപ്രൈസ് ഉപഭോക്താക്കളിൽ നിന്നും കമ്മ്യൂണിറ്റിയിൽ നിന്നുമുള്ള ഫീഡ്‌ബാക്ക് അടിസ്ഥാനമാക്കി, നെറ്റ്‌വർക്ക് ടോപ്പോളജി പ്രോട്ടോക്കോളുകൾ, വിർച്ച്വലൈസേഷൻ, ഇന്റർഫേസുകൾ എന്നിവയുമായി ബന്ധപ്പെട്ട മൊഡ്യൂളുകൾ ആദ്യം കൈകാര്യം ചെയ്യുന്നത് യുക്തിസഹമായിരുന്നു.
ഇനിപ്പറയുന്ന റിസോഴ്‌സ് മൊഡ്യൂളുകൾ അൻസിബിൾ നെറ്റ്‌വർക്ക് ടീം വികസിപ്പിച്ചെടുത്തു കൂടാതെ Red Hat പിന്തുണയ്ക്കുന്ന പ്ലാറ്റ്‌ഫോമുകളുമായി പൊരുത്തപ്പെടുന്നു:

ഇനിപ്പറയുന്ന മൊഡ്യൂളുകൾ അൻസിബിൾ കമ്മ്യൂണിറ്റി വികസിപ്പിച്ചെടുത്തതാണ്:

• exos_lldp_global - എക്സ്ട്രീം നെറ്റ്‌വർക്കുകളിൽ നിന്ന്.
• nxos_bfd_interfaces - സിസ്കോയിൽ നിന്ന്
• nxos_telemetry - സിസ്കോയിൽ നിന്ന്

നിങ്ങൾക്ക് കാണാനാകുന്നതുപോലെ, റിസോഴ്സ് മൊഡ്യൂളുകൾ എന്ന ആശയം ഞങ്ങളുടെ പ്ലാറ്റ്ഫോം കേന്ദ്രീകൃത തന്ത്രവുമായി യോജിക്കുന്നു. അതായത്, നെറ്റ്‌വർക്ക് മൊഡ്യൂളുകളുടെ വികസനത്തിൽ സ്റ്റാൻഡേർഡൈസേഷനെ പിന്തുണയ്ക്കുന്നതിനും അൻസിബിൾ റോളുകളുടെയും പ്ലേബുക്കുകളുടെയും തലത്തിൽ ഉപയോക്താക്കളുടെ ജോലി ലളിതമാക്കുന്നതിനും ആവശ്യമായ കഴിവുകളും പ്രവർത്തനങ്ങളും ഞങ്ങൾ അൻസിബിളിൽ തന്നെ ഉൾപ്പെടുത്തുന്നു. റിസോഴ്സ് മൊഡ്യൂളുകളുടെ വികസനം വിപുലീകരിക്കുന്നതിന്, അൻസിബിൾ ടീം മൊഡ്യൂൾ ബിൽഡർ ടൂൾ പുറത്തിറക്കി.

അൻസിബിൾ 2.10-നും അതിനുശേഷമുള്ള പ്ലാനുകൾ

അൻസിബിൾ 2.9 റിലീസ് ചെയ്‌തുകഴിഞ്ഞാൽ, ഞങ്ങൾ അൻസിബിൾ 2.10-നുള്ള അടുത്ത റിസോഴ്‌സ് മൊഡ്യൂളുകളിൽ പ്രവർത്തിക്കും, അത് നെറ്റ്‌വർക്ക് ടോപ്പോളജിയും പോളിസിയും കൂടുതൽ കോൺഫിഗർ ചെയ്യാൻ ഉപയോഗിക്കാം, ഉദാ. ACL, OSPF, BGP. വികസന പദ്ധതി ഇപ്പോഴും ക്രമീകരിക്കാൻ കഴിയും, അതിനാൽ നിങ്ങൾക്ക് അഭിപ്രായങ്ങളുണ്ടെങ്കിൽ, അത് അറിയിക്കുക അൻസിബിൾ നെറ്റ്‌വർക്ക് കമ്മ്യൂണിറ്റി.

വിഭവങ്ങളും ആരംഭിക്കലും

അൻസിബിൾ ഓട്ടോമേഷൻ പ്ലാറ്റ്‌ഫോമിനെക്കുറിച്ചുള്ള പ്രസ് റിലീസ്
അൻസിബിൾ ഓട്ടോമേഷൻ പ്ലാറ്റ്ഫോം ബ്ലോഗ്
അൻസിബിളിലെ ഉള്ളടക്ക വിതരണത്തിന്റെ ഭാവി
അൻസിബിൾ പ്രോജക്റ്റ് ഘടന മാറ്റുന്നതിനുള്ള പ്രതിഫലനങ്ങൾ

അവലംബം: www.habr.com