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

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

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

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

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

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

Пример плейбука DNS

Чтобы продемонстрировать концепцию роли, следующий пример playbook.yml — это один YAML-файл, содержащий плейбук из двух задач. Этот Ansible Playbook настраивает имя хоста на устройстве 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 Playbook в роль. Перенесите две задачи в файл 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 Playbook, удалив секции 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_nxos
[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