Использование ролей Ansible для сети

Роли представляют собой наборы Ansible-значений по умолчанию, файлов, задач, шаблонов, переменных и других Ansible-компонентов, работающих совместно. Как вы видели в Выполнение первой команды и книги задач, переход от команды к книге задач упрощает выполнение нескольких задач и повторение одних и тех же задач в одном и том же порядке. Переход от книги задач к роли еще больше упрощает повторное использование и совместное использование ваших упорядоченных задач. Вы можете ознакомиться с Ansible Galaxy, которая позволяет делиться своими ролями и использовать роли других, как напрямую, так и для вдохновения.

• Понимание ролей
  • Пример книги задач DNS
  • Преобразование книги задач в роль
  • Порядок приоритета переменных
    • Самый низкий приоритет
    • Самый высокий приоритет
• Поддерживаемые Ansible роли для сети
• Цикл выпуска ролей для сети
  • Обновление установленной роли

Понимание ролей

Итак, что же такое роль и почему вам следует ей интересоваться? Ansible-роли — это по сути книги задач, разбитые на известную структуру файлов. Переход от книги задач к ролям упрощает совместное использование, чтение и обновление вашего Ansible-потока работы. Пользователи могут создавать свои собственные роли. Например, вам не нужно писать собственную книгу задач DNS. Вместо этого вы указываете сервер DNS и роль для его настройки.

Чтобы еще больше упростить вашу работу, команда Ansible Network написала ряд ролей для распространенных сценариев использования сети. Использование этих ролей означает, что вам не нужно изобретать велосипед. Вместо написания и поддержки собственных create_vlan книг задач или ролей, вы можете сосредоточиться на проектировании, кодировании и поддержке шаблонов парсера, описывающих вашу сетевую топологию и инвентаризацию, и позволить ролям сети Ansible выполнить работу. Смотрите сетевые роли в Ansible Galaxy.

Пример книги задач DNS

Чтобы продемонстрировать концепцию роли, приведенный ниже пример playbook.yml представляет собой один файл YAML, содержащий книгу задач с двумя задачами. Эта Ansible-книга задач настраивает имя хоста на устройстве Cisco IOS XE, а затем настраивает серверы DNS (доменной системы имен).

---
- name: configure cisco routers
  hosts: routers
  connection: network_cli
  gather_facts: no
  vars:
    dns: "8.8.8.8 8.8.4.4"

  tasks:
   - name: configure hostname
     ios_config:
       lines: hostname {{ inventory_hostname }}

   - name: configure DNS
     ios_config:
       lines: ip name-server {{dns}}

Если вы запустите эту книгу задач с помощью команды ansible-playbook, вы увидите вывод ниже. В этом примере использовался параметр -l, чтобы ограничить выполнение книги задач только на узле rtr1.

[user@ansible ~]$ ansible-playbook playbook.yml -l rtr1

PLAY [configure cisco routers] *************************************************

TASK [configure hostname] ******************************************************
changed: [rtr1]

TASK [configure DNS] ***********************************************************
changed: [rtr1]

PLAY RECAP *********************************************************************
rtr1                       : ok=2    changed=2    unreachable=0    failed=0

Эта книга задач настроила имя хоста и серверы DNS. Вы можете проверить эту конфигурацию на маршрутизаторе Cisco IOS XE rtr1:

rtr1#sh run | i name
hostname rtr1
ip name-server 8.8.8.8 8.8.4.4

Преобразование книги задач в роль

Следующим шагом является преобразование этой книги задач в многократно используемую роль. Вы можете создать структуру каталогов вручную или использовать ansible-galaxy init для создания стандартной структуры роли.

[user@ansible ~]$ ansible-galaxy init system-demo
[user@ansible ~]$ cd system-demo/
[user@ansible system-demo]$ tree
.
├── defaults
│   └── main.yml
├── files
├── handlers
│   └── main.yml
├── meta
│   └── main.yml
├── README.md
├── tasks
│   └── main.yml
├── templates
├── tests
│   ├── inventory
│   └── test.yml
└── vars
  └── main.yml

В этой первой демонстрации используются только каталоги tasks и vars. Структура каталогов будет выглядеть следующим образом:

[user@ansible system-demo]$ tree
.
├── tasks
│   └── main.yml
└── vars
    └── main.yml

Далее переместите содержимое разделов vars и tasks из исходной книги задач Ansible в роль. Сначала переместите две задачи в файл tasks/main.yml.

[user@ansible system-demo]$ cat tasks/main.yml
---
- name: configure hostname
  ios_config:
    lines: hostname {{ inventory_hostname }}

