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

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

• Пример книги сценариев DNS
• Преобразование книги сценариев в роль

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

  • Наименьший приоритет
  • Наивысший приоритет
• Обновление установленной роли

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

Итак, что же такое роль и почему вам это нужно? 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: ansible.netcommon.network_cli
  gather_facts: no
  vars:
    dns: "8.8.8.8 8.8.4.4"

  tasks:
   - name: configure hostname
     cisco.ios.ios_config:
       lines: hostname {{ inventory_hostname }}

   - name: configure DNS
     cisco.ios.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
  cisco.ios.ios_config:
    lines: hostname {{ inventory_hostname }}

- name: configure DNS
  cisco.ios.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: ansible.netcommon.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: ansible.netcommon.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 и функции обследования. С помощью веб-интерфейса можно запросить у сетевого оператора заполнение параметров с помощью веб-формы. Это может быть очень простым способом для пользователей без технических знаний выполнять книгу сценариев с помощью веб-браузера. Более подробную информацию см. в разделе Ansible Tower Job Template Surveys.

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

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

[user@ansible]$ ansible-galaxy install mynamespace.my_role,v2.7.1 --force