У майбутньому випуску Red Hat Ansible Engine 2.9 на вас чекають вражаючі поліпшення, і деякі з них описані в цій статті. Як завжди, ми розробляли покращення Ansible Network у відкриту, за підтримки спільноти. Приєднуйтесь - загляньте на та вивчіть план розвитку для на сторінці wiki для .
Як ми нещодавно оголосили, тепер включає 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 з боку кінцевих користувачів. І ось що ми з'ясували:
- Організації автоматизують пристрої не одного, а багатьох вендорів.
- Автоматизація — явище не лише технічне, а й культурне.
- Масштабна автоматизація мереж складніша, ніж здається, через фундаментальні архітектурні принципи проектування автоматизації.
Коли ми обговорювали наші довгострокові плани розвитку більше року тому, наші корпоративні клієнти просили наступне:
- Збір фактів потрібно краще стандартизувати та узгодити з робочим процесом автоматизації для будь-яких пристроїв.
- Оновлення конфігурацій на пристрої теж потрібно стандартизувати та узгодити, щоб модулі Ansible обробляли другу половину циклу після збирання фактів.
- Потрібні строгі та підтримувані методи перетворення конфігурації пристрою на структуровані дані. На цій основі джерело істини можна перемістити з мережевого пристрою.
Поліпшення фактів
Збір фактів з мережевих пристроїв з допомогою Ansible часто відбувається навмання. Мережеві платформи різною мірою оснащені можливостями збирання фактів, але вони майже немає — і навіть зовсім немає — функцій для парсингу і стандартизації представлення даних у парах ключ-значение. Читайте Кена Селенці (Ken Celenza) про те, як складно і болісно буває аналізувати та стандартизувати дані фактів.
Можливо ви помітили, як ми працювали над роллю Ansible Network Engine. Природно, через 24 тисячі завантажень роль Network Engine швидко стала однією з найпопулярніших ролей Ansible в Ansible Galaxy для сценаріїв автоматизації мережі. Перш ніж ми перенесли багато з цього Ansible 2.8, щоб підготуватися до того, що знадобиться в Ansible 2.9, ця роль Ansible надала перший набір інструментів для допомоги в парсингу команд, управлінні командами і зборі даних для мережних пристроїв.
Якщо ви розумієтеся у використанні Network Engine, це дуже ефективний спосіб збирання, парсингу та стандартизації даних фактів для використання в Ansible. Мінус цієї ролі в тому, що потрібно створювати цілу купу парсерів для кожної платформи і всієї мережевої активності. Щоб зрозуміти, як складно створювати, постачати та обслуговувати парсери, подивіться на від хлопців із 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.
Чим нові модулі ресурсу відрізняються від попередніх?
Для інженера з автоматизації мереж існують три основні відмінності модулів ресурсу в Ansible 3 від попередніх версій.
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- від Cisconxos_telemetry- від Cisco
Як бачите, концепція модулів ресурсів вписується у нашу стратегію орієнтації на платформи. Тобто ми включаємо необхідні можливості та функції в сам Ansible, щоб підтримати стандартизацію при розробці мережевих модулів, а також спростити роботу користувачів на рівні ролей та плейбуків Ansible. Щоб розширити розробку модулів ресурсів, команда Ansible випустила інструмент Module Builder.
Плани на Ansible 2.10 і надалі
Після випуску Ansible 2.9 ми займемося наступним набором модулів ресурсів для Ansible 2.10, які можна буде використовувати для подальшого налаштування топології та політики мережі, наприклад . План розвитку ще можна коригувати, тому, якщо у вас є коментарі, повідомте про це в .
Ресурси та початок роботи
Джерело: habr.com