- name: configure DNS
  ios_config:
    lines: ip name-server {{dns}}

Затем переместите переменные в файл vars/main.yml:

[user@ansible system-demo]$ cat vars/main.yml
---
dns: "8.8.8.8 8.8.4.4"

Наконец, измените исходную книгу задач Ansible, удалив разделы tasks и vars и добавив ключевое слово roles с именем роли, в данном случае system-demo. Получится такая книга задач:

---
- name: configure cisco routers
  hosts: routers
  connection: network_cli
  gather_facts: no

  roles:
    - system-demo

Подводя итог, в этой демонстрации теперь есть три каталога и три файла YAML. Есть каталог system-demo, представляющий собой роль. Этот каталог system-demo содержит два каталога, tasks и vars. В каждом каталоге есть main.yml. Каталог vars/main.yml содержит переменные из playbook.yml. Каталог tasks/main.yml содержит задачи из playbook.yml. Файл playbook.yml был изменен для вызова роли вместо прямого указания переменных и задач. Вот дерево текущей рабочей директории:

[user@ansible ~]$ tree
.
├── playbook.yml
└── system-demo
    ├── tasks
    │   └── main.yml
    └── vars
        └── main.yml

Запуск книги задач приводит к идентичному поведению с немного отличающимся выводом:

[user@ansible ~]$ ansible-playbook playbook.yml -l rtr1

PLAY [configure cisco routers] *************************************************

TASK [system-demo : configure hostname] ****************************************
ok: [rtr1]

TASK [system-demo : configure DNS] *********************************************
ok: [rtr1]

PLAY RECAP *********************************************************************
rtr1             : ok=2    changed=0    unreachable=0    failed=0

Как видно выше, каждая задача теперь имеет префикс с именем роли, в данном случае system-demo. При запуске книги задач, содержащей несколько ролей, это поможет определить, откуда вызывается задача. Эта книга задач вернула ok вместо changed, потому что имеет идентичное поведение для исходной книги задач с одним файлом.

Как и прежде, книга задач сгенерирует следующую конфигурацию на маршрутизаторе Cisco IOS-XE:

rtr1#sh run | i name
hostname rtr1
ip name-server 8.8.8.8 8.8.4.4

Вот почему Ansible-роли можно просто рассматривать как деконструированные книги задач. Они просты, эффективны и многократно используются. Теперь другой пользователь может просто включить роль system-demo вместо создания пользовательской "жестко закодированной" книги задач.

Порядок приоритета переменных

А что, если вы хотите изменить серверы DNS? Не предполагается, что вы будете изменять vars/main.yml в структуре роли. Ansible имеет много мест, где можно указать переменные для определенной книги задач. Подробности о переменных и порядке приоритета см. в разделе Использование переменных. На самом деле существует 21 место для размещения переменных. Хотя этот список может показаться ошеломляющим с первого взгляда, подавляющее большинство случаев использования сводится к знанию места переменных наименьшего приоритета и способу передачи переменных наибольшего приоритета. См. Порядок приоритета переменных: где разместить переменную? для получения дополнительной информации о том, где размещать переменные.

Самый низкий приоритет

Самый низкий приоритет имеет каталог defaults внутри роли. Это означает, что все остальные 20 возможных мест для указания переменной будут иметь более высокий приоритет, чем defaults, независимо от чего. Чтобы немедленно дать переменным из роли system-demo наименьший приоритет, переименуйте каталог vars в defaults.

[user@ansible system-demo]$ mv vars defaults
[user@ansible system-demo]$ tree
.
├── defaults
│   └── main.yml
├── tasks
│   └── main.yml

Добавьте новый раздел vars в книгу задач, чтобы переопределить поведение по умолчанию (где переменная dns устанавливается в 8.8.8.8 и 8.8.4.4). В этой демонстрации установите dns в 1.1.1.1, так что playbook.yml станет:

---
- name: configure cisco routers
  hosts: routers
  connection: network_cli
  gather_facts: no
  vars:
    dns: 1.1.1.1
  roles:
    - system-demo

Запустите эту обновленную книгу задач на rtr2:

[user@ansible ~]$ ansible-playbook playbook.yml -l rtr2

Конфигурация на маршрутизаторе Cisco rtr2 будет выглядеть следующим образом:

rtr2#sh run | i name-server
ip name-server 1.1.1.1

Переменная, настроенная в книге задач, теперь имеет приоритет над каталогом defaults. На самом деле, любое другое место для настройки переменных будет иметь преимущество над значениями в каталоге defaults.

Самый высокий приоритет

