The Inside Playbook. Ցանցի գործառույթները նոր Ansible Engine 2.9-ում

Red Hat Ansible Engine 2.9-ի առաջիկա թողարկումը բերում է հետաքրքիր բարելավումներ, որոնցից մի քանիսը քննարկվում են այս հոդվածում: Ինչպես միշտ, մենք բացահայտ կերպով զարգացնում ենք Ansible Network-ի բարելավումները՝ համայնքի աջակցությամբ: Միացե՛ք մեզ - նայե՛ք թողարկման տախտակ GitHub-ում և ուսումնասիրել զարգացման ծրագիրը Red Hat Ansible Engine 2.9-ի թողարկումը համար վիքի էջում Ansible ցանց.

Ինչպես վերջերս հայտարարել էինք, Red Hat Ansible ավտոմատացման պլատֆորմ այժմ ներառում է Ansible Tower, Ansible Engine և Ansible Network-ի ողջ բովանդակությունը: Մեր օրերում ամենատարածված ցանցային հարթակներն իրականացվում են Ansible մոդուլների միջոցով: Օրինակ:

• Արիստա EOS
• Cisco IOS- ը
• Cisco IOS XR
• Cisco NX-OS
• Juniper Junos
• VyOS

Պլատֆորմների ամբողջական ցանկի համար, որոնք լիովին աջակցվում են Red Hat-ի կողմից Ansible Automation բաժանորդագրության միջոցով, հրապարակված այստեղ.

Ինչ ենք մենք սովորել

Վերջին չորս տարիների ընթացքում մենք շատ բան ենք սովորել ցանցային ավտոմատացման հարթակի մշակման մասին: Մենք էլ դա իմացանք ինչպես պլատֆորմի արտեֆակտները օգտագործվում են Ansible խաղային գրքերում և դերերում վերջնական օգտագործողների կողմից: Եվ ահա թե ինչ պարզեցինք.

• Կազմակերպությունները ավտոմատացնում են սարքերը ոչ միայն մեկ, այլ բազմաթիվ վաճառողներից:
• Ավտոմատացումը ոչ միայն տեխնիկական, այլեւ մշակութային երեւույթ է։
• Մասշտաբով ցանցերի ավտոմատացումն ավելի դժվար է, քան թվում է, պայմանավորված ավտոմատացման նախագծման հիմնարար ճարտարապետական ​​սկզբունքներով:

Երբ մենք քննարկեցինք մեր երկարաժամկետ աճի պլանները ավելի քան մեկ տարի առաջ, մեր կորպորատիվ հաճախորդները խնդրեցին հետևյալը.

• Փաստերի հավաքագրումը պետք է ավելի լավ ստանդարտացվի և համապատասխանեցվի բոլոր սարքերի ավտոմատացման աշխատանքային հոսքերին:
• Սարքի կոնֆիգուրացիաների թարմացումը նույնպես պետք է լինի ստանդարտացված և հետևողական, որպեսզի Ansible մոդուլները կարգավորեն ցիկլի երկրորդ կեսը փաստեր հավաքելուց հետո:
• Մեզ անհրաժեշտ են խիստ և աջակցվող մեթոդներ՝ սարքի կոնֆիգուրացիան կառուցվածքային տվյալների վերածելու համար: Այս հիման վրա ճշմարտության աղբյուրը կարող է տեղափոխվել ցանցային սարքից:

Փաստերի բարելավումներ

Ansible-ի միջոցով ցանցային սարքերից փաստեր հավաքելը հաճախ պատահական է լինում: Վեբ վրա հիմնված հարթակներն ունեն տարբեր աստիճանի փաստեր հավաքելու հնարավորություններ, սակայն դրանք չունեն կամ չունեն ֆունկցիոնալություն՝ վերլուծելու և ստանդարտացնելու տվյալների ներկայացումը բանալի-արժեք զույգերով: Կարդացեք գրառում Քեն Սելենզան այն մասին, թե որքան դժվար և ցավոտ կարող է լինել փաստացի տվյալների վերլուծությունն ու ստանդարտացումը:

