Inside Playbook. ქსელის ფუნქციები ახალ Ansible Engine 2.9-ში

Red Hat Ansible Engine 2.9-ის მომავალ გამოშვებას მოაქვს საინტერესო გაუმჯობესებები, რომელთაგან ზოგიერთი განხილულია ამ სტატიაში. როგორც ყოველთვის, ჩვენ ვავითარებთ Ansible ქსელის გაუმჯობესებას ღიად, საზოგადოების მხარდაჭერით. შემოგვიერთდით - შეხედეთ გამოშვების დაფა 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

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 დამატებითი დამუშავების ან კონვერტაციის გარეშე.

რესურსის მოდულები

ასე რომ, ჩვენ გამოვყავით ფაქტები, მოვახდინეთ მონაცემების ნორმალიზება, მოვათავსეთ ისინი მონაცემთა შიდა სტრუქტურის სტანდარტიზებულ დიაგრამაში და მივიღეთ მზა სიმართლის წყარო. ჰოო! რა თქმა უნდა, ეს შესანიშნავია, მაგრამ ჩვენ მაინც გვჭირდება როგორმე გადავიტანოთ გასაღები-მნიშვნელობის წყვილები კონკრეტულ კონფიგურაციაზე, რომელსაც კონკრეტული მოწყობილობის პლატფორმა ელის. ახლა ჩვენ გვჭირდება პლატფორმის სპეციფიკური მოდულები, რათა დავაკმაყოფილოთ ახალი ფაქტების შეგროვებისა და ნორმალიზაციის მოთხოვნები.

რა არის რესურსის მოდული? თქვენ შეგიძლიათ წარმოიდგინოთ მოწყობილობის კონფიგურაციის სექციები, როგორც ამ მოწყობილობის მიერ მოწოდებული რესურსები. ქსელის რესურსების მოდულები განზრახ შემოიფარგლება ერთი რესურსით და შეიძლება დალაგდეს სამშენებლო ბლოკების მსგავსად რთული ქსელის სერვისების კონფიგურაციისთვის. შედეგად, რესურსების მოდულის მოთხოვნები და სპეციფიკაციები ბუნებრივად გამარტივებულია, რადგან რესურსის მოდულს შეუძლია წაიკითხოს и კონკრეტული ქსელის სერვისის კონფიგურაცია ქსელურ მოწყობილობაზე.

იმის ასახსნელად, თუ რას აკეთებს რესურსის მოდული, მოდით შევხედოთ სათამაშო წიგნის მაგალითს, რომელიც აჩვენებს იდემპოდენტურ ოპერაციას ახალი ქსელის რესურსის ფაქტებისა და მოდულის გამოყენებით. 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: ნებისმიერი კონფიგურაციის ბრძანება მუშაობს მოწყობილობაზე, რათა ის სასურველ მდგომარეობაში იყოს.

რას ნიშნავს ეს ყველაფერი? Რატომ არის ეს მნიშვნელოვანი?

ეს პოსტი მოიცავს უამრავ რთულ კონცეფციას, მაგრამ ჩვენ ვიმედოვნებთ, რომ საბოლოოდ თქვენ უკეთ გაიგებთ, თუ რას ითხოვენ საწარმოს კლიენტები რეალურად შეგროვებას, მონაცემთა ნორმალიზებას და მარყუჟის კონფიგურაციას ავტომატიზაციის პლატფორმისთვის. მაგრამ რატომ სჭირდებათ მათ ეს გაუმჯობესება? ბევრი ორგანიზაცია ახლა ცდილობს ციფრული ტრანსფორმაციას, რათა მათი IT გარემო უფრო სწრაფი და კონკურენტუნარიანი გახდეს. კარგი თუ უარესი, ბევრი ქსელის ინჟინერი ხდება ქსელის დეველოპერები ან საკუთარი ინტერესებიდან გამომდინარე ან მენეჯმენტის დავალებით.

ორგანიზაციები აცნობიერებენ, რომ ინდივიდუალური ქსელის შაბლონების ავტომატიზაცია არ წყვეტს სილოსის პრობლემას და მხოლოდ გარკვეულწილად ზრდის ეფექტურობას. 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 - ექსტრემალური ქსელებიდან.
• 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 ავტომატიზაციის პლატფორმის შესახებ
Ansible ავტომატიზაციის პლატფორმის ბლოგი
შინაარსის მიწოდების მომავალი Ansible-ში
რეფლექსია Ansible პროექტის სტრუქტურის შეცვლაზე

წყარო: www.habr.com