Указание переменных в каталоге defaults внутри роли всегда будет иметь наименьший приоритет, в то время как указание vars в качестве дополнительных переменных с -e или --extra-vars= всегда будет иметь наивысший приоритет независимо ни от чего. Повторный запуск книги задач с параметром -e переопределяет как каталог defaults (8.8.4.4 и 8.8.8.8), так и вновь созданный каталог vars в книге задач, содержащий сервер DNS 1.1.1.1.

[user@ansible ~]$ ansible-playbook playbook.yml -e "dns=192.168.1.1" -l rtr3

Результат на маршрутизаторе Cisco IOS XE будет содержать только настройку с наивысшим приоритетом 192.168.1.1:

rtr3#sh run | i name-server
ip name-server 192.168.1.1

В чем польза этого? Почему это важно? Дополнительные переменные обычно используются сетевыми операторами для переопределения значений по умолчанию. Ярким примером этого является использование Red Hat Ansible Tower и функции Survey. С помощью веб-интерфейса можно запросить у сетевого оператора заполнить параметры с помощью веб-формы. Это может быть очень простым способом для пользователей без технических навыков выполнения книги задач с помощью веб-браузера. Подробнее см. Ansible Tower Job Template Surveys.

Поддерживаемые Ansible роли для сети

Команда Ansible Network разрабатывает и поддерживает набор сетевых ролей в Ansible Galaxy. Вы можете использовать эти роли для ускорения ваших сетевых автоматизационных работ. Эти роли обновляются примерно раз в две недели, чтобы вы имели доступ к последним сетевым материалам Ansible.

Эти роли делятся на следующие категории:

• Роли пользователей - Роли пользователей сфокусированы на задачах, таких как управление вашей конфигурацией. Используйте эти роли, такие как config_manager и cloud_vpn, напрямую в ваших playbook'ах. Эти роли независимы от платформы/поставщика, позволяя использовать одни и те же роли и playbook'и на разных сетевых платформах или поставщиках облачных услуг.
• Роли поставщика платформы - Роли поставщика переводят между ролями пользователей и различными сетевыми ОС, каждая из которых имеет свой API. Каждая роль поставщика принимает входные данные от поддерживаемой роли пользователя и переводит их для конкретной сетевой ОС. Роли сетевых пользователей зависят от этих ролей поставщика для реализации своих функций. Например, роль пользователя config_manager использует роль поставщика cisco_ios для выполнения задач на сетевых устройствах Cisco IOS.
• Роли поставщика облачных услуг и провайдера - Аналогично, роли пользователей облачных сервисов зависят от ролей поставщика облачных услуг и провайдера для реализации облачных функций для конкретных поставщиков облачных услуг. Например, роль cloud_vpn зависит от роли поставщика aws для взаимодействия с AWS.

Вам необходимо установить хотя бы одну роль поставщика платформы для ваших ролей сетевых пользователей и установить ansible_network_provider на этого поставщика (например, ansible_network_provider: ansible-network.cisco_ios). Ansible Galaxy автоматически устанавливает все другие зависимости, перечисленные в деталях роли в Ansible Galaxy.

Например, чтобы использовать роль config_manager с устройствами Cisco IOS, используйте следующие команды:

[user@ansible]$ ansible-galaxy install ansible-network.cisco_ios
[user@ansible]$ ansible-galaxy install ansible-network.config_manager

Роли полностью документированы с примерами в Ansible Galaxy на вкладке Read Me для каждой роли.

Цикл выпуска ролей сети

Команда Ansible по работе с сетями выпускает обновления и новые роли каждые две недели. Подробная информация о ролях в Ansible Galaxy перечисляет доступные версии ролей, и вы можете посмотреть в репозитории GitHub, чтобы найти файл с изменениями (например, cisco_ios CHANGELOG.rst ), который перечисляет изменения в каждой версии роли.

Версия роли Ansible Galaxy состоит из двух компонентов:

• Главный номер версии (например, 2.6), который показывает версию движка Ansible, поддерживаемую этой ролью.
• Дополнительный номер версии (например, .1), который обозначает цикл выпуска роли и не отражает версию незначительного выпуска движка Ansible.

Обновить установленную роль

Страница Ansible Galaxy для роли перечисляет все доступные версии. Чтобы обновить локально установленную роль до новой или другой версии, используйте команду ansible-galaxy install с версией и опцией --force. Возможно, вам также потребуется вручную обновить все зависимые роли, чтобы они поддерживали эту версию. См. вкладку Read Me роли в Galaxy для минимальных требований к зависимым ролям.

[user@ansible]$ ansible-galaxy install ansible-network.network_engine,v2.7.0 --force
[user@ansible]$ ansible-galaxy install ansible-network.cisco_nxos,v2.7.1 --force