Դուք կարող եք նկատել, որ մենք աշխատում ենք Ansible Network Engine-ի դերի վրա: Բնականաբար, ավելի ուշ 24K ներլցումներ, Ցանցային շարժիչի դերը արագորեն դարձավ Ansible Galaxy-ի ամենահայտնի Ansible դերերից մեկը ցանցային ավտոմատացման սցենարների համար: Մինչ մենք դրա մեծ մասը տեղափոխեցինք Ansible 2.8՝ պատրաստվելու այն ամենին, ինչ անհրաժեշտ կլինի Ansible 2.9-ում, այս Ansible դերը տրամադրեց գործիքների առաջին փաթեթը, որը կօգնի վերլուծել հրամանները, կառավարել հրամանները և հավաքել տվյալներ ցանցային սարքերի համար:

Եթե ​​դուք գիտեք, թե ինչպես օգտագործել Network Engine-ը, սա շատ արդյունավետ միջոց է՝ հավաքելու, վերլուծելու և ստանդարտացնելու փաստերի տվյալները Ansible-ում օգտագործելու համար: Այս դերի թերությունն այն է, որ դուք պետք է ստեղծեք վերլուծիչների մի ամբողջ փունջ յուրաքանչյուր հարթակի և ցանցի ողջ գործունեության համար: Հասկանալու համար, թե որքան դժվար է վերլուծիչներ ստեղծելը, առաքելը և պահպանելը, նայեք Ավելի քան 1200 վերլուծիչ Cisco-ի տղաներից:

Մի խոսքով, սարքերից փաստեր ստանալը և դրանք առանցքային արժեքների զույգերի նորմալացումը կարևոր է մասշտաբով ավտոմատացման համար, բայց դրան հասնելը դժվար է, երբ ունես բազմաթիվ վաճառողներ և ցանցային հարթակներ:

Ansible 2.9-ի ցանցային փաստերի յուրաքանչյուր մոդուլ այժմ կարող է վերլուծել ցանցային սարքի կոնֆիգուրացիան և վերադարձնել կառուցվածքային տվյալներ՝ առանց լրացուցիչ գրադարանների, Ansible դերերի կամ հատուկ վերլուծիչների:

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

Ուշադրություն դարձրեք, թե ինչպես է Ansible-ն առբերում բնիկ կոնֆիգուրացիան Arista սարքից և այն վերածում կառուցվածքային տվյալների՝ որպես ստանդարտ բանալիների արժեքների զույգեր՝ ներքևի առաջադրանքների և գործողությունների համար:

Ինտերֆեյսի փաստերը կարող են ավելացվել Ansible-ի պահված փոփոխականներին և օգտագործվել անմիջապես կամ ավելի ուշ որպես ռեսուրսների մոդուլի մուտքագրում: 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

Ինչպես տեսնում եք, սարքից հավաքված տվյալները փոխանցվում են անմիջապես համապատասխան ռեսուրսային մոդուլին՝ առանց փոխակերպման: Երբ գործարկվում է, խաղագիրքը սարքից վերցնում է արժեքները և համեմատում դրանք ակնկալվող արժեքների հետ: Այս օրինակում վերադարձված արժեքները սպասվածի նման են (այսինքն, այն ստուգում է կազմաձևման շեղումները) և հայտնում է, թե արդյոք կոնֆիգուրացիան փոխվել է:

Կազմաձևման շեղումը հայտնաբերելու իդեալական միջոցը փաստերը Ansible-ի պահված փոփոխականներում պահելն է և պարբերաբար օգտագործել դրանք ռեսուրսի մոդուլի հետ ստուգման ռեժիմում: Սա պարզ մեթոդ է՝ տեսնելու, թե արդյոք ինչ-որ մեկը ձեռքով փոխել է արժեքները: Շատ դեպքերում կազմակերպությունները թույլ են տալիս փոփոխություններ և կազմաձևում ձեռքով, թեև շատ գործողություններ կատարվում են Ansible Automation-ի միջոցով:

Ինչպե՞ս են նոր ռեսուրսների մոդուլները տարբերվում նախորդներից:

Ցանցի ավտոմատացման ինժեների համար կա 3 հիմնական տարբերություն Ansible 2.9-ի ռեսուրսների մոդուլների և նախորդ տարբերակների միջև:

1) Տվյալ ցանցային ռեսուրսի համար (որը կարող է նաև դիտարկվել որպես կազմաձևման բաժին), մոդուլները և փաստերը կզարգանան բոլոր աջակցվող ցանցային օպերացիոն համակարգերում միաժամանակ: Մենք կարծում ենք, որ եթե Ansible-ն աջակցում է ռեսուրսների կազմաձևմանը մեկ ցանցային հարթակում, մենք պետք է աջակցենք այն ամենուր: Սա հեշտացնում է ռեսուրսների մոդուլների օգտագործումը, քանի որ ցանցի ավտոմատացման ինժեներն այժմ կարող է կարգավորել ռեսուրսը (օրինակ՝ LLDP) ցանցի բոլոր օպերացիոն համակարգերում՝ տեղական և աջակցվող մոդուլներով:

2) Ռեսուրսների մոդուլներն այժմ ներառում են պետական ​​արժեք:

• merged: կոնֆիգուրացիան միավորված է տրամադրված կազմաձևի հետ (կանխադրված);
• replacedՌեսուրսի կոնֆիգուրացիան կփոխարինվի տրամադրված կազմաձևով.
• overriddenՌեսուրսի կոնֆիգուրացիան կփոխարինվի տրամադրված կազմաձևով. ավելորդ ռեսուրսների օրինակները կջնջվեն.
• deletedՌեսուրսի կոնֆիգուրացիան կջնջվի/վերականգնվի լռելյայն:

3) Ռեսուրսների մոդուլներն այժմ ներառում են կայուն վերադարձի արժեքներ: Երբ ցանցային ռեսուրսների մոդուլը կատարել է (կամ առաջարկել) անհրաժեշտ փոփոխությունները ցանցային սարքում, այն վերադարձնում է նույն բանալի-արժեք զույգերը խաղագիրք:

• before: սարքի վրա կազմաձևումը կառուցվածքային տվյալների տեսքով՝ առաջադրանքից առաջ.
• afterեթե սարքը փոխվել է (կամ կարող է փոխվել, եթե օգտագործվում է թեստային ռեժիմ), ստացված կոնֆիգուրացիան կվերադարձվի որպես կառուցվածքային տվյալներ.
• commands: Սարքի վրա գործարկվում են կազմաձևման ցանկացած հրաման՝ այն ցանկալի վիճակի բերելու համար:

Ի՞նչ է նշանակում այս ամենը: Ինչու է դա կարևոր:

Այս գրառումը ներառում է շատ բարդ հասկացություններ, բայց մենք հուսով ենք, որ ի վերջո դուք ավելի լավ կհասկանաք, թե ինչ են պահանջում ձեռնարկության հաճախորդները իրականում հավաքագրման, տվյալների նորմալացման և ավտոմատացման հարթակի համար հանգույցի կազմաձևման մասին: Բայց ինչո՞ւ են նրանց պետք այս բարելավումները: Շատ կազմակերպություններ այժմ ձգտում են թվային փոխակերպման՝ իրենց ՏՏ միջավայրն ավելի ճկուն և մրցունակ դարձնելու համար: Լավ թե վատ, շատ ցանցային ինժեներներ դառնում են ցանցի մշակողներ կամ սեփական շահերից ելնելով, կամ ղեկավարության թելադրանքով:

Կազմակերպությունները գիտակցում են, որ անհատական ​​ցանցային կաղապարների ավտոմատացումը չի լուծում սիլոսների խնդիրը և միայն որոշակի չափով բարձրացնում է արդյունավետությունը: Red Hat Ansible Automation Platform-ն ապահովում է ռեսուրսների տվյալների խիստ և նորմատիվ մոդելներ՝ ցանցային սարքի հիմքում ընկած տվյալները ծրագրավորելու համար: Այսինքն, օգտվողներն աստիճանաբար հրաժարվում են անհատական ​​կազմաձևման մեթոդներից՝ հօգուտ ավելի ժամանակակից մեթոդների՝ շեշտը դնելով տեխնոլոգիաների վրա (օրինակ՝ IP հասցեներ, VLAN-ներ, LLDP և այլն), այլ ոչ թե կոնկրետ վաճառողի ներդրման վրա:

Արդյո՞ք սա նշանակում է, որ հուսալի և ապացուցված հրամանի մոդուլների և կոնֆիգուրացիայի օրերը համարակալված են: Ոչ մի դեպքում։ Ցանցի ռեսուրսների ակնկալվող մոդուլները կիրառելի չեն լինի բոլոր դեպքերում կամ յուրաքանչյուր վաճառողի համար, ուստի հրամանի և կազմաձևման մոդուլները դեռևս անհրաժեշտ կլինեն ցանցի ինժեներներին որոշակի իրականացումների համար: Ռեսուրսների մոդուլների նպատակն է պարզեցնել մեծ Jinja ձևանմուշները և նորմալացնել սարքի չկառուցված կոնֆիգուրացիաները JSON ձևաչափով: Ռեսուրսների մոդուլներով, գոյություն ունեցող ցանցերի համար ավելի հեշտ կլինի փոխակերպել իրենց կոնֆիգուրացիան կառուցվածքային բանալի-արժեք զույգերի, որոնք ներկայացնում են ճշմարտության հեշտ ընթեռնելի աղբյուր: Օգտագործելով կառուցվածքային բանալի-արժեք զույգեր՝ դուք կարող եք յուրաքանչյուր սարքի վրա գործարկվող կոնֆիգուրացիաներից անցնել անկախ կառուցվածքային տվյալների հետ աշխատելու և ցանցերը բերել ենթակառուցվածքի կոդ մոտեցման առաջնագիծ:

Ի՞նչ ռեսուրսների մոդուլներ են հայտնվելու Ansible Engine 2.9-ում:

Նախքան ձեզ մանրամասն պատմենք, թե ինչ է լինելու Ansible 2.9-ում, եկեք հիշենք, թե ինչպես ենք բաժանել աշխատանքի ողջ շրջանակը:

Մենք հայտնաբերեցինք 7 կատեգորիա և յուրաքանչյուրին հատկացրինք հատուկ ցանցային ռեսուրսներ.

Նշում. թավատառերով ռեսուրսները պլանավորվել և ներդրվել են Ansible 2.9-ում:
Հիմնվելով ձեռնարկության հաճախորդների և համայնքի արձագանքների վրա, տրամաբանական էր նախ լուծել ցանցի տոպոլոգիայի արձանագրությունների, վիրտուալացման և ինտերֆեյսերի հետ կապված մոդուլները:
Հետևյալ ռեսուրսային մոդուլները մշակվել են Ansible Network թիմի կողմից և համապատասխանում են Red Hat-ի կողմից աջակցվող հարթակներին.

Հետևյալ մոդուլները մշակված են Ansible համայնքի կողմից.

• exos_lldp_global - Extreme Networks-ից:
• nxos_bfd_interfaces - Cisco-ից
• nxos_telemetry - Cisco-ից

Ինչպես տեսնում եք, ռեսուրսների մոդուլների հայեցակարգը տեղավորվում է մեր պլատֆորմակենտրոն ռազմավարության մեջ: Այսինքն՝ մենք ներառում ենք անհրաժեշտ հնարավորություններն ու գործառույթները հենց Ansible-ում՝ ցանցային մոդուլների մշակման մեջ ստանդարտացմանն աջակցելու, ինչպես նաև Ansible դերերի և խաղային գրքույկների մակարդակով օգտատերերի աշխատանքը պարզեցնելու համար: Ռեսուրսների մոդուլների զարգացումն ընդլայնելու համար Ansible թիմը թողարկեց Module Builder գործիքը:

Ծրագրեր Ansible 2.10-ի և դրանից դուրս

Երբ Ansible 2.9-ը թողարկվի, մենք կաշխատենք Ansible 2.10-ի ռեսուրսների մոդուլների հաջորդ հավաքածուի վրա, որոնք կարող են օգտագործվել ցանցի տոպոլոգիան և քաղաքականությունը հետագա կարգավորելու համար, օրինակ. ACL, OSPF և BGP. Զարգացման պլանը դեռ կարող է ճշգրտվել, այնպես որ, եթե մեկնաբանություններ ունեք, խնդրում ենք հայտնել դրա մասին Ansible ցանցային համայնք.

Ռեսուրսներ և սկսել

Մամլո հաղորդագրություն Ansible Automation Platform-ի մասին
Ansible ավտոմատացման հարթակի բլոգ
Բովանդակության առաքման ապագան Ansible-ում
Մտորումներ Ansible նախագծի կառուցվածքը փոխելու վերաբերյալ

Source: www.habr.com